1 2016-07-28T00:02:52  *** evoskuil has joined #bitcoin-core-dev
  2 2016-07-28T00:53:05  *** belcher has quit IRC
  3 2016-07-28T00:55:09  *** netzin has joined #bitcoin-core-dev
  4 2016-07-28T01:00:33  *** netzin has quit IRC
  5 2016-07-28T01:05:49  *** Ylbam has quit IRC
  6 2016-07-28T01:24:12  *** netzin has joined #bitcoin-core-dev
  7 2016-07-28T01:36:00  *** shesek has quit IRC
  8 2016-07-28T01:39:37  *** xiangfu has quit IRC
  9 2016-07-28T01:40:59  *** xiangfu has joined #bitcoin-core-dev
 10 2016-07-28T01:55:12  *** TomMc has quit IRC
 11 2016-07-28T01:55:18  *** PRab has quit IRC
 12 2016-07-28T02:01:06  *** shesek has joined #bitcoin-core-dev
 13 2016-07-28T02:24:11  *** Alopex has quit IRC
 14 2016-07-28T02:25:16  *** Alopex has joined #bitcoin-core-dev
 15 2016-07-28T02:35:11  *** Alopex has quit IRC
 16 2016-07-28T02:36:16  *** Alopex has joined #bitcoin-core-dev
 17 2016-07-28T02:38:38  *** nsh has quit IRC
 18 2016-07-28T02:41:44  *** nsh has joined #bitcoin-core-dev
 19 2016-07-28T02:51:13  *** justanotheruser has quit IRC
 20 2016-07-28T02:51:53  *** Chris_Stewart_5 has quit IRC
 21 2016-07-28T02:56:30  *** justanotheruser has joined #bitcoin-core-dev
 22 2016-07-28T03:07:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 23 2016-07-28T03:17:30  *** TomMc has joined #bitcoin-core-dev
 24 2016-07-28T03:24:26  *** Chris_Stewart_5 has quit IRC
 25 2016-07-28T03:47:33  *** TomMc has quit IRC
 26 2016-07-28T04:05:04  *** aalex__ has quit IRC
 27 2016-07-28T04:21:01  *** aalex__ has joined #bitcoin-core-dev
 28 2016-07-28T04:24:07  *** anu1 has joined #bitcoin-core-dev
 29 2016-07-28T04:27:54  *** anu0 has quit IRC
 30 2016-07-28T04:42:02  *** netzin has quit IRC
 31 2016-07-28T04:42:23  <GitHub179> [bitcoin] shinradev opened pull request #8415: Update tor.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8415
 32 2016-07-28T04:50:32  *** d_t has joined #bitcoin-core-dev
 33 2016-07-28T04:53:26  *** fengling has quit IRC
 34 2016-07-28T04:55:14  *** d_t has quit IRC
 35 2016-07-28T05:32:07  *** Alopex has quit IRC
 36 2016-07-28T05:33:12  *** Alopex has joined #bitcoin-core-dev
 37 2016-07-28T05:35:43  *** fengling has joined #bitcoin-core-dev
 38 2016-07-28T06:12:24  *** spudowiar has quit IRC
 39 2016-07-28T06:14:44  *** spudowiar has joined #bitcoin-core-dev
 40 2016-07-28T06:27:21  *** spudowiar has quit IRC
 41 2016-07-28T06:36:08  *** btcfan has joined #bitcoin-core-dev
 42 2016-07-28T06:36:14  *** d_t has joined #bitcoin-core-dev
 43 2016-07-28T06:45:47  *** BashCo has quit IRC
 44 2016-07-28T06:47:47  *** jannes has joined #bitcoin-core-dev
 45 2016-07-28T06:49:52  <jonasschnelli> wumpus: I guess this is now safe: https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R446
 46 2016-07-28T07:03:38  *** d_t has quit IRC
 47 2016-07-28T07:07:09  *** jtimon has quit IRC
 48 2016-07-28T07:08:26  *** BashCo has joined #bitcoin-core-dev
 49 2016-07-28T07:14:26  *** fengling has quit IRC
 50 2016-07-28T07:16:15  *** fengling has joined #bitcoin-core-dev
 51 2016-07-28T07:24:07  *** AaronvanW has quit IRC
 52 2016-07-28T07:31:36  <wumpus> jonasschnelli: I don't think that will work; you just moved settings.value(strSettingsVersionKey)  to the end
 53 2016-07-28T07:32:08  <wumpus> jonasschnelli: what do you have against what I suggested there? settingsVersion = settings.contains(strSettingsVersionKey) ? settings.value(strSettingsVersionKey) : 0;   upfront, then use then from there on
 54 2016-07-28T07:32:20  <wumpus> also saves calls to settings.value()
 55 2016-07-28T07:34:45  *** AaronvanW has joined #bitcoin-core-dev
 56 2016-07-28T07:34:45  *** AaronvanW has joined #bitcoin-core-dev
 57 2016-07-28T07:35:12  <GitHub154> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4d4970fe530a...c24b50ec168e
 58 2016-07-28T07:35:12  <GitHub154> bitcoin/master d3af342 Kaz Wesley: prepend license statement to indirectmap...
 59 2016-07-28T07:35:13  <GitHub154> bitcoin/master c24b50e Wladimir J. van der Laan: Merge #8414: prepend license statement to indirectmap.h...
 60 2016-07-28T07:35:24  <GitHub100> [bitcoin] laanwj closed pull request #8414: prepend license statement to indirectmap.h (master...indirectmap-license) https://github.com/bitcoin/bitcoin/pull/8414
 61 2016-07-28T07:35:57  <wumpus> by regarding the absence of strSettingsVersionKey as settings version 0, it will do exactly what you want
 62 2016-07-28T07:51:27  <GitHub90> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c24b50ec168e...64d660a43fb8
 63 2016-07-28T07:51:27  <GitHub90> bitcoin/master 38c4c8b Jorge Timón: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock
 64 2016-07-28T07:51:28  <GitHub90> bitcoin/master 64d660a Wladimir J. van der Laan: Merge #8348: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock...
 65 2016-07-28T07:51:36  <GitHub120> [bitcoin] laanwj closed pull request #8348: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock (master...0.12.99-consensus-segwit) https://github.com/bitcoin/bitcoin/pull/8348
 66 2016-07-28T08:08:19  *** Guyver2 has joined #bitcoin-core-dev
 67 2016-07-28T08:11:42  <GitHub159> [bitcoin] shinradev closed pull request #8415: Update tor.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8415
 68 2016-07-28T08:11:55  <jonasschnelli> wumpus: Ah. Sorry. Didn't got your suggestion. But right, makes more sense.
 69 2016-07-28T08:11:59  <jonasschnelli> Let me change it
 70 2016-07-28T08:12:12  <wumpus> thanks :)
 71 2016-07-28T08:13:25  <jonasschnelli> Yes. Much cleaner...
 72 2016-07-28T08:17:06  *** fengling has quit IRC
 73 2016-07-28T08:19:07  <jonasschnelli> wumpus: updated and tested. https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R446
 74 2016-07-28T08:37:01  *** cdecker has joined #bitcoin-core-dev
 75 2016-07-28T08:39:18  *** xiangfu has quit IRC
 76 2016-07-28T08:39:21  <wumpus> jonasschnelli: you removed the check for nDatabaseCache==100 itself :)
 77 2016-07-28T08:39:36  <jonasschnelli> looking...
 78 2016-07-28T08:39:37  <wumpus> jonasschnelli: now it will always change the value to the default on an upgrade even if the user changed it
 79 2016-07-28T08:40:39  *** xiangfu has joined #bitcoin-core-dev
 80 2016-07-28T08:41:03  <jonasschnelli> damit. I should focus on one thing at the time. Thanks wumpus. What would we (I!) do without you...
 81 2016-07-28T08:41:03  <wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache")  && settings.value(strSettingsVersionKey).toInt() == 100)
 82 2016-07-28T08:41:39  *** cdecker has quit IRC
 83 2016-07-28T08:42:26  <wumpus> eh that's wrong
 84 2016-07-28T08:42:27  *** cdecker has joined #bitcoin-core-dev
 85 2016-07-28T08:42:39  <wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache")  && settings.value("nDatabaseCache").toInt() == 100)
 86 2016-07-28T08:42:48  <jonasschnelli> wumpus: that should be better: https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R447 right?
 87 2016-07-28T08:43:00  <wumpus> now I was confusing the settings names... this seems so trivial, but actually it's trivial to accidentally mess up
 88 2016-07-28T08:43:16  <jonasschnelli> yes. Needs to focus to get this right...
 89 2016-07-28T08:43:41  *** fengling has joined #bitcoin-core-dev
 90 2016-07-28T08:45:12  <wumpus> which is difficult with the heat
 91 2016-07-28T08:46:25  <wumpus> my plan is to at least test 8371 today
 92 2016-07-28T08:47:17  <wumpus> jonasschnelli: yes so if (settingsVersion < 130000 && settingsVersion == 100) also doesn't work, it makes the same confusion I did. We need to look at nDatabaseCache here :)
 93 2016-07-28T08:47:52  <jonasschnelli> hah. To dump...
 94 2016-07-28T08:48:38  <jonasschnelli> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value("nDatabaseCache"))?
 95 2016-07-28T08:48:51  *** kadoban has quit IRC
 96 2016-07-28T08:48:54  <jonasschnelli> .toInt() == 100 at the end
 97 2016-07-28T08:48:59  <wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value("nDatabaseCache").toInt()==100)
 98 2016-07-28T08:49:01  <wumpus> yes I think so
 99 2016-07-28T08:51:59  <wumpus> or toLongLong() as we seem to provide it as qint64
100 2016-07-28T08:56:51  <jonasschnelli> Yes. Probably better,... though I don't expect machines with that much RAM. :)
101 2016-07-28T08:57:21  <wumpus> I don't either, but I'm not certain how qt handled type conflicts there. If it works with toInt() that's good enough :)
102 2016-07-28T08:57:57  <jonasschnelli> Changed it to toLongLong() https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R447
103 2016-07-28T09:09:49  <wumpus> awesome
104 2016-07-28T09:14:59  <wumpus> looks good to me now
105 2016-07-28T09:15:51  <wumpus> going to test
106 2016-07-28T09:29:00  <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/64d660a43fb8...30a87c0747a1
107 2016-07-28T09:29:00  <GitHub189> bitcoin/master 893f379 Jonas Schnelli: [Qt] Add dbcache migration path
108 2016-07-28T09:29:01  <GitHub189> bitcoin/master 30a87c0 Wladimir J. van der Laan: Merge #8407: [Qt] Add dbcache migration path...
109 2016-07-28T09:29:16  <GitHub169> [bitcoin] laanwj closed pull request #8407: [Qt] Add dbcache migration path (master...2016/07/qt_dbcache) https://github.com/bitcoin/bitcoin/pull/8407
110 2016-07-28T09:30:01  <jonasschnelli> Should probably merge fine into 0.13
111 2016-07-28T09:30:15  *** Ylbam has joined #bitcoin-core-dev
112 2016-07-28T09:30:20  <wumpus> yep
113 2016-07-28T09:30:49  <GitHub153> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/45eba4b1e0658639bb92730723b987f05e171529
114 2016-07-28T09:30:50  <GitHub153> bitcoin/0.13 45eba4b Jonas Schnelli: [Qt] Add dbcache migration path...
115 2016-07-28T09:41:17  *** spudowiar has joined #bitcoin-core-dev
116 2016-07-28T09:42:57  *** cdecker has quit IRC
117 2016-07-28T09:43:36  *** cdecker has joined #bitcoin-core-dev
118 2016-07-28T09:45:26  <jonasschnelli> wumpus: thanks for testing, just changed the font and added the 2nd info text: https://github.com/bitcoin/bitcoin/pull/8371
119 2016-07-28T09:48:15  <wumpus> okay thanks for updating, will re-test again soon, now looking at 8389
120 2016-07-28T09:49:08  <wumpus> you've certainly been solving many 0.13.0rc1 issues quickly, where would we be without you
121 2016-07-28T09:53:14  <wumpus> looking for more review for: Prevent fingerprinting, disk-DoS with compact blocks #8408
122 2016-07-28T09:54:47  <jonasschnelli> Yes. 8389 is more important
123 2016-07-28T09:54:54  <jonasschnelli> Looking at 8408
124 2016-07-28T09:59:29  <jonasschnelli> 8408 makes sense. Props to sdaftuar! It needs extrem focus to find these issues...
125 2016-07-28T09:59:59  <wumpus> yes these are very sneaky, good to have them discovered and fixed before the release
126 2016-07-28T10:04:53  *** laurentmt has joined #bitcoin-core-dev
127 2016-07-28T10:04:59  *** YOU-JI has joined #bitcoin-core-dev
128 2016-07-28T10:06:46  *** laurentmt has quit IRC
129 2016-07-28T10:08:29  *** Ginnarr has joined #bitcoin-core-dev
130 2016-07-28T10:12:15  <wumpus> ooh, regtest has the same RPC default port as testnet. I only discover this now
131 2016-07-28T10:13:01  <jonasschnelli> wasn't aware of that...
132 2016-07-28T10:13:29  <jonasschnelli> Ah. Just the p2p port is differnt...
133 2016-07-28T10:13:57  <wumpus> me neither. Never tried to start a regtest node on the same host that was running a testnet node before
134 2016-07-28T10:14:23  <wumpus> it gives you: "Error: Unable to start HTTP server. See debug log for details." (where the log indeed contains details about failed binding)
135 2016-07-28T10:14:49  <wumpus> not a big issue just passing rpcport now, but I think it would make sense to bump that port number
136 2016-07-28T10:16:52  <wumpus> I get a "Warning: Error reading wallet.dat! All keys read correctly, but transaction data or address book entries might be missing or incorrect." with #8389, not sure why
137 2016-07-28T10:17:49  <wumpus> after that it just continues
138 2016-07-28T10:18:01  <wumpus> this is an old-fashioned, pre-HD wallet
139 2016-07-28T10:18:15  <jonasschnelli> let me have a look
140 2016-07-28T10:19:02  <jonasschnelli> wumpus: hmm.. that error should not be related to 8389 i guess
141 2016-07-28T10:19:11  <wumpus> let me see if it happens without
142 2016-07-28T10:19:24  <wumpus> maybe it's just a corrupted wallet, that's possible
143 2016-07-28T10:20:12  <wumpus> oops happens without #8408 too
144 2016-07-28T10:20:22  <wumpus> eh without 8389 I mean
145 2016-07-28T10:20:53  <jonasschnelli> hmm... this error means you had an error during ReadKeyValue() but not for a key
146 2016-07-28T10:21:17  <wumpus> moving wallet out of the way, creating a new non-HD wallet
147 2016-07-28T10:21:22  <jonasschnelli> I think your wallet.dat has a key that your current code cannot understand
148 2016-07-28T10:21:34  <jonasschnelli> yes. Maybe do a clean start
149 2016-07-28T10:22:33  <wumpus> that works fine, also after restarting bitcoind with that wallet
150 2016-07-28T10:22:56  <wumpus> so it was something specific to the previous wallet, maybe it was corrupted in some older testing. Ok, phew
151 2016-07-28T10:23:35  <wumpus> I've saved that wallet, might take a look at what key confused it later
152 2016-07-28T10:27:33  <wumpus> huh: dumpwallet result: cTjHTNHECpYNvFsJ2QXGVaDqbX8gX625S45Errqjy44oRHxPEzMc 2011-02-02T21:16:42Z hdmaster=1 # addr=mzUm95ZQPCVhGyPcJ3CvYwARBBQKX7efdR
153 2016-07-28T10:28:17  <wumpus> the date is wrong, and the key stayed the same before and after encryption
154 2016-07-28T10:29:00  <jonasschnelli> hmm... that's wrong. Let me retest. Maybe we have a rebase issue here...
155 2016-07-28T10:29:07  <jonasschnelli> Did you test with master? or 0.13?
156 2016-07-28T10:29:17  <wumpus> 0.13 (as that's what the pull is against)
157 2016-07-28T10:29:24  <jonasschnelli> Okay. Will do also.
158 2016-07-28T10:30:27  <jonasschnelli> We should implement the dumpwallet test as you mentioned in that issue yesterday.
159 2016-07-28T10:35:52  <wumpus> jonasschnelli: see https://github.com/bitcoin/bitcoin/pull/8389 for details on what I did
160 2016-07-28T10:36:08  * jonasschnelli is looking...
161 2016-07-28T10:36:55  <jonasschnelli> there is on inactivehdmaster....
162 2016-07-28T10:36:58  <jonasschnelli> s/on/no
163 2016-07-28T10:37:03  <jonasschnelli> hmm...
164 2016-07-28T10:37:11  <wumpus> indeed, there is no inactivehdmaster, and the hdmaster didn't change
165 2016-07-28T10:37:14  * jonasschnelli is still building 8389 on top of 0.13
166 2016-07-28T10:44:34  <jonasschnelli> wumpus: I'm running the same steps but get a clean/correct 2nd dump
167 2016-07-28T10:44:59  <jonasschnelli> Do you have the "Warning: Error reading wallet.dat! " in your log at the 2nd start of bitcoind?
168 2016-07-28T10:45:21  <jonasschnelli> We definitively need a RPC test for this...
169 2016-07-28T10:45:26  <jonasschnelli> going to write one now
170 2016-07-28T10:45:50  <wumpus> oh shit - I've been testing without #8389 merged
171 2016-07-28T10:46:17  <wumpus> I unmerged it because of testing the error message, then forgot to apply it again
172 2016-07-28T10:46:36  <wumpus> is this the expected output for pre-8389?
173 2016-07-28T10:47:13  <wumpus> LOL yes it is, look at http://www.hastebin.com/rugovalaqi.diff - it generates the same key again for the same hdkeypath
174 2016-07-28T10:47:44  <wumpus> going to retry with actually the right code, sorry
175 2016-07-28T10:48:56  <jonasschnelli> okay.. no problem. Better an mistake during testing then a mistake in the code.
176 2016-07-28T10:49:08  <jonasschnelli> But anyways,.. going to write a dumpwallet test
177 2016-07-28T10:49:21  <wumpus> yes, we need one anyway
178 2016-07-28T10:53:41  *** Giszmo has joined #bitcoin-core-dev
179 2016-07-28T10:55:21  <wumpus> trying to update my post to a tested ACK but I get pink unicorns
180 2016-07-28T10:56:04  <wumpus> BTW: unrelated to any of the HD changes, but I wonder why is a key generated with label="" at initial wallet initialization?
181 2016-07-28T10:56:21  <wumpus> I'm fairly sure it's always been the case, but it doesn't seem necessary
182 2016-07-28T10:58:26  <jonasschnelli> wumpus: During initial wallet created it always generate a first address... luke-jr once explained to my why this is necessary..
183 2016-07-28T11:00:31  <GitHub72> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/30a87c0747a1...806b9e7570a2
184 2016-07-28T11:00:31  <GitHub72> bitcoin/master e37b16a Daniel Cousens: transaction: clarify witness branches
185 2016-07-28T11:00:32  <GitHub72> bitcoin/master 806b9e7 Wladimir J. van der Laan: Merge #8332: semi trivial: clarify witness branches in transaction.h serialization...
186 2016-07-28T11:00:41  <GitHub10> [bitcoin] laanwj closed pull request #8332: semi trivial: clarify witness branches in transaction.h serialization (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8332
187 2016-07-28T11:00:51  <wumpus> curious
188 2016-07-28T11:03:47  <wumpus> created an issue https://github.com/bitcoin/bitcoin/issues/8416 (not relevant for 0.13, but now that we're slowly starting to commit to removing old wallet cruft)
189 2016-07-28T11:04:27  <jonasschnelli> I could imaging some function might run into problems if there are 0 receiving addresses...
190 2016-07-28T11:04:37  <jonasschnelli> Need to remove the default key and run all the RPC tests
191 2016-07-28T11:04:43  <wumpus> yes it's definitely something that requires extensive testing
192 2016-07-28T11:04:50  <wumpus> which is probably why no one ever dared remove that code :)
193 2016-07-28T11:06:05  <jonasschnelli> heh. Indeed
194 2016-07-28T11:07:28  *** spudowiar has quit IRC
195 2016-07-28T11:10:50  <GitHub88> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/45eba4b1e065...c3c82c48d9d7
196 2016-07-28T11:10:51  <GitHub76> [bitcoin] laanwj closed pull request #8389: [0.13] Create a new HD seed after encrypting the wallet (0.13...2016/07/hd_enc) https://github.com/bitcoin/bitcoin/pull/8389
197 2016-07-28T11:10:51  <GitHub88> bitcoin/0.13 f142c11 Jonas Schnelli: [0.13] Create a new HD seed after encrypting the wallet
198 2016-07-28T11:10:51  <GitHub88> bitcoin/0.13 de45c06 Jonas Schnelli: [Wallet] Add CKeyMetadata record for HDMasterKey(s), factor out HD key generation
199 2016-07-28T11:10:52  <GitHub88> bitcoin/0.13 c3c82c4 Wladimir J. van der Laan: Merge #8389: [0.13] Create a new HD seed after encrypting the wallet...
200 2016-07-28T11:11:17  <jonasschnelli> reminder: 8389 needs an "up-port" (my mistake)
201 2016-07-28T11:13:05  <wumpus> seems to apply cleanly to master, apart from the release-notes change which we can ignore there
202 2016-07-28T11:15:49  *** cryptapus has joined #bitcoin-core-dev
203 2016-07-28T11:15:49  *** cryptapus has joined #bitcoin-core-dev
204 2016-07-28T11:23:32  <GitHub54> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/2266b43e3317a889b9150e614169acda50383bf5
205 2016-07-28T11:23:32  <GitHub54> bitcoin/master 2266b43 Jonas Schnelli: Port from 0.13: Create a new HD seed after encrypting the wallet...
206 2016-07-28T11:25:07  *** btcfan has quit IRC
207 2016-07-28T11:28:05  <wumpus> ok that leaves https://github.com/bitcoin/bitcoin/pull/8408 and we can roll rc2!
208 2016-07-28T11:33:49  *** spudowiar has joined #bitcoin-core-dev
209 2016-07-28T11:41:35  *** Ginnarr has quit IRC
210 2016-07-28T11:54:21  <instagibbs> \o/
211 2016-07-28T11:54:28  <GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2266b43e3317...133c727cc4f7
212 2016-07-28T11:54:28  <GitHub124> bitcoin/master fbc6070 Thomas Snider: [trivial] Switched constants to sizeof()
213 2016-07-28T11:54:29  <GitHub124> bitcoin/master 133c727 Wladimir J. van der Laan: Merge #8321: [trivial] Switched constants to sizeof()...
214 2016-07-28T11:54:40  <GitHub32> [bitcoin] laanwj closed pull request #8321: [trivial] Switched constants to sizeof() (master...tjps_cleanups) https://github.com/bitcoin/bitcoin/pull/8321
215 2016-07-28T12:09:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
216 2016-07-28T12:22:07  *** laurentmt has joined #bitcoin-core-dev
217 2016-07-28T12:22:50  *** Chris_Stewart_5 has quit IRC
218 2016-07-28T12:24:56  *** anu0 has joined #bitcoin-core-dev
219 2016-07-28T12:28:25  *** anu1 has quit IRC
220 2016-07-28T12:42:07  *** cryptapus_ has joined #bitcoin-core-dev
221 2016-07-28T12:42:10  *** cryptapus_afk has quit IRC
222 2016-07-28T12:51:27  *** DongSwanson has quit IRC
223 2016-07-28T13:02:24  *** laurentmt has quit IRC
224 2016-07-28T13:02:50  *** YOU-JI has quit IRC
225 2016-07-28T13:07:27  <GitHub44> [bitcoin] jonasschnelli opened pull request #8417: [QA] Add walletdump RPC test (including HD- & encryption-tests) (master...2016/07/dump_test) https://github.com/bitcoin/bitcoin/pull/8417
226 2016-07-28T13:47:09  *** cryptapus_ has quit IRC
227 2016-07-28T13:47:22  *** cryptapus_ has joined #bitcoin-core-dev
228 2016-07-28T13:47:23  *** cryptapus_ has joined #bitcoin-core-dev
229 2016-07-28T13:47:23  *** cryptapus_ is now known as cryptapus_afk
230 2016-07-28T14:05:42  *** spudowiar has quit IRC
231 2016-07-28T14:20:35  *** molz has quit IRC
232 2016-07-28T14:23:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
233 2016-07-28T14:39:43  *** moli has joined #bitcoin-core-dev
234 2016-07-28T15:03:05  *** spudowiar has joined #bitcoin-core-dev
235 2016-07-28T15:14:41  *** Chris_Stewart_5 has quit IRC
236 2016-07-28T15:25:08  *** lightningbot has joined #bitcoin-core-dev
237 2016-07-28T15:29:07  *** laurentmt has joined #bitcoin-core-dev
238 2016-07-28T15:29:37  *** aj has quit IRC
239 2016-07-28T15:29:47  *** aj has joined #bitcoin-core-dev
240 2016-07-28T15:31:23  *** aalex__ has quit IRC
241 2016-07-28T15:32:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
242 2016-07-28T15:42:39  *** lightningbot has joined #bitcoin-core-dev
243 2016-07-28T15:42:55  *** wangchun has joined #bitcoin-core-dev
244 2016-07-28T15:52:39  *** BashCo_ has joined #bitcoin-core-dev
245 2016-07-28T15:55:51  *** BashCo has quit IRC
246 2016-07-28T16:07:04  *** Cory has quit IRC
247 2016-07-28T16:09:18  *** Pasha has joined #bitcoin-core-dev
248 2016-07-28T16:15:08  *** Chris_Stewart_5 has quit IRC
249 2016-07-28T16:16:12  *** Pasha is now known as Cory
250 2016-07-28T16:16:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
251 2016-07-28T16:21:36  *** BashCo_ has quit IRC
252 2016-07-28T16:25:36  *** BashCo has joined #bitcoin-core-dev
253 2016-07-28T16:38:39  *** achow101 has quit IRC
254 2016-07-28T16:39:20  *** achow101 has joined #bitcoin-core-dev
255 2016-07-28T16:44:24  <jonasschnelli> cfields: https://github.com/bitcoin/bitcoin/pull/8135
256 2016-07-28T16:44:39  <jonasschnelli> Is this still required? Lost track of the osx based deployment process...
257 2016-07-28T16:44:44  <jonasschnelli> If not, I can close the PR
258 2016-07-28T16:45:04  *** jtimon has joined #bitcoin-core-dev
259 2016-07-28T16:45:24  <cfields> jonasschnelli: let me take another look. pretty sure i walked away from that one to think on it a bit. all solutions are ugly :\
260 2016-07-28T16:45:56  <jonasschnelli> heh.. sure.. I don't really care. I think deploying (dmging) on OSX is not something we need to support.
261 2016-07-28T16:46:08  <jonasschnelli> Depends/gitian based deployment should be sufficient IMO
262 2016-07-28T16:46:33  <cfields> jonasschnelli: iirc macports/brew use it though
263 2016-07-28T16:46:43  <jonasschnelli> Ah. Okay. that could be...
264 2016-07-28T16:47:12  <jonasschnelli> Yes. Not sure if 8135 fixes it completly... I know it worked on my local mac when I tested it a couple of weeks ago
265 2016-07-28T16:47:39  <cfields> jonasschnelli: what do you think of just pulling the ~3 python libs directly into support/macdeploy?
266 2016-07-28T16:47:48  <cfields> i believe we patch them all already
267 2016-07-28T16:48:03  <cfields> (until upstream merges the fixes, that is)
268 2016-07-28T16:48:20  <jonasschnelli> Or pull in a script that downloads and patches them?
269 2016-07-28T16:48:31  <jonasschnelli> I don't want to blow up our code base...
270 2016-07-28T16:49:55  *** arubi has quit IRC
271 2016-07-28T16:50:22  <cfields> ok. thinking on it. i'll ack/pr something either way so we can move on
272 2016-07-28T16:51:14  *** spudowiar has quit IRC
273 2016-07-28T16:52:28  *** arubi has joined #bitcoin-core-dev
274 2016-07-28T16:52:52  <cfields> jonasschnelli: hmm, now that i think about it, macports/brew only use the .app and not the dmg. how about for osx we stop there, and only linux/gitian creates the dmg?
275 2016-07-28T16:56:20  <cfields> yes, they just use 'make appbundle'. so that works for me if it's ok by you
276 2016-07-28T17:01:01  <jonasschnelli> cfields: yes. I think this would make sense.
277 2016-07-28T17:01:05  *** BashCo_ has joined #bitcoin-core-dev
278 2016-07-28T17:01:12  <jonasschnelli> You don't need a dmg if you selfcompile
279 2016-07-28T17:01:37  <jonasschnelli> Only if you want to distribute... Which we should not encourage over non gitian
280 2016-07-28T17:03:52  *** BashCo has quit IRC
281 2016-07-28T17:10:55  <cfields> right
282 2016-07-28T17:16:45  *** d_t has joined #bitcoin-core-dev
283 2016-07-28T17:26:55  *** supasonic has joined #bitcoin-core-dev
284 2016-07-28T17:37:56  <jtimon> is there any tutorial for monkies like me to do the gitian builds for a given release?
285 2016-07-28T17:39:45  *** Guyver2_ has joined #bitcoin-core-dev
286 2016-07-28T17:40:28  <sipa> jtimon: https://github.com/bitcoin/bitcoin/blob/0.13/doc/gitian-building.md
287 2016-07-28T17:42:21  *** Guyver2 has quit IRC
288 2016-07-28T17:43:52  *** Guyver2_ is now known as Guyver2
289 2016-07-28T17:45:16  *** BitcoinErrorLog has joined #bitcoin-core-dev
290 2016-07-28T17:47:14  *** kadoban has joined #bitcoin-core-dev
291 2016-07-28T17:47:52  <jtimon> sipa: awesome, thanks
292 2016-07-28T17:48:44  <jtimon> looks very complete
293 2016-07-28T17:52:49  *** Chris_Stewart_5 has quit IRC
294 2016-07-28T18:00:33  *** adiabat has quit IRC
295 2016-07-28T18:09:09  *** Chris_Stewart_5 has joined #bitcoin-core-dev
296 2016-07-28T18:10:13  <GitHub99> [bitcoin] sdaftuar opened pull request #8418: Add tests for compact blocks (master...cb-testing) https://github.com/bitcoin/bitcoin/pull/8418
297 2016-07-28T18:19:52  <instagibbs> jtimon, I was able to walk through it fine.
298 2016-07-28T18:23:22  <jtimon> instagibbs: cool, I'm not planning on doing it today, but I would like to start doing it. Hopefully starting with 0.13's release
299 2016-07-28T18:26:38  <sipa> it takes a while :)
300 2016-07-28T18:26:53  <sipa> i went through it again for 0.13.0rc1
301 2016-07-28T18:29:16  *** netzin has joined #bitcoin-core-dev
302 2016-07-28T18:30:49  *** netzin has quit IRC
303 2016-07-28T18:34:10  *** netzin has joined #bitcoin-core-dev
304 2016-07-28T18:34:20  <GitHub152> [bitcoin] sdaftuar opened pull request #8419: Enable size accounting in mining unit tests (master...fix-mining-tests) https://github.com/bitcoin/bitcoin/pull/8419
305 2016-07-28T18:34:35  *** netzin is now known as nets1n
306 2016-07-28T18:35:45  <sdaftuar> sipa: i am having a hard time parsing your comment in #8408
307 2016-07-28T18:39:24  *** supasonic has quit IRC
308 2016-07-28T18:39:31  <sipa> sdaftuar: in general, peers should not send getblocktxn for anything near the tip
309 2016-07-28T18:39:40  <sipa> *anything not near the tip
310 2016-07-28T18:39:51  <sdaftuar> right, agreed
311 2016-07-28T18:40:00  <sdaftuar> are you suggesting that we disconnect for old blocks as wel?
312 2016-07-28T18:40:09  <sdaftuar> rather than not disconnect for unknown blocks?
313 2016-07-28T18:40:37  <sipa> if they do, they're either confused (and they're better off with us disconnecting them, or they'll wait long before timing out) or trying to do something nasty (in which case we're better off disconnecting them)
314 2016-07-28T18:40:58  <sipa> the question is whether there are no cases under which this can happen accidentally
315 2016-07-28T18:41:11  <sdaftuar> i assumed naively that this could happen on testnet
316 2016-07-28T18:41:32  <sdaftuar> ie without much rigorous thought
317 2016-07-28T18:41:54  <sdaftuar> mostly i guess i was comparing the handling of getblocktxn to how we handle getdata requests
318 2016-07-28T18:42:33  <sdaftuar> where we silently ignore unknown, and non-main-chain old blocks
319 2016-07-28T18:43:03  <sipa> ok, in that case let's follow the same approach
320 2016-07-28T18:43:39  <sipa> i think there is a lot of behaviour that's ad hoc and hard to reason about there, but at least that follows existing tested code
321 2016-07-28T18:44:00  <sipa> but perhaps we should rethink this in a bigger rework-block-sync-logic in the future...
322 2016-07-28T18:44:03  <sdaftuar> fyi i did add a test in #8418 that catches the behaviors corrected in #8408
323 2016-07-28T18:44:20  <sdaftuar> but 8418 is so much code that i didn't think it necessarily made sense as a bugfix PR for 0.13.0
324 2016-07-28T18:44:39  <sipa> agree
325 2016-07-28T18:45:05  <sipa> wait; 8418 has no changed behaviour, apart from what is already in 8408?
326 2016-07-28T18:45:09  <sipa> i assume
327 2016-07-28T18:45:15  <sdaftuar> it has one changed behavior, the new command line option -bip9params
328 2016-07-28T18:45:25  <sdaftuar> i needed a way to turn off segwit on regtest
329 2016-07-28T18:45:32  <sipa> sure sure
330 2016-07-28T18:45:42  <sipa> i mean it should no impact on anything in mainnet
331 2016-07-28T18:46:02  <sdaftuar> yes, agreed.  it's a lot of testing code, plus something that should be regtest-only
332 2016-07-28T18:46:13  <sdaftuar> assuming i didn't screw up :)
333 2016-07-28T18:48:28  * luke-jr won't be able to make the meeting today
334 2016-07-28T18:50:44  *** jcorgan has joined #bitcoin-core-dev
335 2016-07-28T19:00:05  * jonasschnelli rings the bell
336 2016-07-28T19:00:12  <gmaxwell> #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
337 2016-07-28T19:00:14  <jtimon> ready
338 2016-07-28T19:00:21  <cfields> thanks, here
339 2016-07-28T19:00:28  <sipa> present
340 2016-07-28T19:00:45  <instagibbs> pre-zent
341 2016-07-28T19:01:03  <wumpus> #startmeeting
342 2016-07-28T19:01:03  <lightningbot> Meeting started Thu Jul 28 19:01:03 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
343 2016-07-28T19:01:03  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
344 2016-07-28T19:01:05  <kanzure> greetings
345 2016-07-28T19:01:42  <wumpus> topc suggestions?
346 2016-07-28T19:01:49  <jtimon> proposed topic eliminate ISM (NicolasDorier's #8391)
347 2016-07-28T19:02:10  <luke-jr> about to board flight..
348 2016-07-28T19:02:15  <wumpus> rc2 is very near being tagged, https://github.com/bitcoin/bitcoin/milestone/20, could use some extra review for https://github.com/bitcoin/bitcoin/pull/8408
349 2016-07-28T19:02:40  <wumpus> but that's the only remaining pull tagged 0.13 left
350 2016-07-28T19:02:48  <luke-jr> wumpus: releadse notes still need to not recommend/opressure bad policy
351 2016-07-28T19:03:08  <wumpus> luke-jr: ok
352 2016-07-28T19:03:19  <luke-jr> tag applicable pr pls
353 2016-07-28T19:03:20  <jtimon> wumpus: shouldn't #8412 be in 0.13?
354 2016-07-28T19:03:25  <wumpus> but I guess people don't agree on what 'bad policy' is
355 2016-07-28T19:03:38  <kanzure> also about to board a flight in a bit
356 2016-07-28T19:03:41  <luke-jr> wumpus: …
357 2016-07-28T19:03:50  <gmaxwell> luke-jr: don't elipises wumpus.
358 2016-07-28T19:03:51  <jonasschnelli> I think it should
359 2016-07-28T19:03:57  <jonasschnelli> (8412)
360 2016-07-28T19:04:19  <jonasschnelli> I'll tag it
361 2016-07-28T19:04:20  <jtimon> in fact, I think it should go in 0.12.2 if there's going to be one
362 2016-07-28T19:04:27  <wumpus> I'm fine with 8412, hadn't heard of it before
363 2016-07-28T19:04:40  <jtimon> wumpus: yeah, just created it yesterday
364 2016-07-28T19:04:47  <sipa> 8412 seems harmless and silly not to include
365 2016-07-28T19:04:53  <jonasschnelli> It's a inconsequence with no risk attached to it (IMO)
366 2016-07-28T19:05:00  <wumpus> seems we agree
367 2016-07-28T19:05:08  <jtimon> great
368 2016-07-28T19:05:18  <luke-jr> the current release nites recommends and undisputably bad policy. if there is controversy it shouldnt recommend anything
369 2016-07-28T19:05:32  <wumpus> luke-jr: do you have a proposed update to the release notes?
370 2016-07-28T19:05:37  <gmaxwell> RE 8412: why are we adding flags for long locked in network features?
371 2016-07-28T19:05:59  <cfields> sdaftuar: any clues where to poke at #8096? Do you still think that's a blocker for release, or calling it a fluke?
372 2016-07-28T19:06:22  <luke-jr> wumpus: yes, the pr is open for a week now
373 2016-07-28T19:06:33  <cfields> err.. sorry for topic drift. we can pick that up later.
374 2016-07-28T19:06:36  <jtimon> what is the "bad policy"? what am I missing?
375 2016-07-28T19:06:43  <gmaxwell> okay never mind, I didn't look at the patch initially, I thought it was GBT rather than libconsensus.
376 2016-07-28T19:06:52  <wumpus> luke-jr: the only PR I know of also changes quite some code
377 2016-07-28T19:06:55  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8388/
378 2016-07-28T19:07:05  <jonasschnelli> Yes. Its not an release not only PR
379 2016-07-28T19:07:12  <morcos> luke-jr: i don't understand why we need to change anything now.  segwit is not released.  using blockmaxcost is fine for 0.13
380 2016-07-28T19:07:17  <gmaxwell> s/not/note/
381 2016-07-28T19:07:26  <luke-jr> jtimon: blockmaxweight rsther than blockmaxsize
382 2016-07-28T19:07:27  <morcos> uh, or weight
383 2016-07-28T19:07:44  <jonasschnelli> gmaxwell: thanks. :)
384 2016-07-28T19:07:58  <luke-jr> wumpus: because people were insisting the code had to change to remove the recommencaation
385 2016-07-28T19:08:14  <gmaxwell> I think it's foolish that we're still releasing with settings that don't reflect the near ubiquitious network usage.
386 2016-07-28T19:08:32  <sipa> luke-jr: we shouldn't be relying on miners picking safe policy that only harms themselves
387 2016-07-28T19:08:37  <jtimon> gmaxwell: on that note, agree with sipa that we should decouple the consensus flags bit poisitions from the script flags', but that's only for master
388 2016-07-28T19:08:48  <sipa> luke-jr: if we're not fine with larger blocks, we shouldn't do segwit as-is
389 2016-07-28T19:09:02  <morcos> sipa: agreed
390 2016-07-28T19:09:15  <morcos> where we is the big we
391 2016-07-28T19:09:16  <sipa> in practice, nearly every miner will set the max block size and weight to the maximum allowed value
392 2016-07-28T19:09:22  <sipa> morcos: yes!
393 2016-07-28T19:09:40  <luke-jr> sipa: we cannot stop segwit for better or worse
394 2016-07-28T19:09:46  <gmaxwell> Asking miners to produce blocks smaller than the network technically allows is a failed policy, in nay case, as we've seen. The default has been 750k-- but go look at the chain, no 750k blocks to be seen. :P
395 2016-07-28T19:09:48  <luke-jr> and hopefully in some monthhs larger blocks WILL vbe fine
396 2016-07-28T19:10:00  <luke-jr> sipa: prqactice is tbd
397 2016-07-28T19:10:01  <sipa> luke-jr: 'fine' is not a boolean
398 2016-07-28T19:10:27  <luke-jr> i need to board…
399 2016-07-28T19:10:32  *** spudowiar has joined #bitcoin-core-dev
400 2016-07-28T19:10:41  <wumpus> gmaxwell: on the other hand, miners not dumbly using the default settings is great, it's exactly what should be happening
401 2016-07-28T19:10:44  <gmaxwell> luke-jr: well nothing special will happen because you aren't here. :P go board, we can talk later.
402 2016-07-28T19:10:45  <morcos> i think it would be fine to include an explanation of the difference in the release notes without making a judgement about whether or not you should want to have blocks with size smaller than what might be created if you only limited by weight
403 2016-07-28T19:10:54  <luke-jr> bbl
404 2016-07-28T19:11:30  *** I_DID_LSD_ON_A_P has joined #bitcoin-core-dev
405 2016-07-28T19:11:49  <jtimon> the way I see it, the default is stupid to kind of force miners not to use the default (and to avoid being changing some defaults all the time)
406 2016-07-28T19:11:57  <morcos> if we don't recommend using size but explain why the option exists, then i also see no reason to cache size, if some people want to use it, its ok if its calc'ed on the fly (as current code does)_
407 2016-07-28T19:12:06  <jtimon> so the issue is that weight has a bigger default than size had?
408 2016-07-28T19:12:10  <wumpus> jtimon: yes, I thought that was the point
409 2016-07-28T19:12:30  <wumpus> jtimon: otherwise it's back to 'devs decide the values'
410 2016-07-28T19:12:46  <btcdrak> sorry I am late. #8412 should be included.
411 2016-07-28T19:12:52  <jtimon> yeah, and people asking to increase op_return size and shit
412 2016-07-28T19:13:20  <gmaxwell> IMO we should just make the defaults the maximums. Doing otherwise is thereatics, we know that users will immediately set them to the largest allowed values. And the few that wouldn't will happily manually reduce them.
413 2016-07-28T19:13:52  <jtimon> re #8412 should I open the PR to 0.13 then?
414 2016-07-28T19:13:54  <gmaxwell> this argument specifically applies to the 'max weight/size' things because we have expirence there with how they will be set in practice.
415 2016-07-28T19:14:20  <sipa> jtimon: 8412 will backport trivially, no need for backport PR
416 2016-07-28T19:14:35  <gmaxwell> (also, FWIW, the income difference between 750k size and maximum is non-trivial).
417 2016-07-28T19:15:29  <jtimon> no strong opinion, it seems natural to take the oportunity of moving from size to weight to change the default to something more used, but I will complain when somebody asks to change it later
418 2016-07-28T19:15:34  <wumpus> I really don't like to go back to discussing what defaults to use, e.g. we've had tons of pull requests to change the default block size and we've always used the reasoning explained by jtimon to hold them off
419 2016-07-28T19:15:40  <wumpus> but indeed, no strong opinion either
420 2016-07-28T19:16:10  <jtimon> if we want to set a lower default to "force people" not to use defaults there, that's fine with me as well
421 2016-07-28T19:16:31  <sipa> the current 0.13 code does not change any defaults
422 2016-07-28T19:16:36  <morcos> wumpus: i suppose the confusion is that now that we have 2 options, its totally non-intuitive how to se tthem given they have non max defaults
423 2016-07-28T19:16:46  <jtimon> sipa: then what's the problem again?
424 2016-07-28T19:16:49  <sipa> and the release notes explain the difference, and that only using weight is faster
425 2016-07-28T19:16:54  <wumpus> yes, what is the problem then?
426 2016-07-28T19:16:58  <sipa> i think the code and notes in 0.13 are fine
427 2016-07-28T19:17:15  *** supasonic has joined #bitcoin-core-dev
428 2016-07-28T19:17:46  <gmaxwell> The notes don't seem to inform me how to set it to the maximum.
429 2016-07-28T19:18:07  <gmaxwell> which is what 99% of the users are going to want to do, as it's what they currently do.
430 2016-07-28T19:18:21  <sipa> ok, let's fix that in the --help message?
431 2016-07-28T19:18:47  <gmaxwell> They won't read that. They'll read the release notes with greater odds than --help.
432 2016-07-28T19:18:55  <wumpus> if it's what they currently do ,then why would the default even matter? they override it already.
433 2016-07-28T19:18:57  <gmaxwell> (otherwise they wouldn't know of the maxweight option at all)
434 2016-07-28T19:18:58  <sipa> i assume they'll read neither
435 2016-07-28T19:19:13  <sdaftuar> (Note that for mainnet, in this release, the equivalent parameter for -blockmaxweight would be four times the desired -blockmaxsize. See BIP 141 for additional details.)
436 2016-07-28T19:19:16  <morcos> you need to know how to set the limits to max, and also not have the code to unnecessary extra serialization
437 2016-07-28T19:19:28  <gmaxwell> The default doesn't matter, except it forces people to override, which they'll likely get wrong now that it's been made more complicated.
438 2016-07-28T19:19:59  <wumpus> in any case the help message and release notes should be clear, if they are missing information that needs to be added
439 2016-07-28T19:20:16  *** yep has joined #bitcoin-core-dev
440 2016-07-28T19:20:22  <gmaxwell> E.g. you'll read that release note and then change your maxsize to maxweight, and then be surprised when their blocks are 250k. :P
441 2016-07-28T19:20:43  <achow101> why not just set it to the max? I can't see any reason why users would complain about that given that that is what they are going to do anyways
442 2016-07-28T19:21:13  <gmaxwell> achow101: that was the argument I was making before. wumpus correctly notes that going and debating defaults again isn't great.
443 2016-07-28T19:21:17  <jtimon> gmaxwell: ok, so you want to just clarify how to select the max block size in the --help because now it's more complicated than before and add something to the release notes?
444 2016-07-28T19:21:30  <gmaxwell> In particular luke will go on a public attack campaign, and some are trying to avoid it.
445 2016-07-28T19:21:42  <wumpus> because we should not be in the business of determining what values miners should use, we've always tried to avoid that, for good reason
446 2016-07-28T19:21:47  <gmaxwell> (because he sees a kind of principled position arising from setting a more correct default which no one uses)
447 2016-07-28T19:22:34  <gmaxwell> wumpus: not at question of should, it's a question of 'does', and forcing people to set settings which are now somewhat complex due to the new option is a bit unfortunate.
448 2016-07-28T19:22:38  <wumpus> if you want to inform people how to set the maximum, then adding how to do so in the release notes makes sense
449 2016-07-28T19:22:52  <gmaxwell> yes, I can make a PR that explains how to do that.
450 2016-07-28T19:22:53  <wumpus> gmaxwell: we've been there; this really feels like deja vu
451 2016-07-28T19:23:34  <wumpus> so to be clear: the current 0.13 defaults will cause miners to do something else than create 750kb blocks, as was the case for 0.12?
452 2016-07-28T19:23:56  <gmaxwell> No, the defaults are functionally equal to 0.12's.
453 2016-07-28T19:23:59  <sdaftuar> wumpus: no, that is not the case.
454 2016-07-28T19:24:07  <wumpus> ok, good then
455 2016-07-28T19:24:17  <morcos>  i think the release notes are accurate and relatively comprehensive enough right now.  unfortunately, i think the logic that exists is complicated enough that miners will make mistakes and either create smaller blocks than they meant to or slow down their mining computation
456 2016-07-28T19:24:32  <gmaxwell> the default maxweight is 3 million, which, with no witness txn is exactly equal to 750k maxsize.
457 2016-07-28T19:24:43  <jtimon> I really don't understand luke-jr's issue if the defaults are untouched
458 2016-07-28T19:25:03  <morcos> i'm not sure what the solution to that is other than explaining exactly what you should do if you want to mine max size blocks, which might be seen as a recommendation
459 2016-07-28T19:25:25  <wumpus> explaining in the release notes and documentation is exactly the right thing to do
460 2016-07-28T19:25:29  <gmaxwell> jtimon: because a maxweight of 3m allows for a 3mb block in future versions with segwit activated and he doesn't want miners being instructed to use maxweight.
461 2016-07-28T19:25:31  <instagibbs> jtimon, theoretical size max would be 3MB I think
462 2016-07-28T19:25:35  <wumpus> so people understand what is being done
463 2016-07-28T19:25:50  <wumpus> instead of saying 'this is too complicated for you, just follow the defaults'
464 2016-07-28T19:26:10  <gmaxwell> wumpus: 'just follow the defaults' was never my position.
465 2016-07-28T19:26:31  <jtimon> gmaxwell: why do miners need to be instructed about maxweight before activation? (not that I'm against informing people beforehand)
466 2016-07-28T19:26:43  <gmaxwell> Rather, we have defaults that match AFAICT what _no one_ wants, meaning that there is no one who can go "oh what the defaults want is already what I want, so I don't have to screw with anything."
467 2016-07-28T19:26:50  <wumpus> gmaxwell: I know, but that's what would effectively happen if the defaults are just the maximum which everyone uses
468 2016-07-28T19:26:52  <morcos> gmaxwell: exactly
469 2016-07-28T19:27:42  <wumpus> gmaxwell: people will start using the defaults, and be recommended using the defaults, which makes us in charge of determining the values. Next release there will be 20 pulls again of people that want to change the default to their favourite value, to lead others into using it
470 2016-07-28T19:27:47  <morcos> jtimon: they need to be informed because we kept blockmaxsize as an option, but it is slower to calculate (by unknown amount)
471 2016-07-28T19:27:59  <gmaxwell> jtimon: because he believes its establishing a bad set of practices which will hold over. I think he's right that it will hold over.. but only slightly, people are also going to immediately crank to maximum. I think luke realizes this too, but is adopting a principled position of not supporting something he thinks is bad even if it is inevitable.
472 2016-07-28T19:28:00  <jtimon> ok, so imagining what most are doing and assuming they don't touch their configuration for now and don't do anything about weigh (ie use the default), everything will be fine, right?
473 2016-07-28T19:28:16  <gmaxwell> And he think it is bad until compactblock deployment has proven that miners producing larger blocks is okay.
474 2016-07-28T19:28:16  <jtimon> morcos: I see
475 2016-07-28T19:28:18  <wumpus> hence, I really think defaults discussion is a waste of time, it just creates more of the same
476 2016-07-28T19:29:08  <gmaxwell> instead we get worse discussions because we have setting which actively trip up users.
477 2016-07-28T19:29:08  <sipa> i think we can just leave defaults as they are now
478 2016-07-28T19:29:21  <gmaxwell> Sorry, wumpus, the software doesn't exist to save us from discussion, it exists to serve its users.
479 2016-07-28T19:29:28  <wumpus> that's what we've learned from previous messing around with defaults, I don't understand why you've certainly changed your mind about this
480 2016-07-28T19:29:28  <gmaxwell> I agree that we can leave them.
481 2016-07-28T19:29:31  <instagibbs> ack for leaving as-is
482 2016-07-28T19:29:45  <jtimon> mhmm, if they were creating bigger blocks, they will keep doing so, and if they were using the default, they will keep doing so
483 2016-07-28T19:29:57  <gmaxwell> But we need instructions for setting them to maximum, because as is people will screw it up and produce 250k blocks (and if you care about complaining: they'll accuse us of being sneaky)
484 2016-07-28T19:30:08  <wumpus> gmaxwell: where did I claim that the software exists to save us from discussion!??
485 2016-07-28T19:30:14  <wumpus> gmaxwell: wtf is this
486 2016-07-28T19:30:16  <jtimon> if they move to weigh because it's cheaper but still use the default, the size is the same
487 2016-07-28T19:30:19  <morcos> I think the lesson to be learned here is we make the code too complicated by trying to be all things to all people.  For policy (not consensus) related decisions, i don't think we need to be able to support every possible thing.   We waste so much time trying to shoehorn in things like priority and maxsize, while simultaneously trying to make the code more efficient
488 2016-07-28T19:30:31  <sipa> agree
489 2016-07-28T19:31:33  <gmaxwell> wumpus: I'm sorry, thats what I'm reading out of your position on the defaults. I feel like you're basically arguing that we should have setting we know are bad and don't match usage, because it allows to refuse to discuss the defaults.
490 2016-07-28T19:31:52  <Eliel_> Well, you could always just make the mining part refuse to function unless the user manually sets the required config values :P
491 2016-07-28T19:31:55  <gmaxwell> I think thats an argument that we should make the software objectively worse in order to avoid debates over what is better.
492 2016-07-28T19:32:04  <gmaxwell> I apologize for reading so much into it.
493 2016-07-28T19:32:06  <Eliel_> as in, no dfaults
494 2016-07-28T19:32:17  <jtimon> anyway, it seems this is mostly an issue for luke-jr, so I don't see the point in keeping discussing it while he is on a plane
495 2016-07-28T19:32:25  <achow101> Eliel_: it's not very user friendly though
496 2016-07-28T19:32:30  <sipa> how about we leave things as is, and in the future (whenever that may be) we find a way to simplify the options (back to one argument, for example)
497 2016-07-28T19:32:40  <sdaftuar> ACK simplifying in the future
498 2016-07-28T19:32:45  <morcos> sipa: i think thats the best we're going to get at this point
499 2016-07-28T19:32:47  <sipa> that can 1) solve the problem of inadvisable defaults
500 2016-07-28T19:32:49  <gmaxwell> But we really do need to have instructions on doing what people will do. And when we write those luke will complain because it will be arguable that we are endorsing those settings. Cannot escape the drama. :)
501 2016-07-28T19:33:07  <wumpus> Eliel_: yes, that has been suggested before
502 2016-07-28T19:33:19  <sipa> and 2) by changing things at the same time as simplifying the logic, it is not necessarily a recommendation
503 2016-07-28T19:33:21  <achow101> gmaxwell: just tell him to suck it up  and deal with it
504 2016-07-28T19:33:22  <Eliel_> achow101: that depends... if the error message comes with a link to a good instructional document, it might actually be a pretty good result.
505 2016-07-28T19:33:36  <gmaxwell> luke only insisted we have the size option because compactblocks is not yet deployed, and if relay network isn't working, orphaning is highly related to size.
506 2016-07-28T19:33:46  <gmaxwell> It didn't seem like it was worth debating.
507 2016-07-28T19:33:52  <morcos> gmaxwell: i'd argue we can leave the release notes as is (which luke might still object to) and then just use other channels to explain to people very simply how they can create max blocks if they want.  simple.  set -blockmaxweight=4000000 and dont' set blockmaxsize at all
508 2016-07-28T19:33:57  <wumpus> Eliel_: it may be better than setting silly defaults, but there was never agreement to do it
509 2016-07-28T19:34:09  <gmaxwell> morcos: I can agree with that too.
510 2016-07-28T19:34:24  <jtimon> gmaxwell: maybe overkill instructions with all the options (keep using the default in a more efficient way (ie not using maxsize) and do what most poeple do) is enough for luke-jr?
511 2016-07-28T19:34:26  <Eliel_> wumpus: that's pretty much my reasoning behind the suggestion.
512 2016-07-28T19:34:41  <Eliel_> if you can't set defaults the way most people want them, don't set any.
513 2016-07-28T19:34:51  <morcos> I'm also fine with that suggestion
514 2016-07-28T19:35:04  <gmaxwell> luke argued for that for years.
515 2016-07-28T19:35:11  <Eliel_> and about user friendliness... do you really want to allow people to mine without understanding what they're doing?
516 2016-07-28T19:35:15  <wumpus> Eliel_: the thing is that people disagree deeply over these setings
517 2016-07-28T19:35:26  <jtimon> other topics?
518 2016-07-28T19:36:02  <wumpus> #topic eliminate ISM (NicolasDorier's #8391)
519 2016-07-28T19:36:11  <gmaxwell> Eliel_: absolutely.
520 2016-07-28T19:36:16  *** laurentmt has quit IRC
521 2016-07-28T19:36:51  <gmaxwell> Eliel_: participants in the network should be avoiding judgement, they're not in charge of the system because they participate.. and not because they have some theoretical technical ability to censor varrious behaviors.
522 2016-07-28T19:37:04  <kanzure> i need to leave. i would like to request that folks send me topic suggestions for my wishlist for the upcoming gathering. not end of the world if it doesn't happen, but having a few thoughts prepared is worthwhile.
523 2016-07-28T19:37:35  *** TomMc has joined #bitcoin-core-dev
524 2016-07-28T19:37:37  <wumpus> ping jtimon
525 2016-07-28T19:37:43  <jtimon> this is quite important for other libconsensus refactors, the sooner it is merged the easy it will be to PR other changes, I would really appreciate fast review, test and merge of #8391
526 2016-07-28T19:38:18  <jtimon> I would say it's the most important libconsensus' PR opened right now
527 2016-07-28T19:38:32  <wumpus> I think we already agreed removing ISM was a good thing lastm eeting, is there more to discuss about it?
528 2016-07-28T19:39:03  <jtimon> wumpus: well, I hope not, but that's why I bring it up (apart from asking for review)
529 2016-07-28T19:39:21  <wumpus> yes it does need more review/testing
530 2016-07-28T19:39:27  <wumpus> #action review https://github.com/bitcoin/bitcoin/pull/8391
531 2016-07-28T19:39:40  <jtimon> thanks
532 2016-07-28T19:39:42  <cfields> next topic suggestion: boost threads/sync replacement for master
533 2016-07-28T19:40:01  <wumpus> #topic boost threads/sync replacement for master
534 2016-07-28T19:40:11  <jtimon> and of course nacks and nits always the sooner the better
535 2016-07-28T19:40:16  <cfields> https://github.com/bitcoin/bitcoin/pull/8023
536 2016-07-28T19:40:27  <cfields> is nowish a good time to start pushing for that?
537 2016-07-28T19:40:37  <wumpus> sounds good to me
538 2016-07-28T19:41:18  <gmaxwell> neat.
539 2016-07-28T19:41:20  <cfields> ok. it's a drop-in replacement for interruptible boost threads/condvars. preferred to switch chunks at a time, or all in one go?
540 2016-07-28T19:41:26  <jtimon> cfields: since it's disruptive, the "refactor window" seems like the perfect time for it, no?
541 2016-07-28T19:41:31  <wumpus> what about your network refactor? seems we should start merging for that as well?
542 2016-07-28T19:42:11  <wumpus> cfields: what would 'chunks at a time' mean, using two potentially conflicting thread libraries?
543 2016-07-28T19:42:11  <cfields> wumpus: yea, review/acks of 2 outstanding PRs would be a big help...
544 2016-07-28T19:42:17  <jtimon> oh, #8023 is not disruptive at all
545 2016-07-28T19:42:23  <cfields> sec for numbers
546 2016-07-28T19:42:29  <wumpus> cfields: can you post the links? ok
547 2016-07-28T19:42:58  <NicolasDorier> I'm back.
548 2016-07-28T19:43:03  <NicolasDorier> for removing ISM
549 2016-07-28T19:43:04  <wumpus> welcome back
550 2016-07-28T19:43:10  <NicolasDorier> I synched nodes successfully
551 2016-07-28T19:43:20  <NicolasDorier> so basically, it needs some review from other people, but should be good
552 2016-07-28T19:43:27  <cfields> #8128 and #8085
553 2016-07-28T19:43:51  <btcdrak> NicolasDorier: ok I'll run a full sync this weekend
554 2016-07-28T19:43:52  <wumpus> #action review+test https://github.com/bitcoin/bitcoin/pull/8128 Net: Turn net structures into dumb storage classes
555 2016-07-28T19:44:03  <cfields> #8085 is a beast to rebase. I have it done locally, but I'm waiting for #8128 to go in before rebasing again and pushing
556 2016-07-28T19:44:10  <sipa> i tried switching some subset of the code to std::thread before, and it was impossible... you need to change it everywhere at once
557 2016-07-28T19:44:24  <wumpus> #action review+test https://github.com/bitcoin/bitcoin/pull/8085 p2p: Begin encapsulation
558 2016-07-28T19:44:54  <cfields> ok, I'll approach it as one big change then
559 2016-07-28T19:45:11  <wumpus> yes it probably makes most sense to do it all as once, it's painful but at least it should be a one time pain then
560 2016-07-28T19:46:24  <NicolasDorier> question: what you call "refactor windows" what is it ?
561 2016-07-28T19:46:31  <cfields> ok. iirc there are 1/2 pre-reqs left for boost-specific usage, then basically a search/replace. I'll go back through my notes and do pulls for the pre-reqs.
562 2016-07-28T19:47:52  <wumpus> NicolasDorier: well the best time for larger changes in 0.14 is now, as there's still some months to go before the release and there is enough time to address problems that come up
563 2016-07-28T19:48:16  <wumpus> e.g. you wouldn't want to switch the thread library a few days before release
564 2016-07-28T19:48:25  <NicolasDorier> ok nice to know, as I'm working around libconsensus... will go a bit quicker so
565 2016-07-28T19:48:49  <NicolasDorier> oh
566 2016-07-28T19:49:29  <NicolasDorier> about https://github.com/bitcoin/bitcoin/pull/8259 when will it be merged for 0.13 ?
567 2016-07-28T19:49:47  <jtimon> re ISM (sorry for not saying it earlier), thoughts on https://github.com/jtimon/bitcoin/commit/273e27bd0c086f5ba20cebc2f5ec9e24f9d79015 ? independently on adding it to the PR or leave it for later
568 2016-07-28T19:49:51  <sipa> NicolasDorier: we'll need to backport that to 0.13 before segwit
569 2016-07-28T19:50:03  <NicolasDorier> ok
570 2016-07-28T19:51:01  <wumpus> NicolasDorier: it's not even merged for master yet, after it is it can be backported
571 2016-07-28T19:51:05  *** droark has joined #bitcoin-core-dev
572 2016-07-28T19:51:37  <wumpus> I'll add a "needs backport" label
573 2016-07-28T19:51:50  <NicolasDorier> ok no prob
574 2016-07-28T19:52:03  <sipa> NicolasDorier: thanks for the reminder on that btw
575 2016-07-28T19:52:13  <wumpus> seems to need some more review too
576 2016-07-28T19:52:29  <NicolasDorier> jtimon: I'd like to see it go personally, but I don't know the reason why bip34Hash was here in the first place
577 2016-07-28T19:52:33  *** BashCo_ has quit IRC
578 2016-07-28T19:52:50  <sipa> jtimon: i vaguely remember there were ugly interactions between the cache code that avoids some database operation, bip30 and bip34... but i don't remember the details
579 2016-07-28T19:52:53  <wumpus> #action review https://github.com/bitcoin/bitcoin/pull/8259 Hash Cache
580 2016-07-28T19:53:09  *** BashCo has joined #bitcoin-core-dev
581 2016-07-28T19:53:14  <jtimon> uff, #8259 is ultra disruptive to consensus branch, should review...
582 2016-07-28T19:53:46  <NicolasDorier> jtimon: yes, I was asking because as part of our work on libconsensus, we'll need to be fixed on that
583 2016-07-28T19:54:21  <jtimon> yep, you agreed on #8346 first, right?
584 2016-07-28T19:54:46  <sipa> jtimon: 8259 will need backport to 0.13
585 2016-07-28T19:55:03  <NicolasDorier> yes
586 2016-07-28T19:56:07  <wumpus> ok, any final topics?
587 2016-07-28T19:57:01  <jtimon> sipa: damm, and #8346 cannot be backported because it's a refactor, "refactor winwow interlocking", before a release it's really the worse time to make refactors, but I repeated this many times...
588 2016-07-28T19:57:18  <wumpus> no, refactors will not be backported, that is too risky
589 2016-07-28T19:58:02  <jtimon> wumpus: then having the "refactor window" precisely when we're backporting more stuff is a bad idea
590 2016-07-28T19:58:03  <sipa> it's fine, we'll find a solution for that
591 2016-07-28T19:58:05  <wumpus> well wait until after the release then jtimon
592 2016-07-28T19:58:19  <wumpus> hopefully rc2 will be the last
593 2016-07-28T19:58:34  <wumpus> that'd mean the release can be next week or so
594 2016-07-28T19:58:48  <jtimon> wumpus: if that still counts as "refactor window" I'm happy, I know when they start but I don't have a clear idea on when they finish
595 2016-07-28T19:58:59  <sipa> wumpus: the issue is that 8346 won't be backported to 0.13, but 8259 will be, thus 8259 can't be based on that refactor
596 2016-07-28T19:59:31  <sipa> but i don't think it's a big issue
597 2016-07-28T19:59:32  <wumpus> sipa: yes, moving the refactor window to after the 0.13.0 release won't help for that
598 2016-07-28T19:59:53  <sipa> sometimes code needs non-trivial backports
599 2016-07-28T19:59:55  <sipa> so be it
600 2016-07-28T19:59:58  <wumpus> yes
601 2016-07-28T20:00:08  <wumpus> it's still trivial compared to backporting to 0.12
602 2016-07-28T20:00:23  <sipa> DOING
603 2016-07-28T20:00:26  <wumpus> #endmeeting
604 2016-07-28T20:00:26  <lightningbot> Meeting ended Thu Jul 28 20:00:26 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
605 2016-07-28T20:00:26  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-28-19.01.html
606 2016-07-28T20:00:26  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-28-19.01.txt
607 2016-07-28T20:00:26  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-28-19.01.log.html
608 2016-07-28T20:00:58  <sipa> DOH-ING
609 2016-07-28T20:01:02  <jtimon> but in this case means that my alternative refactor to checkinputs will never get reviewed or merged...(even if it's way way older than #8259), so my best option is to rewrite it as nits ot #8259 I guess...
610 2016-07-28T20:01:06  <gmaxwell> DOOIINNGGG
611 2016-07-28T20:01:09  *** thokon00 has joined #bitcoin-core-dev
612 2016-07-28T20:01:30  <jonasschnelli> sipa: time for your Pokemon walk. :P
613 2016-07-28T20:01:37  <sdaftuar> cfields: regarding #8096, i don't think i've seen that error since i first reported it.
614 2016-07-28T20:01:38  <jtimon> haha
615 2016-07-28T20:01:58  <wumpus> :P
616 2016-07-28T20:02:11  <NicolasDorier> jtimon: my 8259 in fact date back in march :D
617 2016-07-28T20:02:12  <cfields> sdaftuar: ok. I tried to investigate, but I couldn't even find a good starting point
618 2016-07-28T20:02:23  <NicolasDorier> I needed to refactor and reopen the issue several time
619 2016-07-28T20:02:29  *** cryptapus has quit IRC
620 2016-07-28T20:02:30  <NicolasDorier> I mean rebase
621 2016-07-28T20:02:37  <sdaftuar> i recall having no idea what could have happened :)  i just fired up a script to run that test until failure, hopefully i'll get something i can debug
622 2016-07-28T20:02:39  *** jcorgan has left #bitcoin-core-dev
623 2016-07-28T20:02:48  <NicolasDorier> (the first time 8259 was created was on sipa's branch before the merge :p)
624 2016-07-28T20:03:27  <jtimon> well, my approach is as old as #6061
625 2016-07-28T20:03:29  <cfields> sdaftuar: only thing I could think of is to add an assert(!empty()) at the beginning so at least we'll be able to tell if it was already empty, if we end up seeing another crash
626 2016-07-28T20:03:36  <wumpus> sdaftuar: cfields: in any case, the question was whether that should be a blocker; I don't think a rare test failure should qualify as a release blocker unless you strongly suspect it to be a deeper problem
627 2016-07-28T20:03:53  <sdaftuar> wumpus: i agree that it shouldn't be a blocker
628 2016-07-28T20:03:54  <jtimon> that was a "please don't do too much stuff at a time" PR for my approach
629 2016-07-28T20:04:24  <cfields> wumpus: i have no reason to suspect it's a major problem, i just don't like that we can't explain it :)
630 2016-07-28T20:04:53  <wumpus> sdaftuar: thanks, removing the milestone then
631 2016-07-28T20:05:31  <jtimon> NicolasDorier: last attempt to move in my direction: https://github.com/bitcoin/bitcoin/pull/6445
632 2016-07-28T20:05:34  <wumpus> cfields: yes I agree an unexplainable problem is slightly worrying
633 2016-07-28T20:07:01  <jtimon> it seems it was never the time until now, that it's too late because 8259 needs to be backported but #8346 can't, not your fault...
634 2016-07-28T20:07:20  <jtimon> should I close #8346 then?
635 2016-07-28T20:07:27  <jtimon> ping btcdrak
636 2016-07-28T20:08:04  <NicolasDorier> I don't think it should be closed, we'll just merge later
637 2016-07-28T20:08:10  <wumpus> jtimon: I agree that it's annoying
638 2016-07-28T20:08:18  <btcdrak> jtimon: leave it open
639 2016-07-28T20:08:28  <sipa> jtimon: leave it open
640 2016-07-28T20:08:33  <jtimon> NicolasDorier: oh, it's not disruptive to your approach, cool
641 2016-07-28T20:08:55  <wumpus> it has quite a lot of utACKs so just should be merged?
642 2016-07-28T20:09:14  <NicolasDorier> fine for me
643 2016-07-28T20:09:26  <jtimon> I thought it would interfere with #8259, sorry
644 2016-07-28T20:09:34  <sipa> it would, but so be it
645 2016-07-28T20:09:40  <sipa> sorry for bringing it uo
646 2016-07-28T20:10:04  <jtimon> never be sorry for bringing things up, that's what I need
647 2016-07-28T20:11:03  <NicolasDorier> I've rebased 8259 10 times, I guess I'll support an 11 th time :D
648 2016-07-28T20:11:09  <NicolasDorier> I've nothing to do today anyway :^p
649 2016-07-28T20:11:21  <jtimon> sipa: if you allow me to be honest, I feel you're some times "too polite" with me as a reviewer. Nits and nacks the sooner the better!
650 2016-07-28T20:11:58  <jtimon> anyway, I should review 8259 before continuing talking about it, sorry
651 2016-07-28T20:14:18  *** schmidty has quit IRC
652 2016-07-28T20:19:09  *** BashCo has quit IRC
653 2016-07-28T20:19:12  *** thokon00 has left #bitcoin-core-dev
654 2016-07-28T20:19:15  <jtimon> NicolasDorier: no harm in squashing #8259 at this point I think?
655 2016-07-28T20:22:29  *** nets1n has quit IRC
656 2016-07-28T20:24:42  *** anu1 has joined #bitcoin-core-dev
657 2016-07-28T20:27:12  *** ArthurNumbanumba has quit IRC
658 2016-07-28T20:27:51  *** anu0 has quit IRC
659 2016-07-28T20:33:27  *** Giszmo has quit IRC
660 2016-07-28T20:37:19  *** BashCo has joined #bitcoin-core-dev
661 2016-07-28T20:41:36  <NicolasDorier> jtimon: yes I'll squash. Will do it after changing stuff that need to change because of #8346.
662 2016-07-28T20:41:39  *** Giszmo has joined #bitcoin-core-dev
663 2016-07-28T20:41:56  <NicolasDorier> actually I think that 8346 will make it shorter to review in fact
664 2016-07-28T20:42:31  <NicolasDorier> because a method which needed the hash cache is not called anymore.
665 2016-07-28T20:43:45  *** dgenr8 has quit IRC
666 2016-07-28T20:44:32  *** droark has quit IRC
667 2016-07-28T20:45:16  <jtimon> cool
668 2016-07-28T20:45:47  <jtimon> keep the old version for the backport though
669 2016-07-28T20:46:48  <jtimon> rebase -i addict suggestion: and then try to rebase the old version on top of the new one and see what happens
670 2016-07-28T20:47:30  <jtimon> nothing to commit is complete success
671 2016-07-28T20:48:02  <jtimon> no, wait, forget the defintion of success, that's wrong
672 2016-07-28T20:48:11  *** windsok has quit IRC
673 2016-07-28T20:48:58  <NicolasDorier> In fact in https://github.com/bitcoin/bitcoin/pull/8259/files#diff-ca74c4b28865382863b8fe7633a85cd6L740 the hashCacheMap was not even use...
674 2016-07-28T20:49:10  <NicolasDorier> used
675 2016-07-28T20:49:16  <NicolasDorier> because it does not run the scripts
676 2016-07-28T20:49:18  *** windsok has joined #bitcoin-core-dev
677 2016-07-28T20:50:15  *** cryptapus_afk is now known as cryptapus_
678 2016-07-28T20:50:16  <jtimon> not sure I understand what you just said
679 2016-07-28T20:50:18  *** cryptapus_ is now known as cryptapus
680 2016-07-28T20:54:28  <NicolasDorier> jtimon: in the common piece of code we are touching between #8259 and #8346, I was passing a hashCacheMap as parameter to CheckInput. But it was not even used inside CheckInput because fCheckScript is false.
681 2016-07-28T20:55:19  <jtimon> oh, yeah, I see, was extending on the comment that it will be shorter for master than for 0.13
682 2016-07-28T20:56:40  <jtimon> in fact, you can remove the fCheckScript parameter "for free" in the same commit, as now all callers use false. That's for master, not for 0.13
683 2016-07-28T20:57:00  <jtimon> sorry, now all callers use true
684 2016-07-28T20:58:30  <NicolasDorier> oh that's cool
685 2016-07-28T20:59:47  <jtimon> or your life would be easier if you just backported both #8259 and #8346 instead of only one plus the differences of doing it in a different order, and would make people "forwardporting" stuff easier too, but that would be "cheating" by some defintion I am yet to unterstand
686 2016-07-28T21:02:47  <jtimon> that's ancient coolness that's been ready to pick up for long
687 2016-07-28T21:04:39  <jtimon> but what I really want to do is always call checkTxInputs way before checkInputs (before noone else calculates txFees in that function [ie ConnectBlock and AcceptToMemoryPool])
688 2016-07-28T21:05:14  <jtimon> and remove some redundant calculations while helping with encapsulation
689 2016-07-28T21:05:51  <jtimon> then divide the remaining checkinputs, one multi-thread and one plain simple
690 2016-07-28T21:06:18  <jtimon> of course there's many ways to do this
691 2016-07-28T21:08:07  <jtimon> the first version of verifyblock can be single threaded, we don't even have to expose it in libconsensus yet, just having it would be great (we can also expose it in rpc with the storage dependencies I guess, but not sure how useful that would be)
692 2016-07-28T21:10:12  <jtimon> when we figure out how to expose multi-threading, storage and caches, we can expose verifyblock in libconsensus, but that sounds too long term and that's why I was focusing on maybe exposing verifyheader or verifytx or getflags or whatever was ready first
693 2016-07-28T21:10:30  <jtimon> but I agree that just complete an internal verifyblock would be great
694 2016-07-28T21:10:38  *** cryptapus is now known as cryptapus_afk
695 2016-07-28T21:12:26  <jtimon> and I'm focusing on that now, like you, there's still some stuff I need to move up in my branch because it was about completing verifytx, but it's not needed for completing verifyblock (ie moving things out of contextualcheckblock() )
696 2016-07-28T21:13:49  <jtimon> btw, for trivial consensus stuff #8413 is also opened
697 2016-07-28T21:17:06  <bsm117532> ls
698 2016-07-28T21:19:05  *** yep has quit IRC
699 2016-07-28T21:19:35  *** jtimon has quit IRC
700 2016-07-28T21:19:57  *** jtimon has joined #bitcoin-core-dev
701 2016-07-28T21:21:09  <jtimon>  bsm117532:
702 2016-07-28T21:21:11  <jtimon>  drwxrwxr-x 23 jt jt     12288 jul 28 05:27 .
703 2016-07-28T21:21:13  <jtimon>  drwxrwxr-x 12 jt jt      4096 jul 28 05:24 ..
704 2016-07-28T21:25:03  *** d_t has quit IRC
705 2016-07-28T21:26:57  *** btcdrak has left #bitcoin-core-dev
706 2016-07-28T21:28:49  <bsm117532> [ whereis my brain?
707 2016-07-28T21:32:59  *** btcdrak has joined #bitcoin-core-dev
708 2016-07-28T21:37:16  *** slackircbridge has quit IRC
709 2016-07-28T21:37:29  *** slackircbridge has joined #bitcoin-core-dev
710 2016-07-28T21:38:37  *** dgenr8 has joined #bitcoin-core-dev
711 2016-07-28T21:44:16  <jtimon> bsm117532: in your brain and some other parts of your body, but wrong channel again
712 2016-07-28T21:45:20  <bsm117532> bash: [: missing `]'
713 2016-07-28T21:46:05  *** goatpig has joined #bitcoin-core-dev
714 2016-07-28T21:51:02  *** spudowiar has quit IRC
715 2016-07-28T21:54:07  *** netzin has joined #bitcoin-core-dev
716 2016-07-28T21:54:25  *** netzin is now known as nets1n
717 2016-07-28T21:54:40  *** spudowiar has joined #bitcoin-core-dev
718 2016-07-28T22:06:39  *** spudowiar has quit IRC
719 2016-07-28T22:20:35  *** moli has quit IRC
720 2016-07-28T22:39:15  *** moli has joined #bitcoin-core-dev
721 2016-07-28T22:49:24  *** nets1n has quit IRC
722 2016-07-28T22:51:45  *** Guyver2 has quit IRC
723 2016-07-28T22:53:00  <jtimon> updated #8346
724 2016-07-28T22:58:13  <cfields> sdaftuar: heh: i just forced a crash in PruneBlockIndexCandidates
725 2016-07-28T22:58:40  <cfields> not the same crash, but I suspect it's something similar
726 2016-07-28T22:59:24  <GitHub106> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/133c727cc4f7...ad087638ee48
727 2016-07-28T22:59:24  <GitHub106> bitcoin/master d12b732 Jorge Timón: libconsensus: Expose a flag for BIP112...
728 2016-07-28T22:59:25  <GitHub106> bitcoin/master ad08763 Pieter Wuille: Merge #8412: libconsensus: Expose a flag for BIP112...
729 2016-07-28T22:59:34  <GitHub127> [bitcoin] sipa closed pull request #8412: libconsensus: Expose a flag for BIP112 (master...0.13-consensus-bip112-flag) https://github.com/bitcoin/bitcoin/pull/8412
730 2016-07-28T23:00:50  <cfields> sdaftuar: http://pastebin.com/raw/CnV5HSUP. ctrl+c during startup.
731 2016-07-28T23:02:32  *** spudowiar has joined #bitcoin-core-dev
732 2016-07-28T23:06:51  <jtimon> illumination moment: there was a translation error in the way I was saying "for free": some times I meant "gratiously" I think
733 2016-07-28T23:07:13  *** spudowiar has quit IRC
734 2016-07-28T23:14:20  <jtimon> I wonder why native english speaker don't have some achronym for G.R.A.T.I.S. meaning something completely different yet...
735 2016-07-28T23:14:56  <GitHub140> [bitcoin] theuni opened pull request #8421: httpserver: drop boost (#8023 dependency) (master...http-thread) https://github.com/bitcoin/bitcoin/pull/8421
736 2016-07-28T23:15:34  *** cdecker has quit IRC
737 2016-07-28T23:19:42  <GitHub133> [bitcoin] sipa pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8360d5b37dd4d8248da0552de40e5ea1d17f51eb
738 2016-07-28T23:19:43  <GitHub133> bitcoin/0.13 8360d5b Jorge Timón: libconsensus: Expose a flag for BIP112...
739 2016-07-28T23:20:32  <sipa> NicolasDorier: i think you misunderstand my suggestion
740 2016-07-28T23:20:48  <NicolasDorier> mh maybe
741 2016-07-28T23:22:18  <NicolasDorier> sipa: my point is that lazily calculating the mid state hashes is not worth the added complexity. The only saving is for transaction having no SIGHASH_ALL.
742 2016-07-28T23:22:42  <NicolasDorier> if a CachedHashes are not read only, then I need to protect read and write with a lock
743 2016-07-28T23:23:01  <sipa> NicolasDorier: but you solve that by having two CachedHashes
744 2016-07-28T23:23:50  <sipa> one that's being used inside the computation and modified, and then only copying from the locked map beforehand, and merging back afterwards
745 2016-07-28T23:24:13  <sipa> your code already does this correctly
746 2016-07-28T23:24:15  <NicolasDorier> oh I see as part of the TrySet ?
747 2016-07-28T23:24:21  <sipa> yes
748 2016-07-28T23:24:26  <sipa> TrySet would merge
749 2016-07-28T23:24:53  <NicolasDorier> ah ok yes indeed this is simple
750 2016-07-28T23:25:03  <NicolasDorier> will do that thanks
751 2016-07-28T23:25:30  <NicolasDorier> I'm a bit too used to everything is a pointer from C# world I forgot I was just using a copy
752 2016-07-28T23:25:52  <NicolasDorier> for the computation
753 2016-07-28T23:25:56  <sipa> it also has the advantage of making signature agregation easier later :)
754 2016-07-28T23:27:23  <NicolasDorier> got it
755 2016-07-28T23:27:38  <sipa> also, i'd not touch sigcache.h
756 2016-07-28T23:27:44  <sipa> this is not signature caching
757 2016-07-28T23:29:29  <NicolasDorier> ok will create a new file for it
758 2016-07-28T23:29:36  <sipa> thanks
759 2016-07-28T23:47:38  <jtimon> SIGHASH_ALL is the main.cpp of sighashes
760 2016-07-28T23:49:27  <jtimon> at some point SIGHASH_ALL should be deprecated, and at some point main.cpp should be non-existent (not probably most users won't agree with this [yet])
761 2016-07-28T23:51:37  <jtimon> btw, when I talk about "users", the non-existing CPolicy interface is the way I would like to talk with them, with CRandomPolicy on my side to defent some concerns future users may have
762 2016-07-28T23:54:11  <jtimon> but to be completely honest, when I think about "users" I'm just thinking about me-and-or-potential-future-me's, at least r/btc got that right