12017-06-22T00:06:19 *** chjj has joined #bitcoin-core-dev
22017-06-22T00:11:49 <sipa> jonasschnelli: https://github.com/sipa/bitcoin/commits/progress
32017-06-22T00:11:52 *** neel has joined #bitcoin-core-dev
42017-06-22T00:12:34 <sipa> jonasschnelli: you were just returning from Upgrade without shutting down... no wonder you get a corruption :)
52017-06-22T00:15:24 *** jamesob has joined #bitcoin-core-dev
62017-06-22T00:16:10 *** unholymachine has quit IRC
72017-06-22T00:16:26 *** unholymachine has joined #bitcoin-core-dev
82017-06-22T00:16:33 *** neel has quit IRC
92017-06-22T00:19:30 *** jamesob has quit IRC
102017-06-22T00:44:21 *** Giszmo has joined #bitcoin-core-dev
112017-06-22T01:02:35 *** Ylbam has quit IRC
122017-06-22T01:10:07 *** goatpig has joined #bitcoin-core-dev
132017-06-22T01:14:10 *** Dyaheon has quit IRC
142017-06-22T01:16:08 *** Dyaheon has joined #bitcoin-core-dev
152017-06-22T01:22:20 *** marcoagn1 has quit IRC
162017-06-22T01:34:14 *** marcoagn1 has joined #bitcoin-core-dev
172017-06-22T01:58:48 *** Chris_Stewart_5 has joined #bitcoin-core-dev
182017-06-22T01:59:17 *** neel has joined #bitcoin-core-dev
192017-06-22T02:00:50 *** echonaut has quit IRC
202017-06-22T02:01:03 *** echonaut3 has joined #bitcoin-core-dev
212017-06-22T02:05:00 *** neel has quit IRC
222017-06-22T02:13:48 *** Chris_Stewart_5 has quit IRC
232017-06-22T02:28:34 *** dabura667 has joined #bitcoin-core-dev
242017-06-22T02:29:58 *** Chris_Stewart_5 has joined #bitcoin-core-dev
252017-06-22T02:44:33 *** jamesob has joined #bitcoin-core-dev
262017-06-22T03:26:37 *** nemgun has quit IRC
272017-06-22T03:41:18 *** Chris_Stewart_5 has quit IRC
282017-06-22T03:44:46 *** justan0theruser has joined #bitcoin-core-dev
292017-06-22T03:45:16 *** justan0theruser has joined #bitcoin-core-dev
302017-06-22T03:46:27 *** justanotheruser has quit IRC
312017-06-22T04:11:59 *** imposter has joined #bitcoin-core-dev
322017-06-22T04:23:18 *** marcoagn1 has quit IRC
332017-06-22T04:34:46 *** marcoagn1 has joined #bitcoin-core-dev
342017-06-22T04:39:26 *** randy-waterhouse has joined #bitcoin-core-dev
352017-06-22T04:42:09 *** sogo has joined #bitcoin-core-dev
362017-06-22T05:00:00 *** imposter has quit IRC
372017-06-22T05:01:11 *** jamesob has quit IRC
382017-06-22T05:01:44 *** jamesob has joined #bitcoin-core-dev
392017-06-22T05:06:00 *** jamesob has quit IRC
402017-06-22T05:10:54 *** sogo has quit IRC
412017-06-22T05:26:33 *** randy-waterhouse has quit IRC
422017-06-22T05:40:03 *** paveljanik has quit IRC
432017-06-22T05:53:53 *** CubicEarth has joined #bitcoin-core-dev
442017-06-22T05:57:12 *** Deadhand has quit IRC
452017-06-22T05:58:02 *** Deadhand has joined #bitcoin-core-dev
462017-06-22T06:02:45 <jonasschnelli> sipa: okay. I see. :/
472017-06-22T06:22:46 *** CubicEarth has quit IRC
482017-06-22T06:40:12 *** vicenteH has quit IRC
492017-06-22T06:40:31 *** vicenteH has joined #bitcoin-core-dev
502017-06-22T06:47:14 *** Ylbam has joined #bitcoin-core-dev
512017-06-22T06:49:22 *** JackH has joined #bitcoin-core-dev
522017-06-22T07:00:08 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10649: Make sure we only mine via the first wallet (master...2017/06/wallet_generate) https://github.com/bitcoin/bitcoin/pull/10649
532017-06-22T07:01:10 *** neel has joined #bitcoin-core-dev
542017-06-22T07:05:35 *** neel has quit IRC
552017-06-22T07:16:07 *** neel has joined #bitcoin-core-dev
562017-06-22T07:27:53 *** cheese_ has quit IRC
572017-06-22T07:38:04 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10650: Multiwallet: add RPC endpoint support (master...2017/06/wallet_rpc_endpoint) https://github.com/bitcoin/bitcoin/pull/10650
582017-06-22T07:46:02 *** d9b4bef9 has quit IRC
592017-06-22T07:47:07 *** d9b4bef9 has joined #bitcoin-core-dev
602017-06-22T07:49:16 *** neel has quit IRC
612017-06-22T07:51:28 *** neel has joined #bitcoin-core-dev
622017-06-22T08:01:07 *** neel has quit IRC
632017-06-22T08:23:19 *** ryanku___ has joined #bitcoin-core-dev
642017-06-22T08:25:25 *** ryankung_ has joined #bitcoin-core-dev
652017-06-22T08:28:19 *** ryanku___ has quit IRC
662017-06-22T08:29:27 *** Guyver2 has joined #bitcoin-core-dev
672017-06-22T08:34:27 *** ryankung_ has quit IRC
682017-06-22T08:34:57 *** ryankun__ has joined #bitcoin-core-dev
692017-06-22T08:39:11 *** ryankung_ has joined #bitcoin-core-dev
702017-06-22T08:40:16 *** neel has joined #bitcoin-core-dev
712017-06-22T08:41:38 *** neel has quit IRC
722017-06-22T08:41:56 *** Dyaheon has quit IRC
732017-06-22T08:42:46 *** Dyaheon has joined #bitcoin-core-dev
742017-06-22T08:43:06 *** neel has joined #bitcoin-core-dev
752017-06-22T08:53:31 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d083bd9b9c52...c68a9a69278a
762017-06-22T08:53:32 <bitcoin-git> bitcoin/master 5555fa8 MarcoFalke: qa: Add stopatheight test
772017-06-22T08:53:32 <bitcoin-git> bitcoin/master c68a9a6 MarcoFalke: Merge #10632: qa: Add stopatheight test...
782017-06-22T08:54:03 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10632: qa: Add stopatheight test (master...Mf1706-qaStopAtHeight) https://github.com/bitcoin/bitcoin/pull/10632
792017-06-22T09:01:14 *** riemann has joined #bitcoin-core-dev
802017-06-22T09:09:04 *** timothy has joined #bitcoin-core-dev
812017-06-22T09:18:31 *** neel has quit IRC
822017-06-22T09:24:45 *** neel has joined #bitcoin-core-dev
832017-06-22T09:25:05 *** arubi has quit IRC
842017-06-22T09:25:13 *** neel has joined #bitcoin-core-dev
852017-06-22T09:30:19 *** arubi has joined #bitcoin-core-dev
862017-06-22T09:50:10 *** neel has quit IRC
872017-06-22T09:51:42 *** neel has joined #bitcoin-core-dev
882017-06-22T09:59:31 *** neel has quit IRC
892017-06-22T10:02:46 *** neel has joined #bitcoin-core-dev
902017-06-22T10:05:04 *** luke-jr has quit IRC
912017-06-22T10:07:16 *** neel has quit IRC
922017-06-22T10:10:48 *** neel has joined #bitcoin-core-dev
932017-06-22T10:13:29 *** JackH has quit IRC
942017-06-22T10:13:46 *** luke-jr has joined #bitcoin-core-dev
952017-06-22T10:27:23 *** JackH has joined #bitcoin-core-dev
962017-06-22T11:00:32 *** Dyaheon has quit IRC
972017-06-22T11:03:56 *** Dyaheon has joined #bitcoin-core-dev
982017-06-22T11:06:29 *** neel has quit IRC
992017-06-22T11:12:04 *** ryankung_ has quit IRC
1002017-06-22T11:21:49 *** laurentmt has joined #bitcoin-core-dev
1012017-06-22T11:24:28 *** laurentmt has quit IRC
1022017-06-22T11:46:05 *** Alina-malina has quit IRC
1032017-06-22T12:01:50 *** Alina-malina has joined #bitcoin-core-dev
1042017-06-22T12:05:40 *** JackH has quit IRC
1052017-06-22T12:06:17 *** dabura667 has quit IRC
1062017-06-22T12:07:40 *** neel has joined #bitcoin-core-dev
1072017-06-22T12:08:22 *** riemann has quit IRC
1082017-06-22T12:09:10 *** gill3s has joined #bitcoin-core-dev
1092017-06-22T12:13:05 *** neel has quit IRC
1102017-06-22T12:17:12 *** neel has joined #bitcoin-core-dev
1112017-06-22T12:17:41 *** riemann has joined #bitcoin-core-dev
1122017-06-22T12:25:17 *** gill3s has quit IRC
1132017-06-22T12:32:17 *** Void_ has joined #bitcoin-core-dev
1142017-06-22T12:39:25 *** marcoagn1 has quit IRC
1152017-06-22T12:41:32 *** marcoagn1 has joined #bitcoin-core-dev
1162017-06-22T12:44:19 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1172017-06-22T12:47:37 *** marcoagn1 has quit IRC
1182017-06-22T12:51:06 *** marcoagn1 has joined #bitcoin-core-dev
1192017-06-22T12:56:05 *** Void_ is now known as pvoid
1202017-06-22T12:56:45 *** pvoid is now known as random
1212017-06-22T13:04:33 *** neel has quit IRC
1222017-06-22T13:04:34 *** laurentmt has joined #bitcoin-core-dev
1232017-06-22T13:17:10 *** vicenteH` has joined #bitcoin-core-dev
1242017-06-22T13:17:16 *** vicenteH has quit IRC
1252017-06-22T13:29:01 *** neel_ has joined #bitcoin-core-dev
1262017-06-22T13:32:00 *** ProfMac has quit IRC
1272017-06-22T13:32:25 *** jannes has joined #bitcoin-core-dev
1282017-06-22T13:44:45 *** Alina-malina has quit IRC
1292017-06-22T13:44:46 *** Alina-malina has joined #bitcoin-core-dev
1302017-06-22T13:53:25 *** Cheeseo has joined #bitcoin-core-dev
1312017-06-22T13:53:33 *** laurentmt has quit IRC
1322017-06-22T13:54:29 *** cheese_ has joined #bitcoin-core-dev
1332017-06-22T13:57:50 *** Cheeseo has quit IRC
1342017-06-22T14:03:00 *** Dyaheon has quit IRC
1352017-06-22T14:05:12 *** Dyaheon has joined #bitcoin-core-dev
1362017-06-22T14:11:57 *** Char0n has quit IRC
1372017-06-22T14:12:04 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c68a9a69278a...1d991f6f18df
1382017-06-22T14:12:04 <bitcoin-git> bitcoin/master 700d8d8 practicalswift: Remove obsolete _MSC_VER check...
1392017-06-22T14:12:05 <bitcoin-git> bitcoin/master 1d991f6 Wladimir J. van der Laan: Merge #10642: Remove obsolete _MSC_VER check...
1402017-06-22T14:12:49 <bitcoin-git> [bitcoin] laanwj closed pull request #10642: Remove obsolete _MSC_VER check (master...undefined-msc-ver) https://github.com/bitcoin/bitcoin/pull/10642
1412017-06-22T14:21:00 *** To7 has joined #bitcoin-core-dev
1422017-06-22T14:21:10 *** chjj has quit IRC
1432017-06-22T14:26:48 *** morcos has quit IRC
1442017-06-22T14:27:27 *** jnewbery_ has quit IRC
1452017-06-22T14:27:30 *** sdaftuar has quit IRC
1462017-06-22T14:27:44 *** zxzzt has quit IRC
1472017-06-22T14:28:50 *** morcos has joined #bitcoin-core-dev
1482017-06-22T14:29:19 *** zxzzt has joined #bitcoin-core-dev
1492017-06-22T14:29:26 *** sdaftuar has joined #bitcoin-core-dev
1502017-06-22T14:29:26 *** sdaftuar has joined #bitcoin-core-dev
1512017-06-22T14:29:36 *** jnewbery has joined #bitcoin-core-dev
1522017-06-22T14:31:06 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1d991f6f18df...8465b68985f4
1532017-06-22T14:31:07 <bitcoin-git> bitcoin/master 2c3fc51 fanquake: [depends] expat 2.2.1
1542017-06-22T14:31:07 <bitcoin-git> bitcoin/master 8465b68 Wladimir J. van der Laan: Merge #10628: [depends] expat 2.2.1...
1552017-06-22T14:31:54 <bitcoin-git> [bitcoin] laanwj closed pull request #10628: [depends] expat 2.2.1 (master...expat-2-2-1) https://github.com/bitcoin/bitcoin/pull/10628
1562017-06-22T14:32:40 *** Char0n has joined #bitcoin-core-dev
1572017-06-22T14:33:46 <sdaftuar> sipa: i've finished my functional test for #10148 -- https://github.com/sdaftuar/bitcoin/tree/test-10148
1582017-06-22T14:33:50 <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
1592017-06-22T14:47:12 *** neel_ has quit IRC
1602017-06-22T14:49:05 *** neel has joined #bitcoin-core-dev
1612017-06-22T14:57:00 *** riemann has quit IRC
1622017-06-22T15:04:20 <bitcoin-git> [bitcoin] laanwj closed pull request #10541: Docs: Update INSTALL.md to add link to build notes (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10541
1632017-06-22T15:10:37 *** echonaut3 has quit IRC
1642017-06-22T15:10:48 *** echonaut has joined #bitcoin-core-dev
1652017-06-22T15:17:02 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8465b68985f4...87e69c2549c4
1662017-06-22T15:17:02 <bitcoin-git> bitcoin/master e5c6168 Pavlos Antoniou: Fix instantiation and array accesses in class base_uint<BITS>...
1672017-06-22T15:17:03 <bitcoin-git> bitcoin/master 87e69c2 Wladimir J. van der Laan: Merge #10530: Fix invalid instantiation and possibly unsafe accesses of array in class base_uint<BITS>...
1682017-06-22T15:17:43 <bitcoin-git> [bitcoin] laanwj closed pull request #10530: Fix invalid instantiation and possibly unsafe accesses of array in class base_uint<BITS> (master...master) https://github.com/bitcoin/bitcoin/pull/10530
1692017-06-22T15:20:07 *** rafalcpp has quit IRC
1702017-06-22T15:20:53 *** rafalcpp has joined #bitcoin-core-dev
1712017-06-22T15:31:02 *** neel has quit IRC
1722017-06-22T15:37:41 *** neel has joined #bitcoin-core-dev
1732017-06-22T15:39:52 *** neel has quit IRC
1742017-06-22T15:43:14 *** laurentmt has joined #bitcoin-core-dev
1752017-06-22T15:43:41 *** laurentmt has quit IRC
1762017-06-22T15:44:04 <bitcoin-git> [bitcoin] laanwj closed pull request #8831: Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue (master...2016-09-28-cwallet-loadkeyvalue) https://github.com/bitcoin/bitcoin/pull/8831
1772017-06-22T15:44:53 *** Dizzle has joined #bitcoin-core-dev
1782017-06-22T15:45:48 *** abpa has joined #bitcoin-core-dev
1792017-06-22T15:46:25 *** arubi has quit IRC
1802017-06-22T15:51:56 *** arubi has joined #bitcoin-core-dev
1812017-06-22T15:57:41 *** neel has joined #bitcoin-core-dev
1822017-06-22T16:01:23 *** laurentmt has joined #bitcoin-core-dev
1832017-06-22T16:08:00 *** neel has quit IRC
1842017-06-22T16:09:16 *** neel has joined #bitcoin-core-dev
1852017-06-22T16:11:05 *** nelruk has joined #bitcoin-core-dev
1862017-06-22T16:17:36 *** Guyver2_ has joined #bitcoin-core-dev
1872017-06-22T16:19:57 *** def has joined #bitcoin-core-dev
1882017-06-22T16:20:15 <earlz> Why is CheckTransaction in CheckBlock just a normal rejection and not a DoS rejection? Is there some valid case where CheckTransaction can fail and it not be a malicious actor?
1892017-06-22T16:20:37 *** Guyver2 has quit IRC
1902017-06-22T16:20:40 *** Guyver2_ is now known as Guyver2
1912017-06-22T16:23:31 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/87e69c2549c4...209eef60a9ac
1922017-06-22T16:23:31 <bitcoin-git> bitcoin/master 6171826 Alex Morcos: Don't create change at the dust limit, even if it means paying more than expected
1932017-06-22T16:23:32 <bitcoin-git> bitcoin/master 209eef6 Wladimir J. van der Laan: Merge #9343: Don't create change at dust limit...
1942017-06-22T16:23:41 <sipa> earlz: yes!
1952017-06-22T16:23:43 <bitcoin-git> [bitcoin] laanwj closed pull request #9343: Don't create change at dust limit (master...noneconomicchange) https://github.com/bitcoin/bitcoin/pull/9343
1962017-06-22T16:23:46 <sipa> soft forks
1972017-06-22T16:24:03 <sipa> earlz: the peer may not be aware of a softfork that you are aware of
1982017-06-22T16:25:13 <def> https://0x0.st/lFn.txt <- i can't get signrawtransaction to work, any ideas? i know this isn't a support channel but i'm becoming increasingly convinced that this might be a bug in bitcoin-qt
1992017-06-22T16:33:29 *** nelruk has quit IRC
2002017-06-22T16:34:00 <sipa> def: can you show the output you are trying to spend?
2012017-06-22T16:35:43 <earlz> ah, didn't think about softforks
2022017-06-22T16:35:48 *** CryptoAna has joined #bitcoin-core-dev
2032017-06-22T16:38:44 *** nelruk has joined #bitcoin-core-dev
2042017-06-22T16:38:53 *** neel has joined #bitcoin-core-dev
2052017-06-22T16:39:40 *** neel has quit IRC
2062017-06-22T16:43:23 *** CryptoAna has quit IRC
2072017-06-22T16:46:05 *** nelruk has quit IRC
2082017-06-22T16:50:24 *** nelruk has joined #bitcoin-core-dev
2092017-06-22T16:54:59 *** nelruk has quit IRC
2102017-06-22T17:00:28 *** timothy has quit IRC
2112017-06-22T17:00:32 *** nelruk has joined #bitcoin-core-dev
2122017-06-22T17:07:03 *** nelruk has quit IRC
2132017-06-22T17:10:19 *** nelruk has joined #bitcoin-core-dev
2142017-06-22T17:16:57 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/209eef60a9ac...ffce893982d9
2152017-06-22T17:16:58 <bitcoin-git> bitcoin/master fd369d2 Kalle Alm: Switched httpserver.cpp to use RAII wrapped libevents.
2162017-06-22T17:16:59 <bitcoin-git> bitcoin/master 1ae86ec Karl-Johan Alm: Changed event RAII helper functions to inline to deal with duplicate symbol linker errors.
2172017-06-22T17:16:59 <bitcoin-git> bitcoin/master ffce893 Wladimir J. van der Laan: Merge #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents....
2182017-06-22T17:17:08 <bitcoin-git> [bitcoin] laanwj closed pull request #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents. (master...raii-httpserver) https://github.com/bitcoin/bitcoin/pull/9517
2192017-06-22T17:17:59 *** nelruk has quit IRC
2202017-06-22T17:20:06 *** nelruk has joined #bitcoin-core-dev
2212017-06-22T17:27:53 *** nelruk has quit IRC
2222017-06-22T17:30:46 *** nelruk has joined #bitcoin-core-dev
2232017-06-22T17:33:31 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ffce893982d9...b750b33c3cea
2242017-06-22T17:33:31 <bitcoin-git> bitcoin/master 8d4dafd Andres G. Aragoneses: contrib/verifybinaries: allow filtering by platform...
2252017-06-22T17:33:32 <bitcoin-git> bitcoin/master b750b33 Wladimir J. van der Laan: Merge #10276: contrib/verifybinaries: allow filtering by platform...
2262017-06-22T17:33:51 <bitcoin-git> [bitcoin] laanwj closed pull request #10276: contrib/verifybinaries: allow filtering by platform (master...filterByPlatformInVerifySh) https://github.com/bitcoin/bitcoin/pull/10276
2272017-06-22T17:46:19 *** gaf_ has quit IRC
2282017-06-22T17:51:04 *** gaf_ has joined #bitcoin-core-dev
2292017-06-22T17:54:59 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b750b33c3cea...01c4b143a87e
2302017-06-22T17:54:59 <bitcoin-git> bitcoin/master cf68a48 Pieter Wuille: Deduplicate addrdb.cpp and use CHashWriter/Verifier
2312017-06-22T17:55:00 <bitcoin-git> bitcoin/master 01c4b14 Wladimir J. van der Laan: Merge #10248: Rewrite addrdb with less duplication using CHashVerifier...
2322017-06-22T17:55:24 <bitcoin-git> [bitcoin] laanwj closed pull request #10248: Rewrite addrdb with less duplication using CHashVerifier (master...chashverifier) https://github.com/bitcoin/bitcoin/pull/10248
2332017-06-22T17:59:18 *** paveljanik has joined #bitcoin-core-dev
2342017-06-22T18:04:51 *** SopaXorzTaker has joined #bitcoin-core-dev
2352017-06-22T18:05:38 <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10651: Verify binaries from bitcoincore.org and bitcoin.org (master...2017-06-verify-coreorg) https://github.com/bitcoin/bitcoin/pull/10651
2362017-06-22T18:09:29 *** Dyaheon has quit IRC
2372017-06-22T18:10:01 *** Dyaheon has joined #bitcoin-core-dev
2382017-06-22T18:18:17 *** laurentmt has quit IRC
2392017-06-22T18:18:28 *** def has left #bitcoin-core-dev
2402017-06-22T18:19:07 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/01c4b143a87e...4bc853b50fd9
2412017-06-22T18:19:08 <bitcoin-git> bitcoin/master 999923e MarcoFalke: [qa] util: Check return code after closing bitcoind proc...
2422017-06-22T18:19:09 <bitcoin-git> bitcoin/master 4bc853b MarcoFalke: Merge #10636: [qa] util: Check return code after closing bitcoind proc...
2432017-06-22T18:19:41 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10636: [qa] util: Check return code after closing bitcoind proc (master...Mf1706-qaTraceback) https://github.com/bitcoin/bitcoin/pull/10636
2442017-06-22T18:25:29 *** eenoch has quit IRC
2452017-06-22T18:25:38 *** bordeaux_facile has quit IRC
2462017-06-22T18:32:33 *** bordeaux_facile has joined #bitcoin-core-dev
2472017-06-22T18:41:27 *** nelsondcg has joined #bitcoin-core-dev
2482017-06-22T18:42:50 *** nelruk has quit IRC
2492017-06-22T18:44:28 *** mryandao has quit IRC
2502017-06-22T18:44:57 *** mryandao has joined #bitcoin-core-dev
2512017-06-22T18:44:57 *** mryandao has joined #bitcoin-core-dev
2522017-06-22T18:46:57 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4bc853b50fd9...6bef7ca8bc6a
2532017-06-22T18:46:58 <bitcoin-git> bitcoin/master 0a5a6b9 Dimitris Tsapakidis: Fixed multiple typos...
2542017-06-22T18:46:58 <bitcoin-git> bitcoin/master 6bef7ca Wladimir J. van der Laan: Merge #10633: doc: Fix various typos...
2552017-06-22T18:47:32 <bitcoin-git> [bitcoin] laanwj closed pull request #10633: doc: Fix various typos (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10633
2562017-06-22T18:48:59 *** eenoch has joined #bitcoin-core-dev
2572017-06-22T18:57:43 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/6bef7ca8bc6a...8c2098ad1209
2582017-06-22T18:57:44 <bitcoin-git> bitcoin/master c8914b9 Andrew Chow: Have `make cov` optionally include branch coverage statistics...
2592017-06-22T18:57:44 <bitcoin-git> bitcoin/master 405b86a Andrew Chow: Replace lcov -r commands with faster way...
2602017-06-22T18:57:45 <bitcoin-git> bitcoin/master d5711f4 Andrew Chow: Filter subtrees and and benchmarks from coverage report...
2612017-06-22T18:58:27 <bitcoin-git> [bitcoin] laanwj closed pull request #10565: [coverage] Remove subtrees and benchmarks from coverage report (master...lcov-remove-extra) https://github.com/bitcoin/bitcoin/pull/10565
2622017-06-22T19:00:40 <BlueMatt> meeting?
2632017-06-22T19:00:45 <wumpus> #startmeeting
2642017-06-22T19:00:45 <lightningbot> Meeting started Thu Jun 22 19:00:45 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2652017-06-22T19:00:45 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2662017-06-22T19:00:52 <achow101> hi
2672017-06-22T19:00:56 <jonasschnelli> hi
2682017-06-22T19:00:58 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
2692017-06-22T19:01:05 <cfields> hi
2702017-06-22T19:01:07 <wumpus> topics?
2712017-06-22T19:01:16 <sipa> ohai
2722017-06-22T19:01:46 <wumpus> #topic high priority for review
2732017-06-22T19:01:47 *** jtimon has joined #bitcoin-core-dev
2742017-06-22T19:01:48 <wumpus> #link https://github.com/bitcoin/bitcoin/projects/8
2752017-06-22T19:02:10 <wumpus> any new ones?
2762017-06-22T19:02:32 <BlueMatt> should i give up on #10179 (+ #10286)?
2772017-06-22T19:02:35 <gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
2782017-06-22T19:02:36 <BlueMatt> at least for 15
2792017-06-22T19:02:38 <gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
2802017-06-22T19:02:49 <sipa> BlueMatt: no
2812017-06-22T19:02:51 <kanzure> hi.
2822017-06-22T19:03:11 <BlueMatt> sipa: well i mean point being that is something that really needs to stew in master for a month (or more) before a release
2832017-06-22T19:03:17 <BlueMatt> so its hitting up against the 15 deadline already
2842017-06-22T19:03:22 <wumpus> why give up?
2852017-06-22T19:03:28 <instagibbs> hi
2862017-06-22T19:03:29 <BlueMatt> not a huge deal to push to 16
2872017-06-22T19:03:44 <BlueMatt> because i dont want to ship 10286 right after merging it
2882017-06-22T19:03:56 <BlueMatt> its a real not-gonna-see-the-issues-unless-its-in-master-for-a-month kinda thing :(
2892017-06-22T19:04:26 <wumpus> that's about the risk - what would be the main gain for merging it for 0.15?
2902017-06-22T19:04:46 <wumpus> eh it's already in high-priority for review category
2912017-06-22T19:05:10 <wumpus> we can't bump it anything higher :p
2922017-06-22T19:05:14 <BlueMatt> well im asking if we should drop it from high priority, unless we still think we can get both in pretty quick i think we should say we wont until its 16
2932017-06-22T19:05:17 <jtimon> I would like review on #8498
2942017-06-22T19:05:21 <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
2952017-06-22T19:05:56 <wumpus> ok, but I mean, what would we lose if we decide to drop it for 0.15. Is there something else would be prioritized before it?
2962017-06-22T19:06:16 <wumpus> I don't think it collides with e.g. multiwallet
2972017-06-22T19:06:18 *** ryanofsky_ is now known as ryanofsky
2982017-06-22T19:06:27 <BlueMatt> just 10286 - the dont-really-block-on-wallet-for-block-connection thing
2992017-06-22T19:06:42 <BlueMatt> its not itself a huge win, but iterative steps towards better disconnection
3002017-06-22T19:06:46 <cfields> BlueMatt: I'll try to get through it today, I've put it off long enough :)
3012017-06-22T19:06:54 <BlueMatt> i know ryanofsky wanted it for the separate-process-wallet stuff he was working on
3022017-06-22T19:07:00 <sipa> BlueMatt: how about we re-assess it next week?
3032017-06-22T19:07:06 <BlueMatt> ok, sounds good
3042017-06-22T19:07:07 <jtimon> and #8994 too, not sure which one is more likely to get it
3052017-06-22T19:07:07 <wumpus> looks like they're both getting reviews
3062017-06-22T19:07:08 <sipa> and hope for review in the mean time
3072017-06-22T19:07:10 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
3082017-06-22T19:07:12 <wumpus> yeah...
3092017-06-22T19:07:27 <ryanofsky> yeah i'd prefer 10286 not to be delayed for months
3102017-06-22T19:07:41 *** SopaXorzTaker has quit IRC
3112017-06-22T19:08:21 <jonasschnelli> #10286
3122017-06-22T19:08:24 <gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
3132017-06-22T19:09:00 <wumpus> ok, any other topics?
3142017-06-22T19:09:02 <jtimon> wumpus: well, maybe none of my prs should be in project 8, I don't know
3152017-06-22T19:09:23 *** nel has joined #bitcoin-core-dev
3162017-06-22T19:09:27 <phantomcircuit> pong
3172017-06-22T19:09:28 <sipa> wumpus: coin selection / effective feerate / bnb
3182017-06-22T19:09:31 <wumpus> jtimon: I'm not sure that one warrants extra priority pre-0.15
3192017-06-22T19:09:32 <BlueMatt> random PSA: there is now a copy of binaries hosted on https://bitcoincore.org/bin as well as https://bitcoin.org/bin. This will be the new "official" download site (though the bitcoin.org folks said they were gonna keep their mirror up for those who are used to bitcoin.org to not have to hop to another site)
3202017-06-22T19:10:05 <wumpus> sipa: that's one topic or three?
3212017-06-22T19:10:10 <sipa> wumpus: one
3222017-06-22T19:10:18 <wumpus> #topic coin selection / effective feerate / bnb
3232017-06-22T19:10:41 <sipa> we have a number of open PRs (and one just merged I think) that interact with coin selection
3242017-06-22T19:10:44 <jtimon> wumpus: egoistically for elements project, it would be very nice to have #8994 before 0.15 for next elements rebase (not that bitcoin should care)
3252017-06-22T19:10:46 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
3262017-06-22T19:11:23 <sipa> #10637 #10360 #10333
3272017-06-22T19:11:24 <jtimon> regarding #8498 it's an optimization (perhaps again "not worth it", like #10339)
3282017-06-22T19:11:25 <gribble> https://github.com/bitcoin/bitcoin/issues/10360 | [WIP] [Wallet] Target effective value during transaction creation by instagibbs · Pull Request #10360 · bitcoin/bitcoin · GitHub
3292017-06-22T19:11:27 <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
3302017-06-22T19:11:29 <gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p⦠by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
3312017-06-22T19:11:30 <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
3322017-06-22T19:11:32 <gribble> https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub
3332017-06-22T19:11:59 <sipa> are instagibbs, achow101, ... here?
3342017-06-22T19:12:02 <instagibbs> I'm not sure many are even close to merge.
3352017-06-22T19:12:04 <instagibbs> yeah
3362017-06-22T19:12:10 <sipa> i agree
3372017-06-22T19:12:17 <achow101> i'm here
3382017-06-22T19:12:18 *** nelsondcg has quit IRC
3392017-06-22T19:12:18 <gmaxwell> Hellow meeting.
3402017-06-22T19:12:18 <instagibbs> 10333 is closest, but needs more revision
3412017-06-22T19:12:22 <sipa> but i think there are two approaches to follow here
3422017-06-22T19:12:36 <wumpus> jtimon: I really think we should have #8994, but it seems to collide with a lot of other things
3432017-06-22T19:12:39 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
3442017-06-22T19:13:14 <sipa> one is to aim for overhauling coin selection... which will take a long time, and probably should be merged early in a cycle, so not for 0.15
3452017-06-22T19:13:27 <gmaxwell> 10333 needs to get in (in some form) because it's an important fix.
3462017-06-22T19:13:46 <instagibbs> I can do suggested change that gmaxwell gave, which I noted.
3472017-06-22T19:13:50 <sipa> another is to make changes that 1) fix existing bugs and 2) work as a preprocessing step (in the form "let's see if algorithm X finds a good solution... otherwise fallback to what exists"
3482017-06-22T19:14:11 <wumpus> agree with doing coin selection changes early in a release cycle
3492017-06-22T19:14:15 <sipa> if 10333 is considered a bug fix, perhaps it should be prioritized for 0.15?
3502017-06-22T19:14:15 <jtimon> wumpus: I guess that will wait forever then, previous versions were closed because they "collided with mempool/fee stuff", like more than 1 year ago? I'm happy to help people do the trivial rebases for people if that's the problem
3512017-06-22T19:14:34 <jtimon> anyway, topic changed...
3522017-06-22T19:14:37 <gmaxwell> 10333 should do nothing other than prevent serious overpayment in some corner cases.
3532017-06-22T19:14:44 <instagibbs> sipa, It's marked as such, but if people deem it higher priority I'll make it one
3542017-06-22T19:15:05 <gmaxwell> (at least once it's twiddled some)
3552017-06-22T19:15:38 <sipa> would 10333 + 10637 be reasonable to aim for in 0.15?
3562017-06-22T19:15:43 <instagibbs> It needs rebasing likely due to recent dust change merge
3572017-06-22T19:15:47 <instagibbs> #10637
3582017-06-22T19:15:49 <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
3592017-06-22T19:16:03 <wumpus> I don't think so
3602017-06-22T19:16:22 <instagibbs> latter seems a stretch imo, as great as it would be.
3612017-06-22T19:16:23 <wumpus> #10637 would be better for 0.16 IMO
3622017-06-22T19:16:26 <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
3632017-06-22T19:16:30 <sipa> to clarify, 10637 is just a preprocessing step that makes it much more likely to find a match without change, reducing UTXO set size
3642017-06-22T19:16:32 <wumpus> the other one is already marked for 0.15
3652017-06-22T19:16:37 <sipa> if it fails, it falls back to what we have
3662017-06-22T19:16:46 <achow101> I don't think 10637 would be good for 0.15. I haven't entirely made sure that it doesn't do anything stupid
3672017-06-22T19:16:52 <instagibbs> sipa, if the code is correct, sure, earlier it wasn't (I'd have to do lots of review to make sure)
3682017-06-22T19:16:53 <sipa> ok
3692017-06-22T19:16:58 <sipa> instagibbs: of course
3702017-06-22T19:17:02 <gmaxwell> I am not in favor of takin total overhaul as a general strategy. The problem is that each logical change has a complex 'whole system impact' question connected to it, which is really hard to reasona about for "hay guies, I replaced the whole thing!" So I would much rather see a series of 'obviously sane' changes followed by "I reworked it to make the code clearer with no substantive change in b
3712017-06-22T19:17:05 <wumpus> achow101: agree, no need to hurry it just to make a release
3722017-06-22T19:17:07 <instagibbs> it's a nasty web of code, not his fault, just a fact
3732017-06-22T19:17:08 <gmaxwell> ehavior".
3742017-06-22T19:17:36 <sipa> ok, so let's aim for all coin selection changes in 0.16
3752017-06-22T19:17:39 <sipa> apart from bug fixes
3762017-06-22T19:17:47 <wumpus> the problem is that at some point the code is so convoluted that no option remains but 'redesign the whole thing'
3772017-06-22T19:17:58 <jtimon> yeah, I've been trying to do something like #8494 since at least Jun 10, 2015, but I think actually earlier
3782017-06-22T19:17:58 <gmaxwell> :( is it so late to the end of 0.15 that we're slipping things out of it?
3792017-06-22T19:18:00 <gribble> https://github.com/bitcoin/bitcoin/issues/8494 | [init, wallet] ParameterInteraction() iff wallet enabled by MarcoFalke · Pull Request #8494 · bitcoin/bitcoin · GitHub
3802017-06-22T19:18:07 <wumpus> most of that has been replaced by now, but the coin selection code is arguably some of that
3812017-06-22T19:18:20 <sipa> gmaxwell: i wish you were right, but i believe at some point we'll need to bite the bullet
3822017-06-22T19:18:38 <sipa> though a number of steps can be taken before that point
3832017-06-22T19:18:41 <wumpus> gmaxwell: well it starts to be important, even now, to prioritize things
3842017-06-22T19:18:50 <instagibbs> With BnB in place, lays decent groundwork for more extensions
3852017-06-22T19:18:52 <gmaxwell> wumpus: will then we stay where we've been stuck for years then? I think it improved a lot, changes we made in 0.14 cleaned up CreateTransaction a lot.
3862017-06-22T19:19:30 <jtimon> gmaxwell: agree on that way of doing big refactors, that's the sanest way to review them at least
3872017-06-22T19:19:32 <instagibbs> making sane change-making policy could come next
3882017-06-22T19:19:45 <instagibbs> sane steps exist i think
3892017-06-22T19:20:01 *** nelsondcg has joined #bitcoin-core-dev
3902017-06-22T19:21:34 <gmaxwell> sipa: obviously it needs to be reworked, but I cannot review something that is just "here is replacement code that does everything subtly differently" against threats like "will this cause runaway upbidding" or "will this potentially cause the utxo set size to skyrocket relative to the current code" or "will this trash user privacy" (well hard do to worse than the current on that mark. :P). But
3912017-06-22T19:21:40 <gmaxwell> I can review things like instagibbs's effective rate change against those criteria.
3922017-06-22T19:22:17 <gmaxwell> I think it's important to seperate intentional behavioral changes from implementation structure.
3932017-06-22T19:22:18 <jtimon> so why not try to get merged 10333 first which seems the simpler to review and then revisit the other 2 ?
3942017-06-22T19:22:35 <gmaxwell> jtimon: instagibbs has changes he needs to make.
3952017-06-22T19:22:40 <gmaxwell> And sure.
3962017-06-22T19:22:43 * jtimon nods
3972017-06-22T19:22:46 *** nel has quit IRC
3982017-06-22T19:22:48 <sipa> gmaxwell: i'm worried about something like 10360 to cause unintended runaway behaviour due to some interaction as well
3992017-06-22T19:22:49 <wumpus> jtimon: yes
4002017-06-22T19:23:07 <sipa> gmaxwell: even if it looks perfectly fine by all metrics we considered
4012017-06-22T19:23:17 <gmaxwell> Though if integrated correctly (not saying it is yet) 10637 is just a preprocessing stage that can't make things worse. (not saying that it's yet integrated correctly).
4022017-06-22T19:23:30 <instagibbs> Action item is me incorporating suggestion to 10333 make more robust and beg for review again here
4032017-06-22T19:23:46 <wumpus> so should we add 10333 to high priority for review?
4042017-06-22T19:24:39 <achow101> imo, yes
4052017-06-22T19:25:01 <gmaxwell> sipa: I don't think it looks fine, I think it fixes a flaw we depend on due to a ~total lack of other mechenisms to sweep txins.
4062017-06-22T19:25:54 <sipa> gmaxwell: yes, but i can't reason about its total effect
4072017-06-22T19:26:16 <gmaxwell> (it's easy to show that 10360 will abandon more txouts than current code; and also the current code will _create_ txouts that an immediate second run under that patch would not consider spending)
4082017-06-22T19:26:17 <sipa> i like the change as such, but who knows what interaction we missed
4092017-06-22T19:26:58 <sipa> anyway, probably a discussion for later
4102017-06-22T19:26:58 <gmaxwell> So the only thing I don't know if the effect would be castrophic or just merely not perfect.
4112017-06-22T19:27:11 <sipa> yes, i think 10333 should be prioritized
4122017-06-22T19:27:17 <gmaxwell> ack on 10333.
4132017-06-22T19:27:44 <wumpus> ok, added
4142017-06-22T19:28:19 <gmaxwell> sipa: I think a simple invarient is that we must spend everything we create at least under more or less stationary conditions. Anything less leads to runaway utxo set growth (though perhaps slowly...).
4152017-06-22T19:29:02 <gmaxwell> but thats a minimum and perhaps not sufficient. But still 10360 fails it.
4162017-06-22T19:29:50 <gmaxwell> to be fair, it's not 10360's fault so much as that we only pass that criteria now due to bugs that 10360 fixes.
4172017-06-22T19:30:31 <sipa> other topics?
4182017-06-22T19:31:05 <cfields> quick topic suggestion: add "strongly discourage/forbit default function arguments" to the style guide?
4192017-06-22T19:31:28 <luke-jr> cfields: eh, I don't think that's a good idea
4202017-06-22T19:31:30 <wumpus> #topic add "strongly discourage/forbit default function arguments" to the style guide
4212017-06-22T19:31:31 <cfields> *forbid. forbitting would be too much :p
4222017-06-22T19:31:32 <BlueMatt> not always
4232017-06-22T19:31:37 <wumpus> f-orbitting
4242017-06-22T19:31:47 <gmaxwell> default arguments are a footgun for sure, can we articluate where they are okay-- if they aren't forbidden?
4252017-06-22T19:31:49 <sipa> f(ire from) orbit?
4262017-06-22T19:31:52 <wumpus> no, I don't think that's a good rule in general either
4272017-06-22T19:31:52 <luke-jr> the important thing should be making sure the behaviour doesn't change, when func signatures change
4282017-06-22T19:31:57 <BlueMatt> if theres 20 arguments to the function or its a big many-callers function, maybe
4292017-06-22T19:32:12 <cfields> gmaxwell: yes, i think that's the discussion I was looking for.
4302017-06-22T19:32:24 <luke-jr> "if code calling it before compiles with the new signature, it must behave the same"
4312017-06-22T19:32:25 <wumpus> if there's 20 arguments to a function there's something wrong in general
4322017-06-22T19:32:30 <BlueMatt> but depends on where, eg I think https://github.com/bitcoin/bitcoin/pull/10179/commits/dd53c6f0a3f9fa34b0d8d0f6b9a3e4df51a3eda7 is probably fine
4332017-06-22T19:32:31 <wumpus> please make a rule not to have 20 arguments please
4342017-06-22T19:32:35 <wumpus> certainly not booleans :(
4352017-06-22T19:32:39 <BlueMatt> (adds a default arg to CScheduler::schedule())
4362017-06-22T19:32:44 <BlueMatt> wumpus: lol, yes, indeed
4372017-06-22T19:32:48 <sipa> "It is strongly encouraged to have 19 arguments to functions."
4382017-06-22T19:32:49 <wumpus> Foo(false, true, false, true, false, true, true)
4392017-06-22T19:33:09 <BlueMatt> wumpus: you forgot the NULL for good measure which may or may not be a pointer :p
4402017-06-22T19:33:16 <wumpus> BlueMatt: oh yes
4412017-06-22T19:33:42 <wumpus> default arguments are mostly good for one thing: transitions without touching all the code
4422017-06-22T19:33:43 <gmaxwell> I think the default arg is okay when going from 0 to 1 arguments to add a flag, for example.
4432017-06-22T19:33:55 <sipa> well i think defaults arguments are often used to reduce code impact of a patch... adding an optional argument at the end (especially directly after a non-optional one, and with a type incompatible with the first optional one if any) is perfectly safe and can strongly reduce the amount of code touched
4442017-06-22T19:34:13 <sipa> the same can be achieved by adding a fewer-arguments wrapper, though
4452017-06-22T19:34:17 <wumpus> e.g. if you add an argument to a function that's called from 400 places, it's usually better to add a default argument, at least temporarily
4462017-06-22T19:34:49 <wumpus> right. I think that's a valid use.
4472017-06-22T19:34:58 <sipa> i like the approach of creating a new function (with more args, and perhaps even a different name), and changing the old one to be a wrapper around the new one
4482017-06-22T19:35:07 <luke-jr> indeed, I have been rebasing the rescanblockchain RPC, and this is needed to minimise the conflicts
4492017-06-22T19:35:18 <gmaxwell> The defaults lead to negative interactions with the fact that arguments aren't named. I like sipa's suggestion.
4502017-06-22T19:35:22 <wumpus> well if it has the same name there is no effective difference
4512017-06-22T19:35:27 <luke-jr> (it adds an argument for a stop-scanning index)
4522017-06-22T19:35:33 <BlueMatt> sipa: thats how you end up with AcceptToMemoryPoolWorker(tx, true, false, false, true, NULL, (default) false)
4532017-06-22T19:35:34 <BlueMatt> :(
4542017-06-22T19:35:36 *** justanotheruser has joined #bitcoin-core-dev
4552017-06-22T19:35:46 <gmaxwell> wumpus: because when you make further additions to the arguments, you don't mess things up.
4562017-06-22T19:35:52 <sipa> that wrapper approach also is more restrictive: it _just_ allows the exact old use case, and a new one - not a variety of combinations based on multiple optional args
4572017-06-22T19:36:10 <wumpus> absent argument naming, I like enums better than booleans
4582017-06-22T19:36:23 <wumpus> anyhow, no, I don't think we should add a general rule about this
4592017-06-22T19:36:28 <gmaxwell> We had a near consensus fault in the main split as a result of something related to this. IIRC.
4602017-06-22T19:36:29 <wumpus> just pay attention at reviews to the specific case
4612017-06-22T19:36:49 * luke-jr wishes there was a tool to audit such changes for us
4622017-06-22T19:36:49 <cfields> ok
4632017-06-22T19:36:54 <wumpus> not everything has to be spelled out in the style guide, that just makes for laziness *we've checked all the checkboxes*
4642017-06-22T19:37:05 <gmaxwell> right
4652017-06-22T19:37:23 <sipa> also, i wish there was a sed-like took that understood our AST a bit better, so you could add a new argument to a function everywhere
4662017-06-22T19:37:37 <sipa> but regexps are fundamentally not strong enough to do that :(
4672017-06-22T19:37:42 <wumpus> if only c++ was easier to parse...
4682017-06-22T19:37:52 <gmaxwell> though I still think sipa's suggestion is good: if you need to introduce an argument to a function called in many places, wrap it with something that provides the default. Then over time we change call sites to call the new function.
4692017-06-22T19:37:54 <luke-jr> at least it's not Perl
4702017-06-22T19:37:57 <wumpus> you can do things like that using python + clang, but it's pretty involved, and not fun
4712017-06-22T19:37:59 *** justan0theruser has quit IRC
4722017-06-22T19:38:07 *** jannes has quit IRC
4732017-06-22T19:38:28 <jtimon> ack on strongly discouraging optional arguments, we have way too many and some are really stupid IMO (ehem, ehem #9717 )
4742017-06-22T19:38:30 <gribble> https://github.com/bitcoin/bitcoin/issues/9717 | Pow: Remove fCheckPOW from CheckBlockHeader by jtimon · Pull Request #9717 · bitcoin/bitcoin · GitHub
4752017-06-22T19:38:33 <gmaxwell> then we don't end up with function signatures that are full of a mix of default and non-default arguments.
4762017-06-22T19:38:52 <wumpus> even if you have a c++ parser you get such a lot of information into your mutation function, so many cases to handle
4772017-06-22T19:39:33 <wumpus> gmaxwell: I fully agree, just don't think it makes sense as a rule
4782017-06-22T19:39:39 <gmaxwell> ACK
4792017-06-22T19:40:08 <jtimon> you can also have simpler wrappers on functions with less parameters and "default values" instead of optional arguments
4802017-06-22T19:40:22 <wumpus> yes
4812017-06-22T19:40:31 <gmaxwell> yea, thats what sipa was just saying.
4822017-06-22T19:40:33 <sipa> jtimon: that's what i was suggestion
4832017-06-22T19:40:52 <jtimon> sipa: sorry, catching up...
4842017-06-22T19:40:59 <wumpus> though the advantage of default arguments is that they're self-documenting in the function signature
4852017-06-22T19:42:08 <wumpus> anyhow, more topics?
4862017-06-22T19:42:13 *** justanotheruser has quit IRC
4872017-06-22T19:42:22 <sipa> do we want to bring up multiwallet API again?
4882017-06-22T19:42:25 <jonasschnelli> yes
4892017-06-22T19:42:29 <gmaxwell> I don't think I've personally found that too useful except for functions with just a couple arguments with one or two simple flags. FrobThing(&thing,FrobHarder=true).
4902017-06-22T19:42:33 <wumpus> #topic multiwallet API
4912017-06-22T19:42:39 <jonasschnelli> can we decide what we want to use? path or query string and or versioning?
4922017-06-22T19:42:46 <wumpus> path
4932017-06-22T19:42:49 <jonasschnelli> I think /v1/wallet/<walletid> seems ideal
4942017-06-22T19:42:50 *** justanotheruser has joined #bitcoin-core-dev
4952017-06-22T19:43:01 <gmaxwell> can we at least put a version in first?
4962017-06-22T19:43:01 <wumpus> we've decided that last time, that wallet will be based on endpoints
4972017-06-22T19:43:01 <luke-jr> query string <.<
4982017-06-22T19:43:12 <jonasschnelli> gmaxwell: yes. See above
4992017-06-22T19:43:19 <sipa> luke-jr: i've been thinking about the advantages and disadvantages of both
5002017-06-22T19:43:23 <jonasschnelli> luke-jr: what advantages do you see with query strings?
5012017-06-22T19:43:25 <wumpus> oh sure /v1/something is fine with me
5022017-06-22T19:43:43 <luke-jr> jonasschnelli: it's not hacking the path into a parameter? it's extensible?
5032017-06-22T19:43:45 <wumpus> if we can use /v1 as the general node endpoint hten
5042017-06-22T19:43:54 <sipa> query string has the advantage that it's more flexible - there could be multiple things to direct the RPC, and they don't need to be in a hierarchical pattern
5052017-06-22T19:43:57 <wumpus> and /v1/walletname for the wallet
5062017-06-22T19:44:05 <wumpus> don't use query strings with POST
5072017-06-22T19:44:06 <wumpus> just don't
5082017-06-22T19:44:09 <jonasschnelli> luke-jr: you can still add a query string later if you need non-hirarichal inputs later
5092017-06-22T19:44:10 <gmaxwell> path seems fine to me, so long as there is a version, but I'm clueless. I do have some questions though.
5102017-06-22T19:44:19 <jonasschnelli> what wumpus sais
5112017-06-22T19:44:37 <wumpus> POST has always been used with the idea that the parameters are in the payload
5122017-06-22T19:44:44 * luke-jr wants to hear the rest of sipa's thoughts. âº
5132017-06-22T19:44:46 <wumpus> POST should not have URI parameters
5142017-06-22T19:44:48 <jonasschnelli> wumpus: exactly
5152017-06-22T19:44:50 <ryanofsky> i think query strings are analogous to command line options, paths are analogous to positional command line arguments
5162017-06-22T19:44:51 <sipa> however, most things that would go into the path/query string as well, can just become RPC arguments as well
5172017-06-22T19:45:04 <wumpus> if you confuse them, it will be hard to use from some languages
5182017-06-22T19:45:09 <sipa> i think that perhaps the wallet name is different, in that it's actually a different "module" you're sending it to
5192017-06-22T19:45:18 <jonasschnelli> sipa: indeed... but the /wallet/ endpoint could have a different rpc server once
5202017-06-22T19:45:22 <ryanofsky> options are better for non required things that tweak the current operation, arguments are better for required values that determine operation
5212017-06-22T19:45:25 <gmaxwell> I think it's likely in the future that we'll support doing this "create transaction in wallet A but also able using coins from wallet B,C"-- seems clear to me how this could work in the GUI. How could we RPC call that?
5222017-06-22T19:45:31 <sipa> so i think my preference is path - and for things that don't fit in the normal hierarchical structure, use named RPC arguments
5232017-06-22T19:45:39 <wumpus> oh no... not commands from multiple wallets
5242017-06-22T19:45:58 <sipa> gmaxwell: ugh...
5252017-06-22T19:45:59 <wumpus> can we at least agree on one object to apply commands too
5262017-06-22T19:46:03 <luke-jr> BTW, did we consider a generic JSON-RPC "wallet" named param?
5272017-06-22T19:46:08 <gmaxwell> it's not really 'from multiple wallets'.
5282017-06-22T19:46:13 <sipa> luke-jr: i suggested that before, yes
5292017-06-22T19:46:23 <wumpus> gmaxwell: in that case you should just use the raw transactions api
5302017-06-22T19:46:35 <wumpus> you can listunspent on multiple wallets, then use thei r utxos
5312017-06-22T19:46:36 <sipa> luke-jr: i'd be fine with it, except it's less compatible with a future change that moves it to a different process (which will necessarily have a new endpoint)
5322017-06-22T19:46:45 <jonasschnelli> luke-jr: generic wallet named parameter seems fine. Is it mixable with the non-named parameter?
5332017-06-22T19:46:51 <wumpus> no need to do some obscure voodoo calling a method on multiple objects on the same time
5342017-06-22T19:46:54 <gmaxwell> in any case, without that you are forced to make idiotic pay wallet A from wallet B transactions just to make a large payment. (or as wumpus notes, do something with raw transactions)
5352017-06-22T19:46:55 <jonasschnelli> I guess we then would only allow wallet selecting with name bases params?
5362017-06-22T19:46:57 <wumpus> that way madness lies
5372017-06-22T19:47:06 <luke-jr> sipa: ah, right
5382017-06-22T19:47:33 <sipa> so i think this guideline may help: arguments that select something that may in the future move to another process, should go into the path
5392017-06-22T19:47:36 <gmaxwell> wumpus: fair enough that you wouldn't want to do a ?wallet=a&wallet=b voodoo in any case there, so no interaction with this question.
5402017-06-22T19:47:39 <sipa> other things should be RPC named args
5412017-06-22T19:47:40 <jonasschnelli> I guess endpoints will also make process separation simpler
5422017-06-22T19:47:47 <sipa> jonasschnelli: that's what i was saying
5432017-06-22T19:48:10 <wumpus> sipa: +1
5442017-06-22T19:48:19 <jonasschnelli> Okay. Lets then go for /v1/wallet/walletID for now
5452017-06-22T19:48:27 <wumpus> yes
5462017-06-22T19:48:30 <sipa> ack
5472017-06-22T19:48:32 <luke-jr> v0? :P
5482017-06-22T19:48:38 <jonasschnelli> WalletID is the wallet filename for now... not sure if this is a problem
5492017-06-22T19:48:45 <sipa> luke-jr: v0 already exists :p
5502017-06-22T19:48:47 <jonasschnelli> v0 is not what users are expecting..
5512017-06-22T19:48:47 <wumpus> no, v1, v0 is what we had before :)
5522017-06-22T19:48:54 <luke-jr> but this isn't changing the API
5532017-06-22T19:49:03 <sipa> no, it's creating a new API
5542017-06-22T19:49:04 <jonasschnelli> it's just a prevention for future api changes
5552017-06-22T19:49:09 <wumpus> yes.
5562017-06-22T19:49:12 <gmaxwell> adding /wallet/ is a new API.
5572017-06-22T19:49:19 <gmaxwell> even though its a trivial one.
5582017-06-22T19:49:32 <wumpus> I think it's good to add it just in case, we should be able to use /v1 as endpoint for non-wallet methods
5592017-06-22T19:49:47 <luke-jr> oh, that's a point: how do we specify "no wallet"?
5602017-06-22T19:49:47 <wumpus> and / for both wallet methos and non-wallet methods (wallet will use 'the default wallet')
5612017-06-22T19:49:50 *** neel has joined #bitcoin-core-dev
5622017-06-22T19:49:55 <jonasschnelli> Yes. /v1 should do the same / (selecting the default wallet)
5632017-06-22T19:49:56 <gmaxwell> oh nice, though if we're going to do that, we need to ban wallet methods on /v1/ right away.
5642017-06-22T19:50:03 <wumpus> gmaxwell: yes please
5652017-06-22T19:50:09 <sipa> how about we also add /v1/node for all non-wallet RPCs?
5662017-06-22T19:50:30 <wumpus> /v1 should do away with wallet methods, / should have them for backward compat
5672017-06-22T19:50:35 <sipa> yes
5682017-06-22T19:50:36 <jonasschnelli> Wait, do we want to ban non wallet methods sent to /v1/wallet/?
5692017-06-22T19:50:39 <jtimon> wumpus: why not use query string with POST? we do everything with POST in the rpc, there's no GET, perhaps a link I could read?
5702017-06-22T19:50:41 <wumpus> jonasschnelli: yes
5712017-06-22T19:50:43 <sipa> jonasschnelli: yes
5722017-06-22T19:50:46 <gmaxwell> well we have node rpcs but we also have pure function rpcs. though I don't know how good it is to bother callers with the fine details of how an rpc is implemented.
5732017-06-22T19:50:49 <luke-jr> :|
5742017-06-22T19:50:54 <jonasschnelli> Okay. That makes it a bit more complex. :)
5752017-06-22T19:50:58 <jonasschnelli> And not user friendly.
5762017-06-22T19:51:03 <jtimon> oh, the params after ?, right, sorry
5772017-06-22T19:51:07 <sipa> jonasschnelli: how so?
5782017-06-22T19:51:13 <instagibbs> we should just ban all calls, start fresh :P
5792017-06-22T19:51:17 <luke-jr> sipa: can't just change the endpoint for existing software..
5802017-06-22T19:51:22 <jonasschnelli> what about createrawtransaction?
5812017-06-22T19:51:32 <sipa> luke-jr: then use the old API, which keeps working
5822017-06-22T19:51:39 <luke-jr> sipa: then you can't select the wallet
5832017-06-22T19:51:53 <wumpus> jonasschnelli: well... the methods thaat have both wallet and non-wallet functionality are obviously special here
5842017-06-22T19:51:54 <jtimon> sipa: most things? all things I believe, even for GET
5852017-06-22T19:51:55 <jonasschnelli> switch over to /wallet when you call fundrawtransaction and back to /node when using signrawtransactionwithkey?
5862017-06-22T19:52:05 <wumpus> jonasschnelli: they could be on both, I don't care
5872017-06-22T19:52:08 <gmaxwell> having them track that "x is a wallet rpc" vs "y is a node" rpc is already asking a lot. and following this there should be something for pure rpcs that interact not with the node state or wallet. and so on.
5882017-06-22T19:52:17 <gmaxwell> I guess I'm raising the same concern as jonasschnelli
5892017-06-22T19:52:28 <wumpus> gmaxwell: it's a good preparation for beginning to split off the wallet though
5902017-06-22T19:52:28 <sipa> i see there is a usability issue in doing so
5912017-06-22T19:52:36 <jonasschnelli> Not sure if we can/should already seperate the calls in endpoints
5922017-06-22T19:52:38 <wumpus> gmaxwell: when the wallet would be a separate process it also won't have the node methods
5932017-06-22T19:52:57 <gmaxwell> Yes, and I think the wallet split is reasonable, I'm cautioning about what happens if you continue the logic.
5942017-06-22T19:53:00 <jonasschnelli> Once we have process separation, then we would need it. Yes.
5952017-06-22T19:53:02 <wumpus> also it's a bit starnge to have the same non-wallet methods aliased for every wallet
5962017-06-22T19:53:05 <jonasschnelli> We could warn in the release notes.
5972017-06-22T19:53:10 <wumpus> aliasing is usually a bad idea
5982017-06-22T19:53:35 <luke-jr> I suppose if people want backward compatibility, they can just user per-username default wallets, and have multiple users
5992017-06-22T19:53:55 <gmaxwell> Maybe there really are only three kinds: Things that talk to the node, things that talk to a wallet (and maybe also a node), and things that are pure functions.
6002017-06-22T19:54:03 <wumpus> what makes /v1/wallet/mywallet getnetworkinfo different from /v1/otherwallet netnetworkinfo
6012017-06-22T19:54:13 <wumpus> none has anything to do with wallets
6022017-06-22T19:54:20 <wumpus> gmaxwell: yes, those three kinds exist
6032017-06-22T19:54:24 <jonasschnelli> Yes. Agree that it looks bad.
6042017-06-22T19:54:31 <sipa> can you give an example of the middle one?
6052017-06-22T19:54:41 <wumpus> gmaxwell: we've been trying to get rid of " things that talk to a wallet (and maybe also a node)"
6062017-06-22T19:54:43 <sipa> oh, signrawtransaction needing UTXO access
6072017-06-22T19:54:50 <jonasschnelli> hm... wumpus: not sure. The wallet could have it's own network rules in future
6082017-06-22T19:54:52 <wumpus> sipa: getinfo
6092017-06-22T19:55:00 <sipa> wumpus: i don't care about getinfo :)
6102017-06-22T19:55:10 <gmaxwell> it's a little unfortunate to expose the three kinds to users though. decoderawtransaction and createrawtransaction are pure, signrawtransaction is not.
6112017-06-22T19:55:12 <wumpus> jonasschnelli: sure, then it could have a *different* getnetworkinfo
6122017-06-22T19:55:31 <wumpus> sipa: there are more, I've listed them in some issue, let me see
6132017-06-22T19:55:58 <jonasschnelli> I don't think it's wrong to have node calls in /v1/wallet/mywallet .. it allows us to â in theory â have different peering for different wallets. Also chaintips can be different.
6142017-06-22T19:56:04 <wumpus> sipa: #7965
6152017-06-22T19:56:05 <sipa> i think i'm fine with making v1 support all non-deprecated non-wallet RPCs as well
6162017-06-22T19:56:06 <gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
6172017-06-22T19:56:08 <gmaxwell> I think a split on anything other than wallet vs non-wallet basically exposes implementation details to users.
6182017-06-22T19:56:19 <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10652: Small step towards demangling cs_main from CNodeState (master...2017-06-cnodestateaccessors-1) https://github.com/bitcoin/bitcoin/pull/10652
6192017-06-22T19:56:23 <gmaxwell> jonasschnelli: those don't sound like very interesting things to accomplish. IMO.
6202017-06-22T19:56:25 <luke-jr> I think we're adding too much complexity to make 0.15 :<
6212017-06-22T19:56:48 <wumpus> "RPC still has some calls that vary depending on wallet support. We should split these up. This is the more annoying part as it will involve API changes. No non-wallet RPC call should make an assumption about "a wallet"."
6222017-06-22T19:56:52 <sipa> can we please at least remove getinfo from v1?
6232017-06-22T19:56:58 <BlueMatt> YES
6242017-06-22T19:57:00 <wumpus> YES
6252017-06-22T19:57:04 <gmaxwell> (and by wallet vs non-wallet, I mean a logical split where the address and transaction manipulating functions which are technically pure would still be wallet functions)
6262017-06-22T19:57:25 <jonasschnelli> Okay. Should the call split be in the same PR that introduces the endpoint?
6272017-06-22T19:57:35 <wumpus> jonasschnelli: not necessarily, small steps are fine
6282017-06-22T19:57:38 <sipa> jonasschnelli: i don't care
6292017-06-22T19:57:55 <jonasschnelli> I think it may get pretty big.
6302017-06-22T19:57:58 <gmaxwell> we shouldn't ship a release with /v1/ though that has a lot of calls we intend to remove, however.
6312017-06-22T19:57:58 <jonasschnelli> And ideally the endpoint is in 0.15 (otherwise multiwallet is not really useful)
6322017-06-22T19:58:01 <wumpus> at this point it's better to make progress at all
6332017-06-22T19:58:02 <luke-jr> let's get rid of BTC amounts while we're at it! :x
6342017-06-22T19:58:04 <sipa> gmaxwell: agree
6352017-06-22T19:58:26 <wumpus> gmaxwell: if it's in a release it means it needs to be /v2
6362017-06-22T19:58:29 <sipa> jonasschnelli: we have time, i think
6372017-06-22T19:58:31 <wumpus> gmaxwell: simple as that
6382017-06-22T19:58:38 <gmaxwell> luke-jr: I'd like that but switching to integers could be a v2 thing too...
6392017-06-22T19:58:44 <wumpus> sigh
6402017-06-22T19:58:57 <sipa> wumpus: sure; but i think we can merge endpoints now, and do another PR before 0.15 to remove some of the unnecessary stuff from the wallet endpoints
6412017-06-22T19:58:59 <gmaxwell> wumpus: well will we want to continue supporting v1 for a long time in th case?
6422017-06-22T19:59:00 <jtimon> I would not apps anything in the uri, just /v1/wallet/ with {"wallet": "mywalley", "otherparam" : "other value"}
6432017-06-22T19:59:30 <sipa> jtimon: the downside of that is that doesn't prepare downstream apps well for a future process split
6442017-06-22T19:59:37 <jonasschnelli> jtimon: having it in the JSON layer would make process seperation harder...
6452017-06-22T19:59:38 <wumpus> (sorry, just tired of the whole 'switching to integers' thing)
6462017-06-22T19:59:55 <sipa> wumpus: i think the current solutions which accepts strings everywhere is perfectly fine
6472017-06-22T20:00:01 <gmaxwell> wumpus: oh I thought other people wanted to do that, but the inability to change the api was holding it off.
6482017-06-22T20:00:45 <sipa> PLOINK
6492017-06-22T20:00:54 <jtimon> luke-jr: super ACK on finally moving from BTC to satoshi once and for all, but last time I tried I had to close the PR
6502017-06-22T20:00:56 <luke-jr> sipa fell in the ocean?
6512017-06-22T20:00:58 <instagibbs> that's dutch for "meeting over"
6522017-06-22T20:00:59 <wumpus> gmaxwell: I mean the problem is that JSON doesn't have integers
6532017-06-22T20:01:02 <wumpus> #endmeeting
6542017-06-22T20:01:02 <lightningbot> Meeting ended Thu Jun 22 20:01:02 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6552017-06-22T20:01:02 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.html
6562017-06-22T20:01:02 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.txt
6572017-06-22T20:01:02 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.log.html
6582017-06-22T20:01:12 <sipa> instagibbs: indeed; clearly at least wumpus got it
6592017-06-22T20:01:38 <gmaxwell> wumpus: yea, I thought the suggestion was integers in strings. sorry if I'm desynced there.
6602017-06-22T20:01:43 <BlueMatt> sorry cfields, I didnt want to hold off on PRing #10652 anymore....I only started it last dec :p
6612017-06-22T20:01:45 <gribble> https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
6622017-06-22T20:01:58 <luke-jr> JSON has Numbers, which can be integers just fine
6632017-06-22T20:02:08 <wumpus> if only we used a *SANE* RPC mechanism that support uint64 values
6642017-06-22T20:02:10 <jtimon> I see, the reason to have the wallet id in the uri is for processes, thanks
6652017-06-22T20:02:12 <cfields> BlueMatt: np, great to see
6662017-06-22T20:02:14 <sipa> wumpus: ASN.1
6672017-06-22T20:02:20 <cfields> haha
6682017-06-22T20:02:22 <wumpus> we'd haved save hours, no, days of discussion
6692017-06-22T20:02:22 <gmaxwell> wumpus: the issue that its trying to address is that some json libraries coerse json numbers to 32-bit floats and other horrors and do corrupt our values.
6702017-06-22T20:02:40 <jonasschnelli> cfields: interested if you know why I got again dependencies issues on travis only: https://travis-ci.org/bitcoin/bitcoin/jobs/245674276#L2089
6712017-06-22T20:02:41 <gmaxwell> luke-jr: if you're willing to support proper handling of number we don't need to change anything-- current thing is fine.
6722017-06-22T20:02:42 <wumpus> gmaxwell: we currently accept strings as BTC amounts
6732017-06-22T20:02:56 <gmaxwell> wumpus: yes, but we don't return them.
6742017-06-22T20:02:58 <luke-jr> gmaxwell: current thing confuses internals with externals
6752017-06-22T20:03:48 <wumpus> ASN.1 hehe
6762017-06-22T20:03:50 <jtimon> unrelated: I would add #9271 to project 6 (libconsensus), although I don't manage to fix the tests if I change the enums for the consensus part. Removing that last part doesn't feel right either
6772017-06-22T20:03:51 <gribble> https://github.com/bitcoin/bitcoin/issues/9271 | Theres two types of flags: consensus and script by jtimon · Pull Request #9271 · bitcoin/bitcoin · GitHub
6782017-06-22T20:04:11 <gmaxwell> I'm sorry for commenting. perhaps it would just be better addressed by offering an RPC that isn't json in the future.
6792017-06-22T20:04:20 <cfields> jonasschnelli: will take a look
6802017-06-22T20:04:24 <sipa> gmaxwell: XML?
6812017-06-22T20:04:28 <jtimon> I gave up on verifyHeader, but not on verifyTx
6822017-06-22T20:04:33 <jonasschnelli> cfields: thanks!
6832017-06-22T20:04:38 <wumpus> gmaxwell: no, don't be sorry, I'm sorry for reacting so heavily to it, it's just that it's been discussed so many times, and every time it goes the same
6842017-06-22T20:05:01 <jtimon> sipa: SOAP :p
6852017-06-22T20:05:07 <luke-jr> wumpus: because we never change the API..
6862017-06-22T20:05:15 <wumpus> some people want solution A, some want B, it never changes
6872017-06-22T20:05:18 <gmaxwell> My skin crawls a bit about the big footgun json gives our callers here. :( (though seems luke wasn't even concerned about that)
6882017-06-22T20:05:32 <cfields> jonasschnelli: btw, I pinged you a few days ago for discussion about the policy change, but I guess I missed you. I suspect it's too late now to pester you about it for a min?
6892017-06-22T20:05:45 <wumpus> two? three? years ago I had a PR open that allows, with a command line argument, to change the encoding of amounts to four different things
6902017-06-22T20:05:50 <wumpus> both for accepting and returning
6912017-06-22T20:06:00 <wumpus> but no, no one was interested
6922017-06-22T20:06:05 <wumpus> we rather just keep discussing it
6932017-06-22T20:06:49 <gmaxwell> changing the API from a commandline seems unsafe, however. I think it came up here because we're doing api versions.
6942017-06-22T20:06:55 <wumpus> yeah yeah...
6952017-06-22T20:06:56 <wumpus> never mind
6962017-06-22T20:07:32 <gmaxwell> (e.g. you set the commandline one way then run joinmarket that doesn't know about that, and Bad Things Happen (tm) ... though I apologize if your PR actually addressed that.)
6972017-06-22T20:08:03 <wumpus> so, we could switch between just btc amount and "btc amount" and drop the integer variants, also fine with me
6982017-06-22T20:08:13 * jtimon ended up in https://zeroc.com/products/ice when talking about rpc...remembers he used it for robots to talk to computers with more computing power
6992017-06-22T20:08:43 <luke-jr> wumpus: that would just make the problem worse
7002017-06-22T20:08:59 <wumpus> no way that's dangerous as it would just result in incompatible values that wouldn't be parsed instead of 10^8 blowup
7012017-06-22T20:09:04 <wumpus> oh yeah of course it just makes things worse
7022017-06-22T20:09:07 <wumpus> OF COURSE
7032017-06-22T20:09:16 <gmaxwell> wumpus: Thats a good point
7042017-06-22T20:09:59 <wumpus> jtimon: it's not just bitcoin, no one ever agrees about RPC mechanisms, ever, anywhere :)
7052017-06-22T20:10:07 <luke-jr> lol
7062017-06-22T20:10:25 <gmaxwell> actually what effective numeric value does "1.0000" have in javascript? (a string with a 1.00 in it)
7072017-06-22T20:10:38 <wumpus> that's why hundreds different ones exist
7082017-06-22T20:11:18 <wumpus> 1.0000 if you interpret it as number
7092017-06-22T20:11:46 <jtimon> wumpus: right, I just remembered with gmaxwell comments what I had used i the past, I hated soap and liked ice
7102017-06-22T20:11:56 <gmaxwell> okay, that looks vaguely safe. I was worring for a moment that it would be 0 or something.
7112017-06-22T20:12:47 <wumpus> gmaxwell: javascript:alert("1.0000"+0)
7122017-06-22T20:13:20 <bitcoin-git> [bitcoin] achow101 closed pull request #10511: [Tests] Include branch coverage info in coverage test (master...lcov) https://github.com/bitcoin/bitcoin/pull/10511
7132017-06-22T20:13:45 *** CubicEarth has joined #bitcoin-core-dev
7142017-06-22T20:13:49 <gmaxwell> I don't know how anyone can stand programming in this language because "blart"+0 = "blart0"
7152017-06-22T20:13:52 *** Dyaheon has quit IRC
7162017-06-22T20:15:04 <sipa> gmaxwell: https://www.destroyallsoftware.com/talks/wat
7172017-06-22T20:15:12 *** Dyaheon has joined #bitcoin-core-dev
7182017-06-22T20:15:55 <wumpus> gmaxwell: I don't know either, it's just madness
7192017-06-22T20:16:29 *** jtimon has quit IRC
7202017-06-22T20:19:25 <wumpus> but yes, that probably means that changing a number to a string is going to result in funny results instead of errors immediately
7212017-06-22T20:26:29 *** Giszmo has quit IRC
7222017-06-22T20:27:56 *** Giszmo has joined #bitcoin-core-dev
7232017-06-22T20:34:41 *** laurentmt has joined #bitcoin-core-dev
7242017-06-22T20:34:54 *** laurentmt has quit IRC
7252017-06-22T20:59:26 *** Chris_Stewart_5 has quit IRC
7262017-06-22T21:12:37 *** nelsondcg has quit IRC
7272017-06-22T21:34:23 *** laurentmt has joined #bitcoin-core-dev
7282017-06-22T21:56:33 *** jtimon has joined #bitcoin-core-dev
7292017-06-22T21:57:26 *** neel has quit IRC
7302017-06-22T21:57:59 <sipa> Can I haz some review on https://github.com/bitcoin-core/leveldb/pull/2 ?
7312017-06-22T22:05:42 *** belcher has joined #bitcoin-core-dev
7322017-06-22T22:10:39 *** chjj has joined #bitcoin-core-dev
7332017-06-22T22:12:35 *** neel has joined #bitcoin-core-dev
7342017-06-22T22:18:58 *** Dyaheon has quit IRC
7352017-06-22T22:20:18 *** Dyaheon has joined #bitcoin-core-dev
7362017-06-22T22:26:01 *** Guyver2 has quit IRC
7372017-06-22T22:27:21 <luke-jr> sipa: but I thought we all trusted you to do the LevelDB review? :P
7382017-06-22T22:31:41 <sipa> luke-jr: not of my own code
7392017-06-22T22:32:06 <luke-jr> oh, that's not just the version bump
7402017-06-22T22:32:27 <wumpus> no, the version bump was already done
7412017-06-22T22:32:47 *** neel has quit IRC
7422017-06-22T22:33:46 <wumpus> this just moves the atomic pointer code
7432017-06-22T22:34:19 <sipa> yes, it makes it prefer the c++11 native construct over the adhoc asm code
7442017-06-22T22:37:38 *** chjj has quit IRC
7452017-06-22T22:38:49 *** jtimon has quit IRC
7462017-06-22T22:39:36 <wumpus> yep
7472017-06-22T22:41:02 *** Dizzle has quit IRC
7482017-06-22T22:45:03 <gmaxwell> sipa: unrelated to us reviewing it, but any feedback from upstream about it?
7492017-06-22T22:45:13 <gmaxwell> I certantly feel much more comfortable using C++ atomics.
7502017-06-22T22:46:23 <sipa> gmaxwell: it's even code from upstream
7512017-06-22T22:46:34 <sipa> i just changed the priority of choosing one over another
7522017-06-22T22:46:47 <sipa> not a single comment in the upstream github repo
7532017-06-22T22:50:28 <profall> Can two different people mine to different accounts on the same node?
7542017-06-22T22:52:59 <wumpus> since when can you mine on people?
7552017-06-22T22:53:45 <profall> Sweat shop with people hashing with pen and paper
7562017-06-22T22:54:15 <profall> ASIC, Miner, machine do-dad hashing thing. Want me to rephrase the statement?
7572017-06-22T22:54:32 <sipa> what do accounts have to do with iy
7582017-06-22T22:54:38 <sipa> what have nodes to do with it
7592017-06-22T22:56:05 <wumpus> the question just makes no sense, also this is not the place to ask support questions, try #bitcoin
7602017-06-22T22:56:21 <profall> If Miner #1 is mining to address ABC and Miner #2 is mining to address XZY. However, they have are using the same bitcoin core daemon.
7612017-06-22T22:56:23 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
7622017-06-22T22:56:25 <gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
7632017-06-22T22:56:26 <profall> Alright, will ask there.
7642017-06-22T22:57:50 <sipa> profall: bitcoin core is irrelevant in this question; all core does is provide a block template to mine from
7652017-06-22T22:58:16 <sipa> it does not care what you do with that, where you make the payout go, or where you submit the solved block
7662017-06-22T22:58:36 <profall> Alright, thank you sipa
7672017-06-22T23:15:31 *** laurentmt has quit IRC
7682017-06-22T23:25:11 *** RoyceX has joined #bitcoin-core-dev
7692017-06-22T23:27:11 *** belcher has quit IRC
7702017-06-22T23:28:30 *** cheese_ has quit IRC
7712017-06-22T23:33:08 *** Chris_Stewart_5 has joined #bitcoin-core-dev
7722017-06-22T23:41:22 *** Dyaheon has quit IRC
7732017-06-22T23:42:16 *** midnightmagic has quit IRC
7742017-06-22T23:42:43 *** spinza has quit IRC
7752017-06-22T23:43:12 *** Dyaheon has joined #bitcoin-core-dev
7762017-06-22T23:44:19 *** midnightmagic has joined #bitcoin-core-dev
7772017-06-22T23:51:17 *** spinza has joined #bitcoin-core-dev
7782017-06-22T23:54:55 <bitcoin-git> [bitcoin] ryanofsky opened pull request #10653: Simple, backwards compatible RPC multiwallet support (master...pr/multiparam) https://github.com/bitcoin/bitcoin/pull/10653
7792017-06-22T23:55:23 <achow101> morcos: sdaftuar: what's the best way to get a long term fee rate (e.g. estimatesmartfee for 1008 blocks)? I need this for #10637.
7802017-06-22T23:55:25 <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
7812017-06-22T23:56:19 <achow101> right now I am doing this abomination: https://0bin.net/paste/aql1DfVmBRbaZ9ks#P+ZTH6yYhbb4X-+YeCrCU/Mmt85cjNpkBvlqFvxxHFZ since it seems that estimatesmartfee() will return a fee rate of 0 if the confirmation target is out of the data range
7822017-06-22T23:57:07 <achow101> (getminimumfeerate in that snippet is a function that gets the fee rate with estimatesmartfee and then returns the max of that or the minrelayfee)
7832017-06-22T23:58:41 *** cheese_ has joined #bitcoin-core-dev