12017-01-12T00:16:38  *** cheese_ has quit IRC
   22017-01-12T00:29:56  *** JackH has quit IRC
   32017-01-12T00:42:20  *** MarcoFalke has joined #bitcoin-core-dev
   42017-01-12T00:44:26  <gmaxwell> oh good, you can thumbs up your own comments on github.
   52017-01-12T00:44:33  <gmaxwell> My life is now complete.
   62017-01-12T00:47:42  <luke-jr> lol
   72017-01-12T00:54:53  *** OfficialLeibniz is now known as officia||eibniz
   82017-01-12T00:57:28  *** Ylbam has quit IRC
   92017-01-12T00:58:02  <midnightmagic> I love thumbs-upping my own posts. It aggravates some of the kinds of people I like aggravating. :-)
  102017-01-12T00:58:16  <gmaxwell> sipa: thanks for the ack on #9484.
  112017-01-12T00:58:19  <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
  122017-01-12T01:00:14  *** abpa has quit IRC
  132017-01-12T01:02:36  <gmaxwell> jonasschnelli: did you ever get to producing the change that removes keys from the keypool when they're seen used on the network?
  142017-01-12T01:12:54  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/05950427d310...0b738075bd43
  152017-01-12T01:12:55  <bitcoin-git> bitcoin/master 54ee3fc Michael Rotarius: RPC help updated
  162017-01-12T01:12:55  <bitcoin-git> bitcoin/master 0b73807 MarcoFalke: Merge #9297: Various RPC help outputs updated...
  172017-01-12T01:13:08  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9297: Various RPC help outputs updated (master...rpchelp12/16) https://github.com/bitcoin/bitcoin/pull/9297
  182017-01-12T01:16:07  *** cbits has joined #bitcoin-core-dev
  192017-01-12T01:16:18  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b738075bd43...9ec1330b455c
  202017-01-12T01:16:18  <bitcoin-git> bitcoin/master faaf3ca MarcoFalke: travis: make distdir before make
  212017-01-12T01:16:19  <bitcoin-git> bitcoin/master 9ec1330 MarcoFalke: Merge #9416: travis: make distdir before make...
  222017-01-12T01:16:31  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9416: travis: make distdir before make (master...Mf1612-travisDistDirCheck) https://github.com/bitcoin/bitcoin/pull/9416
  232017-01-12T01:19:56  <gmaxwell> I finally figured out why I wasn't getting any github emails.
  242017-01-12T01:21:29  <midnightmagic> Whyzzat
  252017-01-12T01:26:23  <gmaxwell> I configured an email rule to put them in another folder...
  262017-01-12T01:27:02  *** d9b4bef9 has quit IRC
  272017-01-12T01:28:08  *** d9b4bef9 has joined #bitcoin-core-dev
  282017-01-12T01:31:03  <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
  292017-01-12T01:31:43  <gmaxwell> well I still may be only getting half.
  302017-01-12T01:32:17  <gmaxwell> But I'm not getting none.
  312017-01-12T01:39:18  <MarcoFalke> except: pass
  322017-01-12T01:39:25  <MarcoFalke> why is this still a thing?
  332017-01-12T01:41:40  <midnightmagic> haha
  342017-01-12T01:44:56  *** AaronvanW has quit IRC
  352017-01-12T01:45:25  <luke-jr> gmaxwell: why does #8775 need rebase? O.o
  362017-01-12T01:45:27  <gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
  372017-01-12T01:47:55  <gmaxwell> why is that linking issues?
  382017-01-12T01:48:04  *** cbits has quit IRC
  392017-01-12T01:48:16  <gmaxwell> luke-jr: ask git, not me, it doesn't apply cleanly to master.
  402017-01-12T01:48:29  <gmaxwell> (git am -3 <patch> fails)
  412017-01-12T01:49:59  <luke-jr> gmaxwell: I ask only because both git and github merge it cleanly :x
  422017-01-12T01:50:31  <gmaxwell> gah whitespace errors
  432017-01-12T01:51:59  <gmaxwell> MarcoFalke: does your git diff not show crazy whitespace as wads of red?
  442017-01-12T01:52:08  <MarcoFalke> It does
  452017-01-12T01:52:27  <gmaxwell> K. #9297 added big wads of end of line whitespace.
  462017-01-12T01:52:29  <gribble> https://github.com/bitcoin/bitcoin/issues/9297 | Various RPC help outputs updated by Mirobit · Pull Request #9297 · bitcoin/bitcoin · GitHub
  472017-01-12T01:52:35  <gmaxwell> no biggie.
  482017-01-12T01:52:51  <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.
  492017-01-12T01:53:41  <gmaxwell> luke-jr: just catches fire here.
  502017-01-12T01:53:41  <gmaxwell> fatal: sha1 information is lacking or useless (src/wallet/rpcdump.cpp).
  512017-01-12T01:53:45  <gmaxwell> error: could not build fake ancestor
  522017-01-12T01:53:47  <gmaxwell> Patch failed at 0007 More tightly couple EnsureWalletIsAvailable with GetWalletForJSONRPCRequest where appropriate
  532017-01-12T01:54:31  <MarcoFalke> At some point I feel we need to merge a pull. It can't be always free of µnits...
  542017-01-12T01:54:38  <MarcoFalke> We have more pressing issues right now.
  552017-01-12T01:54:53  <luke-jr> gmaxwell: what if you use git-merge? could you have an old branch?
  562017-01-12T01:55:12  <MarcoFalke> But otoh I understand. Someone will fix it some day...
  572017-01-12T01:55:16  <gmaxwell> luke-jr: that is in a current checkout vs the patch from github.
  582017-01-12T01:55:36  <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. :)
  592017-01-12T01:55:59  <MarcoFalke> ok
  602017-01-12T01:56:46  *** fanquake has joined #bitcoin-core-dev
  612017-01-12T01:57:15  <luke-jr> gmaxwell: looks specific to git-am. merging it normally works
  622017-01-12T01:59:46  <gmaxwell> okay, well I'm not testing it unless it merges with git-am.
  632017-01-12T02:01:25  <luke-jr> ok, rebased and seems to work now
  642017-01-12T02:02:50  <gmaxwell> YUP!
  652017-01-12T02:02:52  <gmaxwell> thanks.
  662017-01-12T02:08:23  *** cbits has joined #bitcoin-core-dev
  672017-01-12T02:11:40  *** xinxi has joined #bitcoin-core-dev
  682017-01-12T02:16:14  *** xinxi has quit IRC
  692017-01-12T02:21:36  <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.
  702017-01-12T02:21:37  <gribble> https://github.com/bitcoin/bitcoin/issues/8639 | [Docs] Minimum required dependencies and current CVEs · Issue #8639 · bitcoin/bitcoin · GitHub
  712017-01-12T02:22:49  <sipa> for non-qt we only need openssl for the PRNG
  722017-01-12T02:23:11  <sipa> which i think means very old versions will work
  732017-01-12T02:23:22  <sipa> not sure if we should suggest that, though
  742017-01-12T02:25:26  <gmaxwell> and our use of it in the rng could darn near be replaced with rand()
  752017-01-12T02:25:46  <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.
  762017-01-12T02:26:24  <fanquake> We are currently using 1.0.1k in depends.
  772017-01-12T02:27:22  <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.
  782017-01-12T02:28:07  <MarcoFalke> How come that doxygen still has main.cpp?
  792017-01-12T02:28:09  <MarcoFalke> https://dev.visucore.com/bitcoin/doxygen/main_8cpp_source.html
  802017-01-12T02:28:35  <MarcoFalke> Generated on Wed Jan 11 2017
  812017-01-12T02:28:42  <MarcoFalke> We killed that last year
  822017-01-12T02:29:30  <fanquake> gmaxwell ok, thanks.
  832017-01-12T02:29:36  <gmaxwell> MarcoFalke: whatever is generating it is on a forked repository?
  842017-01-12T02:30:20  <achow101> apparently decoderawtransaction is not decoding segwit txs properly: https://bitcointalk.org/index.php?topic=1748353.msg17477509#msg17477509
  852017-01-12T02:30:50  <MarcoFalke> ^ wumpus can you take a look at doxygen, please?
  862017-01-12T02:34:12  *** arowser has quit IRC
  872017-01-12T02:38:03  <gmaxwell> achow101: The issue is that segwit txn deseralizes as a 'crazy' non-segwit txn-- one with zero input transactions.
  882017-01-12T02:38:27  <gmaxwell> achow101: the decodehex tries to decode as non-segwit first and then segwit, but that txn successfully decodes.
  892017-01-12T02:39:00  <achow101> is that just bad luck then that it is able to successfully decode as non-segwit first?
  902017-01-12T02:39:31  <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.
  912017-01-12T02:39:35  *** Chris_Stewart_5 has quit IRC
  922017-01-12T02:39:55  <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.
  932017-01-12T02:40:04  <gmaxwell> But I think that is likely the correct fix.
  942017-01-12T02:40:12  <gmaxwell> or most correct.
  952017-01-12T02:40:18  <sipa> didn't we fix that already?
  962017-01-12T02:40:39  <gmaxwell> sipa: for decoderawtransactions?  my description is from reading the current code.
  972017-01-12T02:41:32  <achow101> what use case is there for 0 input txns?
  982017-01-12T02:41:35  <gmaxwell> an alternative would be to reverse the trial order, so it won't even try nonwit unless witness fails.
  992017-01-12T02:42:08  <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.)
 1002017-01-12T02:42:24  <sipa> raw transactions are more often used for unsigned transactions
 1012017-01-12T02:42:31  <sipa> which by definition aren't segwit
 1022017-01-12T02:42:45  <achow101> oh
 1032017-01-12T02:43:08  <sipa> once they're signed, they're usually complete
 1042017-01-12T02:43:21  <sipa> but it's unfortunate that there is ambiguity
 1052017-01-12T02:43:48  <sipa> we should propose some 'partially signed' transaction format
 1062017-01-12T02:43:54  <sipa> that's unambiguous
 1072017-01-12T02:43:59  *** fanquake has quit IRC
 1082017-01-12T02:44:03  <sipa> but has place for metadata etc
 1092017-01-12T02:44:13  <gmaxwell> well in particular, amounts and scriptpubkeys.
 1102017-01-12T02:44:23  <achow101> gmaxwell: what about having decoderawtx take a parameter to tell it to decode as segwit or non
 1112017-01-12T02:44:44  <gmaxwell> achow101: thats a bit ugly.
 1122017-01-12T02:44:44  <achow101> and have that somehow be related to soft fork activation
 1132017-01-12T02:44:57  <gmaxwell> achow101: thats more than a bit ugly. :P
 1142017-01-12T02:47:14  <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?
 1152017-01-12T02:47:56  <gmaxwell> sdaftuar: sure, except for this bug.
 1162017-01-12T02:47:59  <gmaxwell> just shows now inputs.
 1172017-01-12T02:48:13  *** face has quit IRC
 1182017-01-12T02:48:17  <gmaxwell> I suppose it being unwilling wouldn't be the end of the world.
 1192017-01-12T02:48:28  <sipa> decoderawtransaction and fundraetransaction both attempt old and new deserialization
 1202017-01-12T02:48:33  <gmaxwell> it's not like I could sign a zero input transaction.
 1212017-01-12T02:49:01  <sipa> but they only accept the old serialization if it exactly matches the string
 1222017-01-12T02:49:13  <sipa> (no undecoded garbage at the end)
 1232017-01-12T02:49:21  *** face has joined #bitcoin-core-dev
 1242017-01-12T02:49:39  <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.
 1252017-01-12T02:53:47  <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
 1262017-01-12T02:54:37  <sipa> decodehextx gets a bool arg
 1272017-01-12T02:54:56  <sipa> to indicate if non-extended format decoding should be attempted
 1282017-01-12T02:55:07  <sipa> only decoderawtx and fundrawtx set that bool to true
 1292017-01-12T02:55:12  <gmaxwell> that should be false for sendraw.
 1302017-01-12T02:55:20  <sipa> it iz
 1312017-01-12T02:55:22  <sipa> it is
 1322017-01-12T02:55:30  <gmaxwell> iz was okay too.
 1332017-01-12T02:56:00  <sipa> i zhall rezord do uzing voized vowelz vrom now on
 1342017-01-12T02:56:15  *** arowser has joined #bitcoin-core-dev
 1352017-01-12T02:56:16  <gmaxwell> oh dear.
 1362017-01-12T02:56:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 1372017-01-12T02:57:33  *** arowser has quit IRC
 1382017-01-12T02:59:17  *** Kexkey has joined #bitcoin-core-dev
 1392017-01-12T03:00:30  <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.
 1402017-01-12T03:00:33  <gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
 1412017-01-12T03:00:41  <sdaftuar> bumper* transaction
 1422017-01-12T03:02:05  *** JackH has joined #bitcoin-core-dev
 1432017-01-12T03:03:40  *** baldur has quit IRC
 1442017-01-12T03:03:41  <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...
 1452017-01-12T03:04:09  *** arowser has joined #bitcoin-core-dev
 1462017-01-12T03:04:09  *** Chris_Stewart_5 has quit IRC
 1472017-01-12T03:04:41  <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
 1482017-01-12T03:05:59  *** xinxi has joined #bitcoin-core-dev
 1492017-01-12T03:06:08  <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
 1502017-01-12T03:06:29  <sdaftuar> seems reasonable to me
 1512017-01-12T03:08:22  <bitcoin-git> [bitcoin] achow101 opened pull request #9522: [RPC] Fix decoderawtransaction decoding of segwit txs (master...fix-decoderawtx) https://github.com/bitcoin/bitcoin/pull/9522
 1522017-01-12T03:08:53  *** arowser has quit IRC
 1532017-01-12T03:11:13  <sipa> achow101: the bool arg to decodehextx should probably be changed to being an enum, with extended_only, prefer_extended, prefer_normal
 1542017-01-12T03:11:49  <sipa> instead of basing it on hex bytes
 1552017-01-12T03:12:36  *** MarcoFalke has quit IRC
 1562017-01-12T03:13:34  <achow101> it would still have to be based on the hex bytes to know when each one should be done though
 1572017-01-12T03:13:55  <sipa> no
 1582017-01-12T03:14:09  <sipa> you've just implemented a "prefer extended" stratwgy
 1592017-01-12T03:14:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 1602017-01-12T03:15:51  <achow101> but then how do you know which strategy to choose?
 1612017-01-12T03:16:11  <sipa> decoderawtransaction would use prefer extended
 1622017-01-12T03:16:28  <sipa> fundrawtransaction would use prefer olf
 1632017-01-12T03:16:36  <sipa> all the rest would be extended only
 1642017-01-12T03:16:37  *** baldur has joined #bitcoin-core-dev
 1652017-01-12T03:16:44  <achow101> oh.
 1662017-01-12T03:16:49  <sipa> that's what you have implemented now
 1672017-01-12T03:16:58  <achow101> I see
 1682017-01-12T03:18:16  *** Kexkey has quit IRC
 1692017-01-12T03:20:21  <achow101> I can make that change
 1702017-01-12T03:27:43  <sipa> actually
 1712017-01-12T03:28:05  <sipa> what if you just pass false to decodehextx in decoderawtransaction?
 1722017-01-12T03:28:18  <sipa> i believe the behavior will be the same as what you have now
 1732017-01-12T03:29:03  <achow101> then it will be decoding all transactions as extended
 1742017-01-12T03:30:31  <sipa> yes
 1752017-01-12T03:30:44  <sipa> that's what you want, no?
 1762017-01-12T03:31:23  <sipa> the extended format for transactions without witness is identical to the old format
 1772017-01-12T03:31:47  <achow101> right
 1782017-01-12T03:31:54  <achow101> yes, that should work.
 1792017-01-12T03:32:56  <achow101> why was it passing in true originally then?
 1802017-01-12T03:33:44  <sipa> to pick old decoding in case it was ambiguous
 1812017-01-12T03:34:07  <sipa> which is what you want for fundrawtransaction
 1822017-01-12T03:34:16  <sipa> but perhaps not for decoderawtransaction
 1832017-01-12T03:34:34  <sipa> i'm not sure, it's choosing between two suboptimal options
 1842017-01-12T03:44:32  *** cbits has quit IRC
 1852017-01-12T03:45:01  *** PRab has quit IRC
 1862017-01-12T03:46:03  <ZhibiaoPan> https://www.blocktrail.com/tBTC/tx/042e9225966258ec7d133d90a978d21ef1d7e4edc4800331a80f73f2d71316d8
 1872017-01-12T03:46:16  <ZhibiaoPan> Mining Fee is -1.40625000 tBTC
 1882017-01-12T03:46:55  <adiabat> ZhibiaoPan ... it's a coinbase tx
 1892017-01-12T03:47:11  <ZhibiaoPan> CheckBlock() didn't check the block reward and mining fee?
 1902017-01-12T03:47:19  *** robmcl4 has joined #bitcoin-core-dev
 1912017-01-12T03:47:41  <achow101> the output of a coinbase can be less than the reward that the miner is entitled to
 1922017-01-12T03:47:55  <achow101> those coins are then just permanently missing
 1932017-01-12T03:55:41  *** Chris_Stewart_5 has quit IRC
 1942017-01-12T04:09:08  <wumpus> marcofalke: good catch, the script that is supposed to update it was not able to fetch the repo
 1952017-01-12T04:14:16  *** cbits has joined #bitcoin-core-dev
 1962017-01-12T04:17:56  *** chris2000 has joined #bitcoin-core-dev
 1972017-01-12T04:20:37  *** chris200_ has quit IRC
 1982017-01-12T04:22:32  *** justanotheruser has joined #bitcoin-core-dev
 1992017-01-12T04:23:45  *** officia||eibniz has quit IRC
 2002017-01-12T05:03:17  <btcdrak> ZhibiaoPan: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1876-L1881
 2012017-01-12T05:06:15  *** robmcl4 has quit IRC
 2022017-01-12T05:15:02  *** Alopex has quit IRC
 2032017-01-12T05:16:07  *** Alopex has joined #bitcoin-core-dev
 2042017-01-12T05:20:07  <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
 2052017-01-12T05:20:54  <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
 2062017-01-12T05:22:32  <cfields> BlueMatt: yea, i almost suggested that, but it would just kinda mask the issue (usually)
 2072017-01-12T05:22:48  <cfields> BlueMatt: to be clear, i'm not worried about the disk access _at all_
 2082017-01-12T05:22:53  <BlueMatt> I know
 2092017-01-12T05:22:59  <BlueMatt> I am, though, so thanks for reporting :p
 2102017-01-12T05:23:03  <cfields> was just using it as an example
 2112017-01-12T05:23:04  <cfields> heh
 2122017-01-12T05:23:09  <BlueMatt> i mean it fixes your specific issue, but I'm really not a fan of the BlockUntilBlockIsWhereIWant in the net code
 2132017-01-12T05:23:11  <BlueMatt> I know, I know
 2142017-01-12T05:23:39  <cfields> BlueMatt: well if you're not a fan of that, certainly you're not a fan of ActivateBestChain there either :)
 2152017-01-12T05:24:03  <BlueMatt> no, I'm specifically not a fan of BlockOnThing() over DoTheThingIWantToBlockOn()
 2162017-01-12T05:24:22  <cfields> i see
 2172017-01-12T05:24:25  <BlueMatt> wellllll, hum
 2182017-01-12T05:24:28  <BlueMatt> now that i say that
 2192017-01-12T05:24:52  *** xinxi has quit IRC
 2202017-01-12T05:25:14  <cfields> no, you're not doing anything in either action. Either way it's being treated as a fence.
 2212017-01-12T05:25:39  <BlueMatt> well we need a fence primitive for wallet to fix #9148
 2222017-01-12T05:25:40  <gribble> https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
 2232017-01-12T05:25:55  <cfields> er, "not doing anything" is a very poor choice of words, that's obviously not what i meant
 2242017-01-12T05:26:42  <BlueMatt> I mean I feel kinda yucky doing this because what if some braindead caller calls AcceptBlock without ActivateBestChain?
 2252017-01-12T05:26:50  <BlueMatt> we then call the fence and freeze forever
 2262017-01-12T05:26:53  <BlueMatt> is my concern
 2272017-01-12T05:27:27  <BlueMatt> same applies for wallet, though....
 2282017-01-12T05:27:44  <BlueMatt> hence my comment on prefering FenceButFeelFreeToDoWorkToGetThere
 2292017-01-12T05:27:51  <BlueMatt> which is what ABC is to me, here, i guess
 2302017-01-12T05:27:53  <cfields> BlueMatt: i was just picturing: at the top of ABC, working=true. at the bottom, working=false
 2312017-01-12T05:28:02  <cfields> nasty hack, but that's what you really want to know, right?
 2322017-01-12T05:28:14  <BlueMatt> no, you'd need to do that in ProcessNewBlock
 2332017-01-12T05:29:19  <cfields> not for your purposes, i think? It's ABC that would trigger the callback to push out the message, no?
 2342017-01-12T05:29:45  <cfields> er, nm
 2352017-01-12T05:42:14  *** cbits has quit IRC
 2362017-01-12T05:52:43  *** jcorgan has quit IRC
 2372017-01-12T06:01:43  *** jcorgan has joined #bitcoin-core-dev
 2382017-01-12T06:25:39  *** xinxi has joined #bitcoin-core-dev
 2392017-01-12T06:31:52  *** xinxi has quit IRC
 2402017-01-12T07:00:19  *** dermoth has quit IRC
 2412017-01-12T07:01:05  *** dermoth has joined #bitcoin-core-dev
 2422017-01-12T07:01:11  *** chjj has quit IRC
 2432017-01-12T07:05:29  *** xinxi has joined #bitcoin-core-dev
 2442017-01-12T07:18:49  *** Ylbam has joined #bitcoin-core-dev
 2452017-01-12T07:28:14  *** chjj has joined #bitcoin-core-dev
 2462017-01-12T07:45:22  *** wasi has quit IRC
 2472017-01-12T07:45:55  *** wasi has joined #bitcoin-core-dev
 2482017-01-12T08:01:20  <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?
 2492017-01-12T08:01:43  <jonasschnelli> gmaxwell: No. Didn't started. I had in mind that you said you want to start with that... but I can try something...
 2502017-01-12T08:03:46  <jonasschnelli> Oh. Github down?
 2512017-01-12T08:08:03  *** BashCo has quit IRC
 2522017-01-12T08:08:44  *** BashCo has joined #bitcoin-core-dev
 2532017-01-12T08:08:48  <whphhg> Yup, seems so
 2542017-01-12T08:09:14  <rabidus> yup
 2552017-01-12T08:09:22  * jonasschnelli doesn't like the unicorn...
 2562017-01-12T08:13:10  *** BashCo has quit IRC
 2572017-01-12T08:25:24  *** droark has joined #bitcoin-core-dev
 2582017-01-12T08:26:20  *** kadoban has quit IRC
 2592017-01-12T08:26:21  *** goregrin1 is now known as goregrind
 2602017-01-12T08:28:48  *** Cheeseo has quit IRC
 2612017-01-12T08:37:03  *** BashCo has joined #bitcoin-core-dev
 2622017-01-12T08:39:37  *** xinxi has quit IRC
 2632017-01-12T08:57:24  *** xinxi has joined #bitcoin-core-dev
 2642017-01-12T09:03:12  *** midnightmagic has quit IRC
 2652017-01-12T09:04:14  *** michiel_ has joined #bitcoin-core-dev
 2662017-01-12T09:13:42  *** jannes has joined #bitcoin-core-dev
 2672017-01-12T09:19:57  *** Guyver2 has joined #bitcoin-core-dev
 2682017-01-12T09:34:42  *** MarcoFalke has joined #bitcoin-core-dev
 2692017-01-12T09:41:41  *** midnightmagic has joined #bitcoin-core-dev
 2702017-01-12T09:47:31  *** wasi has quit IRC
 2712017-01-12T09:47:53  *** wasi has joined #bitcoin-core-dev
 2722017-01-12T09:54:00  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9ec1330b455c...2456a835f0bc
 2732017-01-12T09:54:00  <bitcoin-git> bitcoin/master db904db Pieter Wuille: Deprecate non-txindex getrawtransaction and better warning
 2742017-01-12T09:54:01  <bitcoin-git> bitcoin/master 2456a83 MarcoFalke: Merge #9520: Deprecate non-txindex getrawtransaction and better warning...
 2752017-01-12T09:54:18  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9520: Deprecate non-txindex getrawtransaction and better warning (master...warntxindex) https://github.com/bitcoin/bitcoin/pull/9520
 2762017-01-12T10:16:29  <MarcoFalke> Thanks for fixing doxygen, wumpus!
 2772017-01-12T10:38:40  <MarcoFalke> What is the desired behavior of pruneblockchain(0)?
 2782017-01-12T10:41:28  *** AaronVW has joined #bitcoin-core-dev
 2792017-01-12T10:49:26  *** jannes has quit IRC
 2802017-01-12T10:51:58  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2456a835f0bc...a65ced1a6657
 2812017-01-12T10:51:58  <bitcoin-git> bitcoin/master 918d1fb Russell Yanofsky: Return height of last block pruned by pruneblockchain RPC...
 2822017-01-12T10:51:59  <bitcoin-git> bitcoin/master a65ced1 MarcoFalke: Merge #9518: Return height of last block pruned by pruneblockchain RPC...
 2832017-01-12T10:52:16  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9518: Return height of last block pruned by pruneblockchain RPC (master...pr/prune-height) https://github.com/bitcoin/bitcoin/pull/9518
 2842017-01-12T11:02:43  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9524: qa/rpc: Fix pruneblockchain edge cases (master...Mf1701-qaPruning) https://github.com/bitcoin/bitcoin/pull/9524
 2852017-01-12T11:02:48  *** jannes has joined #bitcoin-core-dev
 2862017-01-12T11:03:54  <MarcoFalke> We should probably just only allow a single code style with all known bad practices eliminated.
 2872017-01-12T11:06:23  <MarcoFalke> python should stop interpreting when it sees smelly code and gcc should fail to compile.
 2882017-01-12T11:13:40  <bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/a65ced1a6657...fac0f30482d5
 2892017-01-12T11:13:41  <bitcoin-git> bitcoin/master a4bac66 Pieter Wuille: [MOVEONLY] Move progress estimation out of checkpoints
 2902017-01-12T11:13:42  <bitcoin-git> bitcoin/master 3641141 Pieter Wuille: Move tx estimation data out of CCheckPointData
 2912017-01-12T11:13:42  <bitcoin-git> bitcoin/master 6dd8116 Pieter Wuille: Remove SIGCHECK_VERIFICATION_FACTOR
 2922017-01-12T11:13:56  <bitcoin-git> [bitcoin] laanwj closed pull request #9472: Disentangle progress estimation from checkpoints and update it (master...update_tx_estimation) https://github.com/bitcoin/bitcoin/pull/9472
 2932017-01-12T11:18:13  <wumpus> MarcoFalke: continuing without crashing :-)
 2942017-01-12T11:24:59  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/fac0f30482d5...d5d4ad87afbf
 2952017-01-12T11:25:00  <bitcoin-git> bitcoin/master 1814b08 Stanislas Marion: add p2sh and segwit options to bitcoin-tx outscript command
 2962017-01-12T11:25:00  <bitcoin-git> bitcoin/master 61a1534 jnewbery: Add all transaction output types to bitcoin-tx....
 2972017-01-12T11:25:01  <bitcoin-git> bitcoin/master b7e144b jnewbery: Add test cases to test new bitcoin-tx functionality...
 2982017-01-12T11:35:53  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d5d4ad87afbf...2742568a008e
 2992017-01-12T11:35:54  <bitcoin-git> bitcoin/master dfbe0d5 Alex Morcos: Add unstored orphans with rejected parents to recentRejects
 3002017-01-12T11:35:54  <bitcoin-git> bitcoin/master 2742568 Wladimir J. van der Laan: Merge #9261: Add unstored orphans with rejected parents to recentRejects...
 3012017-01-12T11:36:01  <bitcoin-git> [bitcoin] laanwj closed pull request #9261: Add unstored orphans with rejected parents to recentRejects (master...orphanRejects) https://github.com/bitcoin/bitcoin/pull/9261
 3022017-01-12T11:46:48  <bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/2742568a008e...f9117f204756
 3032017-01-12T11:46:49  <bitcoin-git> bitcoin/master 8ac1830 fanquake: [depends] Latest config.guess and config.sub
 3042017-01-12T11:46:49  <bitcoin-git> bitcoin/master 4ed6faf fanquake: [depends] Boost 1.63.0
 3052017-01-12T11:46:50  <bitcoin-git> bitcoin/master 6019d21 fanquake: [depends] FreeType 2.7.1
 3062017-01-12T11:47:03  <bitcoin-git> [bitcoin] laanwj closed pull request #9468: [Depends] Dependency updates for 0.14.0 (master...depends-update-014) https://github.com/bitcoin/bitcoin/pull/9468
 3072017-01-12T11:47:20  *** JackH has quit IRC
 3082017-01-12T11:49:33  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f9117f204756...7cb024eba68b
 3092017-01-12T11:49:33  <bitcoin-git> bitcoin/master 453bda6 Chris Moore: Add 'subtractFeeFromOutputs' option to 'fundrawtransaction'.
 3102017-01-12T11:49:34  <bitcoin-git> bitcoin/master 7cb024e Wladimir J. van der Laan: Merge #9222: Add 'subtractFeeFromAmount' option to 'fundrawtransaction'....
 3112017-01-12T12:15:08  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9525: test: Include tx data in EXTRA_DIST (master...Mf1701-testINCLUDE) https://github.com/bitcoin/bitcoin/pull/9525
 3122017-01-12T12:15:59  <MarcoFalke> going to cancel all travis instances
 3132017-01-12T12:23:05  *** fanquake has joined #bitcoin-core-dev
 3142017-01-12T12:24:01  <fanquake> Let's get a few ACKs on #9525
 3152017-01-12T12:24:03  <gribble> https://github.com/bitcoin/bitcoin/issues/9525 | test: Include tx data in EXTRA_DIST by MarcoFalke · Pull Request #9525 · bitcoin/bitcoin · GitHub
 3162017-01-12T12:43:18  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7cb024eba68b...02e5308c1b9f
 3172017-01-12T12:43:18  <bitcoin-git> bitcoin/master fa29736 MarcoFalke: test: Include tx data in EXTRA_DIST
 3182017-01-12T12:43:19  <bitcoin-git> bitcoin/master 02e5308 MarcoFalke: Merge #9525: test: Include tx data in EXTRA_DIST...
 3192017-01-12T12:43:38  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9525: test: Include tx data in EXTRA_DIST (master...Mf1701-testINCLUDE) https://github.com/bitcoin/bitcoin/pull/9525
 3202017-01-12T12:58:54  *** xinxi has quit IRC
 3212017-01-12T12:59:21  *** xinxi has joined #bitcoin-core-dev
 3222017-01-12T13:01:06  *** MarcoFalke has quit IRC
 3232017-01-12T13:02:46  <da2ce7> Just tested 'make deploy' from git-head on latest mac. Works without problem :)
 3242017-01-12T13:05:09  <wumpus> great!
 3252017-01-12T13:09:17  <fanquake> wumpus any objection to closing 7149 ?
 3262017-01-12T13:12:09  <wumpus> fanquake: yeah I don't think it's going to be merged as it is
 3272017-01-12T13:14:43  *** pavel_ has joined #bitcoin-core-dev
 3282017-01-12T13:17:38  <fanquake> wumpus yea, open for > 1yr with only 2 comments.
 3292017-01-12T13:17:39  *** paveljanik has quit IRC
 3302017-01-12T13:17:39  <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.
 3312017-01-12T13:18:07  *** pavel_ has quit IRC
 3322017-01-12T13:19:05  *** xinxi has quit IRC
 3332017-01-12T13:19:06  <bitcoin-git> [bitcoin] fanquake closed pull request #8339: Consensuslib: Block Verify / Transaction Verify [Do not merge, work in progress]  (master...blkconsensus) https://github.com/bitcoin/bitcoin/pull/8339
 3342017-01-12T13:23:24  <bitcoin-git> [bitcoin] fanquake closed pull request #7149: Bugfix: Correctly calculate priority when inputs are mined after dependent transactions enter the memory pool (master...bugfix_priority) https://github.com/bitcoin/bitcoin/pull/7149
 3352017-01-12T13:25:59  <bitcoin-git> [bitcoin] fanquake closed pull request #8488: Add deleteprivkey and forgetaddress RPC calls (master...forgetaddress-1) https://github.com/bitcoin/bitcoin/pull/8488
 3362017-01-12T13:27:31  *** jtimon has joined #bitcoin-core-dev
 3372017-01-12T13:29:35  <bitcoin-git> [bitcoin] fanquake closed pull request #8849: print P2WSH redeemScript in getrawtransaction if it s not a pubkey (master...print-p2wsh-redeemscript-in-getrawtransaction) https://github.com/bitcoin/bitcoin/pull/8849
 3382017-01-12T13:35:09  <bitcoin-git> [bitcoin] fanquake closed pull request #9116: Allow getblocktemlate for not connected regtest node (master...master) https://github.com/bitcoin/bitcoin/pull/9116
 3392017-01-12T13:38:04  *** xinxi has joined #bitcoin-core-dev
 3402017-01-12T13:42:31  *** xinxi has quit IRC
 3412017-01-12T13:42:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 3422017-01-12T13:43:44  <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?
 3432017-01-12T13:44:01  <wumpus> morcos: both, though mostly the latter
 3442017-01-12T13:44:31  <wumpus> mostly that people get confused that they're suddenly creating a different kind of transactions with different properties
 3452017-01-12T13:44:36  <wumpus> without having asked for it
 3462017-01-12T13:45:17  <wumpus> of course it could be included in the release notes, but the planned release notes for 0.14 will already be huge :)
 3472017-01-12T13:45:23  <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
 3482017-01-12T13:45:48  <fanquake> Yes I'm sure a few things are going to get lost in there already.
 3492017-01-12T13:46:08  <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
 3502017-01-12T13:46:24  <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
 3512017-01-12T13:46:54  <wumpus> yes
 3522017-01-12T13:47:09  <bitcoin-git> [bitcoin] fanquake closed pull request #9064: unify capitalization of "bitcoin address" (master...changeCaps) https://github.com/bitcoin/bitcoin/pull/9064
 3532017-01-12T13:47:09  <wumpus> anywhere bumpfee is mentioned it should be made clear
 3542017-01-12T13:48:39  <wumpus> also in the RPC help for the funcition, thinking of it
 3552017-01-12T13:50:55  *** xinxi has joined #bitcoin-core-dev
 3562017-01-12T13:54:11  <wumpus> in any case let's not make merging that functionality dependent on the defaults discussion
 3572017-01-12T13:54:50  <morcos> sure agreed
 3582017-01-12T13:55:03  *** xinxi has quit IRC
 3592017-01-12T14:07:59  <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 ?
 3602017-01-12T14:08:30  <wumpus> morcos: yes, that sounds like the right approach to me
 3612017-01-12T14:08:59  <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?
 3622017-01-12T14:09:14  <sipa> we should also make the rpc example code use named rgs
 3632017-01-12T14:09:19  <sipa> *args
 3642017-01-12T14:09:40  <sipa> and i wonder if we shouldn't first start converting some methods to natively accept names
 3652017-01-12T14:09:47  *** xinxi has joined #bitcoin-core-dev
 3662017-01-12T14:12:45  <fanquake> Do we really need a nearly 1100 line script to check/maintain copyright headers
 3672017-01-12T14:17:26  <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.
 3682017-01-12T14:17:39  *** jnewbery has joined #bitcoin-core-dev
 3692017-01-12T14:17:45  <wumpus> so adding holes support to a RPC call is good in every way
 3702017-01-12T14:18:23  <wumpus> fanquake: well as long as the guy maintains it it's fine I guess
 3712017-01-12T14:18:29  <instagibbs> morcos, I'm up to 20% RTT saved now, syncing with your number
 3722017-01-12T14:20:24  <fanquake> wumpus I guess. It just seems like something set to degrade. Checking sub-trees also seems like overkill.
 3732017-01-12T14:20:41  <wumpus> fanquake: checking sub-trees is absolutely overkill
 3742017-01-12T14:20:46  <fanquake> I'm not sure what the point of that is, as it's not like we're going to modify them also.
 3752017-01-12T14:20:54  <wumpus> we don't merge any changes to those
 3762017-01-12T14:20:56  <wumpus> right
 3772017-01-12T14:21:24  <wumpus> but I suppose that comes by default - it's *avoiding* subtrees that requires extra logic. Or maybe I'm thinking of it wrong.
 3782017-01-12T14:21:52  <fanquake> I thought you'd be able to just exclude all the files in the subtree dirs.
 3792017-01-12T14:21:53  *** windsok has quit IRC
 3802017-01-12T14:22:13  <wumpus> very possible - I don't know what he uses to query the list of files from git
 3812017-01-12T14:24:15  <fanquake> I am starting to like the idea of adding other types of checking to Travis though. Some discussion in 9452
 3822017-01-12T14:24:37  *** Cheeseo has joined #bitcoin-core-dev
 3832017-01-12T14:26:13  <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.
 3842017-01-12T14:27:34  <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.
 3852017-01-12T14:28:18  <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.
 3862017-01-12T14:29:25  <morcos> gmaxwell: what i said yesterday about using the default in bumpfee doesn't make sense
 3872017-01-12T14:29:44  <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
 3882017-01-12T14:30:25  <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
 3892017-01-12T14:30:42  <gmaxwell> thats okay with me.
 3902017-01-12T14:31:30  <morcos> even that though sounds a bit risky to me
 3912017-01-12T14:32:00  <morcos> what happens when you bump some transaction that was only valid because of its sequence numbers and CSV
 3922017-01-12T14:32:16  <gmaxwell> well considering we can't sign for such a transaction currently...
 3932017-01-12T14:32:31  <morcos> we can't?
 3942017-01-12T14:32:54  <gmaxwell> no, if there is a OP_CSV signrawtransaction won't work, you'd need to be running modified software.
 3952017-01-12T14:33:41  <Chris_Stewart_5> requires standardness?
 3962017-01-12T14:34:01  <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.
 3972017-01-12T14:34:33  <jonasschnelli> gmaxwell: deadlock. :)
 3982017-01-12T14:35:04  <jonasschnelli> Should I start to do something or do you want to work on the HD-keypool auto-jump?
 3992017-01-12T14:35:24  <sipa> Chris_Stewart_5: no, the signing code just doesn't know how to produce a scriptSig for that
 4002017-01-12T14:35:37  <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).
 4012017-01-12T14:35:55  <gmaxwell> jonasschnelli: I think it will be simple (famous last words).
 4022017-01-12T14:36:10  <jonasschnelli> gmaxwell: Okay. Let me try... but I can't start before tomorrow / friday. Not sure if I get something done before the freeze.
 4032017-01-12T14:36:18  <jonasschnelli> gmaxwell: heh. Okay.
 4042017-01-12T14:37:35  <Chris_Stewart_5> gotcha. Thanks.
 4052017-01-12T14:39:01  <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
 4062017-01-12T14:46:34  <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.
 4072017-01-12T14:47:12  <fanquake> wumpus agreed.
 4082017-01-12T14:48:23  <bitcoin-git> [bitcoin] fanquake closed pull request #7823: Add index to wallet UTXO (master...enhancement/cache-unspent-outputs) https://github.com/bitcoin/bitcoin/pull/7823
 4092017-01-12T14:48:39  <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
 4102017-01-12T14:49:34  <fanquake> wumpus Yea I wish it just posted the error/log output in the GitHub comment bit.
 4112017-01-12T14:49:43  <wumpus> well please not the entire thing
 4122017-01-12T14:49:58  <wumpus> just a summary of points, say e.g. what build step failed and the error message
 4132017-01-12T14:50:02  <fanquake> Yes not the whole lot, just the last 10 lines or so.
 4142017-01-12T14:50:11  *** michiel_ is now known as gielbier_
 4152017-01-12T14:50:44  <fanquake> I should be minimized by default too.
 4162017-01-12T14:51:11  <wumpus> any way to put a custom message in the comment bit would be great, we can handle the rest
 4172017-01-12T14:51:45  <fanquake> Anything to save looking at 6 different sets of logs.
 4182017-01-12T14:55:13  <fanquake> Also, are we still manually starting the builds of 7148
 4192017-01-12T14:55:58  <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.
 4202017-01-12T14:59:23  *** laurentmt has joined #bitcoin-core-dev
 4212017-01-12T15:01:56  *** laurentmt has quit IRC
 4222017-01-12T15:02:55  *** windsok has joined #bitcoin-core-dev
 4232017-01-12T15:03:17  *** AaronVW has quit IRC
 4242017-01-12T15:03:48  *** AaronVW has joined #bitcoin-core-dev
 4252017-01-12T15:18:28  *** fanquake has quit IRC
 4262017-01-12T15:31:40  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9527: Enable RBF transactions in wallet by default (master...pr/walletrbf) https://github.com/bitcoin/bitcoin/pull/9527
 4272017-01-12T15:49:29  <bitcoin-git> [bitcoin] practicalswift opened pull request #9528: [trivial] Rename formateNiceTimeOffset(qint64) to formatNiceTimeOffset(qint64) (master...rename-formateNiceTimeOffset) https://github.com/bitcoin/bitcoin/pull/9528
 4282017-01-12T15:50:26  <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.
 4292017-01-12T15:55:08  *** BashCo_ has joined #bitcoin-core-dev
 4302017-01-12T15:56:53  *** BashCo has quit IRC
 4312017-01-12T15:57:21  *** xinxi has quit IRC
 4322017-01-12T16:03:53  *** xinxi has joined #bitcoin-core-dev
 4332017-01-12T16:10:15  *** BashCo_ has quit IRC
 4342017-01-12T16:23:23  <bitcoin-git> [bitcoin] practicalswift opened pull request #9529: Bug fix: Update the instance variable self.lastDate (not the locally scoped variable lastDate) (master...fix-bug-in-BlockDataCopier) https://github.com/bitcoin/bitcoin/pull/9529
 4352017-01-12T16:37:39  *** JackH has joined #bitcoin-core-dev
 4362017-01-12T16:41:37  *** BashCo has joined #bitcoin-core-dev
 4372017-01-12T16:43:17  *** Guest53948 is now known as haakonn
 4382017-01-12T16:43:46  *** haakonn is now known as Guest46061
 4392017-01-12T16:48:53  *** xinxi has quit IRC
 4402017-01-12T16:50:12  *** abpa has joined #bitcoin-core-dev
 4412017-01-12T16:51:50  *** xinxi has joined #bitcoin-core-dev
 4422017-01-12T16:56:45  *** afk11 has joined #bitcoin-core-dev
 4432017-01-12T17:10:03  <luke-jr> any objections to rebasing #9422 ?
 4442017-01-12T17:10:05  <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
 4452017-01-12T17:27:10  <bitcoin-git> [bitcoin] morcos opened pull request #9531: Release notes for estimation changes  (master...relnotes) https://github.com/bitcoin/bitcoin/pull/9531
 4462017-01-12T17:35:12  *** arubi has left #bitcoin-core-dev
 4472017-01-12T17:35:20  *** arubi has joined #bitcoin-core-dev
 4482017-01-12T17:38:55  <bitcoin-git> [bitcoin] practicalswift opened pull request #9532: [trivial] Remove unused variables (master...remove-unused-variables) https://github.com/bitcoin/bitcoin/pull/9532
 4492017-01-12T17:51:33  *** drbolardus has joined #bitcoin-core-dev
 4502017-01-12T17:55:02  <btcdrak> luke-jr: go ahead
 4512017-01-12T18:06:21  *** cbits has joined #bitcoin-core-dev
 4522017-01-12T18:11:31  *** cbits has quit IRC
 4532017-01-12T18:17:17  <sipa> i'll be travelling during part of the meeting
 4542017-01-12T18:22:00  <bitcoin-git> [bitcoin] sipa opened pull request #9533: Allow non-power-of-2 signature cache sizes (master...anysigcachesize) https://github.com/bitcoin/bitcoin/pull/9533
 4552017-01-12T18:36:49  *** MarcoFalke has joined #bitcoin-core-dev
 4562017-01-12T18:50:54  *** Guest46061 is now known as haakonn
 4572017-01-12T18:51:00  *** haakonn has joined #bitcoin-core-dev
 4582017-01-12T18:56:58  <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
 4592017-01-12T18:57:01  <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
 4602017-01-12T18:58:18  <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?
 4612017-01-12T18:58:52  <BlueMatt> I mean I tend to air on the side of it-shouldnt-have-side-effects just because thats how that function /should/ work
 4622017-01-12T18:58:54  <BlueMatt> :/
 4632017-01-12T19:00:08  <wumpus> #startmeeting
 4642017-01-12T19:00:08  <lightningbot> Meeting started Thu Jan 12 19:00:08 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 4652017-01-12T19:00:08  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 4662017-01-12T19:00:17  <jonasschnelli> hi
 4672017-01-12T19:00:37  <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
 4682017-01-12T19:00:44  <kanzure> hi.
 4692017-01-12T19:01:04  <wumpus> proposed topics?
 4702017-01-12T19:01:21  <btcdrak> hi
 4712017-01-12T19:01:25  <michagogo> o/
 4722017-01-12T19:01:34  *** moli_ has joined #bitcoin-core-dev
 4732017-01-12T19:01:39  <BlueMatt> 0.14 freeze monday, so lock in prs that will go in now and finalize PR/issue tags for 0.14?
 4742017-01-12T19:01:43  <jonasschnelli> gmaxwell mentioned yesterday that he's traveling.
 4752017-01-12T19:01:46  <BlueMatt> feature freeze, of course
 4762017-01-12T19:01:47  <jtimon> here
 4772017-01-12T19:01:49  <wumpus> anyone working really hard on getting something in before the feature freeze?
 4782017-01-12T19:02:25  <BlueMatt> my #9499 and #9375 plus cfields' #9441 are massive
 4792017-01-12T19:02:27  <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
 4802017-01-12T19:02:29  <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
 4812017-01-12T19:02:29  <BlueMatt> and probably close enough to make it
 4822017-01-12T19:02:31  <gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
 4832017-01-12T19:02:32  <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
 4842017-01-12T19:02:40  <morcos> +1 BlueMatt's list
 4852017-01-12T19:02:51  <luke-jr> (but IIRC from last meeting, there were more important things than MW that take precedence)
 4862017-01-12T19:02:53  *** e4xit has quit IRC
 4872017-01-12T19:02:58  <cfields> wumpus: there's qt 5.7 which is probably worth having in.
 4882017-01-12T19:03:14  <jonasschnelli> cfields: +1... whats missing? Can I help?
 4892017-01-12T19:03:27  <wumpus> cfields: I don't understand the blocker there
 4902017-01-12T19:03:50  <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 :(
 4912017-01-12T19:03:52  <gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
 4922017-01-12T19:04:00  <wumpus> yes #9441 should be ready for merge really
 4932017-01-12T19:04:03  <gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
 4942017-01-12T19:04:41  <btcdrak> +1 on multiwallet
 4952017-01-12T19:04:45  <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
 4962017-01-12T19:04:50  <BlueMatt> btcdrak: my point was I dont think thats gonna make it
 4972017-01-12T19:04:53  <cfields> (re qt 7.1)
 4982017-01-12T19:04:58  <cfields> er, 5.7. heh.
 4992017-01-12T19:05:05  <BlueMatt> would have to turn out to get acks without any comments on the final multiwallet pr, I think
 5002017-01-12T19:05:16  <BlueMatt> unless we decide we super want it and are willing to let it go in post-feature-freeze
 5012017-01-12T19:05:17  <wumpus> forget about multwallet for 0.14
 5022017-01-12T19:05:40  <jonasschnelli> Yes. It's probably to late
 5032017-01-12T19:05:45  <BlueMatt> yup
 5042017-01-12T19:05:48  <wumpus> it's a pity but let's just merge that stuff after the 0.14 split
 5052017-01-12T19:05:58  <jonasschnelli> Yes. No hurry.
 5062017-01-12T19:06:02  <wumpus> then it has ample time to be tested in master, which it needs
 5072017-01-12T19:06:17  <cfields> jonasschnelli: happy to have help, sure. Let's discuss after meeting.
 5082017-01-12T19:06:21  <jonasschnelli> ok
 5092017-01-12T19:06:24  <wumpus> it's not something that is safe to merge last minute before a release and let people figure it out in a rc :)
 5102017-01-12T19:06:28  <BlueMatt> havent looked at the diff, but I'd call #9519 a bugfix, so should go in post-monday
 5112017-01-12T19:06:30  <gribble> https://github.com/bitcoin/bitcoin/issues/9519 | Exclude RBF replacement txs from fee estimation by morcos · Pull Request #9519 · bitcoin/bitcoin · GitHub
 5122017-01-12T19:06:38  <BlueMatt> morcos: should we tag that 0.14?
 5132017-01-12T19:06:44  <luke-jr> ACK not doing MW in 0.14
 5142017-01-12T19:06:54  <morcos> Yes I talked about it a while this morning with sdaftuar.  We should do it for 0.14
 5152017-01-12T19:07:12  <morcos> It's a very minor change
 5162017-01-12T19:07:21  <wumpus> yes bugfixes can be merged after the feature freeze, will tag it
 5172017-01-12T19:07:32  <BlueMatt> #9512 is probably a 0.14 bugfix that should be tagged
 5182017-01-12T19:07:34  <gribble> https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub
 5192017-01-12T19:07:47  <achow101> there's also the final alert stuff that's supposed to go in 0.14
 5202017-01-12T19:08:04  <wumpus> #9512 a bugfix?
 5212017-01-12T19:08:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub
 5222017-01-12T19:08:23  <morcos> I think we should merge #9380 for 0.14 as well, or at least the part that breaks out the -dustrelayfee
 5232017-01-12T19:08:25  <gribble> https://github.com/bitcoin/bitcoin/issues/9380 | Separate different uses of minimum fees by morcos · Pull Request #9380 · bitcoin/bitcoin · GitHub
 5242017-01-12T19:08:26  <BlueMatt> wumpus: I mean I'd call code correctness bugfixes even if there are no bugs
 5252017-01-12T19:08:28  <wumpus> I don't really like the perf hit
 5262017-01-12T19:08:39  <BlueMatt> wumpus: assuming we can fix the performance hit?
 5272017-01-12T19:08:51  <wumpus> normally I woudln't mind but hashing is very important to bitcoind performance
 5282017-01-12T19:09:07  <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
 5292017-01-12T19:09:12  <BlueMatt> I know gmaxwell wanted #9484 for 0.14, which I think it should be
 5302017-01-12T19:09:14  <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
 5312017-01-12T19:09:31  <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
 5322017-01-12T19:09:52  <BlueMatt> wumpus: ok, lets punt on 9512 for now, then
 5332017-01-12T19:09:58  <BlueMatt> can decide later
 5342017-01-12T19:10:17  <morcos> Can we discuss briefly the concept of dust being tied to minrelaytxfee
 5352017-01-12T19:10:23  <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)
 5362017-01-12T19:10:34  <BlueMatt> so things that need review before monday: 9484, 9499, 9375, 9441
 5372017-01-12T19:10:35  <wumpus> morcos: sure, next topic
 5382017-01-12T19:10:40  <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
 5392017-01-12T19:10:51  <wumpus> #action review before monday : 9484, 9499, 9375, 9441
 5402017-01-12T19:10:55  <wumpus> sipa: great!
 5412017-01-12T19:11:02  *** str4d has joined #bitcoin-core-dev
 5422017-01-12T19:11:10  <sipa> and by faster i mean 0.025%
 5432017-01-12T19:11:18  <BlueMatt> heh
 5442017-01-12T19:11:27  <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?
 5452017-01-12T19:11:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9380 | Separate different uses of minimum fees by morcos · Pull Request #9380 · bitcoin/bitcoin · GitHub
 5462017-01-12T19:11:36  <wumpus> well "not slower" would be the goal so anything faster is doubly awesome
 5472017-01-12T19:11:38  <BlueMatt> wumpus: wait, which PR was the LONG_MAX comment in reference to?
 5482017-01-12T19:12:09  <wumpus> BlueMatt: #9512 IIRC
 5492017-01-12T19:12:11  <gribble> https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub
 5502017-01-12T19:12:30  <BlueMatt> wumpus: ahh, yea, admittedly I havent read the code there yet, beyond very brief skimming
 5512017-01-12T19:12:40  <BlueMatt> morcos: go ahead?
 5522017-01-12T19:12:41  <cfields> yes, it's in the CScriptNum tests
 5532017-01-12T19:13:43  <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
 5542017-01-12T19:13:45  <wumpus> yes https://github.com/bitcoin/bitcoin/pull/9512/files#diff-2513c35abb5ab245137423db2d803628R17
 5552017-01-12T19:14:02  <MarcoFalke> wumpus: Set topic for morcos?
 5562017-01-12T19:14:13  <wumpus> morcos: oh yes forgot that - current topic is still what to do before the feature freeze
 5572017-01-12T19:14:30  <wumpus> #topic  the concept of dust being tied to minrelaytxfee
 5582017-01-12T19:14:38  <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
 5592017-01-12T19:14:46  <BlueMatt> (I assume code is realatively trivial)
 5602017-01-12T19:14:52  <morcos> BlueMatt: what about the transaltion strings
 5612017-01-12T19:15:19  <MarcoFalke> morcos: Those are "hidden" features? So no translation string
 5622017-01-12T19:15:19  <BlueMatt> wumpus: ?
 5632017-01-12T19:15:37  <MarcoFalke> I'd recommend against exposing -dustfeerate
 5642017-01-12T19:15:44  <MarcoFalke> to every user
 5652017-01-12T19:16:02  <MarcoFalke> Maybe not even at all. Just make it a const in the code.
 5662017-01-12T19:16:12  <wumpus> yes, translation freeze is at the same time as feature freeze
 5672017-01-12T19:16:19  <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.
 5682017-01-12T19:16:26  <wumpus> but if it's a debug feature it won't have translation strings, ofc
 5692017-01-12T19:16:37  <morcos> I suppose if we merge it too late, we can start with all features hidden and expose them next version
 5702017-01-12T19:16:41  *** xinxi has quit IRC
 5712017-01-12T19:17:03  <BlueMatt> ehh, I'd say the diff is pretty trivial, lets just target it for monday?
 5722017-01-12T19:17:14  <BlueMatt> (at the risk of piling on top of the other 4)
 5732017-01-12T19:17:23  <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...
 5742017-01-12T19:17:58  *** LeMiner has joined #bitcoin-core-dev
 5752017-01-12T19:18:12  <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
 5762017-01-12T19:19:02  <luke-jr> morcos: eh, is it based on your own fee, or the relay min fee? I thought the latter
 5772017-01-12T19:19:58  <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
 5782017-01-12T19:20:09  <luke-jr> ah
 5792017-01-12T19:20:36  *** laurentmt has joined #bitcoin-core-dev
 5802017-01-12T19:21:05  *** jannes has quit IRC
 5812017-01-12T19:21:49  <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
 5822017-01-12T19:22:00  <wumpus> ok
 5832017-01-12T19:22:09  <BlueMatt> lets add it to the list for monday and if it slips thats ok
 5842017-01-12T19:22:19  <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
 5852017-01-12T19:22:24  <gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
 5862017-01-12T19:22:26  <gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
 5872017-01-12T19:22:28  <gribble> https://github.com/bitcoin/bitcoin/issues/8654 | Reuse sighash computations across evaluation (rebase of #4562) by jl2012 · Pull Request #8654 · bitcoin/bitcoin · GitHub
 5882017-01-12T19:22:29  <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
 5892017-01-12T19:22:30  <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
 5902017-01-12T19:22:35  *** laurentmt has quit IRC
 5912017-01-12T19:23:02  <jonasschnelli> Yes. We should
 5922017-01-12T19:23:03  <jl2012> yes, leave 8654 and 8755 for later
 5932017-01-12T19:23:03  <BlueMatt> jonasschnelli: do you have a strong desire for #9294?
 5942017-01-12T19:23:05  <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
 5952017-01-12T19:23:06  <morcos> I think 8456 can make it...  The others maybe not
 5962017-01-12T19:23:20  <jonasschnelli> Yes. 9294 must go in!
 5972017-01-12T19:23:29  <BlueMatt> morcos: its kinda light on ACKs to get merged this weekend, no?
 5982017-01-12T19:23:32  <jonasschnelli> Needs review. Has only a single utACK
 5992017-01-12T19:23:45  <BlueMatt> jonasschnelli: looks like it needs rebase?
 6002017-01-12T19:23:50  <jonasschnelli> We should also tag #9377
 6012017-01-12T19:23:51  <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
 6022017-01-12T19:24:02  *** PaulCapestany has quit IRC
 6032017-01-12T19:24:08  <BlueMatt> grrr, this list is a bit long for 4 days incl a weekend...
 6042017-01-12T19:24:12  <jonasschnelli> Oh. Yes. Needs rebase (since today)
 6052017-01-12T19:24:20  <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
 6062017-01-12T19:24:21  <luke-jr> maybe we should split up the list between different people?
 6072017-01-12T19:24:30  <wumpus> yes, it's not going to all make it
 6082017-01-12T19:24:34  <luke-jr> we don't all have to review the same stuff
 6092017-01-12T19:24:36  <wumpus> as I've said last week we should really make a choice
 6102017-01-12T19:24:44  <wumpus> instead of trying to  cram everything in
 6112017-01-12T19:24:47  *** drbolardus has quit IRC
 6122017-01-12T19:25:06  <BlueMatt> luke-jr: we dont have enough reviewers for that to work well enough :(
 6132017-01-12T19:25:07  <jonasschnelli> 9377 is a bugfix and can go in later
 6142017-01-12T19:25:23  <jonasschnelli> But please review 9294,.. is a sensitive wallet thing
 6152017-01-12T19:25:24  <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
 6162017-01-12T19:25:31  <wumpus> especiall for the wallet it seems getting reviewers is really hard
 6172017-01-12T19:25:31  <luke-jr> :<
 6182017-01-12T19:25:43  <BlueMatt> yes :(
 6192017-01-12T19:25:44  <bitcoin-git> [bitcoin] losh11 opened pull request #9534: Statoshi (master...master) https://github.com/bitcoin/bitcoin/pull/9534
 6202017-01-12T19:26:06  <bitcoin-git> [bitcoin] losh11 closed pull request #9534: Statoshi (master...master) https://github.com/bitcoin/bitcoin/pull/9534
 6212017-01-12T19:26:15  <cfields> that one's done!
 6222017-01-12T19:26:16  <jtimon> I'm afraid I will prioritize the ones that are easier for me to review either way
 6232017-01-12T19:26:25  <jonasschnelli> sure
 6242017-01-12T19:26:30  <luke-jr> wallet needs the most review after consensus-critical changes, too
 6252017-01-12T19:27:17  <jtimon> jonasschnelli: is the fact that 9377 is a bugfix a good reason to delay it?
 6262017-01-12T19:27:43  <jonasschnelli> jtimon: delay,.. more priorize because of the freeze.
 6272017-01-12T19:27:54  <BlueMatt> 9377 needs rebase
 6282017-01-12T19:27:54  <jonasschnelli> But 9377 fixes a address reuse problem ans should be in 0.14
 6292017-01-12T19:28:06  <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?
 6302017-01-12T19:28:08  <jonasschnelli> It somehow feels that all my PR needs rebase since today.
 6312017-01-12T19:28:20  <BlueMatt> ok, 9377 looks like a bugfix that can go in after monday...looks like an easy diff too
 6322017-01-12T19:28:27  <BlueMatt> can someone tag it?
 6332017-01-12T19:28:36  <luke-jr> jonasschnelli: heh, I rebased something yesterday and had to re-rebase it again today XD
 6342017-01-12T19:28:38  <jonasschnelli> 9294 should be in 0.14 because we should avoid creating more single-chain HD wallets
 6352017-01-12T19:28:51  <sipa> made it to the bus!
 6362017-01-12T19:29:02  <luke-jr> jonasschnelli: can it upgrade single-chain HD wallets?
 6372017-01-12T19:29:07  <jonasschnelli> No
 6382017-01-12T19:29:12  <jonasschnelli> That's why it should be in 0.14
 6392017-01-12T19:29:25  <luke-jr> is there a reason it cannot?
 6402017-01-12T19:29:39  <jonasschnelli> You can't split the hd chains once you have created change outputs on the external chain...
 6412017-01-12T19:29:40  <wumpus> jonasschnelli: that's a good point
 6422017-01-12T19:29:48  <jonasschnelli> well... not with consequences.
 6432017-01-12T19:29:54  <BlueMatt> sipa: yay!
 6442017-01-12T19:29:55  <jonasschnelli> like re-seed
 6452017-01-12T19:29:59  <morcos> and HD isn't released yet?
 6462017-01-12T19:30:04  <jonasschnelli> it is.
 6472017-01-12T19:30:06  <instagibbs> HD is already in 0.13
 6482017-01-12T19:30:06  <wumpus> so from the wallet features we should focus on getting #9294 in
 6492017-01-12T19:30:07  <jonasschnelli> Since 0.13
 6502017-01-12T19:30:09  <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
 6512017-01-12T19:30:16  <luke-jr> jonasschnelli: I don't understand why not. Maybe we should discuss this further after the meeting?
 6522017-01-12T19:30:22  <morcos> Ok so its a matter of not makign it worse then
 6532017-01-12T19:30:26  <wumpus> yes it is, but uses a single chain, which is inconvenient for reconstruction from a seed
 6542017-01-12T19:30:38  <jonasschnelli> Yes.
 6552017-01-12T19:30:39  <sipa> luke-jr: recovery from a seed won't correctly identify change
 6562017-01-12T19:30:44  <sipa> that's all
 6572017-01-12T19:30:50  <jonasschnelli> The change is not complex, but also not trivial
 6582017-01-12T19:31:13  <sipa> are there other wallet related changes we want to see in 0.14
 6592017-01-12T19:31:15  <sipa> ?
 6602017-01-12T19:31:28  <sipa> jonasschnelli: ?
 6612017-01-12T19:31:31  <jonasschnelli> gmaxwell and I like to have the keypool detecting in 0.14
 6622017-01-12T19:31:34  *** PaulCapestany has joined #bitcoin-core-dev
 6632017-01-12T19:31:38  <jonasschnelli> But not sure if its too late
 6642017-01-12T19:31:42  <luke-jr> what happens if I try to recover from a seed generated from a current HD wallet? ;)
 6652017-01-12T19:31:44  <sipa> i think that is too laye
 6662017-01-12T19:31:51  <jonasschnelli> Yes. It feels like
 6672017-01-12T19:31:53  <jtimon> jonasschnelli: how #9294 works with #8723 ?
 6682017-01-12T19:31:55  <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
 6692017-01-12T19:31:57  <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
 6702017-01-12T19:32:01  <luke-jr> jonasschnelli: that's a bugfix IMO
 6712017-01-12T19:32:16  <luke-jr> or potentially a bugfix, at least
 6722017-01-12T19:32:17  <jonasschnelli> 8723 has no reviews.
 6732017-01-12T19:32:22  <jonasschnelli> To late for 0.14 IMO
 6742017-01-12T19:32:29  <sdaftuar> jonasschnelli: can you remind us what keypool detecting is?
 6752017-01-12T19:32:41  <jtimon> but have you thought about how they would combine?
 6762017-01-12T19:32:44  <instagibbs> luke-jr, we have no direct recovery tools from seed AFAIK
 6772017-01-12T19:32:50  <sipa> sdaftuar: the wallet marking keys as used once they are seen in a transaction
 6782017-01-12T19:32:53  <jtimon> independently of which one goes first
 6792017-01-12T19:32:55  <instagibbs> current flow is ~same as before
 6802017-01-12T19:32:56  <luke-jr> instagibbs: but presumably we will be adding one
 6812017-01-12T19:32:58  <jonasschnelli> sdaftuar: if you use an old backup... you want to autodetect keys already been used.
 6822017-01-12T19:33:08  <instagibbs> luke-jr, indeed, which is why split will be important, right?
 6832017-01-12T19:33:22  <sdaftuar> got it, thanks
 6842017-01-12T19:33:30  <jonasschnelli> We need to check the keypool keys during SyncTransaction (each input/output) and mark the key as used when we have a match
 6852017-01-12T19:33:36  <jonasschnelli> Otherwise you re-use keys.
 6862017-01-12T19:34:11  <jonasschnelli> (if you don't topup your keypool +1000 and do a rescan before you use your old backup)
 6872017-01-12T19:34:11  <luke-jr> instagibbs: perhaps. but nothing stops someone from recovering from a pre-split seed?
 6882017-01-12T19:35:05  <jonasschnelli> luke-jr: yes. But we should at least stop creating wallets with change and normal-addresses on the same chain.
 6892017-01-12T19:35:32  <luke-jr> jonasschnelli: not disputing that.
 6902017-01-12T19:35:47  <jonasschnelli> Flexible keypath is nice.. but too late for 0.14.
 6912017-01-12T19:36:00  <jonasschnelli> The sad thing is, it will be another feature that is not downward compatible.
 6922017-01-12T19:36:10  <jonasschnelli> 0.13 HD, 0.14 HD/split, 0.15 flex-keypath
 6932017-01-12T19:36:14  <jonasschnelli> All not backward comp.
 6942017-01-12T19:36:26  <sipa> meh.
 6952017-01-12T19:36:31  <jonasschnelli> Yes. Meh.
 6962017-01-12T19:36:43  <jonasschnelli> That's why I'd like combining the HD split with other stuff.
 6972017-01-12T19:36:44  <luke-jr> surely at least HD/split can be upgraded to flex-keypath⁇
 6982017-01-12T19:36:54  <sipa> breaking backward compatibility in major releases is fine
 6992017-01-12T19:37:25  <instagibbs> Yeah why can't we upgrade to keypath?
 7002017-01-12T19:37:27  <jonasschnelli> Okay.
 7012017-01-12T19:37:37  <jonasschnelli> You can upgrade to keypath, but not downgrade
 7022017-01-12T19:37:38  * instagibbs should have actually reviewed, my bad
 7032017-01-12T19:37:48  <jonasschnelli> Use a 0.15 wallet in 0.14 as an example
 7042017-01-12T19:37:56  <jonasschnelli> But maybe its not so bad.
 7052017-01-12T19:37:58  <luke-jr> upgrade-only is okay. we have -walletupgrade for that
 7062017-01-12T19:38:08  <wumpus> don't you mean forwards compatible? backwards compatible means that it can use old wallets, which should always be possible
 7072017-01-12T19:38:29  <jonasschnelli> wumpus: right. My fault.
 7082017-01-12T19:38:34  <sipa> backward compatible means that old software can use new wallets
 7092017-01-12T19:38:41  <wumpus> but being able to use  a new wallet with an old major version is not
 7102017-01-12T19:38:43  <wumpus> huh?
 7112017-01-12T19:38:51  <jonasschnelli> perspetive thing. :)
 7122017-01-12T19:38:54  <wumpus> I thought the other way around.
 7132017-01-12T19:38:56  <jonasschnelli> *perspective
 7142017-01-12T19:39:01  <sipa> forward compatible is what you normally always have
 7152017-01-12T19:39:02  <wumpus> I don't understand it anymore then
 7162017-01-12T19:39:33  <instagibbs> wallet.dat vs Core wallet relativity...
 7172017-01-12T19:39:34  <sipa> oopz
 7182017-01-12T19:39:34  <CodeShark>  Walllet format vs. Wallet app
 7192017-01-12T19:39:36  <luke-jr> I think we have more cases than normal
 7202017-01-12T19:39:42  <sipa> maybe i am wrong too
 7212017-01-12T19:39:44  <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
 7222017-01-12T19:39:47  <sipa> i will shut up
 7232017-01-12T19:39:56  <jonasschnelli> And now we break that in 0.13, 0.14 and probably 0.15.
 7242017-01-12T19:40:07  <jonasschnelli> But fine for me.
 7252017-01-12T19:40:13  <instagibbs> jonasschnelli, OTOH, these are the kind of upgrades people desperately want...
 7262017-01-12T19:40:16  <instagibbs> for future work
 7272017-01-12T19:40:19  <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
 7282017-01-12T19:40:21  <luke-jr> jonasschnelli: there have been cases where -walletupgrade is needed, and then the wallet ceases to work in old versions
 7292017-01-12T19:40:22  <CodeShark> wallet format is forward compatible, wallet app is backward compatible
 7302017-01-12T19:40:36  <wumpus> jonasschnelli: however, new wallets created with new versions don't need to be open-able with old versions
 7312017-01-12T19:40:56  <jonasschnelli> Okay. Seems that we all agree. Good.
 7322017-01-12T19:40:58  <morcos> wumpus: +1 for those standards
 7332017-01-12T19:41:14  <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
 7342017-01-12T19:41:24  <jonasschnelli> Flexible keypath is nice. But we don't want to support BIP44 anyways thats why it's not urgent
 7352017-01-12T19:41:33  <jtimon> all these backards and forwards compatibility is confusing, softfork and hardforks are much more clear :p
 7362017-01-12T19:41:43  <petertodd> jtimon: +1
 7372017-01-12T19:41:44  <luke-jr> we should also avoid making it incompatible unintentionally; only if -walletupgrade is enabled should we bump the feature requirements of a wallet
 7382017-01-12T19:41:51  <luke-jr> jtimon: lol
 7392017-01-12T19:42:14  <luke-jr> eg, if someone tries to use the flex-keypath, throw an error instead of upgrading the wallet (unless option is enabled0
 7402017-01-12T19:45:03  <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?)
 7412017-01-12T19:45:21  <BlueMatt> well, ok, 9486 is whatever, its trivial
 7422017-01-12T19:45:24  <sdaftuar> BlueMatt: i think 8456 ought to be done, though it is true that gmaxwell keeps finding small issues
 7432017-01-12T19:45:36  <CodeShark> Please no use of the terms "evil compatibility" or "backward-forward compatibility"
 7442017-01-12T19:45:51  <BlueMatt> everything else tagged looks like a bugfix (#9490 is, right?)
 7452017-01-12T19:45:53  <gribble> https://github.com/bitcoin/bitcoin/issues/9490 | Replace FindLatestBefore used by importmuti with FindEarliestAtLeast. by gmaxwell · Pull Request #9490 · bitcoin/bitcoin · GitHub
 7462017-01-12T19:46:03  *** afk11 has quit IRC
 7472017-01-12T19:46:04  <sdaftuar> yes that is a bugfix
 7482017-01-12T19:46:04  <sipa> is #9484 on the list?
 7492017-01-12T19:46:06  <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
 7502017-01-12T19:46:06  <BlueMatt> jonasschnelli: whats up with #9461?
 7512017-01-12T19:46:08  <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
 7522017-01-12T19:46:10  <jtimon> lol evil compatibility
 7532017-01-12T19:46:18  <BlueMatt> sipa: oops, yes, add that to the list
 7542017-01-12T19:46:24  <jonasschnelli> BlueMatt: simple change. Hope we can get it into 0.14
 7552017-01-12T19:46:28  <jonasschnelli> Needs review
 7562017-01-12T19:46:29  <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?)
 7572017-01-12T19:46:35  <luke-jr> BlueMatt: do an `action` thing with the final list?
 7582017-01-12T19:46:49  <instagibbs> someone with the meeting hammer has to do that i think
 7592017-01-12T19:47:02  <luke-jr> O.o
 7602017-01-12T19:47:02  <BlueMatt> that list is much too long :(
 7612017-01-12T19:47:07  <wumpus> I've tagged 9499. Though we should stop tagging more stuff for monday.
 7622017-01-12T19:47:10  <morcos> BlueMatt: nah... we can do all those
 7632017-01-12T19:47:13  <BlueMatt> lol
 7642017-01-12T19:47:23  <wumpus> we're not going to make the current list
 7652017-01-12T19:47:24  <morcos> I think they are almost all ready for merge except perhaps 9294
 7662017-01-12T19:47:27  <luke-jr> maybe we should sort the list by priority
 7672017-01-12T19:47:43  <luke-jr> otherwise we're liable to work on opposite ones first and get none done
 7682017-01-12T19:47:47  <BlueMatt> i dont think 8456 is gonna make that, either
 7692017-01-12T19:48:05  <morcos> in 2 hours it'll have 2 ACK's, but if it doesn't make it, thats fine
 7702017-01-12T19:48:28  <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
 7712017-01-12T19:48:31  <gribble> https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub
 7722017-01-12T19:48:34  * sipa imagines creating a few sockpuppet accounts on github now
 7732017-01-12T19:48:40  <sipa> *morcos
 7742017-01-12T19:48:40  <jonasschnelli> heh
 7752017-01-12T19:48:45  <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
 7762017-01-12T19:48:46  <luke-jr> sipa: that'd violate github tos :P
 7772017-01-12T19:48:49  <cfields> (it belongs in 9441, i just left it out because you already had one)
 7782017-01-12T19:49:03  <jonasschnelli> luke-jr: depends how many kids you have
 7792017-01-12T19:49:08  <BlueMatt> cfields: oh fuck I forgot about the cs_vSend split there
 7802017-01-12T19:49:15  <jtimon> 9380 seems easy to review, more about deciding what to expose now and what to leave for later
 7812017-01-12T19:49:24  <BlueMatt> argh, well I can open it in its own pr, but that one's gonna be a rush if we want it
 7822017-01-12T19:49:28  <BlueMatt> it is a huge win, though :/
 7832017-01-12T19:49:38  <luke-jr> jonasschnelli: account terms #1 You must be 13 years or older to use this Service.
 7842017-01-12T19:49:39  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
 7852017-01-12T19:49:44  <luke-jr> …
 7862017-01-12T19:50:18  <sipa> hah
 7872017-01-12T19:50:20  <jonasschnelli> heh
 7882017-01-12T19:50:28  <cfields> BlueMatt: indeed. I think it's quite simple, though
 7892017-01-12T19:51:12  *** paveljanik has joined #bitcoin-core-dev
 7902017-01-12T19:51:12  *** paveljanik has joined #bitcoin-core-dev
 7912017-01-12T19:51:38  <jtimon> any other topics?
 7922017-01-12T19:51:41  <jtimon> 10 min
 7932017-01-12T19:52:04  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9535: Split CNode::cs_vSend: message processing and message sending (master...2017-01-cs-vsend-split) https://github.com/bitcoin/bitcoin/pull/9535
 7942017-01-12T19:52:43  <cfields> BlueMatt: thanks. Will scrutinize.
 7952017-01-12T19:53:50  <BlueMatt> wumpus: dont kill me, but ^ is kinda worth doing for monday :(
 7962017-01-12T19:54:10  <wumpus> they're all worth doing, that's not the question
 7972017-01-12T19:54:14  <luke-jr> it's not the end of the world if we don't have all optimisations in for 0.14 >_<K
 7982017-01-12T19:54:20  <BlueMatt> true
 7992017-01-12T19:54:23  <wumpus> agree luke-jr
 8002017-01-12T19:55:08  <wumpus> let's leave something for 0.15
 8012017-01-12T19:55:19  <BlueMatt> oh I've got lots for 0.15 already :p
 8022017-01-12T19:55:41  <wumpus> of which at least half will probably miss 0.15 and only make it to 0.16 :)
 8032017-01-12T19:55:47  <BlueMatt> oh yea
 8042017-01-12T19:55:50  <BlueMatt> always do
 8052017-01-12T19:55:52  <luke-jr> XD
 8062017-01-12T19:56:06  <luke-jr> it's not like we have 3 years between releases ☺
 8072017-01-12T19:56:09  <wumpus> that's how it goes, there's no other way if you have time based releases
 8082017-01-12T19:56:29  <BlueMatt> anyway, so lets call the meeting?
 8092017-01-12T19:56:37  <wumpus> and without a deadline we'd never agree what to put in a release and never again do a release
 8102017-01-12T19:56:37  <luke-jr> what's the phone number?
 8112017-01-12T19:56:49  <BlueMatt> wumpus: ooo, I vote for that one
 8122017-01-12T19:56:52  <luke-jr> lol
 8132017-01-12T19:56:54  <wumpus> yes, I think we're out of topics
 8142017-01-12T19:56:56  <wumpus> #endmeeting
 8152017-01-12T19:56:56  <lightningbot> Meeting ended Thu Jan 12 19:56:56 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 8162017-01-12T19:56:56  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.html
 8172017-01-12T19:56:56  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.txt
 8182017-01-12T19:56:56  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.log.html
 8192017-01-12T19:57:05  <BlueMatt> no more releases, just keep putting things in :)
 8202017-01-12T19:57:05  <luke-jr> nobody did a #action with the PR list
 8212017-01-12T19:57:13  <luke-jr> did anyone sort it?
 8222017-01-12T19:57:17  <BlueMatt> ehh, whatever
 8232017-01-12T19:57:56  <luke-jr> if nobody sorts it for me, I'm just going to review them in random order <.<
 8242017-01-12T19:58:04  *** kadoban has joined #bitcoin-core-dev
 8252017-01-12T19:58:54  <jtimon> luke-jr: they're ordered by appearence in the link above ^
 8262017-01-12T19:59:45  <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?
 8272017-01-12T20:00:10  <cfields> BlueMatt: deal.
 8282017-01-12T20:00:46  <cfields> it'll get solved as part of parallel processing
 8292017-01-12T20:01:12  <BlueMatt> not really?
 8302017-01-12T20:01:31  <BlueMatt> i mean its not going away
 8312017-01-12T20:02:52  <cfields> BlueMatt: i mean as part of SendMessages dissolving into more event-based sends
 8322017-01-12T20:03:03  <BlueMatt> how does that fix this?
 8332017-01-12T20:04:01  *** cbits has joined #bitcoin-core-dev
 8342017-01-12T20:04:18  <cfields> BlueMatt: for ex, BlockChecked could unblock all sends waiting on full verification
 8352017-01-12T20:04:36  <luke-jr> (FWIW, my prioritised list I will be using is: 9294, 8456, 9499, 9375, 8441, 9486, 9484, 9380)
 8362017-01-12T20:05:05  <cfields> (not thought through, just an off-the-cuff approach)
 8372017-01-12T20:07:11  *** cbits has quit IRC
 8382017-01-12T20:10:40  <BlueMatt> cfields: yes, possibly
 8392017-01-12T20:12:28  <instagibbs> luke-jr, 8441 is some merged thing from august..
 8402017-01-12T20:12:46  <luke-jr> oops *goes to find what he meant to put there*
 8412017-01-12T20:13:12  <cfields> luke-jr: 9441 i assume
 8422017-01-12T20:13:31  <luke-jr> yep
 8432017-01-12T20:13:38  <instagibbs> crisis averted
 8442017-01-12T20:15:25  * luke-jr wishes 9294 was multiple commits :x oh well
 8452017-01-12T20:15:41  <BlueMatt> cfields: is that sufficient for #9375?
 8462017-01-12T20:15:44  <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
 8472017-01-12T20:17:18  <BlueMatt> sipa: want to ack #9375?
 8482017-01-12T20:17:20  <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
 8492017-01-12T20:17:25  *** xinxi has joined #bitcoin-core-dev
 8502017-01-12T20:19:20  <cfields> BlueMatt: that works, thanks
 8512017-01-12T20:20:50  <sipa> wumpus: i wonder if you should choose randomized feature freeze dates, and not announce them in advance
 8522017-01-12T20:21:02  <BlueMatt> lol
 8532017-01-12T20:21:04  <BlueMatt> probably
 8542017-01-12T20:21:47  *** xinxi has quit IRC
 8552017-01-12T20:21:52  <sipa> BlueMatt: going to look over 9375 again soon
 8562017-01-12T20:40:05  *** str4d has quit IRC
 8572017-01-12T20:50:21  <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
 8582017-01-12T20:51:18  <bitcoin-git> [bitcoin] practicalswift opened pull request #9536: [trivial] Remove unused int64_t nSinceLastSeen (master...remove-unused-variable-nSinceLastSeen) https://github.com/bitcoin/bitcoin/pull/9536
 8592017-01-12T20:52:48  *** moli has quit IRC
 8602017-01-12T21:00:58  <bitcoin-git> [bitcoin] practicalswift closed pull request #9536: [trivial] Remove unused int64_t nSinceLastSeen (master...remove-unused-variable-nSinceLastSeen) https://github.com/bitcoin/bitcoin/pull/9536
 8612017-01-12T21:01:37  *** Chris_Stewart_5 has quit IRC
 8622017-01-12T21:08:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 8632017-01-12T21:09:23  *** [Author] has quit IRC
 8642017-01-12T21:11:44  *** jtimon has quit IRC
 8652017-01-12T21:11:54  <BlueMatt> luke-jr: i havent looked at that code in a long time, happy to review a pr, though :;
 8662017-01-12T21:11:56  <BlueMatt> :p
 8672017-01-12T21:18:42  *** xinxi has joined #bitcoin-core-dev
 8682017-01-12T21:20:43  <bitcoin-git> [bitcoin] luke-jr opened pull request #9537: Wallet: Refactor ReserveKeyFromKeyPool for safety (master...refactor_wallet_RKFKP) https://github.com/bitcoin/bitcoin/pull/9537
 8692017-01-12T21:23:55  <bitcoin-git> [bitcoin] practicalswift opened pull request #9538: [trivial] Remove redundant call to get() on smart pointer (thread_specific_ptr) (master...remove-redundant-get-on-smartptr) https://github.com/bitcoin/bitcoin/pull/9538
 8702017-01-12T21:27:02  *** xinxi has quit IRC
 8712017-01-12T21:30:17  <BlueMatt> cfields: sorry, found two more issues in 9441
 8722017-01-12T21:30:18  <BlueMatt> :(
 8732017-01-12T21:30:28  <cfields> BlueMatt: yep, looking them over now
 8742017-01-12T21:32:11  *** jnewbery has quit IRC
 8752017-01-12T21:32:27  <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.
 8762017-01-12T21:33:39  <BlueMatt> well right now its technically wrong
 8772017-01-12T21:33:40  <BlueMatt> soooo
 8782017-01-12T21:33:59  <BlueMatt> if someone set a stupid low nSendBufferMaxSize it might actually be triggerable, though maybe not
 8792017-01-12T21:34:14  *** kadoban has quit IRC
 8802017-01-12T21:34:27  <jeremyru1in> is there a good reason why validation.h should not include consensus/consensus.h?
 8812017-01-12T21:34:28  *** kadoban has joined #bitcoin-core-dev
 8822017-01-12T21:34:57  <BlueMatt> no?
 8832017-01-12T21:35:49  <jeremyru1in> (ok, was making some derived constants that belong in validation.h)
 8842017-01-12T21:41:31  <instagibbs> morcos, what kind of performance boost does the caching give? (asking the obvious re:relay cmpct)
 8852017-01-12T21:42:33  <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
 8862017-01-12T21:42:34  *** belcher_ has joined #bitcoin-core-dev
 8872017-01-12T21:42:44  <morcos> it greatly decreases the processing time for relay
 8882017-01-12T21:43:40  <BlueMatt> massively so, in fact
 8892017-01-12T21:44:00  <BlueMatt> luckily sipa's last round on 9375 was all pretty minor stuff
 8902017-01-12T21:44:13  *** belcher has quit IRC
 8912017-01-12T21:46:48  *** AaronVW is now known as AaronvanW
 8922017-01-12T21:47:15  *** AaronvanW has quit IRC
 8932017-01-12T21:47:15  *** AaronvanW has joined #bitcoin-core-dev
 8942017-01-12T21:47:48  *** xinxi has joined #bitcoin-core-dev
 8952017-01-12T21:52:05  *** xinxi has quit IRC
 8962017-01-12T21:55:27  *** Chris_Stewart_5 has quit IRC
 8972017-01-12T21:56:30  <bitcoin-git> [bitcoin] practicalswift opened pull request #9539: [trivial] Avoid initialization to a value that is never read (master...avoid-initialization-to-a-value-that-is-never-read) https://github.com/bitcoin/bitcoin/pull/9539
 8982017-01-12T21:56:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 8992017-01-12T22:00:25  <cfields> BlueMatt: yep, you're right.
 9002017-01-12T22:01:19  *** Chris_Stewart_5 has quit IRC
 9012017-01-12T22:03:41  *** fanquake has joined #bitcoin-core-dev
 9022017-01-12T22:04:11  *** belcher_ has quit IRC
 9032017-01-12T22:06:20  <cfields> lol, "git commit --amen" worked
 9042017-01-12T22:06:22  <cfields> praise be.
 9052017-01-12T22:06:36  <BlueMatt> wut
 9062017-01-12T22:06:56  <cfields> typo'd 'git commit --amend'
 9072017-01-12T22:07:04  <BlueMatt> lol, someone left that in as a easteregg
 9082017-01-12T22:07:06  <BlueMatt> not in man-page
 9092017-01-12T22:07:09  <gmaxwell> yep, git commit --amen works.
 9102017-01-12T22:07:16  <BlueMatt> someone go file a bug and ruin their fun :P
 9112017-01-12T22:07:27  <BlueMatt> confirmed: easter egg works here too
 9122017-01-12T22:07:54  <gmaxwell> I don't know if its an easter egg or just 'shortest unambigious prefix is accepted for maximum forward incompatiblity'
 9132017-01-12T22:08:09  <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)
 9142017-01-12T22:08:14  <cfields> seems to be that. --ame works too.
 9152017-01-12T22:08:15  <BlueMatt> i could totally see git pulling shit like that :(
 9162017-01-12T22:08:23  <BlueMatt> ffs
 9172017-01-12T22:09:32  <sipa> BlueMatt, gmaxwell: pretty sure any unambiguous prefix is intentionally accepted
 9182017-01-12T22:09:56  <sipa> sdaftuar: you need a lock for the condition variable anyway
 9192017-01-12T22:10:28  <cfields> right, it's for the condvar
 9202017-01-12T22:11:09  <cfields> sdaftuar: I was thinking the same thing as you. BlueMatt and i debated that. I lost hard.
 9212017-01-12T22:11:20  <sdaftuar> but we release the lock before calling condMsgProc.notifyAll(), don't we?
 9222017-01-12T22:11:35  <BlueMatt> sdaftuar: you cannot use a condvar without a lock.
 9232017-01-12T22:12:32  <cfields> sdaftuar: need to lock regardless, may as well stick the wake condition in it. Notifying while locked would be a pessimism, though.
 9242017-01-12T22:13:06  <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)
 9252017-01-12T22:13:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 9262017-01-12T22:14:35  <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)?
 9272017-01-12T22:15:02  <sdaftuar> is that correct?
 9282017-01-12T22:15:07  <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
 9292017-01-12T22:15:35  <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
 9302017-01-12T22:15:52  <BlueMatt> std::condition_variable_any definitely does
 9312017-01-12T22:16:45  *** belcher_ has joined #bitcoin-core-dev
 9322017-01-12T22:17:32  <sipa> sdaftuar: *waiting* on a condvar requires a lock
 9332017-01-12T22:17:44  <sdaftuar> ok, i remain deeply puzzled, but i will worry about this when i'm at my desk again
 9342017-01-12T22:17:49  <sipa> signalling can happen by anyone, anytime
 9352017-01-12T22:18:54  <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
 9362017-01-12T22:19:23  <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.
 9372017-01-12T22:19:46  <BlueMatt> gmaxwell: I absolutely am confident you could easily get a massive chunk of the network hashpower for a day or two
 9382017-01-12T22:20:18  <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
 9392017-01-12T22:20:45  <gmaxwell> BlueMatt: great 7 days is 7 times a day.
 9402017-01-12T22:21:19  <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
 9412017-01-12T22:22:15  <gmaxwell> keep in mind this also requires the vendor to ship a bad hash, seriously, you're arguing against removing the feature.
 9422017-01-12T22:22:34  <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.
 9432017-01-12T22:22:48  <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?
 9442017-01-12T22:23:50  <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
 9452017-01-12T22:24:08  <BlueMatt> belt-and-suspenders, yo
 9462017-01-12T22:24:31  <BlueMatt> s/massive sync-time feature/massive sync-time difference/
 9472017-01-12T22:24:38  <gmaxwell> on my laptop a month of blocks takes 2.25 hours to validate.
 9482017-01-12T22:25:02  <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)
 9492017-01-12T22:25:31  <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)
 9502017-01-12T22:25:44  <BlueMatt> how long with -assumevalid?
 9512017-01-12T22:25:52  <BlueMatt> (ie how much of that is non-sig-checking)
 9522017-01-12T22:26:59  <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
 9532017-01-12T22:27:44  <gmaxwell> ^ thats with a 3GB db cache..  I think it's about 30 minutes for the same span with assume valid.
 9542017-01-12T22:27:53  *** chjj has quit IRC
 9552017-01-12T22:28:32  <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.
 9562017-01-12T22:28:33  <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
 9572017-01-12T22:30:06  <luke-jr> auditing the hash is as trivial as running without it, no?
 9582017-01-12T22:30:30  <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"
 9592017-01-12T22:30:45  <gmaxwell> luke-jr: yes and checking if that block is in your chain.
 9602017-01-12T22:30:49  <BlueMatt> i mean the recommended method to audit the hash takes a day for many folks :p
 9612017-01-12T22:31:01  <BlueMatt> while the recommended way to set the hash is right before release
 9622017-01-12T22:31:16  <sipa> i'm fine with either a week or a month. </bikeshed>
 9632017-01-12T22:31:20  <gmaxwell> BlueMatt: no, it's part of the procedure that happens at the start of RCs.
 9642017-01-12T22:31:35  * instagibbs re-opens <bikeshed>
 9652017-01-12T22:32:38  <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.
 9662017-01-12T22:33:09  <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)
 9672017-01-12T22:33:14  <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
 9682017-01-12T22:33:40  <gmaxwell> If it is a massive footgun it must not be shipped.
 9692017-01-12T22:33:58  <BlueMatt> if its a massive footgun that cant go off without bitcoin being completely broken I think thats fine :p
 9702017-01-12T22:34:08  <BlueMatt> gmaxwell: how long does your sync take on your laptop start-to-finish with -assumevalid set to a week?
 9712017-01-12T22:34:16  <sipa> i think the footgun (wth is that?) is minimal
 9722017-01-12T22:34:41  <luke-jr> sipa: footgun is a gun designed for shooting one's own foot
 9732017-01-12T22:34:43  <cfields> sipa: a device one uses to shoot one's self in the foot.
 9742017-01-12T22:34:47  <TD-Linux> it's a footgun that only triggers when you've already lost your legs.
 9752017-01-12T22:34:57  <sipa> to exploit it, the attacker would need to have an invalid majority branch already mined at the time of software relwase
 9762017-01-12T22:35:02  <BlueMatt> (if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw)
 9772017-01-12T22:35:13  *** jtimon has joined #bitcoin-core-dev
 9782017-01-12T22:35:47  <sipa> or is the issue not the hardcoded value, but people convincing others to run with a certain settings value?
 9792017-01-12T22:35:51  <gmaxwell> BlueMatt: with my large db cache, about 5 hours in a chainstate reindex. I can do more recent numbers later this week.
 9802017-01-12T22:36:06  <luke-jr> sipa: or trick the user into configuring a majority invalid branch
 9812017-01-12T22:36:17  <BlueMatt> so its 5 hours -> 7.5 hours if we set it to a month?
 9822017-01-12T22:36:29  <BlueMatt> or 5 -> 7.25
 9832017-01-12T22:36:41  <sipa> luke-jr: but they'd need to already have that invalid branch mined, and ahead by a week?
 9842017-01-12T22:36:57  <gmaxwell> If I never stuck that check in none of you would have suggested it.
 9852017-01-12T22:37:01  <BlueMatt> or, i guess 5 + (2.25/4) = 5.5 -> 7.25
 9862017-01-12T22:37:08  <BlueMatt> gmaxwell: (if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw)
 9872017-01-12T22:37:14  <jtimon> luke-jr: right, that's much better justification for the one week thing than the "artificially setting it 'too earlly' in releases" IMO
 9882017-01-12T22:37:16  <gmaxwell> I think you're wrong.
 9892017-01-12T22:37:21  <luke-jr> sipa: not necessarily
 9902017-01-12T22:37:23  <BlueMatt> I'm not sure I would have suggested said check, but if weren't there I'd be saying uhhh, lets not
 9912017-01-12T22:37:29  <luke-jr> ahead by a week, yes, but not already-mined
 9922017-01-12T22:37:51  <sipa> BlueMatt: what specific attack scenario are you worried about?
 9932017-01-12T22:38:00  <sipa> (honest question)
 9942017-01-12T22:38:19  <gmaxwell> BlueMatt: (my blunt assumption is based on that you haven't been contributing to removing the existing checkpoints, no insult intended)
 9952017-01-12T22:39:10  <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
 9962017-01-12T22:39:42  <BlueMatt> its kinda weird, but definitely not impossible
 9972017-01-12T22:39:57  *** str4d has joined #bitcoin-core-dev
 9982017-01-12T22:40:03  <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?
 9992017-01-12T22:40:06  <sipa> BlueMatt: but the assumevalid setting value is only known after creating that branch
10002017-01-12T22:40:20  <gmaxwell> BlueMatt: I believe so.
10012017-01-12T22:40:21  <BlueMatt> gmaxwell: if thats the case, I might be convinced that a month is too long and we should go with 2 weeks
10022017-01-12T22:40:44  <BlueMatt> sipa: creating the start of the branch, not actually having to actively keep it up to sync all that well
10032017-01-12T22:40:45  <luke-jr> sipa: you'd make the transactions after your assumevalid all be valid
10042017-01-12T22:40:58  <BlueMatt> luke-jr: huh? no, you wouldnt
10052017-01-12T22:41:05  <luke-jr> BlueMatt: why not?
10062017-01-12T22:41:14  <BlueMatt> you would make all the txn before your assumevalid be valid
10072017-01-12T22:41:15  <BlueMatt> not after
10082017-01-12T22:41:19  <BlueMatt> well, and including, i think
10092017-01-12T22:41:26  <luke-jr> before it, they won't check if it's valid
10102017-01-12T22:41:27  * gmaxwell flies
10112017-01-12T22:41:29  <jtimon> BlueMatt: he means as an attacker
10122017-01-12T22:41:32  <luke-jr> so that's where you'd want to hide the invalid stuff
10132017-01-12T22:41:43  <sipa> BlueMatt: if at any point your attacker branch is overtaken by the honest branch, assumevalid has no more effect
10142017-01-12T22:41:43  <BlueMatt> oh, i see your point, ok
10152017-01-12T22:42:07  <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
10162017-01-12T22:42:17  <BlueMatt> but maybe only like 5/6 days, and probably not much longer
10172017-01-12T22:42:27  *** Guyver2 has quit IRC
10182017-01-12T22:42:43  <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
10192017-01-12T22:43:20  <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
10202017-01-12T22:44:36  <luke-jr> anyhow, this all requires getting the user to manually set the block hash
10212017-01-12T22:44:43  <luke-jr> IMO just hide it as a debug option and we're fixed
10222017-01-12T22:44:49  <BlueMatt> luke-jr: I think you missed part, above
10232017-01-12T22:44:53  <luke-jr> ?
10242017-01-12T22:46:12  <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
10252017-01-12T22:46:31  <BlueMatt> then you reveal that you've pwned all the pool servers and start mining invalid garbage for a few days
10262017-01-12T22:46:55  <BlueMatt> its kinda a strange scenario, and seems pretty highly unlikely, but I do not believe it is impossible
10272017-01-12T22:47:09  <luke-jr> BlueMatt: how will your invalid chain get accepted?
10282017-01-12T22:47:20  <BlueMatt> it wont be accepted by anyone except your target?
10292017-01-12T22:47:28  <luke-jr> why would it be accepted by your target, though?
10302017-01-12T22:47:36  <luke-jr> he'd need to set the config option to your malicious block hash
10312017-01-12T22:47:44  <jtimon> huhm, what does mining invalid garbage on top of your fake invalid assumevalid give you?
10322017-01-12T22:47:47  <BlueMatt> because you got them to set the assumevalid setting?
10332017-01-12T22:47:59  <BlueMatt> luke-jr: yes, did you miss the part where they set up their bitcoin node based on your instructions?
10342017-01-12T22:48:21  <jtimon> right, the ate the invalid stuff belowe your fake assumevalid, but not above it
10352017-01-12T22:48:49  <jtimon> s/the/they s/belowe/below
10362017-01-12T22:48:56  <luke-jr> ok, so the user is an idiot who will set the option without investigating what it does
10372017-01-12T22:49:03  *** xinxi has joined #bitcoin-core-dev
10382017-01-12T22:49:04  <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
10392017-01-12T22:49:12  <BlueMatt> luke-jr: most users do shit like that....
10402017-01-12T22:49:15  <luke-jr> what if we rename it to assumevalid_this_can_compromise_your_node?
10412017-01-12T22:49:18  <BlueMatt> luke-jr: fuck, many users use the ppa
10422017-01-12T22:50:05  <jtimon> Ok, so precisely this attack is what the 1 week thing serves for, no?
10432017-01-12T22:50:06  <luke-jr> can't blame them. using the PPA makes a lot of sense considering they already trust Canonical.
10442017-01-12T22:50:29  <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
10452017-01-12T22:51:11  <jtimon> BlueMatt: thus you propose to change it to 2 weeks ? (sorry, I should have read all the logs before intervening)
10462017-01-12T22:51:12  <BlueMatt> gmaxwell: does 2 weeks meet your performance target? its more like an extra half hour
10472017-01-12T22:51:45  <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
10482017-01-12T22:52:03  <BlueMatt> which does seem like a big cost to pay
10492017-01-12T22:52:17  <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?
10502017-01-12T22:52:25  <BlueMatt> yes
10512017-01-12T22:52:35  <BlueMatt> thats only if you sync within the first week of the release
10522017-01-12T22:52:43  <BlueMatt> well, first week after the hash was selected/set
10532017-01-12T22:53:45  *** xinxi has quit IRC
10542017-01-12T22:54:10  <jtimon> I don't oppose changing it to 2 weeks, it's performance vs a more cautious protection against a possible attack
10552017-01-12T22:56:55  *** chjj has joined #bitcoin-core-dev
10562017-01-12T22:57:10  <jtimon> I mean, even with a month it's a great improvement over the checkpoint way
10572017-01-12T22:58:15  <BlueMatt> oh, totally I think we should do this, just prefer a tiny inch more conservatism
10582017-01-12T22:58:37  <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.
10592017-01-12T22:59:02  <jtimon> and I'm happy with both 2 or 1 week, so I don't have anything to convince you about
10602017-01-12T22:59:34  <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
10612017-01-12T22:59:48  <BlueMatt> whereas "download from this random site" might be a bit more alarming to folks
10622017-01-12T23:00:20  <jtimon> cfields: well, if you can send them an "evil binary" the whole assumevalid thing is irrelevant: you can change the rules!
10632017-01-12T23:00:40  <cfields> jtimon: that was exactly my point.
10642017-01-12T23:00:48  <jtimon> a bad bitcoin.conf seems more realistic
10652017-01-12T23:00:49  <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
10662017-01-12T23:01:13  <jtimon> "here's my bitcoin.conf, copy it, it syncs super-fast"
10672017-01-12T23:01:31  <BlueMatt> then double because the honest chain has to catch back up
10682017-01-12T23:03:05  <cfields> jtimon: given the example above, undermining the majority of hashpower, surely getting them to run my binary is trivial in comparison
10692017-01-12T23:04:05  <BlueMatt> cfields: you massively underestimate how trivial it is to pwn most pool servers' hosting providers
10702017-01-12T23:04:27  <BlueMatt> also, remember that there is no auth on stratum
10712017-01-12T23:05:04  *** fanquake has quit IRC
10722017-01-12T23:05:25  <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
10732017-01-12T23:05:43  <jtimon> cfields: maybe it's that I underestimate the loss of using 1 month instead of 1 week...
10742017-01-12T23:08:20  <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)
10752017-01-12T23:09:22  <BlueMatt> ehh, I'm not sure about that, though I absolutely agree the example attack given above is not the most robust example
10762017-01-12T23:16:27  <cfields> BlueMatt: updated 9441. Now going over 9375 one last time.
10772017-01-12T23:23:07  *** chjj has quit IRC
10782017-01-12T23:31:49  *** PaulCapestany has quit IRC
10792017-01-12T23:37:39  *** chjj has joined #bitcoin-core-dev
10802017-01-12T23:42:09  *** PaulCapestany has joined #bitcoin-core-dev
10812017-01-12T23:50:12  *** str4d has quit IRC
10822017-01-12T23:57:07  *** wvr has quit IRC