1 2017-01-12 00:44:28	0|gmaxwell|oh good, you can thumbs up your own comments on github.
  2 2017-01-12 00:44:35	0|gmaxwell|My life is now complete.
  3 2017-01-12 00:47:44	0|luke-jr|lol
  4 2017-01-12 00:58:04	0|midnightmagic|I love thumbs-upping my own posts. It aggravates some of the kinds of people I like aggravating. :-)
  5 2017-01-12 00:58:18	0|gmaxwell|sipa: thanks for the ack on #9484.
  6 2017-01-12 00:58:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
  7 2017-01-12 01:02:37	0|gmaxwell|jonasschnelli: did you ever get to producing the change that removes keys from the keypool when they're seen used on the network?
  8 2017-01-12 01:12:56	0|bitcoin-git|13bitcoin/06master 1454ee3fc 15Michael Rotarius: RPC help updated
  9 2017-01-12 01:12:56	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/05950427d310...0b738075bd43
 10 2017-01-12 01:12:57	0|bitcoin-git|13bitcoin/06master 140b73807 15MarcoFalke: Merge #9297: Various RPC help outputs updated...
 11 2017-01-12 01:13:10	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9297: Various RPC help outputs updated (06master...06rpchelp12/16) 02https://github.com/bitcoin/bitcoin/pull/9297
 12 2017-01-12 01:16:20	0|bitcoin-git|13bitcoin/06master 14faaf3ca 15MarcoFalke: travis: make distdir before make
 13 2017-01-12 01:16:20	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0b738075bd43...9ec1330b455c
 14 2017-01-12 01:16:21	0|bitcoin-git|13bitcoin/06master 149ec1330 15MarcoFalke: Merge #9416: travis: make distdir before make...
 15 2017-01-12 01:16:33	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9416: travis: make distdir before make (06master...06Mf1612-travisDistDirCheck) 02https://github.com/bitcoin/bitcoin/pull/9416
 16 2017-01-12 01:19:57	0|gmaxwell|I finally figured out why I wasn't getting any github emails.
 17 2017-01-12 01:21:30	0|midnightmagic|Whyzzat
 18 2017-01-12 01:26:25	0|gmaxwell|I configured an email rule to put them in another folder...
 19 2017-01-12 01:31:05	0|morcos|gmaxwell: that sucks..  i only get like half of github notifications as emails..  and i was less bothered by the fact that not only i was affected
 20 2017-01-12 01:31:44	0|gmaxwell|well I still may be only getting half.
 21 2017-01-12 01:32:19	0|gmaxwell|But I'm not getting none.
 22 2017-01-12 01:39:20	0|MarcoFalke|except: pass
 23 2017-01-12 01:39:26	0|MarcoFalke|why is this still a thing?
 24 2017-01-12 01:41:41	0|midnightmagic|haha
 25 2017-01-12 01:45:26	0|luke-jr|gmaxwell: why does #8775 need rebase? O.o
 26 2017-01-12 01:45:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
 27 2017-01-12 01:47:57	0|gmaxwell|why is that linking issues?
 28 2017-01-12 01:48:18	0|gmaxwell|luke-jr: ask git, not me, it doesn't apply cleanly to master.
 29 2017-01-12 01:48:30	0|gmaxwell|(git am -3 <patch> fails)
 30 2017-01-12 01:50:01	0|luke-jr|gmaxwell: I ask only because both git and github merge it cleanly :x
 31 2017-01-12 01:50:32	0|gmaxwell|gah whitespace errors
 32 2017-01-12 01:52:01	0|gmaxwell|MarcoFalke: does your git diff not show crazy whitespace as wads of red?
 33 2017-01-12 01:52:10	0|MarcoFalke|It does
 34 2017-01-12 01:52:28	0|gmaxwell|K. #9297 added big wads of end of line whitespace.
 35 2017-01-12 01:52:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/9297 | Various RPC help outputs updated by Mirobit · Pull Request #9297 · bitcoin/bitcoin · GitHub
 36 2017-01-12 01:52:36	0|gmaxwell|no biggie.
 37 2017-01-12 01:52:52	0|gmaxwell|Just wanted to make sure you could see it-- used to be that you had to configure it that way, but I think its a default now.
 38 2017-01-12 01:53:43	0|gmaxwell|fatal: sha1 information is lacking or useless (src/wallet/rpcdump.cpp).
 39 2017-01-12 01:53:43	0|gmaxwell|luke-jr: just catches fire here.
 40 2017-01-12 01:53:46	0|gmaxwell|error: could not build fake ancestor
 41 2017-01-12 01:53:49	0|gmaxwell|Patch failed at 0007 More tightly couple EnsureWalletIsAvailable with GetWalletForJSONRPCRequest where appropriate
 42 2017-01-12 01:54:32	0|MarcoFalke|At some point I feel we need to merge a pull. It can't be always free of µnits...
 43 2017-01-12 01:54:40	0|MarcoFalke|We have more pressing issues right now.
 44 2017-01-12 01:54:55	0|luke-jr|gmaxwell: what if you use git-merge? could you have an old branch?
 45 2017-01-12 01:55:13	0|MarcoFalke|But otoh I understand. Someone will fix it some day...
 46 2017-01-12 01:55:17	0|gmaxwell|luke-jr: that is in a current checkout vs the patch from github.
 47 2017-01-12 01:55:37	0|gmaxwell|MarcoFalke: I wasn't critizing, just making sure you could see it, so at least you were making the decision rather than just unaware. :)
 48 2017-01-12 01:56:01	0|MarcoFalke|ok
 49 2017-01-12 01:57:17	0|luke-jr|gmaxwell: looks specific to git-am. merging it normally works
 50 2017-01-12 01:59:48	0|gmaxwell|okay, well I'm not testing it unless it merges with git-am.
 51 2017-01-12 02:01:26	0|luke-jr|ok, rebased and seems to work now
 52 2017-01-12 02:02:51	0|gmaxwell|YUP!
 53 2017-01-12 02:02:54	0|gmaxwell|thanks.
 54 2017-01-12 02:21:37	0|fanquake|If anyone has some more info they could contribute to #8639, it would be appreciated. There's probably enough there now to turn it into some docs, but filling in a few more gaps would be handy. i.e minimum required openssl.
 55 2017-01-12 02:21:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/8639 | [Docs] Minimum required dependencies and current CVEs · Issue #8639 · bitcoin/bitcoin · GitHub
 56 2017-01-12 02:22:50	0|sipa|for non-qt we only need openssl for the PRNG
 57 2017-01-12 02:23:12	0|sipa|which i think means very old versions will work
 58 2017-01-12 02:23:24	0|sipa|not sure if we should suggest that, though
 59 2017-01-12 02:25:27	0|gmaxwell|and our use of it in the rng could darn near be replaced with rand()
 60 2017-01-12 02:25:48	0|fanquake|Should we be suggesting use of the 1.0.1 series at all if it's out of support? Or is that irrelevant here.
 61 2017-01-12 02:26:25	0|fanquake|We are currently using 1.0.1k in depends.
 62 2017-01-12 02:27:23	0|gmaxwell|fanquake: virtually every linux distribution is 1.0.x something, 1.1 changed the API in incompatible ways. We're compatible now, but it would be weird to suggest software that no one has.
 63 2017-01-12 02:28:09	0|MarcoFalke|How come that doxygen still has main.cpp?
 64 2017-01-12 02:28:11	0|MarcoFalke|https://dev.visucore.com/bitcoin/doxygen/main_8cpp_source.html
 65 2017-01-12 02:28:36	0|MarcoFalke|Generated on Wed Jan 11 2017
 66 2017-01-12 02:28:44	0|MarcoFalke|We killed that last year
 67 2017-01-12 02:29:32	0|fanquake|gmaxwell ok, thanks.
 68 2017-01-12 02:29:37	0|gmaxwell|MarcoFalke: whatever is generating it is on a forked repository?
 69 2017-01-12 02:30:22	0|achow101|apparently decoderawtransaction is not decoding segwit txs properly: https://bitcointalk.org/index.php?topic=1748353.msg17477509#msg17477509
 70 2017-01-12 02:30:51	0|MarcoFalke|^ wumpus can you take a look at doxygen, please?
 71 2017-01-12 02:38:05	0|gmaxwell|achow101: The issue is that segwit txn deseralizes as a 'crazy' non-segwit txn-- one with zero input transactions.
 72 2017-01-12 02:38:28	0|gmaxwell|achow101: the decodehex tries to decode as non-segwit first and then segwit, but that txn successfully decodes.
 73 2017-01-12 02:39:01	0|achow101|is that just bad luck then that it is able to successfully decode as non-segwit first?
 74 2017-01-12 02:39:33	0|gmaxwell|well could be bad luck or you could construct ones that way,  in the actual protocol sw and non-sw txn are handled distinctly not by trying to decode both ways.
 75 2017-01-12 02:39:57	0|gmaxwell|achow101: I believe that an acceptable solution is to just make that first try fail if the number of inputs is zero.  But this actually would reduce the functionality of raw transactions slightly, because passing around an inputless raw transaction isn't totally absurd.
 76 2017-01-12 02:40:05	0|gmaxwell|But I think that is likely the correct fix.
 77 2017-01-12 02:40:13	0|gmaxwell|or most correct.
 78 2017-01-12 02:40:20	0|sipa|didn't we fix that already?
 79 2017-01-12 02:40:40	0|gmaxwell|sipa: for decoderawtransactions?  my description is from reading the current code.
 80 2017-01-12 02:41:33	0|achow101|what use case is there for 0 input txns?
 81 2017-01-12 02:41:37	0|gmaxwell|an alternative would be to reverse the trial order, so it won't even try nonwit unless witness fails.
 82 2017-01-12 02:42:09	0|gmaxwell|achow101: I can use them as a payment request, for example... give you a txn with the outputs I want, leave it up to you to add inputs (and change, if required.)
 83 2017-01-12 02:42:25	0|sipa|raw transactions are more often used for unsigned transactions
 84 2017-01-12 02:42:33	0|sipa|which by definition aren't segwit
 85 2017-01-12 02:42:46	0|achow101|oh
 86 2017-01-12 02:43:09	0|sipa|once they're signed, they're usually complete
 87 2017-01-12 02:43:23	0|sipa|but it's unfortunate that there is ambiguity
 88 2017-01-12 02:43:49	0|sipa|we should propose some 'partially signed' transaction format
 89 2017-01-12 02:43:55	0|sipa|that's unambiguous
 90 2017-01-12 02:44:04	0|sipa|but has place for metadata etc
 91 2017-01-12 02:44:14	0|gmaxwell|well in particular, amounts and scriptpubkeys.
 92 2017-01-12 02:44:25	0|achow101|gmaxwell: what about having decoderawtx take a parameter to tell it to decode as segwit or non
 93 2017-01-12 02:44:45	0|gmaxwell|achow101: thats a bit ugly.
 94 2017-01-12 02:44:46	0|achow101|and have that somehow be related to soft fork activation
 95 2017-01-12 02:44:58	0|gmaxwell|achow101: thats more than a bit ugly. :P
 96 2017-01-12 02:47:15	0|sdaftuar|sipa: gmaxwell: does decoderawtransactions need to handle the 0 input case?  i remember discussing this for fundrawtransaction, where 0 inputs does make sense, but not obvious to me that decode should accept a 0-input tx?
 97 2017-01-12 02:47:57	0|gmaxwell|sdaftuar: sure, except for this bug.
 98 2017-01-12 02:48:01	0|gmaxwell|just shows now inputs.
 99 2017-01-12 02:48:19	0|gmaxwell|I suppose it being unwilling wouldn't be the end of the world.
100 2017-01-12 02:48:29	0|sipa|decoderawtransaction and fundraetransaction both attempt old and new deserialization
101 2017-01-12 02:48:34	0|gmaxwell|it's not like I could sign a zero input transaction.
102 2017-01-12 02:49:03	0|sipa|but they only accept the old serialization if it exactly matches the string
103 2017-01-12 02:49:14	0|sipa|(no undecoded garbage at the end)
104 2017-01-12 02:49:40	0|gmaxwell|So I think it would be okay if decoderaw would not decode zero input.   But fundraw needs to read zero input, and this transaction example decodes both ways.
105 2017-01-12 02:53:49	0|achow101|changing decodehextx in core_read.cpp will also affect sendrawtx. but that shouldn't be an issue since a 0 input tx isn't valid
106 2017-01-12 02:54:39	0|sipa|decodehextx gets a bool arg
107 2017-01-12 02:54:57	0|sipa|to indicate if non-extended format decoding should be attempted
108 2017-01-12 02:55:08	0|sipa|only decoderawtx and fundrawtx set that bool to true
109 2017-01-12 02:55:14	0|gmaxwell|that should be false for sendraw.
110 2017-01-12 02:55:22	0|sipa|it iz
111 2017-01-12 02:55:24	0|sipa|it is
112 2017-01-12 02:55:31	0|gmaxwell|iz was okay too.
113 2017-01-12 02:56:01	0|sipa|i zhall rezord do uzing voized vowelz vrom now on
114 2017-01-12 02:56:17	0|gmaxwell|oh dear.
115 2017-01-12 03:00:32	0|sdaftuar|gmaxwell: in #8456, we can replace a bumped transaction, so i don't think we should always mark the replacement as non-replaceable.  i agree with your second reason for wanting the ability though.
116 2017-01-12 03:00:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
117 2017-01-12 03:00:42	0|sdaftuar|bumper* transaction
118 2017-01-12 03:03:42	0|morcos|i think it would make the most sense to have the replacement tx inherit -walletrbf setting , but also add an option to explicitly set it...
119 2017-01-12 03:04:42	0|morcos|we never settled on a way to do that, but now with usings the options argument or named arguments to rpc, its easy enough to just add an rbfflag option to sendtoaddress, sendtomany, and bumpfee
120 2017-01-12 03:06:09	0|morcos|i suppose for starters having it inherit the -walletrbf setting is a very minor change and allows you to do anything you want if you're willing to restart your node
121 2017-01-12 03:06:30	0|sdaftuar|seems reasonable to me
122 2017-01-12 03:08:23	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #9522: [RPC] Fix decoderawtransaction decoding of segwit txs (06master...06fix-decoderawtx) 02https://github.com/bitcoin/bitcoin/pull/9522
123 2017-01-12 03:11:15	0|sipa|achow101: the bool arg to decodehextx should probably be changed to being an enum, with extended_only, prefer_extended, prefer_normal
124 2017-01-12 03:11:50	0|sipa|instead of basing it on hex bytes
125 2017-01-12 03:13:36	0|achow101|it would still have to be based on the hex bytes to know when each one should be done though
126 2017-01-12 03:13:56	0|sipa|no
127 2017-01-12 03:14:11	0|sipa|you've just implemented a "prefer extended" stratwgy
128 2017-01-12 03:15:52	0|achow101|but then how do you know which strategy to choose?
129 2017-01-12 03:16:13	0|sipa|decoderawtransaction would use prefer extended
130 2017-01-12 03:16:29	0|sipa|fundrawtransaction would use prefer olf
131 2017-01-12 03:16:37	0|sipa|all the rest would be extended only
132 2017-01-12 03:16:46	0|achow101|oh.
133 2017-01-12 03:16:51	0|sipa|that's what you have implemented now
134 2017-01-12 03:17:00	0|achow101|I see
135 2017-01-12 03:20:22	0|achow101|I can make that change
136 2017-01-12 03:27:45	0|sipa|actually
137 2017-01-12 03:28:07	0|sipa|what if you just pass false to decodehextx in decoderawtransaction?
138 2017-01-12 03:28:19	0|sipa|i believe the behavior will be the same as what you have now
139 2017-01-12 03:29:04	0|achow101|then it will be decoding all transactions as extended
140 2017-01-12 03:30:33	0|sipa|yes
141 2017-01-12 03:30:45	0|sipa|that's what you want, no?
142 2017-01-12 03:31:25	0|sipa|the extended format for transactions without witness is identical to the old format
143 2017-01-12 03:31:49	0|achow101|right
144 2017-01-12 03:31:55	0|achow101|yes, that should work.
145 2017-01-12 03:32:57	0|achow101|why was it passing in true originally then?
146 2017-01-12 03:33:45	0|sipa|to pick old decoding in case it was ambiguous
147 2017-01-12 03:34:09	0|sipa|which is what you want for fundrawtransaction
148 2017-01-12 03:34:18	0|sipa|but perhaps not for decoderawtransaction
149 2017-01-12 03:34:35	0|sipa|i'm not sure, it's choosing between two suboptimal options
150 2017-01-12 03:46:05	0|ZhibiaoPan|https://www.blocktrail.com/tBTC/tx/042e9225966258ec7d133d90a978d21ef1d7e4edc4800331a80f73f2d71316d8
151 2017-01-12 03:46:17	0|ZhibiaoPan|Mining Fee is -1.40625000 tBTC
152 2017-01-12 03:46:56	0|adiabat|ZhibiaoPan ... it's a coinbase tx
153 2017-01-12 03:47:13	0|ZhibiaoPan|CheckBlock() didn't check the block reward and mining fee?
154 2017-01-12 03:47:43	0|achow101|the output of a coinbase can be less than the reward that the miner is entitled to
155 2017-01-12 03:47:56	0|achow101|those coins are then just permanently missing
156 2017-01-12 04:09:09	0|wumpus|marcofalke: good catch, the script that is supposed to update it was not able to fetch the repo
157 2017-01-12 05:03:19	0|btcdrak|ZhibiaoPan: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1876-L1881
158 2017-01-12 05:20:09	0|BlueMatt|cfields: hum, I owe you an apology - I dont think that issue is gonna go away by changing the threading stuff - I think the "unlock cs_main prior to ActivateBestChain" stuff is going to have to stay because it is the only way to let things which will be quick but need to check something against cs_main and want to run on NewPoW... run
159 2017-01-12 05:20:56	0|BlueMatt|I fixed your specific complaint (the read-block-from-disk one) by simply using the most_recent_block shared_ptr that was already lying around, but I get that thats not really a fix for your general comment of adding complexity
160 2017-01-12 05:22:34	0|cfields|BlueMatt: yea, i almost suggested that, but it would just kinda mask the issue (usually)
161 2017-01-12 05:22:50	0|cfields|BlueMatt: to be clear, i'm not worried about the disk access _at all_
162 2017-01-12 05:22:55	0|BlueMatt|I know
163 2017-01-12 05:23:01	0|BlueMatt|I am, though, so thanks for reporting :p
164 2017-01-12 05:23:05	0|cfields|heh
165 2017-01-12 05:23:05	0|cfields|was just using it as an example
166 2017-01-12 05:23:10	0|BlueMatt|i mean it fixes your specific issue, but I'm really not a fan of the BlockUntilBlockIsWhereIWant in the net code
167 2017-01-12 05:23:12	0|BlueMatt|I know, I know
168 2017-01-12 05:23:40	0|cfields|BlueMatt: well if you're not a fan of that, certainly you're not a fan of ActivateBestChain there either :)
169 2017-01-12 05:24:05	0|BlueMatt|no, I'm specifically not a fan of BlockOnThing() over DoTheThingIWantToBlockOn()
170 2017-01-12 05:24:23	0|cfields|i see
171 2017-01-12 05:24:26	0|BlueMatt|wellllll, hum
172 2017-01-12 05:24:29	0|BlueMatt|now that i say that
173 2017-01-12 05:25:15	0|cfields|no, you're not doing anything in either action. Either way it's being treated as a fence.
174 2017-01-12 05:25:40	0|BlueMatt|well we need a fence primitive for wallet to fix #9148
175 2017-01-12 05:25:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
176 2017-01-12 05:25:56	0|cfields|er, "not doing anything" is a very poor choice of words, that's obviously not what i meant
177 2017-01-12 05:26:43	0|BlueMatt|I mean I feel kinda yucky doing this because what if some braindead caller calls AcceptBlock without ActivateBestChain?
178 2017-01-12 05:26:52	0|BlueMatt|we then call the fence and freeze forever
179 2017-01-12 05:26:54	0|BlueMatt|is my concern
180 2017-01-12 05:27:29	0|BlueMatt|same applies for wallet, though....
181 2017-01-12 05:27:46	0|BlueMatt|hence my comment on prefering FenceButFeelFreeToDoWorkToGetThere
182 2017-01-12 05:27:52	0|BlueMatt|which is what ABC is to me, here, i guess
183 2017-01-12 05:27:55	0|cfields|BlueMatt: i was just picturing: at the top of ABC, working=true. at the bottom, working=false
184 2017-01-12 05:28:03	0|cfields|nasty hack, but that's what you really want to know, right?
185 2017-01-12 05:28:16	0|BlueMatt|no, you'd need to do that in ProcessNewBlock
186 2017-01-12 05:29:21	0|cfields|not for your purposes, i think? It's ABC that would trigger the callback to push out the message, no?
187 2017-01-12 05:29:47	0|cfields|er, nm
188 2017-01-12 08:01:22	0|jonasschnelli|<*highlight>	[02:02:36] <gmaxwell:#bitcoin-core-dev> jonasschnelli: did you ever get to producing the change that removes keys from the keypool when they're seen used on the network?
189 2017-01-12 08:01:44	0|jonasschnelli|gmaxwell: No. Didn't started. I had in mind that you said you want to start with that... but I can try something...
190 2017-01-12 08:03:47	0|jonasschnelli|Oh. Github down?
191 2017-01-12 08:08:50	0|whphhg|Yup, seems so
192 2017-01-12 08:09:16	0|rabidus|yup
193 2017-01-12 09:54:02	0|bitcoin-git|13bitcoin/06master 14db904db 15Pieter Wuille: Deprecate non-txindex getrawtransaction and better warning
194 2017-01-12 09:54:02	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9ec1330b455c...2456a835f0bc
195 2017-01-12 09:54:03	0|bitcoin-git|13bitcoin/06master 142456a83 15MarcoFalke: Merge #9520: Deprecate non-txindex getrawtransaction and better warning...
196 2017-01-12 09:54:19	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9520: Deprecate non-txindex getrawtransaction and better warning (06master...06warntxindex) 02https://github.com/bitcoin/bitcoin/pull/9520
197 2017-01-12 10:16:30	0|MarcoFalke|Thanks for fixing doxygen, wumpus!
198 2017-01-12 10:38:42	0|MarcoFalke|What is the desired behavior of pruneblockchain(0)?
199 2017-01-12 10:51:59	0|bitcoin-git|13bitcoin/06master 14918d1fb 15Russell Yanofsky: Return height of last block pruned by pruneblockchain RPC...
200 2017-01-12 10:51:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2456a835f0bc...a65ced1a6657
201 2017-01-12 10:52:00	0|bitcoin-git|13bitcoin/06master 14a65ced1 15MarcoFalke: Merge #9518: Return height of last block pruned by pruneblockchain RPC...
202 2017-01-12 10:52:18	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9518: Return height of last block pruned by pruneblockchain RPC (06master...06pr/prune-height) 02https://github.com/bitcoin/bitcoin/pull/9518
203 2017-01-12 11:02:44	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9524: qa/rpc: Fix pruneblockchain edge cases (06master...06Mf1701-qaPruning) 02https://github.com/bitcoin/bitcoin/pull/9524
204 2017-01-12 11:03:56	0|MarcoFalke|We should probably just only allow a single code style with all known bad practices eliminated.
205 2017-01-12 11:06:25	0|MarcoFalke|python should stop interpreting when it sees smelly code and gcc should fail to compile.
206 2017-01-12 11:13:42	0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a65ced1a6657...fac0f30482d5
207 2017-01-12 11:13:43	0|bitcoin-git|13bitcoin/06master 143641141 15Pieter Wuille: Move tx estimation data out of CCheckPointData
208 2017-01-12 11:13:43	0|bitcoin-git|13bitcoin/06master 14a4bac66 15Pieter Wuille: [MOVEONLY] Move progress estimation out of checkpoints
209 2017-01-12 11:13:44	0|bitcoin-git|13bitcoin/06master 146dd8116 15Pieter Wuille: Remove SIGCHECK_VERIFICATION_FACTOR
210 2017-01-12 11:13:57	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9472: Disentangle progress estimation from checkpoints and update it (06master...06update_tx_estimation) 02https://github.com/bitcoin/bitcoin/pull/9472
211 2017-01-12 11:18:14	0|wumpus|MarcoFalke: continuing without crashing :-)
212 2017-01-12 11:25:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fac0f30482d5...d5d4ad87afbf
213 2017-01-12 11:25:02	0|bitcoin-git|13bitcoin/06master 141814b08 15Stanislas Marion: add p2sh and segwit options to bitcoin-tx outscript command
214 2017-01-12 11:25:02	0|bitcoin-git|13bitcoin/06master 1461a1534 15jnewbery: Add all transaction output types to bitcoin-tx....
215 2017-01-12 11:25:03	0|bitcoin-git|13bitcoin/06master 14b7e144b 15jnewbery: Add test cases to test new bitcoin-tx functionality...
216 2017-01-12 11:35:55	0|bitcoin-git|13bitcoin/06master 14dfbe0d5 15Alex Morcos: Add unstored orphans with rejected parents to recentRejects
217 2017-01-12 11:35:55	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d5d4ad87afbf...2742568a008e
218 2017-01-12 11:35:56	0|bitcoin-git|13bitcoin/06master 142742568 15Wladimir J. van der Laan: Merge #9261: Add unstored orphans with rejected parents to recentRejects...
219 2017-01-12 11:36:03	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9261: Add unstored orphans with rejected parents to recentRejects (06master...06orphanRejects) 02https://github.com/bitcoin/bitcoin/pull/9261
220 2017-01-12 11:46:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2742568a008e...f9117f204756
221 2017-01-12 11:46:51	0|bitcoin-git|13bitcoin/06master 144ed6faf 15fanquake: [depends] Boost 1.63.0
222 2017-01-12 11:46:51	0|bitcoin-git|13bitcoin/06master 148ac1830 15fanquake: [depends] Latest config.guess and config.sub
223 2017-01-12 11:46:52	0|bitcoin-git|13bitcoin/06master 146019d21 15fanquake: [depends] FreeType 2.7.1
224 2017-01-12 11:47:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9468: [Depends] Dependency updates for 0.14.0 (06master...06depends-update-014) 02https://github.com/bitcoin/bitcoin/pull/9468
225 2017-01-12 11:49:35	0|bitcoin-git|13bitcoin/06master 14453bda6 15Chris Moore: Add 'subtractFeeFromOutputs' option to 'fundrawtransaction'.
226 2017-01-12 11:49:35	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f9117f204756...7cb024eba68b
227 2017-01-12 11:49:36	0|bitcoin-git|13bitcoin/06master 147cb024e 15Wladimir J. van der Laan: Merge #9222: Add 'subtractFeeFromAmount' option to 'fundrawtransaction'....
228 2017-01-12 12:15:10	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9525: test: Include tx data in EXTRA_DIST (06master...06Mf1701-testINCLUDE) 02https://github.com/bitcoin/bitcoin/pull/9525
229 2017-01-12 12:16:00	0|MarcoFalke|going to cancel all travis instances
230 2017-01-12 12:24:03	0|fanquake|Let's get a few ACKs on #9525
231 2017-01-12 12:24:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/9525 | test: Include tx data in EXTRA_DIST by MarcoFalke · Pull Request #9525 · bitcoin/bitcoin · GitHub
232 2017-01-12 12:43:19	0|bitcoin-git|13bitcoin/06master 14fa29736 15MarcoFalke: test: Include tx data in EXTRA_DIST
233 2017-01-12 12:43:19	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7cb024eba68b...02e5308c1b9f
234 2017-01-12 12:43:20	0|bitcoin-git|13bitcoin/06master 1402e5308 15MarcoFalke: Merge #9525: test: Include tx data in EXTRA_DIST...
235 2017-01-12 12:43:39	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9525: test: Include tx data in EXTRA_DIST (06master...06Mf1701-testINCLUDE) 02https://github.com/bitcoin/bitcoin/pull/9525
236 2017-01-12 13:02:47	0|da2ce7|Just tested 'make deploy' from git-head on latest mac. Works without problem :)
237 2017-01-12 13:05:10	0|wumpus|great!
238 2017-01-12 13:09:18	0|fanquake|wumpus any objection to closing 7149 ?
239 2017-01-12 13:12:11	0|wumpus|fanquake: yeah I don't think it's going to be merged as it is
240 2017-01-12 13:17:40	0|fanquake|I might close a few older/inactive pull requests. Mentioning that they are of course free to reopen if they wish to restart/continue the work.
241 2017-01-12 13:17:40	0|fanquake|wumpus yea, open for > 1yr with only 2 comments.
242 2017-01-12 13:19:07	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #8339: Consensuslib: Block Verify / Transaction Verify [Do not merge, work in progress]  (06master...06blkconsensus) 02https://github.com/bitcoin/bitcoin/pull/8339
243 2017-01-12 13:23:25	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #7149: Bugfix: Correctly calculate priority when inputs are mined after dependent transactions enter the memory pool (06master...06bugfix_priority) 02https://github.com/bitcoin/bitcoin/pull/7149
244 2017-01-12 13:26:01	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #8488: Add deleteprivkey and forgetaddress RPC calls (06master...06forgetaddress-1) 02https://github.com/bitcoin/bitcoin/pull/8488
245 2017-01-12 13:29:37	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #8849: print P2WSH redeemScript in getrawtransaction if it s not a pubkey (06master...06print-p2wsh-redeemscript-in-getrawtransaction) 02https://github.com/bitcoin/bitcoin/pull/8849
246 2017-01-12 13:35:10	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9116: Allow getblocktemlate for not connected regtest node (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9116
247 2017-01-12 13:43:45	0|morcos|wumpus: is your concern with changing -walletrbf this close to 0.14 from a technical safety standpoint or more from a user/community awareness standpoint?
248 2017-01-12 13:44:02	0|wumpus|morcos: both, though mostly the latter
249 2017-01-12 13:44:32	0|wumpus|mostly that people get confused that they're suddenly creating a different kind of transactions with different properties
250 2017-01-12 13:44:38	0|wumpus|without having asked for it
251 2017-01-12 13:45:18	0|wumpus|of course it could be included in the release notes, but the planned release notes for 0.14 will already be huge :)
252 2017-01-12 13:45:24	0|morcos|ok, i agree that maybe it needs more forewarning...  but i do think that the problem we'll run into as is, is that people won't have changed the default, they'll have some "stuck" tx and want to bumpfee it and realize they can't
253 2017-01-12 13:45:49	0|fanquake|Yes I'm sure a few things are going to get lost in there already.
254 2017-01-12 13:46:09	0|morcos|so perhaps we should at least make it very clear in the release notes that if you're using a core to send your txs, that you need to change this default in order for bumpfee to be of any use to you
255 2017-01-12 13:46:25	0|wumpus|I think at least in the UI it would  e.g. make sense to add a question on the first transaction send after upgrade
256 2017-01-12 13:46:55	0|wumpus|yes
257 2017-01-12 13:47:10	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9064: unify capitalization of "bitcoin address" (06master...06changeCaps) 02https://github.com/bitcoin/bitcoin/pull/9064
258 2017-01-12 13:47:11	0|wumpus|anywhere bumpfee is mentioned it should be made clear
259 2017-01-12 13:48:40	0|wumpus|also in the RPC help for the funcition, thinking of it
260 2017-01-12 13:54:13	0|wumpus|in any case let's not make merging that functionality dependent on the defaults discussion
261 2017-01-12 13:54:51	0|morcos|sure agreed
262 2017-01-12 14:08:00	0|morcos|wumpus: suppose i want to add a new option such as rbfflag to an rpc call like sendtoaddress...  what is the right way to do that now we have named arguments?  1) add support for holes in sendtoaddress and 2) add a new argument in the last position for rbfflag ?
263 2017-01-12 14:08:31	0|wumpus|morcos: yes, that sounds like the right approach to me
264 2017-01-12 14:09:00	0|morcos|i guess i'm just trying to reconcile some rpc calls having an options argument like bumpfee and some not, so for bumpfee i wouldn't worry about and just add the rbfflag inside the options object?
265 2017-01-12 14:09:16	0|sipa|we should also make the rpc example code use named rgs
266 2017-01-12 14:09:21	0|sipa|*args
267 2017-01-12 14:09:42	0|sipa|and i wonder if we shouldn't first start converting some methods to natively accept names
268 2017-01-12 14:12:47	0|fanquake|Do we really need a nearly 1100 line script to check/maintain copyright headers
269 2017-01-12 14:17:28	0|wumpus|well right now named arugments are completely backwards compatible, and supporting holes also helps people that use positional arguments. It means they can specify 'null' to use the default.
270 2017-01-12 14:17:47	0|wumpus|so adding holes support to a RPC call is good in every way
271 2017-01-12 14:18:25	0|wumpus|fanquake: well as long as the guy maintains it it's fine I guess
272 2017-01-12 14:18:30	0|instagibbs|morcos, I'm up to 20% RTT saved now, syncing with your number
273 2017-01-12 14:20:26	0|fanquake|wumpus I guess. It just seems like something set to degrade. Checking sub-trees also seems like overkill.
274 2017-01-12 14:20:42	0|wumpus|fanquake: checking sub-trees is absolutely overkill
275 2017-01-12 14:20:48	0|fanquake|I'm not sure what the point of that is, as it's not like we're going to modify them also.
276 2017-01-12 14:20:56	0|wumpus|we don't merge any changes to those
277 2017-01-12 14:20:57	0|wumpus|right
278 2017-01-12 14:21:25	0|wumpus|but I suppose that comes by default - it's *avoiding* subtrees that requires extra logic. Or maybe I'm thinking of it wrong.
279 2017-01-12 14:21:53	0|fanquake|I thought you'd be able to just exclude all the files in the subtree dirs.
280 2017-01-12 14:22:15	0|wumpus|very possible - I don't know what he uses to query the list of files from git
281 2017-01-12 14:24:16	0|fanquake|I am starting to like the idea of adding other types of checking to Travis though. Some discussion in 9452
282 2017-01-12 14:26:14	0|fanquake|Just got to find the balance between not failing on every code change to the point that Travis is never green again, and picking up things like 9487.
283 2017-01-12 14:27:36	0|gmaxwell|Re walletrbf: I could see it going either way. We could write the release note for the bumpfee that just said you have to set walletrbf in advance for it to be useful.
284 2017-01-12 14:28:19	0|gmaxwell|Though I think we can't default to walletrbf unless we have a way to bump to non-rbf. Though I think that would be a trivial change to bumpfee.
285 2017-01-12 14:29:26	0|morcos|gmaxwell: what i said yesterday about using the default in bumpfee doesn't make sense
286 2017-01-12 14:29:45	0|morcos|i don't think you want to be changing the sequence numbers on the tx which may have other meaning unless you specifically indicate that you want to
287 2017-01-12 14:30:26	0|morcos|ryanofsky is going to add an option to bumpfee, and the only time you ever modify the sequence numbers is if the option tells you to specifically change it to not be rbf any more
288 2017-01-12 14:30:44	0|gmaxwell|thats okay with me.
289 2017-01-12 14:31:32	0|morcos|even that though sounds a bit risky to me
290 2017-01-12 14:32:01	0|morcos|what happens when you bump some transaction that was only valid because of its sequence numbers and CSV
291 2017-01-12 14:32:18	0|gmaxwell|well considering we can't sign for such a transaction currently...
292 2017-01-12 14:32:33	0|morcos|we can't?
293 2017-01-12 14:32:56	0|gmaxwell|no, if there is a OP_CSV signrawtransaction won't work, you'd need to be running modified software.
294 2017-01-12 14:33:43	0|Chris_Stewart_5|requires standardness?
295 2017-01-12 14:34:03	0|gmaxwell|jonasschnelli: sorry, darn, must have been a miscommunication. I was nagging before because I was saying I'd start on it if you weren't going to; but if you told me you weren't going to I either didn't get the message or forgot.
296 2017-01-12 14:34:34	0|jonasschnelli|gmaxwell: deadlock. :)
297 2017-01-12 14:35:05	0|jonasschnelli|Should I start to do something or do you want to work on the HD-keypool auto-jump?
298 2017-01-12 14:35:25	0|sipa|Chris_Stewart_5: no, the signing code just doesn't know how to produce a scriptSig for that
299 2017-01-12 14:35:38	0|gmaxwell|jonasschnelli: you should start because I'm going to be travling most of the day and don't know if I'll be productive (e.g. have power).
300 2017-01-12 14:35:56	0|gmaxwell|jonasschnelli: I think it will be simple (famous last words).
301 2017-01-12 14:36:11	0|jonasschnelli|gmaxwell: Okay. Let me try... but I can't start before tomorrow / friday. Not sure if I get something done before the freeze.
302 2017-01-12 14:36:20	0|jonasschnelli|gmaxwell: heh. Okay.
303 2017-01-12 14:37:36	0|Chris_Stewart_5|gotcha. Thanks.
304 2017-01-12 14:39:03	0|morcos|gmaxwell: damn.. i should have known that since i wrote the rpc test...  i put the stupid OP_CSV in the scriptSig to test it instead
305 2017-01-12 14:46:36	0|wumpus|fanquake: I'm not against adding checks to travis if they're strongly useful in preventing immediate problems. The only thing I'm sure about is that I don't want copyright header checks in there.
306 2017-01-12 14:47:13	0|fanquake|wumpus agreed.
307 2017-01-12 14:48:24	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #7823: Add index to wallet UTXO (06master...06enhancement/cache-unspent-outputs) 02https://github.com/bitcoin/bitcoin/pull/7823
308 2017-01-12 14:48:40	0|wumpus|the problem really is that travis only has two states (or three?) in any case it has no support for severity levels. This means that someone whose tests fails has to skip through screenfuls of logs to get to the place where the error happened. I wish it had a way to produce a summary instead
309 2017-01-12 14:49:35	0|fanquake|wumpus Yea I wish it just posted the error/log output in the GitHub comment bit.
310 2017-01-12 14:49:45	0|wumpus|well please not the entire thing
311 2017-01-12 14:49:59	0|wumpus|just a summary of points, say e.g. what build step failed and the error message
312 2017-01-12 14:50:04	0|fanquake|Yes not the whole lot, just the last 10 lines or so.
313 2017-01-12 14:50:45	0|fanquake|I should be minimized by default too.
314 2017-01-12 14:51:12	0|wumpus|any way to put a custom message in the comment bit would be great, we can handle the rest
315 2017-01-12 14:51:47	0|fanquake|Anything to save looking at 6 different sets of logs.
316 2017-01-12 14:55:15	0|fanquake|Also, are we still manually starting the builds of 7148
317 2017-01-12 14:55:59	0|fanquake|Just noticed Travis now has a Cron Job feature (beta), so maybe we could setup a branch for the extended test suite and have it run by the cron rather than manual trigger.
318 2017-01-12 15:31:42	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9527: Enable RBF transactions in wallet by default (06master...06pr/walletrbf) 02https://github.com/bitcoin/bitcoin/pull/9527
319 2017-01-12 15:49:31	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9528: [trivial] Rename formateNiceTimeOffset(qint64) to formatNiceTimeOffset(qint64) (06master...06rename-formateNiceTimeOffset) 02https://github.com/bitcoin/bitcoin/pull/9528
320 2017-01-12 15:50:27	0|gmaxwell|does the github api that travis uses allow comments or something? because the error being able to pass up a comment would be great.
321 2017-01-12 16:23:25	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9529: Bug fix: Update the instance variable self.lastDate (not the locally scoped variable lastDate) (06master...06fix-bug-in-BlockDataCopier) 02https://github.com/bitcoin/bitcoin/pull/9529
322 2017-01-12 17:10:04	0|luke-jr|any objections to rebasing #9422 ?
323 2017-01-12 17:10:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/9422 | Refactor mempool.dat to be extensible, and store missing info by luke-jr · Pull Request #9422 · bitcoin/bitcoin · GitHub
324 2017-01-12 17:27:11	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #9531: Release notes for estimation changes  (06master...06relnotes) 02https://github.com/bitcoin/bitcoin/pull/9531
325 2017-01-12 17:38:57	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9532: [trivial] Remove unused variables (06master...06remove-unused-variables) 02https://github.com/bitcoin/bitcoin/pull/9532
326 2017-01-12 17:55:03	0|btcdrak|luke-jr: go ahead
327 2017-01-12 18:17:18	0|sipa|i'll be travelling during part of the meeting
328 2017-01-12 18:22:02	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9533: Allow non-power-of-2 signature cache sizes (06master...06anysigcachesize) 02https://github.com/bitcoin/bitcoin/pull/9533
329 2017-01-12 18:57:00	0|BlueMatt|cfields: yea, dunno what to say, then, about your comment on #9375 - personally I like using ABC to be a barrier for best-chain-activated
330 2017-01-12 18:57:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
331 2017-01-12 18:58:20	0|cfields|BlueMatt: i'm reasonably convinced that it's harmless as-is, my only fear is that it leads to bugs in the future. Any thoughts on preventing future side-effects there?
332 2017-01-12 18:58:53	0|BlueMatt|I mean I tend to air on the side of it-shouldnt-have-side-effects just because thats how that function /should/ work
333 2017-01-12 18:58:55	0|BlueMatt|:/
334 2017-01-12 19:00:10	0|lightningbot|Meeting started Thu Jan 12 19:00:08 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
335 2017-01-12 19:00:10	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
336 2017-01-12 19:00:10	0|wumpus|#startmeeting
337 2017-01-12 19:00:19	0|jonasschnelli|hi
338 2017-01-12 19:00:39	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 instagibbs
339 2017-01-12 19:00:45	0|kanzure|hi.
340 2017-01-12 19:01:06	0|wumpus|proposed topics?
341 2017-01-12 19:01:22	0|btcdrak|hi
342 2017-01-12 19:01:26	0|michagogo|o/
343 2017-01-12 19:01:41	0|BlueMatt|0.14 freeze monday, so lock in prs that will go in now and finalize PR/issue tags for 0.14?
344 2017-01-12 19:01:44	0|jonasschnelli|gmaxwell mentioned yesterday that he's traveling.
345 2017-01-12 19:01:47	0|BlueMatt|feature freeze, of course
346 2017-01-12 19:01:48	0|jtimon|here
347 2017-01-12 19:01:51	0|wumpus|anyone working really hard on getting something in before the feature freeze?
348 2017-01-12 19:02:26	0|BlueMatt|my #9499 and #9375 plus cfields' #9441 are massive
349 2017-01-12 19:02:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/9499 | Use recent-rejects, orphans, and recently-replaced txn for compact-block-reconstruction by TheBlueMatt · Pull Request #9499 · bitcoin/bitcoin · GitHub
350 2017-01-12 19:02:30	0|BlueMatt|and probably close enough to make it
351 2017-01-12 19:02:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
352 2017-01-12 19:02:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
353 2017-01-12 19:02:33	0|luke-jr|would be nice to get multiwallet in, but it's mostly just waiting on review at this point. if we think we can get it in, I will rebase the final PR(s) as soon as the last pre-MW refactor is merged
354 2017-01-12 19:02:41	0|morcos|+1 BlueMatt's list
355 2017-01-12 19:02:52	0|luke-jr|(but IIRC from last meeting, there were more important things than MW that take precedence)
356 2017-01-12 19:03:00	0|cfields|wumpus: there's qt 5.7 which is probably worth having in.
357 2017-01-12 19:03:15	0|jonasschnelli|cfields: +1... whats missing? Can I help?
358 2017-01-12 19:03:29	0|wumpus|cfields: I don't understand the blocker there
359 2017-01-12 19:03:51	0|BlueMatt|luke-jr's multiwallet would have been nice, but we're at least two prs away...#8775 could probably be merged easily, but the one thereafter hasnt really gotten any review yet :(
360 2017-01-12 19:03:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
361 2017-01-12 19:04:01	0|wumpus|yes #9441 should be ready for merge really
362 2017-01-12 19:04:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
363 2017-01-12 19:04:42	0|btcdrak|+1 on multiwallet
364 2017-01-12 19:04:47	0|cfields|wumpus: i did some work on a bump+restructure a while back, and fanquake recently bumped but it's a bit broken. We just need to pull the fixes out of mine and into his. Should be quick/easy, it's just the building that takes a while
365 2017-01-12 19:04:52	0|BlueMatt|btcdrak: my point was I dont think thats gonna make it
366 2017-01-12 19:04:55	0|cfields|(re qt 7.1)
367 2017-01-12 19:04:59	0|cfields|er, 5.7. heh.
368 2017-01-12 19:05:06	0|BlueMatt|would have to turn out to get acks without any comments on the final multiwallet pr, I think
369 2017-01-12 19:05:17	0|BlueMatt|unless we decide we super want it and are willing to let it go in post-feature-freeze
370 2017-01-12 19:05:18	0|wumpus|forget about multwallet for 0.14
371 2017-01-12 19:05:41	0|jonasschnelli|Yes. It's probably to late
372 2017-01-12 19:05:47	0|BlueMatt|yup
373 2017-01-12 19:05:49	0|wumpus|it's a pity but let's just merge that stuff after the 0.14 split
374 2017-01-12 19:05:59	0|jonasschnelli|Yes. No hurry.
375 2017-01-12 19:06:04	0|wumpus|then it has ample time to be tested in master, which it needs
376 2017-01-12 19:06:18	0|cfields|jonasschnelli: happy to have help, sure. Let's discuss after meeting.
377 2017-01-12 19:06:23	0|jonasschnelli|ok
378 2017-01-12 19:06:25	0|wumpus|it's not something that is safe to merge last minute before a release and let people figure it out in a rc :)
379 2017-01-12 19:06:29	0|BlueMatt|havent looked at the diff, but I'd call #9519 a bugfix, so should go in post-monday
380 2017-01-12 19:06:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/9519 | Exclude RBF replacement txs from fee estimation by morcos · Pull Request #9519 · bitcoin/bitcoin · GitHub
381 2017-01-12 19:06:39	0|BlueMatt|morcos: should we tag that 0.14?
382 2017-01-12 19:06:45	0|luke-jr|ACK not doing MW in 0.14
383 2017-01-12 19:06:55	0|morcos|Yes I talked about it a while this morning with sdaftuar.  We should do it for 0.14
384 2017-01-12 19:07:13	0|morcos|It's a very minor change
385 2017-01-12 19:07:22	0|wumpus|yes bugfixes can be merged after the feature freeze, will tag it
386 2017-01-12 19:07:34	0|BlueMatt|#9512 is probably a 0.14 bugfix that should be tagged
387 2017-01-12 19:07:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub
388 2017-01-12 19:07:49	0|achow101|there's also the final alert stuff that's supposed to go in 0.14
389 2017-01-12 19:08:05	0|wumpus|#9512 a bugfix?
390 2017-01-12 19:08:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub
391 2017-01-12 19:08:25	0|morcos|I think we should merge #9380 for 0.14 as well, or at least the part that breaks out the -dustrelayfee
392 2017-01-12 19:08:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/9380 | Separate different uses of minimum fees by morcos · Pull Request #9380 · bitcoin/bitcoin · GitHub
393 2017-01-12 19:08:28	0|BlueMatt|wumpus: I mean I'd call code correctness bugfixes even if there are no bugs
394 2017-01-12 19:08:30	0|wumpus|I don't really like the perf hit
395 2017-01-12 19:08:40	0|BlueMatt|wumpus: assuming we can fix the performance hit?
396 2017-01-12 19:08:53	0|wumpus|normally I woudln't mind but hashing is very important to bitcoind performance
397 2017-01-12 19:09:09	0|sdaftuar|regarding 9512, sipa just told me (he's walking out the door) that he can make it a very slight performance improvement... but i guess he hasn't pushed that yet
398 2017-01-12 19:09:13	0|BlueMatt|I know gmaxwell wanted #9484 for 0.14, which I think it should be
399 2017-01-12 19:09:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
400 2017-01-12 19:09:33	0|wumpus|I had hoped to work on platform specific implementations for sha256, but anyhow, that won't make 0.14 and we shouldn't make the default implementation slower than necessary either
401 2017-01-12 19:09:54	0|BlueMatt|wumpus: ok, lets punt on 9512 for now, then
402 2017-01-12 19:09:59	0|BlueMatt|can decide later
403 2017-01-12 19:10:19	0|morcos|Can we discuss briefly the concept of dust being tied to minrelaytxfee
404 2017-01-12 19:10:25	0|wumpus|BlueMatt: yeah unless there's something that introduces an actual bug (I don't even understand all the change in it - e.g. asked about the change from LONG_MAX to 1<<40)
405 2017-01-12 19:10:35	0|BlueMatt|so things that need review before monday: 9484, 9499, 9375, 9441
406 2017-01-12 19:10:37	0|wumpus|morcos: sure, next topic
407 2017-01-12 19:10:42	0|sipa|wumpus: i'm running to catch a bus, but i believe i have a slightly faster-than-master but sanitize-correct version of ReadLE32 etc
408 2017-01-12 19:10:53	0|wumpus|#action review before monday : 9484, 9499, 9375, 9441
409 2017-01-12 19:10:57	0|wumpus|sipa: great!
410 2017-01-12 19:11:11	0|sipa|and by faster i mean 0.025%
411 2017-01-12 19:11:20	0|BlueMatt|heh
412 2017-01-12 19:11:28	0|morcos|I want to motivate why its important to consider #9380 as well.  At least one of the commits there has translation strings..  do we translate debug help?
413 2017-01-12 19:11:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/9380 | Separate different uses of minimum fees by morcos · Pull Request #9380 · bitcoin/bitcoin · GitHub
414 2017-01-12 19:11:37	0|wumpus|well "not slower" would be the goal so anything faster is doubly awesome
415 2017-01-12 19:11:39	0|BlueMatt|wumpus: wait, which PR was the LONG_MAX comment in reference to?
416 2017-01-12 19:12:10	0|wumpus|BlueMatt: #9512 IIRC
417 2017-01-12 19:12:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub
418 2017-01-12 19:12:31	0|BlueMatt|wumpus: ahh, yea, admittedly I havent read the code there yet, beyond very brief skimming
419 2017-01-12 19:12:42	0|BlueMatt|morcos: go ahead?
420 2017-01-12 19:12:42	0|cfields|yes, it's in the CScriptNum tests
421 2017-01-12 19:13:45	0|morcos|Sorry I was confused as to whether I was waiting for "topic:" or not..  Anyway.  The point is that right now if a miner changes the -minrelaytxfee, this already automatically changes their definition of dust.  This occasionally leads to txs with high feerates not being minable by some portion of miners
422 2017-01-12 19:13:46	0|wumpus|yes https://github.com/bitcoin/bitcoin/pull/9512/files#diff-2513c35abb5ab245137423db2d803628R17
423 2017-01-12 19:14:03	0|MarcoFalke|wumpus: Set topic for morcos?
424 2017-01-12 19:14:15	0|wumpus|morcos: oh yes forgot that - current topic is still what to do before the feature freeze
425 2017-01-12 19:14:31	0|wumpus|#topic  the concept of dust being tied to minrelaytxfee
426 2017-01-12 19:14:39	0|BlueMatt|morcos: ahh, ok, I'd call that a bugfix that we can do post-feature-freeze? but sounds like something that should be fixed
427 2017-01-12 19:14:47	0|BlueMatt|(I assume code is realatively trivial)
428 2017-01-12 19:14:54	0|morcos|BlueMatt: what about the transaltion strings
429 2017-01-12 19:15:20	0|BlueMatt|wumpus: ?
430 2017-01-12 19:15:20	0|MarcoFalke|morcos: Those are "hidden" features? So no translation string
431 2017-01-12 19:15:39	0|MarcoFalke|I'd recommend against exposing -dustfeerate
432 2017-01-12 19:15:46	0|MarcoFalke|to every user
433 2017-01-12 19:16:03	0|MarcoFalke|Maybe not even at all. Just make it a const in the code.
434 2017-01-12 19:16:14	0|wumpus|yes, translation freeze is at the same time as feature freeze
435 2017-01-12 19:16:20	0|morcos|MarcoFalke: ok, in that PR, -blockmintxfee was not hidden, specifically intended to be used by miners...  But yes -dustrelayfee is hidden.  And I agree, it shouldn't be changed by anyone.
436 2017-01-12 19:16:27	0|wumpus|but if it's a debug feature it won't have translation strings, ofc
437 2017-01-12 19:16:39	0|morcos|I suppose if we merge it too late, we can start with all features hidden and expose them next version
438 2017-01-12 19:17:04	0|BlueMatt|ehh, I'd say the diff is pretty trivial, lets just target it for monday?
439 2017-01-12 19:17:16	0|BlueMatt|(at the risk of piling on top of the other 4)
440 2017-01-12 19:17:25	0|morcos|Anyhway there are 2 potential problems:  1, a users txs are stuck for reasons they don't understand, but potentially more seriously it hurts fee estimation...
441 2017-01-12 19:18:14	0|morcos|I actually do agree with luke-jr that ideally fee estimation will be more robust to this...  but considering we dont' see much value in having different nodes have different definitions of dust.  It seems a no-brainer to fix that so it doesn't change anytime someone is trying to avoid spammy low-fee txs
442 2017-01-12 19:19:03	0|luke-jr|morcos: eh, is it based on your own fee, or the relay min fee? I thought the latter
443 2017-01-12 19:20:00	0|morcos|luke-jr: dust is based on minrelayfee, but people change minrelayfee to avoid spam or limit their mempool and inadvently change dust in teh process
444 2017-01-12 19:20:10	0|luke-jr|ah
445 2017-01-12 19:21:50	0|morcos|OK, I'm done..  Just wanted to be sure this was flagged before it was too late... seems like we could merge some version after feature freeze if we had to..  , anyway, someone please tag 9380 for 0.14 as well
446 2017-01-12 19:22:01	0|wumpus|ok
447 2017-01-12 19:22:10	0|BlueMatt|lets add it to the list for monday and if it slips thats ok
448 2017-01-12 19:22:21	0|BlueMatt|wumpus/sdaftuar/morcos should #8456 be un-tagged for 0.14? probably #8501 should be. I dont think we're gonna make #8654 or #8723 or #8755 either
449 2017-01-12 19:22:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
450 2017-01-12 19:22:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
451 2017-01-12 19:22:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/8654 | Reuse sighash computations across evaluation (rebase of #4562) by jl2012 · Pull Request #8654 · bitcoin/bitcoin · GitHub
452 2017-01-12 19:22:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub
453 2017-01-12 19:22:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/8755 | Implement excessive sighashing protection policy with tight sighash estimation by jl2012 · Pull Request #8755 · bitcoin/bitcoin · GitHub
454 2017-01-12 19:23:03	0|jonasschnelli|Yes. We should
455 2017-01-12 19:23:04	0|jl2012|yes, leave 8654 and 8755 for later
456 2017-01-12 19:23:05	0|BlueMatt|jonasschnelli: do you have a strong desire for #9294?
457 2017-01-12 19:23:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
458 2017-01-12 19:23:07	0|morcos|I think 8456 can make it...  The others maybe not
459 2017-01-12 19:23:21	0|jonasschnelli|Yes. 9294 must go in!
460 2017-01-12 19:23:31	0|BlueMatt|morcos: its kinda light on ACKs to get merged this weekend, no?
461 2017-01-12 19:23:33	0|jonasschnelli|Needs review. Has only a single utACK
462 2017-01-12 19:23:46	0|BlueMatt|jonasschnelli: looks like it needs rebase?
463 2017-01-12 19:23:51	0|jonasschnelli|We should also tag #9377
464 2017-01-12 19:23:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/9377 | fundrawtransaction: Keep change-output keys by default, make it optional by jonasschnelli · Pull Request #9377 · bitcoin/bitcoin · GitHub
465 2017-01-12 19:24:10	0|BlueMatt|grrr, this list is a bit long for 4 days incl a weekend...
466 2017-01-12 19:24:14	0|jonasschnelli|Oh. Yes. Needs rebase (since today)
467 2017-01-12 19:24:21	0|wumpus|agree on 8456 may still make it, I think the only discussion there is about the default value for walletrbf and that's unnecessary to decide there
468 2017-01-12 19:24:23	0|luke-jr|maybe we should split up the list between different people?
469 2017-01-12 19:24:31	0|wumpus|yes, it's not going to all make it
470 2017-01-12 19:24:35	0|luke-jr|we don't all have to review the same stuff
471 2017-01-12 19:24:38	0|wumpus|as I've said last week we should really make a choice
472 2017-01-12 19:24:45	0|wumpus|instead of trying to  cram everything in
473 2017-01-12 19:25:07	0|BlueMatt|luke-jr: we dont have enough reviewers for that to work well enough :(
474 2017-01-12 19:25:08	0|jonasschnelli|9377 is a bugfix and can go in later
475 2017-01-12 19:25:24	0|jonasschnelli|But please review 9294,.. is a sensitive wallet thing
476 2017-01-12 19:25:25	0|BlueMatt|and I think gmaxwell and sipa are on the road, plus I'm avoiding review at least until my cold is a bit better and I can think straight
477 2017-01-12 19:25:32	0|luke-jr|:<
478 2017-01-12 19:25:32	0|wumpus|especiall for the wallet it seems getting reviewers is really hard
479 2017-01-12 19:25:45	0|BlueMatt|yes :(
480 2017-01-12 19:25:46	0|bitcoin-git|[13bitcoin] 15losh11 opened pull request #9534: Statoshi (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9534
481 2017-01-12 19:26:07	0|bitcoin-git|[13bitcoin] 15losh11 closed pull request #9534: Statoshi (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9534
482 2017-01-12 19:26:16	0|cfields|that one's done!
483 2017-01-12 19:26:17	0|jtimon|I'm afraid I will prioritize the ones that are easier for me to review either way
484 2017-01-12 19:26:27	0|jonasschnelli|sure
485 2017-01-12 19:26:32	0|luke-jr|wallet needs the most review after consensus-critical changes, too
486 2017-01-12 19:27:18	0|jtimon|jonasschnelli: is the fact that 9377 is a bugfix a good reason to delay it?
487 2017-01-12 19:27:44	0|jonasschnelli|jtimon: delay,.. more priorize because of the freeze.
488 2017-01-12 19:27:55	0|BlueMatt|9377 needs rebase
489 2017-01-12 19:27:55	0|jonasschnelli|But 9377 fixes a address reuse problem ans should be in 0.14
490 2017-01-12 19:28:07	0|luke-jr|jonasschnelli: how important is it to get 9294 in 0.14 as opposed to 0.15? should I prioritise it over the other reviews?
491 2017-01-12 19:28:10	0|jonasschnelli|It somehow feels that all my PR needs rebase since today.
492 2017-01-12 19:28:22	0|BlueMatt|ok, 9377 looks like a bugfix that can go in after monday...looks like an easy diff too
493 2017-01-12 19:28:29	0|BlueMatt|can someone tag it?
494 2017-01-12 19:28:38	0|luke-jr|jonasschnelli: heh, I rebased something yesterday and had to re-rebase it again today XD
495 2017-01-12 19:28:40	0|jonasschnelli|9294 should be in 0.14 because we should avoid creating more single-chain HD wallets
496 2017-01-12 19:28:52	0|sipa|made it to the bus!
497 2017-01-12 19:29:04	0|luke-jr|jonasschnelli: can it upgrade single-chain HD wallets?
498 2017-01-12 19:29:08	0|jonasschnelli|No
499 2017-01-12 19:29:13	0|jonasschnelli|That's why it should be in 0.14
500 2017-01-12 19:29:27	0|luke-jr|is there a reason it cannot?
501 2017-01-12 19:29:40	0|jonasschnelli|You can't split the hd chains once you have created change outputs on the external chain...
502 2017-01-12 19:29:41	0|wumpus|jonasschnelli: that's a good point
503 2017-01-12 19:29:50	0|jonasschnelli|well... not with consequences.
504 2017-01-12 19:29:56	0|BlueMatt|sipa: yay!
505 2017-01-12 19:29:56	0|jonasschnelli|like re-seed
506 2017-01-12 19:30:00	0|morcos|and HD isn't released yet?
507 2017-01-12 19:30:05	0|jonasschnelli|it is.
508 2017-01-12 19:30:07	0|instagibbs|HD is already in 0.13
509 2017-01-12 19:30:08	0|jonasschnelli|Since 0.13
510 2017-01-12 19:30:08	0|wumpus|so from the wallet features we should focus on getting #9294 in
511 2017-01-12 19:30:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
512 2017-01-12 19:30:17	0|luke-jr|jonasschnelli: I don't understand why not. Maybe we should discuss this further after the meeting?
513 2017-01-12 19:30:23	0|morcos|Ok so its a matter of not makign it worse then
514 2017-01-12 19:30:27	0|wumpus|yes it is, but uses a single chain, which is inconvenient for reconstruction from a seed
515 2017-01-12 19:30:39	0|jonasschnelli|Yes.
516 2017-01-12 19:30:40	0|sipa|luke-jr: recovery from a seed won't correctly identify change
517 2017-01-12 19:30:46	0|sipa|that's all
518 2017-01-12 19:30:51	0|jonasschnelli|The change is not complex, but also not trivial
519 2017-01-12 19:31:14	0|sipa|are there other wallet related changes we want to see in 0.14
520 2017-01-12 19:31:16	0|sipa|?
521 2017-01-12 19:31:29	0|sipa|jonasschnelli: ?
522 2017-01-12 19:31:33	0|jonasschnelli|gmaxwell and I like to have the keypool detecting in 0.14
523 2017-01-12 19:31:40	0|jonasschnelli|But not sure if its too late
524 2017-01-12 19:31:43	0|luke-jr|what happens if I try to recover from a seed generated from a current HD wallet? ;)
525 2017-01-12 19:31:45	0|sipa|i think that is too laye
526 2017-01-12 19:31:53	0|jonasschnelli|Yes. It feels like
527 2017-01-12 19:31:54	0|jtimon|jonasschnelli: how #9294 works with #8723 ?
528 2017-01-12 19:31:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
529 2017-01-12 19:31:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub
530 2017-01-12 19:32:02	0|luke-jr|jonasschnelli: that's a bugfix IMO
531 2017-01-12 19:32:18	0|luke-jr|or potentially a bugfix, at least
532 2017-01-12 19:32:19	0|jonasschnelli|8723 has no reviews.
533 2017-01-12 19:32:23	0|jonasschnelli|To late for 0.14 IMO
534 2017-01-12 19:32:31	0|sdaftuar|jonasschnelli: can you remind us what keypool detecting is?
535 2017-01-12 19:32:42	0|jtimon|but have you thought about how they would combine?
536 2017-01-12 19:32:46	0|instagibbs|luke-jr, we have no direct recovery tools from seed AFAIK
537 2017-01-12 19:32:52	0|sipa|sdaftuar: the wallet marking keys as used once they are seen in a transaction
538 2017-01-12 19:32:55	0|jtimon|independently of which one goes first
539 2017-01-12 19:32:57	0|instagibbs|current flow is ~same as before
540 2017-01-12 19:32:57	0|luke-jr|instagibbs: but presumably we will be adding one
541 2017-01-12 19:32:59	0|jonasschnelli|sdaftuar: if you use an old backup... you want to autodetect keys already been used.
542 2017-01-12 19:33:09	0|instagibbs|luke-jr, indeed, which is why split will be important, right?
543 2017-01-12 19:33:24	0|sdaftuar|got it, thanks
544 2017-01-12 19:33:31	0|jonasschnelli|We need to check the keypool keys during SyncTransaction (each input/output) and mark the key as used when we have a match
545 2017-01-12 19:33:37	0|jonasschnelli|Otherwise you re-use keys.
546 2017-01-12 19:34:12	0|jonasschnelli|(if you don't topup your keypool +1000 and do a rescan before you use your old backup)
547 2017-01-12 19:34:12	0|luke-jr|instagibbs: perhaps. but nothing stops someone from recovering from a pre-split seed?
548 2017-01-12 19:35:06	0|jonasschnelli|luke-jr: yes. But we should at least stop creating wallets with change and normal-addresses on the same chain.
549 2017-01-12 19:35:33	0|luke-jr|jonasschnelli: not disputing that.
550 2017-01-12 19:35:49	0|jonasschnelli|Flexible keypath is nice.. but too late for 0.14.
551 2017-01-12 19:36:01	0|jonasschnelli|The sad thing is, it will be another feature that is not downward compatible.
552 2017-01-12 19:36:12	0|jonasschnelli|0.13 HD, 0.14 HD/split, 0.15 flex-keypath
553 2017-01-12 19:36:15	0|jonasschnelli|All not backward comp.
554 2017-01-12 19:36:28	0|sipa|meh.
555 2017-01-12 19:36:32	0|jonasschnelli|Yes. Meh.
556 2017-01-12 19:36:44	0|jonasschnelli|That's why I'd like combining the HD split with other stuff.
557 2017-01-12 19:36:45	0|luke-jr|surely at least HD/split can be upgraded to flex-keypath⁇
558 2017-01-12 19:36:55	0|sipa|breaking backward compatibility in major releases is fine
559 2017-01-12 19:37:26	0|instagibbs|Yeah why can't we upgrade to keypath?
560 2017-01-12 19:37:28	0|jonasschnelli|Okay.
561 2017-01-12 19:37:39	0|jonasschnelli|You can upgrade to keypath, but not downgrade
562 2017-01-12 19:37:50	0|jonasschnelli|Use a 0.15 wallet in 0.14 as an example
563 2017-01-12 19:37:58	0|jonasschnelli|But maybe its not so bad.
564 2017-01-12 19:38:00	0|luke-jr|upgrade-only is okay. we have -walletupgrade for that
565 2017-01-12 19:38:09	0|wumpus|don't you mean forwards compatible? backwards compatible means that it can use old wallets, which should always be possible
566 2017-01-12 19:38:30	0|jonasschnelli|wumpus: right. My fault.
567 2017-01-12 19:38:36	0|sipa|backward compatible means that old software can use new wallets
568 2017-01-12 19:38:43	0|wumpus|but being able to use  a new wallet with an old major version is not
569 2017-01-12 19:38:45	0|wumpus|huh?
570 2017-01-12 19:38:52	0|jonasschnelli|perspetive thing. :)
571 2017-01-12 19:38:56	0|wumpus|I thought the other way around.
572 2017-01-12 19:38:58	0|jonasschnelli|*perspective
573 2017-01-12 19:39:02	0|sipa|forward compatible is what you normally always have
574 2017-01-12 19:39:03	0|wumpus|I don't understand it anymore then
575 2017-01-12 19:39:34	0|instagibbs|wallet.dat vs Core wallet relativity...
576 2017-01-12 19:39:36	0|CodeShark|Walllet format vs. Wallet app
577 2017-01-12 19:39:36	0|sipa|oopz
578 2017-01-12 19:39:37	0|luke-jr|I think we have more cases than normal
579 2017-01-12 19:39:43	0|sipa|maybe i am wrong too
580 2017-01-12 19:39:45	0|jonasschnelli|Looking at the git history tells me, that we took good care about the fact that you can run a newer wallet on an older bitcoin-core version
581 2017-01-12 19:39:49	0|sipa|i will shut up
582 2017-01-12 19:39:57	0|jonasschnelli|And now we break that in 0.13, 0.14 and probably 0.15.
583 2017-01-12 19:40:09	0|jonasschnelli|But fine for me.
584 2017-01-12 19:40:15	0|instagibbs|jonasschnelli, OTOH, these are the kind of upgrades people desperately want...
585 2017-01-12 19:40:18	0|instagibbs|for future work
586 2017-01-12 19:40:20	0|wumpus|jonasschnelli: well in my opinion that doesn't matter too much. What is important is that if you open a wallet once with the new version you should still be able to downgrade
587 2017-01-12 19:40:23	0|luke-jr|jonasschnelli: there have been cases where -walletupgrade is needed, and then the wallet ceases to work in old versions
588 2017-01-12 19:40:24	0|CodeShark|wallet format is forward compatible, wallet app is backward compatible
589 2017-01-12 19:40:38	0|wumpus|jonasschnelli: however, new wallets created with new versions don't need to be open-able with old versions
590 2017-01-12 19:40:57	0|jonasschnelli|Okay. Seems that we all agree. Good.
591 2017-01-12 19:40:59	0|morcos|wumpus: +1 for those standards
592 2017-01-12 19:41:16	0|wumpus|we're just trying to avoid that *touching* a wallet with a new version automatically makes it incompatible, which would happen when upgrading berkeleydb for example
593 2017-01-12 19:41:26	0|jonasschnelli|Flexible keypath is nice. But we don't want to support BIP44 anyways thats why it's not urgent
594 2017-01-12 19:41:34	0|jtimon|all these backards and forwards compatibility is confusing, softfork and hardforks are much more clear :p
595 2017-01-12 19:41:45	0|petertodd|jtimon: +1
596 2017-01-12 19:41:46	0|luke-jr|we should also avoid making it incompatible unintentionally; only if -walletupgrade is enabled should we bump the feature requirements of a wallet
597 2017-01-12 19:41:53	0|luke-jr|jtimon: lol
598 2017-01-12 19:42:15	0|luke-jr|eg, if someone tries to use the flex-keypath, throw an error instead of upgrading the wallet (unless option is enabled0
599 2017-01-12 19:45:04	0|BlueMatt|ok, list for monday: 9380 (if it slips that ok, but prefer monday), net-related: 9441, 9375, 9499 (can someone tag 9499), 9486. wallet related: 9294, 8456 (are you sure that can make it sdaftuar/morcos?)
600 2017-01-12 19:45:23	0|BlueMatt|well, ok, 9486 is whatever, its trivial
601 2017-01-12 19:45:26	0|sdaftuar|BlueMatt: i think 8456 ought to be done, though it is true that gmaxwell keeps finding small issues
602 2017-01-12 19:45:38	0|CodeShark|Please no use of the terms "evil compatibility" or "backward-forward compatibility"
603 2017-01-12 19:45:52	0|BlueMatt|everything else tagged looks like a bugfix (#9490 is, right?)
604 2017-01-12 19:45:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/9490 | Replace FindLatestBefore used by importmuti with FindEarliestAtLeast. by gmaxwell · Pull Request #9490 · bitcoin/bitcoin · GitHub
605 2017-01-12 19:46:05	0|sdaftuar|yes that is a bugfix
606 2017-01-12 19:46:05	0|sipa|is #9484 on the list?
607 2017-01-12 19:46:07	0|BlueMatt|jonasschnelli: whats up with #9461?
608 2017-01-12 19:46:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
609 2017-01-12 19:46:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/9461 | [Qt] Improve progress display during headers-sync and peer-finding by jonasschnelli · Pull Request #9461 · bitcoin/bitcoin · GitHub
610 2017-01-12 19:46:11	0|jtimon|lol evil compatibility
611 2017-01-12 19:46:20	0|BlueMatt|sipa: oops, yes, add that to the list
612 2017-01-12 19:46:25	0|jonasschnelli|BlueMatt: simple change. Hope we can get it into 0.14
613 2017-01-12 19:46:29	0|jonasschnelli|Needs review
614 2017-01-12 19:46:31	0|BlueMatt|ok, list for monday: 9380 (if it slips that ok, but prefer monday), 9484, net-related: 9441, 9375, 9499 (can someone tag 9499), 9486. wallet related: 9294, 8456 (are you sure that can make it sdaftuar/morcos?)
615 2017-01-12 19:46:37	0|luke-jr|BlueMatt: do an `action` thing with the final list?
616 2017-01-12 19:46:50	0|instagibbs|someone with the meeting hammer has to do that i think
617 2017-01-12 19:47:03	0|luke-jr|O.o
618 2017-01-12 19:47:04	0|BlueMatt|that list is much too long :(
619 2017-01-12 19:47:08	0|wumpus|I've tagged 9499. Though we should stop tagging more stuff for monday.
620 2017-01-12 19:47:11	0|morcos|BlueMatt: nah... we can do all those
621 2017-01-12 19:47:15	0|BlueMatt|lol
622 2017-01-12 19:47:24	0|wumpus|we're not going to make the current list
623 2017-01-12 19:47:25	0|morcos|I think they are almost all ready for merge except perhaps 9294
624 2017-01-12 19:47:28	0|luke-jr|maybe we should sort the list by priority
625 2017-01-12 19:47:45	0|luke-jr|otherwise we're liable to work on opposite ones first and get none done
626 2017-01-12 19:47:49	0|BlueMatt|i dont think 8456 is gonna make that, either
627 2017-01-12 19:48:06	0|morcos|in 2 hours it'll have 2 ACK's, but if it doesn't make it, thats fine
628 2017-01-12 19:48:30	0|cfields|BlueMatt: what do you think about pulling out your net lock change from #9419 for inclusion? I've been assuming that would make it in in one way or another
629 2017-01-12 19:48:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub
630 2017-01-12 19:48:41	0|jonasschnelli|heh
631 2017-01-12 19:48:41	0|sipa|*morcos
632 2017-01-12 19:48:46	0|BlueMatt|wumpus: 9499 was deliberately written to be as easy to review as possible (for 0.14)...there are tons of things to make it better, but they were all left
633 2017-01-12 19:48:48	0|luke-jr|sipa: that'd violate github tos :P
634 2017-01-12 19:48:51	0|cfields|(it belongs in 9441, i just left it out because you already had one)
635 2017-01-12 19:49:04	0|jonasschnelli|luke-jr: depends how many kids you have
636 2017-01-12 19:49:10	0|BlueMatt|cfields: oh fuck I forgot about the cs_vSend split there
637 2017-01-12 19:49:16	0|jtimon|9380 seems easy to review, more about deciding what to expose now and what to leave for later
638 2017-01-12 19:49:26	0|BlueMatt|argh, well I can open it in its own pr, but that one's gonna be a rush if we want it
639 2017-01-12 19:49:30	0|BlueMatt|it is a huge win, though :/
640 2017-01-12 19:49:39	0|luke-jr|jonasschnelli: account terms #1 You must be 13 years or older to use this Service.
641 2017-01-12 19:49:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
642 2017-01-12 19:49:45	0|luke-jr|…
643 2017-01-12 19:50:19	0|sipa|hah
644 2017-01-12 19:50:22	0|jonasschnelli|heh
645 2017-01-12 19:50:30	0|cfields|BlueMatt: indeed. I think it's quite simple, though
646 2017-01-12 19:51:39	0|jtimon|any other topics?
647 2017-01-12 19:51:42	0|jtimon|10 min
648 2017-01-12 19:52:06	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9535: Split CNode::cs_vSend: message processing and message sending (06master...062017-01-cs-vsend-split) 02https://github.com/bitcoin/bitcoin/pull/9535
649 2017-01-12 19:52:45	0|cfields|BlueMatt: thanks. Will scrutinize.
650 2017-01-12 19:53:51	0|BlueMatt|wumpus: dont kill me, but ^ is kinda worth doing for monday :(
651 2017-01-12 19:54:11	0|wumpus|they're all worth doing, that's not the question
652 2017-01-12 19:54:15	0|luke-jr|it's not the end of the world if we don't have all optimisations in for 0.14 >_<K
653 2017-01-12 19:54:21	0|BlueMatt|true
654 2017-01-12 19:54:24	0|wumpus|agree luke-jr
655 2017-01-12 19:55:10	0|wumpus|let's leave something for 0.15
656 2017-01-12 19:55:21	0|BlueMatt|oh I've got lots for 0.15 already :p
657 2017-01-12 19:55:42	0|wumpus|of which at least half will probably miss 0.15 and only make it to 0.16 :)
658 2017-01-12 19:55:49	0|BlueMatt|oh yea
659 2017-01-12 19:55:51	0|BlueMatt|always do
660 2017-01-12 19:55:54	0|luke-jr|XD
661 2017-01-12 19:56:08	0|luke-jr|it's not like we have 3 years between releases ☺
662 2017-01-12 19:56:10	0|wumpus|that's how it goes, there's no other way if you have time based releases
663 2017-01-12 19:56:31	0|BlueMatt|anyway, so lets call the meeting?
664 2017-01-12 19:56:38	0|wumpus|and without a deadline we'd never agree what to put in a release and never again do a release
665 2017-01-12 19:56:39	0|luke-jr|what's the phone number?
666 2017-01-12 19:56:50	0|BlueMatt|wumpus: ooo, I vote for that one
667 2017-01-12 19:56:53	0|luke-jr|lol
668 2017-01-12 19:56:56	0|wumpus|yes, I think we're out of topics
669 2017-01-12 19:56:58	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.log.html
670 2017-01-12 19:56:58	0|lightningbot|Meeting ended Thu Jan 12 19:56:56 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
671 2017-01-12 19:56:58	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.html
672 2017-01-12 19:56:58	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.txt
673 2017-01-12 19:56:58	0|wumpus|#endmeeting
674 2017-01-12 19:57:06	0|BlueMatt|no more releases, just keep putting things in :)
675 2017-01-12 19:57:07	0|luke-jr|nobody did a #action with the PR list
676 2017-01-12 19:57:15	0|luke-jr|did anyone sort it?
677 2017-01-12 19:57:18	0|BlueMatt|ehh, whatever
678 2017-01-12 19:57:57	0|luke-jr|if nobody sorts it for me, I'm just going to review them in random order <.<
679 2017-01-12 19:58:56	0|jtimon|luke-jr: they're ordered by appearence in the link above ^
680 2017-01-12 19:59:46	0|BlueMatt|cfields: to finish our discussion from pre-meeting: I'm not sure what to do here...I dont think having a WaitForSync() barrier is sufficient, I can add lots of comments everywhere noting potential issues for reviewers to see on future prs?
681 2017-01-12 20:00:11	0|cfields|BlueMatt: deal.
682 2017-01-12 20:00:47	0|cfields|it'll get solved as part of parallel processing
683 2017-01-12 20:01:14	0|BlueMatt|not really?
684 2017-01-12 20:01:32	0|BlueMatt|i mean its not going away
685 2017-01-12 20:02:53	0|cfields|BlueMatt: i mean as part of SendMessages dissolving into more event-based sends
686 2017-01-12 20:03:05	0|BlueMatt|how does that fix this?
687 2017-01-12 20:04:19	0|cfields|BlueMatt: for ex, BlockChecked could unblock all sends waiting on full verification
688 2017-01-12 20:04:37	0|luke-jr|(FWIW, my prioritised list I will be using is: 9294, 8456, 9499, 9375, 8441, 9486, 9484, 9380)
689 2017-01-12 20:05:06	0|cfields|(not thought through, just an off-the-cuff approach)
690 2017-01-12 20:10:41	0|BlueMatt|cfields: yes, possibly
691 2017-01-12 20:12:30	0|instagibbs|luke-jr, 8441 is some merged thing from august..
692 2017-01-12 20:12:48	0|luke-jr|oops *goes to find what he meant to put there*
693 2017-01-12 20:13:14	0|cfields|luke-jr: 9441 i assume
694 2017-01-12 20:13:32	0|luke-jr|yep
695 2017-01-12 20:13:39	0|instagibbs|crisis averted
696 2017-01-12 20:15:43	0|BlueMatt|cfields: is that sufficient for #9375?
697 2017-01-12 20:15:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
698 2017-01-12 20:17:19	0|BlueMatt|sipa: want to ack #9375?
699 2017-01-12 20:17:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
700 2017-01-12 20:19:21	0|cfields|BlueMatt: that works, thanks
701 2017-01-12 20:20:51	0|sipa|wumpus: i wonder if you should choose randomized feature freeze dates, and not announce them in advance
702 2017-01-12 20:21:03	0|BlueMatt|lol
703 2017-01-12 20:21:05	0|BlueMatt|probably
704 2017-01-12 20:21:53	0|sipa|BlueMatt: going to look over 9375 again soon
705 2017-01-12 20:50:22	0|luke-jr|it kinda scares me that some failure cases of ReserveKeyFromKeyPool are non-obvious and requires explicit checking. would anyone mind if I made it throw an exception instead? jonasschnelli BlueMatt
706 2017-01-12 20:51:20	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9536: [trivial] Remove unused int64_t nSinceLastSeen (06master...06remove-unused-variable-nSinceLastSeen) 02https://github.com/bitcoin/bitcoin/pull/9536
707 2017-01-12 21:01:00	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #9536: [trivial] Remove unused int64_t nSinceLastSeen (06master...06remove-unused-variable-nSinceLastSeen) 02https://github.com/bitcoin/bitcoin/pull/9536
708 2017-01-12 21:11:56	0|BlueMatt|luke-jr: i havent looked at that code in a long time, happy to review a pr, though :;
709 2017-01-12 21:11:57	0|BlueMatt|:p
710 2017-01-12 21:20:45	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #9537: Wallet: Refactor ReserveKeyFromKeyPool for safety (06master...06refactor_wallet_RKFKP) 02https://github.com/bitcoin/bitcoin/pull/9537
711 2017-01-12 21:23:56	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9538: [trivial] Remove redundant call to get() on smart pointer (thread_specific_ptr) (06master...06remove-redundant-get-on-smartptr) 02https://github.com/bitcoin/bitcoin/pull/9538
712 2017-01-12 21:30:19	0|BlueMatt|cfields: sorry, found two more issues in 9441
713 2017-01-12 21:30:20	0|BlueMatt|:(
714 2017-01-12 21:30:30	0|cfields|BlueMatt: yep, looking them over now
715 2017-01-12 21:32:28	0|cfields|BlueMatt: iirc i was unhappy about the placement of setting fPauseSend, but left it alone for the sake of not being a moving target. happy to fix that.
716 2017-01-12 21:33:40	0|BlueMatt|well right now its technically wrong
717 2017-01-12 21:33:41	0|BlueMatt|soooo
718 2017-01-12 21:34:00	0|BlueMatt|if someone set a stupid low nSendBufferMaxSize it might actually be triggerable, though maybe not
719 2017-01-12 21:34:28	0|jeremyru1in|is there a good reason why validation.h should not include consensus/consensus.h?
720 2017-01-12 21:34:58	0|BlueMatt|no?
721 2017-01-12 21:35:51	0|jeremyru1in|(ok, was making some derived constants that belong in validation.h)
722 2017-01-12 21:41:32	0|instagibbs|morcos, what kind of performance boost does the caching give? (asking the obvious re:relay cmpct)
723 2017-01-12 21:42:34	0|morcos|the act of looping through your peers and announcing blocks to them is now much faster that the block is cached, as well as responding to getdata's for the cmpctblock or blocktxn messages
724 2017-01-12 21:42:46	0|morcos|it greatly decreases the processing time for relay
725 2017-01-12 21:43:41	0|BlueMatt|massively so, in fact
726 2017-01-12 21:44:02	0|BlueMatt|luckily sipa's last round on 9375 was all pretty minor stuff
727 2017-01-12 21:56:32	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9539: [trivial] Avoid initialization to a value that is never read (06master...06avoid-initialization-to-a-value-that-is-never-read) 02https://github.com/bitcoin/bitcoin/pull/9539
728 2017-01-12 22:00:26	0|cfields|BlueMatt: yep, you're right.
729 2017-01-12 22:06:21	0|cfields|lol, "git commit --amen" worked
730 2017-01-12 22:06:24	0|cfields|praise be.
731 2017-01-12 22:06:37	0|BlueMatt|wut
732 2017-01-12 22:06:58	0|cfields|typo'd 'git commit --amend'
733 2017-01-12 22:07:05	0|BlueMatt|lol, someone left that in as a easteregg
734 2017-01-12 22:07:07	0|BlueMatt|not in man-page
735 2017-01-12 22:07:10	0|gmaxwell|yep, git commit --amen works.
736 2017-01-12 22:07:17	0|BlueMatt|someone go file a bug and ruin their fun :P
737 2017-01-12 22:07:29	0|BlueMatt|confirmed: easter egg works here too
738 2017-01-12 22:07:56	0|gmaxwell|I don't know if its an easter egg or just 'shortest unambigious prefix is accepted for maximum forward incompatiblity'
739 2017-01-12 22:08:11	0|sdaftuar|cfields: in CConnMan::Interrupt(), why is there a lock protecting flagInterruptMsgProc?  it's an atmoic that doesn't seem to be protected by a lock anywhere else (unless i'm just badly confused about how all this works)
740 2017-01-12 22:08:16	0|cfields|seems to be that. --ame works too.
741 2017-01-12 22:08:17	0|BlueMatt|i could totally see git pulling shit like that :(
742 2017-01-12 22:08:24	0|BlueMatt|ffs
743 2017-01-12 22:09:34	0|sipa|BlueMatt, gmaxwell: pretty sure any unambiguous prefix is intentionally accepted
744 2017-01-12 22:09:58	0|sipa|sdaftuar: you need a lock for the condition variable anyway
745 2017-01-12 22:10:30	0|cfields|right, it's for the condvar
746 2017-01-12 22:11:11	0|cfields|sdaftuar: I was thinking the same thing as you. BlueMatt and i debated that. I lost hard.
747 2017-01-12 22:11:21	0|sdaftuar|but we release the lock before calling condMsgProc.notifyAll(), don't we?
748 2017-01-12 22:11:37	0|BlueMatt|sdaftuar: you cannot use a condvar without a lock.
749 2017-01-12 22:12:34	0|cfields|sdaftuar: need to lock regardless, may as well stick the wake condition in it. Notifying while locked would be a pessimism, though.
750 2017-01-12 22:13:08	0|BlueMatt|said lock has to be released after updating the wakeup condition, and either held during, or released before the wakeup call. (it can, optionally, be taken entirely after updating the wakeup condition)
751 2017-01-12 22:14:37	0|sdaftuar|if i understand right, we acquire lock, set the variable, release the lock, then do the notify_all() (which internally is acquiring and releasing as well)?
752 2017-01-12 22:15:03	0|sdaftuar|is that correct?
753 2017-01-12 22:15:08	0|BlueMatt|gmaxwell: my reasoning for requesting a month timeout on 9484 instead of a week was that if software were to be shipped with a bad hash I'd feel much better if it required the attacker create a month of blocks on top of the invalid one and stay ahead of the longest chain than only a week
754 2017-01-12 22:15:37	0|BlueMatt|sdaftuar: notify_all does not acquire or release a lock, or, it does not need to per the spec, it might very well internally
755 2017-01-12 22:15:54	0|BlueMatt|std::condition_variable_any definitely does
756 2017-01-12 22:17:33	0|sipa|sdaftuar: *waiting* on a condvar requires a lock
757 2017-01-12 22:17:46	0|sdaftuar|ok, i remain deeply puzzled, but i will worry about this when i'm at my desk again
758 2017-01-12 22:17:51	0|sipa|signalling can happen by anyone, anytime
759 2017-01-12 22:18:56	0|BlueMatt|sdaftuar: specifically, whie technically implementing the "unlock+wait is a single atomic action" will require a lock, it will require a lock that is intimately connected with the kernel's thread_waiting stuff in order to not have weird corner cases that are really non-performant
760 2017-01-12 22:19:24	0|gmaxwell|BlueMatt: anyone who can create more than a day of bad blocks is already reversing third party transations and stealing coins from arbritary people.
761 2017-01-12 22:19:48	0|BlueMatt|gmaxwell: I absolutely am confident you could easily get a massive chunk of the network hashpower for a day or two
762 2017-01-12 22:20:19	0|BlueMatt|I am much less confident you could hold it for a week...and if you give it time to reorg back to a valid chain a month makes me feel better :p
763 2017-01-12 22:20:46	0|gmaxwell|BlueMatt: great 7 days is 7 times a day.
764 2017-01-12 22:21:21	0|BlueMatt|if you have like 75% for two days, then it trails off for a few days as folks recover, you may end up staying ahead for a week or so
765 2017-01-12 22:22:16	0|gmaxwell|keep in mind this also requires the vendor to ship a bad hash, seriously, you're arguing against removing the feature.
766 2017-01-12 22:22:36	0|gmaxwell|the argument PT gave is that its harmless because the hash is much easier to audit/review than virtually any of the other code.
767 2017-01-12 22:22:49	0|BlueMatt|huh? I mean if a month is a massive sync-time feature then I'm fine with leaving it, but I dont think it is?
768 2017-01-12 22:23:52	0|BlueMatt|I could absolutely see the hash getting changed in the middle of an rc, everyone saying "meh, i guess thats ok", building happening, and then it getting discovered mid-gitian-phase
769 2017-01-12 22:24:10	0|BlueMatt|belt-and-suspenders, yo
770 2017-01-12 22:24:33	0|BlueMatt|s/massive sync-time feature/massive sync-time difference/
771 2017-01-12 22:24:40	0|gmaxwell|on my laptop a month of blocks takes 2.25 hours to validate.
772 2017-01-12 22:25:03	0|gmaxwell|2017-01-12 13:15:11 UpdateTip: new best=000000000000000000733f6623fd1d5e1a227cb5bd4c66a08714847d0a3267b1 height=436828 version=0x20000000 log2_work=85.483019 tx=167130980 date='2016-11-01 00:30:58' progress=0.969406 cache=2810.3MiB(3802921tx)
773 2017-01-12 22:25:33	0|gmaxwell|2017-01-12 15:36:08 UpdateTip: new best=00000000000000000037811542c2ca670af372dd43555c4d2dcb69744ab899be height=441341 version=0x20000000 log2_work=85.614254 tx=175220623 date='2016-12-01 00:07:06' progress=0.982775 cache=2773.7MiB(3915896tx)
774 2017-01-12 22:25:45	0|BlueMatt|how long with -assumevalid?
775 2017-01-12 22:25:53	0|BlueMatt|(ie how much of that is non-sig-checking)
776 2017-01-12 22:27:00	0|BlueMatt|I mean even with -assumevalid we're gonna take an hour or five to sync on some machines like that...doing the spv-initial sync (especially with -assumevalid) is gonna be the savior if you want lightning-fast sync...I'm ok eating an extra 30 minutes or hour, especially if its not something thats gonna grow ad infinitum forever
777 2017-01-12 22:27:46	0|gmaxwell|^ thats with a 3GB db cache..  I think it's about 30 minutes for the same span with assume valid.
778 2017-01-12 22:28:33	0|gmaxwell|you're missing my point. If you earnestly believe that auditing the hash is harder then the software then you should believe that we MUST NOT ship this feature at all.
779 2017-01-12 22:28:35	0|BlueMatt|hilariously, setting it to a month is gonna mean constant performance for a month after release, as the chain grows on top of the assumevalid setting, whereas setting it to a week means it'll start growing again after a week :p
780 2017-01-12 22:30:08	0|luke-jr|auditing the hash is as trivial as running without it, no?
781 2017-01-12 22:30:31	0|BlueMatt|no, i get your point, but I also dont think we have enough people looking at code, plus there are how many instructions for "how to run a node" that people might figure out if it said "download from my server" but might not catch if it says "set assumevalid to this hash, it makes sync happen instantly"
782 2017-01-12 22:30:47	0|gmaxwell|luke-jr: yes and checking if that block is in your chain.
783 2017-01-12 22:30:51	0|BlueMatt|i mean the recommended method to audit the hash takes a day for many folks :p
784 2017-01-12 22:31:02	0|BlueMatt|while the recommended way to set the hash is right before release
785 2017-01-12 22:31:17	0|sipa|i'm fine with either a week or a month. </bikeshed>
786 2017-01-12 22:31:21	0|gmaxwell|BlueMatt: no, it's part of the procedure that happens at the start of RCs.
787 2017-01-12 22:32:40	0|gmaxwell|BlueMatt: the procedure is actually checking two things: that the release didn't introduce any consensus reguressions in previously validated blocks, and that the new hash is acceptable.  To only check the latter you need simply check that it's in your chain from a node not yet running that value. 2 seconds, and thats it.
788 2017-01-12 22:33:10	0|gmaxwell|The longer procedure is an omission in our current process that we should already be addressing due to the checkpoint skipping. (though I do a checkpointless resync of every release myself)
789 2017-01-12 22:33:15	0|BlueMatt|gmaxwell: look at it this way - shipping a massive footgun which we think might plausibly trigger without considering the entire bitcoin network worthless seems questionable, shipping a massive footgun which would likely only ever trigger if someone had persistent control of 60% of hashpower....maybe less so
790 2017-01-12 22:33:41	0|gmaxwell|If it is a massive footgun it must not be shipped.
791 2017-01-12 22:33:59	0|BlueMatt|if its a massive footgun that cant go off without bitcoin being completely broken I think thats fine :p
792 2017-01-12 22:34:10	0|BlueMatt|gmaxwell: how long does your sync take on your laptop start-to-finish with -assumevalid set to a week?
793 2017-01-12 22:34:18	0|sipa|i think the footgun (wth is that?) is minimal
794 2017-01-12 22:34:43	0|luke-jr|sipa: footgun is a gun designed for shooting one's own foot
795 2017-01-12 22:34:45	0|cfields|sipa: a device one uses to shoot one's self in the foot.
796 2017-01-12 22:34:48	0|TD-Linux|it's a footgun that only triggers when you've already lost your legs.
797 2017-01-12 22:34:59	0|sipa|to exploit it, the attacker would need to have an invalid majority branch already mined at the time of software relwase
798 2017-01-12 22:35:04	0|BlueMatt|(if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw)
799 2017-01-12 22:35:48	0|sipa|or is the issue not the hardcoded value, but people convincing others to run with a certain settings value?
800 2017-01-12 22:35:53	0|gmaxwell|BlueMatt: with my large db cache, about 5 hours in a chainstate reindex. I can do more recent numbers later this week.
801 2017-01-12 22:36:08	0|luke-jr|sipa: or trick the user into configuring a majority invalid branch
802 2017-01-12 22:36:18	0|BlueMatt|so its 5 hours -> 7.5 hours if we set it to a month?
803 2017-01-12 22:36:30	0|BlueMatt|or 5 -> 7.25
804 2017-01-12 22:36:42	0|sipa|luke-jr: but they'd need to already have that invalid branch mined, and ahead by a week?
805 2017-01-12 22:36:58	0|gmaxwell|If I never stuck that check in none of you would have suggested it.
806 2017-01-12 22:37:03	0|BlueMatt|or, i guess 5 + (2.25/4) = 5.5 -> 7.25
807 2017-01-12 22:37:10	0|BlueMatt|gmaxwell: (if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw)
808 2017-01-12 22:37:16	0|jtimon|luke-jr: right, that's much better justification for the one week thing than the "artificially setting it 'too earlly' in releases" IMO
809 2017-01-12 22:37:17	0|gmaxwell|I think you're wrong.
810 2017-01-12 22:37:22	0|luke-jr|sipa: not necessarily
811 2017-01-12 22:37:25	0|BlueMatt|I'm not sure I would have suggested said check, but if weren't there I'd be saying uhhh, lets not
812 2017-01-12 22:37:30	0|luke-jr|ahead by a week, yes, but not already-mined
813 2017-01-12 22:37:53	0|sipa|BlueMatt: what specific attack scenario are you worried about?
814 2017-01-12 22:38:02	0|sipa|(honest question)
815 2017-01-12 22:38:20	0|gmaxwell|BlueMatt: (my blunt assumption is based on that you haven't been contributing to removing the existing checkpoints, no insult intended)
816 2017-01-12 22:39:11	0|BlueMatt|sipa: no, eg you start mining an invalid chain with your small hashpower, tell people to set the assumevalid setting in some blog post in russian that none of us see, when you find one guy who is gonna be your target, pwn a bunch of hahspower for a few days (I'm pretty confident you could get 75% for a few days, at least, if not more), and stay ahead for a week
817 2017-01-12 22:39:43	0|BlueMatt|its kinda weird, but definitely not impossible
818 2017-01-12 22:40:04	0|BlueMatt|gmaxwell: so, to confirm, it would take chain sync on your laptop from roughly 5.5 hours to 7.25 hours to set it to a month?
819 2017-01-12 22:40:07	0|sipa|BlueMatt: but the assumevalid setting value is only known after creating that branch
820 2017-01-12 22:40:21	0|gmaxwell|BlueMatt: I believe so.
821 2017-01-12 22:40:22	0|BlueMatt|gmaxwell: if thats the case, I might be convinced that a month is too long and we should go with 2 weeks
822 2017-01-12 22:40:45	0|BlueMatt|sipa: creating the start of the branch, not actually having to actively keep it up to sync all that well
823 2017-01-12 22:40:46	0|luke-jr|sipa: you'd make the transactions after your assumevalid all be valid
824 2017-01-12 22:41:00	0|BlueMatt|luke-jr: huh? no, you wouldnt
825 2017-01-12 22:41:06	0|luke-jr|BlueMatt: why not?
826 2017-01-12 22:41:16	0|BlueMatt|you would make all the txn before your assumevalid be valid
827 2017-01-12 22:41:17	0|BlueMatt|not after
828 2017-01-12 22:41:20	0|BlueMatt|well, and including, i think
829 2017-01-12 22:41:27	0|luke-jr|before it, they won't check if it's valid
830 2017-01-12 22:41:31	0|jtimon|BlueMatt: he means as an attacker
831 2017-01-12 22:41:33	0|luke-jr|so that's where you'd want to hide the invalid stuff
832 2017-01-12 22:41:44	0|BlueMatt|oh, i see your point, ok
833 2017-01-12 22:41:44	0|sipa|BlueMatt: if at any point your attacker branch is overtaken by the honest branch, assumevalid has no more effect
834 2017-01-12 22:42:08	0|BlueMatt|sipa: I'm aware, and I'm pretty confident you could manage to get an attack chain longer than the honest chain for a week
835 2017-01-12 22:42:18	0|BlueMatt|but maybe only like 5/6 days, and probably not much longer
836 2017-01-12 22:42:44	0|BlueMatt|eg start by pwning 75% of the network for 2 full days, then a tail while folks take a while to fix their shit
837 2017-01-12 22:43:21	0|BlueMatt|if you're really clever you'll pwn the pool servers, have some knowledge of where they'll fall back to, and be prepared to do a bgp attack against their (hopefully-less-bw-flood-intensive) fallback asn
838 2017-01-12 22:44:37	0|luke-jr|anyhow, this all requires getting the user to manually set the block hash
839 2017-01-12 22:44:45	0|luke-jr|IMO just hide it as a debug option and we're fixed
840 2017-01-12 22:44:51	0|BlueMatt|luke-jr: I think you missed part, above
841 2017-01-12 22:44:55	0|luke-jr|?
842 2017-01-12 22:46:13	0|BlueMatt|eg you're an attacker, you maintain a russian-language (or some other language none of us would find) blog on "how to set up a bitcoin node"...you keep some small amount of hashpower mining invalid chains based on the best chain all the time, so you always have some hash in your page that isnt too far back from the tip, maybe a few hours, you very actively monitor users and try to find when someone who is a real target uses it
843 2017-01-12 22:46:32	0|BlueMatt|then you reveal that you've pwned all the pool servers and start mining invalid garbage for a few days
844 2017-01-12 22:46:57	0|BlueMatt|its kinda a strange scenario, and seems pretty highly unlikely, but I do not believe it is impossible
845 2017-01-12 22:47:11	0|luke-jr|BlueMatt: how will your invalid chain get accepted?
846 2017-01-12 22:47:21	0|BlueMatt|it wont be accepted by anyone except your target?
847 2017-01-12 22:47:29	0|luke-jr|why would it be accepted by your target, though?
848 2017-01-12 22:47:37	0|luke-jr|he'd need to set the config option to your malicious block hash
849 2017-01-12 22:47:45	0|jtimon|huhm, what does mining invalid garbage on top of your fake invalid assumevalid give you?
850 2017-01-12 22:47:48	0|BlueMatt|because you got them to set the assumevalid setting?
851 2017-01-12 22:48:01	0|BlueMatt|luke-jr: yes, did you miss the part where they set up their bitcoin node based on your instructions?
852 2017-01-12 22:48:23	0|jtimon|right, the ate the invalid stuff belowe your fake assumevalid, but not above it
853 2017-01-12 22:48:50	0|jtimon|s/the/they s/belowe/below
854 2017-01-12 22:48:57	0|luke-jr|ok, so the user is an idiot who will set the option without investigating what it does
855 2017-01-12 22:49:06	0|BlueMatt|as luke pointed out, you could print (by stealing) on the assumevalid block, and then spend it to your victim in a later bnlock
856 2017-01-12 22:49:13	0|BlueMatt|luke-jr: most users do shit like that....
857 2017-01-12 22:49:16	0|luke-jr|what if we rename it to assumevalid_this_can_compromise_your_node?
858 2017-01-12 22:49:19	0|BlueMatt|luke-jr: fuck, many users use the ppa
859 2017-01-12 22:50:06	0|jtimon|Ok, so precisely this attack is what the 1 week thing serves for, no?
860 2017-01-12 22:50:08	0|luke-jr|can't blame them. using the PPA makes a lot of sense considering they already trust Canonical.
861 2017-01-12 22:50:31	0|BlueMatt|jtimon: my claim is that I'm not at all convinced you could not have a longer chain than the honest one for a week
862 2017-01-12 22:51:12	0|jtimon|BlueMatt: thus you propose to change it to 2 weeks ? (sorry, I should have read all the logs before intervening)
863 2017-01-12 22:51:13	0|BlueMatt|gmaxwell: does 2 weeks meet your performance target? its more like an extra half hour
864 2017-01-12 22:51:46	0|BlueMatt|jtimon: yes, I prefer a mont but gmaxwell pointed out that that increases sync time on his laptop with massive dbcache by something like 1.5 hours
865 2017-01-12 22:52:05	0|BlueMatt|which does seem like a big cost to pay
866 2017-01-12 22:52:18	0|jtimon|regarding the 5.5 vs 7.5 h benchmark, that's only for fresh releases or people setting the arg manually right before the limit, right?
867 2017-01-12 22:52:27	0|BlueMatt|yes
868 2017-01-12 22:52:36	0|BlueMatt|thats only if you sync within the first week of the release
869 2017-01-12 22:52:45	0|BlueMatt|well, first week after the hash was selected/set
870 2017-01-12 22:54:11	0|jtimon|I don't oppose changing it to 2 weeks, it's performance vs a more cautious protection against a possible attack
871 2017-01-12 22:57:12	0|jtimon|I mean, even with a month it's a great improvement over the checkpoint way
872 2017-01-12 22:58:16	0|BlueMatt|oh, totally I think we should do this, just prefer a tiny inch more conservatism
873 2017-01-12 22:58:38	0|cfields|BlueMatt: it seems a bit unrealistic to argue what time-period to pick in that scenario. Assuming I'm an attacker in the above conditions, I'd send the victim an "optimized binary that syncs the chain faster" (and it would, the wrong one :P) rather than trying to get them to fiddle with config settings.
874 2017-01-12 22:59:03	0|jtimon|and I'm happy with both 2 or 1 week, so I don't have anything to convince you about
875 2017-01-12 22:59:36	0|BlueMatt|cfields: given an assumevalid setting, I'm pretty sure it'll become common-enough practice to tell people to set it to make chainsync faster
876 2017-01-12 22:59:50	0|BlueMatt|whereas "download from this random site" might be a bit more alarming to folks
877 2017-01-12 23:00:21	0|jtimon|cfields: well, if you can send them an "evil binary" the whole assumevalid thing is irrelevant: you can change the rules!
878 2017-01-12 23:00:41	0|cfields|jtimon: that was exactly my point.
879 2017-01-12 23:00:49	0|jtimon|a bad bitcoin.conf seems more realistic
880 2017-01-12 23:00:51	0|BlueMatt|as for why a month instead of a week, well its about human-scale response to attacks....how long would it take for pools to escalate a large-scale hack against their infrastructure up to their hosting provider...what about if there's a bgp-based attack? how long for global NOCs to respond? etc
881 2017-01-12 23:01:15	0|jtimon|"here's my bitcoin.conf, copy it, it syncs super-fast"
882 2017-01-12 23:01:32	0|BlueMatt|then double because the honest chain has to catch back up
883 2017-01-12 23:03:06	0|cfields|jtimon: given the example above, undermining the majority of hashpower, surely getting them to run my binary is trivial in comparison
884 2017-01-12 23:04:06	0|BlueMatt|cfields: you massively underestimate how trivial it is to pwn most pool servers' hosting providers
885 2017-01-12 23:04:29	0|BlueMatt|also, remember that there is no auth on stratum
886 2017-01-12 23:05:27	0|BlueMatt|so even those who get off big centralized providers and host themselves for security will possibly get fucked due to mitm/bgp/etc/etc
887 2017-01-12 23:05:44	0|jtimon|cfields: maybe it's that I underestimate the loss of using 1 month instead of 1 week...
888 2017-01-12 23:08:21	0|cfields|BlueMatt: i'm not arguing with you about that. I'm arguing the relative ease of undermining your victim (who is already gullible enough to set assumevalid)
889 2017-01-12 23:09:24	0|BlueMatt|ehh, I'm not sure about that, though I absolutely agree the example attack given above is not the most robust example
890 2017-01-12 23:16:28	0|cfields|BlueMatt: updated 9441. Now going over 9375 one last time.