12017-08-18T00:00:05  <gmaxwell> thats a lot, time for a reback.
  22017-08-18T00:00:10  <gmaxwell> repack.
  32017-08-18T00:00:24  <kanzure> also other unmerged branches though
  42017-08-18T00:00:36  <kanzure> sipa might even have elements.git branches in there
  52017-08-18T00:02:18  <sipa> no
  62017-08-18T00:03:09  <kanzure> welp.
  72017-08-18T00:10:58  <luke-jr> cfields: it occurs to me the reason the dir is dirty, is because it's missing files; so if we want to defer doing a real fix, we can alternatively fix the missing-files issue instead, by generating the tarball from git-archive
  82017-08-18T00:20:29  *** Chris_St1 has quit IRC
  92017-08-18T00:25:25  *** Murch has quit IRC
 102017-08-18T00:26:44  *** JackH has joined #bitcoin-core-dev
 112017-08-18T00:29:51  <cfields> luke-jr: I believe the dir is dirty because we extract the tarball into it
 122017-08-18T00:31:10  <luke-jr> that doesn't make sense..
 132017-08-18T00:40:37  *** MeshNet2 has quit IRC
 142017-08-18T00:41:33  *** Cryptocide has joined #bitcoin-core-dev
 152017-08-18T00:42:32  *** JackH has quit IRC
 162017-08-18T00:46:05  *** rockhouse has quit IRC
 172017-08-18T00:53:49  *** laurentmt has joined #bitcoin-core-dev
 182017-08-18T00:55:44  *** dabura667 has joined #bitcoin-core-dev
 192017-08-18T00:56:30  <praxeology> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
 202017-08-18T00:56:53  <praxeology> sorry my 2yo grabbed my mouse
 212017-08-18T00:57:21  *** str4d has quit IRC
 222017-08-18T00:57:55  *** AaronvanW has quit IRC
 232017-08-18T01:08:43  <cfields> luke-jr: I see what you mean
 242017-08-18T01:08:51  <promag> praxeology: I feel you too
 252017-08-18T01:11:47  *** jtimon has quit IRC
 262017-08-18T01:16:09  <Cryptocide> Abra|BitClub Network|Bitcoin.com|BitFury|BitGo|Bitmain|BitPay Blockchain|Bloq|BTCC|Circle|Ledger|RSK Labs|Xapo, no thanks
 272017-08-18T01:17:42  <kanzure> why XORing them? i don't get it.
 282017-08-18T01:17:50  <kanzure> er, ORing
 292017-08-18T01:18:32  <kanzure> yes. anyway.
 302017-08-18T01:18:46  *** promag has quit IRC
 312017-08-18T01:20:57  *** cheese_ has joined #bitcoin-core-dev
 322017-08-18T01:22:57  *** Mattie161 has quit IRC
 332017-08-18T01:23:29  *** Mattie161 has joined #bitcoin-core-dev
 342017-08-18T01:23:39  *** niska has quit IRC
 352017-08-18T01:24:10  *** Cheeseo has quit IRC
 362017-08-18T01:24:50  *** niska has joined #bitcoin-core-dev
 372017-08-18T01:30:04  *** laurentmt has quit IRC
 382017-08-18T01:30:11  *** RoyceX has joined #bitcoin-core-dev
 392017-08-18T01:33:30  *** cheese_ has quit IRC
 402017-08-18T01:33:40  *** Cheeseo has joined #bitcoin-core-dev
 412017-08-18T01:35:50  *** RoyceX has quit IRC
 422017-08-18T01:35:52  *** cheese_ has joined #bitcoin-core-dev
 432017-08-18T01:39:21  *** Cheeseo has quit IRC
 442017-08-18T01:40:22  *** hsmiths has quit IRC
 452017-08-18T01:42:19  *** mariorz has quit IRC
 462017-08-18T01:42:36  <kallewoof> I'm running a modified Bitcoin Core node to do some profiling on where resources are spent (CPU cycles and bandwidth in particular) and am seeing some really weird stuff. E.g:
 472017-08-18T01:42:43  <kallewoof>  0.77877            27892        282511326         24083459                0 131703419 SendMessages.inventory.trickle (tx-relay).LOCK(cs)
 482017-08-18T01:43:34  <kallewoof> The columns are "portion of CPU used", "min CPU cycles", "max CPU cycles", "medium CPU cycles per call", "bandwidth per call", "# of calls", "code path"
 492017-08-18T01:44:07  <kallewoof> So the LOCK(cs) in SendMessages for inventory for trickle for the tx relay part is taking 78% of all CPU cycles for my node. Does that seem normal?
 502017-08-18T01:44:18  *** mariorz has joined #bitcoin-core-dev
 512017-08-18T01:45:06  <kallewoof> Also baffled by the number of calls. 131 million. I started profiling yesterday.
 522017-08-18T01:49:39  <kallewoof> This is probably from the mempool.info(hash) call in the while loop btw. That probably explains the high # of calls, but 131 million in 24 hours is 1500/second. Maybe my profiling code is broken.
 532017-08-18T01:51:54  <kallewoof> ... Actually, it rose by 38k from 01:48:49 to 01:50:00, so doesn't seem improbable.
 542017-08-18T02:23:07  <gmaxwell> sometimes profiling is confused by locks. (and/or moderately condented locks in an otherwise inactive process can be a high percentage due to spinning).
 552017-08-18T02:23:12  <gmaxwell> Sounds like it might be interesting.
 562017-08-18T02:23:21  <praxeology> Re: https://docs.google.com/document/d/1y6Hsqdg1xBrJY4dFeKP6y05XCceJoVMs0_M_VwKFReM/edit  Maybe it would be a good idea to communicate with the exchanges and check and see who will continue to support Bitcoin Core's chain
 572017-08-18T02:23:48  <gmaxwell> Everyone okay with me doing a presentation on 0.15 improvements to a local group in 1.5 weeks?
 582017-08-18T02:25:22  *** cheese_ has quit IRC
 592017-08-18T02:26:02  <praxeology> Like... I know that BitPay and Coinbase are declaring that they will support Segwit2x... has any exchange declared that they will continue to support Bitcoin (Bitcoin Core's rules)?
 602017-08-18T02:27:38  <kallewoof> gmaxwell: there is some amount of overhead as I am doing the profiling on my own. Maybe that's the cause for the high portion of time spent there, but it still seems like a lot of LOCK calls, regardless of actual CPU cycle count. Would be cool if the mempool could be copied once and then not lock cs at all. Code is here btw: https://github.com/kallewoof/bitcoin/tree/profile-resources
 612017-08-18T02:28:05  <sipa> copying the whole mempool?
 622017-08-18T02:28:14  <kallewoof> Only the hashes.
 632017-08-18T02:28:20  <sipa> oh
 642017-08-18T02:29:09  <kallewoof> Actually that wouldn't work. It uses txinfo for feeRate and tx etc.
 652017-08-18T02:29:33  <praxeology> kallewoof: does your bitcoin process have enough memory to hold the entire chainstate?
 662017-08-18T02:30:06  <praxeology> err, what -dbcache are you using?
 672017-08-18T02:30:08  <kallewoof> it has 16 GB of RAM. 223 MB free atm.
 682017-08-18T02:30:31  <kallewoof> Default
 692017-08-18T02:30:39  <kallewoof> (dbcache)
 702017-08-18T02:31:11  <praxeology> are you profiling while synching from genesis, or from the latest tip, or what?
 712017-08-18T02:31:24  <sipa> praxeology: he's talking about inv relay
 722017-08-18T02:31:28  <sipa> not about sync
 732017-08-18T02:31:29  <kallewoof> The node is fully synced up. I restarted it with profiling enabled so it's from tip
 742017-08-18T02:33:48  <bitcoin-git> [bitcoin] jonasnick opened pull request #11083: Fix combinerawtransaction RPC help result section (master...fix-combinerawtransaction-help) https://github.com/bitcoin/bitcoin/pull/11083
 752017-08-18T02:35:44  <praxeology> kallewoof: is your profiler sampling instruction pointer positions, or is it timing each function call?
 762017-08-18T02:37:05  <kallewoof> It's using rdtsc. Not sure which that falls under.
 772017-08-18T02:37:18  <praxeology> the latter can really mess up measurements
 782017-08-18T02:38:54  <praxeology> and potentially the profile is not actually measuring cpu usage... that could be misleading, instead it could just be saying where a thread is sleeping
 792017-08-18T02:40:20  <kallewoof> Right. It definitely keeps ticking even while waiting for locks. I was more intereted in the # of LOCK() calls/second rather than the actual CPU usage in this case, though.
 802017-08-18T02:41:58  <kallewoof> Since the code is auto-profiling all locks, I can simply reduct the lock times from the parent to get "time spent excluding lock wait times", if that seemed useful.
 812017-08-18T02:43:22  <praxeology> is it measuring the number of lock calls? or the number of times it sampled with the thread being at the Lock() call?
 822017-08-18T02:43:35  <kallewoof> # of calls
 832017-08-18T02:47:03  <praxeology> Does bitcoin's networking code operate on polling or interrupt?
 842017-08-18T02:47:39  <kallewoof> I logged every entry into the tx relay loop and logged the size of vInvTx. I don't have a lot of connections yet (14 or so) but I'm seeing 4-5 per second. Example of vInvTx sizes: 5, 0, 5, 0, 4, 4, 5, 1, 0, 1, 5, 1, 2, 0, 26, 6, 5, 0, 5, 5, 0, 5, 0, 2, 2, 13, 52, 0, 0, 0, 4, 4, 11, 21
 852017-08-18T02:47:58  *** Fibonacci has joined #bitcoin-core-dev
 862017-08-18T02:48:50  <Fibonacci> o/
 872017-08-18T02:49:48  <kallewoof> That doesn't match up with 1500/second at all, but maybe with more connections. Or maybe there was a bunch of txs in the last 24 hours.
 882017-08-18T02:53:45  <kallewoof> Actually, for comparison, the path into "trickle (tx-relay)" only has 543732 instances, which would mean there are on average 133867681/543732=246 calls to LOCK(cs) per entry. Huh.
 892017-08-18T02:56:57  <cfields> kallewoof: you can use my lock dumper to profile: https://github.com/theuni/bitcoin/commit/be49a294a240ec81a901af1aaabbba2172d38dc1
 902017-08-18T02:57:03  <cfields> it should cherry-pick cleanly
 912017-08-18T02:57:10  <cfields> lock stats are dumped at shutdown
 922017-08-18T02:57:19  <cfields> i should really clean that up and PR it
 932017-08-18T02:57:23  * cfields throws it on the pile
 942017-08-18T02:57:27  <kallewoof> Nice :)
 952017-08-18T02:58:01  <cfields> should tell you how long it's locked, and what percentage of the thread time it spent in it
 962017-08-18T02:58:27  <kallewoof> I sort of already know that. What is confusing me is the # of times it is locking.
 972017-08-18T02:58:44  <kallewoof> 350 million in <24h is a lot of LOCK()s.
 982017-08-18T02:58:50  <cfields> heh
 992017-08-18T03:11:04  *** Giszmo1 has joined #bitcoin-core-dev
1002017-08-18T03:12:26  *** Giszmo has quit IRC
1012017-08-18T03:27:32  <Fibonacci> Bitcointalk will soon be irrelevant in the cryptoverse. Alternative methods for coin legitimization are popping up that will more carefully scrutinize developers intentions and identities, while at the same time allowing for an influx of new blood not associated with the corrupt financial institutions. Keep your eyes open for this shifting to a new paradigm
1022017-08-18T03:28:16  <luke-jr> !ops spammer
1032017-08-18T03:28:50  <Fibonacci> That wasn't spam Luke-jr
1042017-08-18T03:28:55  <luke-jr> sure looks like it.
1052017-08-18T03:28:56  <Fibonacci> I typed that myself
1062017-08-18T03:29:17  <luke-jr> considering this channel has nothing to do with bitcointalk, altcoins, etc
1072017-08-18T03:29:19  <Fibonacci> well I think it's time
1082017-08-18T03:34:47  *** Deacyde has joined #bitcoin-core-dev
1092017-08-18T03:35:54  <Cryptocide> People can code whatever they want wherever, and if they have great coding skills they will shine, what is the issue we all agree on this
1102017-08-18T03:38:03  *** ghost43 has joined #bitcoin-core-dev
1112017-08-18T03:39:28  *** hsmiths has joined #bitcoin-core-dev
1122017-08-18T03:39:29  *** Chris_St1 has joined #bitcoin-core-dev
1132017-08-18T03:46:51  *** ekerstein has quit IRC
1142017-08-18T03:48:34  <kallewoof> Found part of why there are so many locks. It's locking cs twice for every entry in vInvTx, which is anything from a few up to 100+. With 4-5 per sec that adds up fast. The first lock is for the CompareInvMempoolOrder (std::pop_heap call at start of loop), and the second is for the actual mempool.info(hash) call.
1152017-08-18T03:55:25  <kallewoof> Actually, since the CompareInvMempoolOrder is a sorter, and each sort calls CompareDepthAndScore which locks cs, the number of lock calls are dependent on the size of the vector. That definitely explains things...
1162017-08-18T03:57:57  <kallewoof> I think this could all be solved by making a sub-mempool which takes a list of hashes and simply pulls them out of the mempool once. These operations could then be done on the sub-mempool without locking anything or at least without locking cs.
1172017-08-18T04:02:40  *** fireofearth has joined #bitcoin-core-dev
1182017-08-18T04:05:27  *** Chris_St1 has quit IRC
1192017-08-18T04:09:28  *** jimpo has quit IRC
1202017-08-18T04:19:33  *** treebear_ has joined #bitcoin-core-dev
1212017-08-18T04:20:21  *** treebeardd has quit IRC
1222017-08-18T04:21:04  *** chjj has quit IRC
1232017-08-18T04:35:26  *** tripleslash has quit IRC
1242017-08-18T04:38:45  *** tripleslash has joined #bitcoin-core-dev
1252017-08-18T04:42:57  *** tripleslash has quit IRC
1262017-08-18T04:46:31  *** tripleslash has joined #bitcoin-core-dev
1272017-08-18T04:55:35  *** tripleslash has quit IRC
1282017-08-18T04:58:57  *** tripleslash has joined #bitcoin-core-dev
1292017-08-18T05:02:30  <kallewoof> Woah.. size of vInvTx after running for a bit (grabbed latest bunch in order): 4596, 4, 0, 7, 2, 8, 3836, 4370, 21, 2, 3, 3806, 1, 5, 4340, 16, 16, 0, 4121, 7, 4478, 11, 16, 0, 4095, 4452, 4264, 5, 9, 6, 1, 4061, 11, 11, 4579, 4544, 7, 10, 1, 1, 0, 4318, 18, 54, 3, 3, 1, 1, 0, 0, 4421, 13. 4+k entries would definitely result in a lot of locking.
1302017-08-18T05:03:28  <sipa> kallewoof: wow
1312017-08-18T05:27:40  *** annanay25 has quit IRC
1322017-08-18T05:27:49  *** annanay25 has joined #bitcoin-core-dev
1332017-08-18T05:29:17  *** annanay25 has joined #bitcoin-core-dev
1342017-08-18T05:34:40  *** annanay25 has joined #bitcoin-core-dev
1352017-08-18T05:35:23  *** annanay25 has quit IRC
1362017-08-18T05:58:50  *** ekerstein has joined #bitcoin-core-dev
1372017-08-18T06:00:19  *** Deacydal has joined #bitcoin-core-dev
1382017-08-18T06:03:10  *** Deacyde has quit IRC
1392017-08-18T06:05:27  *** jannes has quit IRC
1402017-08-18T06:11:11  *** aj_ has joined #bitcoin-core-dev
1412017-08-18T06:11:24  *** aj_ is now known as aj
1422017-08-18T06:32:44  *** jannes has joined #bitcoin-core-dev
1432017-08-18T06:37:37  *** elkalamar has quit IRC
1442017-08-18T06:46:40  *** chjj has joined #bitcoin-core-dev
1452017-08-18T06:50:16  *** jtimon has joined #bitcoin-core-dev
1462017-08-18T06:50:43  *** BashCo has quit IRC
1472017-08-18T06:51:20  *** BashCo has joined #bitcoin-core-dev
1482017-08-18T06:55:35  *** BashCo has quit IRC
1492017-08-18T06:59:06  *** Dyaheon has joined #bitcoin-core-dev
1502017-08-18T07:01:34  *** promag has joined #bitcoin-core-dev
1512017-08-18T07:01:40  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/22e301a3d56d...4afb5aa9e173
1522017-08-18T07:01:40  <bitcoin-git> bitcoin/master 64fb0ac practicalswift: Declare single-argument (non-converting) constructors "explicit"...
1532017-08-18T07:01:41  <bitcoin-git> bitcoin/master 4afb5aa Wladimir J. van der Laan: Merge #10969: Declare single-argument (non-converting) constructors "explicit"...
1542017-08-18T07:02:20  <bitcoin-git> [bitcoin] laanwj closed pull request #10969: Declare single-argument (non-converting) constructors "explicit" (master...explicit) https://github.com/bitcoin/bitcoin/pull/10969
1552017-08-18T07:05:04  *** ekerstein has quit IRC
1562017-08-18T07:05:38  *** treebear_ has quit IRC
1572017-08-18T07:07:23  <bitcoin-git> [bitcoin] kallewoof opened pull request #11084: [mempool] Mempool snapshots to avoid lots of locking (master...mempool-snapshot) https://github.com/bitcoin/bitcoin/pull/11084
1582017-08-18T07:08:25  *** fanquake has joined #bitcoin-core-dev
1592017-08-18T07:12:51  <fanquake> wumpus are you merging a few PRs now, or reviewing
1602017-08-18T07:13:39  *** BashCo has joined #bitcoin-core-dev
1612017-08-18T07:16:15  <fanquake> I think 11071, 11066, 11083, 10878 are ready to go. Fairly trivial.
1622017-08-18T07:23:12  *** waveprop has quit IRC
1632017-08-18T07:29:04  <wumpus> fanquake: thanks! will take a look
1642017-08-18T07:40:40  *** waveprop has joined #bitcoin-core-dev
1652017-08-18T07:42:28  <fanquake> Also 11076 now that it's squashed and the commit message is fixed.
1662017-08-18T07:44:48  *** fanquake has quit IRC
1672017-08-18T07:46:50  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4afb5aa9e173...dbf6bd6ea05f
1682017-08-18T07:46:51  <bitcoin-git> bitcoin/master d1e6f91 practicalswift: Prefer compile-time checking over run-time checking
1692017-08-18T07:46:51  <bitcoin-git> bitcoin/master dbf6bd6 Wladimir J. van der Laan: Merge #11071: Use static_assert(…, …) (C++11) instead of assert(…) where appropriate...
1702017-08-18T07:47:07  *** chjj has quit IRC
1712017-08-18T07:47:20  *** Fibonacci has quit IRC
1722017-08-18T07:47:28  <bitcoin-git> [bitcoin] laanwj closed pull request #11071: Use static_assert(…, …) (C++11) instead of assert(…) where appropriate (master...static_assert) https://github.com/bitcoin/bitcoin/pull/11071
1732017-08-18T07:48:01  <gmaxwell> kallewoof: copying the mempool ids worries me, what happens when it has a million tiny transactions in it... that will be pretty slow and blow out all the caches.  Would it have been possible to use a closure like structure to carry the required operations under a single grab of the lock.  (maybe thats worse, haven't benchmarked)
1742017-08-18T07:49:45  <wumpus> sounds like something that definitely needs benchmarks
1752017-08-18T07:50:02  *** chjj has joined #bitcoin-core-dev
1762017-08-18T07:51:01  <kallewoof> Not sure what you mean by ids. Right now the PR I submitted will make a snapshot copying over the txs in the list as CTxMempoolEntry's. That is one single iteration over mapTx in the mempool, comparing each to the given std::set. I think this is faster than iterating mapTx once per hash, but not sure. Yes, proper benchmarks are probably needed...
1772017-08-18T07:52:59  <gmaxwell> kallewoof: it's just that there can be a million-ish entries in mapTx. So I think that in extreme cases your snapshot could be quite slow. Though I certantly believe it's faster with the typically small mempools.
1782017-08-18T07:53:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dbf6bd6ea05f...f3558834db4d
1792017-08-18T07:53:13  <bitcoin-git> bitcoin/master f9ca0fe Jonas Nick: Fix combinerawtransaction RPC help result section
1802017-08-18T07:53:14  <bitcoin-git> bitcoin/master f355883 Wladimir J. van der Laan: Merge #11083: Fix combinerawtransaction RPC help result section...
1812017-08-18T07:53:53  <bitcoin-git> [bitcoin] laanwj closed pull request #11083: Fix combinerawtransaction RPC help result section (master...fix-combinerawtransaction-help) https://github.com/bitcoin/bitcoin/pull/11083
1822017-08-18T07:56:58  <kallewoof> gmaxwell: I realized I am not stopping iteration ever, so I switched the code a bit (1. it will now erase found entries from set, and 2. it will break when set is empty). I will do benchmarks to see how mempool size impacts speed there.
1832017-08-18T07:57:14  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f3558834db4d...c58128f18992
1842017-08-18T07:57:14  <bitcoin-git> bitcoin/master 72a184a Carl Dong: Update init.md: Fix line breaks in section 3b.
1852017-08-18T07:57:15  <bitcoin-git> bitcoin/master d201e40 Carl Dong: Update init.md: Fix section numbering.
1862017-08-18T07:57:15  <bitcoin-git> bitcoin/master c58128f Wladimir J. van der Laan: Merge #10878: Docs: Fix Markdown formatting issues in init.md...
1872017-08-18T07:57:44  <bitcoin-git> [bitcoin] laanwj closed pull request #10878: Docs: Fix Markdown formatting issues in init.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10878
1882017-08-18T07:59:21  <kallewoof> ... I *am* assuming that iterating over mapTx once is better than simply doing mapTx.find() for each hash. I probably shouldn't assume that.
1892017-08-18T08:00:26  <sipa> iterating is O(1) per ste
1902017-08-18T08:00:33  <sipa> find is O(log n)
1912017-08-18T08:01:25  <kallewoof> sipa: Thanks. So with big mempool and small set, my approach is bad. Will fix.
1922017-08-18T08:01:36  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.15: https://github.com/bitcoin/bitcoin/compare/252ca9c5d8d7...1c4b9b31355f
1932017-08-18T08:01:36  <bitcoin-git> bitcoin/0.15 30c246b practicalswift: Updating the release notes (minor stylistic changes)
1942017-08-18T08:01:37  <bitcoin-git> bitcoin/0.15 1c4b9b3 Wladimir J. van der Laan: Merge #11076: 0.15 release-notes nits: fix redundancy, remove accidental parenthesis & fix range style...
1952017-08-18T08:10:23  <kallewoof> gmaxwell: Updated. With k=vInvTx.size(), n=mapTx.size(), pre: O(k log n); post: O(k log n). This is mapTx stuff only. That's the part you were concerned about, right?
1962017-08-18T08:13:07  <gmaxwell> okay, thats more interesting.
1972017-08-18T08:20:26  <gmaxwell> its late, I must be confused... because I don't understand how this doesn't violate the locking on the multiindex. But I never did understand all the multiindex details all that well.
1982017-08-18T08:21:16  <kallewoof> The snapshot is created under lock. Then it's used single-thread-like. How would that violate multiindex locking?
1992017-08-18T08:23:41  <gmaxwell> Though.. couple extra points: when it's going to access all the vInvTx it would probably be a lot faster to pull all the things that get compared out at once instead of building a CTxMemPool::indexed_transaction_set.
2002017-08-18T08:24:01  <gmaxwell> kallewoof: because there are references being copied, who owns the underlying data?
2012017-08-18T08:24:43  <gmaxwell> e.g. what happens when a mempool entry is deleted while you've dropped the lock but are accessing the snapshot.
2022017-08-18T08:25:31  <kallewoof> I am pretty sure the CTxMemPoolEntry is copied, not referenced.
2032017-08-18T08:26:28  <gmaxwell> the mempool entry contains references.
2042017-08-18T08:26:36  <kallewoof> if deleted, the inv may contain the hash of a deleted tx but that would have been the case if you had arrived a fraction of a second earlier, too, so doesn't seem unacceptable
2052017-08-18T08:26:39  <gmaxwell> (and it better, you sure as heck don't want to copy all the txn! :) )
2062017-08-18T08:27:22  *** vicenteH has joined #bitcoin-core-dev
2072017-08-18T08:27:29  <kallewoof> Oh, yes. But these are accessed without locking already.
2082017-08-18T08:27:41  <kallewoof> Or at the least, they are made available after lock is released.
2092017-08-18T08:27:53  <sipa> what is accessed?
2102017-08-18T08:27:59  <kallewoof> tx, for example.
2112017-08-18T08:28:04  <sipa> the mempool contains shared pointers to constant transactions
2122017-08-18T08:28:16  <sipa> you can copy the shared pointers under lock
2132017-08-18T08:28:22  <sipa> and then lose the lock
2142017-08-18T08:28:34  <sipa> and then deref the shared pointers to txn
2152017-08-18T08:28:37  <sipa> but nothing else
2162017-08-18T08:28:46  <kallewoof> Yes. And if I have a separate structure with pointers to those txs, I can do whatever I want with it, right?
2172017-08-18T08:28:52  <sipa> yes
2182017-08-18T08:28:57  <sipa> txn are immutable
2192017-08-18T08:28:57  <kallewoof> Then I think I'm good.
2202017-08-18T08:38:15  *** Cory has quit IRC
2212017-08-18T08:40:22  <kallewoof> gmaxwell: forgot to reply regarding the vInvTx optimization you mentioned; I'm not entirely sure what you mean. Do you mean I should pull out the TxMempoolInfo objects directly instead of doing the snapshot middle step?
2222017-08-18T08:41:26  <kallewoof> I kind of intended for the snapshot class to be useful in other places but if this is the only one that might be better.
2232017-08-18T08:41:33  <gmaxwell> The only things that get accessed in the objects IIRC are their depth (and if they're in there or not), which means that you can just fetch all the data that the sort will later access in advance, instead of copying the whole CTxMemPoolEntry object.
2242017-08-18T08:42:00  <gmaxwell> Which will probably be very time and memory inefficient (e.g. copying shared pointers)
2252017-08-18T08:42:08  <kallewoof> Ahh.. that makes sense.
2262017-08-18T08:43:36  <gmaxwell> (also their feerate, perhaps. vague recolletion here, in any case, it's just a couple narrow things. We do something like that for the node sorts for eviction)
2272017-08-18T08:44:46  * kallewoof nods
2282017-08-18T08:49:46  <bitcoin-git> [bitcoin] dooglus opened pull request #11085: Add 'sethdseed' RPC to initialize or replace HD seed. (master...set_hd_seed) https://github.com/bitcoin/bitcoin/pull/11085
2292017-08-18T08:50:58  *** jtimon has quit IRC
2302017-08-18T08:51:44  *** Noone has joined #bitcoin-core-dev
2312017-08-18T08:54:06  *** vicenteH has quit IRC
2322017-08-18T08:54:23  *** vicenteH has joined #bitcoin-core-dev
2332017-08-18T08:56:20  *** Noone has quit IRC
2342017-08-18T08:57:47  *** promag has quit IRC
2352017-08-18T08:59:56  *** riemann has joined #bitcoin-core-dev
2362017-08-18T09:01:17  *** AaronvanW has joined #bitcoin-core-dev
2372017-08-18T09:20:46  *** str4d has joined #bitcoin-core-dev
2382017-08-18T09:25:31  *** Cory has joined #bitcoin-core-dev
2392017-08-18T09:28:49  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c58128f18992...9f60b3707d1e
2402017-08-18T09:28:50  <bitcoin-git> bitcoin/master 07685d1 Jonas Schnelli: Add length check for CExtKey deserialization
2412017-08-18T09:28:50  <bitcoin-git> bitcoin/master 9f60b37 Wladimir J. van der Laan: Merge #11081: Add length check for CExtKey deserialization (jonasschnelli, guidovranken)...
2422017-08-18T09:29:34  <bitcoin-git> [bitcoin] laanwj closed pull request #11081: Add length check for CExtKey deserialization (jonasschnelli, guidovranken) (master...2017/08/fix_cextkey) https://github.com/bitcoin/bitcoin/pull/11081
2432017-08-18T09:31:23  *** Guyver2 has joined #bitcoin-core-dev
2442017-08-18T09:38:40  *** JackH has joined #bitcoin-core-dev
2452017-08-18T09:44:26  *** belcher has quit IRC
2462017-08-18T09:47:39  *** fireofearth has left #bitcoin-core-dev
2472017-08-18T09:51:26  *** riemann has quit IRC
2482017-08-18T10:03:54  *** Deacyded has joined #bitcoin-core-dev
2492017-08-18T10:04:39  *** stevenroose has quit IRC
2502017-08-18T10:06:33  *** riemann has joined #bitcoin-core-dev
2512017-08-18T10:07:13  *** stevenroose has joined #bitcoin-core-dev
2522017-08-18T10:07:19  *** Deacydal has quit IRC
2532017-08-18T10:20:45  *** str4d_ has joined #bitcoin-core-dev
2542017-08-18T10:23:26  *** str4d has quit IRC
2552017-08-18T10:30:17  *** Deacydal has joined #bitcoin-core-dev
2562017-08-18T10:32:57  *** dabura667 has quit IRC
2572017-08-18T10:33:49  *** Deacyded has quit IRC
2582017-08-18T11:00:21  *** Deacyded has joined #bitcoin-core-dev
2592017-08-18T11:03:32  *** Deacydal has quit IRC
2602017-08-18T11:35:58  *** promag has joined #bitcoin-core-dev
2612017-08-18T11:41:31  *** rabidus is now known as niinanemustakyrp
2622017-08-18T11:42:18  *** niinanemustakyrp is now known as Jonuz
2632017-08-18T11:43:43  *** Jonuz is now known as rabidus
2642017-08-18T11:45:28  *** riemann has quit IRC
2652017-08-18T11:51:28  *** riemann has joined #bitcoin-core-dev
2662017-08-18T12:04:10  *** jtimon has joined #bitcoin-core-dev
2672017-08-18T12:14:17  *** promag has quit IRC
2682017-08-18T12:14:36  *** SopaXorzTaker has joined #bitcoin-core-dev
2692017-08-18T12:19:13  *** promag has joined #bitcoin-core-dev
2702017-08-18T12:33:15  *** goatpig has joined #bitcoin-core-dev
2712017-08-18T13:00:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2722017-08-18T13:09:43  *** promag has quit IRC
2732017-08-18T13:16:34  *** promag has joined #bitcoin-core-dev
2742017-08-18T13:19:02  *** belcher has joined #bitcoin-core-dev
2752017-08-18T13:22:00  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9f60b3707d1e...aeec8b4b6882
2762017-08-18T13:22:00  <bitcoin-git> bitcoin/master 5be6e9b Wladimir J. van der Laan: doc: Update build-openbsd for 6.1...
2772017-08-18T13:22:01  <bitcoin-git> bitcoin/master aeec8b4 Wladimir J. van der Laan: Merge #11080: doc: Update build-openbsd for 6.1...
2782017-08-18T13:22:40  <bitcoin-git> [bitcoin] laanwj closed pull request #11080: doc: Update build-openbsd for 6.1 (master...2017_08_openbsd_bump) https://github.com/bitcoin/bitcoin/pull/11080
2792017-08-18T13:24:14  <bitcoin-git> [bitcoin] BitonicEelis opened pull request #11087: Diagnose unsuitable outputs in lockunspent(). (master...lockunspent) https://github.com/bitcoin/bitcoin/pull/11087
2802017-08-18T13:24:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/aeec8b4b6882...9e00a625b43c
2812017-08-18T13:24:35  <bitcoin-git> bitcoin/master bea8e9e practicalswift: Document the preference of nullptr over NULL or (void*)0
2822017-08-18T13:24:36  <bitcoin-git> bitcoin/master 9e00a62 Wladimir J. van der Laan: Merge #11066: Document the preference of nullptr over NULL or (void*)0...
2832017-08-18T13:24:57  *** Chris_Stewart_5 has quit IRC
2842017-08-18T13:25:17  <bitcoin-git> [bitcoin] laanwj closed pull request #11066: Document the preference of nullptr over NULL or (void*)0 (master...document-nullptr-preference) https://github.com/bitcoin/bitcoin/pull/11066
2852017-08-18T13:45:55  *** jtimon has quit IRC
2862017-08-18T13:50:50  <promag> wumpus what about https://github.com/bitcoin/bitcoin/pull/11039 ?
2872017-08-18T13:55:23  <wumpus> promag: I'll have a look
2882017-08-18T13:56:10  <promag> np,
2892017-08-18T13:56:16  <wumpus> I like replacing .count() and [] with one find
2902017-08-18T13:56:30  <wumpus> incidentally, [] generates quite a lot of code
2912017-08-18T13:57:13  <wumpus> (when used with maps)
2922017-08-18T13:57:30  <promag> there is a PR to replace that with .at()
2932017-08-18T13:57:59  <promag> the idea there is just to avoid the 2nd lookup
2942017-08-18T13:58:30  <wumpus> yes
2952017-08-18T14:01:55  <wumpus> but the stanza of using count then [] (sometimes even multiple times) instead of using an iterator always annoyed me (but apparently not enough to patch it myself), happy to see it go
2962017-08-18T14:04:17  *** str4d_ has quit IRC
2972017-08-18T14:06:57  <luke-jr> might be nice to do a explicittype& varname = it->second; though - but this is definitely an improvement
2982017-08-18T14:07:25  <luke-jr> (it's hard to tell what it->second actually is here)
2992017-08-18T14:09:58  <wumpus> luke-jr:  looks like that's what he does
3002017-08-18T14:10:06  <wumpus> luke-jr: only the iterator is assigned to an auto
3012017-08-18T14:10:15  <luke-jr> I'm not talking about the iterator ;p
3022017-08-18T14:10:19  <promag> yes, I almost did that, but I think the best is to switch those finds with GetWalletTx which is almost never used
3032017-08-18T14:11:01  <wumpus> luke-jr: I know, but he does "CWalletTx& wtx = it->second;" in many places
3042017-08-18T14:11:12  <wumpus> which matches "explicittype& varname = it->second; " right?
3052017-08-18T14:11:17  <luke-jr> yes, it should be in the other places too
3062017-08-18T14:11:22  <wumpus> meh
3072017-08-18T14:11:46  <promag> those "explicittype& varname = it->second; "  were already there
3082017-08-18T14:11:55  *** goatpig has quit IRC
3092017-08-18T14:11:59  <wumpus> yes. it's fine.
3102017-08-18T14:12:33  <promag> luke-jr: I didn't add new vars
3112017-08-18T14:12:43  <luke-jr> promag: I'm saying you should in this case
3122017-08-18T14:12:56  <luke-jr> directly using it->second is poor for readability
3132017-08-18T14:13:38  <promag> that will cause a bigger diff, out of scope IMO
3142017-08-18T14:13:40  <wumpus> please don't change it now, I've just reviewed it
3152017-08-18T14:13:42  <wumpus> yeah
3162017-08-18T14:14:50  <wumpus> the scope is "avoid second wallet lookup", which he did,  The old code was "mapWallet[txin.prevout.hash].MarkDirty();" whichalso  had no explicit type.
3172017-08-18T14:15:05  <luke-jr> sure
3182017-08-18T14:15:44  <promag> luke-jr: I almost did that, just thought those can be improved in a later PR
3192017-08-18T14:15:48  <promag> cool
3202017-08-18T14:17:42  *** str4d_ has joined #bitcoin-core-dev
3212017-08-18T14:17:51  <luke-jr> even with the nit, it's a utACK, not a NACK ;)
3222017-08-18T14:17:58  <luke-jr> still a clear improvement
3232017-08-18T14:19:51  <promag> ty
3242017-08-18T14:27:01  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e00a625b43c...fc51565cbd4c
3252017-08-18T14:27:01  <bitcoin-git> bitcoin/master 8f2f1e0 João Barbosa: wallet: Avoid second mapWallet lookup
3262017-08-18T14:27:02  <bitcoin-git> bitcoin/master fc51565 Wladimir J. van der Laan: Merge #11039: Avoid second mapWallet lookup...
3272017-08-18T14:27:39  <bitcoin-git> [bitcoin] laanwj closed pull request #11039: Avoid second mapWallet lookup (master...2017-08-avoid-second-mapwallet-lookup) https://github.com/bitcoin/bitcoin/pull/11039
3282017-08-18T14:36:14  <promag> This is similar https://github.com/bitcoin/bitcoin/pull/11041/files but does what luke-jr mentioned
3292017-08-18T14:47:29  *** btcdrak has quit IRC
3302017-08-18T14:50:21  *** JackH has quit IRC
3312017-08-18T14:51:40  *** Cheeseo has joined #bitcoin-core-dev
3322017-08-18T14:54:18  <promag> PR "tagged" with WIP should not be reviewed correct?
3332017-08-18T14:58:31  *** riemann has quit IRC
3342017-08-18T15:00:24  *** Evel-Knievel has quit IRC
3352017-08-18T15:03:53  <wumpus> promag: only the general direction, but reviewing whether all i's are dotted is probably a waste of time and effort
3362017-08-18T15:04:16  <promag> right
3372017-08-18T15:07:41  *** Evel-Knievel has joined #bitcoin-core-dev
3382017-08-18T15:13:33  *** Giszmo1 has quit IRC
3392017-08-18T15:14:09  *** Evel-Knievel has quit IRC
3402017-08-18T15:14:59  *** Evel-Knievel has joined #bitcoin-core-dev
3412017-08-18T15:25:23  *** Evel-Knievel has quit IRC
3422017-08-18T15:25:45  *** Evel-Knievel has joined #bitcoin-core-dev
3432017-08-18T15:28:11  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/fc51565cbd4c...0e5b7486cb7f
3442017-08-18T15:28:12  <bitcoin-git> bitcoin/master 1221f60 John Newbery: [wallet] Remove keypool_topup_cleanups...
3452017-08-18T15:28:12  <bitcoin-git> bitcoin/master 67ceff4 John Newbery: [wallet] Add logging to MarkReserveKeysAsUsed
3462017-08-18T15:28:13  <bitcoin-git> bitcoin/master 0e5b748 Wladimir J. van der Laan: Merge #11044: [wallet] Keypool topup cleanups...
3472017-08-18T15:28:50  <bitcoin-git> [bitcoin] laanwj closed pull request #11044: [wallet] Keypool topup cleanups (master...keypool_topup_cleanups) https://github.com/bitcoin/bitcoin/pull/11044
3482017-08-18T15:33:11  *** annanay25 has joined #bitcoin-core-dev
3492017-08-18T15:35:27  *** vicenteH has quit IRC
3502017-08-18T15:37:50  *** JoeLiu has joined #bitcoin-core-dev
3512017-08-18T15:39:41  *** annanay25 has quit IRC
3522017-08-18T15:46:20  *** ekerstein has joined #bitcoin-core-dev
3532017-08-18T15:50:45  *** BashCo has quit IRC
3542017-08-18T16:14:18  *** riemann has joined #bitcoin-core-dev
3552017-08-18T16:26:52  *** Murch has joined #bitcoin-core-dev
3562017-08-18T16:27:07  *** BashCo has joined #bitcoin-core-dev
3572017-08-18T16:33:30  <bitcoin-git> [bitcoin] luke-jr opened pull request #11089: Enable various p2sh-p2wpkh functionality (master...p2shp2wpkhstuff) https://github.com/bitcoin/bitcoin/pull/11089
3582017-08-18T16:33:59  *** abpa has joined #bitcoin-core-dev
3592017-08-18T16:37:27  *** SopaXorzTaker has quit IRC
3602017-08-18T16:38:08  *** BashCo has quit IRC
3612017-08-18T16:39:36  *** SopaXorzTaker has joined #bitcoin-core-dev
3622017-08-18T16:40:57  *** riemann has quit IRC
3632017-08-18T16:42:55  *** BashCo has joined #bitcoin-core-dev
3642017-08-18T16:47:28  *** SopaXorzTaker has quit IRC
3652017-08-18T16:48:55  *** SopaXorzTaker has joined #bitcoin-core-dev
3662017-08-18T16:52:02  *** str4d__ has joined #bitcoin-core-dev
3672017-08-18T16:55:05  *** str4d_ has quit IRC
3682017-08-18T16:56:00  <bitcoin-git> [bitcoin] instagibbs reopened pull request #9017: Enable various p2sh-p2wpkh functionality (master...p2shp2wpkhstuff) https://github.com/bitcoin/bitcoin/pull/9017
3692017-08-18T16:57:41  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0e5b7486cb7f...262167393d05
3702017-08-18T16:57:42  <bitcoin-git> bitcoin/master e53615b Andrew Chow: Remove vchDefaultKey and have better first run detection...
3712017-08-18T16:57:42  <bitcoin-git> bitcoin/master 2621673 Wladimir J. van der Laan: Merge #10952: [wallet] Remove vchDefaultKey and have better first run detection...
3722017-08-18T16:58:14  <bitcoin-git> [bitcoin] laanwj closed pull request #10952: [wallet] Remove vchDefaultKey and have better first run detection (master...remove-defaultkey) https://github.com/bitcoin/bitcoin/pull/10952
3732017-08-18T16:59:32  <luke-jr> instagibbs: see #11089
3742017-08-18T17:06:10  *** riemann has joined #bitcoin-core-dev
3752017-08-18T17:12:59  *** SopaXorzTaker has quit IRC
3762017-08-18T17:13:15  <instagibbs> luke-jr, ah sorry didn't notice that
3772017-08-18T17:13:39  <luke-jr> instagibbs: if you want to take it back, I can close
3782017-08-18T17:13:48  <instagibbs> nah, you rebased for me
3792017-08-18T17:13:51  <instagibbs> thanks :P
3802017-08-18T17:13:51  <luke-jr> although I cut out some of it
3812017-08-18T17:14:29  *** jimpo has joined #bitcoin-core-dev
3822017-08-18T17:15:40  <instagibbs> sure, doesn't have to be done all at once
3832017-08-18T17:17:41  <bitcoin-git> [bitcoin] instagibbs closed pull request #9017: Enable various p2sh-p2wpkh functionality (master...p2shp2wpkhstuff) https://github.com/bitcoin/bitcoin/pull/9017
3842017-08-18T17:27:12  *** ekerstein has quit IRC
3852017-08-18T17:29:21  <luke-jr> instagibbs: well, I disagree with extending sign/verify ;)
3862017-08-18T17:33:20  *** SopaXorzTaker has joined #bitcoin-core-dev
3872017-08-18T17:34:08  <bitcoin-git> [bitcoin] Derek701 opened pull request #11090: Update release-notes.md (0.15...patch-1) https://github.com/bitcoin/bitcoin/pull/11090
3882017-08-18T17:36:27  *** vicenteH has joined #bitcoin-core-dev
3892017-08-18T17:40:02  <instagibbs> luke-jr, no strong opinions :)
3902017-08-18T17:42:15  *** ekerstein has joined #bitcoin-core-dev
3912017-08-18T17:46:51  *** JoeLiu has quit IRC
3922017-08-18T17:47:06  *** belcher has quit IRC
3932017-08-18T17:50:58  *** riemann has quit IRC
3942017-08-18T17:53:27  *** vicenteH has quit IRC
3952017-08-18T17:55:19  *** SopaXorzTaker has quit IRC
3962017-08-18T17:55:29  *** elkalamar has joined #bitcoin-core-dev
3972017-08-18T18:08:19  *** SopaXorzTaker has joined #bitcoin-core-dev
3982017-08-18T18:17:05  *** vicenteH has joined #bitcoin-core-dev
3992017-08-18T18:18:57  *** treebeardd has joined #bitcoin-core-dev
4002017-08-18T18:26:43  *** ekerstein has quit IRC
4012017-08-18T18:32:21  *** SopaXorzTaker has quit IRC
4022017-08-18T18:34:47  *** SopaXorzTaker has joined #bitcoin-core-dev
4032017-08-18T18:39:12  *** praxeology1 has joined #bitcoin-core-dev
4042017-08-18T18:42:20  *** henrik_ has joined #bitcoin-core-dev
4052017-08-18T18:42:41  *** praxeology has quit IRC
4062017-08-18T18:42:47  *** henrik_ has quit IRC
4072017-08-18T18:47:21  *** SopaXorzTaker has quit IRC
4082017-08-18T18:49:47  *** SopaXorzTaker has joined #bitcoin-core-dev
4092017-08-18T18:55:44  *** chjj has quit IRC
4102017-08-18T18:56:30  *** Cheeseo has quit IRC
4112017-08-18T18:57:26  *** SopaXorzTaker has quit IRC
4122017-08-18T18:58:52  *** SopaXorzTaker has joined #bitcoin-core-dev
4132017-08-18T19:03:45  *** tiagotrs has joined #bitcoin-core-dev
4142017-08-18T19:07:21  *** SopaXorzTaker has quit IRC
4152017-08-18T19:08:09  *** Char0n has left #bitcoin-core-dev
4162017-08-18T19:09:47  *** SopaXorzTaker has joined #bitcoin-core-dev
4172017-08-18T19:10:25  *** BashCo has quit IRC
4182017-08-18T19:11:30  *** jimpo has quit IRC
4192017-08-18T19:17:21  *** SopaXorzTaker has quit IRC
4202017-08-18T19:19:47  *** SopaXorzTaker has joined #bitcoin-core-dev
4212017-08-18T19:20:17  *** ekerstein has joined #bitcoin-core-dev
4222017-08-18T19:20:36  *** BashCo has joined #bitcoin-core-dev
4232017-08-18T19:27:06  *** jimpo has joined #bitcoin-core-dev
4242017-08-18T19:28:27  *** chjj has joined #bitcoin-core-dev
4252017-08-18T19:29:20  *** CubicEarth has joined #bitcoin-core-dev
4262017-08-18T19:42:33  <warren> https://bitcoincore.org/en/2016/01/26/segwit-benefits/    "(this effectively results in an effective limit closer to 1.6 to 2 MB)."  <--- This can be improved, asking for fact checks.
4272017-08-18T19:43:32  <warren> 1) I don't think 'effective limit" is accurate in describing what is really a practical size compared to pre-segwit transaction uses, which these estimates were really referring to?
4282017-08-18T19:44:08  <warren> 2) And isn't 1.6MB-2MB the very old estimates, later found in a Bitfury study (?) to be more like 2.1MB?  I wonder what it would be now.
4292017-08-18T19:45:37  *** ekerstein has quit IRC
4302017-08-18T19:48:48  *** BashCo has quit IRC
4312017-08-18T19:51:19  *** BashCo has joined #bitcoin-core-dev
4322017-08-18T19:52:26  *** SopaXorzTaker has quit IRC
4332017-08-18T19:53:55  *** SopaXorzTaker has joined #bitcoin-core-dev
4342017-08-18T19:59:16  <gmaxwell> warren: luke posted an alaysis patch on reddit, it's about 1.9x IIRC.
4352017-08-18T20:04:53  *** AaronvanW has quit IRC
4362017-08-18T20:05:09  *** AaronvanW has joined #bitcoin-core-dev
4372017-08-18T20:07:21  <warren> "effective limit" -> "effective size"?
4382017-08-18T20:09:02  *** griswaalt has joined #bitcoin-core-dev
4392017-08-18T20:12:51  <bitcoin-git> [bitcoin] laanwj opened pull request #11091: test: Increase initial RPC timeout to 60 seconds (master...2017_08_test_wait_for_rpc) https://github.com/bitcoin/bitcoin/pull/11091
4402017-08-18T20:14:09  *** CubicEarth has quit IRC
4412017-08-18T20:17:39  *** belcher has joined #bitcoin-core-dev
4422017-08-18T20:18:30  *** dermoth has quit IRC
4432017-08-18T20:19:14  *** dermoth has joined #bitcoin-core-dev
4442017-08-18T20:20:41  *** BashCo has quit IRC
4452017-08-18T20:21:21  *** justanotheruser has quit IRC
4462017-08-18T20:21:52  *** mkarrer has joined #bitcoin-core-dev
4472017-08-18T20:24:03  *** griswaalt has quit IRC
4482017-08-18T20:33:30  <luke-jr> does per-TXO store the outpoint in both the key and the value? O.o
4492017-08-18T20:35:13  *** BashCo has joined #bitcoin-core-dev
4502017-08-18T20:36:28  <sipa> luke-jr: no, only in the key
4512017-08-18T20:36:30  *** Giszmo has joined #bitcoin-core-dev
4522017-08-18T20:37:32  <sipa> COutPoint in the key, CTxOut in the value
4532017-08-18T20:43:52  *** mkarrer has quit IRC
4542017-08-18T20:44:39  *** griswaalt[m] has joined #bitcoin-core-dev
4552017-08-18T20:47:02  *** Alina-malina has quit IRC
4562017-08-18T20:48:02  *** treebeardd has quit IRC
4572017-08-18T20:49:53  *** Alina-malina has joined #bitcoin-core-dev
4582017-08-18T20:53:41  *** praxeology1 has quit IRC
4592017-08-18T20:54:56  *** chjj has quit IRC
4602017-08-18T20:56:11  *** AaronvanW has quit IRC
4612017-08-18T20:56:48  *** AaronvanW has joined #bitcoin-core-dev
4622017-08-18T21:05:35  *** jimpo has quit IRC
4632017-08-18T21:06:31  *** treebeardd has joined #bitcoin-core-dev
4642017-08-18T21:23:10  <cfields> luke-jr: grr, using git archive won't work either. Ironically, because the substitution from 'git archive' creates a diff.
4652017-08-18T21:24:22  *** waveprop has quit IRC
4662017-08-18T21:24:22  *** waveprop has joined #bitcoin-core-dev
4672017-08-18T21:24:50  *** Guyver2 has quit IRC
4682017-08-18T21:37:23  <luke-jr> >_<
4692017-08-18T21:37:37  <luke-jr> well, we want that anyway I think, so maybe PR it for master at least
4702017-08-18T21:37:45  <luke-jr> or at least don't discard it yet
4712017-08-18T21:37:54  *** lolkeep has joined #bitcoin-core-dev
4722017-08-18T21:38:17  *** jimpo has joined #bitcoin-core-dev
4732017-08-18T21:38:55  <luke-jr> cfields: so that leaves either fixing the tarball to build with the desired string, or making src/obj/build.h manually, right?
4742017-08-18T21:39:19  <cfields> luke-jr: i don't think we can make it manually, it'll just get overwritten
4752017-08-18T21:40:16  *** lolkeep has quit IRC
4762017-08-18T21:40:53  *** chjj has joined #bitcoin-core-dev
4772017-08-18T21:41:07  <BlueMatt> cfields: can you confirm there is nothing stopping switching sync.h primitives to std?
4782017-08-18T21:41:44  <cfields> BlueMatt: sure, let me finish this thing up first though
4792017-08-18T21:41:51  <BlueMatt> no rush
4802017-08-18T21:42:06  <BlueMatt> cfields: just comment on 10866
4812017-08-18T21:42:33  <luke-jr>     echo '#!/bin/true' >share/genbuild.sh
4822017-08-18T21:42:35  <luke-jr>     mkdir -p src/obj
4832017-08-18T21:42:36  <luke-jr>     echo "#define BUILD_SUFFIX gentoo${PVR#${PV}}" >src/obj/build.h
4842017-08-18T21:42:39  <luke-jr> cfields: ^ what I do for Gentoo
4852017-08-18T21:43:55  <cfields> BlueMatt: oh. at the very least, CSemaphore/CScheduler/CCheckqueue non-interruptible
4862017-08-18T21:44:20  <BlueMatt> hmm?
4872017-08-18T21:44:33  <BlueMatt> I dont think CSemaphore needs to be interruptible
4882017-08-18T21:44:40  <BlueMatt> CScheduler and CCheckqueue use boost:: directiyl
4892017-08-18T21:44:42  <BlueMatt> directly
4902017-08-18T21:46:24  <cfields> BlueMatt: ok right, those were preventing the switch to std::thread.
4912017-08-18T21:46:44  <BlueMatt> yes
4922017-08-18T21:46:45  <cfields> luke-jr: heh
4932017-08-18T21:48:20  <cfields> BlueMatt: yea, i guess CSemaphore is ok too. though didn't we decide at one point that the interruptions were saving us?
4942017-08-18T21:50:36  <BlueMatt> on CSemaphore? no?
4952017-08-18T21:50:51  <cfields> nm, was thinking of e007b24
4962017-08-18T21:51:20  <cfields> i guess that commit shows we rely on posting :)
4972017-08-18T21:51:29  <BlueMatt> yes, we rely on posting
4982017-08-18T21:54:03  <cfields> ok neat, i guess the boost::mutex dep slowly dissolved
4992017-08-18T21:55:12  <BlueMatt> =D
5002017-08-18T21:55:20  <cfields> luke-jr: ok, want to just do that for gitian?
5012017-08-18T21:55:31  <BlueMatt> well, no, not neat, really, we have locking primitives that have useful debug things in them, and a bunch of code is blindly using boost:: directly :(
5022017-08-18T21:55:34  <BlueMatt> but oh well
5032017-08-18T21:55:42  <cfields> that's really gross, as it completely defeats the purpose of all of the version stuff
5042017-08-18T21:56:07  <cfields> but i guess it works for 0.15
5052017-08-18T21:56:28  *** str4d__ has quit IRC
5062017-08-18T21:57:00  <luke-jr> cfields: personally, I prefer the "just get it fixed" approach, but if we don't have time for that, okay..
5072017-08-18T21:57:48  <cfields> luke-jr: well the "just get it fixed" approach involves nuking most of our version handling, no?
5082017-08-18T21:58:30  <cfields> i think we'll just take the complexity down to "the tarball injected the version" or "check git" ?
5092017-08-18T22:00:46  <luke-jr> cfields: more like using genbuild on the git to generate the stuff used by the tar
5102017-08-18T22:01:12  <luke-jr> what should it say, btw?
5112017-08-18T22:01:21  <cfields> sure, that works
5122017-08-18T22:01:33  <cfields> hmm?
5132017-08-18T22:01:47  <luke-jr> I've never seen it without the git hash in the version ;)
5142017-08-18T22:01:59  <luke-jr> Bitcoin Core RPC client version v0.15.0
5152017-08-18T22:02:01  <luke-jr> ?
5162017-08-18T22:03:01  *** Deacydal has joined #bitcoin-core-dev
5172017-08-18T22:03:43  *** Alina-malina has quit IRC
5182017-08-18T22:03:43  <cfields> oh, heh
5192017-08-18T22:03:51  *** abpa has quit IRC
5202017-08-18T22:03:53  <cfields> let me check 0.14.2
5212017-08-18T22:04:51  *** Alina-malina has joined #bitcoin-core-dev
5222017-08-18T22:05:53  *** Deacyde has joined #bitcoin-core-dev
5232017-08-18T22:06:55  *** Deacyded has quit IRC
5242017-08-18T22:07:50  *** Deacydal has quit IRC
5252017-08-18T22:09:08  <cfields> splash says "v0.14.2"
5262017-08-18T22:09:12  <luke-jr> cfields: working on another branch atm, can you try http://codepad.org/TexBr9BW ?
5272017-08-18T22:09:30  <cfields> i think the rc's usually have a git commit tacked on though. trying to find one
5282017-08-18T22:10:56  <cfields> heh, good idea
5292017-08-18T22:12:34  <cfields> testing
5302017-08-18T22:15:58  *** tiagotrs has quit IRC
5312017-08-18T22:17:34  <cfields> we should nuke the GIT_DIR export, then
5322017-08-18T22:18:32  *** Deacydal has joined #bitcoin-core-dev
5332017-08-18T22:21:50  *** Deacyde has quit IRC
5342017-08-18T22:22:47  <luke-jr> cfields: yes, probably
5352017-08-18T22:24:53  *** Giszmo has quit IRC
5362017-08-18T22:25:33  *** rgrant has joined #bitcoin-core-dev
5372017-08-18T22:31:30  *** Murch has quit IRC
5382017-08-18T22:33:31  *** Cheeseo has joined #bitcoin-core-dev
5392017-08-18T22:45:29  <cfields> luke-jr: it works as-is
5402017-08-18T22:46:04  <cfields> luke-jr: i have to run out. you're welcome to PR, or I'll do it tonight when I get back
5412017-08-18T22:46:16  <cfields> thanks for the fix :)
5422017-08-18T22:48:14  *** rgrant has left #bitcoin-core-dev
5432017-08-18T22:48:28  <luke-jr> cfields: np, although it's probably  not a good long-term fix..
5442017-08-18T22:53:37  *** justanotheruser has joined #bitcoin-core-dev
5452017-08-18T22:54:00  *** justanotheruser has joined #bitcoin-core-dev
5462017-08-18T23:01:57  *** str4d has joined #bitcoin-core-dev
5472017-08-18T23:09:01  *** Alina-malina has quit IRC
5482017-08-18T23:09:02  *** Cheeseo has quit IRC
5492017-08-18T23:12:29  *** Alina-malina has joined #bitcoin-core-dev
5502017-08-18T23:22:53  *** Alina-malina has quit IRC
5512017-08-18T23:25:28  *** Alina-malina has joined #bitcoin-core-dev
5522017-08-18T23:35:04  <bitcoin-git> [bitcoin] MojaPochi opened pull request #11092: Litecoin ver 0.10.4 for macOS (master...master) https://github.com/bitcoin/bitcoin/pull/11092
5532017-08-18T23:36:00  <bitcoin-git> [bitcoin] fanquake closed pull request #11092: Litecoin ver 0.10.4 for macOS (master...master) https://github.com/bitcoin/bitcoin/pull/11092
5542017-08-18T23:36:04  *** unholymachine has quit IRC
5552017-08-18T23:39:27  *** unholymachine has joined #bitcoin-core-dev