1 2017-01-12T00:16:38  *** cheese_ has quit IRC
   2 2017-01-12T00:29:56  *** JackH has quit IRC
   3 2017-01-12T00:42:20  *** MarcoFalke has joined #bitcoin-core-dev
   4 2017-01-12T00:44:26  <gmaxwell> oh good, you can thumbs up your own comments on github.
   5 2017-01-12T00:44:33  <gmaxwell> My life is now complete.
   6 2017-01-12T00:47:42  <luke-jr> lol
   7 2017-01-12T00:54:53  *** OfficialLeibniz is now known as officia||eibniz
   8 2017-01-12T00:57:28  *** Ylbam has quit IRC
   9 2017-01-12T00:58:02  <midnightmagic> I love thumbs-upping my own posts. It aggravates some of the kinds of people I like aggravating. :-)
  10 2017-01-12T00:58:16  <gmaxwell> sipa: thanks for the ack on #9484.
  11 2017-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
  12 2017-01-12T01:00:14  *** abpa has quit IRC
  13 2017-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?
  14 2017-01-12T01:12:54  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/05950427d310...0b738075bd43
  15 2017-01-12T01:12:55  <bitcoin-git> bitcoin/master 54ee3fc Michael Rotarius: RPC help updated
  16 2017-01-12T01:12:55  <bitcoin-git> bitcoin/master 0b73807 MarcoFalke: Merge #9297: Various RPC help outputs updated...
  17 2017-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
  18 2017-01-12T01:16:07  *** cbits has joined #bitcoin-core-dev
  19 2017-01-12T01:16:18  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b738075bd43...9ec1330b455c
  20 2017-01-12T01:16:18  <bitcoin-git> bitcoin/master faaf3ca MarcoFalke: travis: make distdir before make
  21 2017-01-12T01:16:19  <bitcoin-git> bitcoin/master 9ec1330 MarcoFalke: Merge #9416: travis: make distdir before make...
  22 2017-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
  23 2017-01-12T01:19:56  <gmaxwell> I finally figured out why I wasn't getting any github emails.
  24 2017-01-12T01:21:29  <midnightmagic> Whyzzat
  25 2017-01-12T01:26:23  <gmaxwell> I configured an email rule to put them in another folder...
  26 2017-01-12T01:27:02  *** d9b4bef9 has quit IRC
  27 2017-01-12T01:28:08  *** d9b4bef9 has joined #bitcoin-core-dev
  28 2017-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
  29 2017-01-12T01:31:43  <gmaxwell> well I still may be only getting half.
  30 2017-01-12T01:32:17  <gmaxwell> But I'm not getting none.
  31 2017-01-12T01:39:18  <MarcoFalke> except: pass
  32 2017-01-12T01:39:25  <MarcoFalke> why is this still a thing?
  33 2017-01-12T01:41:40  <midnightmagic> haha
  34 2017-01-12T01:44:56  *** AaronvanW has quit IRC
  35 2017-01-12T01:45:25  <luke-jr> gmaxwell: why does #8775 need rebase? O.o
  36 2017-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
  37 2017-01-12T01:47:55  <gmaxwell> why is that linking issues?
  38 2017-01-12T01:48:04  *** cbits has quit IRC
  39 2017-01-12T01:48:16  <gmaxwell> luke-jr: ask git, not me, it doesn't apply cleanly to master.
  40 2017-01-12T01:48:29  <gmaxwell> (git am -3 <patch> fails)
  41 2017-01-12T01:49:59  <luke-jr> gmaxwell: I ask only because both git and github merge it cleanly :x
  42 2017-01-12T01:50:31  <gmaxwell> gah whitespace errors
  43 2017-01-12T01:51:59  <gmaxwell> MarcoFalke: does your git diff not show crazy whitespace as wads of red?
  44 2017-01-12T01:52:08  <MarcoFalke> It does
  45 2017-01-12T01:52:27  <gmaxwell> K. #9297 added big wads of end of line whitespace.
  46 2017-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
  47 2017-01-12T01:52:35  <gmaxwell> no biggie.
  48 2017-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.
  49 2017-01-12T01:53:41  <gmaxwell> luke-jr: just catches fire here.
  50 2017-01-12T01:53:41  <gmaxwell> fatal: sha1 information is lacking or useless (src/wallet/rpcdump.cpp).
  51 2017-01-12T01:53:45  <gmaxwell> error: could not build fake ancestor
  52 2017-01-12T01:53:47  <gmaxwell> Patch failed at 0007 More tightly couple EnsureWalletIsAvailable with GetWalletForJSONRPCRequest where appropriate
  53 2017-01-12T01:54:31  <MarcoFalke> At some point I feel we need to merge a pull. It can't be always free of µnits...
  54 2017-01-12T01:54:38  <MarcoFalke> We have more pressing issues right now.
  55 2017-01-12T01:54:53  <luke-jr> gmaxwell: what if you use git-merge? could you have an old branch?
  56 2017-01-12T01:55:12  <MarcoFalke> But otoh I understand. Someone will fix it some day...
  57 2017-01-12T01:55:16  <gmaxwell> luke-jr: that is in a current checkout vs the patch from github.
  58 2017-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. :)
  59 2017-01-12T01:55:59  <MarcoFalke> ok
  60 2017-01-12T01:56:46  *** fanquake has joined #bitcoin-core-dev
  61 2017-01-12T01:57:15  <luke-jr> gmaxwell: looks specific to git-am. merging it normally works
  62 2017-01-12T01:59:46  <gmaxwell> okay, well I'm not testing it unless it merges with git-am.
  63 2017-01-12T02:01:25  <luke-jr> ok, rebased and seems to work now
  64 2017-01-12T02:02:50  <gmaxwell> YUP!
  65 2017-01-12T02:02:52  <gmaxwell> thanks.
  66 2017-01-12T02:08:23  *** cbits has joined #bitcoin-core-dev
  67 2017-01-12T02:11:40  *** xinxi has joined #bitcoin-core-dev
  68 2017-01-12T02:16:14  *** xinxi has quit IRC
  69 2017-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.
  70 2017-01-12T02:21:37  <gribble> https://github.com/bitcoin/bitcoin/issues/8639 | [Docs] Minimum required dependencies and current CVEs · Issue #8639 · bitcoin/bitcoin · GitHub
  71 2017-01-12T02:22:49  <sipa> for non-qt we only need openssl for the PRNG
  72 2017-01-12T02:23:11  <sipa> which i think means very old versions will work
  73 2017-01-12T02:23:22  <sipa> not sure if we should suggest that, though
  74 2017-01-12T02:25:26  <gmaxwell> and our use of it in the rng could darn near be replaced with rand()
  75 2017-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.
  76 2017-01-12T02:26:24  <fanquake> We are currently using 1.0.1k in depends.
  77 2017-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.
  78 2017-01-12T02:28:07  <MarcoFalke> How come that doxygen still has main.cpp?
  79 2017-01-12T02:28:09  <MarcoFalke> https://dev.visucore.com/bitcoin/doxygen/main_8cpp_source.html
  80 2017-01-12T02:28:35  <MarcoFalke> Generated on Wed Jan 11 2017
  81 2017-01-12T02:28:42  <MarcoFalke> We killed that last year
  82 2017-01-12T02:29:30  <fanquake> gmaxwell ok, thanks.
  83 2017-01-12T02:29:36  <gmaxwell> MarcoFalke: whatever is generating it is on a forked repository?
  84 2017-01-12T02:30:20  <achow101> apparently decoderawtransaction is not decoding segwit txs properly: https://bitcointalk.org/index.php?topic=1748353.msg17477509#msg17477509
  85 2017-01-12T02:30:50  <MarcoFalke> ^ wumpus can you take a look at doxygen, please?
  86 2017-01-12T02:34:12  *** arowser has quit IRC
  87 2017-01-12T02:38:03  <gmaxwell> achow101: The issue is that segwit txn deseralizes as a 'crazy' non-segwit txn-- one with zero input transactions.
  88 2017-01-12T02:38:27  <gmaxwell> achow101: the decodehex tries to decode as non-segwit first and then segwit, but that txn successfully decodes.
  89 2017-01-12T02:39:00  <achow101> is that just bad luck then that it is able to successfully decode as non-segwit first?
  90 2017-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.
  91 2017-01-12T02:39:35  *** Chris_Stewart_5 has quit IRC
  92 2017-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.
  93 2017-01-12T02:40:04  <gmaxwell> But I think that is likely the correct fix.
  94 2017-01-12T02:40:12  <gmaxwell> or most correct.
  95 2017-01-12T02:40:18  <sipa> didn't we fix that already?
  96 2017-01-12T02:40:39  <gmaxwell> sipa: for decoderawtransactions?  my description is from reading the current code.
  97 2017-01-12T02:41:32  <achow101> what use case is there for 0 input txns?
  98 2017-01-12T02:41:35  <gmaxwell> an alternative would be to reverse the trial order, so it won't even try nonwit unless witness fails.
  99 2017-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.)
 100 2017-01-12T02:42:24  <sipa> raw transactions are more often used for unsigned transactions
 101 2017-01-12T02:42:31  <sipa> which by definition aren't segwit
 102 2017-01-12T02:42:45  <achow101> oh
 103 2017-01-12T02:43:08  <sipa> once they're signed, they're usually complete
 104 2017-01-12T02:43:21  <sipa> but it's unfortunate that there is ambiguity
 105 2017-01-12T02:43:48  <sipa> we should propose some 'partially signed' transaction format
 106 2017-01-12T02:43:54  <sipa> that's unambiguous
 107 2017-01-12T02:43:59  *** fanquake has quit IRC
 108 2017-01-12T02:44:03  <sipa> but has place for metadata etc
 109 2017-01-12T02:44:13  <gmaxwell> well in particular, amounts and scriptpubkeys.
 110 2017-01-12T02:44:23  <achow101> gmaxwell: what about having decoderawtx take a parameter to tell it to decode as segwit or non
 111 2017-01-12T02:44:44  <gmaxwell> achow101: thats a bit ugly.
 112 2017-01-12T02:44:44  <achow101> and have that somehow be related to soft fork activation
 113 2017-01-12T02:44:57  <gmaxwell> achow101: thats more than a bit ugly. :P
 114 2017-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?
 115 2017-01-12T02:47:56  <gmaxwell> sdaftuar: sure, except for this bug.
 116 2017-01-12T02:47:59  <gmaxwell> just shows now inputs.
 117 2017-01-12T02:48:13  *** face has quit IRC
 118 2017-01-12T02:48:17  <gmaxwell> I suppose it being unwilling wouldn't be the end of the world.
 119 2017-01-12T02:48:28  <sipa> decoderawtransaction and fundraetransaction both attempt old and new deserialization
 120 2017-01-12T02:48:33  <gmaxwell> it's not like I could sign a zero input transaction.
 121 2017-01-12T02:49:01  <sipa> but they only accept the old serialization if it exactly matches the string
 122 2017-01-12T02:49:13  <sipa> (no undecoded garbage at the end)
 123 2017-01-12T02:49:21  *** face has joined #bitcoin-core-dev
 124 2017-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.
 125 2017-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
 126 2017-01-12T02:54:37  <sipa> decodehextx gets a bool arg
 127 2017-01-12T02:54:56  <sipa> to indicate if non-extended format decoding should be attempted
 128 2017-01-12T02:55:07  <sipa> only decoderawtx and fundrawtx set that bool to true
 129 2017-01-12T02:55:12  <gmaxwell> that should be false for sendraw.
 130 2017-01-12T02:55:20  <sipa> it iz
 131 2017-01-12T02:55:22  <sipa> it is
 132 2017-01-12T02:55:30  <gmaxwell> iz was okay too.
 133 2017-01-12T02:56:00  <sipa> i zhall rezord do uzing voized vowelz vrom now on
 134 2017-01-12T02:56:15  *** arowser has joined #bitcoin-core-dev
 135 2017-01-12T02:56:16  <gmaxwell> oh dear.
 136 2017-01-12T02:56:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 137 2017-01-12T02:57:33  *** arowser has quit IRC
 138 2017-01-12T02:59:17  *** Kexkey has joined #bitcoin-core-dev
 139 2017-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.
 140 2017-01-12T03:00:33  <gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
 141 2017-01-12T03:00:41  <sdaftuar> bumper* transaction
 142 2017-01-12T03:02:05  *** JackH has joined #bitcoin-core-dev
 143 2017-01-12T03:03:40  *** baldur has quit IRC
 144 2017-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...
 145 2017-01-12T03:04:09  *** arowser has joined #bitcoin-core-dev
 146 2017-01-12T03:04:09  *** Chris_Stewart_5 has quit IRC
 147 2017-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
 148 2017-01-12T03:05:59  *** xinxi has joined #bitcoin-core-dev
 149 2017-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
 150 2017-01-12T03:06:29  <sdaftuar> seems reasonable to me
 151 2017-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
 152 2017-01-12T03:08:53  *** arowser has quit IRC
 153 2017-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
 154 2017-01-12T03:11:49  <sipa> instead of basing it on hex bytes
 155 2017-01-12T03:12:36  *** MarcoFalke has quit IRC
 156 2017-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
 157 2017-01-12T03:13:55  <sipa> no
 158 2017-01-12T03:14:09  <sipa> you've just implemented a "prefer extended" stratwgy
 159 2017-01-12T03:14:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 160 2017-01-12T03:15:51  <achow101> but then how do you know which strategy to choose?
 161 2017-01-12T03:16:11  <sipa> decoderawtransaction would use prefer extended
 162 2017-01-12T03:16:28  <sipa> fundrawtransaction would use prefer olf
 163 2017-01-12T03:16:36  <sipa> all the rest would be extended only
 164 2017-01-12T03:16:37  *** baldur has joined #bitcoin-core-dev
 165 2017-01-12T03:16:44  <achow101> oh.
 166 2017-01-12T03:16:49  <sipa> that's what you have implemented now
 167 2017-01-12T03:16:58  <achow101> I see
 168 2017-01-12T03:18:16  *** Kexkey has quit IRC
 169 2017-01-12T03:20:21  <achow101> I can make that change
 170 2017-01-12T03:27:43  <sipa> actually
 171 2017-01-12T03:28:05  <sipa> what if you just pass false to decodehextx in decoderawtransaction?
 172 2017-01-12T03:28:18  <sipa> i believe the behavior will be the same as what you have now
 173 2017-01-12T03:29:03  <achow101> then it will be decoding all transactions as extended
 174 2017-01-12T03:30:31  <sipa> yes
 175 2017-01-12T03:30:44  <sipa> that's what you want, no?
 176 2017-01-12T03:31:23  <sipa> the extended format for transactions without witness is identical to the old format
 177 2017-01-12T03:31:47  <achow101> right
 178 2017-01-12T03:31:54  <achow101> yes, that should work.
 179 2017-01-12T03:32:56  <achow101> why was it passing in true originally then?
 180 2017-01-12T03:33:44  <sipa> to pick old decoding in case it was ambiguous
 181 2017-01-12T03:34:07  <sipa> which is what you want for fundrawtransaction
 182 2017-01-12T03:34:16  <sipa> but perhaps not for decoderawtransaction
 183 2017-01-12T03:34:34  <sipa> i'm not sure, it's choosing between two suboptimal options
 184 2017-01-12T03:44:32  *** cbits has quit IRC
 185 2017-01-12T03:45:01  *** PRab has quit IRC
 186 2017-01-12T03:46:03  <ZhibiaoPan> https://www.blocktrail.com/tBTC/tx/042e9225966258ec7d133d90a978d21ef1d7e4edc4800331a80f73f2d71316d8
 187 2017-01-12T03:46:16  <ZhibiaoPan> Mining Fee is -1.40625000 tBTC
 188 2017-01-12T03:46:55  <adiabat> ZhibiaoPan ... it's a coinbase tx
 189 2017-01-12T03:47:11  <ZhibiaoPan> CheckBlock() didn't check the block reward and mining fee?
 190 2017-01-12T03:47:19  *** robmcl4 has joined #bitcoin-core-dev
 191 2017-01-12T03:47:41  <achow101> the output of a coinbase can be less than the reward that the miner is entitled to
 192 2017-01-12T03:47:55  <achow101> those coins are then just permanently missing
 193 2017-01-12T03:55:41  *** Chris_Stewart_5 has quit IRC
 194 2017-01-12T04:09:08  <wumpus> marcofalke: good catch, the script that is supposed to update it was not able to fetch the repo
 195 2017-01-12T04:14:16  *** cbits has joined #bitcoin-core-dev
 196 2017-01-12T04:17:56  *** chris2000 has joined #bitcoin-core-dev
 197 2017-01-12T04:20:37  *** chris200_ has quit IRC
 198 2017-01-12T04:22:32  *** justanotheruser has joined #bitcoin-core-dev
 199 2017-01-12T04:23:45  *** officia||eibniz has quit IRC
 200 2017-01-12T05:03:17  <btcdrak> ZhibiaoPan: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1876-L1881
 201 2017-01-12T05:06:15  *** robmcl4 has quit IRC
 202 2017-01-12T05:15:02  *** Alopex has quit IRC
 203 2017-01-12T05:16:07  *** Alopex has joined #bitcoin-core-dev
 204 2017-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
 205 2017-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
 206 2017-01-12T05:22:32  <cfields> BlueMatt: yea, i almost suggested that, but it would just kinda mask the issue (usually)
 207 2017-01-12T05:22:48  <cfields> BlueMatt: to be clear, i'm not worried about the disk access _at all_
 208 2017-01-12T05:22:53  <BlueMatt> I know
 209 2017-01-12T05:22:59  <BlueMatt> I am, though, so thanks for reporting :p
 210 2017-01-12T05:23:03  <cfields> was just using it as an example
 211 2017-01-12T05:23:04  <cfields> heh
 212 2017-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
 213 2017-01-12T05:23:11  <BlueMatt> I know, I know
 214 2017-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 :)
 215 2017-01-12T05:24:03  <BlueMatt> no, I'm specifically not a fan of BlockOnThing() over DoTheThingIWantToBlockOn()
 216 2017-01-12T05:24:22  <cfields> i see
 217 2017-01-12T05:24:25  <BlueMatt> wellllll, hum
 218 2017-01-12T05:24:28  <BlueMatt> now that i say that
 219 2017-01-12T05:24:52  *** xinxi has quit IRC
 220 2017-01-12T05:25:14  <cfields> no, you're not doing anything in either action. Either way it's being treated as a fence.
 221 2017-01-12T05:25:39  <BlueMatt> well we need a fence primitive for wallet to fix #9148
 222 2017-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
 223 2017-01-12T05:25:55  <cfields> er, "not doing anything" is a very poor choice of words, that's obviously not what i meant
 224 2017-01-12T05:26:42  <BlueMatt> I mean I feel kinda yucky doing this because what if some braindead caller calls AcceptBlock without ActivateBestChain?
 225 2017-01-12T05:26:50  <BlueMatt> we then call the fence and freeze forever
 226 2017-01-12T05:26:53  <BlueMatt> is my concern
 227 2017-01-12T05:27:27  <BlueMatt> same applies for wallet, though....
 228 2017-01-12T05:27:44  <BlueMatt> hence my comment on prefering FenceButFeelFreeToDoWorkToGetThere
 229 2017-01-12T05:27:51  <BlueMatt> which is what ABC is to me, here, i guess
 230 2017-01-12T05:27:53  <cfields> BlueMatt: i was just picturing: at the top of ABC, working=true. at the bottom, working=false
 231 2017-01-12T05:28:02  <cfields> nasty hack, but that's what you really want to know, right?
 232 2017-01-12T05:28:14  <BlueMatt> no, you'd need to do that in ProcessNewBlock
 233 2017-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?
 234 2017-01-12T05:29:45  <cfields> er, nm
 235 2017-01-12T05:42:14  *** cbits has quit IRC
 236 2017-01-12T05:52:43  *** jcorgan has quit IRC
 237 2017-01-12T06:01:43  *** jcorgan has joined #bitcoin-core-dev
 238 2017-01-12T06:25:39  *** xinxi has joined #bitcoin-core-dev
 239 2017-01-12T06:31:52  *** xinxi has quit IRC
 240 2017-01-12T07:00:19  *** dermoth has quit IRC
 241 2017-01-12T07:01:05  *** dermoth has joined #bitcoin-core-dev
 242 2017-01-12T07:01:11  *** chjj has quit IRC
 243 2017-01-12T07:05:29  *** xinxi has joined #bitcoin-core-dev
 244 2017-01-12T07:18:49  *** Ylbam has joined #bitcoin-core-dev
 245 2017-01-12T07:28:14  *** chjj has joined #bitcoin-core-dev
 246 2017-01-12T07:45:22  *** wasi has quit IRC
 247 2017-01-12T07:45:55  *** wasi has joined #bitcoin-core-dev
 248 2017-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?
 249 2017-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...
 250 2017-01-12T08:03:46  <jonasschnelli> Oh. Github down?
 251 2017-01-12T08:08:03  *** BashCo has quit IRC
 252 2017-01-12T08:08:44  *** BashCo has joined #bitcoin-core-dev
 253 2017-01-12T08:08:48  <whphhg> Yup, seems so
 254 2017-01-12T08:09:14  <rabidus> yup
 255 2017-01-12T08:09:22  * jonasschnelli doesn't like the unicorn...
 256 2017-01-12T08:13:10  *** BashCo has quit IRC
 257 2017-01-12T08:25:24  *** droark has joined #bitcoin-core-dev
 258 2017-01-12T08:26:20  *** kadoban has quit IRC
 259 2017-01-12T08:26:21  *** goregrin1 is now known as goregrind
 260 2017-01-12T08:28:48  *** Cheeseo has quit IRC
 261 2017-01-12T08:37:03  *** BashCo has joined #bitcoin-core-dev
 262 2017-01-12T08:39:37  *** xinxi has quit IRC
 263 2017-01-12T08:57:24  *** xinxi has joined #bitcoin-core-dev
 264 2017-01-12T09:03:12  *** midnightmagic has quit IRC
 265 2017-01-12T09:04:14  *** michiel_ has joined #bitcoin-core-dev
 266 2017-01-12T09:13:42  *** jannes has joined #bitcoin-core-dev
 267 2017-01-12T09:19:57  *** Guyver2 has joined #bitcoin-core-dev
 268 2017-01-12T09:34:42  *** MarcoFalke has joined #bitcoin-core-dev
 269 2017-01-12T09:41:41  *** midnightmagic has joined #bitcoin-core-dev
 270 2017-01-12T09:47:31  *** wasi has quit IRC
 271 2017-01-12T09:47:53  *** wasi has joined #bitcoin-core-dev
 272 2017-01-12T09:54:00  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9ec1330b455c...2456a835f0bc
 273 2017-01-12T09:54:00  <bitcoin-git> bitcoin/master db904db Pieter Wuille: Deprecate non-txindex getrawtransaction and better warning
 274 2017-01-12T09:54:01  <bitcoin-git> bitcoin/master 2456a83 MarcoFalke: Merge #9520: Deprecate non-txindex getrawtransaction and better warning...
 275 2017-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
 276 2017-01-12T10:16:29  <MarcoFalke> Thanks for fixing doxygen, wumpus!
 277 2017-01-12T10:38:40  <MarcoFalke> What is the desired behavior of pruneblockchain(0)?
 278 2017-01-12T10:41:28  *** AaronVW has joined #bitcoin-core-dev
 279 2017-01-12T10:49:26  *** jannes has quit IRC
 280 2017-01-12T10:51:58  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2456a835f0bc...a65ced1a6657
 281 2017-01-12T10:51:58  <bitcoin-git> bitcoin/master 918d1fb Russell Yanofsky: Return height of last block pruned by pruneblockchain RPC...
 282 2017-01-12T10:51:59  <bitcoin-git> bitcoin/master a65ced1 MarcoFalke: Merge #9518: Return height of last block pruned by pruneblockchain RPC...
 283 2017-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
 284 2017-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
 285 2017-01-12T11:02:48  *** jannes has joined #bitcoin-core-dev
 286 2017-01-12T11:03:54  <MarcoFalke> We should probably just only allow a single code style with all known bad practices eliminated.
 287 2017-01-12T11:06:23  <MarcoFalke> python should stop interpreting when it sees smelly code and gcc should fail to compile.
 288 2017-01-12T11:13:40  <bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/a65ced1a6657...fac0f30482d5
 289 2017-01-12T11:13:41  <bitcoin-git> bitcoin/master a4bac66 Pieter Wuille: [MOVEONLY] Move progress estimation out of checkpoints
 290 2017-01-12T11:13:42  <bitcoin-git> bitcoin/master 3641141 Pieter Wuille: Move tx estimation data out of CCheckPointData
 291 2017-01-12T11:13:42  <bitcoin-git> bitcoin/master 6dd8116 Pieter Wuille: Remove SIGCHECK_VERIFICATION_FACTOR
 292 2017-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
 293 2017-01-12T11:18:13  <wumpus> MarcoFalke: continuing without crashing :-)
 294 2017-01-12T11:24:59  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/fac0f30482d5...d5d4ad87afbf
 295 2017-01-12T11:25:00  <bitcoin-git> bitcoin/master 1814b08 Stanislas Marion: add p2sh and segwit options to bitcoin-tx outscript command
 296 2017-01-12T11:25:00  <bitcoin-git> bitcoin/master 61a1534 jnewbery: Add all transaction output types to bitcoin-tx....
 297 2017-01-12T11:25:01  <bitcoin-git> bitcoin/master b7e144b jnewbery: Add test cases to test new bitcoin-tx functionality...
 298 2017-01-12T11:35:53  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d5d4ad87afbf...2742568a008e
 299 2017-01-12T11:35:54  <bitcoin-git> bitcoin/master dfbe0d5 Alex Morcos: Add unstored orphans with rejected parents to recentRejects
 300 2017-01-12T11:35:54  <bitcoin-git> bitcoin/master 2742568 Wladimir J. van der Laan: Merge #9261: Add unstored orphans with rejected parents to recentRejects...
 301 2017-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
 302 2017-01-12T11:46:48  <bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/2742568a008e...f9117f204756
 303 2017-01-12T11:46:49  <bitcoin-git> bitcoin/master 8ac1830 fanquake: [depends] Latest config.guess and config.sub
 304 2017-01-12T11:46:49  <bitcoin-git> bitcoin/master 4ed6faf fanquake: [depends] Boost 1.63.0
 305 2017-01-12T11:46:50  <bitcoin-git> bitcoin/master 6019d21 fanquake: [depends] FreeType 2.7.1
 306 2017-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
 307 2017-01-12T11:47:20  *** JackH has quit IRC
 308 2017-01-12T11:49:33  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f9117f204756...7cb024eba68b
 309 2017-01-12T11:49:33  <bitcoin-git> bitcoin/master 453bda6 Chris Moore: Add 'subtractFeeFromOutputs' option to 'fundrawtransaction'.
 310 2017-01-12T11:49:34  <bitcoin-git> bitcoin/master 7cb024e Wladimir J. van der Laan: Merge #9222: Add 'subtractFeeFromAmount' option to 'fundrawtransaction'....
 311 2017-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
 312 2017-01-12T12:15:59  <MarcoFalke> going to cancel all travis instances
 313 2017-01-12T12:23:05  *** fanquake has joined #bitcoin-core-dev
 314 2017-01-12T12:24:01  <fanquake> Let's get a few ACKs on #9525
 315 2017-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
 316 2017-01-12T12:43:18  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7cb024eba68b...02e5308c1b9f
 317 2017-01-12T12:43:18  <bitcoin-git> bitcoin/master fa29736 MarcoFalke: test: Include tx data in EXTRA_DIST
 318 2017-01-12T12:43:19  <bitcoin-git> bitcoin/master 02e5308 MarcoFalke: Merge #9525: test: Include tx data in EXTRA_DIST...
 319 2017-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
 320 2017-01-12T12:58:54  *** xinxi has quit IRC
 321 2017-01-12T12:59:21  *** xinxi has joined #bitcoin-core-dev
 322 2017-01-12T13:01:06  *** MarcoFalke has quit IRC
 323 2017-01-12T13:02:46  <da2ce7> Just tested 'make deploy' from git-head on latest mac. Works without problem :)
 324 2017-01-12T13:05:09  <wumpus> great!
 325 2017-01-12T13:09:17  <fanquake> wumpus any objection to closing 7149 ?
 326 2017-01-12T13:12:09  <wumpus> fanquake: yeah I don't think it's going to be merged as it is
 327 2017-01-12T13:14:43  *** pavel_ has joined #bitcoin-core-dev
 328 2017-01-12T13:17:38  <fanquake> wumpus yea, open for > 1yr with only 2 comments.
 329 2017-01-12T13:17:39  *** paveljanik has quit IRC
 330 2017-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.
 331 2017-01-12T13:18:07  *** pavel_ has quit IRC
 332 2017-01-12T13:19:05  *** xinxi has quit IRC
 333 2017-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
 334 2017-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
 335 2017-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
 336 2017-01-12T13:27:31  *** jtimon has joined #bitcoin-core-dev
 337 2017-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
 338 2017-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
 339 2017-01-12T13:38:04  *** xinxi has joined #bitcoin-core-dev
 340 2017-01-12T13:42:31  *** xinxi has quit IRC
 341 2017-01-12T13:42:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 342 2017-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?
 343 2017-01-12T13:44:01  <wumpus> morcos: both, though mostly the latter
 344 2017-01-12T13:44:31  <wumpus> mostly that people get confused that they're suddenly creating a different kind of transactions with different properties
 345 2017-01-12T13:44:36  <wumpus> without having asked for it
 346 2017-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 :)
 347 2017-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
 348 2017-01-12T13:45:48  <fanquake> Yes I'm sure a few things are going to get lost in there already.
 349 2017-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
 350 2017-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
 351 2017-01-12T13:46:54  <wumpus> yes
 352 2017-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
 353 2017-01-12T13:47:09  <wumpus> anywhere bumpfee is mentioned it should be made clear
 354 2017-01-12T13:48:39  <wumpus> also in the RPC help for the funcition, thinking of it
 355 2017-01-12T13:50:55  *** xinxi has joined #bitcoin-core-dev
 356 2017-01-12T13:54:11  <wumpus> in any case let's not make merging that functionality dependent on the defaults discussion
 357 2017-01-12T13:54:50  <morcos> sure agreed
 358 2017-01-12T13:55:03  *** xinxi has quit IRC
 359 2017-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 ?
 360 2017-01-12T14:08:30  <wumpus> morcos: yes, that sounds like the right approach to me
 361 2017-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?
 362 2017-01-12T14:09:14  <sipa> we should also make the rpc example code use named rgs
 363 2017-01-12T14:09:19  <sipa> *args
 364 2017-01-12T14:09:40  <sipa> and i wonder if we shouldn't first start converting some methods to natively accept names
 365 2017-01-12T14:09:47  *** xinxi has joined #bitcoin-core-dev
 366 2017-01-12T14:12:45  <fanquake> Do we really need a nearly 1100 line script to check/maintain copyright headers
 367 2017-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.
 368 2017-01-12T14:17:39  *** jnewbery has joined #bitcoin-core-dev
 369 2017-01-12T14:17:45  <wumpus> so adding holes support to a RPC call is good in every way
 370 2017-01-12T14:18:23  <wumpus> fanquake: well as long as the guy maintains it it's fine I guess
 371 2017-01-12T14:18:29  <instagibbs> morcos, I'm up to 20% RTT saved now, syncing with your number
 372 2017-01-12T14:20:24  <fanquake> wumpus I guess. It just seems like something set to degrade. Checking sub-trees also seems like overkill.
 373 2017-01-12T14:20:41  <wumpus> fanquake: checking sub-trees is absolutely overkill
 374 2017-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.
 375 2017-01-12T14:20:54  <wumpus> we don't merge any changes to those
 376 2017-01-12T14:20:56  <wumpus> right
 377 2017-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.
 378 2017-01-12T14:21:52  <fanquake> I thought you'd be able to just exclude all the files in the subtree dirs.
 379 2017-01-12T14:21:53  *** windsok has quit IRC
 380 2017-01-12T14:22:13  <wumpus> very possible - I don't know what he uses to query the list of files from git
 381 2017-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
 382 2017-01-12T14:24:37  *** Cheeseo has joined #bitcoin-core-dev
 383 2017-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.
 384 2017-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.
 385 2017-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.
 386 2017-01-12T14:29:25  <morcos> gmaxwell: what i said yesterday about using the default in bumpfee doesn't make sense
 387 2017-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
 388 2017-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
 389 2017-01-12T14:30:42  <gmaxwell> thats okay with me.
 390 2017-01-12T14:31:30  <morcos> even that though sounds a bit risky to me
 391 2017-01-12T14:32:00  <morcos> what happens when you bump some transaction that was only valid because of its sequence numbers and CSV
 392 2017-01-12T14:32:16  <gmaxwell> well considering we can't sign for such a transaction currently...
 393 2017-01-12T14:32:31  <morcos> we can't?
 394 2017-01-12T14:32:54  <gmaxwell> no, if there is a OP_CSV signrawtransaction won't work, you'd need to be running modified software.
 395 2017-01-12T14:33:41  <Chris_Stewart_5> requires standardness?
 396 2017-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.
 397 2017-01-12T14:34:33  <jonasschnelli> gmaxwell: deadlock. :)
 398 2017-01-12T14:35:04  <jonasschnelli> Should I start to do something or do you want to work on the HD-keypool auto-jump?
 399 2017-01-12T14:35:24  <sipa> Chris_Stewart_5: no, the signing code just doesn't know how to produce a scriptSig for that
 400 2017-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).
 401 2017-01-12T14:35:55  <gmaxwell> jonasschnelli: I think it will be simple (famous last words).
 402 2017-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.
 403 2017-01-12T14:36:18  <jonasschnelli> gmaxwell: heh. Okay.
 404 2017-01-12T14:37:35  <Chris_Stewart_5> gotcha. Thanks.
 405 2017-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
 406 2017-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.
 407 2017-01-12T14:47:12  <fanquake> wumpus agreed.
 408 2017-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
 409 2017-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
 410 2017-01-12T14:49:34  <fanquake> wumpus Yea I wish it just posted the error/log output in the GitHub comment bit.
 411 2017-01-12T14:49:43  <wumpus> well please not the entire thing
 412 2017-01-12T14:49:58  <wumpus> just a summary of points, say e.g. what build step failed and the error message
 413 2017-01-12T14:50:02  <fanquake> Yes not the whole lot, just the last 10 lines or so.
 414 2017-01-12T14:50:11  *** michiel_ is now known as gielbier_
 415 2017-01-12T14:50:44  <fanquake> I should be minimized by default too.
 416 2017-01-12T14:51:11  <wumpus> any way to put a custom message in the comment bit would be great, we can handle the rest
 417 2017-01-12T14:51:45  <fanquake> Anything to save looking at 6 different sets of logs.
 418 2017-01-12T14:55:13  <fanquake> Also, are we still manually starting the builds of 7148
 419 2017-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.
 420 2017-01-12T14:59:23  *** laurentmt has joined #bitcoin-core-dev
 421 2017-01-12T15:01:56  *** laurentmt has quit IRC
 422 2017-01-12T15:02:55  *** windsok has joined #bitcoin-core-dev
 423 2017-01-12T15:03:17  *** AaronVW has quit IRC
 424 2017-01-12T15:03:48  *** AaronVW has joined #bitcoin-core-dev
 425 2017-01-12T15:18:28  *** fanquake has quit IRC
 426 2017-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
 427 2017-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
 428 2017-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.
 429 2017-01-12T15:55:08  *** BashCo_ has joined #bitcoin-core-dev
 430 2017-01-12T15:56:53  *** BashCo has quit IRC
 431 2017-01-12T15:57:21  *** xinxi has quit IRC
 432 2017-01-12T16:03:53  *** xinxi has joined #bitcoin-core-dev
 433 2017-01-12T16:10:15  *** BashCo_ has quit IRC
 434 2017-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
 435 2017-01-12T16:37:39  *** JackH has joined #bitcoin-core-dev
 436 2017-01-12T16:41:37  *** BashCo has joined #bitcoin-core-dev
 437 2017-01-12T16:43:17  *** Guest53948 is now known as haakonn
 438 2017-01-12T16:43:46  *** haakonn is now known as Guest46061
 439 2017-01-12T16:48:53  *** xinxi has quit IRC
 440 2017-01-12T16:50:12  *** abpa has joined #bitcoin-core-dev
 441 2017-01-12T16:51:50  *** xinxi has joined #bitcoin-core-dev
 442 2017-01-12T16:56:45  *** afk11 has joined #bitcoin-core-dev
 443 2017-01-12T17:10:03  <luke-jr> any objections to rebasing #9422 ?
 444 2017-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
 445 2017-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
 446 2017-01-12T17:35:12  *** arubi has left #bitcoin-core-dev
 447 2017-01-12T17:35:20  *** arubi has joined #bitcoin-core-dev
 448 2017-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
 449 2017-01-12T17:51:33  *** drbolardus has joined #bitcoin-core-dev
 450 2017-01-12T17:55:02  <btcdrak> luke-jr: go ahead
 451 2017-01-12T18:06:21  *** cbits has joined #bitcoin-core-dev
 452 2017-01-12T18:11:31  *** cbits has quit IRC
 453 2017-01-12T18:17:17  <sipa> i'll be travelling during part of the meeting
 454 2017-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
 455 2017-01-12T18:36:49  *** MarcoFalke has joined #bitcoin-core-dev
 456 2017-01-12T18:50:54  *** Guest46061 is now known as haakonn
 457 2017-01-12T18:51:00  *** haakonn has joined #bitcoin-core-dev
 458 2017-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
 459 2017-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
 460 2017-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?
 461 2017-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
 462 2017-01-12T18:58:54  <BlueMatt> :/
 463 2017-01-12T19:00:08  <wumpus> #startmeeting
 464 2017-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.
 465 2017-01-12T19:00:08  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 466 2017-01-12T19:00:17  <jonasschnelli> hi
 467 2017-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
 468 2017-01-12T19:00:44  <kanzure> hi.
 469 2017-01-12T19:01:04  <wumpus> proposed topics?
 470 2017-01-12T19:01:21  <btcdrak> hi
 471 2017-01-12T19:01:25  <michagogo> o/
 472 2017-01-12T19:01:34  *** moli_ has joined #bitcoin-core-dev
 473 2017-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?
 474 2017-01-12T19:01:43  <jonasschnelli> gmaxwell mentioned yesterday that he's traveling.
 475 2017-01-12T19:01:46  <BlueMatt> feature freeze, of course
 476 2017-01-12T19:01:47  <jtimon> here
 477 2017-01-12T19:01:49  <wumpus> anyone working really hard on getting something in before the feature freeze?
 478 2017-01-12T19:02:25  <BlueMatt> my #9499 and #9375 plus cfields' #9441 are massive
 479 2017-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
 480 2017-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
 481 2017-01-12T19:02:29  <BlueMatt> and probably close enough to make it
 482 2017-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
 483 2017-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
 484 2017-01-12T19:02:40  <morcos> +1 BlueMatt's list
 485 2017-01-12T19:02:51  <luke-jr> (but IIRC from last meeting, there were more important things than MW that take precedence)
 486 2017-01-12T19:02:53  *** e4xit has quit IRC
 487 2017-01-12T19:02:58  <cfields> wumpus: there's qt 5.7 which is probably worth having in.
 488 2017-01-12T19:03:14  <jonasschnelli> cfields: +1... whats missing? Can I help?
 489 2017-01-12T19:03:27  <wumpus> cfields: I don't understand the blocker there
 490 2017-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 :(
 491 2017-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
 492 2017-01-12T19:04:00  <wumpus> yes #9441 should be ready for merge really
 493 2017-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
 494 2017-01-12T19:04:41  <btcdrak> +1 on multiwallet
 495 2017-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
 496 2017-01-12T19:04:50  <BlueMatt> btcdrak: my point was I dont think thats gonna make it
 497 2017-01-12T19:04:53  <cfields> (re qt 7.1)
 498 2017-01-12T19:04:58  <cfields> er, 5.7. heh.
 499 2017-01-12T19:05:05  <BlueMatt> would have to turn out to get acks without any comments on the final multiwallet pr, I think
 500 2017-01-12T19:05:16  <BlueMatt> unless we decide we super want it and are willing to let it go in post-feature-freeze
 501 2017-01-12T19:05:17  <wumpus> forget about multwallet for 0.14
 502 2017-01-12T19:05:40  <jonasschnelli> Yes. It's probably to late
 503 2017-01-12T19:05:45  <BlueMatt> yup
 504 2017-01-12T19:05:48  <wumpus> it's a pity but let's just merge that stuff after the 0.14 split
 505 2017-01-12T19:05:58  <jonasschnelli> Yes. No hurry.
 506 2017-01-12T19:06:02  <wumpus> then it has ample time to be tested in master, which it needs
 507 2017-01-12T19:06:17  <cfields> jonasschnelli: happy to have help, sure. Let's discuss after meeting.
 508 2017-01-12T19:06:21  <jonasschnelli> ok
 509 2017-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 :)
 510 2017-01-12T19:06:28  <BlueMatt> havent looked at the diff, but I'd call #9519 a bugfix, so should go in post-monday
 511 2017-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
 512 2017-01-12T19:06:38  <BlueMatt> morcos: should we tag that 0.14?
 513 2017-01-12T19:06:44  <luke-jr> ACK not doing MW in 0.14
 514 2017-01-12T19:06:54  <morcos> Yes I talked about it a while this morning with sdaftuar.  We should do it for 0.14
 515 2017-01-12T19:07:12  <morcos> It's a very minor change
 516 2017-01-12T19:07:21  <wumpus> yes bugfixes can be merged after the feature freeze, will tag it
 517 2017-01-12T19:07:32  <BlueMatt> #9512 is probably a 0.14 bugfix that should be tagged
 518 2017-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
 519 2017-01-12T19:07:47  <achow101> there's also the final alert stuff that's supposed to go in 0.14
 520 2017-01-12T19:08:04  <wumpus> #9512 a bugfix?
 521 2017-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
 522 2017-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
 523 2017-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
 524 2017-01-12T19:08:26  <BlueMatt> wumpus: I mean I'd call code correctness bugfixes even if there are no bugs
 525 2017-01-12T19:08:28  <wumpus> I don't really like the perf hit
 526 2017-01-12T19:08:39  <BlueMatt> wumpus: assuming we can fix the performance hit?
 527 2017-01-12T19:08:51  <wumpus> normally I woudln't mind but hashing is very important to bitcoind performance
 528 2017-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
 529 2017-01-12T19:09:12  <BlueMatt> I know gmaxwell wanted #9484 for 0.14, which I think it should be
 530 2017-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
 531 2017-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
 532 2017-01-12T19:09:52  <BlueMatt> wumpus: ok, lets punt on 9512 for now, then
 533 2017-01-12T19:09:58  <BlueMatt> can decide later
 534 2017-01-12T19:10:17  <morcos> Can we discuss briefly the concept of dust being tied to minrelaytxfee
 535 2017-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)
 536 2017-01-12T19:10:34  <BlueMatt> so things that need review before monday: 9484, 9499, 9375, 9441
 537 2017-01-12T19:10:35  <wumpus> morcos: sure, next topic
 538 2017-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
 539 2017-01-12T19:10:51  <wumpus> #action review before monday : 9484, 9499, 9375, 9441
 540 2017-01-12T19:10:55  <wumpus> sipa: great!
 541 2017-01-12T19:11:02  *** str4d has joined #bitcoin-core-dev
 542 2017-01-12T19:11:10  <sipa> and by faster i mean 0.025%
 543 2017-01-12T19:11:18  <BlueMatt> heh
 544 2017-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?
 545 2017-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
 546 2017-01-12T19:11:36  <wumpus> well "not slower" would be the goal so anything faster is doubly awesome
 547 2017-01-12T19:11:38  <BlueMatt> wumpus: wait, which PR was the LONG_MAX comment in reference to?
 548 2017-01-12T19:12:09  <wumpus> BlueMatt: #9512 IIRC
 549 2017-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
 550 2017-01-12T19:12:30  <BlueMatt> wumpus: ahh, yea, admittedly I havent read the code there yet, beyond very brief skimming
 551 2017-01-12T19:12:40  <BlueMatt> morcos: go ahead?
 552 2017-01-12T19:12:41  <cfields> yes, it's in the CScriptNum tests
 553 2017-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
 554 2017-01-12T19:13:45  <wumpus> yes https://github.com/bitcoin/bitcoin/pull/9512/files#diff-2513c35abb5ab245137423db2d803628R17
 555 2017-01-12T19:14:02  <MarcoFalke> wumpus: Set topic for morcos?
 556 2017-01-12T19:14:13  <wumpus> morcos: oh yes forgot that - current topic is still what to do before the feature freeze
 557 2017-01-12T19:14:30  <wumpus> #topic  the concept of dust being tied to minrelaytxfee
 558 2017-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
 559 2017-01-12T19:14:46  <BlueMatt> (I assume code is realatively trivial)
 560 2017-01-12T19:14:52  <morcos> BlueMatt: what about the transaltion strings
 561 2017-01-12T19:15:19  <MarcoFalke> morcos: Those are "hidden" features? So no translation string
 562 2017-01-12T19:15:19  <BlueMatt> wumpus: ?
 563 2017-01-12T19:15:37  <MarcoFalke> I'd recommend against exposing -dustfeerate
 564 2017-01-12T19:15:44  <MarcoFalke> to every user
 565 2017-01-12T19:16:02  <MarcoFalke> Maybe not even at all. Just make it a const in the code.
 566 2017-01-12T19:16:12  <wumpus> yes, translation freeze is at the same time as feature freeze
 567 2017-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.
 568 2017-01-12T19:16:26  <wumpus> but if it's a debug feature it won't have translation strings, ofc
 569 2017-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
 570 2017-01-12T19:16:41  *** xinxi has quit IRC
 571 2017-01-12T19:17:03  <BlueMatt> ehh, I'd say the diff is pretty trivial, lets just target it for monday?
 572 2017-01-12T19:17:14  <BlueMatt> (at the risk of piling on top of the other 4)
 573 2017-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...
 574 2017-01-12T19:17:58  *** LeMiner has joined #bitcoin-core-dev
 575 2017-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
 576 2017-01-12T19:19:02  <luke-jr> morcos: eh, is it based on your own fee, or the relay min fee? I thought the latter
 577 2017-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
 578 2017-01-12T19:20:09  <luke-jr> ah
 579 2017-01-12T19:20:36  *** laurentmt has joined #bitcoin-core-dev
 580 2017-01-12T19:21:05  *** jannes has quit IRC
 581 2017-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
 582 2017-01-12T19:22:00  <wumpus> ok
 583 2017-01-12T19:22:09  <BlueMatt> lets add it to the list for monday and if it slips thats ok
 584 2017-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
 585 2017-01-12T19:22:24  <gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
 586 2017-01-12T19:22:26  <gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
 587 2017-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
 588 2017-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
 589 2017-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
 590 2017-01-12T19:22:35  *** laurentmt has quit IRC
 591 2017-01-12T19:23:02  <jonasschnelli> Yes. We should
 592 2017-01-12T19:23:03  <jl2012> yes, leave 8654 and 8755 for later
 593 2017-01-12T19:23:03  <BlueMatt> jonasschnelli: do you have a strong desire for #9294?
 594 2017-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
 595 2017-01-12T19:23:06  <morcos> I think 8456 can make it...  The others maybe not
 596 2017-01-12T19:23:20  <jonasschnelli> Yes. 9294 must go in!
 597 2017-01-12T19:23:29  <BlueMatt> morcos: its kinda light on ACKs to get merged this weekend, no?
 598 2017-01-12T19:23:32  <jonasschnelli> Needs review. Has only a single utACK
 599 2017-01-12T19:23:45  <BlueMatt> jonasschnelli: looks like it needs rebase?
 600 2017-01-12T19:23:50  <jonasschnelli> We should also tag #9377
 601 2017-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
 602 2017-01-12T19:24:02  *** PaulCapestany has quit IRC
 603 2017-01-12T19:24:08  <BlueMatt> grrr, this list is a bit long for 4 days incl a weekend...
 604 2017-01-12T19:24:12  <jonasschnelli> Oh. Yes. Needs rebase (since today)
 605 2017-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
 606 2017-01-12T19:24:21  <luke-jr> maybe we should split up the list between different people?
 607 2017-01-12T19:24:30  <wumpus> yes, it's not going to all make it
 608 2017-01-12T19:24:34  <luke-jr> we don't all have to review the same stuff
 609 2017-01-12T19:24:36  <wumpus> as I've said last week we should really make a choice
 610 2017-01-12T19:24:44  <wumpus> instead of trying to  cram everything in
 611 2017-01-12T19:24:47  *** drbolardus has quit IRC
 612 2017-01-12T19:25:06  <BlueMatt> luke-jr: we dont have enough reviewers for that to work well enough :(
 613 2017-01-12T19:25:07  <jonasschnelli> 9377 is a bugfix and can go in later
 614 2017-01-12T19:25:23  <jonasschnelli> But please review 9294,.. is a sensitive wallet thing
 615 2017-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
 616 2017-01-12T19:25:31  <wumpus> especiall for the wallet it seems getting reviewers is really hard
 617 2017-01-12T19:25:31  <luke-jr> :<
 618 2017-01-12T19:25:43  <BlueMatt> yes :(
 619 2017-01-12T19:25:44  <bitcoin-git> [bitcoin] losh11 opened pull request #9534: Statoshi (master...master) https://github.com/bitcoin/bitcoin/pull/9534
 620 2017-01-12T19:26:06  <bitcoin-git> [bitcoin] losh11 closed pull request #9534: Statoshi (master...master) https://github.com/bitcoin/bitcoin/pull/9534
 621 2017-01-12T19:26:15  <cfields> that one's done!
 622 2017-01-12T19:26:16  <jtimon> I'm afraid I will prioritize the ones that are easier for me to review either way
 623 2017-01-12T19:26:25  <jonasschnelli> sure
 624 2017-01-12T19:26:30  <luke-jr> wallet needs the most review after consensus-critical changes, too
 625 2017-01-12T19:27:17  <jtimon> jonasschnelli: is the fact that 9377 is a bugfix a good reason to delay it?
 626 2017-01-12T19:27:43  <jonasschnelli> jtimon: delay,.. more priorize because of the freeze.
 627 2017-01-12T19:27:54  <BlueMatt> 9377 needs rebase
 628 2017-01-12T19:27:54  <jonasschnelli> But 9377 fixes a address reuse problem ans should be in 0.14
 629 2017-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?
 630 2017-01-12T19:28:08  <jonasschnelli> It somehow feels that all my PR needs rebase since today.
 631 2017-01-12T19:28:20  <BlueMatt> ok, 9377 looks like a bugfix that can go in after monday...looks like an easy diff too
 632 2017-01-12T19:28:27  <BlueMatt> can someone tag it?
 633 2017-01-12T19:28:36  <luke-jr> jonasschnelli: heh, I rebased something yesterday and had to re-rebase it again today XD
 634 2017-01-12T19:28:38  <jonasschnelli> 9294 should be in 0.14 because we should avoid creating more single-chain HD wallets
 635 2017-01-12T19:28:51  <sipa> made it to the bus!
 636 2017-01-12T19:29:02  <luke-jr> jonasschnelli: can it upgrade single-chain HD wallets?
 637 2017-01-12T19:29:07  <jonasschnelli> No
 638 2017-01-12T19:29:12  <jonasschnelli> That's why it should be in 0.14
 639 2017-01-12T19:29:25  <luke-jr> is there a reason it cannot?
 640 2017-01-12T19:29:39  <jonasschnelli> You can't split the hd chains once you have created change outputs on the external chain...
 641 2017-01-12T19:29:40  <wumpus> jonasschnelli: that's a good point
 642 2017-01-12T19:29:48  <jonasschnelli> well... not with consequences.
 643 2017-01-12T19:29:54  <BlueMatt> sipa: yay!
 644 2017-01-12T19:29:55  <jonasschnelli> like re-seed
 645 2017-01-12T19:29:59  <morcos> and HD isn't released yet?
 646 2017-01-12T19:30:04  <jonasschnelli> it is.
 647 2017-01-12T19:30:06  <instagibbs> HD is already in 0.13
 648 2017-01-12T19:30:06  <wumpus> so from the wallet features we should focus on getting #9294 in
 649 2017-01-12T19:30:07  <jonasschnelli> Since 0.13
 650 2017-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
 651 2017-01-12T19:30:16  <luke-jr> jonasschnelli: I don't understand why not. Maybe we should discuss this further after the meeting?
 652 2017-01-12T19:30:22  <morcos> Ok so its a matter of not makign it worse then
 653 2017-01-12T19:30:26  <wumpus> yes it is, but uses a single chain, which is inconvenient for reconstruction from a seed
 654 2017-01-12T19:30:38  <jonasschnelli> Yes.
 655 2017-01-12T19:30:39  <sipa> luke-jr: recovery from a seed won't correctly identify change
 656 2017-01-12T19:30:44  <sipa> that's all
 657 2017-01-12T19:30:50  <jonasschnelli> The change is not complex, but also not trivial
 658 2017-01-12T19:31:13  <sipa> are there other wallet related changes we want to see in 0.14
 659 2017-01-12T19:31:15  <sipa> ?
 660 2017-01-12T19:31:28  <sipa> jonasschnelli: ?
 661 2017-01-12T19:31:31  <jonasschnelli> gmaxwell and I like to have the keypool detecting in 0.14
 662 2017-01-12T19:31:34  *** PaulCapestany has joined #bitcoin-core-dev
 663 2017-01-12T19:31:38  <jonasschnelli> But not sure if its too late
 664 2017-01-12T19:31:42  <luke-jr> what happens if I try to recover from a seed generated from a current HD wallet? ;)
 665 2017-01-12T19:31:44  <sipa> i think that is too laye
 666 2017-01-12T19:31:51  <jonasschnelli> Yes. It feels like
 667 2017-01-12T19:31:53  <jtimon> jonasschnelli: how #9294 works with #8723 ?
 668 2017-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
 669 2017-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
 670 2017-01-12T19:32:01  <luke-jr> jonasschnelli: that's a bugfix IMO
 671 2017-01-12T19:32:16  <luke-jr> or potentially a bugfix, at least
 672 2017-01-12T19:32:17  <jonasschnelli> 8723 has no reviews.
 673 2017-01-12T19:32:22  <jonasschnelli> To late for 0.14 IMO
 674 2017-01-12T19:32:29  <sdaftuar> jonasschnelli: can you remind us what keypool detecting is?
 675 2017-01-12T19:32:41  <jtimon> but have you thought about how they would combine?
 676 2017-01-12T19:32:44  <instagibbs> luke-jr, we have no direct recovery tools from seed AFAIK
 677 2017-01-12T19:32:50  <sipa> sdaftuar: the wallet marking keys as used once they are seen in a transaction
 678 2017-01-12T19:32:53  <jtimon> independently of which one goes first
 679 2017-01-12T19:32:55  <instagibbs> current flow is ~same as before
 680 2017-01-12T19:32:56  <luke-jr> instagibbs: but presumably we will be adding one
 681 2017-01-12T19:32:58  <jonasschnelli> sdaftuar: if you use an old backup... you want to autodetect keys already been used.
 682 2017-01-12T19:33:08  <instagibbs> luke-jr, indeed, which is why split will be important, right?
 683 2017-01-12T19:33:22  <sdaftuar> got it, thanks
 684 2017-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
 685 2017-01-12T19:33:36  <jonasschnelli> Otherwise you re-use keys.
 686 2017-01-12T19:34:11  <jonasschnelli> (if you don't topup your keypool +1000 and do a rescan before you use your old backup)
 687 2017-01-12T19:34:11  <luke-jr> instagibbs: perhaps. but nothing stops someone from recovering from a pre-split seed?
 688 2017-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.
 689 2017-01-12T19:35:32  <luke-jr> jonasschnelli: not disputing that.
 690 2017-01-12T19:35:47  <jonasschnelli> Flexible keypath is nice.. but too late for 0.14.
 691 2017-01-12T19:36:00  <jonasschnelli> The sad thing is, it will be another feature that is not downward compatible.
 692 2017-01-12T19:36:10  <jonasschnelli> 0.13 HD, 0.14 HD/split, 0.15 flex-keypath
 693 2017-01-12T19:36:14  <jonasschnelli> All not backward comp.
 694 2017-01-12T19:36:26  <sipa> meh.
 695 2017-01-12T19:36:31  <jonasschnelli> Yes. Meh.
 696 2017-01-12T19:36:43  <jonasschnelli> That's why I'd like combining the HD split with other stuff.
 697 2017-01-12T19:36:44  <luke-jr> surely at least HD/split can be upgraded to flex-keypath⁇
 698 2017-01-12T19:36:54  <sipa> breaking backward compatibility in major releases is fine
 699 2017-01-12T19:37:25  <instagibbs> Yeah why can't we upgrade to keypath?
 700 2017-01-12T19:37:27  <jonasschnelli> Okay.
 701 2017-01-12T19:37:37  <jonasschnelli> You can upgrade to keypath, but not downgrade
 702 2017-01-12T19:37:38  * instagibbs should have actually reviewed, my bad
 703 2017-01-12T19:37:48  <jonasschnelli> Use a 0.15 wallet in 0.14 as an example
 704 2017-01-12T19:37:56  <jonasschnelli> But maybe its not so bad.
 705 2017-01-12T19:37:58  <luke-jr> upgrade-only is okay. we have -walletupgrade for that
 706 2017-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
 707 2017-01-12T19:38:29  <jonasschnelli> wumpus: right. My fault.
 708 2017-01-12T19:38:34  <sipa> backward compatible means that old software can use new wallets
 709 2017-01-12T19:38:41  <wumpus> but being able to use  a new wallet with an old major version is not
 710 2017-01-12T19:38:43  <wumpus> huh?
 711 2017-01-12T19:38:51  <jonasschnelli> perspetive thing. :)
 712 2017-01-12T19:38:54  <wumpus> I thought the other way around.
 713 2017-01-12T19:38:56  <jonasschnelli> *perspective
 714 2017-01-12T19:39:01  <sipa> forward compatible is what you normally always have
 715 2017-01-12T19:39:02  <wumpus> I don't understand it anymore then
 716 2017-01-12T19:39:33  <instagibbs> wallet.dat vs Core wallet relativity...
 717 2017-01-12T19:39:34  <sipa> oopz
 718 2017-01-12T19:39:34  <CodeShark>  Walllet format vs. Wallet app
 719 2017-01-12T19:39:36  <luke-jr> I think we have more cases than normal
 720 2017-01-12T19:39:42  <sipa> maybe i am wrong too
 721 2017-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
 722 2017-01-12T19:39:47  <sipa> i will shut up
 723 2017-01-12T19:39:56  <jonasschnelli> And now we break that in 0.13, 0.14 and probably 0.15.
 724 2017-01-12T19:40:07  <jonasschnelli> But fine for me.
 725 2017-01-12T19:40:13  <instagibbs> jonasschnelli, OTOH, these are the kind of upgrades people desperately want...
 726 2017-01-12T19:40:16  <instagibbs> for future work
 727 2017-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
 728 2017-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
 729 2017-01-12T19:40:22  <CodeShark> wallet format is forward compatible, wallet app is backward compatible
 730 2017-01-12T19:40:36  <wumpus> jonasschnelli: however, new wallets created with new versions don't need to be open-able with old versions
 731 2017-01-12T19:40:56  <jonasschnelli> Okay. Seems that we all agree. Good.
 732 2017-01-12T19:40:58  <morcos> wumpus: +1 for those standards
 733 2017-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
 734 2017-01-12T19:41:24  <jonasschnelli> Flexible keypath is nice. But we don't want to support BIP44 anyways thats why it's not urgent
 735 2017-01-12T19:41:33  <jtimon> all these backards and forwards compatibility is confusing, softfork and hardforks are much more clear :p
 736 2017-01-12T19:41:43  <petertodd> jtimon: +1
 737 2017-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
 738 2017-01-12T19:41:51  <luke-jr> jtimon: lol
 739 2017-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
 740 2017-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?)
 741 2017-01-12T19:45:21  <BlueMatt> well, ok, 9486 is whatever, its trivial
 742 2017-01-12T19:45:24  <sdaftuar> BlueMatt: i think 8456 ought to be done, though it is true that gmaxwell keeps finding small issues
 743 2017-01-12T19:45:36  <CodeShark> Please no use of the terms "evil compatibility" or "backward-forward compatibility"
 744 2017-01-12T19:45:51  <BlueMatt> everything else tagged looks like a bugfix (#9490 is, right?)
 745 2017-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
 746 2017-01-12T19:46:03  *** afk11 has quit IRC
 747 2017-01-12T19:46:04  <sdaftuar> yes that is a bugfix
 748 2017-01-12T19:46:04  <sipa> is #9484 on the list?
 749 2017-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
 750 2017-01-12T19:46:06  <BlueMatt> jonasschnelli: whats up with #9461?
 751 2017-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
 752 2017-01-12T19:46:10  <jtimon> lol evil compatibility
 753 2017-01-12T19:46:18  <BlueMatt> sipa: oops, yes, add that to the list
 754 2017-01-12T19:46:24  <jonasschnelli> BlueMatt: simple change. Hope we can get it into 0.14
 755 2017-01-12T19:46:28  <jonasschnelli> Needs review
 756 2017-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?)
 757 2017-01-12T19:46:35  <luke-jr> BlueMatt: do an `action` thing with the final list?
 758 2017-01-12T19:46:49  <instagibbs> someone with the meeting hammer has to do that i think
 759 2017-01-12T19:47:02  <luke-jr> O.o
 760 2017-01-12T19:47:02  <BlueMatt> that list is much too long :(
 761 2017-01-12T19:47:07  <wumpus> I've tagged 9499. Though we should stop tagging more stuff for monday.
 762 2017-01-12T19:47:10  <morcos> BlueMatt: nah... we can do all those
 763 2017-01-12T19:47:13  <BlueMatt> lol
 764 2017-01-12T19:47:23  <wumpus> we're not going to make the current list
 765 2017-01-12T19:47:24  <morcos> I think they are almost all ready for merge except perhaps 9294
 766 2017-01-12T19:47:27  <luke-jr> maybe we should sort the list by priority
 767 2017-01-12T19:47:43  <luke-jr> otherwise we're liable to work on opposite ones first and get none done
 768 2017-01-12T19:47:47  <BlueMatt> i dont think 8456 is gonna make that, either
 769 2017-01-12T19:48:05  <morcos> in 2 hours it'll have 2 ACK's, but if it doesn't make it, thats fine
 770 2017-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
 771 2017-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
 772 2017-01-12T19:48:34  * sipa imagines creating a few sockpuppet accounts on github now
 773 2017-01-12T19:48:40  <sipa> *morcos
 774 2017-01-12T19:48:40  <jonasschnelli> heh
 775 2017-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
 776 2017-01-12T19:48:46  <luke-jr> sipa: that'd violate github tos :P
 777 2017-01-12T19:48:49  <cfields> (it belongs in 9441, i just left it out because you already had one)
 778 2017-01-12T19:49:03  <jonasschnelli> luke-jr: depends how many kids you have
 779 2017-01-12T19:49:08  <BlueMatt> cfields: oh fuck I forgot about the cs_vSend split there
 780 2017-01-12T19:49:15  <jtimon> 9380 seems easy to review, more about deciding what to expose now and what to leave for later
 781 2017-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
 782 2017-01-12T19:49:28  <BlueMatt> it is a huge win, though :/
 783 2017-01-12T19:49:38  <luke-jr> jonasschnelli: account terms #1 You must be 13 years or older to use this Service.
 784 2017-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
 785 2017-01-12T19:49:44  <luke-jr> …
 786 2017-01-12T19:50:18  <sipa> hah
 787 2017-01-12T19:50:20  <jonasschnelli> heh
 788 2017-01-12T19:50:28  <cfields> BlueMatt: indeed. I think it's quite simple, though
 789 2017-01-12T19:51:12  *** paveljanik has joined #bitcoin-core-dev
 790 2017-01-12T19:51:12  *** paveljanik has joined #bitcoin-core-dev
 791 2017-01-12T19:51:38  <jtimon> any other topics?
 792 2017-01-12T19:51:41  <jtimon> 10 min
 793 2017-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
 794 2017-01-12T19:52:43  <cfields> BlueMatt: thanks. Will scrutinize.
 795 2017-01-12T19:53:50  <BlueMatt> wumpus: dont kill me, but ^ is kinda worth doing for monday :(
 796 2017-01-12T19:54:10  <wumpus> they're all worth doing, that's not the question
 797 2017-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
 798 2017-01-12T19:54:20  <BlueMatt> true
 799 2017-01-12T19:54:23  <wumpus> agree luke-jr
 800 2017-01-12T19:55:08  <wumpus> let's leave something for 0.15
 801 2017-01-12T19:55:19  <BlueMatt> oh I've got lots for 0.15 already :p
 802 2017-01-12T19:55:41  <wumpus> of which at least half will probably miss 0.15 and only make it to 0.16 :)
 803 2017-01-12T19:55:47  <BlueMatt> oh yea
 804 2017-01-12T19:55:50  <BlueMatt> always do
 805 2017-01-12T19:55:52  <luke-jr> XD
 806 2017-01-12T19:56:06  <luke-jr> it's not like we have 3 years between releases ☺
 807 2017-01-12T19:56:09  <wumpus> that's how it goes, there's no other way if you have time based releases
 808 2017-01-12T19:56:29  <BlueMatt> anyway, so lets call the meeting?
 809 2017-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
 810 2017-01-12T19:56:37  <luke-jr> what's the phone number?
 811 2017-01-12T19:56:49  <BlueMatt> wumpus: ooo, I vote for that one
 812 2017-01-12T19:56:52  <luke-jr> lol
 813 2017-01-12T19:56:54  <wumpus> yes, I think we're out of topics
 814 2017-01-12T19:56:56  <wumpus> #endmeeting
 815 2017-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)
 816 2017-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
 817 2017-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
 818 2017-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
 819 2017-01-12T19:57:05  <BlueMatt> no more releases, just keep putting things in :)
 820 2017-01-12T19:57:05  <luke-jr> nobody did a #action with the PR list
 821 2017-01-12T19:57:13  <luke-jr> did anyone sort it?
 822 2017-01-12T19:57:17  <BlueMatt> ehh, whatever
 823 2017-01-12T19:57:56  <luke-jr> if nobody sorts it for me, I'm just going to review them in random order <.<
 824 2017-01-12T19:58:04  *** kadoban has joined #bitcoin-core-dev
 825 2017-01-12T19:58:54  <jtimon> luke-jr: they're ordered by appearence in the link above ^
 826 2017-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?
 827 2017-01-12T20:00:10  <cfields> BlueMatt: deal.
 828 2017-01-12T20:00:46  <cfields> it'll get solved as part of parallel processing
 829 2017-01-12T20:01:12  <BlueMatt> not really?
 830 2017-01-12T20:01:31  <BlueMatt> i mean its not going away
 831 2017-01-12T20:02:52  <cfields> BlueMatt: i mean as part of SendMessages dissolving into more event-based sends
 832 2017-01-12T20:03:03  <BlueMatt> how does that fix this?
 833 2017-01-12T20:04:01  *** cbits has joined #bitcoin-core-dev
 834 2017-01-12T20:04:18  <cfields> BlueMatt: for ex, BlockChecked could unblock all sends waiting on full verification
 835 2017-01-12T20:04:36  <luke-jr> (FWIW, my prioritised list I will be using is: 9294, 8456, 9499, 9375, 8441, 9486, 9484, 9380)
 836 2017-01-12T20:05:05  <cfields> (not thought through, just an off-the-cuff approach)
 837 2017-01-12T20:07:11  *** cbits has quit IRC
 838 2017-01-12T20:10:40  <BlueMatt> cfields: yes, possibly
 839 2017-01-12T20:12:28  <instagibbs> luke-jr, 8441 is some merged thing from august..
 840 2017-01-12T20:12:46  <luke-jr> oops *goes to find what he meant to put there*
 841 2017-01-12T20:13:12  <cfields> luke-jr: 9441 i assume
 842 2017-01-12T20:13:31  <luke-jr> yep
 843 2017-01-12T20:13:38  <instagibbs> crisis averted
 844 2017-01-12T20:15:25  * luke-jr wishes 9294 was multiple commits :x oh well
 845 2017-01-12T20:15:41  <BlueMatt> cfields: is that sufficient for #9375?
 846 2017-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
 847 2017-01-12T20:17:18  <BlueMatt> sipa: want to ack #9375?
 848 2017-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
 849 2017-01-12T20:17:25  *** xinxi has joined #bitcoin-core-dev
 850 2017-01-12T20:19:20  <cfields> BlueMatt: that works, thanks
 851 2017-01-12T20:20:50  <sipa> wumpus: i wonder if you should choose randomized feature freeze dates, and not announce them in advance
 852 2017-01-12T20:21:02  <BlueMatt> lol
 853 2017-01-12T20:21:04  <BlueMatt> probably
 854 2017-01-12T20:21:47  *** xinxi has quit IRC
 855 2017-01-12T20:21:52  <sipa> BlueMatt: going to look over 9375 again soon
 856 2017-01-12T20:40:05  *** str4d has quit IRC
 857 2017-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
 858 2017-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
 859 2017-01-12T20:52:48  *** moli has quit IRC
 860 2017-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
 861 2017-01-12T21:01:37  *** Chris_Stewart_5 has quit IRC
 862 2017-01-12T21:08:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 863 2017-01-12T21:09:23  *** [Author] has quit IRC
 864 2017-01-12T21:11:44  *** jtimon has quit IRC
 865 2017-01-12T21:11:54  <BlueMatt> luke-jr: i havent looked at that code in a long time, happy to review a pr, though :;
 866 2017-01-12T21:11:56  <BlueMatt> :p
 867 2017-01-12T21:18:42  *** xinxi has joined #bitcoin-core-dev
 868 2017-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
 869 2017-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
 870 2017-01-12T21:27:02  *** xinxi has quit IRC
 871 2017-01-12T21:30:17  <BlueMatt> cfields: sorry, found two more issues in 9441
 872 2017-01-12T21:30:18  <BlueMatt> :(
 873 2017-01-12T21:30:28  <cfields> BlueMatt: yep, looking them over now
 874 2017-01-12T21:32:11  *** jnewbery has quit IRC
 875 2017-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.
 876 2017-01-12T21:33:39  <BlueMatt> well right now its technically wrong
 877 2017-01-12T21:33:40  <BlueMatt> soooo
 878 2017-01-12T21:33:59  <BlueMatt> if someone set a stupid low nSendBufferMaxSize it might actually be triggerable, though maybe not
 879 2017-01-12T21:34:14  *** kadoban has quit IRC
 880 2017-01-12T21:34:27  <jeremyru1in> is there a good reason why validation.h should not include consensus/consensus.h?
 881 2017-01-12T21:34:28  *** kadoban has joined #bitcoin-core-dev
 882 2017-01-12T21:34:57  <BlueMatt> no?
 883 2017-01-12T21:35:49  <jeremyru1in> (ok, was making some derived constants that belong in validation.h)
 884 2017-01-12T21:41:31  <instagibbs> morcos, what kind of performance boost does the caching give? (asking the obvious re:relay cmpct)
 885 2017-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
 886 2017-01-12T21:42:34  *** belcher_ has joined #bitcoin-core-dev
 887 2017-01-12T21:42:44  <morcos> it greatly decreases the processing time for relay
 888 2017-01-12T21:43:40  <BlueMatt> massively so, in fact
 889 2017-01-12T21:44:00  <BlueMatt> luckily sipa's last round on 9375 was all pretty minor stuff
 890 2017-01-12T21:44:13  *** belcher has quit IRC
 891 2017-01-12T21:46:48  *** AaronVW is now known as AaronvanW
 892 2017-01-12T21:47:15  *** AaronvanW has quit IRC
 893 2017-01-12T21:47:15  *** AaronvanW has joined #bitcoin-core-dev
 894 2017-01-12T21:47:48  *** xinxi has joined #bitcoin-core-dev
 895 2017-01-12T21:52:05  *** xinxi has quit IRC
 896 2017-01-12T21:55:27  *** Chris_Stewart_5 has quit IRC
 897 2017-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
 898 2017-01-12T21:56:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 899 2017-01-12T22:00:25  <cfields> BlueMatt: yep, you're right.
 900 2017-01-12T22:01:19  *** Chris_Stewart_5 has quit IRC
 901 2017-01-12T22:03:41  *** fanquake has joined #bitcoin-core-dev
 902 2017-01-12T22:04:11  *** belcher_ has quit IRC
 903 2017-01-12T22:06:20  <cfields> lol, "git commit --amen" worked
 904 2017-01-12T22:06:22  <cfields> praise be.
 905 2017-01-12T22:06:36  <BlueMatt> wut
 906 2017-01-12T22:06:56  <cfields> typo'd 'git commit --amend'
 907 2017-01-12T22:07:04  <BlueMatt> lol, someone left that in as a easteregg
 908 2017-01-12T22:07:06  <BlueMatt> not in man-page
 909 2017-01-12T22:07:09  <gmaxwell> yep, git commit --amen works.
 910 2017-01-12T22:07:16  <BlueMatt> someone go file a bug and ruin their fun :P
 911 2017-01-12T22:07:27  <BlueMatt> confirmed: easter egg works here too
 912 2017-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'
 913 2017-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)
 914 2017-01-12T22:08:14  <cfields> seems to be that. --ame works too.
 915 2017-01-12T22:08:15  <BlueMatt> i could totally see git pulling shit like that :(
 916 2017-01-12T22:08:23  <BlueMatt> ffs
 917 2017-01-12T22:09:32  <sipa> BlueMatt, gmaxwell: pretty sure any unambiguous prefix is intentionally accepted
 918 2017-01-12T22:09:56  <sipa> sdaftuar: you need a lock for the condition variable anyway
 919 2017-01-12T22:10:28  <cfields> right, it's for the condvar
 920 2017-01-12T22:11:09  <cfields> sdaftuar: I was thinking the same thing as you. BlueMatt and i debated that. I lost hard.
 921 2017-01-12T22:11:20  <sdaftuar> but we release the lock before calling condMsgProc.notifyAll(), don't we?
 922 2017-01-12T22:11:35  <BlueMatt> sdaftuar: you cannot use a condvar without a lock.
 923 2017-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.
 924 2017-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)
 925 2017-01-12T22:13:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 926 2017-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)?
 927 2017-01-12T22:15:02  <sdaftuar> is that correct?
 928 2017-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
 929 2017-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
 930 2017-01-12T22:15:52  <BlueMatt> std::condition_variable_any definitely does
 931 2017-01-12T22:16:45  *** belcher_ has joined #bitcoin-core-dev
 932 2017-01-12T22:17:32  <sipa> sdaftuar: *waiting* on a condvar requires a lock
 933 2017-01-12T22:17:44  <sdaftuar> ok, i remain deeply puzzled, but i will worry about this when i'm at my desk again
 934 2017-01-12T22:17:49  <sipa> signalling can happen by anyone, anytime
 935 2017-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
 936 2017-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.
 937 2017-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
 938 2017-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
 939 2017-01-12T22:20:45  <gmaxwell> BlueMatt: great 7 days is 7 times a day.
 940 2017-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
 941 2017-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.
 942 2017-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.
 943 2017-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?
 944 2017-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
 945 2017-01-12T22:24:08  <BlueMatt> belt-and-suspenders, yo
 946 2017-01-12T22:24:31  <BlueMatt> s/massive sync-time feature/massive sync-time difference/
 947 2017-01-12T22:24:38  <gmaxwell> on my laptop a month of blocks takes 2.25 hours to validate.
 948 2017-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)
 949 2017-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)
 950 2017-01-12T22:25:44  <BlueMatt> how long with -assumevalid?
 951 2017-01-12T22:25:52  <BlueMatt> (ie how much of that is non-sig-checking)
 952 2017-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
 953 2017-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.
 954 2017-01-12T22:27:53  *** chjj has quit IRC
 955 2017-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.
 956 2017-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
 957 2017-01-12T22:30:06  <luke-jr> auditing the hash is as trivial as running without it, no?
 958 2017-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"
 959 2017-01-12T22:30:45  <gmaxwell> luke-jr: yes and checking if that block is in your chain.
 960 2017-01-12T22:30:49  <BlueMatt> i mean the recommended method to audit the hash takes a day for many folks :p
 961 2017-01-12T22:31:01  <BlueMatt> while the recommended way to set the hash is right before release
 962 2017-01-12T22:31:16  <sipa> i'm fine with either a week or a month. </bikeshed>
 963 2017-01-12T22:31:20  <gmaxwell> BlueMatt: no, it's part of the procedure that happens at the start of RCs.
 964 2017-01-12T22:31:35  * instagibbs re-opens <bikeshed>
 965 2017-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.
 966 2017-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)
 967 2017-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
 968 2017-01-12T22:33:40  <gmaxwell> If it is a massive footgun it must not be shipped.
 969 2017-01-12T22:33:58  <BlueMatt> if its a massive footgun that cant go off without bitcoin being completely broken I think thats fine :p
 970 2017-01-12T22:34:08  <BlueMatt> gmaxwell: how long does your sync take on your laptop start-to-finish with -assumevalid set to a week?
 971 2017-01-12T22:34:16  <sipa> i think the footgun (wth is that?) is minimal
 972 2017-01-12T22:34:41  <luke-jr> sipa: footgun is a gun designed for shooting one's own foot
 973 2017-01-12T22:34:43  <cfields> sipa: a device one uses to shoot one's self in the foot.
 974 2017-01-12T22:34:47  <TD-Linux> it's a footgun that only triggers when you've already lost your legs.
 975 2017-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
 976 2017-01-12T22:35:02  <BlueMatt> (if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw)
 977 2017-01-12T22:35:13  *** jtimon has joined #bitcoin-core-dev
 978 2017-01-12T22:35:47  <sipa> or is the issue not the hardcoded value, but people convincing others to run with a certain settings value?
 979 2017-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.
 980 2017-01-12T22:36:06  <luke-jr> sipa: or trick the user into configuring a majority invalid branch
 981 2017-01-12T22:36:17  <BlueMatt> so its 5 hours -> 7.5 hours if we set it to a month?
 982 2017-01-12T22:36:29  <BlueMatt> or 5 -> 7.25
 983 2017-01-12T22:36:41  <sipa> luke-jr: but they'd need to already have that invalid branch mined, and ahead by a week?
 984 2017-01-12T22:36:57  <gmaxwell> If I never stuck that check in none of you would have suggested it.
 985 2017-01-12T22:37:01  <BlueMatt> or, i guess 5 + (2.25/4) = 5.5 -> 7.25
 986 2017-01-12T22:37:08  <BlueMatt> gmaxwell: (if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw)
 987 2017-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
 988 2017-01-12T22:37:16  <gmaxwell> I think you're wrong.
 989 2017-01-12T22:37:21  <luke-jr> sipa: not necessarily
 990 2017-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
 991 2017-01-12T22:37:29  <luke-jr> ahead by a week, yes, but not already-mined
 992 2017-01-12T22:37:51  <sipa> BlueMatt: what specific attack scenario are you worried about?
 993 2017-01-12T22:38:00  <sipa> (honest question)
 994 2017-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)
 995 2017-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
 996 2017-01-12T22:39:42  <BlueMatt> its kinda weird, but definitely not impossible
 997 2017-01-12T22:39:57  *** str4d has joined #bitcoin-core-dev
 998 2017-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?
 999 2017-01-12T22:40:06  <sipa> BlueMatt: but the assumevalid setting value is only known after creating that branch
1000 2017-01-12T22:40:20  <gmaxwell> BlueMatt: I believe so.
1001 2017-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
1002 2017-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
1003 2017-01-12T22:40:45  <luke-jr> sipa: you'd make the transactions after your assumevalid all be valid
1004 2017-01-12T22:40:58  <BlueMatt> luke-jr: huh? no, you wouldnt
1005 2017-01-12T22:41:05  <luke-jr> BlueMatt: why not?
1006 2017-01-12T22:41:14  <BlueMatt> you would make all the txn before your assumevalid be valid
1007 2017-01-12T22:41:15  <BlueMatt> not after
1008 2017-01-12T22:41:19  <BlueMatt> well, and including, i think
1009 2017-01-12T22:41:26  <luke-jr> before it, they won't check if it's valid
1010 2017-01-12T22:41:27  * gmaxwell flies
1011 2017-01-12T22:41:29  <jtimon> BlueMatt: he means as an attacker
1012 2017-01-12T22:41:32  <luke-jr> so that's where you'd want to hide the invalid stuff
1013 2017-01-12T22:41:43  <sipa> BlueMatt: if at any point your attacker branch is overtaken by the honest branch, assumevalid has no more effect
1014 2017-01-12T22:41:43  <BlueMatt> oh, i see your point, ok
1015 2017-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
1016 2017-01-12T22:42:17  <BlueMatt> but maybe only like 5/6 days, and probably not much longer
1017 2017-01-12T22:42:27  *** Guyver2 has quit IRC
1018 2017-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
1019 2017-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
1020 2017-01-12T22:44:36  <luke-jr> anyhow, this all requires getting the user to manually set the block hash
1021 2017-01-12T22:44:43  <luke-jr> IMO just hide it as a debug option and we're fixed
1022 2017-01-12T22:44:49  <BlueMatt> luke-jr: I think you missed part, above
1023 2017-01-12T22:44:53  <luke-jr> ?
1024 2017-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
1025 2017-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
1026 2017-01-12T22:46:55  <BlueMatt> its kinda a strange scenario, and seems pretty highly unlikely, but I do not believe it is impossible
1027 2017-01-12T22:47:09  <luke-jr> BlueMatt: how will your invalid chain get accepted?
1028 2017-01-12T22:47:20  <BlueMatt> it wont be accepted by anyone except your target?
1029 2017-01-12T22:47:28  <luke-jr> why would it be accepted by your target, though?
1030 2017-01-12T22:47:36  <luke-jr> he'd need to set the config option to your malicious block hash
1031 2017-01-12T22:47:44  <jtimon> huhm, what does mining invalid garbage on top of your fake invalid assumevalid give you?
1032 2017-01-12T22:47:47  <BlueMatt> because you got them to set the assumevalid setting?
1033 2017-01-12T22:47:59  <BlueMatt> luke-jr: yes, did you miss the part where they set up their bitcoin node based on your instructions?
1034 2017-01-12T22:48:21  <jtimon> right, the ate the invalid stuff belowe your fake assumevalid, but not above it
1035 2017-01-12T22:48:49  <jtimon> s/the/they s/belowe/below
1036 2017-01-12T22:48:56  <luke-jr> ok, so the user is an idiot who will set the option without investigating what it does
1037 2017-01-12T22:49:03  *** xinxi has joined #bitcoin-core-dev
1038 2017-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
1039 2017-01-12T22:49:12  <BlueMatt> luke-jr: most users do shit like that....
1040 2017-01-12T22:49:15  <luke-jr> what if we rename it to assumevalid_this_can_compromise_your_node?
1041 2017-01-12T22:49:18  <BlueMatt> luke-jr: fuck, many users use the ppa
1042 2017-01-12T22:50:05  <jtimon> Ok, so precisely this attack is what the 1 week thing serves for, no?
1043 2017-01-12T22:50:06  <luke-jr> can't blame them. using the PPA makes a lot of sense considering they already trust Canonical.
1044 2017-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
1045 2017-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)
1046 2017-01-12T22:51:12  <BlueMatt> gmaxwell: does 2 weeks meet your performance target? its more like an extra half hour
1047 2017-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
1048 2017-01-12T22:52:03  <BlueMatt> which does seem like a big cost to pay
1049 2017-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?
1050 2017-01-12T22:52:25  <BlueMatt> yes
1051 2017-01-12T22:52:35  <BlueMatt> thats only if you sync within the first week of the release
1052 2017-01-12T22:52:43  <BlueMatt> well, first week after the hash was selected/set
1053 2017-01-12T22:53:45  *** xinxi has quit IRC
1054 2017-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
1055 2017-01-12T22:56:55  *** chjj has joined #bitcoin-core-dev
1056 2017-01-12T22:57:10  <jtimon> I mean, even with a month it's a great improvement over the checkpoint way
1057 2017-01-12T22:58:15  <BlueMatt> oh, totally I think we should do this, just prefer a tiny inch more conservatism
1058 2017-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.
1059 2017-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
1060 2017-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
1061 2017-01-12T22:59:48  <BlueMatt> whereas "download from this random site" might be a bit more alarming to folks
1062 2017-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!
1063 2017-01-12T23:00:40  <cfields> jtimon: that was exactly my point.
1064 2017-01-12T23:00:48  <jtimon> a bad bitcoin.conf seems more realistic
1065 2017-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
1066 2017-01-12T23:01:13  <jtimon> "here's my bitcoin.conf, copy it, it syncs super-fast"
1067 2017-01-12T23:01:31  <BlueMatt> then double because the honest chain has to catch back up
1068 2017-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
1069 2017-01-12T23:04:05  <BlueMatt> cfields: you massively underestimate how trivial it is to pwn most pool servers' hosting providers
1070 2017-01-12T23:04:27  <BlueMatt> also, remember that there is no auth on stratum
1071 2017-01-12T23:05:04  *** fanquake has quit IRC
1072 2017-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
1073 2017-01-12T23:05:43  <jtimon> cfields: maybe it's that I underestimate the loss of using 1 month instead of 1 week...
1074 2017-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)
1075 2017-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
1076 2017-01-12T23:16:27  <cfields> BlueMatt: updated 9441. Now going over 9375 one last time.
1077 2017-01-12T23:23:07  *** chjj has quit IRC
1078 2017-01-12T23:31:49  *** PaulCapestany has quit IRC
1079 2017-01-12T23:37:39  *** chjj has joined #bitcoin-core-dev
1080 2017-01-12T23:42:09  *** PaulCapestany has joined #bitcoin-core-dev
1081 2017-01-12T23:50:12  *** str4d has quit IRC
1082 2017-01-12T23:57:07  *** wvr has quit IRC