1 2017-08-18T00:00:05  <gmaxwell> thats a lot, time for a reback.
  2 2017-08-18T00:00:10  <gmaxwell> repack.
  3 2017-08-18T00:00:24  <kanzure> also other unmerged branches though
  4 2017-08-18T00:00:36  <kanzure> sipa might even have elements.git branches in there
  5 2017-08-18T00:02:18  <sipa> no
  6 2017-08-18T00:03:09  <kanzure> welp.
  7 2017-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
  8 2017-08-18T00:20:29  *** Chris_St1 has quit IRC
  9 2017-08-18T00:25:25  *** Murch has quit IRC
 10 2017-08-18T00:26:44  *** JackH has joined #bitcoin-core-dev
 11 2017-08-18T00:29:51  <cfields> luke-jr: I believe the dir is dirty because we extract the tarball into it
 12 2017-08-18T00:31:10  <luke-jr> that doesn't make sense..
 13 2017-08-18T00:40:37  *** MeshNet2 has quit IRC
 14 2017-08-18T00:41:33  *** Cryptocide has joined #bitcoin-core-dev
 15 2017-08-18T00:42:32  *** JackH has quit IRC
 16 2017-08-18T00:46:05  *** rockhouse has quit IRC
 17 2017-08-18T00:53:49  *** laurentmt has joined #bitcoin-core-dev
 18 2017-08-18T00:55:44  *** dabura667 has joined #bitcoin-core-dev
 19 2017-08-18T00:56:30  <praxeology> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
 20 2017-08-18T00:56:53  <praxeology> sorry my 2yo grabbed my mouse
 21 2017-08-18T00:57:21  *** str4d has quit IRC
 22 2017-08-18T00:57:55  *** AaronvanW has quit IRC
 23 2017-08-18T01:08:43  <cfields> luke-jr: I see what you mean
 24 2017-08-18T01:08:51  <promag> praxeology: I feel you too
 25 2017-08-18T01:11:47  *** jtimon has quit IRC
 26 2017-08-18T01:16:09  <Cryptocide> Abra|BitClub Network|Bitcoin.com|BitFury|BitGo|Bitmain|BitPay Blockchain|Bloq|BTCC|Circle|Ledger|RSK Labs|Xapo, no thanks
 27 2017-08-18T01:17:42  <kanzure> why XORing them? i don't get it.
 28 2017-08-18T01:17:50  <kanzure> er, ORing
 29 2017-08-18T01:18:32  <kanzure> yes. anyway.
 30 2017-08-18T01:18:46  *** promag has quit IRC
 31 2017-08-18T01:20:57  *** cheese_ has joined #bitcoin-core-dev
 32 2017-08-18T01:22:57  *** Mattie161 has quit IRC
 33 2017-08-18T01:23:29  *** Mattie161 has joined #bitcoin-core-dev
 34 2017-08-18T01:23:39  *** niska has quit IRC
 35 2017-08-18T01:24:10  *** Cheeseo has quit IRC
 36 2017-08-18T01:24:50  *** niska has joined #bitcoin-core-dev
 37 2017-08-18T01:30:04  *** laurentmt has quit IRC
 38 2017-08-18T01:30:11  *** RoyceX has joined #bitcoin-core-dev
 39 2017-08-18T01:33:30  *** cheese_ has quit IRC
 40 2017-08-18T01:33:40  *** Cheeseo has joined #bitcoin-core-dev
 41 2017-08-18T01:35:50  *** RoyceX has quit IRC
 42 2017-08-18T01:35:52  *** cheese_ has joined #bitcoin-core-dev
 43 2017-08-18T01:39:21  *** Cheeseo has quit IRC
 44 2017-08-18T01:40:22  *** hsmiths has quit IRC
 45 2017-08-18T01:42:19  *** mariorz has quit IRC
 46 2017-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:
 47 2017-08-18T01:42:43  <kallewoof>  0.77877            27892        282511326         24083459                0 131703419 SendMessages.inventory.trickle (tx-relay).LOCK(cs)
 48 2017-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"
 49 2017-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?
 50 2017-08-18T01:44:18  *** mariorz has joined #bitcoin-core-dev
 51 2017-08-18T01:45:06  <kallewoof> Also baffled by the number of calls. 131 million. I started profiling yesterday.
 52 2017-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.
 53 2017-08-18T01:51:54  <kallewoof> ... Actually, it rose by 38k from 01:48:49 to 01:50:00, so doesn't seem improbable.
 54 2017-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).
 55 2017-08-18T02:23:12  <gmaxwell> Sounds like it might be interesting.
 56 2017-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
 57 2017-08-18T02:23:48  <gmaxwell> Everyone okay with me doing a presentation on 0.15 improvements to a local group in 1.5 weeks?
 58 2017-08-18T02:25:22  *** cheese_ has quit IRC
 59 2017-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)?
 60 2017-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
 61 2017-08-18T02:28:05  <sipa> copying the whole mempool?
 62 2017-08-18T02:28:14  <kallewoof> Only the hashes.
 63 2017-08-18T02:28:20  <sipa> oh
 64 2017-08-18T02:29:09  <kallewoof> Actually that wouldn't work. It uses txinfo for feeRate and tx etc.
 65 2017-08-18T02:29:33  <praxeology> kallewoof: does your bitcoin process have enough memory to hold the entire chainstate?
 66 2017-08-18T02:30:06  <praxeology> err, what -dbcache are you using?
 67 2017-08-18T02:30:08  <kallewoof> it has 16 GB of RAM. 223 MB free atm.
 68 2017-08-18T02:30:31  <kallewoof> Default
 69 2017-08-18T02:30:39  <kallewoof> (dbcache)
 70 2017-08-18T02:31:11  <praxeology> are you profiling while synching from genesis, or from the latest tip, or what?
 71 2017-08-18T02:31:24  <sipa> praxeology: he's talking about inv relay
 72 2017-08-18T02:31:28  <sipa> not about sync
 73 2017-08-18T02:31:29  <kallewoof> The node is fully synced up. I restarted it with profiling enabled so it's from tip
 74 2017-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
 75 2017-08-18T02:35:44  <praxeology> kallewoof: is your profiler sampling instruction pointer positions, or is it timing each function call?
 76 2017-08-18T02:37:05  <kallewoof> It's using rdtsc. Not sure which that falls under.
 77 2017-08-18T02:37:18  <praxeology> the latter can really mess up measurements
 78 2017-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
 79 2017-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.
 80 2017-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.
 81 2017-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?
 82 2017-08-18T02:43:35  <kallewoof> # of calls
 83 2017-08-18T02:47:03  <praxeology> Does bitcoin's networking code operate on polling or interrupt?
 84 2017-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
 85 2017-08-18T02:47:58  *** Fibonacci has joined #bitcoin-core-dev
 86 2017-08-18T02:48:50  <Fibonacci> o/
 87 2017-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.
 88 2017-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.
 89 2017-08-18T02:56:57  <cfields> kallewoof: you can use my lock dumper to profile: https://github.com/theuni/bitcoin/commit/be49a294a240ec81a901af1aaabbba2172d38dc1
 90 2017-08-18T02:57:03  <cfields> it should cherry-pick cleanly
 91 2017-08-18T02:57:10  <cfields> lock stats are dumped at shutdown
 92 2017-08-18T02:57:19  <cfields> i should really clean that up and PR it
 93 2017-08-18T02:57:23  * cfields throws it on the pile
 94 2017-08-18T02:57:27  <kallewoof> Nice :)
 95 2017-08-18T02:58:01  <cfields> should tell you how long it's locked, and what percentage of the thread time it spent in it
 96 2017-08-18T02:58:27  <kallewoof> I sort of already know that. What is confusing me is the # of times it is locking.
 97 2017-08-18T02:58:44  <kallewoof> 350 million in <24h is a lot of LOCK()s.
 98 2017-08-18T02:58:50  <cfields> heh
 99 2017-08-18T03:11:04  *** Giszmo1 has joined #bitcoin-core-dev
100 2017-08-18T03:12:26  *** Giszmo has quit IRC
101 2017-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
102 2017-08-18T03:28:16  <luke-jr> !ops spammer
103 2017-08-18T03:28:50  <Fibonacci> That wasn't spam Luke-jr
104 2017-08-18T03:28:55  <luke-jr> sure looks like it.
105 2017-08-18T03:28:56  <Fibonacci> I typed that myself
106 2017-08-18T03:29:17  <luke-jr> considering this channel has nothing to do with bitcointalk, altcoins, etc
107 2017-08-18T03:29:19  <Fibonacci> well I think it's time
108 2017-08-18T03:34:47  *** Deacyde has joined #bitcoin-core-dev
109 2017-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
110 2017-08-18T03:38:03  *** ghost43 has joined #bitcoin-core-dev
111 2017-08-18T03:39:28  *** hsmiths has joined #bitcoin-core-dev
112 2017-08-18T03:39:29  *** Chris_St1 has joined #bitcoin-core-dev
113 2017-08-18T03:46:51  *** ekerstein has quit IRC
114 2017-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.
115 2017-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...
116 2017-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.
117 2017-08-18T04:02:40  *** fireofearth has joined #bitcoin-core-dev
118 2017-08-18T04:05:27  *** Chris_St1 has quit IRC
119 2017-08-18T04:09:28  *** jimpo has quit IRC
120 2017-08-18T04:19:33  *** treebear_ has joined #bitcoin-core-dev
121 2017-08-18T04:20:21  *** treebeardd has quit IRC
122 2017-08-18T04:21:04  *** chjj has quit IRC
123 2017-08-18T04:35:26  *** tripleslash has quit IRC
124 2017-08-18T04:38:45  *** tripleslash has joined #bitcoin-core-dev
125 2017-08-18T04:42:57  *** tripleslash has quit IRC
126 2017-08-18T04:46:31  *** tripleslash has joined #bitcoin-core-dev
127 2017-08-18T04:55:35  *** tripleslash has quit IRC
128 2017-08-18T04:58:57  *** tripleslash has joined #bitcoin-core-dev
129 2017-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.
130 2017-08-18T05:03:28  <sipa> kallewoof: wow
131 2017-08-18T05:27:40  *** annanay25 has quit IRC
132 2017-08-18T05:27:49  *** annanay25 has joined #bitcoin-core-dev
133 2017-08-18T05:29:17  *** annanay25 has joined #bitcoin-core-dev
134 2017-08-18T05:34:40  *** annanay25 has joined #bitcoin-core-dev
135 2017-08-18T05:35:23  *** annanay25 has quit IRC
136 2017-08-18T05:58:50  *** ekerstein has joined #bitcoin-core-dev
137 2017-08-18T06:00:19  *** Deacydal has joined #bitcoin-core-dev
138 2017-08-18T06:03:10  *** Deacyde has quit IRC
139 2017-08-18T06:05:27  *** jannes has quit IRC
140 2017-08-18T06:11:11  *** aj_ has joined #bitcoin-core-dev
141 2017-08-18T06:11:24  *** aj_ is now known as aj
142 2017-08-18T06:32:44  *** jannes has joined #bitcoin-core-dev
143 2017-08-18T06:37:37  *** elkalamar has quit IRC
144 2017-08-18T06:46:40  *** chjj has joined #bitcoin-core-dev
145 2017-08-18T06:50:16  *** jtimon has joined #bitcoin-core-dev
146 2017-08-18T06:50:43  *** BashCo has quit IRC
147 2017-08-18T06:51:20  *** BashCo has joined #bitcoin-core-dev
148 2017-08-18T06:55:35  *** BashCo has quit IRC
149 2017-08-18T06:59:06  *** Dyaheon has joined #bitcoin-core-dev
150 2017-08-18T07:01:34  *** promag has joined #bitcoin-core-dev
151 2017-08-18T07:01:40  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/22e301a3d56d...4afb5aa9e173
152 2017-08-18T07:01:40  <bitcoin-git> bitcoin/master 64fb0ac practicalswift: Declare single-argument (non-converting) constructors "explicit"...
153 2017-08-18T07:01:41  <bitcoin-git> bitcoin/master 4afb5aa Wladimir J. van der Laan: Merge #10969: Declare single-argument (non-converting) constructors "explicit"...
154 2017-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
155 2017-08-18T07:05:04  *** ekerstein has quit IRC
156 2017-08-18T07:05:38  *** treebear_ has quit IRC
157 2017-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
158 2017-08-18T07:08:25  *** fanquake has joined #bitcoin-core-dev
159 2017-08-18T07:12:51  <fanquake> wumpus are you merging a few PRs now, or reviewing
160 2017-08-18T07:13:39  *** BashCo has joined #bitcoin-core-dev
161 2017-08-18T07:16:15  <fanquake> I think 11071, 11066, 11083, 10878 are ready to go. Fairly trivial.
162 2017-08-18T07:23:12  *** waveprop has quit IRC
163 2017-08-18T07:29:04  <wumpus> fanquake: thanks! will take a look
164 2017-08-18T07:40:40  *** waveprop has joined #bitcoin-core-dev
165 2017-08-18T07:42:28  <fanquake> Also 11076 now that it's squashed and the commit message is fixed.
166 2017-08-18T07:44:48  *** fanquake has quit IRC
167 2017-08-18T07:46:50  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4afb5aa9e173...dbf6bd6ea05f
168 2017-08-18T07:46:51  <bitcoin-git> bitcoin/master d1e6f91 practicalswift: Prefer compile-time checking over run-time checking
169 2017-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...
170 2017-08-18T07:47:07  *** chjj has quit IRC
171 2017-08-18T07:47:20  *** Fibonacci has quit IRC
172 2017-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
173 2017-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)
174 2017-08-18T07:49:45  <wumpus> sounds like something that definitely needs benchmarks
175 2017-08-18T07:50:02  *** chjj has joined #bitcoin-core-dev
176 2017-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...
177 2017-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.
178 2017-08-18T07:53:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dbf6bd6ea05f...f3558834db4d
179 2017-08-18T07:53:13  <bitcoin-git> bitcoin/master f9ca0fe Jonas Nick: Fix combinerawtransaction RPC help result section
180 2017-08-18T07:53:14  <bitcoin-git> bitcoin/master f355883 Wladimir J. van der Laan: Merge #11083: Fix combinerawtransaction RPC help result section...
181 2017-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
182 2017-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.
183 2017-08-18T07:57:14  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f3558834db4d...c58128f18992
184 2017-08-18T07:57:14  <bitcoin-git> bitcoin/master 72a184a Carl Dong: Update init.md: Fix line breaks in section 3b.
185 2017-08-18T07:57:15  <bitcoin-git> bitcoin/master d201e40 Carl Dong: Update init.md: Fix section numbering.
186 2017-08-18T07:57:15  <bitcoin-git> bitcoin/master c58128f Wladimir J. van der Laan: Merge #10878: Docs: Fix Markdown formatting issues in init.md...
187 2017-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
188 2017-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.
189 2017-08-18T08:00:26  <sipa> iterating is O(1) per ste
190 2017-08-18T08:00:33  <sipa> find is O(log n)
191 2017-08-18T08:01:25  <kallewoof> sipa: Thanks. So with big mempool and small set, my approach is bad. Will fix.
192 2017-08-18T08:01:36  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.15: https://github.com/bitcoin/bitcoin/compare/252ca9c5d8d7...1c4b9b31355f
193 2017-08-18T08:01:36  <bitcoin-git> bitcoin/0.15 30c246b practicalswift: Updating the release notes (minor stylistic changes)
194 2017-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...
195 2017-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?
196 2017-08-18T08:13:07  <gmaxwell> okay, thats more interesting.
197 2017-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.
198 2017-08-18T08:21:16  <kallewoof> The snapshot is created under lock. Then it's used single-thread-like. How would that violate multiindex locking?
199 2017-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.
200 2017-08-18T08:24:01  <gmaxwell> kallewoof: because there are references being copied, who owns the underlying data?
201 2017-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.
202 2017-08-18T08:25:31  <kallewoof> I am pretty sure the CTxMemPoolEntry is copied, not referenced.
203 2017-08-18T08:26:28  <gmaxwell> the mempool entry contains references.
204 2017-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
205 2017-08-18T08:26:39  <gmaxwell> (and it better, you sure as heck don't want to copy all the txn! :) )
206 2017-08-18T08:27:22  *** vicenteH has joined #bitcoin-core-dev
207 2017-08-18T08:27:29  <kallewoof> Oh, yes. But these are accessed without locking already.
208 2017-08-18T08:27:41  <kallewoof> Or at the least, they are made available after lock is released.
209 2017-08-18T08:27:53  <sipa> what is accessed?
210 2017-08-18T08:27:59  <kallewoof> tx, for example.
211 2017-08-18T08:28:04  <sipa> the mempool contains shared pointers to constant transactions
212 2017-08-18T08:28:16  <sipa> you can copy the shared pointers under lock
213 2017-08-18T08:28:22  <sipa> and then lose the lock
214 2017-08-18T08:28:34  <sipa> and then deref the shared pointers to txn
215 2017-08-18T08:28:37  <sipa> but nothing else
216 2017-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?
217 2017-08-18T08:28:52  <sipa> yes
218 2017-08-18T08:28:57  <sipa> txn are immutable
219 2017-08-18T08:28:57  <kallewoof> Then I think I'm good.
220 2017-08-18T08:38:15  *** Cory has quit IRC
221 2017-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?
222 2017-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.
223 2017-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.
224 2017-08-18T08:42:00  <gmaxwell> Which will probably be very time and memory inefficient (e.g. copying shared pointers)
225 2017-08-18T08:42:08  <kallewoof> Ahh.. that makes sense.
226 2017-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)
227 2017-08-18T08:44:46  * kallewoof nods
228 2017-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
229 2017-08-18T08:50:58  *** jtimon has quit IRC
230 2017-08-18T08:51:44  *** Noone has joined #bitcoin-core-dev
231 2017-08-18T08:54:06  *** vicenteH has quit IRC
232 2017-08-18T08:54:23  *** vicenteH has joined #bitcoin-core-dev
233 2017-08-18T08:56:20  *** Noone has quit IRC
234 2017-08-18T08:57:47  *** promag has quit IRC
235 2017-08-18T08:59:56  *** riemann has joined #bitcoin-core-dev
236 2017-08-18T09:01:17  *** AaronvanW has joined #bitcoin-core-dev
237 2017-08-18T09:20:46  *** str4d has joined #bitcoin-core-dev
238 2017-08-18T09:25:31  *** Cory has joined #bitcoin-core-dev
239 2017-08-18T09:28:49  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c58128f18992...9f60b3707d1e
240 2017-08-18T09:28:50  <bitcoin-git> bitcoin/master 07685d1 Jonas Schnelli: Add length check for CExtKey deserialization
241 2017-08-18T09:28:50  <bitcoin-git> bitcoin/master 9f60b37 Wladimir J. van der Laan: Merge #11081: Add length check for CExtKey deserialization (jonasschnelli, guidovranken)...
242 2017-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
243 2017-08-18T09:31:23  *** Guyver2 has joined #bitcoin-core-dev
244 2017-08-18T09:38:40  *** JackH has joined #bitcoin-core-dev
245 2017-08-18T09:44:26  *** belcher has quit IRC
246 2017-08-18T09:47:39  *** fireofearth has left #bitcoin-core-dev
247 2017-08-18T09:51:26  *** riemann has quit IRC
248 2017-08-18T10:03:54  *** Deacyded has joined #bitcoin-core-dev
249 2017-08-18T10:04:39  *** stevenroose has quit IRC
250 2017-08-18T10:06:33  *** riemann has joined #bitcoin-core-dev
251 2017-08-18T10:07:13  *** stevenroose has joined #bitcoin-core-dev
252 2017-08-18T10:07:19  *** Deacydal has quit IRC
253 2017-08-18T10:20:45  *** str4d_ has joined #bitcoin-core-dev
254 2017-08-18T10:23:26  *** str4d has quit IRC
255 2017-08-18T10:30:17  *** Deacydal has joined #bitcoin-core-dev
256 2017-08-18T10:32:57  *** dabura667 has quit IRC
257 2017-08-18T10:33:49  *** Deacyded has quit IRC
258 2017-08-18T11:00:21  *** Deacyded has joined #bitcoin-core-dev
259 2017-08-18T11:03:32  *** Deacydal has quit IRC
260 2017-08-18T11:35:58  *** promag has joined #bitcoin-core-dev
261 2017-08-18T11:41:31  *** rabidus is now known as niinanemustakyrp
262 2017-08-18T11:42:18  *** niinanemustakyrp is now known as Jonuz
263 2017-08-18T11:43:43  *** Jonuz is now known as rabidus
264 2017-08-18T11:45:28  *** riemann has quit IRC
265 2017-08-18T11:51:28  *** riemann has joined #bitcoin-core-dev
266 2017-08-18T12:04:10  *** jtimon has joined #bitcoin-core-dev
267 2017-08-18T12:14:17  *** promag has quit IRC
268 2017-08-18T12:14:36  *** SopaXorzTaker has joined #bitcoin-core-dev
269 2017-08-18T12:19:13  *** promag has joined #bitcoin-core-dev
270 2017-08-18T12:33:15  *** goatpig has joined #bitcoin-core-dev
271 2017-08-18T13:00:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
272 2017-08-18T13:09:43  *** promag has quit IRC
273 2017-08-18T13:16:34  *** promag has joined #bitcoin-core-dev
274 2017-08-18T13:19:02  *** belcher has joined #bitcoin-core-dev
275 2017-08-18T13:22:00  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9f60b3707d1e...aeec8b4b6882
276 2017-08-18T13:22:00  <bitcoin-git> bitcoin/master 5be6e9b Wladimir J. van der Laan: doc: Update build-openbsd for 6.1...
277 2017-08-18T13:22:01  <bitcoin-git> bitcoin/master aeec8b4 Wladimir J. van der Laan: Merge #11080: doc: Update build-openbsd for 6.1...
278 2017-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
279 2017-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
280 2017-08-18T13:24:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/aeec8b4b6882...9e00a625b43c
281 2017-08-18T13:24:35  <bitcoin-git> bitcoin/master bea8e9e practicalswift: Document the preference of nullptr over NULL or (void*)0
282 2017-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...
283 2017-08-18T13:24:57  *** Chris_Stewart_5 has quit IRC
284 2017-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
285 2017-08-18T13:45:55  *** jtimon has quit IRC
286 2017-08-18T13:50:50  <promag> wumpus what about https://github.com/bitcoin/bitcoin/pull/11039 ?
287 2017-08-18T13:55:23  <wumpus> promag: I'll have a look
288 2017-08-18T13:56:10  <promag> np,
289 2017-08-18T13:56:16  <wumpus> I like replacing .count() and [] with one find
290 2017-08-18T13:56:30  <wumpus> incidentally, [] generates quite a lot of code
291 2017-08-18T13:57:13  <wumpus> (when used with maps)
292 2017-08-18T13:57:30  <promag> there is a PR to replace that with .at()
293 2017-08-18T13:57:59  <promag> the idea there is just to avoid the 2nd lookup
294 2017-08-18T13:58:30  <wumpus> yes
295 2017-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
296 2017-08-18T14:04:17  *** str4d_ has quit IRC
297 2017-08-18T14:06:57  <luke-jr> might be nice to do a explicittype& varname = it->second; though - but this is definitely an improvement
298 2017-08-18T14:07:25  <luke-jr> (it's hard to tell what it->second actually is here)
299 2017-08-18T14:09:58  <wumpus> luke-jr:  looks like that's what he does
300 2017-08-18T14:10:06  <wumpus> luke-jr: only the iterator is assigned to an auto
301 2017-08-18T14:10:15  <luke-jr> I'm not talking about the iterator ;p
302 2017-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
303 2017-08-18T14:11:01  <wumpus> luke-jr: I know, but he does "CWalletTx& wtx = it->second;" in many places
304 2017-08-18T14:11:12  <wumpus> which matches "explicittype& varname = it->second; " right?
305 2017-08-18T14:11:17  <luke-jr> yes, it should be in the other places too
306 2017-08-18T14:11:22  <wumpus> meh
307 2017-08-18T14:11:46  <promag> those "explicittype& varname = it->second; "  were already there
308 2017-08-18T14:11:55  *** goatpig has quit IRC
309 2017-08-18T14:11:59  <wumpus> yes. it's fine.
310 2017-08-18T14:12:33  <promag> luke-jr: I didn't add new vars
311 2017-08-18T14:12:43  <luke-jr> promag: I'm saying you should in this case
312 2017-08-18T14:12:56  <luke-jr> directly using it->second is poor for readability
313 2017-08-18T14:13:38  <promag> that will cause a bigger diff, out of scope IMO
314 2017-08-18T14:13:40  <wumpus> please don't change it now, I've just reviewed it
315 2017-08-18T14:13:42  <wumpus> yeah
316 2017-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.
317 2017-08-18T14:15:05  <luke-jr> sure
318 2017-08-18T14:15:44  <promag> luke-jr: I almost did that, just thought those can be improved in a later PR
319 2017-08-18T14:15:48  <promag> cool
320 2017-08-18T14:17:42  *** str4d_ has joined #bitcoin-core-dev
321 2017-08-18T14:17:51  <luke-jr> even with the nit, it's a utACK, not a NACK ;)
322 2017-08-18T14:17:58  <luke-jr> still a clear improvement
323 2017-08-18T14:19:51  <promag> ty
324 2017-08-18T14:27:01  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e00a625b43c...fc51565cbd4c
325 2017-08-18T14:27:01  <bitcoin-git> bitcoin/master 8f2f1e0 João Barbosa: wallet: Avoid second mapWallet lookup
326 2017-08-18T14:27:02  <bitcoin-git> bitcoin/master fc51565 Wladimir J. van der Laan: Merge #11039: Avoid second mapWallet lookup...
327 2017-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
328 2017-08-18T14:36:14  <promag> This is similar https://github.com/bitcoin/bitcoin/pull/11041/files but does what luke-jr mentioned
329 2017-08-18T14:47:29  *** btcdrak has quit IRC
330 2017-08-18T14:50:21  *** JackH has quit IRC
331 2017-08-18T14:51:40  *** Cheeseo has joined #bitcoin-core-dev
332 2017-08-18T14:54:18  <promag> PR "tagged" with WIP should not be reviewed correct?
333 2017-08-18T14:58:31  *** riemann has quit IRC
334 2017-08-18T15:00:24  *** Evel-Knievel has quit IRC
335 2017-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
336 2017-08-18T15:04:16  <promag> right
337 2017-08-18T15:07:41  *** Evel-Knievel has joined #bitcoin-core-dev
338 2017-08-18T15:13:33  *** Giszmo1 has quit IRC
339 2017-08-18T15:14:09  *** Evel-Knievel has quit IRC
340 2017-08-18T15:14:59  *** Evel-Knievel has joined #bitcoin-core-dev
341 2017-08-18T15:25:23  *** Evel-Knievel has quit IRC
342 2017-08-18T15:25:45  *** Evel-Knievel has joined #bitcoin-core-dev
343 2017-08-18T15:28:11  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/fc51565cbd4c...0e5b7486cb7f
344 2017-08-18T15:28:12  <bitcoin-git> bitcoin/master 1221f60 John Newbery: [wallet] Remove keypool_topup_cleanups...
345 2017-08-18T15:28:12  <bitcoin-git> bitcoin/master 67ceff4 John Newbery: [wallet] Add logging to MarkReserveKeysAsUsed
346 2017-08-18T15:28:13  <bitcoin-git> bitcoin/master 0e5b748 Wladimir J. van der Laan: Merge #11044: [wallet] Keypool topup cleanups...
347 2017-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
348 2017-08-18T15:33:11  *** annanay25 has joined #bitcoin-core-dev
349 2017-08-18T15:35:27  *** vicenteH has quit IRC
350 2017-08-18T15:37:50  *** JoeLiu has joined #bitcoin-core-dev
351 2017-08-18T15:39:41  *** annanay25 has quit IRC
352 2017-08-18T15:46:20  *** ekerstein has joined #bitcoin-core-dev
353 2017-08-18T15:50:45  *** BashCo has quit IRC
354 2017-08-18T16:14:18  *** riemann has joined #bitcoin-core-dev
355 2017-08-18T16:26:52  *** Murch has joined #bitcoin-core-dev
356 2017-08-18T16:27:07  *** BashCo has joined #bitcoin-core-dev
357 2017-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
358 2017-08-18T16:33:59  *** abpa has joined #bitcoin-core-dev
359 2017-08-18T16:37:27  *** SopaXorzTaker has quit IRC
360 2017-08-18T16:38:08  *** BashCo has quit IRC
361 2017-08-18T16:39:36  *** SopaXorzTaker has joined #bitcoin-core-dev
362 2017-08-18T16:40:57  *** riemann has quit IRC
363 2017-08-18T16:42:55  *** BashCo has joined #bitcoin-core-dev
364 2017-08-18T16:47:28  *** SopaXorzTaker has quit IRC
365 2017-08-18T16:48:55  *** SopaXorzTaker has joined #bitcoin-core-dev
366 2017-08-18T16:52:02  *** str4d__ has joined #bitcoin-core-dev
367 2017-08-18T16:55:05  *** str4d_ has quit IRC
368 2017-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
369 2017-08-18T16:57:41  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0e5b7486cb7f...262167393d05
370 2017-08-18T16:57:42  <bitcoin-git> bitcoin/master e53615b Andrew Chow: Remove vchDefaultKey and have better first run detection...
371 2017-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...
372 2017-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
373 2017-08-18T16:59:32  <luke-jr> instagibbs: see #11089
374 2017-08-18T17:06:10  *** riemann has joined #bitcoin-core-dev
375 2017-08-18T17:12:59  *** SopaXorzTaker has quit IRC
376 2017-08-18T17:13:15  <instagibbs> luke-jr, ah sorry didn't notice that
377 2017-08-18T17:13:39  <luke-jr> instagibbs: if you want to take it back, I can close
378 2017-08-18T17:13:48  <instagibbs> nah, you rebased for me
379 2017-08-18T17:13:51  <instagibbs> thanks :P
380 2017-08-18T17:13:51  <luke-jr> although I cut out some of it
381 2017-08-18T17:14:29  *** jimpo has joined #bitcoin-core-dev
382 2017-08-18T17:15:40  <instagibbs> sure, doesn't have to be done all at once
383 2017-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
384 2017-08-18T17:27:12  *** ekerstein has quit IRC
385 2017-08-18T17:29:21  <luke-jr> instagibbs: well, I disagree with extending sign/verify ;)
386 2017-08-18T17:33:20  *** SopaXorzTaker has joined #bitcoin-core-dev
387 2017-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
388 2017-08-18T17:36:27  *** vicenteH has joined #bitcoin-core-dev
389 2017-08-18T17:40:02  <instagibbs> luke-jr, no strong opinions :)
390 2017-08-18T17:42:15  *** ekerstein has joined #bitcoin-core-dev
391 2017-08-18T17:46:51  *** JoeLiu has quit IRC
392 2017-08-18T17:47:06  *** belcher has quit IRC
393 2017-08-18T17:50:58  *** riemann has quit IRC
394 2017-08-18T17:53:27  *** vicenteH has quit IRC
395 2017-08-18T17:55:19  *** SopaXorzTaker has quit IRC
396 2017-08-18T17:55:29  *** elkalamar has joined #bitcoin-core-dev
397 2017-08-18T18:08:19  *** SopaXorzTaker has joined #bitcoin-core-dev
398 2017-08-18T18:17:05  *** vicenteH has joined #bitcoin-core-dev
399 2017-08-18T18:18:57  *** treebeardd has joined #bitcoin-core-dev
400 2017-08-18T18:26:43  *** ekerstein has quit IRC
401 2017-08-18T18:32:21  *** SopaXorzTaker has quit IRC
402 2017-08-18T18:34:47  *** SopaXorzTaker has joined #bitcoin-core-dev
403 2017-08-18T18:39:12  *** praxeology1 has joined #bitcoin-core-dev
404 2017-08-18T18:42:20  *** henrik_ has joined #bitcoin-core-dev
405 2017-08-18T18:42:41  *** praxeology has quit IRC
406 2017-08-18T18:42:47  *** henrik_ has quit IRC
407 2017-08-18T18:47:21  *** SopaXorzTaker has quit IRC
408 2017-08-18T18:49:47  *** SopaXorzTaker has joined #bitcoin-core-dev
409 2017-08-18T18:55:44  *** chjj has quit IRC
410 2017-08-18T18:56:30  *** Cheeseo has quit IRC
411 2017-08-18T18:57:26  *** SopaXorzTaker has quit IRC
412 2017-08-18T18:58:52  *** SopaXorzTaker has joined #bitcoin-core-dev
413 2017-08-18T19:03:45  *** tiagotrs has joined #bitcoin-core-dev
414 2017-08-18T19:07:21  *** SopaXorzTaker has quit IRC
415 2017-08-18T19:08:09  *** Char0n has left #bitcoin-core-dev
416 2017-08-18T19:09:47  *** SopaXorzTaker has joined #bitcoin-core-dev
417 2017-08-18T19:10:25  *** BashCo has quit IRC
418 2017-08-18T19:11:30  *** jimpo has quit IRC
419 2017-08-18T19:17:21  *** SopaXorzTaker has quit IRC
420 2017-08-18T19:19:47  *** SopaXorzTaker has joined #bitcoin-core-dev
421 2017-08-18T19:20:17  *** ekerstein has joined #bitcoin-core-dev
422 2017-08-18T19:20:36  *** BashCo has joined #bitcoin-core-dev
423 2017-08-18T19:27:06  *** jimpo has joined #bitcoin-core-dev
424 2017-08-18T19:28:27  *** chjj has joined #bitcoin-core-dev
425 2017-08-18T19:29:20  *** CubicEarth has joined #bitcoin-core-dev
426 2017-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.
427 2017-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?
428 2017-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.
429 2017-08-18T19:45:37  *** ekerstein has quit IRC
430 2017-08-18T19:48:48  *** BashCo has quit IRC
431 2017-08-18T19:51:19  *** BashCo has joined #bitcoin-core-dev
432 2017-08-18T19:52:26  *** SopaXorzTaker has quit IRC
433 2017-08-18T19:53:55  *** SopaXorzTaker has joined #bitcoin-core-dev
434 2017-08-18T19:59:16  <gmaxwell> warren: luke posted an alaysis patch on reddit, it's about 1.9x IIRC.
435 2017-08-18T20:04:53  *** AaronvanW has quit IRC
436 2017-08-18T20:05:09  *** AaronvanW has joined #bitcoin-core-dev
437 2017-08-18T20:07:21  <warren> "effective limit" -> "effective size"?
438 2017-08-18T20:09:02  *** griswaalt has joined #bitcoin-core-dev
439 2017-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
440 2017-08-18T20:14:09  *** CubicEarth has quit IRC
441 2017-08-18T20:17:39  *** belcher has joined #bitcoin-core-dev
442 2017-08-18T20:18:30  *** dermoth has quit IRC
443 2017-08-18T20:19:14  *** dermoth has joined #bitcoin-core-dev
444 2017-08-18T20:20:41  *** BashCo has quit IRC
445 2017-08-18T20:21:21  *** justanotheruser has quit IRC
446 2017-08-18T20:21:52  *** mkarrer has joined #bitcoin-core-dev
447 2017-08-18T20:24:03  *** griswaalt has quit IRC
448 2017-08-18T20:33:30  <luke-jr> does per-TXO store the outpoint in both the key and the value? O.o
449 2017-08-18T20:35:13  *** BashCo has joined #bitcoin-core-dev
450 2017-08-18T20:36:28  <sipa> luke-jr: no, only in the key
451 2017-08-18T20:36:30  *** Giszmo has joined #bitcoin-core-dev
452 2017-08-18T20:37:32  <sipa> COutPoint in the key, CTxOut in the value
453 2017-08-18T20:43:52  *** mkarrer has quit IRC
454 2017-08-18T20:44:39  *** griswaalt[m] has joined #bitcoin-core-dev
455 2017-08-18T20:47:02  *** Alina-malina has quit IRC
456 2017-08-18T20:48:02  *** treebeardd has quit IRC
457 2017-08-18T20:49:53  *** Alina-malina has joined #bitcoin-core-dev
458 2017-08-18T20:53:41  *** praxeology1 has quit IRC
459 2017-08-18T20:54:56  *** chjj has quit IRC
460 2017-08-18T20:56:11  *** AaronvanW has quit IRC
461 2017-08-18T20:56:48  *** AaronvanW has joined #bitcoin-core-dev
462 2017-08-18T21:05:35  *** jimpo has quit IRC
463 2017-08-18T21:06:31  *** treebeardd has joined #bitcoin-core-dev
464 2017-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.
465 2017-08-18T21:24:22  *** waveprop has quit IRC
466 2017-08-18T21:24:22  *** waveprop has joined #bitcoin-core-dev
467 2017-08-18T21:24:50  *** Guyver2 has quit IRC
468 2017-08-18T21:37:23  <luke-jr> >_<
469 2017-08-18T21:37:37  <luke-jr> well, we want that anyway I think, so maybe PR it for master at least
470 2017-08-18T21:37:45  <luke-jr> or at least don't discard it yet
471 2017-08-18T21:37:54  *** lolkeep has joined #bitcoin-core-dev
472 2017-08-18T21:38:17  *** jimpo has joined #bitcoin-core-dev
473 2017-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?
474 2017-08-18T21:39:19  <cfields> luke-jr: i don't think we can make it manually, it'll just get overwritten
475 2017-08-18T21:40:16  *** lolkeep has quit IRC
476 2017-08-18T21:40:53  *** chjj has joined #bitcoin-core-dev
477 2017-08-18T21:41:07  <BlueMatt> cfields: can you confirm there is nothing stopping switching sync.h primitives to std?
478 2017-08-18T21:41:44  <cfields> BlueMatt: sure, let me finish this thing up first though
479 2017-08-18T21:41:51  <BlueMatt> no rush
480 2017-08-18T21:42:06  <BlueMatt> cfields: just comment on 10866
481 2017-08-18T21:42:33  <luke-jr>     echo '#!/bin/true' >share/genbuild.sh
482 2017-08-18T21:42:35  <luke-jr>     mkdir -p src/obj
483 2017-08-18T21:42:36  <luke-jr>     echo "#define BUILD_SUFFIX gentoo${PVR#${PV}}" >src/obj/build.h
484 2017-08-18T21:42:39  <luke-jr> cfields: ^ what I do for Gentoo
485 2017-08-18T21:43:55  <cfields> BlueMatt: oh. at the very least, CSemaphore/CScheduler/CCheckqueue non-interruptible
486 2017-08-18T21:44:20  <BlueMatt> hmm?
487 2017-08-18T21:44:33  <BlueMatt> I dont think CSemaphore needs to be interruptible
488 2017-08-18T21:44:40  <BlueMatt> CScheduler and CCheckqueue use boost:: directiyl
489 2017-08-18T21:44:42  <BlueMatt> directly
490 2017-08-18T21:46:24  <cfields> BlueMatt: ok right, those were preventing the switch to std::thread.
491 2017-08-18T21:46:44  <BlueMatt> yes
492 2017-08-18T21:46:45  <cfields> luke-jr: heh
493 2017-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?
494 2017-08-18T21:50:36  <BlueMatt> on CSemaphore? no?
495 2017-08-18T21:50:51  <cfields> nm, was thinking of e007b24
496 2017-08-18T21:51:20  <cfields> i guess that commit shows we rely on posting :)
497 2017-08-18T21:51:29  <BlueMatt> yes, we rely on posting
498 2017-08-18T21:54:03  <cfields> ok neat, i guess the boost::mutex dep slowly dissolved
499 2017-08-18T21:55:12  <BlueMatt> =D
500 2017-08-18T21:55:20  <cfields> luke-jr: ok, want to just do that for gitian?
501 2017-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 :(
502 2017-08-18T21:55:34  <BlueMatt> but oh well
503 2017-08-18T21:55:42  <cfields> that's really gross, as it completely defeats the purpose of all of the version stuff
504 2017-08-18T21:56:07  <cfields> but i guess it works for 0.15
505 2017-08-18T21:56:28  *** str4d__ has quit IRC
506 2017-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..
507 2017-08-18T21:57:48  <cfields> luke-jr: well the "just get it fixed" approach involves nuking most of our version handling, no?
508 2017-08-18T21:58:30  <cfields> i think we'll just take the complexity down to "the tarball injected the version" or "check git" ?
509 2017-08-18T22:00:46  <luke-jr> cfields: more like using genbuild on the git to generate the stuff used by the tar
510 2017-08-18T22:01:12  <luke-jr> what should it say, btw?
511 2017-08-18T22:01:21  <cfields> sure, that works
512 2017-08-18T22:01:33  <cfields> hmm?
513 2017-08-18T22:01:47  <luke-jr> I've never seen it without the git hash in the version ;)
514 2017-08-18T22:01:59  <luke-jr> Bitcoin Core RPC client version v0.15.0
515 2017-08-18T22:02:01  <luke-jr> ?
516 2017-08-18T22:03:01  *** Deacydal has joined #bitcoin-core-dev
517 2017-08-18T22:03:43  *** Alina-malina has quit IRC
518 2017-08-18T22:03:43  <cfields> oh, heh
519 2017-08-18T22:03:51  *** abpa has quit IRC
520 2017-08-18T22:03:53  <cfields> let me check 0.14.2
521 2017-08-18T22:04:51  *** Alina-malina has joined #bitcoin-core-dev
522 2017-08-18T22:05:53  *** Deacyde has joined #bitcoin-core-dev
523 2017-08-18T22:06:55  *** Deacyded has quit IRC
524 2017-08-18T22:07:50  *** Deacydal has quit IRC
525 2017-08-18T22:09:08  <cfields> splash says "v0.14.2"
526 2017-08-18T22:09:12  <luke-jr> cfields: working on another branch atm, can you try http://codepad.org/TexBr9BW ?
527 2017-08-18T22:09:30  <cfields> i think the rc's usually have a git commit tacked on though. trying to find one
528 2017-08-18T22:10:56  <cfields> heh, good idea
529 2017-08-18T22:12:34  <cfields> testing
530 2017-08-18T22:15:58  *** tiagotrs has quit IRC
531 2017-08-18T22:17:34  <cfields> we should nuke the GIT_DIR export, then
532 2017-08-18T22:18:32  *** Deacydal has joined #bitcoin-core-dev
533 2017-08-18T22:21:50  *** Deacyde has quit IRC
534 2017-08-18T22:22:47  <luke-jr> cfields: yes, probably
535 2017-08-18T22:24:53  *** Giszmo has quit IRC
536 2017-08-18T22:25:33  *** rgrant has joined #bitcoin-core-dev
537 2017-08-18T22:31:30  *** Murch has quit IRC
538 2017-08-18T22:33:31  *** Cheeseo has joined #bitcoin-core-dev
539 2017-08-18T22:45:29  <cfields> luke-jr: it works as-is
540 2017-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
541 2017-08-18T22:46:16  <cfields> thanks for the fix :)
542 2017-08-18T22:48:14  *** rgrant has left #bitcoin-core-dev
543 2017-08-18T22:48:28  <luke-jr> cfields: np, although it's probably  not a good long-term fix..
544 2017-08-18T22:53:37  *** justanotheruser has joined #bitcoin-core-dev
545 2017-08-18T22:54:00  *** justanotheruser has joined #bitcoin-core-dev
546 2017-08-18T23:01:57  *** str4d has joined #bitcoin-core-dev
547 2017-08-18T23:09:01  *** Alina-malina has quit IRC
548 2017-08-18T23:09:02  *** Cheeseo has quit IRC
549 2017-08-18T23:12:29  *** Alina-malina has joined #bitcoin-core-dev
550 2017-08-18T23:22:53  *** Alina-malina has quit IRC
551 2017-08-18T23:25:28  *** Alina-malina has joined #bitcoin-core-dev
552 2017-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
553 2017-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
554 2017-08-18T23:36:04  *** unholymachine has quit IRC
555 2017-08-18T23:39:27  *** unholymachine has joined #bitcoin-core-dev