12017-03-02T00:02:55 *** Micheal_PVR has quit IRC
22017-03-02T00:04:03 *** Ylbam has quit IRC
32017-03-02T00:08:28 *** Giszmo has quit IRC
42017-03-02T00:08:38 *** jeremyrubin has joined #bitcoin-core-dev
52017-03-02T00:08:43 *** Giszmo has joined #bitcoin-core-dev
62017-03-02T00:10:09 *** shesek has quit IRC
72017-03-02T00:10:27 *** To7 has joined #bitcoin-core-dev
82017-03-02T00:27:50 *** dodomojo has joined #bitcoin-core-dev
92017-03-02T00:31:38 *** dodomojo_ has joined #bitcoin-core-dev
102017-03-02T00:34:01 *** dodomojo has quit IRC
112017-03-02T00:50:13 *** dodomojo_ has quit IRC
122017-03-02T00:58:26 *** laurentmt has joined #bitcoin-core-dev
132017-03-02T00:58:39 *** laurentmt has quit IRC
142017-03-02T00:59:00 *** Giszmo has quit IRC
152017-03-02T00:59:15 *** abpa has quit IRC
162017-03-02T01:11:02 *** d9b4bef9 has quit IRC
172017-03-02T01:12:14 *** d9b4bef9 has joined #bitcoin-core-dev
182017-03-02T01:13:49 *** Giszmo has joined #bitcoin-core-dev
192017-03-02T01:16:37 *** moli_ has joined #bitcoin-core-dev
202017-03-02T01:24:05 *** AaronvanW has quit IRC
212017-03-02T02:03:45 *** AaronvanW has joined #bitcoin-core-dev
222017-03-02T02:13:00 *** PaulCapestany has quit IRC
232017-03-02T02:15:07 *** PaulCapestany has joined #bitcoin-core-dev
242017-03-02T02:22:34 *** Giszmo has quit IRC
252017-03-02T02:36:23 *** Giszmo has joined #bitcoin-core-dev
262017-03-02T02:51:01 *** rafalcpp has quit IRC
272017-03-02T02:51:47 *** rafalcpp has joined #bitcoin-core-dev
282017-03-02T03:08:28 *** Victor_sueca has joined #bitcoin-core-dev
292017-03-02T03:11:07 *** Victorsueca has quit IRC
302017-03-02T03:22:58 *** CubicEarth has joined #bitcoin-core-dev
312017-03-02T03:27:20 *** PaulCapestany has quit IRC
322017-03-02T03:31:10 *** PaulCapestany has joined #bitcoin-core-dev
332017-03-02T03:31:25 *** PaulCapestany has quit IRC
342017-03-02T03:34:12 *** PaulCapestany has joined #bitcoin-core-dev
352017-03-02T03:34:47 *** wudayoda has joined #bitcoin-core-dev
362017-03-02T03:36:34 *** PaulCapestany has quit IRC
372017-03-02T03:38:40 *** PaulCapestany has joined #bitcoin-core-dev
382017-03-02T03:39:31 *** wudayoda has quit IRC
392017-03-02T03:40:06 *** PaulCapestany has quit IRC
402017-03-02T03:47:33 *** PaulCapestany has joined #bitcoin-core-dev
412017-03-02T03:59:06 *** PaulCapestany has joined #bitcoin-core-dev
422017-03-02T03:59:42 *** PaulCapestany has quit IRC
432017-03-02T04:02:30 *** PaulCapestany has joined #bitcoin-core-dev
442017-03-02T04:04:09 *** wudayoda has joined #bitcoin-core-dev
452017-03-02T04:05:42 *** PaulCapestany has joined #bitcoin-core-dev
462017-03-02T04:07:35 *** PaulCapestany has joined #bitcoin-core-dev
472017-03-02T04:08:00 *** harrymm has quit IRC
482017-03-02T04:08:45 *** PaulCapestany has quit IRC
492017-03-02T04:10:47 *** PaulCapestany has joined #bitcoin-core-dev
502017-03-02T04:11:01 *** wudayoda has quit IRC
512017-03-02T04:12:56 *** wudayoda has joined #bitcoin-core-dev
522017-03-02T04:15:33 *** PaulCape_ has joined #bitcoin-core-dev
532017-03-02T04:15:34 *** PaulCapestany has quit IRC
542017-03-02T04:15:56 *** neha has quit IRC
552017-03-02T04:17:51 *** PaulCape_ has quit IRC
562017-03-02T04:20:25 *** PaulCapestany has joined #bitcoin-core-dev
572017-03-02T04:20:53 *** PaulCapestany has quit IRC
582017-03-02T04:22:13 *** wudayoda has quit IRC
592017-03-02T04:23:47 *** PaulCapestany has joined #bitcoin-core-dev
602017-03-02T04:27:14 *** harrymm has joined #bitcoin-core-dev
612017-03-02T04:31:18 *** wudayoda has joined #bitcoin-core-dev
622017-03-02T04:33:09 *** wudayoda has quit IRC
632017-03-02T04:33:26 *** wudayoda has joined #bitcoin-core-dev
642017-03-02T04:39:09 *** CubicEarth has quit IRC
652017-03-02T04:42:03 *** wudayoda has quit IRC
662017-03-02T05:08:00 <luke-jr> any idea what /TestClient:0.0.1/ is?
672017-03-02T05:34:24 *** kadoban has quit IRC
682017-03-02T05:50:27 <mryandao> spy node, just guessing
692017-03-02T05:55:30 <luke-jr> seemed to be abusing bloom to work my CPU
702017-03-02T06:23:52 *** lclc has joined #bitcoin-core-dev
712017-03-02T06:33:09 *** baldur has joined #bitcoin-core-dev
722017-03-02T06:39:16 *** shesek has joined #bitcoin-core-dev
732017-03-02T06:42:44 <luke-jr> fyi https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
742017-03-02T06:45:01 <gmaxwell> people are misinterperting the gihub license, the things people are objecting to are related to moral rights, not copyright, moral rights largely don't exist in the US.
752017-03-02T07:10:13 *** isle2983 has quit IRC
762017-03-02T07:50:15 *** BashCo has quit IRC
772017-03-02T08:10:25 *** BashCo has joined #bitcoin-core-dev
782017-03-02T08:30:53 *** owowo has quit IRC
792017-03-02T08:32:11 <wumpus> at some point, github is going to do something really stupid and we'll see an exodus of projects, just like what happened to sourceforge, and we'll have to move our main development hub somewhere else. But this seems largely based on misinterpretation and very avid attempts at "reading between the lines", at least it seems to me...
802017-03-02T08:38:07 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d19d45a1e6a4...b00ba6251f71
812017-03-02T08:38:07 <bitcoin-git> bitcoin/master 5b528d7 Marko Bencun: qt: clean up initialize/shutdown signals...
822017-03-02T08:38:08 <bitcoin-git> bitcoin/master b00ba62 Jonas Schnelli: Merge #9834: qt: clean up initialize/shutdown signals...
832017-03-02T08:38:34 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9834: qt: clean up initialize/shutdown signals (master...exitcode) https://github.com/bitcoin/bitcoin/pull/9834
842017-03-02T08:40:39 <bitcoin-git> [bitcoin] laanwj opened pull request #9902: Lightweight abstraction of boost::filesystem (master...2017_03_fs) https://github.com/bitcoin/bitcoin/pull/9902
852017-03-02T08:44:24 <jonasschnelli> ryanofsky: I have a question about your comment: https://github.com/bitcoin/bitcoin/pull/9681#discussion_r102847930
862017-03-02T08:44:31 <jonasschnelli> Tell me if you are available...
872017-03-02T08:46:25 *** Guyver2 has joined #bitcoin-core-dev
882017-03-02T08:53:46 *** owowo has joined #bitcoin-core-dev
892017-03-02T09:06:02 *** owowo has quit IRC
902017-03-02T09:07:59 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b00ba6251f71...0496e15aef1c
912017-03-02T09:07:59 <bitcoin-git> bitcoin/master 6665977 Gregory Sanders: remove 'label' filter for rpc command help
922017-03-02T09:08:00 <bitcoin-git> bitcoin/master 0496e15 Wladimir J. van der Laan: Merge #9894: remove 'label' filter for rpc command help...
932017-03-02T09:08:19 <bitcoin-git> [bitcoin] laanwj closed pull request #9894: remove 'label' filter for rpc command help (master...filterrpc) https://github.com/bitcoin/bitcoin/pull/9894
942017-03-02T09:09:20 <luke-jr> wumpus: GitHub's ToS were never particularly good
952017-03-02T09:09:28 <wumpus> luke-jr: indeed
962017-03-02T09:10:15 *** owowo has joined #bitcoin-core-dev
972017-03-02T09:10:15 *** owowo has joined #bitcoin-core-dev
982017-03-02T09:17:54 *** AaronvanW has joined #bitcoin-core-dev
992017-03-02T09:20:07 *** Victor_sueca is now known as Victorsueca
1002017-03-02T09:28:08 *** JackH has quit IRC
1012017-03-02T09:29:53 *** MarcoFalke_ has joined #bitcoin-core-dev
1022017-03-02T09:30:30 <MarcoFalke_> jonasschnelli: Can you update/upload your public subkey on a keyserver.
1032017-03-02T09:40:29 *** JackH has joined #bitcoin-core-dev
1042017-03-02T09:44:09 *** shesek has quit IRC
1052017-03-02T09:47:51 <jonasschnelli> MarcoFalke_: I did... 30mins ago... mit/debian keyservers at least.
1062017-03-02T09:48:05 <jonasschnelli> Can someone check if i haven't screwed up my first new subkey commit: https://github.com/bitcoin/bitcoin/commit/b00ba6251f71fa1edaabdf809514e1bc3c67862e
1072017-03-02T09:48:35 <jonasschnelli> I think the key is here available: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x29D4BCB6416F53EC
1082017-03-02T09:48:41 <jonasschnelli> 03C7922D
1092017-03-02T09:50:05 <wumpus> yes, I can request the key
1102017-03-02T09:50:30 <wumpus> sub 0E/0x713A6E6216EA1E7F 2017-03-01 [expires: 2027-02-27]
1112017-03-02T09:51:43 *** paveljanik has quit IRC
1122017-03-02T09:54:38 <wumpus> gpg2 is more informative: sub nistp256/0x713A6E6216EA1E7F 2017-03-01 [S] [expires: 2027-02-27]
1132017-03-02T09:56:15 *** AaronvanW has quit IRC
1142017-03-02T09:59:01 <wumpus> for 9834: * | gpg: Signature made Thu 02 Mar 2017 09:37:40 AM CET
1152017-03-02T09:59:01 <wumpus> |\ \ gpg: using RSA key 0x1EB776BB03C7922D
1162017-03-02T09:59:01 <wumpus> | | | gpg: Can't check signature: public key not found
1172017-03-02T09:59:18 <wumpus> that seems a different key? I cannot find that one anywhere
1182017-03-02T10:00:21 <jonasschnelli> wumpus: hmm.. 0x1EB776BB03C7922D is available at https://pgp.mit.edu/pks/lookup?op=vindex&search=0x29D4BCB6416F53EC IMO
1192017-03-02T10:01:12 <jonasschnelli> I delkey every other key (like 0x713A6E6216EA1E7F), but they seem to still exist on the keyserver
1202017-03-02T10:01:40 <jonasschnelli> (*every other key == the NIST-P key)
1212017-03-02T10:02:20 <wumpus> gpg2 --recv-key 0x1EB776BB03C7922D gives me "gpg: keyserver receive failed: No data"
1222017-03-02T10:02:37 <MarcoFalke_> wumpus try curl and pipe that into gpg
1232017-03-02T10:03:12 <MarcoFalke_> I had issues with refreshing keys when they already existed
1242017-03-02T10:03:27 <jonasschnelli> wumpus: maybe use a specific keyserver --keyserver pgp.mit.edu
1252017-03-02T10:03:29 <wumpus> ah, network issues, I somehow cannot acces pgp.mit.edu at all
1262017-03-02T10:12:34 <wumpus> piping https://pgp.mit.edu/pks/lookup?op=get&search=0x29D4BCB6416F53EC into gpg --import worked
1272017-03-02T10:21:00 <jonasschnelli> wumpus: I think #9143 is ready for merge... babysteps towards multiple database backend (deprecate BDB)
1282017-03-02T10:21:02 <gribble> https://github.com/bitcoin/bitcoin/issues/9143 | Refactor ZapWalletTxes to avoid layer violations by jonasschnelli · Pull Request #9143 · bitcoin/bitcoin · GitHub
1292017-03-02T10:24:36 *** lclc has quit IRC
1302017-03-02T10:25:11 *** AaronvanW has joined #bitcoin-core-dev
1312017-03-02T10:28:52 <wumpus> jonasschnelli: thanks, will take a look
1322017-03-02T10:29:24 *** lclc has joined #bitcoin-core-dev
1332017-03-02T10:32:59 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0496e15aef1c...65d90f585a83
1342017-03-02T10:32:59 <bitcoin-git> bitcoin/master 0165a56 Jonas Schnelli: Refactor ZapWalletTxes to avoid layer vialotions
1352017-03-02T10:33:00 <bitcoin-git> bitcoin/master 65d90f5 Wladimir J. van der Laan: Merge #9143: Refactor ZapWalletTxes to avoid layer violations...
1362017-03-02T10:33:08 <bitcoin-git> [bitcoin] laanwj closed pull request #9143: Refactor ZapWalletTxes to avoid layer violations (master...2016/11/wallet_db_refactoring_1) https://github.com/bitcoin/bitcoin/pull/9143
1372017-03-02T10:34:33 *** belcher_ has joined #bitcoin-core-dev
1382017-03-02T10:35:36 *** belcher has quit IRC
1392017-03-02T10:40:26 *** jannes has joined #bitcoin-core-dev
1402017-03-02T10:40:32 *** To7 has quit IRC
1412017-03-02T10:42:38 <luke-jr> does #8775 need anything else?
1422017-03-02T10:42:41 <gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
1432017-03-02T10:56:21 *** wudayoda has joined #bitcoin-core-dev
1442017-03-02T11:00:52 *** wudayoda has quit IRC
1452017-03-02T11:07:30 <wumpus> luke-jr: adding it to my list...
1462017-03-02T11:11:13 *** lclc has quit IRC
1472017-03-02T11:14:15 <wumpus> indeed seems important to get that merged now after the 0.14 fork
1482017-03-02T11:14:27 <wumpus> but I need to go over it in detail
1492017-03-02T11:15:35 <luke-jr> #7533 would be nice to get over-with (needs rebasing often), but is lacking review (8775 has a decent amount already)
1502017-03-02T11:15:37 <gribble> https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub
1512017-03-02T11:37:37 *** LeMiner2 has joined #bitcoin-core-dev
1522017-03-02T11:40:12 *** LeMiner has quit IRC
1532017-03-02T11:40:12 *** LeMiner2 is now known as LeMiner
1542017-03-02T11:47:05 *** Victor_sueca has joined #bitcoin-core-dev
1552017-03-02T11:48:28 *** Victorsueca has quit IRC
1562017-03-02T11:49:19 *** Victorsueca has joined #bitcoin-core-dev
1572017-03-02T11:50:19 *** afk11 has quit IRC
1582017-03-02T11:50:36 *** wudayoda has joined #bitcoin-core-dev
1592017-03-02T11:50:56 *** lclc has joined #bitcoin-core-dev
1602017-03-02T11:51:57 *** Victor_sueca has quit IRC
1612017-03-02T11:55:07 *** wudayoda has quit IRC
1622017-03-02T11:55:08 *** afk11 has joined #bitcoin-core-dev
1632017-03-02T11:58:26 *** laurentmt has joined #bitcoin-core-dev
1642017-03-02T12:04:47 *** laurentmt has quit IRC
1652017-03-02T12:17:44 *** To7 has joined #bitcoin-core-dev
1662017-03-02T12:37:23 *** laurentmt has joined #bitcoin-core-dev
1672017-03-02T12:40:33 *** mol has joined #bitcoin-core-dev
1682017-03-02T12:43:28 *** moli_ has quit IRC
1692017-03-02T12:44:47 *** wudayoda has joined #bitcoin-core-dev
1702017-03-02T12:46:44 *** laurentmt has quit IRC
1712017-03-02T12:49:22 *** wudayoda has quit IRC
1722017-03-02T12:50:51 <bitcoin-git> [bitcoin] ian-kelling opened pull request #9903: Docs: add details to -rpcclienttimeout doc (master...docs-client-timeout) https://github.com/bitcoin/bitcoin/pull/9903
1732017-03-02T13:04:50 *** e4xit_ has quit IRC
1742017-03-02T13:04:53 *** e4xit has joined #bitcoin-core-dev
1752017-03-02T13:09:23 *** BashCo_ has joined #bitcoin-core-dev
1762017-03-02T13:12:35 *** BashCo has quit IRC
1772017-03-02T13:13:52 *** mol has quit IRC
1782017-03-02T13:17:08 *** rabidus has quit IRC
1792017-03-02T13:17:31 *** rabidus has joined #bitcoin-core-dev
1802017-03-02T13:18:01 *** cryptapus_afk is now known as cryptapus
1812017-03-02T13:18:55 *** rafalcpp has quit IRC
1822017-03-02T13:20:43 *** instagibbs has quit IRC
1832017-03-02T13:23:26 *** Ylbam has joined #bitcoin-core-dev
1842017-03-02T13:27:12 *** ovovo has joined #bitcoin-core-dev
1852017-03-02T13:39:09 *** wudayoda has joined #bitcoin-core-dev
1862017-03-02T13:43:16 *** wudayoda has quit IRC
1872017-03-02T13:46:14 *** lclc has quit IRC
1882017-03-02T13:47:46 *** neha has joined #bitcoin-core-dev
1892017-03-02T13:47:57 *** owowo has quit IRC
1902017-03-02T13:49:05 *** ovovo has quit IRC
1912017-03-02T13:49:33 *** lclc has joined #bitcoin-core-dev
1922017-03-02T13:54:55 *** cryptapus has joined #bitcoin-core-dev
1932017-03-02T13:55:09 *** cryptapus is now known as cryptapus_afk
1942017-03-02T13:55:19 <bitcoin-git> [bitcoin] laanwj opened pull request #9904: test: Fail if InitBlockIndex fails (master...2017_03_test_check_blkindex_result) https://github.com/bitcoin/bitcoin/pull/9904
1952017-03-02T13:55:41 *** n1ce_ has joined #bitcoin-core-dev
1962017-03-02T13:57:34 *** laurentmt has joined #bitcoin-core-dev
1972017-03-02T13:57:58 *** n1ce has quit IRC
1982017-03-02T14:02:47 *** jnewbery has joined #bitcoin-core-dev
1992017-03-02T14:06:57 *** rafalcpp has joined #bitcoin-core-dev
2002017-03-02T14:14:45 *** isle2983 has joined #bitcoin-core-dev
2012017-03-02T14:21:37 *** laurentmt has quit IRC
2022017-03-02T14:32:43 <ryanofsky> jonasschnelli: something about shared_ptr?
2032017-03-02T14:32:56 <jonasschnelli> ryanofsky: I think i could solve it...
2042017-03-02T14:33:27 *** wudayoda has joined #bitcoin-core-dev
2052017-03-02T14:33:40 <jonasschnelli> ryanofsky: it was about https://github.com/bitcoin/bitcoin/pull/9681
2062017-03-02T14:34:06 <jonasschnelli> ryanofsky: So I did this: https://github.com/bitcoin/bitcoin/commit/c81a8a7ddef6f3c1e4cb0816aa12ae16b91cbf02
2072017-03-02T14:37:52 *** wudayoda has quit IRC
2082017-03-02T14:39:35 *** moli_ has joined #bitcoin-core-dev
2092017-03-02T14:40:08 <BlueMatt> jonasschnelli: yes, it appears pgp.mit.edu is broken (not syncing to other servers), again....this happens often
2102017-03-02T14:40:18 <BlueMatt> anyway, I pushed your key to the sks pool, so it should be good in a bit
2112017-03-02T14:42:14 <jonasschnelli> Okay. Pushed to sks pool
2122017-03-02T14:44:11 *** riemann has joined #bitcoin-core-dev
2132017-03-02T15:13:22 *** CubicEarth has joined #bitcoin-core-dev
2142017-03-02T15:14:44 *** moli_ has quit IRC
2152017-03-02T15:15:06 *** nOgAnOo has joined #bitcoin-core-dev
2162017-03-02T15:15:34 *** moli_ has joined #bitcoin-core-dev
2172017-03-02T15:16:28 *** rafalcpp has quit IRC
2182017-03-02T15:18:56 *** rafalcpp has joined #bitcoin-core-dev
2192017-03-02T15:26:44 *** str4d has joined #bitcoin-core-dev
2202017-03-02T15:26:56 *** Sosumi has joined #bitcoin-core-dev
2212017-03-02T15:27:53 *** CubicEarth has quit IRC
2222017-03-02T15:27:56 *** CubicEar_ has joined #bitcoin-core-dev
2232017-03-02T15:34:03 *** Ylbam has quit IRC
2242017-03-02T15:35:34 *** mol has joined #bitcoin-core-dev
2252017-03-02T15:36:02 *** wudayoda has joined #bitcoin-core-dev
2262017-03-02T15:37:23 *** wudayoda has quit IRC
2272017-03-02T15:37:32 *** wudayoda has joined #bitcoin-core-dev
2282017-03-02T15:37:36 *** lclc has quit IRC
2292017-03-02T15:38:44 *** moli_ has quit IRC
2302017-03-02T15:48:50 *** molz_ has joined #bitcoin-core-dev
2312017-03-02T15:52:06 *** mol has quit IRC
2322017-03-02T15:59:08 *** laurentmt has joined #bitcoin-core-dev
2332017-03-02T16:06:20 *** CubicEar_ is now known as CubicEarth
2342017-03-02T16:19:25 *** BashCo_ has quit IRC
2352017-03-02T16:21:53 *** laurentmt has quit IRC
2362017-03-02T16:43:08 *** riemann has quit IRC
2372017-03-02T16:45:28 *** abpa has joined #bitcoin-core-dev
2382017-03-02T16:58:36 *** BashCo has joined #bitcoin-core-dev
2392017-03-02T17:03:33 <cfields> wumpus: nice work on fs! reading now.
2402017-03-02T17:34:19 *** laurentmt has joined #bitcoin-core-dev
2412017-03-02T17:59:15 *** Pasha has joined #bitcoin-core-dev
2422017-03-02T18:07:26 *** nOgAnOo has quit IRC
2432017-03-02T18:12:52 *** laurentmt has quit IRC
2442017-03-02T18:13:13 *** laurentmt has joined #bitcoin-core-dev
2452017-03-02T18:20:57 *** CubicEarth has quit IRC
2462017-03-02T18:21:11 *** CubicEarth has joined #bitcoin-core-dev
2472017-03-02T18:29:52 *** MarcoFalke has joined #bitcoin-core-dev
2482017-03-02T18:32:10 *** juscamarena has quit IRC
2492017-03-02T18:34:06 *** juscamarena has joined #bitcoin-core-dev
2502017-03-02T18:37:04 *** Pasha is now known as Cory
2512017-03-02T18:51:08 *** Giszmo has quit IRC
2522017-03-02T18:51:14 *** Giszmo1 has joined #bitcoin-core-dev
2532017-03-02T18:53:40 *** goregrin1 is now known as goregrind
2542017-03-02T19:00:32 <achow101> meeting?
2552017-03-02T19:00:38 <sipa> meeting!
2562017-03-02T19:01:12 <Chris_Stewart_5> gniteem
2572017-03-02T19:01:16 <wumpus> #meetingstart
2582017-03-02T19:01:32 <wumpus> #startmeeting
2592017-03-02T19:01:32 <lightningbot> Meeting started Thu Mar 2 19:01:32 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2602017-03-02T19:01:32 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2612017-03-02T19:02:02 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt
2622017-03-02T19:02:02 <wumpus> instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
2632017-03-02T19:02:08 <sdaftuar> hi
2642017-03-02T19:02:09 <kanzure> hi.
2652017-03-02T19:02:23 <BlueMatt> topics?
2662017-03-02T19:02:48 * BlueMatt would like to discuss the lack of unicorns 'round here
2672017-03-02T19:03:01 <sdaftuar> topic suggestion: any open items for 0.14?
2682017-03-02T19:03:08 <wumpus> BlueMatt: +1
2692017-03-02T19:03:34 <wumpus> any new issues with rc3?
2702017-03-02T19:04:16 <gmaxwell> I have an issue.
2712017-03-02T19:04:28 *** jannes has quit IRC
2722017-03-02T19:04:40 <gmaxwell> It isn't released yet. :P
2732017-03-02T19:04:46 <sipa> ha.
2742017-03-02T19:05:01 <wumpus> hehe
2752017-03-02T19:05:09 <BlueMatt> yup
2762017-03-02T19:05:39 <BlueMatt> rc3 was posted yesterday, so release is next tuesday if nothing else comes up, I believe?
2772017-03-02T19:06:17 <sipa> seems reasonable
2782017-03-02T19:06:24 <gmaxwell> I saw some positive comments on Bitcoin talk.
2792017-03-02T19:06:30 <BlueMatt> dont we normally do a week after rc?
2802017-03-02T19:06:38 <wumpus> yup, that's how it useually goes yes, BlueMatt
2812017-03-02T19:08:07 <MarcoFalke> #action plan to release next tuesday if nothing else comes up
2822017-03-02T19:08:38 <morcos> i'd like to briefly discuss the timing of merging #9602.. b/c assuming we are going to do it, it would be nice to get it out of the way so its not a rebase/review nightmare. i also have a ton of fee estimation changes built on top
2832017-03-02T19:08:42 <gribble> https://github.com/bitcoin/bitcoin/issues/9602 | Remove coin age priority and free transactions - implementation by morcos · Pull Request #9602 · bitcoin/bitcoin · GitHub
2842017-03-02T19:08:58 <BlueMatt> morcos: will finish review soon, but so far lgtm
2852017-03-02T19:09:05 <BlueMatt> would agree it should merge fast
2862017-03-02T19:09:25 <wumpus> #topic discuss the timing of merging #9602
2872017-03-02T19:09:27 <gribble> https://github.com/bitcoin/bitcoin/issues/9602 | Remove coin age priority and free transactions - implementation by morcos · Pull Request #9602 · bitcoin/bitcoin · GitHub
2882017-03-02T19:09:37 <sdaftuar> +1 for merging sooner rather than later
2892017-03-02T19:10:22 <wumpus> well if it is ready for merge it should be merged
2902017-03-02T19:10:22 <sdaftuar> i'm also working on some mining tweaks that i'd rather just build on top of 9602
2912017-03-02T19:10:48 <BlueMatt> wumpus: I believe it needs review and morcos is asking for fast-review because its a pita to rebase constantly
2922017-03-02T19:11:04 <morcos> wumpus: oh ok, i just wanted to coordinate so people were reviewing at the same time frame... thats when the rebases get annoying, when ppl have reviewed different versions. and now it seems people have started reviewing
2932017-03-02T19:11:13 <morcos> so anyone else that is interested, sooner is better than later
2942017-03-02T19:11:30 <gmaxwell> Sounds fine to me, a related subject is that there are a number of other features (like multiwallet) that just missed 0.14 which we should try to get in early rather than later.
2952017-03-02T19:12:04 <wumpus> yes
2962017-03-02T19:12:22 <BlueMatt> yes, I imagine luke's dont-use-pwalletMin thing is a pita to rebase as well
2972017-03-02T19:13:06 <BlueMatt> that would be #8775
2982017-03-02T19:13:09 <gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
2992017-03-02T19:13:18 <gmaxwell> it's also an issue that if these things drag on until late in the cycle they'll miss again.
3002017-03-02T19:14:04 <wumpus> right, so all review multiwallet pulls
3012017-03-02T19:14:48 <wumpus> #8775 should probably go in first
3022017-03-02T19:14:51 <gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
3032017-03-02T19:15:13 <MarcoFalke> They don't conflict according to git merge, so no strict order required
3042017-03-02T19:15:18 <gmaxwell> It might be useful, not in this meeting, but for people to think about what they'd like the big features of 0.15 to be and make sure we make progress early enough on those things so that they can actually be there. :) I feel like there were things that at least I personally wanted in 0.14 but didn't give them enough attention until too late.
3052017-03-02T19:16:02 <morcos> 1 major feature thats in the back of my mind, but a bit complicated so might require some discussion as to whether we want it and when is automated fee-bumping
3062017-03-02T19:16:40 <wumpus> well at least there should be time for features again in 0.15. 0.14 time was mostly spent on segwit
3072017-03-02T19:16:52 *** jannes has joined #bitcoin-core-dev
3082017-03-02T19:16:53 <sipa> famous last words :)
3092017-03-02T19:16:56 <sipa> but i agree
3102017-03-02T19:17:23 <gmaxwell> morcos: I would replace 'automated fee bumping' with 'precomputed fee bumping' E.g. when you sign, presign all the bumps, locktimed... so they don't interfear with the wallet encryption.. and could even be handed off to someone if you go offline.
3112017-03-02T19:17:29 <wumpus> well I don't know of any large upcoming softfork projects monopolizing everyone at least?
3122017-03-02T19:17:45 <gmaxwell> wumpus: everything like that is on hold for segwit!
3132017-03-02T19:18:03 <wumpus> so hopefully for 0.16 again then :)
3142017-03-02T19:18:33 <wumpus> anyhow, it means for 0.15 we can focus on software features instead of network/consensus features
3152017-03-02T19:18:37 <morcos> gmaxwell: do we not have any suggested SF's that aren't built off segwit in the queue? lets take advantage of BIP 9!
3162017-03-02T19:19:11 <sipa> raise min difficulty, optional utxo commitments, ...
3172017-03-02T19:19:12 <gmaxwell> on that subject, we should reconsider some things around how segwit works: that we won't mine once segwit is active without the flag set, and we don't set the versionbit without the flag... Both of these are foolish IMO.
3182017-03-02T19:20:34 <sipa> oh, by flag you mean whether the GBT client indicates support?
3192017-03-02T19:20:45 <gmaxwell> by 'don't set the versionbit without the flag-- if the GBT client doesn't signal segwit support we don't set the BIP 9 bit. Which is stupid, since we'll happily enforce the rules.
3202017-03-02T19:20:48 <sdaftuar> we do that so that segwit can't activate without the miners actually mining segwit transactions
3212017-03-02T19:20:59 <BlueMatt> sdaftuar: I'm not too worried about that
3222017-03-02T19:21:19 <gmaxwell> sdaftuar: yea but I think that is an error. So what if they don't? Then there is just less capacity for segwit txn initially until they upgrade, and they'll lose out on fees.
3232017-03-02T19:21:27 <BlueMatt> I prefer for miners to be able to mine and just lose out on fee revenue than stop mining
3242017-03-02T19:21:44 <wumpus> #action review and merge #8775 and #9602 as soon as possible, they are prone to turning into rebase/merge nightmares
3252017-03-02T19:21:47 <gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
3262017-03-02T19:21:49 <gribble> https://github.com/bitcoin/bitcoin/issues/9602 | Remove coin age priority and free transactions - implementation by morcos · Pull Request #9602 · bitcoin/bitcoin · GitHub
3272017-03-02T19:21:53 <sdaftuar> gmaxwell: my concern (before we got to the point we're at now) was that segwit could have activated with 0 miners mining
3282017-03-02T19:22:00 <sdaftuar> and then mempools could be attacekd with transactions that wouldn't confirm
3292017-03-02T19:22:05 <morcos> gmaxwell: agreed, as long as we know that SOME miners are mining them.. which seems we're at that poin tnow
3302017-03-02T19:22:05 <sdaftuar> perhaps now we can relax it
3312017-03-02T19:22:07 <gmaxwell> sdaftuar: Yes, I agree. That would be silly. But we're not there now. :)
3322017-03-02T19:22:34 <gmaxwell> I didn't protest at the time because of that. (well actually on the stops mining thing, I thought we fixed that)
3332017-03-02T19:22:52 <sipa> suggested topic: CNB calling TBV or not, and CNB caching
3342017-03-02T19:23:12 <gmaxwell> (My misunderstanding was that I thought we stopped mining without the gbt-flag entirely once the code had support for it.. and I saw that wasn't the case)
3352017-03-02T19:24:07 <gmaxwell> We need to get TBV out of the critical path. I do not really agree with lightswords view on it though-- I think it's important that we have some process that tests that blocks were handing out to mine. It does not need to be in the critical path.
3362017-03-02T19:24:41 <wumpus> #topic CNB calling TBV or not, and CNB caching
3372017-03-02T19:24:45 <sipa> i believe that what the code does for an actual miners doesn't matter
3382017-03-02T19:24:53 <morcos> gmaxwell: sipa: i think the downside of leaving it in the critical path is an extra 150ms of mining with an empty block
3392017-03-02T19:25:00 <sipa> yes, that's obvious
3402017-03-02T19:25:05 <sipa> and there are various solutions
3412017-03-02T19:25:08 <gmaxwell> morcos: or worse.
3422017-03-02T19:25:12 <sipa> an easy one (just get rid of the test)
3432017-03-02T19:25:22 <sipa> or a hard one (background validation, caching, ...)
3442017-03-02T19:25:36 *** jannes has quit IRC
3452017-03-02T19:25:46 <gmaxwell> The challenge with backgrounding it is that test holds cs_main for a long time.
3462017-03-02T19:25:55 <morcos> hmm, i guess i was wrong
3472017-03-02T19:25:55 <gmaxwell> I have suggested making the validation it does interruptable.
3482017-03-02T19:26:15 <BlueMatt> gmaxwell: I have suggested that many times :)
3492017-03-02T19:26:17 <morcos> if you want to build on a prior header, you can't have TBV in the critical path, b/c you might not be even able to do it if you dont' have prior block
3502017-03-02T19:26:33 <gmaxwell> E.g. an atomic checked between each transaction which can abort a test validation. This would also be useful for the block proposal validations.
3512017-03-02T19:27:00 <gmaxwell> then an incoming block will set the atomic and then block on acquiring cs_main.
3522017-03-02T19:27:08 <sipa> morcos: well building on a prior header is easy... i'm sure we can build an empty block that's valid
3532017-03-02T19:27:30 <gmaxwell> the background thread would just go to sleep and try again later. Block proposals would just sleep for a bit then try again (while the RPC caller waited)
3542017-03-02T19:27:45 <morcos> yes but we have to have a way of skipping TBV on that block don't we? or some really hacking version that calls TBV on a fake chain active
3552017-03-02T19:28:38 <sipa> an alternative is just having a background process that every so often runs CNB and caches the result
3562017-03-02T19:28:47 <sipa> and then validates it after storing in the cache
3572017-03-02T19:28:56 <gmaxwell> Well my thought would be we'd just have a background loop, running even if you don't mine, that TBVs once a minute or so.. and it can get interrupted. and if its interrupted it just gives up until the next minute.
3582017-03-02T19:29:03 <morcos> it only needs to be out of the criticial path when there is a new tip... when its just updating the block, it doesn't matter if you wait for it
3592017-03-02T19:29:04 <sipa> then GBT can check whether the cached block still builds on top of the best header, and if not, return an empty block
3602017-03-02T19:29:20 *** CubicEarth has quit IRC
3612017-03-02T19:29:24 <gmaxwell> okay if doing what sipa suggests a minute is a bit slow!
3622017-03-02T19:29:40 <sipa> and a new tip would obviously wake the background thread
3632017-03-02T19:29:41 *** CubicEarth has joined #bitcoin-core-dev
3642017-03-02T19:29:50 <gmaxwell> but sounds like we were thinking of similar-ish things.
3652017-03-02T19:30:08 <sipa> however, we wouldn't want such a background CNB for normal nodes
3662017-03-02T19:30:26 <gmaxwell> I dunno, at a low enough frequency it would be fine and would create a lot more in-field testing.
3672017-03-02T19:30:36 <morcos> the good thing about going down that road is you can be smarter about waking the CNB thread to wait until you have new high fee txs that are at least n seconds old or what have you
3682017-03-02T19:30:52 <sdaftuar> morcos: are you going to PR something that calls CNB to keep pcoinsTip warm?
3692017-03-02T19:31:00 <sipa> and it would keep the sigcache warm with what we expect to be mined
3702017-03-02T19:31:01 <morcos> running TBV on slow hardware over and over is probably bad
3712017-03-02T19:31:16 <gmaxwell> One thing I suggested previously is that calling GBT pump the refresh of the cache... so it runs more often if you're calling GBT than otherwise.
3722017-03-02T19:31:31 <sipa> gmaxwell: seems reasonable
3732017-03-02T19:31:41 <morcos> sdaftuar: i don't remember.... but i think the version i had, only ran it once after a flush
3742017-03-02T19:31:54 <sipa> this not only takes TBV out of the critical path, but also CNB
3752017-03-02T19:31:55 <gmaxwell> morcos: once a minute? it wouldn't be horrible. Once every 10 minutes? 20 minutes? I think there is a number where its harmless and we would avoid having code that runs only on a very small number of nodes thus gets inadequate operaiton to expose bugs.
3762017-03-02T19:32:36 <morcos> honestly i think a more important direction to go would be to start by replacing GBT with a better framework
3772017-03-02T19:32:40 <morcos> and then making that work optimally
3782017-03-02T19:32:48 <sipa> morcos: i think this may be orthogonal work
3792017-03-02T19:32:56 <gmaxwell> I think this is more or less orthorgonal to GBT. In that anything else will still need to create a block template. :)
3802017-03-02T19:32:57 <sipa> it'd just be a wrapper around CNB
3812017-03-02T19:33:21 <morcos> i agree its mostly orthogonal.. but one still probably has to occupy our attention first
3822017-03-02T19:33:42 <sipa> well GBT replacement needs a lot of external discussion
3832017-03-02T19:33:50 <gmaxwell> Well there are design considerations in the 'better thing' that hinge really on how fast CNB is ... and the spectrum of options we want to hand out when we can't give an answer fast.
3842017-03-02T19:35:06 <morcos> gmaxwell: hmm.. yes... perhaps what i mean is we should design the better thing so it informs what we want out of CNB/TBV. and document the design so we dont' forget.. even if we don't do it yet
3852017-03-02T19:36:02 <gmaxwell> I think right now I don't have a lot of appetite for major inititavies that we can't just do within the project. But if someone wants to undertake a big coordination effort, that shouldn't slow them down.
3862017-03-02T19:36:13 <gmaxwell> Okay, well an expirement is not something we need permission for... :)
3872017-03-02T19:36:41 <morcos> ok no argument here
3882017-03-02T19:37:08 <morcos> i guess this all hinges on making the TBV code (and maybe even CNB) interruptible
3892017-03-02T19:37:11 *** bsm1175322 has quit IRC
3902017-03-02T19:37:19 <sipa> i think that's relatively easy
3912017-03-02T19:37:57 *** jannes has joined #bitcoin-core-dev
3922017-03-02T19:38:45 <morcos> yeah thinking about it, they both are pretty trivial
3932017-03-02T19:39:20 <gmaxwell> Tightly related to this question is the question of bypassing validation for things in our template. As you may be aware some people have been using in-mempoolness as a proxy for validity. This seems rather sketchy to me, though it should be a pretty substantial latency improvement. The assumption that makes ditching TBV okay also makes doing that okay, I believe. And there is an open alternat
3942017-03-02T19:39:26 <gmaxwell> ive which is potentially more safe, if a transaction is in our template cache for this height, which we've already verified, then its validation could be skipped.
3952017-03-02T19:40:18 <morcos> i'm basically opposed to that
3962017-03-02T19:40:55 <sipa> relying on the template-validation-cache to be correct seems less risky than relying on the mempool itself to be correct
3972017-03-02T19:41:03 <gmaxwell> And if it results in users not using this software but software written by people who don't even know enough to oppose that?
3982017-03-02T19:41:07 <sipa> but it does make TBV consensus critical
3992017-03-02T19:41:09 <morcos> i do think we could do these things while waiting for validation
4002017-03-02T19:41:18 <gmaxwell> In any case, just a thought.
4012017-03-02T19:41:25 <luke-jr> TBV is already consensus-critical, more or less
4022017-03-02T19:41:30 <luke-jr> the code for it anyhow
4032017-03-02T19:41:32 *** wudayoda has quit IRC
4042017-03-02T19:41:33 <gmaxwell> (that using a tested template is safer than the mempool)
4052017-03-02T19:41:58 <sipa> luke-jr: well it uses most of ConnectBlock, which definitely is consensus critical
4062017-03-02T19:42:03 <morcos> e.g. get a new block from the network... -> assume valid -> mark all txs in mempool as potentially used -> CNB from remaining -> have not yet validated new tip or TBV new template, and if we find a block, so be it...
4072017-03-02T19:42:04 <sipa> luke-jr: that overlap is what makes it less risky
4082017-03-02T19:42:27 <gmaxwell> morcos: that is also interesting.
4092017-03-02T19:42:35 <gmaxwell> so fast for mining but nothing else.
4102017-03-02T19:42:38 <morcos> gmaxwell: i guess its not QUITE that easy
4112017-03-02T19:43:10 <gmaxwell> morcos: but in that case you would extend an invalid block, bad.
4122017-03-02T19:43:45 <morcos> gmaxwell: yes but only for a couple hundred ms... you still immediately validate and switch work if there was a problem
4132017-03-02T19:44:04 <gmaxwell> (very bad to have miners extending invalid blocks, even for relatively brief intervals, massively amplifies risk for lite clients-- especially since devices may stay on old work for tens of seconds)
4142017-03-02T19:44:22 <sipa> plan: 1) make TBV interruptible 2) add background thread that caches CNB results 3) make GBT return an empty block if the cache does not build on your tip
4152017-03-02T19:44:27 <gmaxwell> (and I got flamed to death when I suggested a singaling mechenism for lite clients to ignore confirmations constructed that way)
4162017-03-02T19:44:45 <gmaxwell> sipa: that plan sounds good.
4172017-03-02T19:44:51 <morcos> well we can't make our plans based on what you get flamed for can we? :)
4182017-03-02T19:44:56 <BlueMatt> gmaxwell: I'm more a fan of not relying on validation being fast - mine empty blocks for the 100ms it takes to get a blocktemplate, and relay blocks during validation
4192017-03-02T19:44:58 <BlueMatt> problem solved :)
4202017-03-02T19:45:03 <sipa> agree
4212017-03-02T19:45:34 <sipa> where did you get flamed?
4222017-03-02T19:45:38 <gmaxwell> BlueMatt: you still need to validate a block before extending it. To not do so is toxic to lite clients which strongly trust that you have.
4232017-03-02T19:45:41 <gmaxwell> bitcoin-dev
4242017-03-02T19:45:53 <morcos> sipa: ha ha ha, that was a funny
4252017-03-02T19:46:22 <BlueMatt> gmaxwell: oh? every time I've discussed it with anyone in person they're like "yea, do that, sounds good" :)
4262017-03-02T19:46:28 <gmaxwell> I wrote a spec for signaling that you've not validated the prior block. So that lite clients could just ignore those blocks as confirmations.
4272017-03-02T19:46:43 <sipa> morcos: it was an honest question - i can remember gmaxwell bringing it up in here a few times, i didn't know there was more to it
4282017-03-02T19:47:24 <gmaxwell> I wrote a BIP, draft-maxwell-flagverify
4292017-03-02T19:47:24 <BlueMatt> gmaxwell: and I think we should implement that when we go to return empty blocks :)
4302017-03-02T19:47:33 <BlueMatt> I'm happy to go implement it in lite clients, too
4312017-03-02T19:47:53 *** bsm1175322 has joined #bitcoin-core-dev
4322017-03-02T19:49:26 <gmaxwell> I also think the rise in fees is such that it's increasingly less interesting to produce empty blocks.
4332017-03-02T19:50:03 <BlueMatt> true, but 12.5 BTC is sitll > 0 BTC :P
4342017-03-02T19:50:05 <luke-jr> should GBT return partial blocks, as the background thread fills it?
4352017-03-02T19:50:15 <gmaxwell> lightsword isn't here now it seems but previously he has pointed out that returning an empty template is often bad because the downstream software stack doesn't know to try again immediately and so will mine on it for a long time.
4362017-03-02T19:50:22 <BlueMatt> there is just more pressure to limit the time you're spending mining empty blocks :)
4372017-03-02T19:50:43 <BlueMatt> Lightsword: yes he is
4382017-03-02T19:51:11 <luke-jr> gmaxwell: what Eloipool does to solve that, is return a longpollid which is triggered as soon as the full template is available
4392017-03-02T19:51:28 <gmaxwell> BlueMatt: yes but that isn't the tradeoff. Assuming you mine on the template for --say-- 30 seconds, it's 13.4 BTC expected (13.5 - 100ms of mining) vs 12.5. or whatnot.
4402017-03-02T19:51:51 *** MarcoFalke_ has quit IRC
4412017-03-02T19:52:27 <sipa> well, we could optionally also make GBT return a partial block and/or block until the full block is available (but not yet TBVed)
4422017-03-02T19:52:39 <gmaxwell> e.g. current fees pay for 100ms of delay easily.
4432017-03-02T19:52:45 <BlueMatt> gmaxwell: oh? I believe most pools can push a "hard update" or whatever its called
4442017-03-02T19:52:52 <BlueMatt> that will force the asic to switch
4452017-03-02T19:52:52 <sipa> moving the actual construction to the background won't hurt
4462017-03-02T19:52:56 <BlueMatt> there is a flag in stratum for it
4472017-03-02T19:53:16 <BlueMatt> (to flush workqueue in asic)
4482017-03-02T19:53:18 <gmaxwell> BlueMatt: for some hardware retargeting causes misbehavior/loss of performance.
4492017-03-02T19:53:50 <gmaxwell> In any case, it isn't so simple.
4502017-03-02T19:53:55 <BlueMatt> fair
4512017-03-02T19:54:09 <BlueMatt> I assume most modern hardware supports it, though
4522017-03-02T19:54:13 <BlueMatt> given that most pools do this
4532017-03-02T19:54:19 <BlueMatt> incl pools run by the hardware mfgrs
4542017-03-02T19:54:19 <gmaxwell> Do not assume that.
4552017-03-02T19:54:29 <BlueMatt> ok, fair
4562017-03-02T19:54:40 <sipa> we're running out of time
4572017-03-02T19:54:44 <sipa> any other topics?
4582017-03-02T19:54:49 <gmaxwell> quick, empty messages
4592017-03-02T19:54:52 <sipa>
4602017-03-02T19:54:54 <luke-jr>
4612017-03-02T19:55:05 <wumpus>
4622017-03-02T19:55:22 <gmaxwell>
4632017-03-02T19:55:31 <luke-jr> inb4 trolls use this as proof we obey gmaxwell
4642017-03-02T19:55:37 <gwillen>
4652017-03-02T19:56:07 <BlueMatt> lulwut
4662017-03-02T19:56:21 <wumpus> #topic
4672017-03-02T19:56:26 <sipa> it's "lolwut", BlueMatt.
4682017-03-02T19:56:38 <BlueMatt> lulzwutz
4692017-03-02T19:56:49 <wumpus> cleared the topic, too, now we can cleanly exit the meeting
4702017-03-02T19:56:50 <gmaxwell> We should appoint a subcommittee to investigate the spelling of lolwut/lulwut.
4712017-03-02T19:56:59 <wumpus> #endmeeting
4722017-03-02T19:56:59 <lightningbot> Meeting ended Thu Mar 2 19:56:59 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4732017-03-02T19:56:59 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.html
4742017-03-02T19:56:59 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.txt
4752017-03-02T19:56:59 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.log.html
4762017-03-02T19:59:06 <Chris_Stewart_5> What do the acronyms CNB and TBV stand for?
4772017-03-02T19:59:48 <sipa> CreateNewBlock, TestBlockValidity
4782017-03-02T19:59:57 <Chris_Stewart_5> Thanks.
4792017-03-02T20:01:58 *** wudayoda has joined #bitcoin-core-dev
4802017-03-02T20:03:57 *** Giszmo1 has quit IRC
4812017-03-02T20:04:19 *** Giszmo has joined #bitcoin-core-dev
4822017-03-02T20:06:57 *** wudayoda has quit IRC
4832017-03-02T20:09:09 <Lightsword> gmaxwell, morcos, sipa, one other approach is to use a more strictly performance optimized version of CNB for the first block template that doesnât do all the fee maximizing calculations and just takes the top of the mempool
4842017-03-02T20:09:49 <gmaxwell> Lightsword: the fee stuff I think takes pratically no time at all.
4852017-03-02T20:09:58 <gmaxwell> because it's all built from efficient indexes.
4862017-03-02T20:11:08 <gmaxwell> An empty template can be faster because it can be constructed without the prior block having removed its transactions from the mempool... because it needs ~no hashing to construct, etc.
4872017-03-02T20:11:46 <gmaxwell> back in the days of priority constructing a template was objectively slow. Now it's just traversing a precomputed index pretty much.
4882017-03-02T20:12:10 <Lightsword> gmaxwell, do we loop over the index more than once?
4892017-03-02T20:12:13 <sipa> no
4902017-03-02T20:13:14 <sipa> but it's a big data structure, traversing indexes that are spread out over memory can take time
4912017-03-02T20:13:27 <sdaftuar> fyi i've been benchmarking today
4922017-03-02T20:13:41 <sdaftuar> it's a bit slower now than it was last time i benchmarked, so i'm going to investigate
4932017-03-02T20:14:15 <gmaxwell> Interesting. previously and my expectation was that it was just a couple milliseconds, and that we spend more time seralizing the data to json.
4942017-03-02T20:14:18 <Lightsword> how much overhead is GetMemPoolChildren? https://github.com/bitcoin/bitcoin/blob/cbdb4732f10cb00ec46a35e5c7adb2c4cdf1d64d/src/miner.cpp#L596
4952017-03-02T20:14:42 <sdaftuar> yeah it used to be like 7-10ms of transaction selection, followed by ~35-45ms of TBV, or something like that
4962017-03-02T20:15:04 <sdaftuar> but on my runs today on data from December, it's been more like 30-40ms for each of those parts, maybe a bit more
4972017-03-02T20:15:21 <gmaxwell> That is interesting.
4982017-03-02T20:15:29 <sdaftuar> Lightsword: depends on the state of the mempool. i think it's possible that if there are more chained transactinos now than the last time i analyzed, it could slow things down
4992017-03-02T20:15:52 <sipa> Lightsword: GetMemPoolChildren just returns a reference to a precomputed list of children
5002017-03-02T20:16:12 <sipa> i wonder if BOOST_FOREACH makes a copy of it, though
5012017-03-02T20:16:13 <sdaftuar> oops, i was thinking of CalculateMemPoolDescendants() or whatever :)
5022017-03-02T20:16:15 <Lightsword> sdaftaur, are there any other calls similar to that which could be potentially skipped on the first run through the mempool?
5032017-03-02T20:16:44 <sdaftuar> Lightsword: potentially, yeah we could consider dropping the re-sorting of descendants of selected transactions
5042017-03-02T20:16:59 <sdaftuar> i'll add that to my list of things to consider
5052017-03-02T20:17:30 <Lightsword> my thoughts are that the CNB first call after a block change we can skip descendant calculations entirely and only add transactions that have confirmed inputs
5062017-03-02T20:18:10 <gmaxwell> well you could also only take the highest feerate transactions that capture something like 90% of the available fee, and potentially return a short template that will be faster to seralize and send.
5072017-03-02T20:18:55 <gmaxwell> but you will still need to wait then for the prior block to remove transactions from the mempool... which is not blindingly fast.
5082017-03-02T20:19:13 <Lightsword> how long are you seeing full GBT serialization take?
5092017-03-02T20:20:19 <cfields> dammit, I managed to completely miss the meeting
5102017-03-02T20:20:42 *** paveljanik has joined #bitcoin-core-dev
5112017-03-02T20:20:59 <Lightsword> cfields, we decided you get to rewrite GBT :P
5122017-03-02T20:21:36 <cfields> heh
5132017-03-02T20:22:45 <cfields> I blame wumpus :p. i was distracted by the fs abstraction and lost track of time.
5142017-03-02T20:24:12 <jeremyrubin> cfields: https://www.youtube.com/watch?v=OXc5ltzKq3Y
5152017-03-02T20:25:04 <cfields> haha
5162017-03-02T20:25:18 <wumpus> cfields: sorry :p
5172017-03-02T20:26:01 <cfields> wumpus: good problem to have :). Nice work.
5182017-03-02T20:26:02 <jonasschnelli> I pimped my build server (nightly, PR, release builds): https://bitcoinsrv.jonasschnelli.ch (if anyone cares)
5192017-03-02T20:27:41 <wumpus> cfields: Thanks! heh myself I got stuck on a very weird miscompile issue with clang: https://github.com/NuxiNL/cloudabi-ports/issues/30 (likely nothing we have to worry about for our builds, except that we shouldn't be enabling safestack for now)
5202017-03-02T20:27:52 <wumpus> jonasschnelli: cool
5212017-03-02T20:29:59 <jeremyrubin> wumpus: does they cloudabi stuff exist locally as a sandbox you then run bitcoin in or do you compile it in?
5222017-03-02T20:30:20 <wumpus> jonasschnelli: : that web interface is pretty neat
5232017-03-02T20:31:10 <cfields> wumpus: nice responsiveness from them
5242017-03-02T20:31:16 <wumpus> jeremyrubin: the normal way is to use "cross-compilation", which are available for various platforms. I don't think the compilers themselves run in it yet
5252017-03-02T20:31:51 <wumpus> cfields: yes absolutely!
5262017-03-02T20:32:11 <cfields> wumpus: i wonder if this effort would help with enabling sandboxing for macos as well
5272017-03-02T20:32:21 <cfields> similar restrictions, i would assume
5282017-03-02T20:32:31 <wumpus> cfields: I think so
5292017-03-02T20:32:41 <jeremyrubin> I guess I was asking because it would be easier to run untrusted binaries
5302017-03-02T20:32:54 *** CubicEarth has quit IRC
5312017-03-02T20:33:36 <jeremyrubin> e.g., you run the launcher program that you know is secure on your machine, which passes the FD to the binary that's marked as unable to get any new capabilities
5322017-03-02T20:34:03 <wumpus> jeremyrubin: yes, that's what you can use it for
5332017-03-02T20:34:34 *** wudayoda has joined #bitcoin-core-dev
5342017-03-02T20:35:02 <wumpus> jeremyrubin: the program cannot do anything that you haven't allowed to it, not look around the filesystem, not look at hardware identifiers, not connect to the network, etc
5352017-03-02T20:35:29 <cfields> jonasschnelli: very cool
5362017-03-02T20:37:48 *** str4d has quit IRC
5372017-03-02T20:39:13 *** wudayoda has quit IRC
5382017-03-02T20:41:34 *** kadoban has joined #bitcoin-core-dev
5392017-03-02T20:46:56 *** Sosumi has quit IRC
5402017-03-02T20:56:49 <jeremyrubin> wumpus: but only if you know you compiled it? If someone else compiled it, they could just not link against cloudabi
5412017-03-02T20:59:45 <jeremyrubin> random question:
5422017-03-02T21:00:06 <jeremyrubin> How important is it that CPubKey::Verify takes a hash?
5432017-03-02T21:00:22 <jeremyrubin> e.g., could it be any (padded to 32 byte) data safely?
5442017-03-02T21:00:47 <cfields> jeremyrubin: i assume it sets a libc dep, or even elf identifier
5452017-03-02T21:01:50 <cfields> jeremyrubin: for what purpose?
5462017-03-02T21:01:55 *** laurentmt has quit IRC
5472017-03-02T21:02:58 <jeremyrubin> cfields: looking at checksigfromstack implementation
5482017-03-02T21:03:09 <jeremyrubin> cfields: I don't think it should include a digest
5492017-03-02T21:06:06 *** wudayoda has joined #bitcoin-core-dev
5502017-03-02T21:08:56 <jeremyrubin> yeah I can't think of how it could be unsafe (except maybe unsafe for signers if they sign 0 or something)
5512017-03-02T21:09:05 <cfields> jeremyrubin: er, we surely don't want that calculation happening at the pubkey layer?
5522017-03-02T21:10:34 *** wudayoda has quit IRC
5532017-03-02T21:34:24 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/65d90f585a83...f7ec7cfd38b5
5542017-03-02T21:34:24 <bitcoin-git> bitcoin/master 7ed143c Russell Yanofsky: Add test for CWalletTx::GetImmatureCredit() returning stale values....
5552017-03-02T21:34:25 <bitcoin-git> bitcoin/master f7ec7cf MarcoFalke: Merge #9359: Add test for CWalletTx::GetImmatureCredit() returning stale values....
5562017-03-02T21:34:40 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9359: Add test for CWalletTx::GetImmatureCredit() returning stale values. (master...pr/immature) https://github.com/bitcoin/bitcoin/pull/9359
5572017-03-02T21:35:45 *** wudayoda has joined #bitcoin-core-dev
5582017-03-02T21:54:20 *** Guyver2 has quit IRC
5592017-03-02T21:57:22 *** chjj has quit IRC
5602017-03-02T22:08:53 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9905: contrib: Move second sha512 check to the end (master...Mf1703-gh-merge) https://github.com/bitcoin/bitcoin/pull/9905
5612017-03-02T22:18:23 <arubi> does anyone know, was there ever a writeup \ -dev thread about witnessV1\sighashV2 from jl2012's mastV3 fork I see it enables a lot more ways to sign transactions. I'd appreciate a manual :)
5622017-03-02T22:18:51 <arubi> s/from/? from
5632017-03-02T22:29:03 <arubi> talking about https://git.io/vynmA and https://git.io/vynmh (python, c++)
5642017-03-02T22:48:58 *** JackH has quit IRC
5652017-03-02T22:51:15 *** Taek42 is now known as Taek
5662017-03-02T22:56:01 *** chjj has joined #bitcoin-core-dev
5672017-03-02T23:02:13 *** chjj has quit IRC
5682017-03-02T23:02:27 *** wudayoda has quit IRC
5692017-03-02T23:03:01 *** chjj has joined #bitcoin-core-dev
5702017-03-02T23:06:03 *** refused has joined #bitcoin-core-dev
5712017-03-02T23:06:18 *** chjj has quit IRC
5722017-03-02T23:06:35 *** chjj has joined #bitcoin-core-dev
5732017-03-02T23:07:34 *** JackH has joined #bitcoin-core-dev
5742017-03-02T23:18:27 *** Giszmo has quit IRC
5752017-03-02T23:21:27 *** refused is now known as b3f0r3
5762017-03-02T23:32:09 *** b3f0r3 has quit IRC
5772017-03-02T23:33:04 *** wudayoda has joined #bitcoin-core-dev
5782017-03-02T23:38:05 *** wudayoda has quit IRC
5792017-03-02T23:40:09 *** MarcoFalke has left #bitcoin-core-dev
5802017-03-02T23:48:40 *** dgenr8 has quit IRC
5812017-03-02T23:49:32 *** dgenr8 has joined #bitcoin-core-dev
5822017-03-02T23:50:06 *** Ylbam has joined #bitcoin-core-dev
5832017-03-02T23:52:19 *** bityogi has quit IRC
5842017-03-02T23:57:02 *** jannes has quit IRC
5852017-03-02T23:59:52 *** chjj has quit IRC