1 2018-06-14 00:58:45	0|bitcoin-git|[13bitcoin] 15ken2812221 opened pull request #13465: Avoid concurrency issue when make multiple target (06master...06no_parallel) 02https://github.com/bitcoin/bitcoin/pull/13465
  2 2018-06-14 01:33:29	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #13467: [Tests] Make p2p_segwit easier to debug (06master...06tidy_up_p2p_segwit) 02https://github.com/bitcoin/bitcoin/pull/13467
  3 2018-06-14 02:15:49	0|christos88|im so happy, the client finished the checkup, now its downloading blocks again :)
  4 2018-06-14 03:02:14	0|bitcoin-git|[13bitcoin] 15kaloudis opened pull request #13468: Trivial: Fix locale typos (06master...06locale-typos) 02https://github.com/bitcoin/bitcoin/pull/13468
  5 2018-06-14 03:04:03	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #13468: Trivial: Fix locale typos (06master...06locale-typos) 02https://github.com/bitcoin/bitcoin/pull/13468
  6 2018-06-14 07:16:57	0|GitHub85|[13bitcoin-detached-sigs] 15jonasschnelli opened pull request #8: 0.16.1: osx signatures for 0.16.1 (060.16...060.16) 02https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/8
  7 2018-06-14 09:01:50	0|bitcoin-git|[13bitcoin] 15Empact closed pull request #13239: [moveonly] Fix CConnman template methods to be fully-defined in net.h (06master...06net-template-methods) 02https://github.com/bitcoin/bitcoin/pull/13239
  8 2018-06-14 09:28:19	0|jonasschnelli|sipa: you may want to review the Bech32X python ref impl. https://github.com/jonasschnelli/Bech32X/blob/master/ref/python/bech32x.py
  9 2018-06-14 09:28:35	0|jonasschnelli|It's still WIP, I added the HRP handling
 10 2018-06-14 09:28:52	0|jonasschnelli|Not sure if it should have decode and correct or only correct
 11 2018-06-14 09:29:27	0|promag|jonasschnelli: can you explain how is the progress calculated in FindScriptPubKey*
 12 2018-06-14 09:30:00	0|promag|I don't understand lines 42-43
 13 2018-06-14 09:32:07	0|jonasschnelli|promag: let me check...
 14 2018-06-14 09:33:06	0|jonasschnelli|promag: hases are stored ordered, ... so we calculate the progress from the hash in relation to 0xFFFF IIRC
 15 2018-06-14 09:33:31	0|jonasschnelli|Not to 0xFFFF but similar
 16 2018-06-14 09:51:57	0|promag|jonasschnelli: I think I get it, still it's an approximation right?
 17 2018-06-14 09:52:38	0|promag|I mean, it's not linear
 18 2018-06-14 09:53:05	0|jonasschnelli|yes. its approx
 19 2018-06-14 13:12:14	0|ken2812221|wumpus: Can I add #13426 to High priority for review? The meeting time is 3 am for me.
 20 2018-06-14 13:12:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Add u8path and u8string to fix #13103 by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub
 21 2018-06-14 13:58:04	0|instagibbs|was there ever any resolution to the release notes conflict-a-thon
 22 2018-06-14 14:11:18	0|ken2812221|instagibbs: You can create release-notes-prXXXXX.md to avoid it. Also see #12819
 23 2018-06-14 14:11:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/12819 | Avoid release-notes.md conflicts · Issue #12819 · bitcoin/bitcoin · GitHub
 24 2018-06-14 14:26:28	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #13470: WIP [bench] CCoinsView(Cache): measure various scenarios (06master...062018/06/bench_db_cache) 02https://github.com/bitcoin/bitcoin/pull/13470
 25 2018-06-14 15:11:32	0|bitcoin-git|[13bitcoin] 15Sjors closed pull request #12404: Prune more aggressively during IBD (06master...062018/02/ibd_prune_extra) 02https://github.com/bitcoin/bitcoin/pull/12404
 26 2018-06-14 17:08:18	0|promag|do we lock files?
 27 2018-06-14 17:09:09	0|sipa|we lock a lockfile
 28 2018-06-14 17:13:13	0|promag|is that what luke-jr means in https://github.com/bitcoin/bitcoin/pull/12842#issuecomment-396686016?
 29 2018-06-14 17:18:09	0|sipa|perhaps
 30 2018-06-14 17:36:22	0|jnewbery|promag: what is https://github.com/bitcoin/bitcoin/pull/13111/files#diff-2e3836af182cfb375329c3463ffd91f8R370 suppposed to be doing? It's invoking a method called "unload" which I can't find
 31 2018-06-14 17:39:20	0|bitcoin-git|13bitcoin/06master 1486edf4a 15Gregory Sanders: expose CBlockIndex::nTx in getblock(header)
 32 2018-06-14 17:39:20	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4a7e64fc8546...cc7cbd756acd
 33 2018-06-14 17:39:21	0|bitcoin-git|13bitcoin/06master 14cc7cbd7 15Wladimir J. van der Laan: Merge #13451: rpc: expose CBlockIndex::nTx in getblock(header)...
 34 2018-06-14 17:40:13	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13451: rpc: expose CBlockIndex::nTx in getblock(header) (06master...06expose_nTx) 02https://github.com/bitcoin/bitcoin/pull/13451
 35 2018-06-14 17:44:35	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #13471: For AVX2 code, also check for AVX, XSAVE, and OS support (06master...06201806_avxossupport) 02https://github.com/bitcoin/bitcoin/pull/13471
 36 2018-06-14 17:51:27	0|kanzure|wom 3
 37 2018-06-14 17:51:32	0|kanzure|error. hm.
 38 2018-06-14 18:19:05	0|jonasschnelli|sipa: The polynominal operation in Bech32X requires 256bit bitwise AND operation, right?
 39 2018-06-14 18:19:27	0|sipa|jonasschnelli: 135 bit XOR
 40 2018-06-14 18:19:38	0|jonasschnelli|okay.. I see
 41 2018-06-14 18:19:48	0|sipa|on languages that don't support big integers, split it up in 3 64-bit integers
 42 2018-06-14 18:20:06	0|jonasschnelli|Yes. Will do
 43 2018-06-14 18:20:27	0|sipa|what language?
 44 2018-06-14 18:20:59	0|jonasschnelli|sipa: the python impl. is "done" (draft) https://github.com/jonasschnelli/Bech32X/blob/master/ref/python/bech32x.py ... now working on C
 45 2018-06-14 18:21:40	0|jonasschnelli|sipa: I guess it makes sense to have a straight decode() _and_ a correct() in case decode fails?
 46 2018-06-14 18:22:32	0|sipa|jonasschnelli: the correction code is less efficient in realizing there are no errors
 47 2018-06-14 18:22:49	0|jonasschnelli|okay
 48 2018-06-14 18:23:19	0|sipa|it could have a short circuit check if all syndromes are 0, and in that case just straight decode
 49 2018-06-14 18:23:33	0|sipa|(the syn variable, after the "for v" loop)
 50 2018-06-14 18:23:51	0|jonasschnelli|Okay. That makes sense...
 51 2018-06-14 18:24:15	0|bitcoin-git|[13bitcoin] 15kristapsk closed pull request #13464: RPC: Allow to specify rescan start timestamp for importaddress, importprivkey and importpubkey (06master...06rescan-from) 02https://github.com/bitcoin/bitcoin/pull/13464
 52 2018-06-14 18:24:19	0|sipa|no need to invoke solver etc in that case
 53 2018-06-14 18:24:50	0|jonasschnelli|Also, what made me think a bit: dropping a char will not be detected which seems like a likely (error) case
 54 2018-06-14 18:25:06	0|jonasschnelli|s/detected/corrected
 55 2018-06-14 18:26:45	0|sipa|huh
 56 2018-06-14 18:26:51	0|sipa|that should be detected
 57 2018-06-14 18:27:00	0|gmaxwell|sipa: he means a frameshift, and correction, not detection.
 58 2018-06-14 18:27:40	0|gmaxwell|i think for these things its useful if the length is explicit and known, so then you can trigger dropped character repair more usefully.
 59 2018-06-14 18:28:32	0|jonasschnelli|Yes. Length is known,.. but the correction would need to be different
 60 2018-06-14 18:30:11	0|gmaxwell|yes, there isn't a simple algebraic correction for that, but you can insert a dummy at each position and run the normal correction.  I think it's sufficient to know it's possible to do that.
 61 2018-06-14 18:30:32	0|jonasschnelli|agree
 62 2018-06-14 18:31:12	0|sipa|i wonder if ability to detect such errors is something we can optimize the code for
 63 2018-06-14 18:31:32	0|gmaxwell|even placing two characters in a 64 character string is only about 2k possibilities.
 64 2018-06-14 18:33:13	0|gmaxwell|sipa: I started to write a fancy bech32 hinter with the idea of list decoding out to 3 errors, including searching for patterns of up to a couple drop and inserts, then using that recent data base of password entry error probablities (which include probabilities for dropped, transposed, and inserted characters) and ranking a probablity for each option.
 65 2018-06-14 18:33:29	0|jonasschnelli|I'm manly worried about that people will think with "it can correct up to X characters", it does include missing chars
 66 2018-06-14 18:33:48	0|sipa|it's hamming distance, not levenshtein distance :)
 67 2018-06-14 18:34:28	0|gmaxwell|well it does correct up to missing characters with unknown positions, assuming a sutiable decoder.
 68 2018-06-14 18:35:14	0|sipa|jonasschnelli: oh, something that i haven't mentioned - that bech32x code can correct up to 14 errors if you know their positions
 69 2018-06-14 18:35:40	0|sipa|jonasschnelli: which means that if you have explicitly unreadable characters (as opposed to characters that may be wrong), its error correction ability is much stronger
 70 2018-06-14 18:35:48	0|sipa|this is called erasure, not correction
 71 2018-06-14 18:35:50	0|gmaxwell|by 'correct up to' sipa means "with no more remaining error detection power"
 72 2018-06-14 18:36:23	0|sipa|or in general, you can correct with M known erasures and N addition errors in unknown places as long as M+2*N <= 14
 73 2018-06-14 18:36:35	0|sipa|that's not implemented in that demo
 74 2018-06-14 18:36:40	0|jonasschnelli|I see...
 75 2018-06-14 18:36:41	0|sipa|but it's not very hard to do
 76 2018-06-14 18:37:20	0|sipa|M+2*N < 15 is why this is called a distance 15 code
 77 2018-06-14 18:37:45	0|gmaxwell|sipa: are those figures really all that useful for this application?  e.g. if you can't externally tell that the key is correct (by checking against the blockchain) you can't go safely to that bound, and if you can tell via external information, you can go further.
 78 2018-06-14 18:38:29	0|sipa|why can't you safely go to that bound?
 79 2018-06-14 18:38:44	0|gmaxwell|because you can't tell if the result is right or not.
 80 2018-06-14 18:39:21	0|gmaxwell|if you corrupt 15 characters, but think you have corrupted 14, you'll "recover" something but it'll be the wrong one.
 81 2018-06-14 18:39:53	0|gmaxwell|Of course, if you can check against the blockchain you're good to go, but in that case in we could go beyond 15 errors.
 82 2018-06-14 18:40:05	0|sipa|right
 83 2018-06-14 18:40:11	0|sipa|in practice you always have both, i guess
 84 2018-06-14 18:40:32	0|sipa|but the without-the-blockchain inner "loop" is much more efficient
 85 2018-06-14 18:59:14	0|wumpus|meeting time?
 86 2018-06-14 18:59:18	0|jonasschnelli|jup
 87 2018-06-14 18:59:19	0|lightningbot|Meeting started Thu Jun 14 19:00:32 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 88 2018-06-14 18:59:19	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 89 2018-06-14 18:59:19	0|wumpus|#startmeeting
 90 2018-06-14 18:59:23	0|jonasschnelli|hi
 91 2018-06-14 18:59:24	0|sipa|aye
 92 2018-06-14 18:59:28	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
 93 2018-06-14 18:59:31	0|meshcollider|hi
 94 2018-06-14 18:59:39	0|cfields|hi
 95 2018-06-14 18:59:46	0|kanzure|hi.
 96 2018-06-14 18:59:54	0|meshcollider|Sorry I haven't been around for the last few weeks, swamped with assignments and exams
 97 2018-06-14 18:59:58	0|achow101|hi
 98 2018-06-14 19:00:08	0|promag|hi
 99 2018-06-14 19:00:32	0|wumpus|meshcollider: np!
100 2018-06-14 19:00:37	0|wumpus|topic proposals?
101 2018-06-14 19:01:13	0|wumpus|#topic high priority for review
102 2018-06-14 19:01:24	0|promag|jnewbery: after qt4 is dropped, I'll replace qt connections with the new sintax
103 2018-06-14 19:01:25	0|wumpus|currently on the list: #13425 #13111 #13062 #12196 #12136
104 2018-06-14 19:01:29	0|achow101|topic proposal: srd fallback coin selection
105 2018-06-14 19:01:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
106 2018-06-14 19:01:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
107 2018-06-14 19:01:34	0|gribble|https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
108 2018-06-14 19:01:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
109 2018-06-14 19:01:40	0|bitcoin-git|[13bitcoin] 15HashUnlimited opened pull request #13472: [devtools translations] catch invalid specifiers (06master...06HashUnlimited-translate-1) 02https://github.com/bitcoin/bitcoin/pull/13472
110 2018-06-14 19:01:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions serialization and RPCs by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
111 2018-06-14 19:01:50	0|wumpus|unloadwallet from promag seems almost ready for merge
112 2018-06-14 19:01:51	0|achow101|12136 can be removed for now
113 2018-06-14 19:02:02	0|wumpus|achow101: ok
114 2018-06-14 19:02:07	0|achow101|it depends on 13425
115 2018-06-14 19:02:45	0|wumpus|dropped
116 2018-06-14 19:02:53	0|promag|wumpus: I think so, I have to fix last jnewbery points
117 2018-06-14 19:02:56	0|sipa|#13425 is pretty much all of the PSBT internal changes that are needed, excluding serialization and RPCs
118 2018-06-14 19:02:56	0|wumpus|it was unfair for you to have two entires on the list, anyway
119 2018-06-14 19:02:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
120 2018-06-14 19:03:34	0|jnewbery|I think since the last change, unloadwallet no longer removes the unloaded wallet from the dropdown menu
121 2018-06-14 19:03:39	0|wumpus|(just kidding, no idea how it came that way)
122 2018-06-14 19:04:01	0|promag|jnewbery: you are right
123 2018-06-14 19:04:14	0|promag|needs signal unload
124 2018-06-14 19:04:21	0|wumpus|right
125 2018-06-14 19:04:30	0|jnewbery|yep. Seems to work with that method declaration readded
126 2018-06-14 19:05:50	0|wumpus|should we add anything to the list this week?
127 2018-06-14 19:06:12	0|promag|#13160
128 2018-06-14 19:06:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
129 2018-06-14 19:06:25	0|wumpus|you already have one
130 2018-06-14 19:06:33	0|meshcollider|Lol
131 2018-06-14 19:06:40	0|promag|there was a behaviour change since 0,15 iirc, that fixes it
132 2018-06-14 19:07:19	0|wumpus|promag: but I agree it needs more attention, FWIW
133 2018-06-14 19:07:57	0|promag|it's one line change
134 2018-06-14 19:08:02	0|sipa|the high-priority list is for things that block other work
135 2018-06-14 19:08:09	0|wumpus|yes
136 2018-06-14 19:08:13	0|sipa|not just "this needs attention"
137 2018-06-14 19:08:29	0|wumpus|that's what the meeting is for
138 2018-06-14 19:09:20	0|wumpus|#action look at #13160
139 2018-06-14 19:09:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
140 2018-06-14 19:09:39	0|wumpus|other topics?
141 2018-06-14 19:09:48	0|meshcollider|I just reviewed it fwiw promag
142 2018-06-14 19:09:56	0|wumpus|meshcollider: thanks!
143 2018-06-14 19:10:07	0|achow101|<achow101> topic proposal: srd fallback coin selection
144 2018-06-14 19:10:26	0|wumpus|#topic srd fallback coin selection (achow101)
145 2018-06-14 19:10:57	0|wumpus|srd = Single Random Draw?
146 2018-06-14 19:11:01	0|achow101|yes
147 2018-06-14 19:11:06	0|wumpus|#13307
148 2018-06-14 19:11:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/13307 | Replace coin selection fallback strategy with Single Random Draw by achow101 · Pull Request #13307 · bitcoin/bitcoin · GitHub
149 2018-06-14 19:11:20	0|achow101|I think we should discuss instagibbs's point here: https://github.com/bitcoin/bitcoin/pull/13307#discussion_r192899180
150 2018-06-14 19:11:31	0|instagibbs|oh, I said something eh
151 2018-06-14 19:11:51	0|achow101|the basic point is that in the current coin selection, we prefer exact matches over confirmations. However the current implementation of srd fallback is that we prefer confirmations over exact matches
152 2018-06-14 19:12:22	0|instagibbs|altnernating between BnB(Exact match) and then fallback, rather than Bnb of all sorts then fallback
153 2018-06-14 19:12:48	0|sipa|so this is a bit of a question on what our coin selection algorithm should prioritize
154 2018-06-14 19:12:55	0|achow101|yes
155 2018-06-14 19:12:56	0|sipa|confirmed coins, or (immediate) fee
156 2018-06-14 19:13:06	0|instagibbs|and privacy
157 2018-06-14 19:13:32	0|instagibbs|imo privacy puts it over the top and we should try really hard to do it
158 2018-06-14 19:13:40	0|instagibbs|but obviously it's not a slam dunk
159 2018-06-14 19:13:46	0|sipa|hmm, unclear how privacy is affect here?
160 2018-06-14 19:13:56	0|instagibbs|change-less outputs mess with coin analysis
161 2018-06-14 19:14:03	0|instagibbs|to a large degree
162 2018-06-14 19:14:23	0|sipa|that's a good point
163 2018-06-14 19:15:32	0|sipa|sdaftuar, morcos: present, opinions?
164 2018-06-14 19:15:49	0|sipa|gmaxwell: ?
165 2018-06-14 19:16:14	0|instagibbs|IIRC we converged on being ok with current behavior, because it breaks the long chains if it works
166 2018-06-14 19:16:18	0|achow101|I also did a simulation (so take it with a grain of salt) that showed that the number of utxos with exact match over confirmations was higher than not
167 2018-06-14 19:16:22	0|instagibbs|was an intentional design decision
168 2018-06-14 19:18:13	0|sipa|what do you mean by "current behaviour"?
169 2018-06-14 19:18:18	0|instagibbs|in master
170 2018-06-14 19:18:20	0|sipa|master or the SRD PR?
171 2018-06-14 19:18:21	0|sipa|ok
172 2018-06-14 19:18:58	0|sipa|there is another question here on what the criteria for SRD merge should be
173 2018-06-14 19:19:37	0|sipa|because it seems it results in somewhat higher average UTXOs per wallet in simulations
174 2018-06-14 19:19:57	0|instagibbs|merge as in code? or?
175 2018-06-14 19:20:15	0|achow101|merge as in merge the pr
176 2018-06-14 19:20:45	0|instagibbs|ah
177 2018-06-14 19:20:51	0|sipa|yes, i'm wondering what our bar for deciding to change tbe logic should be
178 2018-06-14 19:20:54	0|achow101|it doesn't seem to perform as well as the current coin selection in master w.r.t mean number of utxos in the wallet in my simulations
179 2018-06-14 19:21:07	0|meshcollider|Significantly higher?
180 2018-06-14 19:21:19	0|instagibbs|did you try filtering for using only coins lower than target value? using coins with negative effective value?
181 2018-06-14 19:21:24	0|achow101|from ~20 utxos to ~90 utxos
182 2018-06-14 19:21:24	0|instagibbs|allowing a single negative effective value?
183 2018-06-14 19:21:54	0|instagibbs|Core is an extreme UTXO cop currently. I don't think we're going to be able to match it.
184 2018-06-14 19:22:06	0|achow101|these are the results so far https://gist.github.com/achow101/242470486265d3f21adab08f65b9102c
185 2018-06-14 19:22:48	0|achow101|I have tried filtering for inputs smaller than the target value and doing srd on that. if that fails, srd on all inputs
186 2018-06-14 19:23:07	0|achow101|I have also done that but instead of srd on all inputs on failure, choosing the input that is immediately larger than the target value
187 2018-06-14 19:24:16	0|sipa|also, these numbers are just for a single simulation, right?
188 2018-06-14 19:24:27	0|achow101|yes, those are all for the same scenario
189 2018-06-14 19:24:32	0|sipa|on different workloads differents effects may be preswnt
190 2018-06-14 19:24:49	0|achow101|I'm running simulations for the other scenarios right now, but that will take a while to finish
191 2018-06-14 19:25:16	0|sipa|i guess more to discuss in the PR
192 2018-06-14 19:27:22	0|instagibbs|achow101, you can also test not filtering for -EV
193 2018-06-14 19:27:38	0|instagibbs|to see how big an effect that is
194 2018-06-14 19:27:54	0|achow101|so we could be spending dust?
195 2018-06-14 19:28:23	0|instagibbs|Like we do now yes
196 2018-06-14 19:28:40	0|achow101|hmm.. ok, I can try that too
197 2018-06-14 19:28:41	0|instagibbs|And "allow 1 negative EV output" type logic
198 2018-06-14 19:28:53	0|instagibbs|anyways, more to discuss on PR
199 2018-06-14 19:29:12	0|sipa|EV filtering is probably the biggest reason for increased UTXO
200 2018-06-14 19:32:10	0|instagibbs|"allow 1" might be nice in that you won't blow up way past what is actually sane, while containing the bloat
201 2018-06-14 19:32:10	0|MarcoFalke|Sorry for being late, but I'd like to propose #13439 for high priority for review
202 2018-06-14 19:32:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/13439 | rpc: Avoid "duplicate" return value for invalid submitblock by TheBlueMatt · Pull Request #13439 · bitcoin/bitcoin · GitHub
203 2018-06-14 19:34:08	0|wumpus|MarcoFalke: sure
204 2018-06-14 19:34:15	0|MarcoFalke|thx
205 2018-06-14 19:35:00	0|wumpus|MarcoFalke: done
206 2018-06-14 19:35:03	0|wumpus|any other topics?
207 2018-06-14 19:37:48	0|sipa|i have 4 PRs open relating to optimized hardware SHA256... should I combine them into 1, or leave like this?
208 2018-06-14 19:38:01	0|wumpus|let me see
209 2018-06-14 19:38:25	0|sipa|#13471 #13386 #13442 #13438
210 2018-06-14 19:38:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/13471 | For AVX2 code, also check for AVX, XSAVE, and OS support by sipa · Pull Request #13471 · bitcoin/bitcoin · GitHub
211 2018-06-14 19:38:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/13386 | SHA256 implementations based on Intel SHA Extensions by sipa · Pull Request #13386 · bitcoin/bitcoin · GitHub
212 2018-06-14 19:38:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/13442 | Convert the 1-way SSE4 SHA256 code from asm to intrinsics by sipa · Pull Request #13442 · bitcoin/bitcoin · GitHub
213 2018-06-14 19:38:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/13438 | Improve coverage of SHA256 SelfTest code by sipa · Pull Request #13438 · bitcoin/bitcoin · GitHub
214 2018-06-14 19:38:41	0|wumpus|it's good for the selftest one to be seperate, I think that one can be merged
215 2018-06-14 19:39:06	0|wumpus|I haven't really looked at the other ones yet in detail yet
216 2018-06-14 19:39:20	0|cfields|sipa: I have a follow-up PR as well to build a lib-for-each-arch
217 2018-06-14 19:39:25	0|sipa|cfields: ah yes
218 2018-06-14 19:39:33	0|sipa|i'll leave things like this
219 2018-06-14 19:39:35	0|cfields|I figured I'd just wait until everything settled for that one, but let me know if you'd prefer something else
220 2018-06-14 19:39:46	0|wumpus|re: 13442, didn't you first say that made things a few % *slower* on 64 bit?
221 2018-06-14 19:40:01	0|sipa|wumpus: i made more changes, it's faster now
222 2018-06-14 19:40:09	0|wumpus|great, no problems with it anymore then
223 2018-06-14 19:40:21	0|sipa|but it's very heavily compiler dependent... rearranging two lines can have 5% effect on speed
224 2018-06-14 19:40:38	0|sipa|or making a constant static
225 2018-06-14 19:40:38	0|wumpus|seems preferable in every way then
226 2018-06-14 19:40:46	0|sipa|how so?
227 2018-06-14 19:40:56	0|wumpus|both more readable and faster
228 2018-06-14 19:41:06	0|sipa|ah yes, but probably less reliably faster
229 2018-06-14 19:41:10	0|sipa|perhaps on clang it's slower
230 2018-06-14 19:41:12	0|cfields|sipa: also worth considering (I read this just yesterday), apparently gcc switched the way that 256bit loads are done, somewhere around gcc6, I believe.
231 2018-06-14 19:41:15	0|sipa|or with particular gcc versions
232 2018-06-14 19:41:19	0|cfields|so, worth considering compiler age as well.
233 2018-06-14 19:41:25	0|wumpus|right
234 2018-06-14 19:42:28	0|wumpus|if it becomes faster with new compilers it's good
235 2018-06-14 19:42:43	0|wumpus|if slower, not :)
236 2018-06-14 19:42:45	0|cfields|(see gcc's "mavx256-split-unaligned-load" option, which had its default value changed)
237 2018-06-14 19:43:03	0|ryanofsky|cd
238 2018-06-14 19:43:24	0|sipa|wumpus: another benefit is that this lets us compile the exact same code with -mavx, and get a slightly faster version for AVX capable machines
239 2018-06-14 19:43:27	0|cfields|~$
240 2018-06-14 19:43:37	0|wumpus|sipa: that's really nice
241 2018-06-14 19:43:47	0|wumpus|sipa: so we compile it twice, the same code?
242 2018-06-14 19:43:52	0|sipa|wumpus: yup
243 2018-06-14 19:43:59	0|sipa|cfields is working on build system changes for that
244 2018-06-14 19:44:02	0|wumpus|almost for free
245 2018-06-14 19:44:23	0|sipa|i wonder what percentage of our binary will be SHA256 implementations...
246 2018-06-14 19:44:55	0|wumpus|a very small part
247 2018-06-14 19:45:00	0|cfields|heh
248 2018-06-14 19:45:20	0|wumpus|though I understand the sentiment :)
249 2018-06-14 19:46:16	0|wumpus|as for the source code, a larger part, which reminds me I still need to add ARM
250 2018-06-14 19:46:34	0|wumpus|POWER8 one needs review #13203
251 2018-06-14 19:46:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/13203 | Add POWER8 ASM for 4-way SHA256 by TheBlueMatt · Pull Request #13203 · bitcoin/bitcoin · GitHub
252 2018-06-14 19:47:18	0|sipa|cfields: we should also try with things like -mmovbe, -mbmi1, -mbmi2, ...
253 2018-06-14 19:47:21	0|wumpus|that's really an instruction set I have no clue about
254 2018-06-14 19:47:30	0|sipa|cfields: i think these may not be implied by -mavx / -mavx2
255 2018-06-14 19:47:45	0|sipa|but generally available on the same systems
256 2018-06-14 19:47:52	0|cfields|sipa: yes. IIRC bmi provides some useful things.
257 2018-06-14 19:48:21	0|cfields|yea, rorx
258 2018-06-14 19:48:34	0|cfields|sorry, that's bmi2
259 2018-06-14 19:51:24	0|wumpus|I'm lost
260 2018-06-14 19:51:37	0|sipa|don't worry :)
261 2018-06-14 19:52:03	0|wumpus|:)
262 2018-06-14 19:52:13	0|wumpus|any quick topic?
263 2018-06-14 19:52:29	0|achow101|when 0.16.1 detached sigs?
264 2018-06-14 19:52:52	0|cfields|achow101: soon, building now
265 2018-06-14 19:53:08	0|cfields|jonasschnelli: ^^ ping for other half
266 2018-06-14 19:53:29	0|jonasschnelli|already made
267 2018-06-14 19:53:31	0|jonasschnelli|https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/8
268 2018-06-14 19:53:34	0|wumpus|cfields: jonasschnelli: thanks
269 2018-06-14 19:54:00	0|cfields|jonasschnelli: ah, I missed the pr! You beat me to it :)
270 2018-06-14 19:54:15	0|jonasschnelli|:-)
271 2018-06-14 19:54:16	0|GitHub133|[13bitcoin-detached-sigs] 15laanwj closed pull request #8: 0.16.1: osx signatures for 0.16.1 (060.16...060.16) 02https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/8
272 2018-06-14 19:55:49	0|luke-jr|hi
273 2018-06-14 19:56:01	0|wumpus|jonasschnelli: you should probably be able to merge your own stuff there
274 2018-06-14 19:56:28	0|jonasschnelli|wumpus: Yes. I did create the PR because I wasn't sure if we did hit the threshold or required non code-signed signatures
275 2018-06-14 19:56:49	0|wumpus|right, good point
276 2018-06-14 19:57:25	0|luke-jr|well, as soon as the signatures exist, someone could potentially use them
277 2018-06-14 19:57:33	0|luke-jr|so if the threshold isn't met, even a PR could be problematic
278 2018-06-14 19:57:42	0|wumpus|5 signers for every platform so that seems ok
279 2018-06-14 19:58:10	0|cfields|yea, it'd only be an issue if there were 2 competing "correct" gitian outputs
280 2018-06-14 19:58:19	0|wumpus|agree that for a -final relaese it's better to wait for a few more
281 2018-06-14 19:58:21	0|cfields|I think that's happened in the past due to timezones
282 2018-06-14 19:58:29	0|luke-jr|5 is fine
283 2018-06-14 19:58:32	0|wumpus|cfields: yes, that's worrying
284 2018-06-14 19:58:38	0|luke-jr|IIRC threshold was 3 anyway
285 2018-06-14 19:58:50	0|wumpus|meeting ending in 1 minute
286 2018-06-14 19:58:53	0|wumpus|oh no, now
287 2018-06-14 19:58:56	0|lightningbot|Meeting ended Thu Jun 14 20:00:09 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
288 2018-06-14 19:58:56	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-14-19.00.html
289 2018-06-14 19:58:56	0|wumpus|#endmeeting
290 2018-06-14 19:58:57	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-14-19.00.log.html
291 2018-06-14 19:58:57	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-14-19.00.txt
292 2018-06-14 20:00:50	0|jamesob|maybe not meeting-worthy, but something I've been curious about is whether there are other indexes people'd like to see (now that we have this nice framework for building them)
293 2018-06-14 20:01:10	0|jamesob|I was thinking address-to-related-txns might be nice
294 2018-06-14 20:01:20	0|luke-jr|AFAIK the goal was to move indexes out of Core
295 2018-06-14 20:01:43	0|jamesob|I think in some cases there can be a compelling argument for additional opt-in indexes
296 2018-06-14 20:02:08	0|jonasschnelli|jamesob: I also started an experimental external indexing daemon: https://github.com/jonasschnelli/bitcoincore-indexd
297 2018-06-14 20:02:12	0|wumpus|at least the indexing functionality has been factored to a generic class now
298 2018-06-14 20:02:46	0|jamesob|jonasschnelli: cool, I'll take a look
299 2018-06-14 20:03:07	0|jonasschnelli|jamesob: I tried to build an address-to-related-txns,... but figured out its a source for general evil things like "central validation". :)
300 2018-06-14 20:03:31	0|jamesob|hah
301 2018-06-14 20:04:10	0|jonasschnelli|I think using the wallet more for "selective indexing" makes more sense.
302 2018-06-14 20:04:35	0|jonasschnelli|But IMO an address-to-related-txns is probably better kept external...
303 2018-06-14 20:05:18	0|jamesob|it'd be nice to, e.g., back trezor's web interface with your own bitcoind node instead of a bitcore instance and afaik part of that is because bitcore maintains indexes that bitcoind doesn't
304 2018-06-14 20:05:41	0|jonasschnelli|I understand this use case... but indexing everything for this is just silly..
305 2018-06-14 20:05:54	0|jonasschnelli|You only want to index a certain xpub or range of keys
306 2018-06-14 20:06:20	0|jamesob|yeah, makes sense
307 2018-06-14 20:06:36	0|jonasschnelli|The only use case is probably if you want to recover a backup...
308 2018-06-14 20:06:53	0|jonasschnelli|But even for that, my new scantxoutset PR makes more sense and works also with pruned peers...
309 2018-06-14 20:07:08	0|jonasschnelli|it just can't reproduce the transaction history,... just recover the funds.
310 2018-06-14 20:07:47	0|jonasschnelli|For bitcore / Trezor,... I'm pretty sure one can do the same thing belcher did with stratum (his personal electrum server)
311 2018-06-14 20:08:05	0|jonasschnelli|Create a bitcoin interface where only a defined set of keys (or xpubs) are indexed.
312 2018-06-14 20:08:15	0|jonasschnelli|In the background, you could use a watch-only core wallet for this...
313 2018-06-14 20:08:30	0|jonasschnelli|If you don't need backup-recovery, it would work with pruned peers as well
314 2018-06-14 20:09:15	0|gmaxwell|instagibbs: I don't think it would be hard to beat bitcoin core in terms of tx out cleanup.
315 2018-06-14 20:09:51	0|gmaxwell|For example, if it agressively spent all outputs to a scriptpubkey when it spent from any, it would likely sweep more txouts than the current code, AND improve privacy.
316 2018-06-14 20:12:21	0|jamesob|jonasschnelli: interesting, thanks
317 2018-06-14 20:12:55	0|instagibbs|gmaxwell, yeah yeah i meant within the constraints of the discussion, but agreed!
318 2018-06-14 20:15:28	0|gmaxwell|instagibbs: my thought on it was that we'd offset more txout prolific behavior with explicit txo consuming behavior.
319 2018-06-14 20:15:37	0|instagibbs|gotcha
320 2018-06-14 20:17:47	0|gmaxwell|the two kinds of extra consuming behavior I know of are (1) grouping by scriptpubkey (which helps privacy), (2) spending more small inputs when fees are low.
321 2018-06-14 20:27:48	0|sipa|gmaxwell: #12257
322 2018-06-14 20:27:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/12257 | [wallet] Use destination groups instead of coins in coin select by kallewoof · Pull Request #12257 · bitcoin/bitcoin · GitHub
323 2018-06-14 20:36:55	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #11604: [net] Remove ForNode/ForEachNode (06master...062017-11-no-foreachnode) 02https://github.com/bitcoin/bitcoin/pull/11604
324 2018-06-14 20:37:11	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #12138: Track best-possible-headers (06master...062017-10-best-header-tracking) 02https://github.com/bitcoin/bitcoin/pull/12138
325 2018-06-14 20:37:21	0|bitcoin-git|13bitcoin/06master 14fa3d39e 15MarcoFalke: doc: Remove note to install all boost dev packages
326 2018-06-14 20:37:21	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cc7cbd756acd...1939536eea7a
327 2018-06-14 20:37:22	0|bitcoin-git|13bitcoin/06master 141939536 15MarcoFalke: Merge #13460: doc: Remove note to install all boost dev packages...
328 2018-06-14 20:37:43	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #13233:  Skip PrecomputedTransactionData hashing for cache hits. (06master...062018-05-no-needless-precompute) 02https://github.com/bitcoin/bitcoin/pull/13233
329 2018-06-14 20:38:18	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13460: doc: Remove note to install all boost dev packages (06master...06Mf1806-docBuildUbuntu) 02https://github.com/bitcoin/bitcoin/pull/13460
330 2018-06-14 20:38:44	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #11775: Move fee estimator into validationinterface/cscheduler thread (06master...062017-09-background-feeest) 02https://github.com/bitcoin/bitcoin/pull/11775
331 2018-06-14 20:39:13	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #11856: [RFC] I Have a Hammer! (Replace parts of ui_interface with validationinterface) (06master...062017-12-remove-cvblockchange) 02https://github.com/bitcoin/bitcoin/pull/11856
332 2018-06-14 20:39:34	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #10984: Allow 2 simultaneous (compact-)block downloads (06master...062017-08-paralell-block-downloads) 02https://github.com/bitcoin/bitcoin/pull/10984
333 2018-06-14 20:39:50	0|BlueMatt|phew, now I dont have so many prs to rebase, and none that conflict with each other
334 2018-06-14 20:40:05	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #11913: Avoid cs_main during ReadBlockFromDisk Calls (06master...062017-12-no-readblockfromdisk-csmain) 02https://github.com/bitcoin/bitcoin/pull/11913
335 2018-06-14 20:47:17	0|wumpus|whoa
336 2018-06-14 20:47:32	0|BlueMatt|heh, havent had time to rebase anything in a while :(
337 2018-06-14 20:47:39	0|BlueMatt|maybe I'll get back to them in a few weeks or so
338 2018-06-14 20:47:59	0|promag|\o/ < 270 prs!
339 2018-06-14 20:49:00	0|sipa|MarcoFalke: feature request: in the conflict checker, if one PR is just a prefix of another one's commits, don't call it a conflict
340 2018-06-14 20:52:58	0|sipa|BlueMatt: :(
341 2018-06-14 20:53:07	0|sipa|BlueMatt: oh, some are still open
342 2018-06-14 20:54:14	0|BlueMatt|lol ffs, I was just closing stale crap I'm not gonna have a chance to rebase for a month
343 2018-06-14 20:54:18	0|BlueMatt|or, more likely, longer
344 2018-06-14 20:56:01	0|sipa|okay!
345 2018-06-14 21:05:39	0|bitcoin-git|[13bitcoin] 15Empact closed pull request #13462: scripted-diff: Simplify common case of CHashWriter and drop SER_GETHASH & SerializeHash (06master...06serialize-hash-type) 02https://github.com/bitcoin/bitcoin/pull/13462
346 2018-06-14 21:17:09	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #11639: Rewrite the interface between validation and net_processing wrt DoS (06master...062017-10-dos-rewrite) 02https://github.com/bitcoin/bitcoin/pull/11639
347 2018-06-14 21:23:12	0|cfields|gitian builders: v0.16.1 detached sigs are pushed
348 2018-06-14 21:23:15	0|cfields|achow101: ^^
349 2018-06-14 21:33:35	0|wumpus|thanks
350 2018-06-14 21:47:45	0|bitcoin-git|[13bitcoin] 15Empact reopened pull request #13462: scripted-diff: Simplify common case of CHashWriter and drop SER_GETHASH & SerializeHash (06master...06serialize-hash-type) 02https://github.com/bitcoin/bitcoin/pull/13462
351 2018-06-14 21:48:00	0|bitcoin-git|[13bitcoin] 15Empact closed pull request #13462: scripted-diff: Simplify common case of CHashWriter and drop SER_GETHASH & SerializeHash (06master...06serialize-hash-type) 02https://github.com/bitcoin/bitcoin/pull/13462