12016-08-04T00:00:09 *** ennui has joined #bitcoin-core-dev
22016-08-04T00:07:50 *** justanotheruser has quit IRC
32016-08-04T00:12:13 *** justanotheruser has joined #bitcoin-core-dev
42016-08-04T00:20:55 *** fengling has joined #bitcoin-core-dev
52016-08-04T00:21:35 *** grubles has quit IRC
62016-08-04T00:25:46 *** fengling has quit IRC
72016-08-04T00:27:13 *** Guyver2 has quit IRC
82016-08-04T00:36:01 *** Giszmo has quit IRC
92016-08-04T00:38:02 *** ennui has quit IRC
102016-08-04T00:39:29 *** ennui has joined #bitcoin-core-dev
112016-08-04T00:47:01 *** Ylbam_ has joined #bitcoin-core-dev
122016-08-04T00:47:33 *** Ylbam has quit IRC
132016-08-04T00:47:33 *** Ylbam_ is now known as Ylbam
142016-08-04T00:48:24 *** ennui has quit IRC
152016-08-04T00:55:21 *** belcher has quit IRC
162016-08-04T01:09:50 *** aureianimus_ has quit IRC
172016-08-04T01:16:57 <GitHub184> [bitcoin] sipa opened pull request #8451: Get rid of the const field in CTransaction (master...noconsttx) https://github.com/bitcoin/bitcoin/pull/8451
182016-08-04T01:22:36 *** fengling has joined #bitcoin-core-dev
192016-08-04T01:25:50 *** Ylbam has quit IRC
202016-08-04T01:27:26 *** fengling has quit IRC
212016-08-04T01:45:08 *** spudowiar has quit IRC
222016-08-04T01:48:00 *** spudowiar has joined #bitcoin-core-dev
232016-08-04T02:06:24 *** jtimon has quit IRC
242016-08-04T02:16:59 *** FNinTak has joined #bitcoin-core-dev
252016-08-04T02:23:53 <GitHub106> [bitcoin] sipa opened pull request #8452: Code simplification: inline CTxInWitness inside CTxIn (master...segwitinline) https://github.com/bitcoin/bitcoin/pull/8452
262016-08-04T02:24:10 *** fengling has joined #bitcoin-core-dev
272016-08-04T02:28:26 *** fengling has quit IRC
282016-08-04T02:43:36 *** spudowiar has quit IRC
292016-08-04T02:51:07 *** spudowiar has joined #bitcoin-core-dev
302016-08-04T02:51:27 *** spudowiar has joined #bitcoin-core-dev
312016-08-04T02:53:45 *** JackH has joined #bitcoin-core-dev
322016-08-04T02:59:18 <phantomcircuit> wumpus, replaced that wallet test with a python one
332016-08-04T02:59:32 <phantomcircuit> i think it actually covers more of the behavior than it did before but im going to go and check
342016-08-04T03:00:22 <phantomcircuit> hmm im not testing addmultisigaddress
352016-08-04T03:00:36 *** NLNico has joined #bitcoin-core-dev
362016-08-04T03:00:44 <phantomcircuit> but that's already being tested in other places
372016-08-04T03:01:12 <phantomcircuit> although not that it works with accounts
382016-08-04T03:04:18 *** Chris_Stewart_5 has quit IRC
392016-08-04T03:06:25 *** hsmiths has quit IRC
402016-08-04T03:06:46 *** Chris_Stewart_5 has joined #bitcoin-core-dev
412016-08-04T03:10:25 *** hsmiths has joined #bitcoin-core-dev
422016-08-04T03:12:11 *** Alopex has quit IRC
432016-08-04T03:13:19 *** Alopex has joined #bitcoin-core-dev
442016-08-04T03:14:07 *** Chris_Stewart_5 has quit IRC
452016-08-04T03:24:53 *** fengling has joined #bitcoin-core-dev
462016-08-04T03:29:47 *** fengling has quit IRC
472016-08-04T03:35:17 *** spudowiar has quit IRC
482016-08-04T03:46:02 *** jgarzik has joined #bitcoin-core-dev
492016-08-04T03:46:02 *** jgarzik has joined #bitcoin-core-dev
502016-08-04T03:53:34 *** pmienk has quit IRC
512016-08-04T04:06:15 *** pmienk has joined #bitcoin-core-dev
522016-08-04T04:25:50 *** FNinTak has quit IRC
532016-08-04T04:27:03 *** fengling has joined #bitcoin-core-dev
542016-08-04T04:31:46 *** fengling has quit IRC
552016-08-04T04:50:28 *** d_t has joined #bitcoin-core-dev
562016-08-04T04:55:03 *** d_t has quit IRC
572016-08-04T05:28:47 *** fengling has joined #bitcoin-core-dev
582016-08-04T05:33:06 *** fengling has quit IRC
592016-08-04T05:39:04 *** teslax has joined #bitcoin-core-dev
602016-08-04T05:39:14 *** teslax has left #bitcoin-core-dev
612016-08-04T05:48:15 *** opz has quit IRC
622016-08-04T06:28:27 *** fengling has joined #bitcoin-core-dev
632016-08-04T06:35:27 *** jgarzik has quit IRC
642016-08-04T06:51:09 *** luke-jr has quit IRC
652016-08-04T06:51:48 *** luke-jr has joined #bitcoin-core-dev
662016-08-04T06:52:44 *** BashCo_ has quit IRC
672016-08-04T06:53:20 *** d_t has joined #bitcoin-core-dev
682016-08-04T07:13:52 *** BashCo has joined #bitcoin-core-dev
692016-08-04T07:19:46 *** luke-jr has quit IRC
702016-08-04T07:19:54 *** luke-jr has joined #bitcoin-core-dev
712016-08-04T07:23:42 *** laurentmt has joined #bitcoin-core-dev
722016-08-04T07:27:22 *** d_t has quit IRC
732016-08-04T07:36:20 *** jgarzik has joined #bitcoin-core-dev
742016-08-04T08:13:18 *** d_t has joined #bitcoin-core-dev
752016-08-04T08:25:52 *** MarcoFalke has joined #bitcoin-core-dev
762016-08-04T08:50:45 <wumpus> phantomcircuit: nice!
772016-08-04T08:53:41 <wumpus> sipa: the last update of secp256k1 has been ~9 months ago (6c527ec), is it maybe time to update the subtree again? At least the (experimental) ARM assembly has been merged since
782016-08-04T08:54:50 <sipa> wumpus: good idea
792016-08-04T08:55:26 <sipa> there are certainly no regressions known that would make the current master less appropriate than the subtree in bitcoin currently
802016-08-04T08:56:07 <wumpus> exactly, I did mean for master, not 0.13
812016-08-04T08:57:05 <sipa> sure
822016-08-04T08:58:47 *** Ayhan has joined #bitcoin-core-dev
832016-08-04T09:03:44 *** Giszmo has joined #bitcoin-core-dev
842016-08-04T09:04:02 *** Ayhan has quit IRC
852016-08-04T09:08:38 *** Guyver2 has joined #bitcoin-core-dev
862016-08-04T09:18:39 *** Lauda has quit IRC
872016-08-04T09:19:06 *** Lauda has joined #bitcoin-core-dev
882016-08-04T09:25:45 <GitHub30> [bitcoin] laanwj opened pull request #8453: Bring secp256k1 subtree up to date with master (master...2016_08_update_secp256k1) https://github.com/bitcoin/bitcoin/pull/8453
892016-08-04T09:43:59 *** berndj has quit IRC
902016-08-04T09:44:32 *** NLNico has quit IRC
912016-08-04T09:48:12 *** aureianimus_ has joined #bitcoin-core-dev
922016-08-04T10:07:01 *** spudowiar has joined #bitcoin-core-dev
932016-08-04T10:21:19 <GitHub18> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5c7a5e1f66d8...37d83bb0a980
942016-08-04T10:21:19 <GitHub18> bitcoin/master 122786d NicolasDorier: Consensus: Remove ISM
952016-08-04T10:21:20 <GitHub18> bitcoin/master 37d83bb Wladimir J. van der Laan: Merge #8391: Consensus: Remove ISM...
962016-08-04T10:21:25 <GitHub105> [bitcoin] laanwj closed pull request #8391: Consensus: Remove ISM (master...remove-ism) https://github.com/bitcoin/bitcoin/pull/8391
972016-08-04T10:22:36 *** spudowiar has quit IRC
982016-08-04T10:26:32 *** MarcoFalke has left #bitcoin-core-dev
992016-08-04T10:34:02 <GitHub46> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/37d83bb0a980...f97d335942ae
1002016-08-04T10:34:03 <GitHub46> bitcoin/master 0fd2a33 Pieter Wuille: Use a signal to continue init after genesis activation
1012016-08-04T10:34:03 <GitHub46> bitcoin/master aa59f2e Pieter Wuille: Add extra message to avoid a long 'Loading banlist'
1022016-08-04T10:34:04 <GitHub46> bitcoin/master 9d4eb9a Pieter Wuille: Do diskspace check before import thread is started
1032016-08-04T10:34:11 <GitHub154> [bitcoin] laanwj closed pull request #8392: Fix several node initialization issues (master...fixactivatewait) https://github.com/bitcoin/bitcoin/pull/8392
1042016-08-04T10:42:47 *** d_t has quit IRC
1052016-08-04T10:46:53 *** rubensayshi has joined #bitcoin-core-dev
1062016-08-04T10:49:58 *** laurentmt has quit IRC
1072016-08-04T10:52:53 *** Cory has quit IRC
1082016-08-04T10:53:32 <paveljanik> wumpus, do you use gmp? string.h is included in num_gmp_impl.h... This could be difference.
1092016-08-04T10:54:57 <wumpus> yes, that could be it
1102016-08-04T10:55:45 <wumpus> will try with bignum=no
1112016-08-04T10:55:59 <wumpus> yes, that does it
1122016-08-04T10:56:29 *** laurentmt has joined #bitcoin-core-dev
1132016-08-04T10:57:32 *** Cory has joined #bitcoin-core-dev
1142016-08-04T11:02:14 <wumpus> paveljanik: https://github.com/bitcoin-core/secp256k1/pull/410
1152016-08-04T11:12:09 *** randy-waterhouse has quit IRC
1162016-08-04T11:14:40 *** laurentmt has quit IRC
1172016-08-04T11:15:11 *** laurentmt has joined #bitcoin-core-dev
1182016-08-04T11:17:20 <paveljanik> thanks!
1192016-08-04T11:31:30 <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f97d335942ae...6e6ab2c32382
1202016-08-04T11:31:31 <GitHub189> bitcoin/master 2c517b3 Suhas Daftuar: Fix p2p-feefilter.py for changed tx relay behavior
1212016-08-04T11:31:31 <GitHub189> bitcoin/master 6e6ab2c Wladimir J. van der Laan: Merge #8444: Fix p2p-feefilter.py for changed tx relay behavior...
1222016-08-04T11:31:40 <GitHub87> [bitcoin] laanwj closed pull request #8444: Fix p2p-feefilter.py for changed tx relay behavior (master...fix-feefilter-test) https://github.com/bitcoin/bitcoin/pull/8444
1232016-08-04T11:35:06 <paveljanik> wumpus, in fact, the fix is not upstream, but side-stream ;-)
1242016-08-04T11:35:42 <wumpus> well I hope it can be merged soon, I'll update #8453 after that
1252016-08-04T11:36:19 <wumpus> bah I'd really feel better without expat in the depends :)
1262016-08-04T11:37:36 *** cjcj has joined #bitcoin-core-dev
1272016-08-04T11:43:11 *** cryptapus has joined #bitcoin-core-dev
1282016-08-04T11:43:11 *** cryptapus has joined #bitcoin-core-dev
1292016-08-04T11:54:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1302016-08-04T12:02:55 *** berndj has joined #bitcoin-core-dev
1312016-08-04T12:26:06 *** fengling has quit IRC
1322016-08-04T12:26:08 <GitHub129> [bitcoin] MarcoFalke opened pull request #8454: [0.13.1] Fix p2p-feefilter.py for changed tx relay behavior (0.13...Mf1608-qaFeeFilter013) https://github.com/bitcoin/bitcoin/pull/8454
1332016-08-04T12:40:45 <GitHub71> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/d485a6c5a8d238cac5ad732ce9e744f4b121143c
1342016-08-04T12:40:45 <GitHub71> bitcoin/0.13 d485a6c Wladimir J. van der Laan: doc: Add list of new and removed RPC commands to release notes...
1352016-08-04T12:41:43 <wumpus> sipa: do you still plan on writing something for the release notes about -reindex-chainstate?
1362016-08-04T12:45:55 <wumpus> I've added a list of added and removed and changed RPC calls, which means that #7678 can almost be closed, leaving -maxtimeadjust and -reindex-chainstate, of which I think reindex-chainstate (and the changed reindexing in general) is most relevant
1372016-08-04T12:56:46 *** Guyver2 has quit IRC
1382016-08-04T12:59:13 *** fengling has joined #bitcoin-core-dev
1392016-08-04T12:59:33 *** Chris_Stewart_5 has quit IRC
1402016-08-04T13:04:06 *** fengling has quit IRC
1412016-08-04T13:06:49 *** BashCo has quit IRC
1422016-08-04T13:06:55 *** BashCo_ has joined #bitcoin-core-dev
1432016-08-04T13:29:29 *** zooko has joined #bitcoin-core-dev
1442016-08-04T13:33:30 *** laurentmt1 has joined #bitcoin-core-dev
1452016-08-04T13:34:36 *** laurentmt has quit IRC
1462016-08-04T13:34:36 *** laurentmt1 is now known as laurentmt
1472016-08-04T13:52:38 <GitHub198> [bitcoin] mrbandrews opened pull request #8456: [RPC] Simplified bumpfee command. (master...ba-rpcbumpfee) https://github.com/bitcoin/bitcoin/pull/8456
1482016-08-04T14:00:26 *** mkarrer has quit IRC
1492016-08-04T14:00:34 *** fengling has joined #bitcoin-core-dev
1502016-08-04T14:01:11 *** mkarrer has joined #bitcoin-core-dev
1512016-08-04T14:05:26 *** fengling has quit IRC
1522016-08-04T14:20:29 *** spudowiar has joined #bitcoin-core-dev
1532016-08-04T14:33:02 *** Guyver2 has joined #bitcoin-core-dev
1542016-08-04T15:00:02 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1552016-08-04T15:02:07 *** fengling has joined #bitcoin-core-dev
1562016-08-04T15:07:06 *** fengling has quit IRC
1572016-08-04T15:35:01 *** aalex has joined #bitcoin-core-dev
1582016-08-04T15:53:26 *** BashCo_ has quit IRC
1592016-08-04T15:54:06 *** BashCo has joined #bitcoin-core-dev
1602016-08-04T16:02:45 *** Chris_Stewart_5 has quit IRC
1612016-08-04T16:03:39 *** fengling has joined #bitcoin-core-dev
1622016-08-04T16:04:09 *** BashCo has quit IRC
1632016-08-04T16:08:26 *** fengling has quit IRC
1642016-08-04T16:17:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1652016-08-04T16:24:52 <GitHub160> [bitcoin] pedrobranco opened pull request #8457: Add block height support in rpc call getblock (master...feature/add-get-block-by-number) https://github.com/bitcoin/bitcoin/pull/8457
1662016-08-04T16:30:42 *** rubensayshi has quit IRC
1672016-08-04T16:30:45 *** BashCo has joined #bitcoin-core-dev
1682016-08-04T16:32:38 *** saurb has joined #bitcoin-core-dev
1692016-08-04T16:33:47 *** saurb has quit IRC
1702016-08-04T16:41:58 *** jtimon has joined #bitcoin-core-dev
1712016-08-04T16:45:55 <sipa> wumpus: ack, will write
1722016-08-04T16:46:05 *** laurentmt has quit IRC
1732016-08-04T17:03:21 *** Guyver2 has quit IRC
1742016-08-04T17:05:09 *** fengling has joined #bitcoin-core-dev
1752016-08-04T17:06:00 *** zooko has quit IRC
1762016-08-04T17:08:34 *** Guyver2 has joined #bitcoin-core-dev
1772016-08-04T17:10:06 *** fengling has quit IRC
1782016-08-04T17:26:46 *** laurentmt has joined #bitcoin-core-dev
1792016-08-04T17:27:46 *** shaiguit1r has joined #bitcoin-core-dev
1802016-08-04T17:30:04 *** shaiguitar has quit IRC
1812016-08-04T17:46:40 *** Chris_Stewart_5 has quit IRC
1822016-08-04T17:52:45 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1832016-08-04T18:07:25 *** fengling has joined #bitcoin-core-dev
1842016-08-04T18:08:12 <instagibbs> during salvage on an unbroken wallet.dat file I'm seeing keys getting skipped
1852016-08-04T18:08:16 <instagibbs> on master
1862016-08-04T18:08:49 <instagibbs> 0-4 keys on a fresh wallet with keypool 100, randomly
1872016-08-04T18:09:21 <gmaxwell> I've said before that salvagewallet should be called "savagewallet".
1882016-08-04T18:09:29 <gmaxwell> instagibbs: can you figure out why?
1892016-08-04T18:09:40 <instagibbs> no ive been trying to chase it down all day
1902016-08-04T18:10:19 <instagibbs> it's very random, and only happens once every 25+ keys
1912016-08-04T18:10:51 <gmaxwell> presumably you've filled up the salvage code with instrumentation to see where they're getting dropped? (e.g. does bdb just never hand them to us?)
1922016-08-04T18:11:11 *** gabridome has joined #bitcoin-core-dev
1932016-08-04T18:11:11 <instagibbs> it's an error thrown when doing >> for private key
1942016-08-04T18:11:22 <instagibbs> "key" type, trying to deserialize the key
1952016-08-04T18:11:26 <instagibbs> priv*
1962016-08-04T18:11:32 <sipa> is it trying to deserialize master key data as the wrong type?
1972016-08-04T18:11:46 *** fengling has quit IRC
1982016-08-04T18:13:48 <instagibbs> I don't think so, as keypool=1 almost never has it happen
1992016-08-04T18:14:06 <instagibbs> I've never had it happen with keypool 1, that is to say
2002016-08-04T18:16:13 *** Chris_Stewart_5 has quit IRC
2012016-08-04T18:19:15 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2022016-08-04T18:20:14 *** jtimon has quit IRC
2032016-08-04T18:20:23 *** gabridome has quit IRC
2042016-08-04T18:20:36 *** telelvis has joined #bitcoin-core-dev
2052016-08-04T18:22:07 <wumpus> instagibbs: can you upload the wallet somewhere that it happens with?
2062016-08-04T18:23:15 <instagibbs> it's literally a fresh wallet, start up bitcoind in regtest, stop, start back up with salvagewallet. Some not small % of time i get those messages
2072016-08-04T18:23:25 <instagibbs> but yes I can upload one
2082016-08-04T18:23:28 <wumpus> it's a known issue btw: salvagewallet drops valid keys #7379 but I've never had it happen to me
2092016-08-04T18:24:10 <wumpus> another similar problem is salvagewallet fails verification #7463 , salvagewallet on an uncorrupted wallet sometimes makes bdb return errors
2102016-08-04T18:24:35 <wumpus> so what you are seeing may be similar, I noticed that problem, just never saw keys being dropped
2112016-08-04T18:25:04 <instagibbs> 2016-08-04 18:07:42 Salvage(aggressive) found 439 records
2122016-08-04T18:25:04 <instagibbs> 2016-08-04 18:07:42 WARNING: CWalletDB::Recover skipping key:
2132016-08-04T18:25:07 <wumpus> I would not be surprised if bdb's "aggressive" salvage sometimes returns crap or misses records
2142016-08-04T18:25:35 <instagibbs> oh is it an actual bdb mode? That might explain the difference
2152016-08-04T18:27:03 <gmaxwell> maybe it should run twice, once normally without any bdb magig, and then again in agressive mode?
2162016-08-04T18:27:25 <gmaxwell> "never do worse than simply reading it."
2172016-08-04T18:27:28 <wumpus> I don't know if that makes a difference, but worth a try
2182016-08-04T18:27:43 <instagibbs> i can try that, if i figure out the settings
2192016-08-04T18:27:56 <gmaxwell> well presumably it must, after all we don't miss those keys during normal reads without salvaging.
2202016-08-04T18:29:09 <wumpus> ooh! those may be ghost keys instagibbs
2212016-08-04T18:29:12 <wumpus> "Output all the key/data pairs in the file that can be found. By default, DB->verify() does not assume corruption. For example, if a key/data pair on a page is marked as deleted, it is not then written to the output file. When DB_AGGRESSIVE is specified, corruption is assumed, and any key/data pair that can be found is written. In this case, key/data pairs that are corrupted or have been deleted may appear in the output (even
2222016-08-04T18:29:13 <wumpus> if the file being salvaged is in no way corrupt), and the output will almost certainly require editing before being loaded into a database."
2232016-08-04T18:29:34 <instagibbs> i aint afraid of no ghost
2242016-08-04T18:29:34 <wumpus> aggressive should return *more* records, but some of them may be deleted, or not really exist at all
2252016-08-04T18:29:55 <cfields> sipa: mm, I just noticed that 0.13 doesn't enable asm for osx due to secp256k1 #373 :\
2262016-08-04T18:30:44 <wumpus> *even if the file being salvaged is in no way corrupt* is the important part there
2272016-08-04T18:30:56 <instagibbs> so how can we test that
2282016-08-04T18:31:04 <wumpus> so yes, trying to salvage without aggressive makes sense first
2292016-08-04T18:32:20 <wumpus> but how can we detect if keys have been dropped due to corruption, which would appear with salvage aggressive? I don't know
2302016-08-04T18:32:41 <wumpus> yes you don't really know, that's the problem
2312016-08-04T18:32:53 <wumpus> was it a real key or just a corrupted echo?
2322016-08-04T18:33:46 <wumpus> cfields: maybe do the secp256k1 update for 0.13.1 too then
2332016-08-04T18:34:02 <instagibbs> so worst case with "ghost" keys would be having keys you didn't actually generate? or?
2342016-08-04T18:34:17 <wumpus> instagibbs: or partial old records
2352016-08-04T18:34:25 *** telelvis1 has joined #bitcoin-core-dev
2362016-08-04T18:34:26 <cfields> wumpus: probably makes sense, yes. I'm running a bench with/without atm.
2372016-08-04T18:34:53 <wumpus> instagibbs: it does a linear scan over the file and everything that looks like a key/value is returned
2382016-08-04T18:35:18 <instagibbs> so aggressive will indeed return more, but we toss anything that looks wrong
2392016-08-04T18:35:20 <paveljanik> Trivial -Wshadow PRs for review: 8109, 8163, 8191, 8449. I'd be glad to get some ACKs. Thank you.
2402016-08-04T18:35:59 <wumpus> instagibbs: yes, we do, we're fairly robust there. But it means possible false positives inthe log
2412016-08-04T18:35:59 *** telelvis has quit IRC
2422016-08-04T18:36:13 <instagibbs> wumpus, ok, well that's less scary, thanks
2432016-08-04T18:36:47 <wumpus> instagibbs: I hope that's it! but you can only find out by analysing that wallet\
2442016-08-04T18:37:08 <wumpus> see if the keys that are in the original wallet and post-salvage wallet are the same, despite the WARNING
2452016-08-04T18:37:50 <sipa> wumpus: i'll merge the strings include in secp
2462016-08-04T18:37:59 <wumpus> sipa: thanks
2472016-08-04T18:38:07 <sipa> so that can be included in the subtree
2482016-08-04T18:38:14 <wumpus> right, I'll update the pr
2492016-08-04T18:38:25 *** spudowiar has quit IRC
2502016-08-04T18:38:38 <cfields> 116us vs 124us. not the end of the world.
2512016-08-04T18:38:39 *** telelvis has joined #bitcoin-core-dev
2522016-08-04T18:39:01 *** telelvis1 has quit IRC
2532016-08-04T18:39:01 <wumpus> don't think that'd be worth it for any random warning, but missing prototypes are pretty serious business
2542016-08-04T18:40:02 <sipa> cfields: that's the output of bench_verify ?
2552016-08-04T18:40:22 <gmaxwell> cfields: I'm surprised by that.
2562016-08-04T18:40:29 <gmaxwell> the difference is smaller than I expected.
2572016-08-04T18:40:29 <sipa> likewise
2582016-08-04T18:40:31 <cfields> sipa: yes
2592016-08-04T18:41:44 <sipa> what compilation flags?
2602016-08-04T18:41:58 <cfields> sipa: default passed down from bitcoin
2612016-08-04T18:42:37 <wumpus> 116 versus 124 seems in the error margin, are you sure something changed at all?
2622016-08-04T18:42:42 <cfields> sipa: http://pastebin.com/raw/VbmBERA8
2632016-08-04T18:43:18 <cfields> ran a few times of each, didn't deviate much. double-checking.
2642016-08-04T18:43:23 <wumpus> okay
2652016-08-04T18:44:53 <gmaxwell> cfields: what cpu is this?
2662016-08-04T18:46:38 <cfields> gmaxwell: i5, 2.4ghz. there's no /proc/cpuinfo in osx, i can dig around and find it if you'd like the gen
2672016-08-04T18:47:57 *** MarcoFalke has joined #bitcoin-core-dev
2682016-08-04T18:48:04 <sipa> cfields: reproduced
2692016-08-04T18:48:13 <cfields> there we go. 4258U. haswell.
2702016-08-04T18:48:36 <sipa> 112us vs 117us here
2712016-08-04T18:48:46 <sipa> ecdsa_verify: min 117us / avg 117us / max 117us
2722016-08-04T18:48:54 <sipa> ecdsa_verify: min 112us / avg 113us / max 113us
2732016-08-04T18:49:11 <jonasschnelli> cfields: OSX: use "sysctl -n machdep.cpu.brand_string" instead cat /proc/cpuinfo
2742016-08-04T18:49:15 <cfields> sipa: in linux? or reproduced on mac?
2752016-08-04T18:49:23 <sipa> linux
2762016-08-04T18:49:36 <sipa> with cpu clock pinned to a single frequency
2772016-08-04T18:49:44 <GitHub127> [bitcoin] MarcoFalke pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/d485a6c5a8d2...114f7e944b1c
2782016-08-04T18:49:45 <GitHub127> bitcoin/0.13 cd0910b Suhas Daftuar: Fix p2p-feefilter.py for changed tx relay behavior...
2792016-08-04T18:49:45 <GitHub127> bitcoin/0.13 114f7e9 MarcoFalke: Merge #8454: [0.13.1] Fix p2p-feefilter.py for changed tx relay behavior...
2802016-08-04T18:49:46 <GitHub182> [bitcoin] MarcoFalke closed pull request #8454: [0.13.1] Fix p2p-feefilter.py for changed tx relay behavior (0.13...Mf1608-qaFeeFilter013) https://github.com/bitcoin/bitcoin/pull/8454
2812016-08-04T18:50:00 <cfields> huh.
2822016-08-04T18:50:02 <gmaxwell> sipa: that looks broken, those numbers are much higher than I expect.
2832016-08-04T18:50:09 <gmaxwell> (for both of you)
2842016-08-04T18:50:28 <sipa> that's without gmp or endomorphism, at 2.6 GHz
2852016-08-04T18:50:33 <cfields> gmaxwell: remember no bignum or endo
2862016-08-04T18:50:37 <gmaxwell> I normally expect a verify to be more like 70us. but maybe thats all gmp.
2872016-08-04T18:51:42 <cfields> jonasschnelli: thanks
2882016-08-04T18:52:02 <wumpus> MarcoFalke: please don't merge anything for 0.13 now, we have to decide on the meeting whether to release final, this is a test change but I don't want to have to trigger a new rc without good reason
2892016-08-04T18:52:29 <MarcoFalke> This should not be enough for a new rc
2902016-08-04T18:52:57 <wumpus> I know, but you named it 0.13.1, and it's not time to merge for 0.13.1 yet, just clarifying
2912016-08-04T18:53:10 <MarcoFalke> oops
2922016-08-04T18:53:27 * gmaxwell predicts a build system problem.
2932016-08-04T18:53:35 <gmaxwell> (in libsecp256k1)
2942016-08-04T18:53:37 <wumpus> (people may still want to do e.g. changelog changes before tagging final)
2952016-08-04T18:53:44 <gmaxwell> cd ~
2962016-08-04T18:54:07 <cfields> gmaxwell: for which?
2972016-08-04T18:54:11 <wumpus> bitcoin is always without gmp
2982016-08-04T18:54:20 <sipa> gmaxwell: sounds likely... with endo and gmp enabled is see no statistically significant performance difference between asm enabled and disabled
2992016-08-04T18:54:44 <sipa> 71.2us vs 71.4us
3002016-08-04T18:55:02 <sipa> (with variance between tests exceeding 0.2us)
3012016-08-04T18:57:32 <gmaxwell> Aside, I think in the GUI and logs we should display the verification performance... so people will better realize how radically difference in speed different machines are. :)
3022016-08-04T18:58:22 <wumpus> yes, a graph of verification performance in the gui would be nice
3032016-08-04T18:59:02 <wumpus> similar to the bandwidth one
3042016-08-04T18:59:19 <wumpus> with part spent in i/o secp256k1 etc
3052016-08-04T18:59:20 <jonasschnelli> heh.. currently working on a mempool graph
3062016-08-04T18:59:44 <wumpus> nice
3072016-08-04T19:00:10 <jonasschnelli> http://i.imgur.com/G6yi9UR.png (very basic atm)
3082016-08-04T19:00:14 <gmaxwell> wumpus: Well I meant as a static this computer x faster than that computer. not usage.
3092016-08-04T19:00:24 <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
3102016-08-04T19:00:43 <wumpus> #startmeeting
3112016-08-04T19:00:43 <lightningbot> Meeting started Thu Aug 4 19:00:43 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3122016-08-04T19:00:43 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3132016-08-04T19:01:01 <cfields> gmaxwell: mm, i just stuck some "#error foo" in the asm paths, it blows up as expected.
3142016-08-04T19:01:06 <cfields> whoops, will continue after meeting
3152016-08-04T19:01:15 <MarcoFalke> topic 0.13.0, I guess?
3162016-08-04T19:01:22 <wumpus> #topic 0.13.0 final?
3172016-08-04T19:01:33 <wumpus> did anyone hear of any critical problems with rc2?
3182016-08-04T19:01:54 <gmaxwell> I haven't heard much on it. Been quiet.
3192016-08-04T19:02:03 <sipa> we forgot to backport 8438/8365 into 0.13...
3202016-08-04T19:02:16 <wumpus> sipa something for 0.13.1?
3212016-08-04T19:02:29 <kanzure> hi. greetings.
3222016-08-04T19:02:39 <luke-jr> wumpus: the release notes are still inappropriate AFAIK
3232016-08-04T19:03:07 <luke-jr> also gmaxwell was going to add a section I believe, covering the new relay policy influences (maybe I missed that being added)
3242016-08-04T19:03:11 <jeremyrubin> hi
3252016-08-04T19:03:12 <gmaxwell> I think I owed some release note text which I haven't done yet re max blocksize settings.
3262016-08-04T19:03:12 <kanzure> this isn't short-term development related but it's high signal-noise crypto content that a few developers recently participated in, http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/
3272016-08-04T19:03:16 <MarcoFalke> Wouldn't 8438 require rc3?
3282016-08-04T19:03:16 <wumpus> luke-jr: then update them, sipa also still wants to add something
3292016-08-04T19:03:22 <wumpus> MarcoFalke: yes
3302016-08-04T19:03:28 <luke-jr> wumpus: my PR to update them is still open.
3312016-08-04T19:03:35 <wumpus> luke-jr: it also updates code
3322016-08-04T19:03:43 <jonasschnelli> luke-jr: does the PR still contain code changes?
3332016-08-04T19:03:46 *** telelvis has quit IRC
3342016-08-04T19:03:46 <luke-jr> so you want a version without code changes?
3352016-08-04T19:04:06 <wumpus> luke-jr: if you make a PR that just updates the changelog, and it's accepted by others, it would have been merged a long time ago
3362016-08-04T19:04:47 <luke-jr> wumpus: the current language was not accepted.
3372016-08-04T19:04:59 <jonasschnelli> sipa: do you think https://github.com/bitcoin/bitcoin/pull/8438 can wait for 0.13.1?
3382016-08-04T19:05:06 <luke-jr> I find this double-standard somewhat annoying.
3392016-08-04T19:05:12 <morcos> sigh, if this is another meeting of us all arguing against luke-jr then i'm going to find something else to do
3402016-08-04T19:05:20 *** telelvis1 has joined #bitcoin-core-dev
3412016-08-04T19:05:29 <jonasschnelli> heh. Yes. Finish this. luke-jr can open a pr (action)
3422016-08-04T19:05:40 <wumpus> I'm not arguing against luke-jr
3432016-08-04T19:06:08 <wumpus> anyhow that derailed my question - so no one had any critical problems with 0.13.0rc2?
3442016-08-04T19:06:22 <wumpus> and I don't mean with the release notes
3452016-08-04T19:06:30 <sipa> is there any fear of instagibbs' problem being due to a code error?
3462016-08-04T19:06:38 <wumpus> what problem?
3472016-08-04T19:06:41 <instagibbs> sipa, fwiw it's showing up on older fork...
3482016-08-04T19:06:58 <instagibbs> it's not HD-related, or anything fairly recent
3492016-08-04T19:07:00 <gmaxwell> instagibbs: so without the bip32 changes?
3502016-08-04T19:07:04 <instagibbs> correct
3512016-08-04T19:07:05 <wumpus> you mean the salvagewallet problem? that's old hat, there's two issues open with salvagewallet problems
3522016-08-04T19:07:09 <sipa> instagibbs: ok, good to know
3532016-08-04T19:07:11 <wumpus> as I mentioned
3542016-08-04T19:07:19 <sipa> sorry, i didn't follow the whole discussion
3552016-08-04T19:07:19 <wumpus> this is not a last minute problem
3562016-08-04T19:07:21 <luke-jr> wumpus: earlier we were discussing 0.13.0's failure mode downgrading from 0.13.1; I am not clear what the status of that is, or if we need changes for it
3572016-08-04T19:07:22 <instagibbs> yes I'll double-check that keys aren't actually going away
3582016-08-04T19:07:26 <instagibbs> but not worried now
3592016-08-04T19:07:31 <gmaxwell> OK.
3602016-08-04T19:07:36 <instagibbs> LoadWallet works anyhoo :P
3612016-08-04T19:07:39 <wumpus> yes
3622016-08-04T19:08:23 *** fengling has joined #bitcoin-core-dev
3632016-08-04T19:08:26 <wumpus> so, all agree that it is time to release 0.13.0 final?
3642016-08-04T19:08:34 <wumpus> (after say, a day of updating the release notes)
3652016-08-04T19:09:06 <sipa> do we care about what happens when someone downgrades 0.13.1 to 0.13.0 after segwit activates?
3662016-08-04T19:09:08 <jonasschnelli> ACK, I can live with https://github.com/bitcoin/bitcoin/pull/8438 for 0.13.1 but don't know about others opinions.
3672016-08-04T19:09:09 <sdaftuar> i think we can just tell users who want to downgrade to 0.13.0 after segwit activates to do a reindex?
3682016-08-04T19:09:27 <sdaftuar> they'll end up redownloading blocks, without witnesses, but that seems fine
3692016-08-04T19:09:30 <luke-jr> sipa: I care only to the extent that it shouldn't make a "working" node that doesn't match consensus
3702016-08-04T19:09:32 <sdaftuar> kind of a weird case to try to optimize
3712016-08-04T19:09:45 <wumpus> agree with luke-jr - it should give a clear error
3722016-08-04T19:09:49 <luke-jr> ie, it should give a hard error or reindex or something
3732016-08-04T19:09:54 <wumpus> it should not seem to work, but if it requires a reindex that's fine
3742016-08-04T19:10:04 <jonasschnelli> sdaftuar: Yes. I think this would be good. I don't think we need to cover the downgrade case.
3752016-08-04T19:10:05 <sipa> luke-jr: i think the only risk (but i haven't tried) is that it either works fine or crashes
3762016-08-04T19:10:11 <gmaxwell> Loss of #8438 is unfortunate but if including it would mean delaying the release I don't think it would be good to do so.
3772016-08-04T19:10:15 <sipa> luke-jr: the UTXO set is identical across the two
3782016-08-04T19:10:42 <luke-jr> I suggest someone should try it before final 0.13.0
3792016-08-04T19:10:53 <luke-jr> probably not difficult using testnet?
3802016-08-04T19:10:56 <sdaftuar> sipa: i guess its somewhat unfortunate that it will seem to work fine.
3812016-08-04T19:10:57 <sipa> luke-jr: ack
3822016-08-04T19:11:00 <gmaxwell> it can be tested by changing the testnet parameters.
3832016-08-04T19:11:10 <sipa> detecting this situation is not hard, btw
3842016-08-04T19:11:24 <sdaftuar> oh because 0.13.1 will use OPT_WITNESS?
3852016-08-04T19:11:27 *** pmienk has quit IRC
3862016-08-04T19:11:32 <sipa> sdaftuar: yes
3872016-08-04T19:12:03 <sdaftuar> hm so maybe we should add code then to look for that, hmm
3882016-08-04T19:12:16 <sipa> it's very last minute though...
3892016-08-04T19:12:23 <sdaftuar> i agree. and seemingly not that important
3902016-08-04T19:12:25 <sipa> i wish we thought of this before
3912016-08-04T19:12:35 <sipa> but i don't think it's worth holding up the release for
3922016-08-04T19:12:56 <luke-jr> it's trivial to test I think; if everyone else is too busy, I will try to do it today
3932016-08-04T19:13:02 <wumpus> gmaxwell: it would mean doing another rc, we could do final next week
3942016-08-04T19:13:06 *** fengling has quit IRC
3952016-08-04T19:13:58 <gmaxwell> that woudl also allow adding segwit downgrade protection sipa is currently discussing. (should be 3loc or so)
3962016-08-04T19:14:10 <wumpus> I don't know if it is that critical though, at some point we should just make the cut and stop slipping
3972016-08-04T19:14:32 <wumpus> yes that is true
3982016-08-04T19:15:06 * sipa notes that we're only 3 days past the date in https://github.com/bitcoin/bitcoin/issues/7679
3992016-08-04T19:15:36 <sipa> ideally deadlines don't slip, but iirc we're much more on track than for earlier major releases
4002016-08-04T19:15:37 <jonasschnelli> Yes. Maybe https://github.com/bitcoin/bitcoin/pull/8438 + SW0.13 downgrade compatibility is worth a week delay
4012016-08-04T19:15:40 <wumpus> yes, we've caught up a bit with the rc1 slip by doing a fast rc phase
4022016-08-04T19:15:48 <GitHub107> [bitcoin] luke-jr opened pull request #8458: [0.13] release notes: remove bad advice to switch to blockmaxweight prematurely (master...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8458
4032016-08-04T19:15:51 <btcdrak> 0.13.1 shouldnt be too far behind at least, but my preference is to include it and do another rc
4042016-08-04T19:15:54 <wumpus> note that I planned amonth for the rc1 phase
4052016-08-04T19:15:59 <wumpus> eh for the rc phase
4062016-08-04T19:16:31 <wumpus> well the downgrade protection cna't be postponed to 0.13.1
4072016-08-04T19:16:34 <wumpus> that'd defeat the point
4082016-08-04T19:16:38 <wumpus> otherwise that'd be my preference
4092016-08-04T19:16:45 <luke-jr> 8458 also mentions an idea I had for a 3-liner to make blockmaxsize perform identical to blockmaxweight, if we do another rc.. if that's desired, someone please say so and I'll do it now
4102016-08-04T19:17:01 <sipa> luke-jr: i think you included a few commits too many
4112016-08-04T19:17:01 <wumpus> yes now everyone starts with last minute ideas
4122016-08-04T19:17:02 <wumpus> great
4132016-08-04T19:17:11 <luke-jr> oh crap, I made it against master
4142016-08-04T19:17:34 <GitHub168> [bitcoin] luke-jr closed pull request #8458: [0.13] release notes: remove bad advice to switch to blockmaxweight prematurely (master...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8458
4152016-08-04T19:17:38 <gmaxwell> luke-jr: nah, something changing transaction selection.. not a good thing now.
4162016-08-04T19:17:41 <luke-jr> wumpus: well, it's trivial and probably unnecessary; fine if we don't do it
4172016-08-04T19:18:28 <wumpus> #action check if downgrade protection is really needed, or whether it already fails
4182016-08-04T19:18:52 <GitHub10> [bitcoin] luke-jr opened pull request #8459: [0.13] release-notes: Do not encourage changing blockmaxsize to blockmaxweight (0.13...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8459
4192016-08-04T19:19:40 <wumpus> other topics?
4202016-08-04T19:19:59 <cfields> oh
4212016-08-04T19:20:29 <sipa> segwit mempool malleability dos (#8279)
4222016-08-04T19:20:33 <cfields> (sec, someone else feel free to go ahead)
4232016-08-04T19:20:52 <wumpus> #topic segwit mempool malleability dos
4242016-08-04T19:21:51 <wumpus> wasn't that supposed to be solved in #8312?
4252016-08-04T19:21:57 <sdaftuar> no, it was only solved for 0.13.0
4262016-08-04T19:22:01 *** pmienk has joined #bitcoin-core-dev
4272016-08-04T19:22:04 <sdaftuar> we need to decide what to do in our first segwit release
4282016-08-04T19:22:08 <sipa> so i suggested removing the "transaction failure purely due to witness does not cause rejection cache entry"
4292016-08-04T19:22:42 <sipa> with the rationale that all it does it prevent an attacker from hiding a valid transaction from you in some cases
4302016-08-04T19:23:04 <sipa> but it doesn't prevent it entirely (they can announce and just never send the transaction)
4312016-08-04T19:23:35 <sipa> sdaftuar notes that the mempool malleability attack only needs a short lived connection, while the never send tx data attack needs a persistent one
4322016-08-04T19:23:53 <sdaftuar> and it needs more than one persistent one -- you need several, as we retry tx download from other peers
4332016-08-04T19:24:18 <sipa> sdaftuar: rejection cache is also temporary, but a node won't just re-request...
4342016-08-04T19:24:31 <morcos> i think i'm coming around to the idea of full verification of all txs
4352016-08-04T19:24:39 <gmaxwell> morcos: hah
4362016-08-04T19:24:51 <BlueMatt> was there rationale to inv'ing with txid instead of wtxid for segwit nodes?
4372016-08-04T19:25:31 <BlueMatt> (just noting that wtxid would be Keep The Same Behavior As Pre SegWit (tm))
4382016-08-04T19:26:38 <sipa> BlueMatt: duplicating a lot of logic (mempool, orphan, caches, ...), and causes at least a potential doubling anyway (you could be inved the same tx from a pre-segwit and post-segwit node once with txid and once with wtxid, without being able to tell they're the same)
4392016-08-04T19:27:24 <gmaxwell> also in the long term, the high malleability of witnesses would let an attacker waste lots of bandwidth. with nodes relaying different witness versions of the same txn among each other.
4402016-08-04T19:27:42 <BlueMatt> sipa: if you're inved a tx with a witness from a pre-segwit node we get a double anyway since its garbage to us
4412016-08-04T19:28:19 <BlueMatt> gmaxwell: same is true for scriptSigs...up to IsStandard limits (which could, in fact, be more easily enforced on witnesses)
4422016-08-04T19:28:22 <sdaftuar> BlueMatt: that's true but shouldn't happen, as pre-segwit nodes shouldn't be accepting segwit transactions unless they're running with an unusual policy
4432016-08-04T19:28:29 <sipa> also, if you have a tx with malleable witness (say, op_drop argument), nodes on the network could modify the witness without invalidating, and you wouldn't even be able to tell you already had the transaction before download
4442016-08-04T19:28:59 <sipa> and you couldn't ban them for it, because they're all valid transactions
4452016-08-04T19:30:00 <gmaxwell> BlueMatt: the kind of isstandard restriction against malleability only works great for limited classes of transactions, at least in the long term that isn't great.
4462016-08-04T19:30:10 <BlueMatt> I'm aware
4472016-08-04T19:30:18 <sipa> a solution is inving with both txid and wtxid... but if we go that way, we should also adds resource information to all invs (fees, size, sigops, ...)
4482016-08-04T19:30:35 <BlueMatt> sipa: I was about to say that...seems like a real solution is inving both...
4492016-08-04T19:30:41 <morcos> aren't we approachign the size of the tx at that point
4502016-08-04T19:31:04 <sipa> morcos: certainly within an order of magnitude
4512016-08-04T19:31:07 <BlueMatt> gmaxwell: but IsStandard is allowed to serve the same purpose as always - enforce reasonable limits to ensure code sanity until we've explored edge cases thouroughly
4522016-08-04T19:31:20 <gmaxwell> the txid is within an order of magnitude. :P
4532016-08-04T19:31:30 <sdaftuar> sipa: i think we might we just end up overfitting current policy rules by adding resource information
4542016-08-04T19:31:32 <gmaxwell> (for the median size)
4552016-08-04T19:31:50 <sipa> sdaftuar: 'overfitting' ?
4562016-08-04T19:31:51 <gmaxwell> but future mempool sync these sizes will matter less.
4572016-08-04T19:32:03 <gmaxwell> sdaftuar: feerate is pretty fundimental, however.
4582016-08-04T19:32:04 <sdaftuar> ie policy will change, and the information will be insufficient
4592016-08-04T19:32:08 <gmaxwell> I think including sigops would be dumb.
4602016-08-04T19:32:22 <sdaftuar> gmaxwell: yes, but already handled with less bandwidth by feefilter
4612016-08-04T19:32:29 <gmaxwell> if sigops really matter, something is wrong.
4622016-08-04T19:32:48 <gmaxwell> sdaftuar: indeed. feefilter makes it implicit.
4632016-08-04T19:32:53 <sipa> well, ok... we could send size and fee
4642016-08-04T19:33:05 <sipa> but that's not much better than making feefilter mandatory
4652016-08-04T19:33:12 <sipa> except slightly more flexible
4662016-08-04T19:33:20 <sipa> and sending two hashes is annoying
4672016-08-04T19:33:24 <gmaxwell> we're in the weeds for this right now.
4682016-08-04T19:33:31 <sipa> agree
4692016-08-04T19:33:45 <sipa> i think there is no simple clear cut solution for this
4702016-08-04T19:34:08 <gmaxwell> if we're doing set recon it doesn't really matter that much how long the identifiers are.
4712016-08-04T19:34:16 <sipa> but that's much further out
4722016-08-04T19:34:20 <BlueMatt> if inv'ing both hashes werent stupid for bandwidth, Id say that was a pretty great solution
4732016-08-04T19:34:29 <BlueMatt> true
4742016-08-04T19:34:57 <gmaxwell> sipa: depends on how long it takes me to convince you to implement the relevant number theory code. :P
4752016-08-04T19:35:52 <gmaxwell> In any case, the witnessID really doesn't matter for much of anything except rejection here.
4762016-08-04T19:36:00 <sipa> alternative idea: make feefilter mandatory for segwit, and just disable rejectioncache...
4772016-08-04T19:36:16 <sipa> rejectioncache only helps in practice against repeated announcements of transactions below your threshold
4782016-08-04T19:36:28 <sipa> it's not a protection against attacks
4792016-08-04T19:38:01 <sdaftuar> hm, not a bad idea
4802016-08-04T19:38:03 <luke-jr> feefilter isn't even used by default last I knew? (because there is no min fee until the mempool fills)
4812016-08-04T19:38:15 <sipa> luke-jr: good point
4822016-08-04T19:38:40 <BlueMatt> damn, mem^H^H^Hdiskpool was too late :(
4832016-08-04T19:38:47 <morcos> i'm all for making fee filter mandatory, if i'd known people would have liked it this much, we should have designed it that way from teh beginning
4842016-08-04T19:39:06 <morcos> i'm a bit worried about removing the rejection cache entirely
4852016-08-04T19:39:16 <gmaxwell> luke-jr: there is a minrelayfee.
4862016-08-04T19:39:27 <gmaxwell> Do we not feefilter on that?
4872016-08-04T19:39:29 <sdaftuar> gmaxwell: but we let in free transactions still
4882016-08-04T19:39:35 <gmaxwell> oh right.
4892016-08-04T19:39:58 <morcos> anytime there is any policy difference between nodes (such as a change in minrelay fee change isDust) then you get txs bouncing aroudn the network between the sets of nodes with different policies
4902016-08-04T19:40:06 <gmaxwell> full validation and distinguishing why rejection happened would help.
4912016-08-04T19:40:11 <morcos> i think its nice to have a sort of protection against that
4922016-08-04T19:42:12 <gmaxwell> we could just have one rejection filter per peer type.
4932016-08-04T19:42:25 <gmaxwell> e.g. rejection filter for non-sw peers and a rejection filter for sw peers.
4942016-08-04T19:43:03 <sdaftuar> with sw peers using wtxid invs?
4952016-08-04T19:43:30 <sipa> sdaftuar: still not enough... you need to be able to tell whether you already have another version of the same tx
4962016-08-04T19:43:35 <sipa> even with only sw peers
4972016-08-04T19:43:58 <gmaxwell> +full validation.
4982016-08-04T19:44:39 *** jtimon has joined #bitcoin-core-dev
4992016-08-04T19:44:44 <sdaftuar> sipa: i don't see why that's needed, any more than we have today with not knowing a tx is a double-spend before processing
5002016-08-04T19:45:50 <sipa> sdaftuar: someone connects to a 1000 nodes on the network, and relays a different version of the same valid transaction to each
5012016-08-04T19:45:59 <sipa> sdaftuar: now you potentially need to download 1000 transactions
5022016-08-04T19:46:14 <sipa> only one of which pays fees
5032016-08-04T19:46:20 <morcos> proposal: make feefilter mandatory. fully validate txs so we can punish peers who send us invalid stuff. don't put any witness tx in the rejection cache. then evaluate how useful rejection cache continues to be or whether we have policy violating segwit txs bouncing around
5042016-08-04T19:46:21 <sdaftuar> so you mean a 3rd party uses signature malleability to do this?
5052016-08-04T19:46:32 <sdaftuar> because the tx originator can already do that
5062016-08-04T19:46:59 <sipa> sdaftuar: right, the distinction isn't all that big
5072016-08-04T19:47:34 <sipa> morcos: i like that... but i think it's a big change for 0.13.1
5082016-08-04T19:47:34 <gmaxwell> the distinction though is that an attacker doing it pays fees, eventually runs out of funds, vs an attacker doing it to other peoples' txn does not ever run out of funds.
5092016-08-04T19:48:02 *** d_t has joined #bitcoin-core-dev
5102016-08-04T19:48:10 <morcos> sipa: i think if we start with " don't put any witness tx in the rejection cache" then we'll be ok
5112016-08-04T19:48:27 <sipa> morcos: ack
5122016-08-04T19:48:32 <morcos> we can see how easy and short he other 2 are
5132016-08-04T19:50:18 <wumpus> that concludes the topic for this meeting?
5142016-08-04T19:50:27 <wumpus> any other topic proposals? cfields?
5152016-08-04T19:50:29 <NicolasDorier> for information, I created ##libconsensus bikeshedding room about how to handle libconsensus for anybody interested.
5162016-08-04T19:50:48 <cfields> NicolasDorier: haha, i was just about to paste a blurb for that
5172016-08-04T19:51:06 <NicolasDorier> aha I just woke up for that, will go back bed :D
5182016-08-04T19:51:22 <instagibbs> I have to leave now, but just letting you know salvage is finding lots of "extra" keys vs keys actually in wallet. *shrug*
5192016-08-04T19:52:02 <cfields> NicolasDorier and I discussed libconsensus a bit this weekend. We're hoping to discuss amongst ourselves, come up with some goals, and present them clearly for easier review
5202016-08-04T19:52:12 <morcos> +100
5212016-08-04T19:52:16 <cfields> jtimon: ^^
5222016-08-04T19:52:25 <wumpus> #topic libconsensus
5232016-08-04T19:52:37 <cfields> that was it :)
5242016-08-04T19:52:54 <NicolasDorier> wumpus: we have not started the bikeshedding yet, expect longer fight about it soon :p
5252016-08-04T19:53:08 <luke-jr> NicolasDorier: IMO just discuss it here
5262016-08-04T19:53:14 <luke-jr> way too many channels already
5272016-08-04T19:53:31 <NicolasDorier> the reason I prefer a separate channel is so we can keep history and review it more easily
5282016-08-04T19:53:46 <wumpus> it's not like this channel is very busy\
5292016-08-04T19:53:47 <NicolasDorier> things said here get lost quickly enough in the sea of discussion
5302016-08-04T19:54:25 <wumpus> that always happens on IRC, if you want discussions with good history/memory then it may be better to use a different discussion mechanism, or keep summaries or such
5312016-08-04T19:54:36 <sipa> i think having a separate place to 'form' a proposal makes sense
5322016-08-04T19:55:00 <luke-jr> #bitcoin-dev is also fairly quiet
5332016-08-04T19:55:08 <sipa> involving the whole world in a design rarely leads to something useful
5342016-08-04T19:55:19 *** cryptapus has quit IRC
5352016-08-04T19:55:27 <jtimon> from what I talked with NicolasDorier in previous times, the current goal is to complete a verifyBlock without necessarily exposing it in libconsensus at first
5362016-08-04T19:55:28 <wumpus> that's true, as long as you can get the people you want to pay attention to join it's fine
5372016-08-04T19:55:41 <wumpus> sometimes it's good to not have too many people there
5382016-08-04T19:55:51 <wumpus> but speaking for myself, I'm already in so many channels, I have a hard time following more
5392016-08-04T19:55:52 <morcos> to be clear, the design will be presented to the bigger group for feedback and not set in stone
5402016-08-04T19:55:57 <btcdrak> yeah ack on limiting channel proliferation, also it is more open in a logged channel
5412016-08-04T19:56:34 <morcos> i don't plan on joining the libconsensus subgroup, but i think having a focused small group will make progress actually happen
5422016-08-04T19:56:37 <BlueMatt> I'm with wumpus...too many channels these days (not that I've been paying enough attention to have much of a voice, but still)
5432016-08-04T19:56:43 <wumpus> then again that's up to you, doesn't need to be a discussion topic here to decide onthat.
5442016-08-04T19:56:48 <jtimon> I don't think creating a new channel or not is going to be important either way...
5452016-08-04T19:56:59 <cfields> morcos: sure. doesn't matter to me where the discussion takes place, just hoping to organize the discussion/planning a bit.
5462016-08-04T19:57:03 <wumpus> any other topics? 4 minutes to go
5472016-08-04T19:57:14 <sipa> i'm in favor of having it in a separate channel because i prefer not to see all discussions around it before there is clean design :)
5482016-08-04T19:57:33 <NicolasDorier> bikeshedding about the creation of the channel libconsensus announce the color of the future bikeshedding on the actual code ;)
5492016-08-04T19:57:40 <wumpus> NicolasDorier: exactly
5502016-08-04T19:57:47 <wumpus> let's stop that
5512016-08-04T19:57:49 <cfields> heh
5522016-08-04T19:57:50 <sipa> haha
5532016-08-04T19:58:01 <sipa> 3 minutes
5542016-08-04T19:58:17 <jtimon> cfields: NicolasDorier if you can share the goals
5552016-08-04T19:58:23 <wumpus> looks like we're done
5562016-08-04T19:58:24 <wumpus> #endmeeting
5572016-08-04T19:58:24 <lightningbot> Meeting ended Thu Aug 4 19:58:24 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5582016-08-04T19:58:24 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-04-19.00.html
5592016-08-04T19:58:24 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-04-19.00.txt
5602016-08-04T19:58:24 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-04-19.00.log.html
5612016-08-04T19:59:48 <NicolasDorier> I have a code question: I'm working on a commit similar to one from jtimon, he is removing one check here https://github.com/jtimon/bitcoin/compare/remove-ism...consensus-post-remove-ism#diff-7ec3c68a81efff79b6ca22ac1f1eabbaL2353 about BIP30, does somebody know if it is actually safe to do so ?
5622016-08-04T20:00:23 <cfields> jtimon: i think everyone has different goals in mind. the point of organizing is to settle on something and work towards it. i can catch you up on our discussions this weekend, though ofc you've spent more time on it than anyone
5632016-08-04T20:01:10 <jtimon> cfields: well, a small summary of the "goals in common" or "easy to achieve" goals or something would be something
5642016-08-04T20:02:48 <NicolasDorier> jtimon: I think we still have also to discover what the goals in common are. Which is why I think we can discuss it in the channel. I guess if the three of us agree (plus anybody in the channel), there is good chance the rest agree too
5652016-08-04T20:02:52 *** telelvis1 has quit IRC
5662016-08-04T20:02:59 <morcos> NicolasDorier: See this comment from sdaftuar: https://github.com/bitcoin/bitcoin/pull/8391#issuecomment-237584871
5672016-08-04T20:03:31 <NicolasDorier> correct, I'll write a bip
5682016-08-04T20:04:33 <jtimon> NicolasDorier: I may not be so optimist, but fair enough, I mean, great. do you guys have time now to give me a little summary of your discussions so far now (in the other channel)?
5692016-08-04T20:04:44 <morcos> It's related. The point is once you are enforcing BIP34 then BIP30 is unnecessary except for historical violations. We're changing the rule to have BIP34 be enforced as of a certain height, however, it kind of requires that the chain be the same otherwise we dont' know what the historical violations are or might be
5702016-08-04T20:04:58 <NicolasDorier> yes, I will jtimon, but later I'll go back bed soon (5am here)
5712016-08-04T20:05:12 <jtimon> yeah, I say so in my commit, it is unnecessary because we're not using ISM anymore
5722016-08-04T20:06:19 <jtimon> oh, no worries, another time will be fine
5732016-08-04T20:06:37 *** gabridome has joined #bitcoin-core-dev
5742016-08-04T20:07:00 <cfields> jtimon: same, in the middle of several things atm. maybe some time tomorrow?
5752016-08-04T20:07:14 <jtimon> sure, no problem
5762016-08-04T20:07:55 <NicolasDorier> morcos: so basically we could remove BIP30 altogether as this is unlikely another chain manage to catch up the amount of work of the current one
5772016-08-04T20:08:36 <sipa> isn't there some interaction between BIP30 and the no-overwrite optimization in coinscache?
5782016-08-04T20:08:49 <sipa> which needs a BIP30 check during IBD
5792016-08-04T20:09:23 <NicolasDorier> mmh I think I won't make any change about it after all... I'm not confident of this thing
5802016-08-04T20:09:25 <morcos> NicolasDorier: yeah we need it on IBD
5812016-08-04T20:09:31 <morcos> hmm this brings up a kind of good point
5822016-08-04T20:09:44 *** fengling has joined #bitcoin-core-dev
5832016-08-04T20:09:47 <morcos> you can't remove the BIP34Hash unless you are going to checkpoint the chain at that point
5842016-08-04T20:10:42 <NicolasDorier> ok, so I will not touch it
5852016-08-04T20:10:49 *** pmienk has quit IRC
5862016-08-04T20:11:09 <jtimon> you cannot remove it completely, but when you use bip34 you don't need to do it (this is current behaviour)
5872016-08-04T20:11:28 <morcos> jtimon: no, when you use BIP34 on the existing BIP34 hash then you dont' need to do it
5882016-08-04T20:11:46 <morcos> if you activated BIP34 at the same height on a different chain, it would be unclear whether yous till needed to do BIP30
5892016-08-04T20:11:50 <jtimon> morcos: only one block?
5902016-08-04T20:11:57 <morcos> depends on the status of historical violations on that chain
5912016-08-04T20:12:01 <morcos> no on all future blocks
5922016-08-04T20:13:29 <jtimon> https://github.com/jtimon/bitcoin/commit/273e27bd0c086f5ba20cebc2f5ec9e24f9d79015
5932016-08-04T20:13:31 <morcos> i can't remember off the top of my head, but if in an alternate chain you spent coinbase A before you generate coinbase A' then you activated BIP34, then you still need BIP30 to make sure the spend of A' doesn't conflict with the spend of A
5942016-08-04T20:13:49 <morcos> but in the BIP34hash chain we know that didn't happen
5952016-08-04T20:13:50 <jtimon> do you think that commit is incorrect after removing ISM?
5962016-08-04T20:14:19 <morcos> jtimon: its incorrect in that it'll be broken code on a mainnet chain that doesn't contain BIP34hash
5972016-08-04T20:14:26 *** fengling has quit IRC
5982016-08-04T20:14:32 <morcos> so who knows what happens if someone feeds you such a chain on startup
5992016-08-04T20:15:07 <jtimon> I think it will only fail if we reorg below BIP34Height (227931)
6002016-08-04T20:15:13 <morcos> oh wait
6012016-08-04T20:15:46 <morcos> maybe because BIP30 is enforced for everythign except those two exceptions you're ok
6022016-08-04T20:15:49 <jtimon> and what we have now, if it reorgs that long, without code for ISM...what? bip34 is going to be activated at that height no matter what
6032016-08-04T20:15:55 *** MarcoFalke has left #bitcoin-core-dev
6042016-08-04T20:16:17 <jtimon> well, I wouldn't call them exceptions
6052016-08-04T20:17:02 <jtimon> pindexBIP34height will only be NULL if pindex->pprev->GetAncestor(227931) returns null
6062016-08-04T20:17:42 *** JackH_ has joined #bitcoin-core-dev
6072016-08-04T20:18:01 <jtimon> what is doing now is that if you are above that height and the block you activated bip34 in is 227931, then don't enforce bip30 since bip34 is enforced
6082016-08-04T20:19:11 <jtimon> in a reorg that deep, if it was activated with another block, then bip30 will be checked always regardless of bip34 activation (no optimization, never)
6092016-08-04T20:19:12 <morcos> jtimon: i honestly don't think its worth doing. but if you really want to, i will take the time to think about it. there are a lot of issues, down to when you flush your cache. but please make an actual PR for me to review that other people also want to merge
6102016-08-04T20:19:41 <jtimon> with my suggested change, it would always do the optimization after bip34 activation height, even after such a long reorg
6112016-08-04T20:20:22 <jtimon> morcos: absolutely, no problem
6122016-08-04T20:20:38 *** Ylbam has joined #bitcoin-core-dev
6132016-08-04T20:21:22 <morcos> jtimon: ok, i think i got the problem
6142016-08-04T20:21:42 <jtimon> well, if you tell me now I won't open the PR :)
6152016-08-04T20:21:47 <morcos> imagine that you reorg to height 90000 (or are just fed an alternate chain on startup)
6162016-08-04T20:22:09 <morcos> ah shoot....
6172016-08-04T20:22:10 <morcos> nm
6182016-08-04T20:22:23 <morcos> wait
6192016-08-04T20:22:24 <morcos> yes
6202016-08-04T20:22:25 <morcos> thats it
6212016-08-04T20:22:31 <morcos> so confusing
6222016-08-04T20:22:44 <jtimon> let's do one thing at a time, yep, you reorg to 9000 or you fed an alternate chain?
6232016-08-04T20:23:03 <morcos> either, same affect you start processing different blocks starting at 90000
6242016-08-04T20:23:05 <jtimon> think the worse case: you reorg to block 1
6252016-08-04T20:23:17 *** pmienk has joined #bitcoin-core-dev
6262016-08-04T20:23:27 <morcos> thats after coinbase A was created but before its duplicate A' was created
6272016-08-04T20:23:32 <morcos> now you spend coinbase A
6282016-08-04T20:24:13 <jtimon> bip 30 is checked before bip34 always except the exceptions
6292016-08-04T20:24:29 <jtimon> after bip34 activation, it is no longer necessary
6302016-08-04T20:24:35 <morcos> then you create coinbase A' (allowed b/c it doesn't violate BIP30 , A is spent, and BIP34 is not active yet)
6312016-08-04T20:24:49 <morcos> now you activate BIP34 at height 227931
6322016-08-04T20:25:02 *** JackH_ has quit IRC
6332016-08-04T20:25:09 <morcos> then you can spend A' and create the same txid as your spend of A b/c you aren't enforcing BIP30 any more
6342016-08-04T20:25:18 <jtimon> yes, from now on you can stop checking bip30 in new blocks
6352016-08-04T20:25:24 <morcos> no you can't
6362016-08-04T20:25:42 <morcos> spending A' would be allowed and would create a duplicate txid of the spend of A
6372016-08-04T20:27:06 <jtimon> mhmm, whay they cannot today?
6382016-08-04T20:27:10 <jtimon> why
6392016-08-04T20:27:41 <morcos> because A' the coinbase was created before A was spent
6402016-08-04T20:27:50 <morcos> so A' overwrote A already
6412016-08-04T20:28:15 <morcos> but if in an alternate history you spent A to B first
6422016-08-04T20:28:21 <jtimon> doesn't include the height make it very difficult to collide with coinbases before 227931 ?
6432016-08-04T20:28:23 <morcos> then you have to worry about B' and B
6442016-08-04T20:28:45 <jtimon> instead of A'
6452016-08-04T20:28:59 <jtimon> think of all the coinbases before 227931
6462016-08-04T20:29:29 <jtimon> no? you don't want the same as neither of those
6472016-08-04T20:29:39 <morcos> you can try this on regtest.. enforce BIP30 only up to height 100 and BIP34 only starting at height 100. create some coinbases, spend them and then create duplicates before 100.
6482016-08-04T20:29:42 <jtimon> that's with or without a reorg
6492016-08-04T20:29:44 <morcos> then after 100 make them colide
6502016-08-04T20:29:56 <Chris_Stewart_5> Is there a simple way to serialize a CKey? Doesn't seem to have the SERIALIZE_METHODS macro
6512016-08-04T20:30:44 <jtimon> morcos: yeah, you could "attack regtest" that way...
6522016-08-04T20:31:07 <morcos> well if you change the code, someone could feed you a messed up mainnet chain that way
6532016-08-04T20:31:09 <sipa> Chris_Stewart_5: historically, it's converted from/to a CPrivKey for serialization
6542016-08-04T20:31:13 <jtimon> I thought we were talking about mainnet
6552016-08-04T20:32:24 <morcos> jtimon: yes so on mainnet, you'd have to have a REALLY deep reorg, below 227931
6562016-08-04T20:32:49 <Chris_Stewart_5> sipa: Is there a simple utility function serialize CPrivKey? Can it just be passed to HexStr?
6572016-08-04T20:33:05 <morcos> or if somoene just fed you an alternate low work chain then i'm not really sure what would happen, its possible that your utxo could get into a messed up state than you wouldn't be able to fix when you found out about the real chain
6582016-08-04T20:33:17 <jtimon> and then a node without my change would always check bip30, even after bip34 activation, is that the desired behaviour?
6592016-08-04T20:33:30 <sipa> Chris_Stewart_5: CKey also has begin() and end(), to it can be passed to HexStr directly
6602016-08-04T20:33:39 <sipa> Chris_Stewart_5: and has a constructor that takes a byte array
6612016-08-04T20:33:50 <jtimon> my node would not check bip30 after bip34, even after the reorg
6622016-08-04T20:34:48 <morcos> jtimon: yes you can either always check BIP30 even after BIP34, or you can examine the chain you're on pre BIP34 and decide whether you can now skip BIP30 checks (which is what we decided to do with mainnet, but requires manual intervention)
6632016-08-04T20:34:56 <morcos> are you opposed to leaving in the BIP34 hash
6642016-08-04T20:35:14 <morcos> checking BIP30 is exteremely slow
6652016-08-04T20:35:38 <morcos> that's why we put in the ability to skip it
6662016-08-04T20:36:58 <jtimon> so, yes, theoretically always checking bip30 after bip34 has certain risk if there's that reorg...but aren't we screwed if that happens anyway?
6672016-08-04T20:37:16 <jtimon> like, really screwed
6682016-08-04T20:37:50 <jtimon> I don't know, maybe it's not worth it
6692016-08-04T20:38:03 <Chris_Stewart_5> sipa: Thanks
6702016-08-04T20:39:08 <jtimon> the advantages are code simplification and a slight optimization (really no need to call GetAncestor if you don't care about the hash), and keep the optimization in case of pre-bip34 reorg, which is arguably a disadvantage
6712016-08-04T20:39:35 <jtimon> no, not opposed, removing it is just a suggestion
6722016-08-04T20:40:46 <jtimon> if we knew we weren't doing it, we could have made https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5 without bip34 directly in #8391...
6732016-08-04T20:41:02 <jtimon> now I'm afraid the right time to do that will be...never
6742016-08-04T20:41:07 <morcos> jtimon: i think the issue is less a reorg than that someone might feed you an alternate chain on startup and get your utxo into a permanently messed up state b/c you don't know how to reorg back
6752016-08-04T20:41:37 <jtimon> oh, I see
6762016-08-04T20:41:55 <morcos> i'm not positive that would happen, but seems more likely than not, and also seems like it could be affected by future changes to the way coins work that we might not anticipate
6772016-08-04T20:41:55 <jtimon> yeah, makes sense, thanks
6782016-08-04T20:44:14 <jtimon> yeah, I wasn't properly thinking about an isolated node doing initial synchornization, that's what you meant by fed up with the wrong chain from the beginning, sorry
6792016-08-04T20:44:44 <jtimon> nah, better to avoid that risk, definitely not worth it
6802016-08-04T20:44:51 <jtimon> thansk
6812016-08-04T20:44:52 <morcos> jtimon: yeah
6822016-08-04T20:44:54 <morcos> sure
6832016-08-04T20:47:34 <jtimon> well, maybe the time for https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5 is whenever bip113 activation is simplified from bip9 in the same way
6842016-08-04T20:47:38 *** gabridome has quit IRC
6852016-08-04T20:48:59 <jtimon> or when/if we expose consensus::Params in libconsensus
6862016-08-04T20:49:27 <jtimon> anyway, that's another topic
6872016-08-04T20:49:39 <Chris_Stewart_5> sipa: When I serialize CPriv/CPub I get something that is larger than 32 bytes?
6882016-08-04T20:50:35 <sipa> Chris_Stewart_5: CPrivKey uses OpenSSL DER serialization... which is 300 bytes or so for a private key
6892016-08-04T20:50:41 <sipa> CPubKeys are 33 or 65 bytes
6902016-08-04T20:50:49 <sipa> CKey is internally 32 bytes + compression flag
6912016-08-04T20:52:18 <Chris_Stewart_5> ahh ok, that makes more sense. So basically CKey is the interface exposed inside of core... except for serialization. Something that could be implemented in a pull?
6922016-08-04T20:52:55 <sipa> well there isn't one single obvious serialization for CKey
6932016-08-04T20:55:52 <Chris_Stewart_5> Seems like the 32 byte serialization would be the intuitive one.. at least to me. Am I missing something here?
6942016-08-04T20:56:53 <Chris_Stewart_5> oh nvm i see what you are talking about now, since CKeys can be both priv and pubs right?
6952016-08-04T20:57:29 <sipa> no
6962016-08-04T20:57:42 <sipa> CKey is a private key
6972016-08-04T20:57:49 <sipa> but you need the compression flag too
6982016-08-04T20:58:31 <sipa> and there is no deserialize because we use secure memory for private keys where possible
6992016-08-04T21:02:29 *** TomMc has joined #bitcoin-core-dev
7002016-08-04T21:08:55 <NicolasDorier> jtimon, I will soon make a PR similar to https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5 along with another change to parametize buriedsf height for regtest
7012016-08-04T21:10:19 <jtimon> NicolasDorier: cool, but I believe the right time was in your PR, at least with the new ones if you didn't wanted to touch bip34
7022016-08-04T21:11:03 <NicolasDorier> jtimon: I disagree, my PR was making a "big" consensus change so I wanted to keep it as simple as possible to review
7032016-08-04T21:11:13 *** fengling has joined #bitcoin-core-dev
7042016-08-04T21:11:28 <NicolasDorier> I wanted to be it merged the quickier I could so I can continue my work on libconsensus
7052016-08-04T21:11:39 <jtimon> although I won't oppose the refactor, of course, just worry that it will be less acceptable
7062016-08-04T21:12:16 <jtimon> how would using an array instead of two variables have been more complicated?
7072016-08-04T21:12:26 <jtimon> anyway, as said I won't oppose
7082016-08-04T21:12:34 *** Chris_Stewart_5 has quit IRC
7092016-08-04T21:13:15 <NicolasDorier> jtimon: I don't think it wil lbe less acceptable, this buried deployment stuff will be a BIP. In the future other SF will end up using the same structure
7102016-08-04T21:13:24 <NicolasDorier> anyway, I made two differents commit
7112016-08-04T21:13:40 <NicolasDorier> we can take one and not the other
7122016-08-04T21:13:51 <jtimon> NicolasDorier: yeah I guess the BIP is an opportunity to reorganize the struct
7132016-08-04T21:15:15 <jtimon> anyway, I'm suffering from premature worry about controversy, let's not discuss about whether something will be acceptable or not when we both want it
7142016-08-04T21:15:36 *** gabridome has joined #bitcoin-core-dev
7152016-08-04T21:16:06 *** fengling has quit IRC
7162016-08-04T21:20:56 *** gabridome has quit IRC
7172016-08-04T21:21:05 *** spudowiar has joined #bitcoin-core-dev
7182016-08-04T21:27:08 <GitHub193> [bitcoin] NicolasDorier opened pull request #8460: parametrize buried soft fork in regtest and refactor (master...buriedsf) https://github.com/bitcoin/bitcoin/pull/8460
7192016-08-04T21:27:35 *** gabridome has joined #bitcoin-core-dev
7202016-08-04T21:27:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
7212016-08-04T21:27:46 <NicolasDorier> jtimon: worrying about controversy create a meta controversy :D
7222016-08-04T21:28:21 <NicolasDorier> just created the PR
7232016-08-04T21:31:31 *** TomMc has quit IRC
7242016-08-04T21:33:17 *** gabridome has quit IRC
7252016-08-04T21:33:48 <jtimon> yeah, I'm revieweing it
7262016-08-04T21:34:59 *** gabridome has joined #bitcoin-core-dev
7272016-08-04T21:35:16 <jtimon> and looking at 8418 too
7282016-08-04T21:36:23 <jtimon> https://github.com/bitcoin/bitcoin/pull/8418/files#diff-c865a8939105e6350a50af02766291b7R981
7292016-08-04T21:36:40 <jtimon> .MineBlocksOnDemand() is starting too look like IsRegtest()
7302016-08-04T21:37:12 <GitHub92> [bitcoin] jlopp opened pull request #8461: document return value of networkhashps for getmininginfo RPC endpoint (master...rpcMiningHelp) https://github.com/bitcoin/bitcoin/pull/8461
7312016-08-04T21:37:39 *** gabridome has quit IRC
7322016-08-04T21:38:16 *** gabridome has joined #bitcoin-core-dev
7332016-08-04T21:43:11 *** gabridome has quit IRC
7342016-08-04T21:43:59 *** gabridome has joined #bitcoin-core-dev
7352016-08-04T21:44:24 *** TomMc has joined #bitcoin-core-dev
7362016-08-04T21:44:54 <jtimon> oh, it was RegTest() or Params().NetworkID() == CChainParams::REGTEST directly, never mind, it's been a while since 3824, thinking out loud
7372016-08-04T21:46:42 *** gabridome has quit IRC
7382016-08-04T21:50:44 *** gabridome has joined #bitcoin-core-dev
7392016-08-04T21:55:42 *** gabridome has joined #bitcoin-core-dev
7402016-08-04T21:59:11 <jtimon> NicolasDorier: in #8460, how do you modify a couple of them? -buriedsfparams=bip65:1351,bip66:1251 ?
7412016-08-04T21:59:29 <NicolasDorier> you repeat
7422016-08-04T21:59:35 <NicolasDorier> -buriedsfparams=bip65:1351 -buriedsfparams=bip66:1251
7432016-08-04T21:59:47 <jtimon> ok, thanks
7442016-08-04T22:02:04 <jtimon> https://github.com/bitcoin/bitcoin/pull/8418/files#r73610819
7452016-08-04T22:03:06 *** gabridome has left #bitcoin-core-dev
7462016-08-04T22:05:17 *** laurentmt has quit IRC
7472016-08-04T22:06:52 *** spudowiar has quit IRC
7482016-08-04T22:09:05 *** spudowiar has joined #bitcoin-core-dev
7492016-08-04T22:09:54 *** Lauda_ has joined #bitcoin-core-dev
7502016-08-04T22:10:48 *** Lauda_ has quit IRC
7512016-08-04T22:11:27 *** TomMc has quit IRC
7522016-08-04T22:12:26 *** Lauda_ has joined #bitcoin-core-dev
7532016-08-04T22:12:44 *** fengling has joined #bitcoin-core-dev
7542016-08-04T22:14:29 *** Lauda has quit IRC
7552016-08-04T22:14:35 *** Lauda_ is now known as Lauda
7562016-08-04T22:15:01 *** LaudaM has joined #bitcoin-core-dev
7572016-08-04T22:17:11 *** LaudaM has quit IRC
7582016-08-04T22:17:22 *** LaudaM has joined #bitcoin-core-dev
7592016-08-04T22:17:26 *** fengling has quit IRC
7602016-08-04T22:20:42 *** AaronvanW has quit IRC
7612016-08-04T22:23:30 *** randy-waterhouse has joined #bitcoin-core-dev
7622016-08-04T22:25:29 <NicolasDorier> jtimon: I think one bool is enough. fAllowOverwriteSoftforks which both BIP9 and buried SF use
7632016-08-04T22:27:34 *** TomMc has joined #bitcoin-core-dev
7642016-08-04T22:27:42 <jtimon> NicolasDorier: fine with me, sounds reasonable
7652016-08-04T22:27:56 <NicolasDorier> will add commit to my PR later
7662016-08-04T22:28:02 <jtimon> great
7672016-08-04T22:37:00 *** spudowiar has quit IRC
7682016-08-04T22:37:51 *** spudowiar has joined #bitcoin-core-dev
7692016-08-04T22:39:48 <jtimon> NicolasDorier: you are not removing BIP34Height BIP65Height and BIP66Height in Consensus::Params
7702016-08-04T22:41:17 <jtimon> you can leave:
7712016-08-04T22:41:17 <jtimon> /** Block hash at which BIP34 becomes active (for BIP30 optimization)*/
7722016-08-04T22:41:17 <jtimon> uint256 BIP34Hash;
7732016-08-04T22:42:14 *** Guyver2 has quit IRC
7742016-08-04T22:44:41 <NicolasDorier> oh
7752016-08-04T22:51:03 *** LaudaM is now known as random4343
7762016-08-04T22:51:12 *** random4343 is now known as LaudaM
7772016-08-04T22:52:15 *** LaudaM is now known as CatWoman
7782016-08-04T22:57:32 *** CatWoman has quit IRC
7792016-08-04T22:57:43 *** LaudaM has joined #bitcoin-core-dev
7802016-08-04T23:01:33 *** Giszmo has quit IRC
7812016-08-04T23:04:27 <sipa> does anyone know offhand where the last segwit transaction in the chain is?
7822016-08-04T23:04:30 <sipa> *testnet chain
7832016-08-04T23:04:32 *** molly has joined #bitcoin-core-dev
7842016-08-04T23:05:27 <sipa> i've reset the testnet chainparams for segwit to 0, and reconsiderblock/invalidateblock 100000 blocks, and it works fine
7852016-08-04T23:07:34 *** molz has quit IRC
7862016-08-04T23:13:43 *** fengling has joined #bitcoin-core-dev
7872016-08-04T23:18:26 *** fengling has quit IRC
7882016-08-04T23:27:09 *** molz has joined #bitcoin-core-dev
7892016-08-04T23:30:21 *** molly has quit IRC
7902016-08-04T23:39:19 *** d_t has quit IRC
7912016-08-04T23:45:22 <NicolasDorier> jtimon: I fixed the nit as well as added the commit with the allowSfOverride
7922016-08-04T23:48:59 *** belcher has joined #bitcoin-core-dev
7932016-08-04T23:50:56 <jtimon> NicolasDorier: tiny last nit https://github.com/bitcoin/bitcoin/pull/8460/files#r73622457
7942016-08-04T23:52:16 <NicolasDorier> jtimon: this is removed in later commits
7952016-08-04T23:52:50 <NicolasDorier> oups
7962016-08-04T23:52:52 <NicolasDorier> nop
7972016-08-04T23:54:00 <NicolasDorier> removed :)
7982016-08-04T23:54:30 <NicolasDorier> I did quite a lot of rebase to clean up the history. But now it should be stable
7992016-08-04T23:55:08 <jtimon> good work
8002016-08-04T23:56:52 <NicolasDorier> thanks, going to bed for real now (9am) :D
8012016-08-04T23:58:52 <jtimon> oh, sorry about that