12016-07-28T00:02:52 *** evoskuil has joined #bitcoin-core-dev
22016-07-28T00:53:05 *** belcher has quit IRC
32016-07-28T00:55:09 *** netzin has joined #bitcoin-core-dev
42016-07-28T01:00:33 *** netzin has quit IRC
52016-07-28T01:05:49 *** Ylbam has quit IRC
62016-07-28T01:24:12 *** netzin has joined #bitcoin-core-dev
72016-07-28T01:36:00 *** shesek has quit IRC
82016-07-28T01:39:37 *** xiangfu has quit IRC
92016-07-28T01:40:59 *** xiangfu has joined #bitcoin-core-dev
102016-07-28T01:55:12 *** TomMc has quit IRC
112016-07-28T01:55:18 *** PRab has quit IRC
122016-07-28T02:01:06 *** shesek has joined #bitcoin-core-dev
132016-07-28T02:24:11 *** Alopex has quit IRC
142016-07-28T02:25:16 *** Alopex has joined #bitcoin-core-dev
152016-07-28T02:35:11 *** Alopex has quit IRC
162016-07-28T02:36:16 *** Alopex has joined #bitcoin-core-dev
172016-07-28T02:38:38 *** nsh has quit IRC
182016-07-28T02:41:44 *** nsh has joined #bitcoin-core-dev
192016-07-28T02:51:13 *** justanotheruser has quit IRC
202016-07-28T02:51:53 *** Chris_Stewart_5 has quit IRC
212016-07-28T02:56:30 *** justanotheruser has joined #bitcoin-core-dev
222016-07-28T03:07:56 *** Chris_Stewart_5 has joined #bitcoin-core-dev
232016-07-28T03:17:30 *** TomMc has joined #bitcoin-core-dev
242016-07-28T03:24:26 *** Chris_Stewart_5 has quit IRC
252016-07-28T03:47:33 *** TomMc has quit IRC
262016-07-28T04:05:04 *** aalex__ has quit IRC
272016-07-28T04:21:01 *** aalex__ has joined #bitcoin-core-dev
282016-07-28T04:24:07 *** anu1 has joined #bitcoin-core-dev
292016-07-28T04:27:54 *** anu0 has quit IRC
302016-07-28T04:42:02 *** netzin has quit IRC
312016-07-28T04:42:23 <GitHub179> [bitcoin] shinradev opened pull request #8415: Update tor.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8415
322016-07-28T04:50:32 *** d_t has joined #bitcoin-core-dev
332016-07-28T04:53:26 *** fengling has quit IRC
342016-07-28T04:55:14 *** d_t has quit IRC
352016-07-28T05:32:07 *** Alopex has quit IRC
362016-07-28T05:33:12 *** Alopex has joined #bitcoin-core-dev
372016-07-28T05:35:43 *** fengling has joined #bitcoin-core-dev
382016-07-28T06:12:24 *** spudowiar has quit IRC
392016-07-28T06:14:44 *** spudowiar has joined #bitcoin-core-dev
402016-07-28T06:27:21 *** spudowiar has quit IRC
412016-07-28T06:36:08 *** btcfan has joined #bitcoin-core-dev
422016-07-28T06:36:14 *** d_t has joined #bitcoin-core-dev
432016-07-28T06:45:47 *** BashCo has quit IRC
442016-07-28T06:47:47 *** jannes has joined #bitcoin-core-dev
452016-07-28T06:49:52 <jonasschnelli> wumpus: I guess this is now safe: https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R446
462016-07-28T07:03:38 *** d_t has quit IRC
472016-07-28T07:07:09 *** jtimon has quit IRC
482016-07-28T07:08:26 *** BashCo has joined #bitcoin-core-dev
492016-07-28T07:14:26 *** fengling has quit IRC
502016-07-28T07:16:15 *** fengling has joined #bitcoin-core-dev
512016-07-28T07:24:07 *** AaronvanW has quit IRC
522016-07-28T07:31:36 <wumpus> jonasschnelli: I don't think that will work; you just moved settings.value(strSettingsVersionKey) to the end
532016-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
542016-07-28T07:32:20 <wumpus> also saves calls to settings.value()
552016-07-28T07:34:45 *** AaronvanW has joined #bitcoin-core-dev
562016-07-28T07:34:45 *** AaronvanW has joined #bitcoin-core-dev
572016-07-28T07:35:12 <GitHub154> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4d4970fe530a...c24b50ec168e
582016-07-28T07:35:12 <GitHub154> bitcoin/master d3af342 Kaz Wesley: prepend license statement to indirectmap...
592016-07-28T07:35:13 <GitHub154> bitcoin/master c24b50e Wladimir J. van der Laan: Merge #8414: prepend license statement to indirectmap.h...
602016-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
612016-07-28T07:35:57 <wumpus> by regarding the absence of strSettingsVersionKey as settings version 0, it will do exactly what you want
622016-07-28T07:51:27 <GitHub90> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c24b50ec168e...64d660a43fb8
632016-07-28T07:51:27 <GitHub90> bitcoin/master 38c4c8b Jorge Timón: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock
642016-07-28T07:51:28 <GitHub90> bitcoin/master 64d660a Wladimir J. van der Laan: Merge #8348: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock...
652016-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
662016-07-28T08:08:19 *** Guyver2 has joined #bitcoin-core-dev
672016-07-28T08:11:42 <GitHub159> [bitcoin] shinradev closed pull request #8415: Update tor.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8415
682016-07-28T08:11:55 <jonasschnelli> wumpus: Ah. Sorry. Didn't got your suggestion. But right, makes more sense.
692016-07-28T08:11:59 <jonasschnelli> Let me change it
702016-07-28T08:12:12 <wumpus> thanks :)
712016-07-28T08:13:25 <jonasschnelli> Yes. Much cleaner...
722016-07-28T08:17:06 *** fengling has quit IRC
732016-07-28T08:19:07 <jonasschnelli> wumpus: updated and tested. https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R446
742016-07-28T08:37:01 *** cdecker has joined #bitcoin-core-dev
752016-07-28T08:39:18 *** xiangfu has quit IRC
762016-07-28T08:39:21 <wumpus> jonasschnelli: you removed the check for nDatabaseCache==100 itself :)
772016-07-28T08:39:36 <jonasschnelli> looking...
782016-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
792016-07-28T08:40:39 *** xiangfu has joined #bitcoin-core-dev
802016-07-28T08:41:03 <jonasschnelli> damit. I should focus on one thing at the time. Thanks wumpus. What would we (I!) do without you...
812016-07-28T08:41:03 <wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value(strSettingsVersionKey).toInt() == 100)
822016-07-28T08:41:39 *** cdecker has quit IRC
832016-07-28T08:42:26 <wumpus> eh that's wrong
842016-07-28T08:42:27 *** cdecker has joined #bitcoin-core-dev
852016-07-28T08:42:39 <wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value("nDatabaseCache").toInt() == 100)
862016-07-28T08:42:48 <jonasschnelli> wumpus: that should be better: https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R447 right?
872016-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
882016-07-28T08:43:16 <jonasschnelli> yes. Needs to focus to get this right...
892016-07-28T08:43:41 *** fengling has joined #bitcoin-core-dev
902016-07-28T08:45:12 <wumpus> which is difficult with the heat
912016-07-28T08:46:25 <wumpus> my plan is to at least test 8371 today
922016-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 :)
932016-07-28T08:47:52 <jonasschnelli> hah. To dump...
942016-07-28T08:48:38 <jonasschnelli> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value("nDatabaseCache"))?
952016-07-28T08:48:51 *** kadoban has quit IRC
962016-07-28T08:48:54 <jonasschnelli> .toInt() == 100 at the end
972016-07-28T08:48:59 <wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value("nDatabaseCache").toInt()==100)
982016-07-28T08:49:01 <wumpus> yes I think so
992016-07-28T08:51:59 <wumpus> or toLongLong() as we seem to provide it as qint64
1002016-07-28T08:56:51 <jonasschnelli> Yes. Probably better,... though I don't expect machines with that much RAM. :)
1012016-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 :)
1022016-07-28T08:57:57 <jonasschnelli> Changed it to toLongLong() https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R447
1032016-07-28T09:09:49 <wumpus> awesome
1042016-07-28T09:14:59 <wumpus> looks good to me now
1052016-07-28T09:15:51 <wumpus> going to test
1062016-07-28T09:29:00 <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/64d660a43fb8...30a87c0747a1
1072016-07-28T09:29:00 <GitHub189> bitcoin/master 893f379 Jonas Schnelli: [Qt] Add dbcache migration path
1082016-07-28T09:29:01 <GitHub189> bitcoin/master 30a87c0 Wladimir J. van der Laan: Merge #8407: [Qt] Add dbcache migration path...
1092016-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
1102016-07-28T09:30:01 <jonasschnelli> Should probably merge fine into 0.13
1112016-07-28T09:30:15 *** Ylbam has joined #bitcoin-core-dev
1122016-07-28T09:30:20 <wumpus> yep
1132016-07-28T09:30:49 <GitHub153> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/45eba4b1e0658639bb92730723b987f05e171529
1142016-07-28T09:30:50 <GitHub153> bitcoin/0.13 45eba4b Jonas Schnelli: [Qt] Add dbcache migration path...
1152016-07-28T09:41:17 *** spudowiar has joined #bitcoin-core-dev
1162016-07-28T09:42:57 *** cdecker has quit IRC
1172016-07-28T09:43:36 *** cdecker has joined #bitcoin-core-dev
1182016-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
1192016-07-28T09:48:15 <wumpus> okay thanks for updating, will re-test again soon, now looking at 8389
1202016-07-28T09:49:08 <wumpus> you've certainly been solving many 0.13.0rc1 issues quickly, where would we be without you
1212016-07-28T09:53:14 <wumpus> looking for more review for: Prevent fingerprinting, disk-DoS with compact blocks #8408
1222016-07-28T09:54:47 <jonasschnelli> Yes. 8389 is more important
1232016-07-28T09:54:54 <jonasschnelli> Looking at 8408
1242016-07-28T09:59:29 <jonasschnelli> 8408 makes sense. Props to sdaftuar! It needs extrem focus to find these issues...
1252016-07-28T09:59:59 <wumpus> yes these are very sneaky, good to have them discovered and fixed before the release
1262016-07-28T10:04:53 *** laurentmt has joined #bitcoin-core-dev
1272016-07-28T10:04:59 *** YOU-JI has joined #bitcoin-core-dev
1282016-07-28T10:06:46 *** laurentmt has quit IRC
1292016-07-28T10:08:29 *** Ginnarr has joined #bitcoin-core-dev
1302016-07-28T10:12:15 <wumpus> ooh, regtest has the same RPC default port as testnet. I only discover this now
1312016-07-28T10:13:01 <jonasschnelli> wasn't aware of that...
1322016-07-28T10:13:29 <jonasschnelli> Ah. Just the p2p port is differnt...
1332016-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
1342016-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)
1352016-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
1362016-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
1372016-07-28T10:17:49 <wumpus> after that it just continues
1382016-07-28T10:18:01 <wumpus> this is an old-fashioned, pre-HD wallet
1392016-07-28T10:18:15 <jonasschnelli> let me have a look
1402016-07-28T10:19:02 <jonasschnelli> wumpus: hmm.. that error should not be related to 8389 i guess
1412016-07-28T10:19:11 <wumpus> let me see if it happens without
1422016-07-28T10:19:24 <wumpus> maybe it's just a corrupted wallet, that's possible
1432016-07-28T10:20:12 <wumpus> oops happens without #8408 too
1442016-07-28T10:20:22 <wumpus> eh without 8389 I mean
1452016-07-28T10:20:53 <jonasschnelli> hmm... this error means you had an error during ReadKeyValue() but not for a key
1462016-07-28T10:21:17 <wumpus> moving wallet out of the way, creating a new non-HD wallet
1472016-07-28T10:21:22 <jonasschnelli> I think your wallet.dat has a key that your current code cannot understand
1482016-07-28T10:21:34 <jonasschnelli> yes. Maybe do a clean start
1492016-07-28T10:22:33 <wumpus> that works fine, also after restarting bitcoind with that wallet
1502016-07-28T10:22:56 <wumpus> so it was something specific to the previous wallet, maybe it was corrupted in some older testing. Ok, phew
1512016-07-28T10:23:35 <wumpus> I've saved that wallet, might take a look at what key confused it later
1522016-07-28T10:27:33 <wumpus> huh: dumpwallet result: cTjHTNHECpYNvFsJ2QXGVaDqbX8gX625S45Errqjy44oRHxPEzMc 2011-02-02T21:16:42Z hdmaster=1 # addr=mzUm95ZQPCVhGyPcJ3CvYwARBBQKX7efdR
1532016-07-28T10:28:17 <wumpus> the date is wrong, and the key stayed the same before and after encryption
1542016-07-28T10:29:00 <jonasschnelli> hmm... that's wrong. Let me retest. Maybe we have a rebase issue here...
1552016-07-28T10:29:07 <jonasschnelli> Did you test with master? or 0.13?
1562016-07-28T10:29:17 <wumpus> 0.13 (as that's what the pull is against)
1572016-07-28T10:29:24 <jonasschnelli> Okay. Will do also.
1582016-07-28T10:30:27 <jonasschnelli> We should implement the dumpwallet test as you mentioned in that issue yesterday.
1592016-07-28T10:35:52 <wumpus> jonasschnelli: see https://github.com/bitcoin/bitcoin/pull/8389 for details on what I did
1602016-07-28T10:36:08 * jonasschnelli is looking...
1612016-07-28T10:36:55 <jonasschnelli> there is on inactivehdmaster....
1622016-07-28T10:36:58 <jonasschnelli> s/on/no
1632016-07-28T10:37:03 <jonasschnelli> hmm...
1642016-07-28T10:37:11 <wumpus> indeed, there is no inactivehdmaster, and the hdmaster didn't change
1652016-07-28T10:37:14 * jonasschnelli is still building 8389 on top of 0.13
1662016-07-28T10:44:34 <jonasschnelli> wumpus: I'm running the same steps but get a clean/correct 2nd dump
1672016-07-28T10:44:59 <jonasschnelli> Do you have the "Warning: Error reading wallet.dat! " in your log at the 2nd start of bitcoind?
1682016-07-28T10:45:21 <jonasschnelli> We definitively need a RPC test for this...
1692016-07-28T10:45:26 <jonasschnelli> going to write one now
1702016-07-28T10:45:50 <wumpus> oh shit - I've been testing without #8389 merged
1712016-07-28T10:46:17 <wumpus> I unmerged it because of testing the error message, then forgot to apply it again
1722016-07-28T10:46:36 <wumpus> is this the expected output for pre-8389?
1732016-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
1742016-07-28T10:47:44 <wumpus> going to retry with actually the right code, sorry
1752016-07-28T10:48:56 <jonasschnelli> okay.. no problem. Better an mistake during testing then a mistake in the code.
1762016-07-28T10:49:08 <jonasschnelli> But anyways,.. going to write a dumpwallet test
1772016-07-28T10:49:21 <wumpus> yes, we need one anyway
1782016-07-28T10:53:41 *** Giszmo has joined #bitcoin-core-dev
1792016-07-28T10:55:21 <wumpus> trying to update my post to a tested ACK but I get pink unicorns
1802016-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?
1812016-07-28T10:56:21 <wumpus> I'm fairly sure it's always been the case, but it doesn't seem necessary
1822016-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..
1832016-07-28T11:00:31 <GitHub72> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/30a87c0747a1...806b9e7570a2
1842016-07-28T11:00:31 <GitHub72> bitcoin/master e37b16a Daniel Cousens: transaction: clarify witness branches
1852016-07-28T11:00:32 <GitHub72> bitcoin/master 806b9e7 Wladimir J. van der Laan: Merge #8332: semi trivial: clarify witness branches in transaction.h serialization...
1862016-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
1872016-07-28T11:00:51 <wumpus> curious
1882016-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)
1892016-07-28T11:04:27 <jonasschnelli> I could imaging some function might run into problems if there are 0 receiving addresses...
1902016-07-28T11:04:37 <jonasschnelli> Need to remove the default key and run all the RPC tests
1912016-07-28T11:04:43 <wumpus> yes it's definitely something that requires extensive testing
1922016-07-28T11:04:50 <wumpus> which is probably why no one ever dared remove that code :)
1932016-07-28T11:06:05 <jonasschnelli> heh. Indeed
1942016-07-28T11:07:28 *** spudowiar has quit IRC
1952016-07-28T11:10:50 <GitHub88> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/45eba4b1e065...c3c82c48d9d7
1962016-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
1972016-07-28T11:10:51 <GitHub88> bitcoin/0.13 f142c11 Jonas Schnelli: [0.13] Create a new HD seed after encrypting the wallet
1982016-07-28T11:10:51 <GitHub88> bitcoin/0.13 de45c06 Jonas Schnelli: [Wallet] Add CKeyMetadata record for HDMasterKey(s), factor out HD key generation
1992016-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...
2002016-07-28T11:11:17 <jonasschnelli> reminder: 8389 needs an "up-port" (my mistake)
2012016-07-28T11:13:05 <wumpus> seems to apply cleanly to master, apart from the release-notes change which we can ignore there
2022016-07-28T11:15:49 *** cryptapus has joined #bitcoin-core-dev
2032016-07-28T11:15:49 *** cryptapus has joined #bitcoin-core-dev
2042016-07-28T11:23:32 <GitHub54> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/2266b43e3317a889b9150e614169acda50383bf5
2052016-07-28T11:23:32 <GitHub54> bitcoin/master 2266b43 Jonas Schnelli: Port from 0.13: Create a new HD seed after encrypting the wallet...
2062016-07-28T11:25:07 *** btcfan has quit IRC
2072016-07-28T11:28:05 <wumpus> ok that leaves https://github.com/bitcoin/bitcoin/pull/8408 and we can roll rc2!
2082016-07-28T11:33:49 *** spudowiar has joined #bitcoin-core-dev
2092016-07-28T11:41:35 *** Ginnarr has quit IRC
2102016-07-28T11:54:21 <instagibbs> \o/
2112016-07-28T11:54:28 <GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2266b43e3317...133c727cc4f7
2122016-07-28T11:54:28 <GitHub124> bitcoin/master fbc6070 Thomas Snider: [trivial] Switched constants to sizeof()
2132016-07-28T11:54:29 <GitHub124> bitcoin/master 133c727 Wladimir J. van der Laan: Merge #8321: [trivial] Switched constants to sizeof()...
2142016-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
2152016-07-28T12:09:12 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2162016-07-28T12:22:07 *** laurentmt has joined #bitcoin-core-dev
2172016-07-28T12:22:50 *** Chris_Stewart_5 has quit IRC
2182016-07-28T12:24:56 *** anu0 has joined #bitcoin-core-dev
2192016-07-28T12:28:25 *** anu1 has quit IRC
2202016-07-28T12:42:07 *** cryptapus_ has joined #bitcoin-core-dev
2212016-07-28T12:42:10 *** cryptapus_afk has quit IRC
2222016-07-28T12:51:27 *** DongSwanson has quit IRC
2232016-07-28T13:02:24 *** laurentmt has quit IRC
2242016-07-28T13:02:50 *** YOU-JI has quit IRC
2252016-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
2262016-07-28T13:47:09 *** cryptapus_ has quit IRC
2272016-07-28T13:47:22 *** cryptapus_ has joined #bitcoin-core-dev
2282016-07-28T13:47:23 *** cryptapus_ has joined #bitcoin-core-dev
2292016-07-28T13:47:23 *** cryptapus_ is now known as cryptapus_afk
2302016-07-28T14:05:42 *** spudowiar has quit IRC
2312016-07-28T14:20:35 *** molz has quit IRC
2322016-07-28T14:23:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2332016-07-28T14:39:43 *** moli has joined #bitcoin-core-dev
2342016-07-28T15:03:05 *** spudowiar has joined #bitcoin-core-dev
2352016-07-28T15:14:41 *** Chris_Stewart_5 has quit IRC
2362016-07-28T15:25:08 *** lightningbot has joined #bitcoin-core-dev
2372016-07-28T15:29:07 *** laurentmt has joined #bitcoin-core-dev
2382016-07-28T15:29:37 *** aj has quit IRC
2392016-07-28T15:29:47 *** aj has joined #bitcoin-core-dev
2402016-07-28T15:31:23 *** aalex__ has quit IRC
2412016-07-28T15:32:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2422016-07-28T15:42:39 *** lightningbot has joined #bitcoin-core-dev
2432016-07-28T15:42:55 *** wangchun has joined #bitcoin-core-dev
2442016-07-28T15:52:39 *** BashCo_ has joined #bitcoin-core-dev
2452016-07-28T15:55:51 *** BashCo has quit IRC
2462016-07-28T16:07:04 *** Cory has quit IRC
2472016-07-28T16:09:18 *** Pasha has joined #bitcoin-core-dev
2482016-07-28T16:15:08 *** Chris_Stewart_5 has quit IRC
2492016-07-28T16:16:12 *** Pasha is now known as Cory
2502016-07-28T16:16:36 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2512016-07-28T16:21:36 *** BashCo_ has quit IRC
2522016-07-28T16:25:36 *** BashCo has joined #bitcoin-core-dev
2532016-07-28T16:38:39 *** achow101 has quit IRC
2542016-07-28T16:39:20 *** achow101 has joined #bitcoin-core-dev
2552016-07-28T16:44:24 <jonasschnelli> cfields: https://github.com/bitcoin/bitcoin/pull/8135
2562016-07-28T16:44:39 <jonasschnelli> Is this still required? Lost track of the osx based deployment process...
2572016-07-28T16:44:44 <jonasschnelli> If not, I can close the PR
2582016-07-28T16:45:04 *** jtimon has joined #bitcoin-core-dev
2592016-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 :\
2602016-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.
2612016-07-28T16:46:08 <jonasschnelli> Depends/gitian based deployment should be sufficient IMO
2622016-07-28T16:46:33 <cfields> jonasschnelli: iirc macports/brew use it though
2632016-07-28T16:46:43 <jonasschnelli> Ah. Okay. that could be...
2642016-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
2652016-07-28T16:47:39 <cfields> jonasschnelli: what do you think of just pulling the ~3 python libs directly into support/macdeploy?
2662016-07-28T16:47:48 <cfields> i believe we patch them all already
2672016-07-28T16:48:03 <cfields> (until upstream merges the fixes, that is)
2682016-07-28T16:48:20 <jonasschnelli> Or pull in a script that downloads and patches them?
2692016-07-28T16:48:31 <jonasschnelli> I don't want to blow up our code base...
2702016-07-28T16:49:55 *** arubi has quit IRC
2712016-07-28T16:50:22 <cfields> ok. thinking on it. i'll ack/pr something either way so we can move on
2722016-07-28T16:51:14 *** spudowiar has quit IRC
2732016-07-28T16:52:28 *** arubi has joined #bitcoin-core-dev
2742016-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?
2752016-07-28T16:56:20 <cfields> yes, they just use 'make appbundle'. so that works for me if it's ok by you
2762016-07-28T17:01:01 <jonasschnelli> cfields: yes. I think this would make sense.
2772016-07-28T17:01:05 *** BashCo_ has joined #bitcoin-core-dev
2782016-07-28T17:01:12 <jonasschnelli> You don't need a dmg if you selfcompile
2792016-07-28T17:01:37 <jonasschnelli> Only if you want to distribute... Which we should not encourage over non gitian
2802016-07-28T17:03:52 *** BashCo has quit IRC
2812016-07-28T17:10:55 <cfields> right
2822016-07-28T17:16:45 *** d_t has joined #bitcoin-core-dev
2832016-07-28T17:26:55 *** supasonic has joined #bitcoin-core-dev
2842016-07-28T17:37:56 <jtimon> is there any tutorial for monkies like me to do the gitian builds for a given release?
2852016-07-28T17:39:45 *** Guyver2_ has joined #bitcoin-core-dev
2862016-07-28T17:40:28 <sipa> jtimon: https://github.com/bitcoin/bitcoin/blob/0.13/doc/gitian-building.md
2872016-07-28T17:42:21 *** Guyver2 has quit IRC
2882016-07-28T17:43:52 *** Guyver2_ is now known as Guyver2
2892016-07-28T17:45:16 *** BitcoinErrorLog has joined #bitcoin-core-dev
2902016-07-28T17:47:14 *** kadoban has joined #bitcoin-core-dev
2912016-07-28T17:47:52 <jtimon> sipa: awesome, thanks
2922016-07-28T17:48:44 <jtimon> looks very complete
2932016-07-28T17:52:49 *** Chris_Stewart_5 has quit IRC
2942016-07-28T18:00:33 *** adiabat has quit IRC
2952016-07-28T18:09:09 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2962016-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
2972016-07-28T18:19:52 <instagibbs> jtimon, I was able to walk through it fine.
2982016-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
2992016-07-28T18:26:38 <sipa> it takes a while :)
3002016-07-28T18:26:53 <sipa> i went through it again for 0.13.0rc1
3012016-07-28T18:29:16 *** netzin has joined #bitcoin-core-dev
3022016-07-28T18:30:49 *** netzin has quit IRC
3032016-07-28T18:34:10 *** netzin has joined #bitcoin-core-dev
3042016-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
3052016-07-28T18:34:35 *** netzin is now known as nets1n
3062016-07-28T18:35:45 <sdaftuar> sipa: i am having a hard time parsing your comment in #8408
3072016-07-28T18:39:24 *** supasonic has quit IRC
3082016-07-28T18:39:31 <sipa> sdaftuar: in general, peers should not send getblocktxn for anything near the tip
3092016-07-28T18:39:40 <sipa> *anything not near the tip
3102016-07-28T18:39:51 <sdaftuar> right, agreed
3112016-07-28T18:40:00 <sdaftuar> are you suggesting that we disconnect for old blocks as wel?
3122016-07-28T18:40:09 <sdaftuar> rather than not disconnect for unknown blocks?
3132016-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)
3142016-07-28T18:40:58 <sipa> the question is whether there are no cases under which this can happen accidentally
3152016-07-28T18:41:11 <sdaftuar> i assumed naively that this could happen on testnet
3162016-07-28T18:41:32 <sdaftuar> ie without much rigorous thought
3172016-07-28T18:41:54 <sdaftuar> mostly i guess i was comparing the handling of getblocktxn to how we handle getdata requests
3182016-07-28T18:42:33 <sdaftuar> where we silently ignore unknown, and non-main-chain old blocks
3192016-07-28T18:43:03 <sipa> ok, in that case let's follow the same approach
3202016-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
3212016-07-28T18:44:00 <sipa> but perhaps we should rethink this in a bigger rework-block-sync-logic in the future...
3222016-07-28T18:44:03 <sdaftuar> fyi i did add a test in #8418 that catches the behaviors corrected in #8408
3232016-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
3242016-07-28T18:44:39 <sipa> agree
3252016-07-28T18:45:05 <sipa> wait; 8418 has no changed behaviour, apart from what is already in 8408?
3262016-07-28T18:45:09 <sipa> i assume
3272016-07-28T18:45:15 <sdaftuar> it has one changed behavior, the new command line option -bip9params
3282016-07-28T18:45:25 <sdaftuar> i needed a way to turn off segwit on regtest
3292016-07-28T18:45:32 <sipa> sure sure
3302016-07-28T18:45:42 <sipa> i mean it should no impact on anything in mainnet
3312016-07-28T18:46:02 <sdaftuar> yes, agreed. it's a lot of testing code, plus something that should be regtest-only
3322016-07-28T18:46:13 <sdaftuar> assuming i didn't screw up :)
3332016-07-28T18:48:28 * luke-jr won't be able to make the meeting today
3342016-07-28T18:50:44 *** jcorgan has joined #bitcoin-core-dev
3352016-07-28T19:00:05 * jonasschnelli rings the bell
3362016-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
3372016-07-28T19:00:14 <jtimon> ready
3382016-07-28T19:00:21 <cfields> thanks, here
3392016-07-28T19:00:28 <sipa> present
3402016-07-28T19:00:45 <instagibbs> pre-zent
3412016-07-28T19:01:03 <wumpus> #startmeeting
3422016-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.
3432016-07-28T19:01:03 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3442016-07-28T19:01:05 <kanzure> greetings
3452016-07-28T19:01:42 <wumpus> topc suggestions?
3462016-07-28T19:01:49 <jtimon> proposed topic eliminate ISM (NicolasDorier's #8391)
3472016-07-28T19:02:10 <luke-jr> about to board flight..
3482016-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
3492016-07-28T19:02:40 <wumpus> but that's the only remaining pull tagged 0.13 left
3502016-07-28T19:02:48 <luke-jr> wumpus: releadse notes still need to not recommend/opressure bad policy
3512016-07-28T19:03:08 <wumpus> luke-jr: ok
3522016-07-28T19:03:19 <luke-jr> tag applicable pr pls
3532016-07-28T19:03:20 <jtimon> wumpus: shouldn't #8412 be in 0.13?
3542016-07-28T19:03:25 <wumpus> but I guess people don't agree on what 'bad policy' is
3552016-07-28T19:03:38 <kanzure> also about to board a flight in a bit
3562016-07-28T19:03:41 <luke-jr> wumpus: â¦
3572016-07-28T19:03:50 <gmaxwell> luke-jr: don't elipises wumpus.
3582016-07-28T19:03:51 <jonasschnelli> I think it should
3592016-07-28T19:03:57 <jonasschnelli> (8412)
3602016-07-28T19:04:19 <jonasschnelli> I'll tag it
3612016-07-28T19:04:20 <jtimon> in fact, I think it should go in 0.12.2 if there's going to be one
3622016-07-28T19:04:27 <wumpus> I'm fine with 8412, hadn't heard of it before
3632016-07-28T19:04:40 <jtimon> wumpus: yeah, just created it yesterday
3642016-07-28T19:04:47 <sipa> 8412 seems harmless and silly not to include
3652016-07-28T19:04:53 <jonasschnelli> It's a inconsequence with no risk attached to it (IMO)
3662016-07-28T19:05:00 <wumpus> seems we agree
3672016-07-28T19:05:08 <jtimon> great
3682016-07-28T19:05:18 <luke-jr> the current release nites recommends and undisputably bad policy. if there is controversy it shouldnt recommend anything
3692016-07-28T19:05:32 <wumpus> luke-jr: do you have a proposed update to the release notes?
3702016-07-28T19:05:37 <gmaxwell> RE 8412: why are we adding flags for long locked in network features?
3712016-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?
3722016-07-28T19:06:22 <luke-jr> wumpus: yes, the pr is open for a week now
3732016-07-28T19:06:33 <cfields> err.. sorry for topic drift. we can pick that up later.
3742016-07-28T19:06:36 <jtimon> what is the "bad policy"? what am I missing?
3752016-07-28T19:06:43 <gmaxwell> okay never mind, I didn't look at the patch initially, I thought it was GBT rather than libconsensus.
3762016-07-28T19:06:52 <wumpus> luke-jr: the only PR I know of also changes quite some code
3772016-07-28T19:06:55 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8388/
3782016-07-28T19:07:05 <jonasschnelli> Yes. Its not an release not only PR
3792016-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
3802016-07-28T19:07:17 <gmaxwell> s/not/note/
3812016-07-28T19:07:26 <luke-jr> jtimon: blockmaxweight rsther than blockmaxsize
3822016-07-28T19:07:27 <morcos> uh, or weight
3832016-07-28T19:07:44 <jonasschnelli> gmaxwell: thanks. :)
3842016-07-28T19:07:58 <luke-jr> wumpus: because people were insisting the code had to change to remove the recommencaation
3852016-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.
3862016-07-28T19:08:32 <sipa> luke-jr: we shouldn't be relying on miners picking safe policy that only harms themselves
3872016-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
3882016-07-28T19:08:48 <sipa> luke-jr: if we're not fine with larger blocks, we shouldn't do segwit as-is
3892016-07-28T19:09:02 <morcos> sipa: agreed
3902016-07-28T19:09:15 <morcos> where we is the big we
3912016-07-28T19:09:16 <sipa> in practice, nearly every miner will set the max block size and weight to the maximum allowed value
3922016-07-28T19:09:22 <sipa> morcos: yes!
3932016-07-28T19:09:40 <luke-jr> sipa: we cannot stop segwit for better or worse
3942016-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
3952016-07-28T19:09:48 <luke-jr> and hopefully in some monthhs larger blocks WILL vbe fine
3962016-07-28T19:10:00 <luke-jr> sipa: prqactice is tbd
3972016-07-28T19:10:01 <sipa> luke-jr: 'fine' is not a boolean
3982016-07-28T19:10:27 <luke-jr> i need to boardâ¦
3992016-07-28T19:10:32 *** spudowiar has joined #bitcoin-core-dev
4002016-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
4012016-07-28T19:10:44 <gmaxwell> luke-jr: well nothing special will happen because you aren't here. :P go board, we can talk later.
4022016-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
4032016-07-28T19:10:54 <luke-jr> bbl
4042016-07-28T19:11:30 *** I_DID_LSD_ON_A_P has joined #bitcoin-core-dev
4052016-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)
4062016-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)_
4072016-07-28T19:12:06 <jtimon> so the issue is that weight has a bigger default than size had?
4082016-07-28T19:12:10 <wumpus> jtimon: yes, I thought that was the point
4092016-07-28T19:12:30 <wumpus> jtimon: otherwise it's back to 'devs decide the values'
4102016-07-28T19:12:46 <btcdrak> sorry I am late. #8412 should be included.
4112016-07-28T19:12:52 <jtimon> yeah, and people asking to increase op_return size and shit
4122016-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.
4132016-07-28T19:13:52 <jtimon> re #8412 should I open the PR to 0.13 then?
4142016-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.
4152016-07-28T19:14:20 <sipa> jtimon: 8412 will backport trivially, no need for backport PR
4162016-07-28T19:14:35 <gmaxwell> (also, FWIW, the income difference between 750k size and maximum is non-trivial).
4172016-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
4182016-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
4192016-07-28T19:15:40 <wumpus> but indeed, no strong opinion either
4202016-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
4212016-07-28T19:16:31 <sipa> the current 0.13 code does not change any defaults
4222016-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
4232016-07-28T19:16:46 <jtimon> sipa: then what's the problem again?
4242016-07-28T19:16:49 <sipa> and the release notes explain the difference, and that only using weight is faster
4252016-07-28T19:16:54 <wumpus> yes, what is the problem then?
4262016-07-28T19:16:58 <sipa> i think the code and notes in 0.13 are fine
4272016-07-28T19:17:15 *** supasonic has joined #bitcoin-core-dev
4282016-07-28T19:17:46 <gmaxwell> The notes don't seem to inform me how to set it to the maximum.
4292016-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.
4302016-07-28T19:18:21 <sipa> ok, let's fix that in the --help message?
4312016-07-28T19:18:47 <gmaxwell> They won't read that. They'll read the release notes with greater odds than --help.
4322016-07-28T19:18:55 <wumpus> if it's what they currently do ,then why would the default even matter? they override it already.
4332016-07-28T19:18:57 <gmaxwell> (otherwise they wouldn't know of the maxweight option at all)
4342016-07-28T19:18:58 <sipa> i assume they'll read neither
4352016-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.)
4362016-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
4372016-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.
4382016-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
4392016-07-28T19:20:16 *** yep has joined #bitcoin-core-dev
4402016-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
4412016-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
4422016-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.
4432016-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?
4442016-07-28T19:21:30 <gmaxwell> In particular luke will go on a public attack campaign, and some are trying to avoid it.
4452016-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
4462016-07-28T19:21:47 <gmaxwell> (because he sees a kind of principled position arising from setting a more correct default which no one uses)
4472016-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.
4482016-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
4492016-07-28T19:22:52 <gmaxwell> yes, I can make a PR that explains how to do that.
4502016-07-28T19:22:53 <wumpus> gmaxwell: we've been there; this really feels like deja vu
4512016-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?
4522016-07-28T19:23:56 <gmaxwell> No, the defaults are functionally equal to 0.12's.
4532016-07-28T19:23:59 <sdaftuar> wumpus: no, that is not the case.
4542016-07-28T19:24:07 <wumpus> ok, good then
4552016-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
4562016-07-28T19:24:32 <gmaxwell> the default maxweight is 3 million, which, with no witness txn is exactly equal to 750k maxsize.
4572016-07-28T19:24:43 <jtimon> I really don't understand luke-jr's issue if the defaults are untouched
4582016-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
4592016-07-28T19:25:25 <wumpus> explaining in the release notes and documentation is exactly the right thing to do
4602016-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.
4612016-07-28T19:25:31 <instagibbs> jtimon, theoretical size max would be 3MB I think
4622016-07-28T19:25:35 <wumpus> so people understand what is being done
4632016-07-28T19:25:50 <wumpus> instead of saying 'this is too complicated for you, just follow the defaults'
4642016-07-28T19:26:10 <gmaxwell> wumpus: 'just follow the defaults' was never my position.
4652016-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)
4662016-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."
4672016-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
4682016-07-28T19:26:52 <morcos> gmaxwell: exactly
4692016-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
4702016-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)
4712016-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.
4722016-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?
4732016-07-28T19:28:16 <gmaxwell> And he think it is bad until compactblock deployment has proven that miners producing larger blocks is okay.
4742016-07-28T19:28:16 <jtimon> morcos: I see
4752016-07-28T19:28:18 <wumpus> hence, I really think defaults discussion is a waste of time, it just creates more of the same
4762016-07-28T19:29:08 <gmaxwell> instead we get worse discussions because we have setting which actively trip up users.
4772016-07-28T19:29:08 <sipa> i think we can just leave defaults as they are now
4782016-07-28T19:29:21 <gmaxwell> Sorry, wumpus, the software doesn't exist to save us from discussion, it exists to serve its users.
4792016-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
4802016-07-28T19:29:28 <gmaxwell> I agree that we can leave them.
4812016-07-28T19:29:31 <instagibbs> ack for leaving as-is
4822016-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
4832016-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)
4842016-07-28T19:30:08 <wumpus> gmaxwell: where did I claim that the software exists to save us from discussion!??
4852016-07-28T19:30:14 <wumpus> gmaxwell: wtf is this
4862016-07-28T19:30:16 <jtimon> if they move to weigh because it's cheaper but still use the default, the size is the same
4872016-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
4882016-07-28T19:30:31 <sipa> agree
4892016-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.
4902016-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
4912016-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.
4922016-07-28T19:32:04 <gmaxwell> I apologize for reading so much into it.
4932016-07-28T19:32:06 <Eliel_> as in, no dfaults
4942016-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
4952016-07-28T19:32:25 <achow101> Eliel_: it's not very user friendly though
4962016-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)
4972016-07-28T19:32:40 <sdaftuar> ACK simplifying in the future
4982016-07-28T19:32:45 <morcos> sipa: i think thats the best we're going to get at this point
4992016-07-28T19:32:47 <sipa> that can 1) solve the problem of inadvisable defaults
5002016-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. :)
5012016-07-28T19:33:07 <wumpus> Eliel_: yes, that has been suggested before
5022016-07-28T19:33:19 <sipa> and 2) by changing things at the same time as simplifying the logic, it is not necessarily a recommendation
5032016-07-28T19:33:21 <achow101> gmaxwell: just tell him to suck it up and deal with it
5042016-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.
5052016-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.
5062016-07-28T19:33:46 <gmaxwell> It didn't seem like it was worth debating.
5072016-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
5082016-07-28T19:33:57 <wumpus> Eliel_: it may be better than setting silly defaults, but there was never agreement to do it
5092016-07-28T19:34:09 <gmaxwell> morcos: I can agree with that too.
5102016-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?
5112016-07-28T19:34:26 <Eliel_> wumpus: that's pretty much my reasoning behind the suggestion.
5122016-07-28T19:34:41 <Eliel_> if you can't set defaults the way most people want them, don't set any.
5132016-07-28T19:34:51 <morcos> I'm also fine with that suggestion
5142016-07-28T19:35:04 <gmaxwell> luke argued for that for years.
5152016-07-28T19:35:11 <Eliel_> and about user friendliness... do you really want to allow people to mine without understanding what they're doing?
5162016-07-28T19:35:15 <wumpus> Eliel_: the thing is that people disagree deeply over these setings
5172016-07-28T19:35:26 <jtimon> other topics?
5182016-07-28T19:36:02 <wumpus> #topic eliminate ISM (NicolasDorier's #8391)
5192016-07-28T19:36:11 <gmaxwell> Eliel_: absolutely.
5202016-07-28T19:36:16 *** laurentmt has quit IRC
5212016-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.
5222016-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.
5232016-07-28T19:37:35 *** TomMc has joined #bitcoin-core-dev
5242016-07-28T19:37:37 <wumpus> ping jtimon
5252016-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
5262016-07-28T19:38:18 <jtimon> I would say it's the most important libconsensus' PR opened right now
5272016-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?
5282016-07-28T19:39:03 <jtimon> wumpus: well, I hope not, but that's why I bring it up (apart from asking for review)
5292016-07-28T19:39:21 <wumpus> yes it does need more review/testing
5302016-07-28T19:39:27 <wumpus> #action review https://github.com/bitcoin/bitcoin/pull/8391
5312016-07-28T19:39:40 <jtimon> thanks
5322016-07-28T19:39:42 <cfields> next topic suggestion: boost threads/sync replacement for master
5332016-07-28T19:40:01 <wumpus> #topic boost threads/sync replacement for master
5342016-07-28T19:40:11 <jtimon> and of course nacks and nits always the sooner the better
5352016-07-28T19:40:16 <cfields> https://github.com/bitcoin/bitcoin/pull/8023
5362016-07-28T19:40:27 <cfields> is nowish a good time to start pushing for that?
5372016-07-28T19:40:37 <wumpus> sounds good to me
5382016-07-28T19:41:18 <gmaxwell> neat.
5392016-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?
5402016-07-28T19:41:26 <jtimon> cfields: since it's disruptive, the "refactor window" seems like the perfect time for it, no?
5412016-07-28T19:41:31 <wumpus> what about your network refactor? seems we should start merging for that as well?
5422016-07-28T19:42:11 <wumpus> cfields: what would 'chunks at a time' mean, using two potentially conflicting thread libraries?
5432016-07-28T19:42:11 <cfields> wumpus: yea, review/acks of 2 outstanding PRs would be a big help...
5442016-07-28T19:42:17 <jtimon> oh, #8023 is not disruptive at all
5452016-07-28T19:42:23 <cfields> sec for numbers
5462016-07-28T19:42:29 <wumpus> cfields: can you post the links? ok
5472016-07-28T19:42:58 <NicolasDorier> I'm back.
5482016-07-28T19:43:03 <NicolasDorier> for removing ISM
5492016-07-28T19:43:04 <wumpus> welcome back
5502016-07-28T19:43:10 <NicolasDorier> I synched nodes successfully
5512016-07-28T19:43:20 <NicolasDorier> so basically, it needs some review from other people, but should be good
5522016-07-28T19:43:27 <cfields> #8128 and #8085
5532016-07-28T19:43:51 <btcdrak> NicolasDorier: ok I'll run a full sync this weekend
5542016-07-28T19:43:52 <wumpus> #action review+test https://github.com/bitcoin/bitcoin/pull/8128 Net: Turn net structures into dumb storage classes
5552016-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
5562016-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
5572016-07-28T19:44:24 <wumpus> #action review+test https://github.com/bitcoin/bitcoin/pull/8085 p2p: Begin encapsulation
5582016-07-28T19:44:54 <cfields> ok, I'll approach it as one big change then
5592016-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
5602016-07-28T19:46:24 <NicolasDorier> question: what you call "refactor windows" what is it ?
5612016-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.
5622016-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
5632016-07-28T19:48:16 <wumpus> e.g. you wouldn't want to switch the thread library a few days before release
5642016-07-28T19:48:25 <NicolasDorier> ok nice to know, as I'm working around libconsensus... will go a bit quicker so
5652016-07-28T19:48:49 <NicolasDorier> oh
5662016-07-28T19:49:29 <NicolasDorier> about https://github.com/bitcoin/bitcoin/pull/8259 when will it be merged for 0.13 ?
5672016-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
5682016-07-28T19:49:51 <sipa> NicolasDorier: we'll need to backport that to 0.13 before segwit
5692016-07-28T19:50:03 <NicolasDorier> ok
5702016-07-28T19:51:01 <wumpus> NicolasDorier: it's not even merged for master yet, after it is it can be backported
5712016-07-28T19:51:05 *** droark has joined #bitcoin-core-dev
5722016-07-28T19:51:37 <wumpus> I'll add a "needs backport" label
5732016-07-28T19:51:50 <NicolasDorier> ok no prob
5742016-07-28T19:52:03 <sipa> NicolasDorier: thanks for the reminder on that btw
5752016-07-28T19:52:13 <wumpus> seems to need some more review too
5762016-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
5772016-07-28T19:52:33 *** BashCo_ has quit IRC
5782016-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
5792016-07-28T19:52:53 <wumpus> #action review https://github.com/bitcoin/bitcoin/pull/8259 Hash Cache
5802016-07-28T19:53:09 *** BashCo has joined #bitcoin-core-dev
5812016-07-28T19:53:14 <jtimon> uff, #8259 is ultra disruptive to consensus branch, should review...
5822016-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
5832016-07-28T19:54:21 <jtimon> yep, you agreed on #8346 first, right?
5842016-07-28T19:54:46 <sipa> jtimon: 8259 will need backport to 0.13
5852016-07-28T19:55:03 <NicolasDorier> yes
5862016-07-28T19:56:07 <wumpus> ok, any final topics?
5872016-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...
5882016-07-28T19:57:18 <wumpus> no, refactors will not be backported, that is too risky
5892016-07-28T19:58:02 <jtimon> wumpus: then having the "refactor window" precisely when we're backporting more stuff is a bad idea
5902016-07-28T19:58:03 <sipa> it's fine, we'll find a solution for that
5912016-07-28T19:58:05 <wumpus> well wait until after the release then jtimon
5922016-07-28T19:58:19 <wumpus> hopefully rc2 will be the last
5932016-07-28T19:58:34 <wumpus> that'd mean the release can be next week or so
5942016-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
5952016-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
5962016-07-28T19:59:31 <sipa> but i don't think it's a big issue
5972016-07-28T19:59:32 <wumpus> sipa: yes, moving the refactor window to after the 0.13.0 release won't help for that
5982016-07-28T19:59:53 <sipa> sometimes code needs non-trivial backports
5992016-07-28T19:59:55 <sipa> so be it
6002016-07-28T19:59:58 <wumpus> yes
6012016-07-28T20:00:08 <wumpus> it's still trivial compared to backporting to 0.12
6022016-07-28T20:00:23 <sipa> DOING
6032016-07-28T20:00:26 <wumpus> #endmeeting
6042016-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)
6052016-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
6062016-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
6072016-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
6082016-07-28T20:00:58 <sipa> DOH-ING
6092016-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...
6102016-07-28T20:01:06 <gmaxwell> DOOIINNGGG
6112016-07-28T20:01:09 *** thokon00 has joined #bitcoin-core-dev
6122016-07-28T20:01:30 <jonasschnelli> sipa: time for your Pokemon walk. :P
6132016-07-28T20:01:37 <sdaftuar> cfields: regarding #8096, i don't think i've seen that error since i first reported it.
6142016-07-28T20:01:38 <jtimon> haha
6152016-07-28T20:01:58 <wumpus> :P
6162016-07-28T20:02:11 <NicolasDorier> jtimon: my 8259 in fact date back in march :D
6172016-07-28T20:02:12 <cfields> sdaftuar: ok. I tried to investigate, but I couldn't even find a good starting point
6182016-07-28T20:02:23 <NicolasDorier> I needed to refactor and reopen the issue several time
6192016-07-28T20:02:29 *** cryptapus has quit IRC
6202016-07-28T20:02:30 <NicolasDorier> I mean rebase
6212016-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
6222016-07-28T20:02:39 *** jcorgan has left #bitcoin-core-dev
6232016-07-28T20:02:48 <NicolasDorier> (the first time 8259 was created was on sipa's branch before the merge :p)
6242016-07-28T20:03:27 <jtimon> well, my approach is as old as #6061
6252016-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
6262016-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
6272016-07-28T20:03:53 <sdaftuar> wumpus: i agree that it shouldn't be a blocker
6282016-07-28T20:03:54 <jtimon> that was a "please don't do too much stuff at a time" PR for my approach
6292016-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 :)
6302016-07-28T20:04:53 <wumpus> sdaftuar: thanks, removing the milestone then
6312016-07-28T20:05:31 <jtimon> NicolasDorier: last attempt to move in my direction: https://github.com/bitcoin/bitcoin/pull/6445
6322016-07-28T20:05:34 <wumpus> cfields: yes I agree an unexplainable problem is slightly worrying
6332016-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...
6342016-07-28T20:07:20 <jtimon> should I close #8346 then?
6352016-07-28T20:07:27 <jtimon> ping btcdrak
6362016-07-28T20:08:04 <NicolasDorier> I don't think it should be closed, we'll just merge later
6372016-07-28T20:08:10 <wumpus> jtimon: I agree that it's annoying
6382016-07-28T20:08:18 <btcdrak> jtimon: leave it open
6392016-07-28T20:08:28 <sipa> jtimon: leave it open
6402016-07-28T20:08:33 <jtimon> NicolasDorier: oh, it's not disruptive to your approach, cool
6412016-07-28T20:08:55 <wumpus> it has quite a lot of utACKs so just should be merged?
6422016-07-28T20:09:14 <NicolasDorier> fine for me
6432016-07-28T20:09:26 <jtimon> I thought it would interfere with #8259, sorry
6442016-07-28T20:09:34 <sipa> it would, but so be it
6452016-07-28T20:09:40 <sipa> sorry for bringing it uo
6462016-07-28T20:10:04 <jtimon> never be sorry for bringing things up, that's what I need
6472016-07-28T20:11:03 <NicolasDorier> I've rebased 8259 10 times, I guess I'll support an 11 th time :D
6482016-07-28T20:11:09 <NicolasDorier> I've nothing to do today anyway :^p
6492016-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!
6502016-07-28T20:11:58 <jtimon> anyway, I should review 8259 before continuing talking about it, sorry
6512016-07-28T20:14:18 *** schmidty has quit IRC
6522016-07-28T20:19:09 *** BashCo has quit IRC
6532016-07-28T20:19:12 *** thokon00 has left #bitcoin-core-dev
6542016-07-28T20:19:15 <jtimon> NicolasDorier: no harm in squashing #8259 at this point I think?
6552016-07-28T20:22:29 *** nets1n has quit IRC
6562016-07-28T20:24:42 *** anu1 has joined #bitcoin-core-dev
6572016-07-28T20:27:12 *** ArthurNumbanumba has quit IRC
6582016-07-28T20:27:51 *** anu0 has quit IRC
6592016-07-28T20:33:27 *** Giszmo has quit IRC
6602016-07-28T20:37:19 *** BashCo has joined #bitcoin-core-dev
6612016-07-28T20:41:36 <NicolasDorier> jtimon: yes I'll squash. Will do it after changing stuff that need to change because of #8346.
6622016-07-28T20:41:39 *** Giszmo has joined #bitcoin-core-dev
6632016-07-28T20:41:56 <NicolasDorier> actually I think that 8346 will make it shorter to review in fact
6642016-07-28T20:42:31 <NicolasDorier> because a method which needed the hash cache is not called anymore.
6652016-07-28T20:43:45 *** dgenr8 has quit IRC
6662016-07-28T20:44:32 *** droark has quit IRC
6672016-07-28T20:45:16 <jtimon> cool
6682016-07-28T20:45:47 <jtimon> keep the old version for the backport though
6692016-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
6702016-07-28T20:47:30 <jtimon> nothing to commit is complete success
6712016-07-28T20:48:02 <jtimon> no, wait, forget the defintion of success, that's wrong
6722016-07-28T20:48:11 *** windsok has quit IRC
6732016-07-28T20:48:58 <NicolasDorier> In fact in https://github.com/bitcoin/bitcoin/pull/8259/files#diff-ca74c4b28865382863b8fe7633a85cd6L740 the hashCacheMap was not even use...
6742016-07-28T20:49:10 <NicolasDorier> used
6752016-07-28T20:49:16 <NicolasDorier> because it does not run the scripts
6762016-07-28T20:49:18 *** windsok has joined #bitcoin-core-dev
6772016-07-28T20:50:15 *** cryptapus_afk is now known as cryptapus_
6782016-07-28T20:50:16 <jtimon> not sure I understand what you just said
6792016-07-28T20:50:18 *** cryptapus_ is now known as cryptapus
6802016-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.
6812016-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
6822016-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
6832016-07-28T20:57:00 <jtimon> sorry, now all callers use true
6842016-07-28T20:58:30 <NicolasDorier> oh that's cool
6852016-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
6862016-07-28T21:02:47 <jtimon> that's ancient coolness that's been ready to pick up for long
6872016-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])
6882016-07-28T21:05:14 <jtimon> and remove some redundant calculations while helping with encapsulation
6892016-07-28T21:05:51 <jtimon> then divide the remaining checkinputs, one multi-thread and one plain simple
6902016-07-28T21:06:18 <jtimon> of course there's many ways to do this
6912016-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)
6922016-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
6932016-07-28T21:10:30 <jtimon> but I agree that just complete an internal verifyblock would be great
6942016-07-28T21:10:38 *** cryptapus is now known as cryptapus_afk
6952016-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() )
6962016-07-28T21:13:49 <jtimon> btw, for trivial consensus stuff #8413 is also opened
6972016-07-28T21:17:06 <bsm117532> ls
6982016-07-28T21:19:05 *** yep has quit IRC
6992016-07-28T21:19:35 *** jtimon has quit IRC
7002016-07-28T21:19:57 *** jtimon has joined #bitcoin-core-dev
7012016-07-28T21:21:09 <jtimon> bsm117532:
7022016-07-28T21:21:11 <jtimon> drwxrwxr-x 23 jt jt 12288 jul 28 05:27 .
7032016-07-28T21:21:13 <jtimon> drwxrwxr-x 12 jt jt 4096 jul 28 05:24 ..
7042016-07-28T21:25:03 *** d_t has quit IRC
7052016-07-28T21:26:57 *** btcdrak has left #bitcoin-core-dev
7062016-07-28T21:28:49 <bsm117532> [ whereis my brain?
7072016-07-28T21:32:59 *** btcdrak has joined #bitcoin-core-dev
7082016-07-28T21:37:16 *** slackircbridge has quit IRC
7092016-07-28T21:37:29 *** slackircbridge has joined #bitcoin-core-dev
7102016-07-28T21:38:37 *** dgenr8 has joined #bitcoin-core-dev
7112016-07-28T21:44:16 <jtimon> bsm117532: in your brain and some other parts of your body, but wrong channel again
7122016-07-28T21:45:20 <bsm117532> bash: [: missing `]'
7132016-07-28T21:46:05 *** goatpig has joined #bitcoin-core-dev
7142016-07-28T21:51:02 *** spudowiar has quit IRC
7152016-07-28T21:54:07 *** netzin has joined #bitcoin-core-dev
7162016-07-28T21:54:25 *** netzin is now known as nets1n
7172016-07-28T21:54:40 *** spudowiar has joined #bitcoin-core-dev
7182016-07-28T22:06:39 *** spudowiar has quit IRC
7192016-07-28T22:20:35 *** moli has quit IRC
7202016-07-28T22:39:15 *** moli has joined #bitcoin-core-dev
7212016-07-28T22:49:24 *** nets1n has quit IRC
7222016-07-28T22:51:45 *** Guyver2 has quit IRC
7232016-07-28T22:53:00 <jtimon> updated #8346
7242016-07-28T22:58:13 <cfields> sdaftuar: heh: i just forced a crash in PruneBlockIndexCandidates
7252016-07-28T22:58:40 <cfields> not the same crash, but I suspect it's something similar
7262016-07-28T22:59:24 <GitHub106> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/133c727cc4f7...ad087638ee48
7272016-07-28T22:59:24 <GitHub106> bitcoin/master d12b732 Jorge Timón: libconsensus: Expose a flag for BIP112...
7282016-07-28T22:59:25 <GitHub106> bitcoin/master ad08763 Pieter Wuille: Merge #8412: libconsensus: Expose a flag for BIP112...
7292016-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
7302016-07-28T23:00:50 <cfields> sdaftuar: http://pastebin.com/raw/CnV5HSUP. ctrl+c during startup.
7312016-07-28T23:02:32 *** spudowiar has joined #bitcoin-core-dev
7322016-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
7332016-07-28T23:07:13 *** spudowiar has quit IRC
7342016-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...
7352016-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
7362016-07-28T23:15:34 *** cdecker has quit IRC
7372016-07-28T23:19:42 <GitHub133> [bitcoin] sipa pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8360d5b37dd4d8248da0552de40e5ea1d17f51eb
7382016-07-28T23:19:43 <GitHub133> bitcoin/0.13 8360d5b Jorge Timón: libconsensus: Expose a flag for BIP112...
7392016-07-28T23:20:32 <sipa> NicolasDorier: i think you misunderstand my suggestion
7402016-07-28T23:20:48 <NicolasDorier> mh maybe
7412016-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.
7422016-07-28T23:22:42 <NicolasDorier> if a CachedHashes are not read only, then I need to protect read and write with a lock
7432016-07-28T23:23:01 <sipa> NicolasDorier: but you solve that by having two CachedHashes
7442016-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
7452016-07-28T23:24:13 <sipa> your code already does this correctly
7462016-07-28T23:24:15 <NicolasDorier> oh I see as part of the TrySet ?
7472016-07-28T23:24:21 <sipa> yes
7482016-07-28T23:24:26 <sipa> TrySet would merge
7492016-07-28T23:24:53 <NicolasDorier> ah ok yes indeed this is simple
7502016-07-28T23:25:03 <NicolasDorier> will do that thanks
7512016-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
7522016-07-28T23:25:52 <NicolasDorier> for the computation
7532016-07-28T23:25:56 <sipa> it also has the advantage of making signature agregation easier later :)
7542016-07-28T23:27:23 <NicolasDorier> got it
7552016-07-28T23:27:38 <sipa> also, i'd not touch sigcache.h
7562016-07-28T23:27:44 <sipa> this is not signature caching
7572016-07-28T23:29:29 <NicolasDorier> ok will create a new file for it
7582016-07-28T23:29:36 <sipa> thanks
7592016-07-28T23:47:38 <jtimon> SIGHASH_ALL is the main.cpp of sighashes
7602016-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])
7612016-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
7622016-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