12017-03-23T00:02:42 *** magicwund has joined #bitcoin-core-dev
22017-03-23T00:07:34 *** magicwund has quit IRC
32017-03-23T00:08:57 *** owowo has joined #bitcoin-core-dev
42017-03-23T00:21:43 *** Chris_Stewart_5 has quit IRC
52017-03-23T00:43:19 *** owowo has quit IRC
62017-03-23T00:44:21 <bitcoin-git> [bitcoin] tjps opened pull request #10059: [trivial] Removed one Boost usage and headers in util.cpp (master...tjps_boost) https://github.com/bitcoin/bitcoin/pull/10059
72017-03-23T00:53:24 <bitcoin-git> [bitcoin] jnewbery closed pull request #10055: [test] [POC] Stop and start bitcoind nodes asynchronously in functional tests (master...stopstartasync) https://github.com/bitcoin/bitcoin/pull/10055
82017-03-23T01:00:33 *** echonaut has quit IRC
92017-03-23T01:00:59 *** echonaut has joined #bitcoin-core-dev
102017-03-23T01:02:22 *** CubicEarth has quit IRC
112017-03-23T01:06:02 *** owowo has joined #bitcoin-core-dev
122017-03-23T01:06:02 *** owowo has joined #bitcoin-core-dev
132017-03-23T01:08:43 *** PRab has quit IRC
142017-03-23T01:10:25 <bitcoin-git> [bitcoin] achow101 opened pull request #10060: [RPC] Ensure an item exists on the rpcconsole stack before adding (master...fix-rpcconsole-empty-stack) https://github.com/bitcoin/bitcoin/pull/10060
152017-03-23T01:10:46 *** owowo has quit IRC
162017-03-23T01:11:19 *** PaulCape_ has joined #bitcoin-core-dev
172017-03-23T01:11:27 *** owowo has joined #bitcoin-core-dev
182017-03-23T01:12:10 *** PaulCapestany has quit IRC
192017-03-23T01:22:51 *** magicwund has joined #bitcoin-core-dev
202017-03-23T01:27:12 *** magicwund has quit IRC
212017-03-23T01:31:03 *** echonaut has quit IRC
222017-03-23T01:31:48 *** echonaut has joined #bitcoin-core-dev
232017-03-23T01:47:37 *** magicwund has joined #bitcoin-core-dev
242017-03-23T01:51:05 *** [Author] has joined #bitcoin-core-dev
252017-03-23T01:51:57 *** magicwund has quit IRC
262017-03-23T02:10:38 *** Giszmo has quit IRC
272017-03-23T02:10:51 *** Giszmo has joined #bitcoin-core-dev
282017-03-23T02:51:30 *** mol has quit IRC
292017-03-23T02:54:13 *** dodomojo has joined #bitcoin-core-dev
302017-03-23T02:55:14 *** dodomojo has joined #bitcoin-core-dev
312017-03-23T03:00:28 *** magicwund has joined #bitcoin-core-dev
322017-03-23T03:04:52 *** AaronvanW has quit IRC
332017-03-23T03:04:57 *** magicwund has quit IRC
342017-03-23T03:13:21 *** dodomojo_ has joined #bitcoin-core-dev
352017-03-23T03:15:22 *** dodomojo has quit IRC
362017-03-23T03:40:09 *** dodomojo_ has quit IRC
372017-03-23T03:43:07 *** CubicEarth has joined #bitcoin-core-dev
382017-03-23T03:49:10 *** blueyez has joined #bitcoin-core-dev
392017-03-23T03:54:46 *** magicwund has joined #bitcoin-core-dev
402017-03-23T03:55:03 *** harrymm has joined #bitcoin-core-dev
412017-03-23T03:55:45 *** moli has joined #bitcoin-core-dev
422017-03-23T04:03:23 *** chris200_ has joined #bitcoin-core-dev
432017-03-23T04:04:07 *** Ylbam has quit IRC
442017-03-23T04:05:52 *** chris2000 has quit IRC
452017-03-23T04:07:57 *** magicwund has quit IRC
462017-03-23T04:26:50 *** CubicEarth has quit IRC
472017-03-23T04:27:00 *** rafalcpp has quit IRC
482017-03-23T04:27:48 *** CubicEarth has joined #bitcoin-core-dev
492017-03-23T04:28:57 *** jtimon has quit IRC
502017-03-23T04:44:34 *** CubicEar_ has joined #bitcoin-core-dev
512017-03-23T04:44:42 *** CubicEarth has quit IRC
522017-03-23T04:46:17 *** CubicEar_ is now known as CubicEarth
532017-03-23T05:06:57 *** CubicEarth has quit IRC
542017-03-23T05:08:25 *** CubicEarthh has joined #bitcoin-core-dev
552017-03-23T05:09:19 *** CubicEarthh has quit IRC
562017-03-23T05:12:10 *** moli has quit IRC
572017-03-23T05:12:58 *** CubicEarthh has joined #bitcoin-core-dev
582017-03-23T05:17:25 <bitcoin-git> [bitcoin] tjps opened pull request #10061: [net] Added SetSocketNoDelay() utility function (master...tjps_nodelay) https://github.com/bitcoin/bitcoin/pull/10061
592017-03-23T05:39:13 *** kungfuant has joined #bitcoin-core-dev
602017-03-23T05:54:38 *** arubi_ has joined #bitcoin-core-dev
612017-03-23T05:56:43 *** arubi has quit IRC
622017-03-23T06:04:31 *** Giszmo has quit IRC
632017-03-23T06:05:07 *** afk11 has quit IRC
642017-03-23T06:11:04 *** afk11 has joined #bitcoin-core-dev
652017-03-23T06:13:03 *** [b__b] has quit IRC
662017-03-23T06:13:04 *** isle2983 has quit IRC
672017-03-23T06:13:05 *** murr4y has quit IRC
682017-03-23T06:13:06 *** xiangfu has quit IRC
692017-03-23T06:13:06 *** xiangfu has joined #bitcoin-core-dev
702017-03-23T06:13:08 *** [b__b] has joined #bitcoin-core-dev
712017-03-23T06:15:34 *** murr4y has joined #bitcoin-core-dev
722017-03-23T06:26:09 *** moli_ has joined #bitcoin-core-dev
732017-03-23T06:26:18 <bitcoin-git> [bitcoin] kallewoof opened pull request #10062: [net] Clean up the net.h file. (master...20170322-cleanup-net) https://github.com/bitcoin/bitcoin/pull/10062
742017-03-23T07:01:35 *** MarcoFalke has quit IRC
752017-03-23T07:03:05 *** instagibbs_ has quit IRC
762017-03-23T07:03:07 *** afk11 has quit IRC
772017-03-23T07:03:31 *** arubi_ has quit IRC
782017-03-23T07:03:31 *** wasi has quit IRC
792017-03-23T07:03:35 *** morcos has quit IRC
802017-03-23T07:04:15 *** afk11 has joined #bitcoin-core-dev
812017-03-23T07:04:28 *** wasi has joined #bitcoin-core-dev
822017-03-23T07:04:35 *** zxzzt has quit IRC
832017-03-23T07:04:36 *** xiangfu has quit IRC
842017-03-23T07:04:40 *** morcos has joined #bitcoin-core-dev
852017-03-23T07:04:42 *** MarcoFalke has joined #bitcoin-core-dev
862017-03-23T07:05:13 *** xiangfu has joined #bitcoin-core-dev
872017-03-23T07:05:22 *** zxzzt has joined #bitcoin-core-dev
882017-03-23T07:07:01 *** arubi has joined #bitcoin-core-dev
892017-03-23T07:07:23 *** instagibbs has joined #bitcoin-core-dev
902017-03-23T07:11:42 *** riemann has joined #bitcoin-core-dev
912017-03-23T07:18:26 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/02d64bd929c9...86f7d5b69bb7
922017-03-23T07:18:26 <bitcoin-git> bitcoin/master 97b8213 practicalswift: Fix parameter naming inconsistencies between .h and .cpp files...
932017-03-23T07:18:27 <bitcoin-git> bitcoin/master 86f7d5b Jonas Schnelli: Merge #10029: Fix parameter naming inconsistencies between .h and .cpp files...
942017-03-23T07:18:47 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #10029: Fix parameter naming inconsistencies between .h and .cpp files (master...fix-header-parameter-naming-inconsistencies) https://github.com/bitcoin/bitcoin/pull/10029
952017-03-23T07:19:12 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/86f7d5b69bb7...7b585cf70ec5
962017-03-23T07:19:12 <bitcoin-git> bitcoin/master c4a6929 Matt Corallo: Clarify assumptions made about when BlockCheck is called
972017-03-23T07:19:13 <bitcoin-git> bitcoin/master 7b585cf Jonas Schnelli: Merge #9558: Clarify assumptions made about when BlockCheck is called...
982017-03-23T07:19:22 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9558: Clarify assumptions made about when BlockCheck is called (master...2017-01-blockcheckeddocs) https://github.com/bitcoin/bitcoin/pull/9558
992017-03-23T07:27:43 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7b585cf70ec5...3568b30ca31d
1002017-03-23T07:27:44 <bitcoin-git> bitcoin/master 6d8fe35 Andrew Chow: 'help' rpc commands autocomplete...
1012017-03-23T07:27:44 <bitcoin-git> bitcoin/master 3568b30 Jonas Schnelli: Merge #9500: [Qt][RPC] Autocomplete commands for 'help' command in debug console...
1022017-03-23T07:28:11 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9500: [Qt][RPC] Autocomplete commands for 'help' command in debug console (master...help-rpc-autocomplete) https://github.com/bitcoin/bitcoin/pull/9500
1032017-03-23T07:36:08 *** magicwund has joined #bitcoin-core-dev
1042017-03-23T07:40:57 *** magicwund has quit IRC
1052017-03-23T07:44:48 *** BashCo has quit IRC
1062017-03-23T07:48:42 *** riemann has quit IRC
1072017-03-23T08:06:29 *** BashCo has joined #bitcoin-core-dev
1082017-03-23T08:14:21 *** moli_ has quit IRC
1092017-03-23T08:15:39 *** Victorsueca has joined #bitcoin-core-dev
1102017-03-23T08:21:37 *** Madars_ has quit IRC
1112017-03-23T08:22:08 *** juscamarena has quit IRC
1122017-03-23T08:22:51 *** Madars_ has joined #bitcoin-core-dev
1132017-03-23T08:30:27 *** juscamarena has joined #bitcoin-core-dev
1142017-03-23T08:33:55 *** moli_ has joined #bitcoin-core-dev
1152017-03-23T08:41:02 *** Ylbam has joined #bitcoin-core-dev
1162017-03-23T08:42:22 *** belcher has quit IRC
1172017-03-23T08:44:49 *** Evel-Knievel has joined #bitcoin-core-dev
1182017-03-23T08:48:03 *** CubicEarthh has quit IRC
1192017-03-23T08:52:27 *** belcher has joined #bitcoin-core-dev
1202017-03-23T09:09:16 *** riemann has joined #bitcoin-core-dev
1212017-03-23T09:38:10 *** udiWertheimer has joined #bitcoin-core-dev
1222017-03-23T09:47:44 *** idufohid has joined #bitcoin-core-dev
1232017-03-23T09:48:53 *** CubicEarthh has joined #bitcoin-core-dev
1242017-03-23T09:53:48 *** CubicEarthh has quit IRC
1252017-03-23T09:57:28 *** idufohid has quit IRC
1262017-03-23T09:57:36 *** rafalcpp has joined #bitcoin-core-dev
1272017-03-23T09:59:38 *** Guyver2 has joined #bitcoin-core-dev
1282017-03-23T10:01:57 *** udiWertheimer has quit IRC
1292017-03-23T10:03:49 *** go1111111 has quit IRC
1302017-03-23T10:06:01 *** idufohid has joined #bitcoin-core-dev
1312017-03-23T10:13:06 *** idufohid has quit IRC
1322017-03-23T10:39:39 <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/3568b30ca31d...dfef6b6af080
1332017-03-23T10:39:40 <bitcoin-git> bitcoin/master 72163d4 practicalswift: [tests] Remove unused and duplicate imports
1342017-03-23T10:39:40 <bitcoin-git> bitcoin/master 3897459 practicalswift: [tests] Remove unused variables
1352017-03-23T10:39:41 <bitcoin-git> bitcoin/master dfef6b6 MarcoFalke: Merge #10047: [tests] Remove unused variables and imports...
1362017-03-23T10:40:22 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10047: [tests] Remove unused variables and imports (master...remove-unused-python-imports) https://github.com/bitcoin/bitcoin/pull/10047
1372017-03-23T10:47:16 *** idufohid has joined #bitcoin-core-dev
1382017-03-23T10:49:39 *** CubicEarthh has joined #bitcoin-core-dev
1392017-03-23T10:51:44 *** AaronvanW has joined #bitcoin-core-dev
1402017-03-23T10:51:44 *** AaronvanW has joined #bitcoin-core-dev
1412017-03-23T10:52:52 *** idufohid has quit IRC
1422017-03-23T10:54:40 *** CubicEarthh has quit IRC
1432017-03-23T10:59:11 *** idufohid has joined #bitcoin-core-dev
1442017-03-23T10:59:43 *** NicolasDorier has quit IRC
1452017-03-23T11:03:58 *** idufohid has quit IRC
1462017-03-23T11:12:56 *** NicolasDorier has joined #bitcoin-core-dev
1472017-03-23T11:23:28 <bitcoin-git> [bitcoin] MarcoFalke pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/dfef6b6af080...a230b0588788
1482017-03-23T11:23:29 <bitcoin-git> bitcoin/master 94b528b Russell Yanofsky: [qa] Remove bumpfee.py get_change_address hack
1492017-03-23T11:23:29 <bitcoin-git> bitcoin/master e6b2963 Russell Yanofsky: [qa] Get rid of nondeterminism in bumpfee.py...
1502017-03-23T11:23:30 <bitcoin-git> bitcoin/master 1dfd64f Russell Yanofsky: [qa] Make bumpfee.py test function order consistent...
1512017-03-23T11:23:43 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9701: Make bumpfee tests less fragile (master...pr/bumpfee-fragile) https://github.com/bitcoin/bitcoin/pull/9701
1522017-03-23T11:46:29 *** shesek has quit IRC
1532017-03-23T11:50:28 <luke-jr> woo, sizefp code builds finally
1542017-03-23T11:51:00 <luke-jr> although it's still incomplete.. need a good way to detect the "no full size proofs on right sides of duplicate merkle link hashes"
1552017-03-23T11:51:35 <luke-jr> but I'd better get to bed so I can be up for the meeting :x
1562017-03-23T12:00:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1572017-03-23T12:02:01 *** d9b4bef9 has quit IRC
1582017-03-23T12:03:07 *** d9b4bef9 has joined #bitcoin-core-dev
1592017-03-23T12:03:58 *** shesek has joined #bitcoin-core-dev
1602017-03-23T12:04:18 *** jannes has joined #bitcoin-core-dev
1612017-03-23T12:18:52 *** magicwund has joined #bitcoin-core-dev
1622017-03-23T12:22:57 *** magicwund has quit IRC
1632017-03-23T12:53:22 *** magicwund has joined #bitcoin-core-dev
1642017-03-23T13:01:22 *** magicwund has quit IRC
1652017-03-23T13:06:50 *** kexkey has joined #bitcoin-core-dev
1662017-03-23T13:12:44 *** magicwund has joined #bitcoin-core-dev
1672017-03-23T13:15:05 *** isle2983 has joined #bitcoin-core-dev
1682017-03-23T13:17:14 *** magicwund has quit IRC
1692017-03-23T13:31:24 <btcdrak> wow it's Thursday again already... how time flies
1702017-03-23T13:43:59 *** magicwund has joined #bitcoin-core-dev
1712017-03-23T13:48:43 <bitcoin-git> [bitcoin] flack opened pull request #10063: add missing spaces so that markdown recognizes headline (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10063
1722017-03-23T13:48:58 *** magicwund has quit IRC
1732017-03-23T13:52:01 *** jtimon has joined #bitcoin-core-dev
1742017-03-23T13:55:13 *** Giszmo has joined #bitcoin-core-dev
1752017-03-23T14:08:05 *** Giszmo has quit IRC
1762017-03-23T14:20:54 *** Giszmo has joined #bitcoin-core-dev
1772017-03-23T14:21:07 *** magicwund has joined #bitcoin-core-dev
1782017-03-23T14:26:27 *** magicwund has quit IRC
1792017-03-23T14:27:10 *** Turner has joined #bitcoin-core-dev
1802017-03-23T14:37:00 *** magicwund has joined #bitcoin-core-dev
1812017-03-23T14:38:05 *** BashCo_ has joined #bitcoin-core-dev
1822017-03-23T14:40:42 *** BashCo has quit IRC
1832017-03-23T14:43:29 *** BashCo has joined #bitcoin-core-dev
1842017-03-23T14:45:27 *** BashCo_ has quit IRC
1852017-03-23T14:59:18 *** owowo has quit IRC
1862017-03-23T15:10:43 *** talmai has joined #bitcoin-core-dev
1872017-03-23T15:10:53 *** owowo has joined #bitcoin-core-dev
1882017-03-23T15:47:47 *** abpa has joined #bitcoin-core-dev
1892017-03-23T15:50:39 *** CubicEarthh has joined #bitcoin-core-dev
1902017-03-23T15:59:30 *** riemann has quit IRC
1912017-03-23T16:14:07 *** bityogi has joined #bitcoin-core-dev
1922017-03-23T16:26:29 *** laurentmt has joined #bitcoin-core-dev
1932017-03-23T16:38:45 *** talmai has quit IRC
1942017-03-23T16:52:30 *** cryptapus has joined #bitcoin-core-dev
1952017-03-23T16:58:20 *** jouke has quit IRC
1962017-03-23T16:58:20 *** jouke has joined #bitcoin-core-dev
1972017-03-23T16:59:44 *** CubicEarthh has quit IRC
1982017-03-23T17:05:52 *** magicwund has quit IRC
1992017-03-23T17:15:47 *** magicwund has joined #bitcoin-core-dev
2002017-03-23T17:19:33 *** juscamarena has quit IRC
2012017-03-23T17:26:23 *** juscamarena has joined #bitcoin-core-dev
2022017-03-23T17:34:10 *** ChillazZ has quit IRC
2032017-03-23T17:34:25 *** gabridome has joined #bitcoin-core-dev
2042017-03-23T18:02:50 *** laurentmt has quit IRC
2052017-03-23T18:08:23 *** talmai has joined #bitcoin-core-dev
2062017-03-23T18:16:58 *** talmai has quit IRC
2072017-03-23T18:17:51 *** talmai has joined #bitcoin-core-dev
2082017-03-23T18:26:54 *** GoldSlash has joined #bitcoin-core-dev
2092017-03-23T18:27:45 *** talmai_ has joined #bitcoin-core-dev
2102017-03-23T18:28:31 *** talmai has quit IRC
2112017-03-23T18:29:23 *** Sosumi has joined #bitcoin-core-dev
2122017-03-23T18:30:54 *** talmai_ has quit IRC
2132017-03-23T18:31:32 *** talmai has joined #bitcoin-core-dev
2142017-03-23T18:34:34 <gmaxwell> meeting in 20 minutes.
2152017-03-23T18:34:49 *** GoldSlash_ has joined #bitcoin-core-dev
2162017-03-23T18:37:18 *** GoldSlash__ has joined #bitcoin-core-dev
2172017-03-23T18:37:39 *** GoldSlash_ has quit IRC
2182017-03-23T18:40:03 *** GoldSlash__ has quit IRC
2192017-03-23T18:41:22 *** GoldSlash__ has joined #bitcoin-core-dev
2202017-03-23T18:43:22 *** schmidty has quit IRC
2212017-03-23T18:43:46 *** GoldSlash__ has quit IRC
2222017-03-23T18:47:09 <petertodd> sipa: IIRC there's something not unlike that in rust with deref coercion
2232017-03-23T18:49:10 *** Giszmo has quit IRC
2242017-03-23T18:50:04 <gmaxwell> luke-jr: does your prover optimize that it's cheaper to provide merkle membership proofs when you show transactions with common parents in the tree? e.g. Say that the sizes are 1000 900 100 910 you get more size-proof per proof-size if you select 1000,900 instead of 1000,910.
2252017-03-23T18:50:35 *** chjj has quit IRC
2262017-03-23T18:51:51 <luke-jr> gmaxwell: the current code doesn't
2272017-03-23T18:53:50 *** juscamarena has quit IRC
2282017-03-23T18:55:51 <gmaxwell> luke-jr: I would eliminate transactions by first assuming all are in and then asking "can I leave out this leaf?" for each interior node and child, then remove the one that eliminates the most proof size per transaction size proven.
2292017-03-23T18:56:10 *** juscamarena has joined #bitcoin-core-dev
2302017-03-23T18:56:47 <gmaxwell> (proof size including the membership proofs, and the extra data, so it'll tend to remove txn that have a lot of extradata)
2312017-03-23T18:57:37 <gmaxwell> luke-jr: this is another reason for a softfork increasing the minimum transaction size in the future. Your proofs should also be able to prove that there is a transaction smaller than a minimum.
2322017-03-23T18:58:04 <gmaxwell> would be interesting to profile your proofs on the existing chain with a fake block limit of 750k and also see how the proof size changes as a function of the minimum transaction size.
2332017-03-23T19:00:03 <sipa> PING
2342017-03-23T19:00:14 <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
2352017-03-23T19:00:17 <kanzure> hi.
2362017-03-23T19:00:17 <jonasschnelli> hi
2372017-03-23T19:00:18 <petertodd> hi
2382017-03-23T19:00:20 <wumpus> #startmeeting
2392017-03-23T19:00:20 <lightningbot> Meeting started Thu Mar 23 19:00:20 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2402017-03-23T19:00:20 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2412017-03-23T19:00:20 <sipa> hi
2422017-03-23T19:00:20 <achow101> hi
2432017-03-23T19:00:27 <gmaxwell> Welcome to meeting.
2442017-03-23T19:00:34 <cfields> hi
2452017-03-23T19:00:49 *** chjj has joined #bitcoin-core-dev
2462017-03-23T19:00:50 <btcdrak> greetings!
2472017-03-23T19:00:57 <wumpus> proposed topics?
2482017-03-23T19:01:14 <btcdrak> holiday at the beach?
2492017-03-23T19:01:27 <petertodd> btcdrak: that's what the financial crypto conference is for
2502017-03-23T19:01:29 <gmaxwell> wumpus: The segwit address proposal on the list.
2512017-03-23T19:01:35 <petertodd> gmaxwell: +1
2522017-03-23T19:01:37 <wumpus> sounds good to me
2532017-03-23T19:01:39 <btcdrak> +1
2542017-03-23T19:01:44 <wumpus> #topic segwit address proposal
2552017-03-23T19:01:53 <jonasschnelli> proposed topic: DER encoded priv keys in wallet
2562017-03-23T19:02:05 <jonasschnelli> ack #sw addr format
2572017-03-23T19:02:12 <sipa> general opinions/questions about the segwit addr format?
2582017-03-23T19:02:25 <gmaxwell> We might have made a strategic error in getting 1:1 comments from too many people, causing a darth of comments on the list. Comments on the list would be good even if they're just "I reviewed this before, LGTM"
2592017-03-23T19:02:26 <jonasschnelli> Andreas S. concern about QRCode?
2602017-03-23T19:02:44 <kanzure> who has reviewed bech32 by now?
2612017-03-23T19:02:45 <btcdrak> ML post is here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013749.html
2622017-03-23T19:03:03 <sipa> jonasschnelli: petertodd responded, by i can give some extra commemtd
2632017-03-23T19:03:04 <petertodd> gmaxwell: along thsoe lines, I think making some of those 1:1 comments public might be helpful for new devs interested in learning how these processes work
2642017-03-23T19:03:06 <sipa> *commemts
2652017-03-23T19:03:10 <jonasschnelli> IMO QRCode have redundant parts while - as far as I understand bech32 â has also error correction.. seems a bit unefficient. Though QRCode are another layer I guess.
2662017-03-23T19:03:47 <jonasschnelli> (need to read petertodd's response; wasn't aware(
2672017-03-23T19:03:55 <gmaxwell> jonasschnelli: He suggested it use more characters but using anything non-alphanum makes it so double click copy doesn't work in browsers, also being a non power-of-prime base makes strong error detection infesable, and at best could reduce the size by a couple percent.
2682017-03-23T19:04:09 <gmaxwell> These points are all addressed in the document, I believe.
2692017-03-23T19:04:29 <kanzure> tromp's MiXcAsE proposal was a joke right?
2702017-03-23T19:04:43 <sipa> gmaxwell: base 43 is actually totally doable as it is a prime
2712017-03-23T19:04:46 <petertodd> gmaxwell: there's a few things that the document doesn't mention as clearly as it could, like how non-alphanum poses barriers for non-english-speaking users
2722017-03-23T19:04:50 <wumpus> jonasschnelli: I don't think the qr error detection/correction is strong enough for somthing as critical to get right as an address
2732017-03-23T19:04:51 <gmaxwell> (in fact in an earlier revision we used - as a seperator but dropped it for click copy compatibility)
2742017-03-23T19:04:51 <sipa> gmaxwell: but it requires bignum code to convert
2752017-03-23T19:05:04 <jonasschnelli> wumpus: Yes. Agree.
2762017-03-23T19:05:24 <sipa> petertodd: feel free to suggest better language :)
2772017-03-23T19:05:29 <gmaxwell> wumpus: it would probably be fine if we only ever used QR codes.. but obviously that isn't possible.
2782017-03-23T19:06:03 <petertodd> sipa: will do - also thanks for having such a great list of rationals already! really helpful to understand why something was chosen and what the tradeoffs are
2792017-03-23T19:06:09 <gmaxwell> petertodd: yes, though really being num only be best for international support but the result is significantly bigger and slower to deal with. :( I tried that out at one point.
2802017-03-23T19:06:13 <wumpus> gmaxwell: a more compact format could be used with qr codes, in any case, if that's desirable. That doesn't affect this standard.
2812017-03-23T19:06:21 <luke-jr> QR codes could hypothetically encode it in binary, but meh
2822017-03-23T19:06:36 *** juscamarena has quit IRC
2832017-03-23T19:06:43 <kanzure> rationale section was good, although i think it would be worthwhile to describe the 'exhaustive search'
2842017-03-23T19:06:47 <kanzure> in public
2852017-03-23T19:06:49 <wumpus> luke-jr: right.
2862017-03-23T19:06:59 <gmaxwell> luke-jr: if we had a binary QR only format I assume it would intentionally begin with something like a null byte to make sure it doesn't get mangled by text channels.
2872017-03-23T19:07:14 <petertodd> gmaxwell: yeah, we're fortunate that lots of non-english-speakers still known the alphabet; even english speakers often don't know the names of punctuation symbols, and those names are also not entirely canonical
2882017-03-23T19:07:25 *** handlex has joined #bitcoin-core-dev
2892017-03-23T19:07:40 *** Giszmo has joined #bitcoin-core-dev
2902017-03-23T19:07:57 <jonasschnelli> It's probably not worth to design an additional binary addr standard for QrCodes. Maybe they are only temporary? Gone in 3-4 yrs?
2912017-03-23T19:08:04 <gmaxwell> There were a lot of other rational things we trimmed from the document. One of pieter's concerns was that the length of the document would make it seem complicated (though the proposal is pretty simple.); feedback on reddit seemed to somewhat validate that.
2922017-03-23T19:08:12 <petertodd> luke-jr: so by matchin QR code's special-case character set support, we end up with an encoding that at the low level is basically binary anyway
2932017-03-23T19:08:35 <gmaxwell> jonasschnelli: I think that it's probably not worth it for that, but industry feedback would be nice.
2942017-03-23T19:08:50 <gmaxwell> petertodd: thats a point, though the unfortuate thing is that it's exposed to mangling.
2952017-03-23T19:09:04 <sipa> the alphanuneric mode is pretty efficient; only 10% extra compared to binary
2962017-03-23T19:09:12 <sipa> it uses 5.5 bits per character
2972017-03-23T19:09:16 <gmaxwell> e.g. QR decoder -> something that munges up the strings -> software -> coins in sppppaccccceeee.
2982017-03-23T19:09:24 <sipa> so 5.5 bits per 5 bits of data is pretty goof
2992017-03-23T19:09:26 <sipa> good
3002017-03-23T19:09:34 <petertodd> jonasschnelli: I think the day Qr codes aren't heavily used will be the day bech32 is irrelevant anyway because people are all paying each other by very different means :)
3012017-03-23T19:09:49 <jonasschnelli> probably... :)
3022017-03-23T19:10:04 <sipa> while base58 uses 8 bits per 5.86 bits of data
3032017-03-23T19:10:15 <gmaxwell> sipas point is more important, only a 10%-ish overhead in this format vs some binary QR code.
3042017-03-23T19:10:50 <sipa> if you also drop the checksum, we get much larger savings of course
3052017-03-23T19:11:13 <sipa> in practice you'd get a 25% reduction for p2wpkh
3062017-03-23T19:11:23 <jonasschnelli> side note: could the Bech32 encoding also be used for private keys (== 32bit seeds)?
3072017-03-23T19:11:29 <gmaxwell> true. but ugh. the some text handling path replaces a character.
3082017-03-23T19:11:31 <sipa> jonasschnelli: good question!
3092017-03-23T19:11:37 <wumpus> indeed, for base58 addresses there also never has been a binary standard for qr codes
3102017-03-23T19:11:44 <sipa> jonasschnelli: we've been thinking about a stronger checksum for private keys
3112017-03-23T19:11:45 <Anduck> QR codes iirc can work even if 30% of the code misread
3122017-03-23T19:11:46 <wumpus> which would have saved a lot more
3132017-03-23T19:12:03 <petertodd> jonasschnelli: yes - in fact I'm planning on using it for non-bitcoin applications too
3142017-03-23T19:12:06 <sipa> possibly 12 checksum characters (which is the maximum doable with 64 bit arithmetic)
3152017-03-23T19:12:24 <jonasschnelli> Yes. An alternative for bip39?
3162017-03-23T19:12:42 <gmaxwell> For private keys additional error _correction_ is interesting, and additional overhead is not very consequential.
3172017-03-23T19:12:43 *** juscamarena has joined #bitcoin-core-dev
3182017-03-23T19:12:59 <sipa> bech32 can only correct 2 errors, but detect 4
3192017-03-23T19:13:17 *** magicwund has quit IRC
3202017-03-23T19:13:22 <sipa> for addresses you really only care about detection
3212017-03-23T19:13:29 <sipa> but for private keys you want correction
3222017-03-23T19:13:37 <wumpus> yes, quite a different use case
3232017-03-23T19:13:45 <gmaxwell> So we've been working on that some in the background. So it would be a different spec but just very similar. (e.g. similar kind of 5 lines of code) for the 12 digit checksum or what not.
3242017-03-23T19:13:58 <sipa> with a 12 character checksum, correcting 3 errors is trivial
3252017-03-23T19:14:07 <jonasschnelli> current WIF can correct 0.
3262017-03-23T19:14:15 <sipa> but perhaps we can find one that can correct 4
3272017-03-23T19:14:20 <gmaxwell> kanzure: we left out a lot of technical manutia about the construction which is interesting but not really relevant to the spec.
3282017-03-23T19:15:05 <wumpus> makes sense to keep the spec focused and minimal, that way people will more likely read it :) you could link to an additional description, or include it as appendix or such
3292017-03-23T19:15:42 <sipa> earlier version explained finite field arithmetic and generator polynomials :)
3302017-03-23T19:15:45 <petertodd> wumpus: maybe good to make it a spec + design document? put rational/etc. in the latter. IIRC SHA3 had a document like that, among others.
3312017-03-23T19:15:58 <wumpus> petertodd: yes indeed
3322017-03-23T19:16:05 <jonasschnelli> The question about the level of complexity: We should't care. Pieter's stuff tend to be complicated. But only because its great and though through well. Awesome work IMO!
3332017-03-23T19:16:06 <jtimon> I haven't fully reviewed it, but I've had a fast read on several versions of the doc and asked questions to sipa
3342017-03-23T19:16:42 <gmaxwell> Finding a 12-digit code that corrects 4 may take more computing power than we have with just the a hundred cores here... though sipa has done a lot to take that search from completely intractable to plausable. :) I think this work is a lot lower priority though other things we could be working on (like utxo database refactors and tx compaction) ....
3352017-03-23T19:17:27 <sipa> jonasschnelli: i think the result is actually surprisingly simple
3362017-03-23T19:17:30 *** hejdjdusuabxb has joined #bitcoin-core-dev
3372017-03-23T19:17:50 <sipa> (but i'm probably biased)
3382017-03-23T19:17:52 <gmaxwell> In any case, review and comment please!
3392017-03-23T19:17:59 <luke-jr> I think it's more important to *detect* errors, than to correct them
3402017-03-23T19:18:07 <sipa> luke-jr: for addresses, absolutely
3412017-03-23T19:18:19 <luke-jr> 4 seems a bit low in that regard
3422017-03-23T19:18:51 <jonasschnelli> sipa: I think deeply understanding the specs takes a coupe of hours... and it's different to the current base58check. This may frighten off people... but that shouldn't be something that should affect the process of selecting the *next* addr encoding format IMO
3432017-03-23T19:18:53 <gmaxwell> luke-jr: for private keys you can generate the resulting wallet and check against the blockchain.. so correcting can be very useful.
3442017-03-23T19:18:53 <petertodd> luke-jr: what do you mean by "4" in the above?
3452017-03-23T19:19:12 <luke-jr> [19:12:59] <sipa> bech32 can only correct 2 errors, but detect 4
3462017-03-23T19:19:36 <gmaxwell> Well it is _guarenteed_ to detect 4 errors, more than 4 you have a 1:2^30 chance of detecting.
3472017-03-23T19:19:56 <sipa> luke-jr: well it has a 99.9999999068% chance to detect more errors
3482017-03-23T19:19:58 <luke-jr> if I carefully construct gibberish, I'd expect it to be rejected
3492017-03-23T19:20:14 <luke-jr> sipa: ah, okay
3502017-03-23T19:20:38 <petertodd> luke-jr: for this application, the threat is random mistakes, not malice - in the malice case someone could just replace the address anyway
3512017-03-23T19:20:50 <gmaxwell> This graph shows the probablity of an error going undetected (y) as a function of how likely the user is to make mistakes (x):
3522017-03-23T19:20:53 <gmaxwell> https://people.xiph.org/~greg/temp/bch-eff3.png
3532017-03-23T19:21:08 <sipa> jonasschnelli: https://github.com/sipa/bech32/blob/master/ref/python/segwit_addr.py <- full encoder/decoder implementation
3542017-03-23T19:21:13 <cfields> great work indeed. From what I remember from our discussions before, the work to derive the function was complex, but afterwards, implementing it is simple. Seems best-case to me :). Will review now that it's final.
3552017-03-23T19:21:42 <jonasschnelli> sipa: 121 lines... yes. thats indeed very simple.
3562017-03-23T19:21:50 <gmaxwell> As you can see, if the user's error rate is below 3.53 errors per address entered, this code has better protection than a 32bit hash (like base58 check uses). And because of case modulation, users are MUCH less likely to make mistakes with this format.
3572017-03-23T19:22:07 *** BashCo_ has joined #bitcoin-core-dev
3582017-03-23T19:22:16 *** laurentmt has joined #bitcoin-core-dev
3592017-03-23T19:22:37 *** magicwund has joined #bitcoin-core-dev
3602017-03-23T19:22:38 <gmaxwell> If the user is unlikely to make errors, then the effective protection of this scheme tends to infinity.
3612017-03-23T19:23:22 <gmaxwell> e.g. 0.1% chance of error per character and the probablity that an errored string goes undetected is 1:2^60.
3622017-03-23T19:23:40 <sipa> enough on this topic, i guess
3632017-03-23T19:24:10 <wumpus> other topics?
3642017-03-23T19:24:18 <gmaxwell> jonasschnelli suggested the der wallet thing.
3652017-03-23T19:24:30 <jonasschnelli> Yes. We still keep all priv keys DER encoded in BDB
3662017-03-23T19:24:47 <jonasschnelli> I think we should bundle the next wallet db update with remvoing DER
3672017-03-23T19:24:50 <gmaxwell> The compressed flag has no effect on our operation. We should always set it IMO... make the wallet sightly smaller. Its dumb that the data is stored at all.. it's not used. But since it's there, better to make it small.
3682017-03-23T19:24:57 *** BashCo has quit IRC
3692017-03-23T19:25:04 <gmaxwell> if we make the format incompatible, sure.
3702017-03-23T19:25:29 <jonasschnelli> Reading DER (old versions) must be supported. But new wallets should store in plain.
3712017-03-23T19:25:33 <wumpus> #topic DER privkeys in wallet
3722017-03-23T19:25:33 <gmaxwell> Why are we even storing seralized private keys when BIP32 is in use?
3732017-03-23T19:25:41 <jonasschnelli> Yes.
3742017-03-23T19:25:44 <jonasschnelli> Importprivkey
3752017-03-23T19:25:48 <jonasschnelli> and old wallets
3762017-03-23T19:26:00 <jonasschnelli> But I think HD wallets should only have a single privkey (the HD seed)
3772017-03-23T19:26:02 <gmaxwell> okay, for that, sure. But I agree, fine to not use DER private keys for that.
3782017-03-23T19:26:22 <jonasschnelli> Also the seed key is also DER right now. :/
3792017-03-23T19:26:27 <gmaxwell> but otherwise there shouldn't be seralized private keys. Pubkeys yes. :)
3802017-03-23T19:26:37 <gmaxwell> wut
3812017-03-23T19:26:52 <jonasschnelli> Yes. Ideally it should be... and I think we are working in this direction...
3822017-03-23T19:26:55 <wumpus> didn't we have an issue related to this?
3832017-03-23T19:26:56 <gmaxwell> okay well, whatever, there is only one there. We could encode it as cat pictures for all I care.
3842017-03-23T19:26:56 <phantomcircuit> yeah it's saved using the same format as other private keys
3852017-03-23T19:27:26 <gmaxwell> wumpus: there is an issue open over the compressed flag, though its inconsequential.
3862017-03-23T19:27:31 <jonasschnelli> wumpus: Yes. https://github.com/bitcoin/bitcoin/issues/10041
3872017-03-23T19:27:38 <wumpus> gmaxwell: ok
3882017-03-23T19:27:44 <jonasschnelli> and a fix: https://github.com/bitcoin/bitcoin/pull/10043
3892017-03-23T19:27:56 <wumpus> I wasn't aware it was inconsequential
3902017-03-23T19:27:58 <gmaxwell> I think that to the extent that we continue to write those keys (e.g. for old wallets) that we should always use the compressed flag.
3912017-03-23T19:28:00 * luke-jr ponders if importprivkey should be rejected for HD wallets
3922017-03-23T19:28:02 <wumpus> did anyone reply that to the issue?
3932017-03-23T19:28:03 <jonasschnelli> Though,... as long as nobody reads BDB from the outside it shoudn't matter
3942017-03-23T19:28:07 <gmaxwell> wumpus: we decided compressed/uncompressed from the pubkey.
3952017-03-23T19:28:24 <gmaxwell> wumpus: the public key inside the der private key does nothing.
3962017-03-23T19:28:25 <wumpus> luke-jr: would be nice to keep HD wallets 'pure'
3972017-03-23T19:28:34 <wumpus> luke-jr: at the least it should throw a warning
3982017-03-23T19:28:51 <wumpus> gmaxwell: weird :)
3992017-03-23T19:28:52 <jonasschnelli> luke-jr: Yes. We should reject... in that case
4002017-03-23T19:28:55 <luke-jr> if we could do warnings, importprivkey should always throw a warning anyway :p
4012017-03-23T19:29:02 <gmaxwell> Background: The DER private key format includes the public key, along with all the ECC group parameters, and other overheads all packed in hundreds of bytes of ASN1 parsing hell.
4022017-03-23T19:29:14 <jonasschnelli> wumpus: Yes. It wired... better DER is gone sooner then later
4032017-03-23T19:29:29 <jonasschnelli> It would be another thing that will make future devs stumbel
4042017-03-23T19:29:34 <wumpus> agreed
4052017-03-23T19:29:49 <wumpus> so if there is a backwards-incompatible wallet change, that could be included, I guess
4062017-03-23T19:29:54 <gmaxwell> Turns out we were trying to tell the der private key to use compressed or not on the basis of the key using compressed or not... but the code was wrong. But it doesn't matter because we never did anything with the private key embedded public key.
4072017-03-23T19:30:12 <jonasschnelli> wumpus: Yes. The hd chain split...
4082017-03-23T19:30:23 <jonasschnelli> (which we hopefully can merge soon)
4092017-03-23T19:30:28 <wumpus> jonasschnelli: right
4102017-03-23T19:30:55 <jonasschnelli> I think we would have enought time post hd split merge to remove DER for 0.14
4112017-03-23T19:31:00 <gmaxwell> we should stage up several incompatible changes to make at once, the multitude of versions is a support burden. Changing the private key formats would be one of them.
4122017-03-23T19:31:09 <luke-jr> jonasschnelli: 0.14 is gone; you mean 0.15?
4132017-03-23T19:31:13 <BlueMatt> 15
4142017-03-23T19:31:22 <jonasschnelli> Ergh.. yes.
4152017-03-23T19:32:13 <jonasschnelli> Do we expect that the wallet db handles error correction or should we directly switch to something like Bech32 for our internal privkey serialisation?
4162017-03-23T19:32:19 <BlueMatt> gmaxwell: the code looks the same either way? wallet version 14990 14991 14992 can all be in the same release, whatever...code is still wallet.AmUpgradedTo(THING)
4172017-03-23T19:32:54 <gmaxwell> in our code but not necessarily in other tools.
4182017-03-23T19:33:00 <gmaxwell> also we have to worry about interactions.
4192017-03-23T19:33:27 <BlueMatt> fair
4202017-03-23T19:33:37 <wumpus> the wallet db has no error correction
4212017-03-23T19:33:38 <BlueMatt> gmaxwell: to be clear, are you suggesting they all happen in one wallet version, or in one release?
4222017-03-23T19:33:55 <BlueMatt> (I mean we dont support wallet versions from mid-release, but it'd be really annoying...)
4232017-03-23T19:34:02 <jonasschnelli> wumpus: I think this would/should be very desirable
4242017-03-23T19:34:04 <wumpus> (berkeleydb doesn't and neither does leveldb, the latter only has detection)
4252017-03-23T19:34:15 <wumpus> jonasschnelli: yes, encoding privkeys in a resilient format makes sense
4262017-03-23T19:34:20 <wumpus> jonasschnelli: though doesn't encryption break that?
4272017-03-23T19:34:30 <wumpus> jonasschnelli: the error correction should be around the encryption, not inside it
4282017-03-23T19:34:41 <wumpus> otherwise one bit change will completely mangle it anyway
4292017-03-23T19:34:44 <gmaxwell> BlueMatt: preferable to be one version, but certantly one release. I don't know that we really don't support midrelease wallets. "sorry dude, your funds are gone, you made the mistake of helping us test." :P there are degrees of non-support.
4302017-03-23T19:34:48 <luke-jr> we have never broken wallet versions from mid-release AFAIK
4312017-03-23T19:34:50 <jonasschnelli> wumpus: good point
4322017-03-23T19:35:18 <gmaxwell> bech32 is not helpful for the kinds of errors we would find on disk.. you'll usually lose a whole sector at a time.
4332017-03-23T19:35:24 <wumpus> eh, wallets from mid-release should not suddenly break in later updates
4342017-03-23T19:35:45 <jonasschnelli> There is also a PR i'd like to bundle with chain-split/rm DER that would detatch the client version from the wallet version/migration handling (PR is called "wallet flags" or similar)
4352017-03-23T19:35:48 <gmaxwell> To make a wallet database master key error robust you should just repeat it across multiple disk sectors. :P
4362017-03-23T19:36:01 <wumpus> gmaxwell: I've seen single bit errors happen on disk too, though usually due to bus errors
4372017-03-23T19:36:28 <gmaxwell> wumpus: yea, but not as common. And it would be fine to have a wallet format with a 4kb master key. .. but I think thats stuff to think about for the post BDB world.
4382017-03-23T19:36:30 <petertodd> wumpus: repeating across multiple disk errors fixes that too :)
4392017-03-23T19:36:33 <wumpus> but some of the corrupted block files I"ve analyzed certainly had single bit errors
4402017-03-23T19:36:47 <gmaxwell> sorry I stated it too strongly.
4412017-03-23T19:37:18 <wumpus> in any case - for HD wallets we need to store way less private keys
4422017-03-23T19:37:22 <wumpus> so blowing up the master key to 4kb is fine
4432017-03-23T19:37:32 <gmaxwell> ya, t'was my intended point. :)
4442017-03-23T19:37:35 <wumpus> if that helps protect against various kinds of corruption
4452017-03-23T19:37:40 <BlueMatt> gmaxwell: ok, so multiple version numbers, but external tools only need support them as a group and -walletupgrade only supports them as a group?
4462017-03-23T19:38:16 <sipa> the wallet flags idea removes that release/walletversion inconsistency completely
4472017-03-23T19:38:16 <gmaxwell> BlueMatt: I think that would be okay but why multiple versions? add the code with the features, then a patch that turns all of them on with a single version.
4482017-03-23T19:38:18 *** handlex has quit IRC
4492017-03-23T19:38:52 <sipa> gmaxwell: that's very hard for testing
4502017-03-23T19:39:16 <sipa> as you'd need to be able to override the min version in tests to be able to even observe the feature
4512017-03-23T19:39:19 <BlueMatt> yea, was just thinking easier for review burden, but I suppose thats fine too
4522017-03-23T19:39:35 <BlueMatt> sipa: not so hard to have an extra commit in a pr that doesnt get merged
4532017-03-23T19:39:44 <sipa> BlueMatt: ugh
4542017-03-23T19:39:48 <gmaxwell> we just create support hurdles for ourselves supporting mixed features. "oh this change brakes bob's wallet because he had a mid-release version that had X and not Y"
4552017-03-23T19:39:54 <sipa> code in master should be testable
4562017-03-23T19:40:19 <sipa> wallet flags does not necessarily imply supporting mixed features
4572017-03-23T19:40:41 <gmaxwell> As long as it doesn't then I don't mind.
4582017-03-23T19:40:56 <gmaxwell> Just please lets not dribble in three different incompatible versions during a release cycle.
4592017-03-23T19:41:03 <BlueMatt> jonasschnelli: detaching client version, fine, but would strongly prefer a serially increasing version number and not flags
4602017-03-23T19:41:06 <gmaxwell> and end up with people with weird wallets that will break later.
4612017-03-23T19:41:24 <sipa> we could also detach walletversion from client version
4622017-03-23T19:41:32 <sipa> that would accomplish the same thing
4632017-03-23T19:41:38 <BlueMatt> yea, that ^
4642017-03-23T19:41:41 <gmaxwell> unless we're going to add tests for all the possible variations we shouldn't let people running master encounter them unawares.
4652017-03-23T19:41:46 <sipa> and just increment the wallet version when a new feature is added
4662017-03-23T19:41:52 <BlueMatt> wasnt sipa magic number picker for a while? can we just go back to that
4672017-03-23T19:42:12 <BlueMatt> or jonasschnelli, since he owns wallet these days, mostly
4682017-03-23T19:42:21 <gmaxwell> for testing you should just be able to set a commandline paramter that turns on future versions/features.
4692017-03-23T19:42:51 <gmaxwell> e.g. default wallet created is version X but there is code for version Y (or flag Y) and you can ask for it for testing, but until its the default its unstable and all bets are off.
4702017-03-23T19:43:13 <jonasschnelli> Need to think about it. Flags seems to be good anyways (supports HD, watch only,...) but most not be linked to the wallet database version.. hmm..
4712017-03-23T19:43:25 <gmaxwell> I don't care if we retain compatiblity for a wallet someone created by running bitcoind with --force-wallet-screw-me-over-now-now-now
4722017-03-23T19:43:28 <jonasschnelli> s/most/must
4732017-03-23T19:43:43 *** pindarhk has quit IRC
4742017-03-23T19:44:06 <BlueMatt> jonasschnelli: flags just makes things more complicated to support (interactions, yuck), and I'm not sure we have a compelling use-case for turning on some stuff but not others, aside from "I want my wallet to work all the way back to version 0.X"
4752017-03-23T19:44:07 *** pindarhk has joined #bitcoin-core-dev
4762017-03-23T19:44:11 <gmaxwell> And I'm fine with flags too, of course, but not with supporting arbritary combinations. (unless someone really wants to build extensive automated testing for all the combinations)
4772017-03-23T19:44:37 <luke-jr> BlueMatt: Core isn't the only compatible wallet.
4782017-03-23T19:44:47 <gmaxwell> e.g. basically a version implies flags... and you use flags in the code, and that doesn't mean that all combinations of flags get tested.
4792017-03-23T19:45:13 <BlueMatt> luke-jr: all other wallets that read our wallet format are unsupported, I believe (and, hell, probably easier for them if we dont have flags with interactions...)
4802017-03-23T19:45:15 <jtimon> right, you can have flags and maybe even have debug option for experimental wallet features that we can remove in releases (or just not leave any wallet feature that doesn't have a version yet)
4812017-03-23T19:45:22 <jonasschnelli> Flags would allow flexible backporting? But I think we don't want to do this.
4822017-03-23T19:45:35 <jtimon> or just an extra commit that doesn't get merged like BlueMatt says
4832017-03-23T19:45:40 <luke-jr> BlueMatt: you're rather aggressive with "unsupported" IMO
4842017-03-23T19:45:42 <wumpus> we never backport wallet features
4852017-03-23T19:45:54 <gmaxwell> luke-jr: Our _binary_ wallet format isn't intended to be interoperable. If it is, great! but without a spec and a moving target, it isn't something we can guaretee. To begin with there would need to be an extensive all features all flags test suite... and I think it would be a waste of time to construct that for this format (esp since we're never going to specify BDB itself).
4862017-03-23T19:45:57 <BlueMatt> luke-jr: we have limited resources, but, fair point
4872017-03-23T19:46:11 <wumpus> yes, the database formats are not an external interface
4882017-03-23T19:46:58 <wumpus> we reserve the right to change them completely from one release to another without advance notice, though that will usually not happen
4892017-03-23T19:47:05 <gmaxwell> I don't know if wallet format compatiblity is a reasonable goal in general, at least not this year-- just because it's so integrally tied to the functionality.
4902017-03-23T19:47:27 <wumpus> older wallets should *always* work
4912017-03-23T19:47:34 <wumpus> that's the only guarantee
4922017-03-23T19:47:36 <gmaxwell> but obviously we don't want to create unnecessary incompatiblity.
4932017-03-23T19:47:43 <gmaxwell> right.
4942017-03-23T19:47:51 <gmaxwell> okay, is this horse dead yet?
4952017-03-23T19:47:55 <wumpus> yes
4962017-03-23T19:47:57 <jonasschnelli> yes
4972017-03-23T19:47:59 <wumpus> other topics?
4982017-03-23T19:48:07 <sipa> lunch?
4992017-03-23T19:48:11 <gmaxwell> I'd like to know if people might be willing to sign onto a statement like this:
5002017-03-23T19:48:12 <luke-jr> wallet format changes move slowly. I try to avoid backporting pending PRs to Knots now, but IMO once they get merged they should be fair.
5012017-03-23T19:48:15 <gmaxwell> https://0bin.net/paste/vSuqwACPe8WzpCnI#4katsiFvmtzK85e8eNgNVuElwD8kTbjPVuQnkontSyF
5022017-03-23T19:48:17 <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
5032017-03-23T19:48:29 <jtimon> sorry, "--force-wallet-screw-me-over-now-now-now" is exactly what I meant
5042017-03-23T19:48:32 <petertodd> gmaxwell: ACK
5052017-03-23T19:48:32 * BlueMatt proposes we have a weekly call for "what pr are you blocked on and want review on", though we've had mixed results when I've done that before
5062017-03-23T19:48:36 <gmaxwell> (gee thanks for the link gribble)
5072017-03-23T19:49:06 <wumpus> #topic statement against running closed source node code
5082017-03-23T19:49:16 <kanzure> "If it ever does, you may safely assume that the actual contributors to the project are locked in a basement somewhere. In that case, please send help." and food
5092017-03-23T19:49:21 <luke-jr> gmaxwell: I haven't thought about it sufficiently to be certain about "never"
5102017-03-23T19:49:23 <wumpus> gmaxwell: ACK
5112017-03-23T19:49:30 <petertodd> gmaxwell: though I think the statement should be a little more clear on what the risks are - this is money so such a binary may very well be an attempt to steal your coins
5122017-03-23T19:49:51 <wumpus> or may have hidden vulnerabilities, bugdoors and backdoors
5132017-03-23T19:50:01 <BlueMatt> gmaxwell: seems reasonable
5142017-03-23T19:50:04 <jtimon> BlueMatt: the original flags can be replaced with the version flag once you have a version for a set of them
5152017-03-23T19:50:07 <kanzure> yep seems good to me
5162017-03-23T19:50:20 <gmaxwell> luke-jr: I think I have, plus 1001 other open source packages have. As I point out in the document even if all other options fail, "shut off" remains an option too.
5172017-03-23T19:50:27 <jonasschnelli> Yes. A statement would be good. Also.. github.binaries with a SHA256 on reddit is _not_ want you want for a such ecosystem
5182017-03-23T19:50:31 <luke-jr> true
5192017-03-23T19:50:41 <petertodd> wumpus: see, I think it's good to say in such a statement "hidden vulnerabilities, bugdoors and backdoors" and *also* give a 100% concrete example for the non-devs reading it
5202017-03-23T19:50:41 <jtimon> I mean, you can have a single fWalletForNextVersionExperimental flag
5212017-03-23T19:50:42 <gmaxwell> okay well I would welcome revisions. I didn't want to make it long and explaining all the options and risks.
5222017-03-23T19:50:58 <gmaxwell> Just saying "don't run these things if 'we' do" is protective to both the users and us.
5232017-03-23T19:51:04 <wumpus> we have this stringent gitian process which costs quite a lot of time, maybe we should put more focus on it...
5242017-03-23T19:51:34 <gmaxwell> In any earlier draft I had listed out some of the options we have (and have used before) and it was 3x longer than this just explining a couple of them. :)
5252017-03-23T19:51:45 <kanzure> also, submitting source code "later" is not acceptable either
5262017-03-23T19:51:47 <achow101> the statement should say "Bitcoin Core project", not "Bitcoin project" IMO
5272017-03-23T19:51:52 <wumpus> I sometimes have the feeling we're doing all this auditability for nothing if people are ready to just download random crap binaries of the internet and run them, though I guess some do validate it...
5282017-03-23T19:52:07 <gmaxwell> wumpus: well we know not everyone does that.
5292017-03-23T19:52:19 <sipa> wumpus: i think it's a slow process... the best we can do is talk about it, and highlight what we're doing
5302017-03-23T19:52:37 <sipa> and just the increase in number of gitian builders on itself is a good sign
5312017-03-23T19:52:40 <kanzure> mentioning bugdoors, backdoors and other malware is important
5322017-03-23T19:52:46 <sipa> (reminds me, i need to build 0.14...)
5332017-03-23T19:53:05 <petertodd> wumpus: I know for a fact that many high-value users do verify PGP signatures and the like, e.g. exchanges and custodians. That effort isn't wasted.
5342017-03-23T19:53:07 <gmaxwell> okay, well I can work with some people on some language twiddling. Sounds like a couple people are interested.
5352017-03-23T19:53:20 <wumpus> I guess the important thing is that some people do validate it, and can raise a stink if things don't match, which is not possible with random crap executables
5362017-03-23T19:53:28 <wumpus> petertodd: right.
5372017-03-23T19:53:29 <gmaxwell> and luke-jr if you want to talk later and have me convince you that we'd would never in the future do a binary release, I'd be happy to.
5382017-03-23T19:53:39 <BlueMatt> one of these days I'm gonna finally convince cfields to finish his "trusting trust" compiler-builder for use in gitian, then I'll be much louder...the trusting-ubuntu part of gitian is...irritating at best (but still infinitely better than the alternative)
5392017-03-23T19:53:48 <gmaxwell> (_NEVER_ I mean, in the strongest sense, I'm sure you already are convinced that almost never would hold)
5402017-03-23T19:54:09 <luke-jr> yeah, I certainly can't think of any circumstances that would ever justify it.
5412017-03-23T19:54:42 <cfields> BlueMatt: yea, that's a goal of mine for 0.15.
5422017-03-23T19:54:43 <petertodd> gmaxwell: I like that you explicitly mentioned in that doc that interruption of service is perferable
5432017-03-23T19:54:54 <BlueMatt> cfields: yippee
5442017-03-23T19:55:02 <BlueMatt> topic?
5452017-03-23T19:55:11 * BlueMatt proposes we have a weekly call for "what pr are you blocked on and want review on", though we've had mixed results when I've done that before
5462017-03-23T19:55:26 <gmaxwell> petertodd: well I tested some of this explination on reddit while talking to people 1:1 about some things. so I have an idea of what needs to be explained.
5472017-03-23T19:55:34 <jtimon> gmaxwell: I would prefer if we mentioned free software explicitly or even replace open source with free software, but I agree with everything said in that statement
5482017-03-23T19:55:36 <sipa> BlueMatt: sounds good to me
5492017-03-23T19:55:43 <sipa> BlueMatt: everyone gets to list 1 PR?
5502017-03-23T19:55:49 <BlueMatt> sipa: sure
5512017-03-23T19:55:51 <jonasschnelli> Maybe two? :)
5522017-03-23T19:55:58 <BlueMatt> mine is 9725
5532017-03-23T19:56:02 <gmaxwell> jtimon: ack. Thanks for the feedback I'll revise some and consult with others that had comments.
5542017-03-23T19:56:06 <jonasschnelli> #9725
5552017-03-23T19:56:09 <gribble> https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt · Pull Request #9725 · bitcoin/bitcoin · GitHub
5562017-03-23T19:56:11 <wumpus> so jonasschnelli's wallet chain split seems important
5572017-03-23T19:56:21 <jonasschnelli> yes. please. #9294
5582017-03-23T19:56:25 <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
5592017-03-23T19:56:26 <kanzure> on that last topic, uh, maybe wee should point out that backdoors have been found in node software already (ahem some exchanges come to mind..).
5602017-03-23T19:56:33 <BlueMatt> list from last week was #8694, 9294, 9725 and #7729
5612017-03-23T19:56:35 <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
5622017-03-23T19:56:39 <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
5632017-03-23T19:57:06 <BlueMatt> any additions/replacements or should we let the list stand?
5642017-03-23T19:57:47 <gmaxwell> #9959 could probably take some more reviews.
5652017-03-23T19:57:48 <wumpus> I'd also really like to have feedback on my patches to add UNIX sockets support at some point (#9979, #9919) though it's not really urgent
5662017-03-23T19:57:49 <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
5672017-03-23T19:57:50 <gribble> https://github.com/bitcoin/bitcoin/issues/9979 | p2p: Bare minimum to support UNIX sockets by laanwj · Pull Request #9979 · bitcoin/bitcoin · GitHub
5682017-03-23T19:57:52 <gribble> https://github.com/bitcoin/bitcoin/issues/9919 | UNIX sockets support for RPC by laanwj · Pull Request #9919 · bitcoin/bitcoin · GitHub
5692017-03-23T19:58:05 <gmaxwell> (suhas doesn't appear to be here now, so I thought I'd mention it)
5702017-03-23T19:58:07 * jtimon reminds to build 0.14
5712017-03-23T19:58:30 <luke-jr> I still have to look over BlueMatt's review on multiwallet, so I'll refrain from listing one this time ;)
5722017-03-23T19:58:34 <gmaxwell> wumpus: Those are a great idea. I will be trying them out. Did we find out if your patch to libevent is going to make it upstream?
5732017-03-23T19:58:35 <cfields> wumpus: ah, i hadn't seen the p2p one
5742017-03-23T19:58:40 <jonasschnelli> Can we keep the most important 1PR list on github somehow? A project?
5752017-03-23T19:58:57 <sipa> jonasschnelli: sounds good to me
5762017-03-23T19:59:02 <jonasschnelli> I think this would be great because priorizing reviews is hard right now
5772017-03-23T19:59:10 <wumpus> gmaxwell: still haven't heard about that one, but I don't think it should matter for getting these patches in
5782017-03-23T19:59:11 <sipa> a PR can belong to multiple projects, right?
5792017-03-23T19:59:21 <gmaxwell> keep in mind to prioritize things that we would want in a 0.14.1.
5802017-03-23T19:59:23 <wumpus> sipa: AFAIK yes
5812017-03-23T19:59:26 <jonasschnelli> hopefully
5822017-03-23T19:59:29 <luke-jr> PR labels seems workable for that too
5832017-03-23T19:59:37 <wumpus> we already have so many labels
5842017-03-23T19:59:39 <luke-jr> "Top Priority" or somethign perhaps
5852017-03-23T19:59:48 <luke-jr> wumpus: but labels are easy to filter :D
5862017-03-23T19:59:59 <wumpus> also I use those to classify pulls for the release notes, so I'd prefer not to use them for non-categoritical things
5872017-03-23T20:00:04 <jonasschnelli> Project seems to be the better choice...
5882017-03-23T20:00:07 <wumpus> yes
5892017-03-23T20:00:12 <gmaxwell> "author:wumpus" (since he does most of the merging any of his PRs are effectively 1-reviewer disadvantaged for getting in)
5902017-03-23T20:00:17 <sipa> DONG
5912017-03-23T20:00:29 <wumpus> #endmeeting
5922017-03-23T20:00:29 <lightningbot> Meeting ended Thu Mar 23 20:00:29 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5932017-03-23T20:00:29 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-23-19.00.html
5942017-03-23T20:00:29 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-23-19.00.txt
5952017-03-23T20:00:29 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-23-19.00.log.html
5962017-03-23T20:00:31 <gmaxwell> Okay, I think its time to feed sipa.
5972017-03-23T20:00:35 <luke-jr> lol
5982017-03-23T20:00:38 <jonasschnelli> hehe
5992017-03-23T20:00:51 <jtimon> I've been waiting on #8855 (previously #6907 previously part of other prs) for so long...
6002017-03-23T20:00:52 <sipa> must... not... chew PRs
6012017-03-23T20:00:53 <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
6022017-03-23T20:00:53 <kanzure> programmer chow is other programmers
6032017-03-23T20:00:55 <gribble> https://github.com/bitcoin/bitcoin/issues/6907 | Chainparams: Use a regular factory for creating chainparams by jtimon · Pull Request #6907 · bitcoin/bitcoin · GitHub
6042017-03-23T20:00:57 * jonasschnelli will be in SF in September.
6052017-03-23T20:00:58 <luke-jr> when did we agree on a 1 hour limit to meetings anyway? IIRC there was only a set start time.. maybe they should go for 24 hours? :p
6062017-03-23T20:01:02 <sipa> jonasschnelli: cool!
6072017-03-23T20:01:12 <gmaxwell> luke-jr: because without a limit some people would starve.
6082017-03-23T20:01:17 <sipa> jonasschnelli: i may be in switzerland next month
6092017-03-23T20:01:21 <kanzure> luke-jr: maybe it should be based on time until 6 blocks
6102017-03-23T20:01:31 <jonasschnelli> sipa: If you are,... tell me and let's hand out.
6112017-03-23T20:01:33 <luke-jr> gmaxwell: am I the only one who eats during meetings sometimes?
6122017-03-23T20:01:40 <luke-jr> kanzure: hehe
6132017-03-23T20:01:45 <jtimon> another old one with several previous attempts is #8498 but I guess that's my fault for saying "Optimization" without doing benchmarks...
6142017-03-23T20:01:45 <jonasschnelli> s/hand/hang
6152017-03-23T20:01:48 <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
6162017-03-23T20:02:46 *** dcousens has joined #bitcoin-core-dev
6172017-03-23T20:02:55 <BlueMatt> we always have office space available for those who want a stopover between .eu and sf :P
6182017-03-23T20:03:04 <BlueMatt> and we have good flights :)
6192017-03-23T20:04:04 <luke-jr> does SF<->EU go that direction?
6202017-03-23T20:04:34 <jonasschnelli> BlueMatt: Ah.. man. I fly to SF over Iceland!
6212017-03-23T20:04:41 <jtimon> I suspect #9608 will also be open for ages, but at least that will force me to read every change in ProcessMessage...
6222017-03-23T20:04:43 <gribble> https://github.com/bitcoin/bitcoin/issues/9608 | Net: Divide ProcessMessage in smaller functions by jtimon · Pull Request #9608 · bitcoin/bitcoin · GitHub
6232017-03-23T20:04:56 <BlueMatt> jtimon: we said you get to pick one :P
6242017-03-23T20:05:24 *** BashCo_ has quit IRC
6252017-03-23T20:05:59 <sipa> jonasschnelli: cool, wowair?
6262017-03-23T20:06:00 <cfields> jtimon: I'll chime in on that one.
6272017-03-23T20:06:18 <jtimon> just like #8329 and #8337 force me to review every change in certain functions
6282017-03-23T20:06:19 <jonasschnelli> sipa: Yes. :|
6292017-03-23T20:06:21 <gribble> https://github.com/bitcoin/bitcoin/issues/8329 | Consensus: MOVEONLY: Move functions for tx verification by jtimon · Pull Request #8329 · bitcoin/bitcoin · GitHub
6302017-03-23T20:06:23 <gribble> https://github.com/bitcoin/bitcoin/issues/8337 | Consensus: MOVEONLY: Move functions for header verification by jtimon · Pull Request #8337 · bitcoin/bitcoin · GitHub
6312017-03-23T20:07:11 <jtimon> BlueMatt: if only one, then #8855, actually it doesn't need rebase but I'll just do it in case there's new uses of Params(std::string)
6322017-03-23T20:07:13 <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
6332017-03-23T20:15:06 *** hejdjdusuabxb has quit IRC
6342017-03-23T20:16:06 *** talmai has quit IRC
6352017-03-23T20:16:21 <jtimon> cfields: cool thanks, rebased, no new uses of Params(std::string)
6362017-03-23T20:19:34 *** cryptapus has quit IRC
6372017-03-23T20:21:18 *** laurentmt has quit IRC
6382017-03-23T20:26:22 <jtimon> gmaxwell: is there anything planned for 0.14.1 ?
6392017-03-23T20:27:04 *** BashCo has joined #bitcoin-core-dev
6402017-03-23T20:27:06 <sipa> bug fixes
6412017-03-23T20:28:50 *** GoldSlash__ has joined #bitcoin-core-dev
6422017-03-23T20:29:36 *** GoldSlash has quit IRC
6432017-03-23T20:33:34 *** moli_ has quit IRC
6442017-03-23T20:35:01 <bitcoin-git> [bitcoin] jtimon closed pull request #9845: RPC: cleanups in rpc/server (master...0.15-extern-rpc-server) https://github.com/bitcoin/bitcoin/pull/9845
6452017-03-23T20:38:17 *** Sosumi has quit IRC
6462017-03-23T20:40:16 *** adiabat has joined #bitcoin-core-dev
6472017-03-23T20:40:17 *** moli_ has joined #bitcoin-core-dev
6482017-03-23T20:40:45 *** moli_ has quit IRC
6492017-03-23T20:41:07 *** moli_ has joined #bitcoin-core-dev
6502017-03-23T20:49:18 *** juscamarena has quit IRC
6512017-03-23T20:53:46 *** Giszmo has quit IRC
6522017-03-23T21:05:00 *** magicwund has quit IRC
6532017-03-23T21:07:49 <BlueMatt> wumpus: were we gonna label peoples' review-picks as "blocking someone" or should i just put up a list somewhere
6542017-03-23T21:08:10 *** Giszmo has joined #bitcoin-core-dev
6552017-03-23T21:09:19 <gmaxwell> jtimon: there are a number of fixes already merged.
6562017-03-23T21:09:38 <jtimon> I see
6572017-03-23T21:09:46 <gmaxwell> jtimon: I'd like to see one ship in the not far future. I'm kinda surprised how few bugs we've had with 0.14.0
6582017-03-23T21:10:48 <BlueMatt> I believe the list was me: 9725
6592017-03-23T21:10:49 <BlueMatt> jonas: 9294
6602017-03-23T21:10:49 <BlueMatt> wlad: 7729 (+9979, 9919, though not blocking per se)
6612017-03-23T21:10:49 <BlueMatt> suhas: 9959
6622017-03-23T21:10:49 <BlueMatt> jorge: 8855
6632017-03-23T21:11:42 <jtimon> I think it had to do with delaying forking the 0.14 branch, or perhaps I just want to think that
6642017-03-23T21:12:03 <jtimon> BlueMatt: thanks, that's cool, perhaps we can do that at the end of every meeting
6652017-03-23T21:12:22 <BlueMatt> jtimon: that was my plan
6662017-03-23T21:12:32 <jtimon> well ack your plan then
6672017-03-23T21:13:19 <BlueMatt> though I think jonasschnelli has things to respond to from my review on 9294
6682017-03-23T21:13:37 <jtimon> that will save me "review begging" comments
6692017-03-23T21:16:07 <BlueMatt> oh, and I'll go ahead and add alex as 9942, because iirc he has a few things based on that too
6702017-03-23T22:06:04 *** rockhouse has quit IRC
6712017-03-23T22:06:04 *** rockhouse has joined #bitcoin-core-dev
6722017-03-23T22:55:53 <kanzure> testnet bug report (maybe) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013765.html
6732017-03-23T22:57:05 <sipa> segwit nodes don't download blocks from non-segwit nodes, by design
6742017-03-23T23:01:22 *** Guyver2 has quit IRC
6752017-03-23T23:30:29 <gmaxwell> *when segwit is active.
6762017-03-23T23:36:29 *** voyager_ has quit IRC
6772017-03-23T23:37:06 *** voyager_ has joined #bitcoin-core-dev
6782017-03-23T23:42:49 <bitcoin-git> [bitcoin] tjps opened pull request #10067: [trivial] Dead code removal (master...tjps_dead_code) https://github.com/bitcoin/bitcoin/pull/10067