12019-07-25T00:00:01  *** hcchien has quit IRC
  22019-07-25T00:03:00  *** ozbot has joined #bitcoin-core-dev
  32019-07-25T00:27:50  *** EagleTM has joined #bitcoin-core-dev
  42019-07-25T00:28:56  *** AaronvanW has joined #bitcoin-core-dev
  52019-07-25T00:33:23  *** AaronvanW has quit IRC
  62019-07-25T00:38:51  <fanquake> cfields: Would you be able to put the 10.14 macOS SDK up onto bitcoincore.org, or wherever Travis pulls the current SDK from?
  72019-07-25T00:39:05  <fanquake> It's blocking Travis in #16392.
  82019-07-25T00:39:07  <gribble> https://github.com/bitcoin/bitcoin/issues/16392 | WIP build: macOS toolchain update by fanquake · Pull Request #16392 · bitcoin/bitcoin · GitHub
  92019-07-25T00:43:31  *** Eagle[TM] has joined #bitcoin-core-dev
 102019-07-25T00:44:50  *** EagleTM has quit IRC
 112019-07-25T00:45:31  *** EagleTM has joined #bitcoin-core-dev
 122019-07-25T00:48:40  *** Eagle[TM] has quit IRC
 132019-07-25T00:50:20  *** captjakk has quit IRC
 142019-07-25T00:50:36  *** captjakk has joined #bitcoin-core-dev
 152019-07-25T00:51:14  *** toto99 has joined #bitcoin-core-dev
 162019-07-25T00:51:55  *** captjakk has joined #bitcoin-core-dev
 172019-07-25T01:05:56  *** bitcoin-git has joined #bitcoin-core-dev
 182019-07-25T01:05:57  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d960d5ca99b7...d5a54ce8f0cf
 192019-07-25T01:05:58  <bitcoin-git> bitcoin/master 4433ed0 Suhas Daftuar: [validation] Crash if disconnecting a block fails
 202019-07-25T01:05:59  <bitcoin-git> bitcoin/master a47df13 Suhas Daftuar: [qa] Test disconnect block failure -> shutdown
 212019-07-25T01:05:59  <bitcoin-git> bitcoin/master d5a54ce fanquake: Merge #15305: [validation] Crash if disconnecting a block fails
 222019-07-25T01:06:01  *** bitcoin-git has left #bitcoin-core-dev
 232019-07-25T01:06:31  *** bitcoin-git has joined #bitcoin-core-dev
 242019-07-25T01:06:31  <bitcoin-git> [bitcoin] fanquake merged pull request #15305: [validation] Crash if disconnecting a block fails (master...2019-01-disconnect-failure-shutdown) https://github.com/bitcoin/bitcoin/pull/15305
 252019-07-25T01:06:33  *** bitcoin-git has left #bitcoin-core-dev
 262019-07-25T01:07:06  *** AaronvanW has joined #bitcoin-core-dev
 272019-07-25T01:11:42  *** jeremyrubin has quit IRC
 282019-07-25T01:12:06  *** AaronvanW has quit IRC
 292019-07-25T01:20:42  *** toto99 has quit IRC
 302019-07-25T01:23:27  *** Eagle[TM] has joined #bitcoin-core-dev
 312019-07-25T01:27:03  *** EagleTM has quit IRC
 322019-07-25T01:40:30  *** EagleTM has joined #bitcoin-core-dev
 332019-07-25T01:42:26  *** Eagle[TM] has quit IRC
 342019-07-25T01:44:36  *** bitcoin-git has joined #bitcoin-core-dev
 352019-07-25T01:44:36  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d5a54ce8f0cf...fe001925f803
 362019-07-25T01:44:36  <bitcoin-git> bitcoin/master 77773ed MarcoFalke: doc: Remove downgrading warning in release notes, per 0.18 branch
 372019-07-25T01:44:37  <bitcoin-git> bitcoin/master fe00192 fanquake: Merge #16455: doc: Remove downgrading warning in release notes, per 0.18 b...
 382019-07-25T01:44:38  *** bitcoin-git has left #bitcoin-core-dev
 392019-07-25T01:45:22  *** DeanWeen has joined #bitcoin-core-dev
 402019-07-25T01:45:41  *** bitcoin-git has joined #bitcoin-core-dev
 412019-07-25T01:45:41  <bitcoin-git> [bitcoin] fanquake merged pull request #16455: doc: Remove downgrading warning in release notes, per 0.18 branch (master...1907-docReleaseNotes) https://github.com/bitcoin/bitcoin/pull/16455
 422019-07-25T01:45:44  *** bitcoin-git has left #bitcoin-core-dev
 432019-07-25T01:46:55  *** AaronvanW has joined #bitcoin-core-dev
 442019-07-25T01:51:35  *** AaronvanW has quit IRC
 452019-07-25T01:52:50  *** Eagle[TM] has joined #bitcoin-core-dev
 462019-07-25T01:54:06  *** AaronvanW has joined #bitcoin-core-dev
 472019-07-25T01:54:15  *** EagleTM has quit IRC
 482019-07-25T02:04:09  *** EagleTM has joined #bitcoin-core-dev
 492019-07-25T02:08:02  *** Eagle[TM] has quit IRC
 502019-07-25T02:08:22  *** Eagle[TM] has joined #bitcoin-core-dev
 512019-07-25T02:10:42  *** EagleTM has quit IRC
 522019-07-25T02:17:58  *** justanotheruser has quit IRC
 532019-07-25T02:20:39  *** justanotheruser has joined #bitcoin-core-dev
 542019-07-25T02:25:37  *** elichai2 has quit IRC
 552019-07-25T02:32:34  *** cdecker has quit IRC
 562019-07-25T02:45:04  *** pinheadmz has quit IRC
 572019-07-25T02:47:49  *** promag has quit IRC
 582019-07-25T02:48:33  *** promag has joined #bitcoin-core-dev
 592019-07-25T02:49:39  *** pinheadmz has joined #bitcoin-core-dev
 602019-07-25T03:00:02  *** ozbot has quit IRC
 612019-07-25T03:04:25  *** secdragon has joined #bitcoin-core-dev
 622019-07-25T03:07:53  *** schnerchi has joined #bitcoin-core-dev
 632019-07-25T03:10:58  *** schnerch_ has quit IRC
 642019-07-25T03:19:22  *** EagleTM has joined #bitcoin-core-dev
 652019-07-25T03:21:17  *** Eagle[TM] has quit IRC
 662019-07-25T03:21:33  *** DeanWeen has quit IRC
 672019-07-25T03:28:36  *** xuing has joined #bitcoin-core-dev
 682019-07-25T03:52:31  *** hebasto_ has quit IRC
 692019-07-25T03:53:47  *** DeanGuss has joined #bitcoin-core-dev
 702019-07-25T04:09:07  *** kcalvinalvin has joined #bitcoin-core-dev
 712019-07-25T04:14:10  *** kcalvinalvin has quit IRC
 722019-07-25T04:31:48  *** Victor_sueca has joined #bitcoin-core-dev
 732019-07-25T04:34:42  *** Victorsueca has quit IRC
 742019-07-25T04:37:10  *** pinheadmz has quit IRC
 752019-07-25T04:41:18  *** pinheadmz has joined #bitcoin-core-dev
 762019-07-25T05:14:04  *** kcalvinalvin has joined #bitcoin-core-dev
 772019-07-25T06:00:01  *** secdragon has quit IRC
 782019-07-25T06:02:42  *** d_t has joined #bitcoin-core-dev
 792019-07-25T06:14:20  *** Bullitje has joined #bitcoin-core-dev
 802019-07-25T06:15:26  *** inquis has joined #bitcoin-core-dev
 812019-07-25T06:17:03  *** cryptapus_ has joined #bitcoin-core-dev
 822019-07-25T06:17:03  *** cryptapus_ has quit IRC
 832019-07-25T06:17:03  *** cryptapus_ has joined #bitcoin-core-dev
 842019-07-25T06:17:40  *** Bullit has quit IRC
 852019-07-25T06:18:00  *** cryptapus has quit IRC
 862019-07-25T06:37:07  *** ryanofsky has quit IRC
 872019-07-25T06:50:49  *** d_t has quit IRC
 882019-07-25T07:01:35  *** timothy has joined #bitcoin-core-dev
 892019-07-25T07:03:46  *** liberiga has joined #bitcoin-core-dev
 902019-07-25T07:05:56  *** d_t has joined #bitcoin-core-dev
 912019-07-25T07:08:49  *** EagleTM has quit IRC
 922019-07-25T07:26:28  *** calkob has joined #bitcoin-core-dev
 932019-07-25T07:27:04  *** Deadhand has quit IRC
 942019-07-25T07:28:23  *** d_t has quit IRC
 952019-07-25T07:29:24  *** calkob has left #bitcoin-core-dev
 962019-07-25T07:33:10  *** Deadhand has joined #bitcoin-core-dev
 972019-07-25T07:42:50  *** kljasdfvv has joined #bitcoin-core-dev
 982019-07-25T07:52:43  *** xuing has quit IRC
 992019-07-25T07:55:56  *** EagleTM has joined #bitcoin-core-dev
1002019-07-25T08:10:06  *** jungly has joined #bitcoin-core-dev
1012019-07-25T08:15:23  *** EagleTM has quit IRC
1022019-07-25T08:15:45  *** EagleTM has joined #bitcoin-core-dev
1032019-07-25T08:18:47  *** EagleTM has quit IRC
1042019-07-25T08:19:09  *** EagleTM has joined #bitcoin-core-dev
1052019-07-25T08:19:48  *** dendisuhubdy has joined #bitcoin-core-dev
1062019-07-25T08:20:43  *** dgfhdfg has joined #bitcoin-core-dev
1072019-07-25T08:21:23  *** kcalvinalvin has quit IRC
1082019-07-25T08:22:11  *** EagleTM has quit IRC
1092019-07-25T08:22:33  *** EagleTM has joined #bitcoin-core-dev
1102019-07-25T08:27:35  *** EagleTM has quit IRC
1112019-07-25T08:27:59  *** EagleTM has joined #bitcoin-core-dev
1122019-07-25T08:30:57  *** Victor_sueca is now known as Victorsueca
1132019-07-25T08:34:04  *** setpill has joined #bitcoin-core-dev
1142019-07-25T08:36:52  *** dendisuhubdy has quit IRC
1152019-07-25T08:49:56  *** EagleTM has quit IRC
1162019-07-25T08:50:08  *** laptop500 has joined #bitcoin-core-dev
1172019-07-25T08:50:19  *** EagleTM has joined #bitcoin-core-dev
1182019-07-25T08:56:48  *** EagleTM has quit IRC
1192019-07-25T08:57:15  *** tnaka_ has joined #bitcoin-core-dev
1202019-07-25T09:00:02  *** inquis has quit IRC
1212019-07-25T09:02:40  *** queip has quit IRC
1222019-07-25T09:06:52  *** queip has joined #bitcoin-core-dev
1232019-07-25T09:09:53  *** akionak has joined #bitcoin-core-dev
1242019-07-25T09:14:39  *** ihower has joined #bitcoin-core-dev
1252019-07-25T09:28:37  *** kcalvinalvin has joined #bitcoin-core-dev
1262019-07-25T09:34:00  *** spinza has quit IRC
1272019-07-25T09:39:08  *** Kevin30 has joined #bitcoin-core-dev
1282019-07-25T09:39:24  *** ihower has quit IRC
1292019-07-25T09:41:01  *** lugosi1 has joined #bitcoin-core-dev
1302019-07-25T09:41:02  *** kcalvina_ has joined #bitcoin-core-dev
1312019-07-25T09:44:05  *** kcalvinalvin has quit IRC
1322019-07-25T09:44:59  *** ryanofsky has joined #bitcoin-core-dev
1332019-07-25T09:53:18  *** spinza has joined #bitcoin-core-dev
1342019-07-25T10:08:11  *** kcalvina_ has quit IRC
1352019-07-25T10:27:33  *** ptiyoyip has joined #bitcoin-core-dev
1362019-07-25T10:27:39  *** Kevin30 has quit IRC
1372019-07-25T10:28:24  *** queip has quit IRC
1382019-07-25T10:29:53  *** AaronvanW has quit IRC
1392019-07-25T10:31:22  *** dgfhdfg has quit IRC
1402019-07-25T10:38:29  *** queip has joined #bitcoin-core-dev
1412019-07-25T10:47:09  *** lnostdal has quit IRC
1422019-07-25T10:52:02  *** rh0nj has quit IRC
1432019-07-25T10:53:07  *** rh0nj has joined #bitcoin-core-dev
1442019-07-25T10:53:30  *** AaronvanW has joined #bitcoin-core-dev
1452019-07-25T11:35:03  *** schnerchi has quit IRC
1462019-07-25T11:37:35  *** schnerchi has joined #bitcoin-core-dev
1472019-07-25T11:40:55  <jonasschnelli> MarcoFalke: feature_block.py failed now for the second time in 24h in master (in my CI): https://bitcoinbuilds.org/index.php?ansilog=2ff386f7-798c-4f9a-8233-dc62978cb175.log#l7076
1482019-07-25T11:40:57  <jonasschnelli> any ideas?
1492019-07-25T11:47:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1502019-07-25T11:49:31  *** zivl has joined #bitcoin-core-dev
1512019-07-25T11:54:40  *** jungly has quit IRC
1522019-07-25T11:59:10  *** ossifrage_ has joined #bitcoin-core-dev
1532019-07-25T11:59:16  *** ossifrage has quit IRC
1542019-07-25T12:00:02  *** lugosi1 has quit IRC
1552019-07-25T12:01:38  *** BGL has quit IRC
1562019-07-25T12:04:12  *** ZeroZiat has joined #bitcoin-core-dev
1572019-07-25T12:20:44  *** liberiga has quit IRC
1582019-07-25T12:24:47  *** ryufghj has joined #bitcoin-core-dev
1592019-07-25T12:24:55  *** ptiyoyip has quit IRC
1602019-07-25T12:39:01  *** kcalvinalvin has joined #bitcoin-core-dev
1612019-07-25T12:44:12  *** shesek has joined #bitcoin-core-dev
1622019-07-25T12:44:13  *** shesek has quit IRC
1632019-07-25T12:44:13  *** shesek has joined #bitcoin-core-dev
1642019-07-25T12:44:58  *** kcalvinalvin has quit IRC
1652019-07-25T12:46:37  *** Emcy has quit IRC
1662019-07-25T12:48:28  *** ryufghj has quit IRC
1672019-07-25T12:49:29  *** Emcy has joined #bitcoin-core-dev
1682019-07-25T12:53:23  *** promag has quit IRC
1692019-07-25T12:53:35  *** promag has joined #bitcoin-core-dev
1702019-07-25T13:11:35  *** shigeya has quit IRC
1712019-07-25T13:12:24  *** shigeya has joined #bitcoin-core-dev
1722019-07-25T13:13:06  *** sipa has quit IRC
1732019-07-25T13:19:02  *** lnostdal has joined #bitcoin-core-dev
1742019-07-25T13:23:27  *** sipa has joined #bitcoin-core-dev
1752019-07-25T13:34:59  *** BGL has joined #bitcoin-core-dev
1762019-07-25T13:50:47  *** d_t has joined #bitcoin-core-dev
1772019-07-25T13:55:25  *** d_t has quit IRC
1782019-07-25T13:56:36  *** davterra has joined #bitcoin-core-dev
1792019-07-25T14:01:20  *** laptop500 has quit IRC
1802019-07-25T14:06:48  *** DeanGuss has quit IRC
1812019-07-25T14:18:40  *** elichai2 has joined #bitcoin-core-dev
1822019-07-25T14:19:13  *** bitcoin-git has joined #bitcoin-core-dev
1832019-07-25T14:19:13  <bitcoin-git> [bitcoin] Chunbao opened pull request #16457: test (0.18...master) https://github.com/bitcoin/bitcoin/pull/16457
1842019-07-25T14:19:15  *** bitcoin-git has left #bitcoin-core-dev
1852019-07-25T14:20:03  *** bitcoin-git has joined #bitcoin-core-dev
1862019-07-25T14:20:03  <bitcoin-git> [bitcoin] fanquake closed pull request #16457: test (0.18...master) https://github.com/bitcoin/bitcoin/pull/16457
1872019-07-25T14:20:06  *** bitcoin-git has left #bitcoin-core-dev
1882019-07-25T14:20:50  *** davterra has quit IRC
1892019-07-25T14:21:18  *** davterra has joined #bitcoin-core-dev
1902019-07-25T14:24:11  *** captjakk has quit IRC
1912019-07-25T14:32:22  *** goatpig has joined #bitcoin-core-dev
1922019-07-25T14:38:02  *** as1nc has quit IRC
1932019-07-25T14:47:03  *** bitcoin-git has joined #bitcoin-core-dev
1942019-07-25T14:47:03  <bitcoin-git> [bitcoin] Chunbao opened pull request #16458: Fix msvc compiler error C4146 (unary minus operator applied to unsign… (0.17...fix-C4146-in-util-test) https://github.com/bitcoin/bitcoin/pull/16458
1952019-07-25T14:47:05  *** bitcoin-git has left #bitcoin-core-dev
1962019-07-25T14:53:27  *** hebasto has joined #bitcoin-core-dev
1972019-07-25T14:57:19  *** rajarshi has joined #bitcoin-core-dev
1982019-07-25T14:58:33  *** michaelsdunn1 has joined #bitcoin-core-dev
1992019-07-25T15:00:02  *** ZeroZiat has quit IRC
2002019-07-25T15:04:51  *** NikolaiToryzin has joined #bitcoin-core-dev
2012019-07-25T15:07:50  *** davterra has quit IRC
2022019-07-25T15:14:22  *** davterra has joined #bitcoin-core-dev
2032019-07-25T15:16:44  *** Chris_Stewart_5 has quit IRC
2042019-07-25T15:18:47  *** davterra has quit IRC
2052019-07-25T15:22:31  *** lightlike has joined #bitcoin-core-dev
2062019-07-25T15:31:10  *** bitcoin-git has joined #bitcoin-core-dev
2072019-07-25T15:31:11  <bitcoin-git> [bitcoin] sdaftuar opened pull request #16459: [qa] Fix race condition in example_test.py (master...2019-07-fix-example-test) https://github.com/bitcoin/bitcoin/pull/16459
2082019-07-25T15:31:24  *** bitcoin-git has left #bitcoin-core-dev
2092019-07-25T15:31:50  *** bitcoin-git has joined #bitcoin-core-dev
2102019-07-25T15:31:50  <bitcoin-git> [bitcoin] Chunbao opened pull request #16460: 0.17my (0.17...master) https://github.com/bitcoin/bitcoin/pull/16460
2112019-07-25T15:32:03  *** bitcoin-git has left #bitcoin-core-dev
2122019-07-25T15:33:27  *** bitcoin-git has joined #bitcoin-core-dev
2132019-07-25T15:33:28  <bitcoin-git> [bitcoin] fanquake closed pull request #16460: 0.17my (0.17...master) https://github.com/bitcoin/bitcoin/pull/16460
2142019-07-25T15:33:29  *** bitcoin-git has left #bitcoin-core-dev
2152019-07-25T15:46:30  *** kljasdfvv has quit IRC
2162019-07-25T15:49:10  *** bitcoin-git has joined #bitcoin-core-dev
2172019-07-25T15:49:10  <bitcoin-git> [bitcoin] promag opened pull request #16461: doc: Fix code example in developer notes (master...2019-07-fix-devnotes) https://github.com/bitcoin/bitcoin/pull/16461
2182019-07-25T15:49:11  *** bitcoin-git has left #bitcoin-core-dev
2192019-07-25T15:49:54  *** owowo has quit IRC
2202019-07-25T15:52:16  <sdaftuar_> jonasschnelli: that is a very strange failure. it looks like the test is trying to construct a 1000000byte block to test p2sh sigop counting, but somehow in your test failure the block was 1000001 bytes, which is why it broke
2212019-07-25T15:52:39  <sdaftuar_> jonasschnelli: maybe there is some non-determinism in the test that we need to track down
2222019-07-25T15:53:14  *** rajarshi has quit IRC
2232019-07-25T15:53:38  *** davterra has joined #bitcoin-core-dev
2242019-07-25T15:54:01  *** owowo has joined #bitcoin-core-dev
2252019-07-25T15:54:01  *** owowo has joined #bitcoin-core-dev
2262019-07-25T15:56:10  *** setpill has quit IRC
2272019-07-25T16:07:18  *** michaelsdunn1 has quit IRC
2282019-07-25T16:14:03  *** emilengler has joined #bitcoin-core-dev
2292019-07-25T16:14:33  *** emilengler has quit IRC
2302019-07-25T16:14:54  *** emilengler has joined #bitcoin-core-dev
2312019-07-25T16:15:12  *** bitcoin-git has joined #bitcoin-core-dev
2322019-07-25T16:15:12  <bitcoin-git> [bitcoin] Chunbao opened pull request #16462: jjjj (0.17...0.18) https://github.com/bitcoin/bitcoin/pull/16462
2332019-07-25T16:15:13  *** bitcoin-git has left #bitcoin-core-dev
2342019-07-25T16:15:31  <emilengler> Hi, what was still the name of the channel where pull requests were being discussed every thursday?
2352019-07-25T16:16:02  *** bitcoin-git has joined #bitcoin-core-dev
2362019-07-25T16:16:02  <bitcoin-git> [bitcoin] laanwj closed pull request #16462: jjjj (0.17...0.18) https://github.com/bitcoin/bitcoin/pull/16462
2372019-07-25T16:16:07  *** bitcoin-git has left #bitcoin-core-dev
2382019-07-25T16:17:54  *** emilengler has quit IRC
2392019-07-25T16:18:05  *** emilengler has joined #bitcoin-core-dev
2402019-07-25T16:18:50  *** emilengler has quit IRC
2412019-07-25T16:19:01  *** emilengler has joined #bitcoin-core-dev
2422019-07-25T16:25:52  *** michaelsdunn1 has joined #bitcoin-core-dev
2432019-07-25T16:25:53  *** michaelsdunn1 has quit IRC
2442019-07-25T16:25:53  *** michaelsdunn1 has joined #bitcoin-core-dev
2452019-07-25T16:33:49  *** kcalvinalvin has joined #bitcoin-core-dev
2462019-07-25T16:37:08  *** rajarshi has joined #bitcoin-core-dev
2472019-07-25T16:47:30  *** ezegom has joined #bitcoin-core-dev
2482019-07-25T16:53:23  *** queip has quit IRC
2492019-07-25T16:53:35  *** d_t has joined #bitcoin-core-dev
2502019-07-25T16:54:51  *** hebasto has quit IRC
2512019-07-25T16:55:26  *** bitcoin-git has joined #bitcoin-core-dev
2522019-07-25T16:55:26  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fe001925f803...fcc4025c1255
2532019-07-25T16:55:27  <bitcoin-git> bitcoin/master d9ab0ff Suhas Daftuar: [qa] Fix race condition in example_test.py
2542019-07-25T16:55:27  <bitcoin-git> bitcoin/master fcc4025 MarcoFalke: Merge #16459: [qa] Fix race condition in example_test.py
2552019-07-25T16:55:29  *** bitcoin-git has left #bitcoin-core-dev
2562019-07-25T16:56:36  *** bitcoin-git has joined #bitcoin-core-dev
2572019-07-25T16:56:36  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #16459: [qa] Fix race condition in example_test.py (master...2019-07-fix-example-test) https://github.com/bitcoin/bitcoin/pull/16459
2582019-07-25T16:56:37  *** bitcoin-git has left #bitcoin-core-dev
2592019-07-25T16:57:01  *** rajarshi has quit IRC
2602019-07-25T16:57:16  *** emilengler has quit IRC
2612019-07-25T16:57:29  *** emilengler has joined #bitcoin-core-dev
2622019-07-25T17:00:33  *** EagleTM has joined #bitcoin-core-dev
2632019-07-25T17:01:34  *** queip has joined #bitcoin-core-dev
2642019-07-25T17:02:59  *** Eagle[TM] has joined #bitcoin-core-dev
2652019-07-25T17:03:50  *** kcalvinalvin has quit IRC
2662019-07-25T17:05:16  *** EagleTM has quit IRC
2672019-07-25T17:05:48  *** emilengler has quit IRC
2682019-07-25T17:06:01  *** emilengler has joined #bitcoin-core-dev
2692019-07-25T17:06:04  <moneyball> emilengler: there is a weekly PR review club on wednesdays. IRC channel and other info found here https://bitcoin-core-review-club.github.io/
2702019-07-25T17:06:27  <emilengler> moneyball, Thank you
2712019-07-25T17:11:30  *** Eagle[TM] has quit IRC
2722019-07-25T17:17:29  *** timothy has quit IRC
2732019-07-25T17:45:56  *** bitcoin-git has joined #bitcoin-core-dev
2742019-07-25T17:45:56  <bitcoin-git> [bitcoin] achow101 opened pull request #16463: [BIP 174] Implement serialization support for GLOBAL_XPUB field. (master...bip174-xpub) https://github.com/bitcoin/bitcoin/pull/16463
2752019-07-25T17:46:00  *** bitcoin-git has left #bitcoin-core-dev
2762019-07-25T18:00:01  *** NikolaiToryzin has quit IRC
2772019-07-25T18:01:01  <jnewbery_> Does anyone know the probabilities of 70 or 69 byte signatures? Is it always 1/2n of the number of bytes under 73?
2782019-07-25T18:04:30  *** fredcooke1 has joined #bitcoin-core-dev
2792019-07-25T18:04:32  *** DeanGuss has joined #bitcoin-core-dev
2802019-07-25T18:08:52  *** instagibbs has quit IRC
2812019-07-25T18:10:23  <harding> jnewbery_: I think 73 -> 72 is a special case (because an extra byte is added if the value is over 0x80).  For anything below 72, there would have to be a 0x00 byte in order for it to be implicit, so the odds are 1/256 per each byte fewer.  So 70 bytes or fewer would be (1/2 * 1/256 * 1/256).  I'm not confident about this, though.
2822019-07-25T18:11:49  *** Raystonn_ has joined #bitcoin-core-dev
2832019-07-25T18:12:04  *** instagibbs has joined #bitcoin-core-dev
2842019-07-25T18:14:56  *** Raystonn has quit IRC
2852019-07-25T18:15:07  *** Raystonn_ is now known as Raystonn
2862019-07-25T18:15:19  *** EagleTM has joined #bitcoin-core-dev
2872019-07-25T18:17:10  <jonasschnelli> sdaftuar_: re block test: looks like. It's happening sometimes...
2882019-07-25T18:17:15  *** reallll has joined #bitcoin-core-dev
2892019-07-25T18:17:33  <sipa> jnewbery_: with low-r grinding?
2902019-07-25T18:17:42  *** d_t has quit IRC
2912019-07-25T18:17:49  <sdaftuar_> jonasschnelli: i think i found the problem
2922019-07-25T18:18:00  <jonasschnelli> sdaftuar_: nice! What is it?
2932019-07-25T18:18:37  <sdaftuar_> there's non-determinism in the length of the signature in the first transaction of the block (b39) used in the first p2sh sigops test
2942019-07-25T18:18:56  <sdaftuar_> combined with a bug in the way the block size is measured in the loop, we can accidentally make too big a block if the first transaction has a too-small signature
2952019-07-25T18:19:16  <sdaftuar_> i've got a simple fix, i think, which i'm verifying
2962019-07-25T18:19:29  <jonasschnelli> Cool! Thanks for fixing it sdaftuar_.
2972019-07-25T18:19:37  <jonasschnelli> So it should have also happend in travis
2982019-07-25T18:19:49  <jonasschnelli> (it probably did)
2992019-07-25T18:19:55  *** EagleTM has quit IRC
3002019-07-25T18:20:07  <sdaftuar_> yeah that's what motivated john's question, we were trying to figure out what the likelihood of this happening is
3012019-07-25T18:20:31  <jonasschnelli> i see
3022019-07-25T18:20:33  <sdaftuar_> i suspect the likelihood went up after we switched to using a new secp256k1 implementation for our python test suite?
3032019-07-25T18:20:39  <sdaftuar_> sipa: ^^ does that make sense to you?
3042019-07-25T18:21:16  *** belcher has quit IRC
3052019-07-25T18:23:27  <sipa> sdaftuar_: the python EC code doesn't do low-r grinding, so it'd be around a 50% chance for 71 byte sigs and 50% for 72 byte sigs (including the sighash byte)
3062019-07-25T18:23:35  <sipa> and a tiny probability for 70 bytes and below
3072019-07-25T18:33:51  <emilengler> In which file/function the inital blockchain download is being started?
3082019-07-25T18:35:05  <sipa> emilengler: PeerValidationLogic::SendMessages(CNode* pto) in src/net_processing.cpp
3092019-07-25T18:35:22  <sipa> specifically under the comment "// Start block sync"
3102019-07-25T18:38:38  <sipa> it's a function that gets called periodically for each peer
3112019-07-25T18:39:00  *** davterra has quit IRC
3122019-07-25T18:39:08  <sipa> that piece of code specifically starts the fetching of headers
3132019-07-25T18:39:35  <sipa> once we have enough headers, and know of peers who have blocks corresponding to those headers, we'll automatically start requesting blocks from them
3142019-07-25T18:40:09  *** davterra has joined #bitcoin-core-dev
3152019-07-25T18:40:19  *** rex4539 has joined #bitcoin-core-dev
3162019-07-25T18:41:08  *** reallll is now known as belcher
3172019-07-25T18:43:14  *** owowo has quit IRC
3182019-07-25T18:44:38  <emilengler> sipa, Thank you
3192019-07-25T18:45:15  *** emilengler has quit IRC
3202019-07-25T18:45:58  *** bitcoin-git has joined #bitcoin-core-dev
3212019-07-25T18:45:58  <bitcoin-git> [bitcoin] sdaftuar opened pull request #16464: [qa] Ensure we don't generate a too-big block in p2sh sigops test (master...2019-07-fix-feature-block) https://github.com/bitcoin/bitcoin/pull/16464
3222019-07-25T18:45:59  *** bitcoin-git has left #bitcoin-core-dev
3232019-07-25T18:46:39  *** emilengler has joined #bitcoin-core-dev
3242019-07-25T18:47:30  *** emilengler has quit IRC
3252019-07-25T18:47:44  *** emilengler has joined #bitcoin-core-dev
3262019-07-25T18:48:39  *** owowo has joined #bitcoin-core-dev
3272019-07-25T18:50:42  *** ryufghj has joined #bitcoin-core-dev
3282019-07-25T18:59:35  *** jonatack has quit IRC
3292019-07-25T18:59:52  *** jonatack has joined #bitcoin-core-dev
3302019-07-25T19:00:14  <jnewbery_> meeting time?
3312019-07-25T19:00:20  <wumpus> #startmeeting
3322019-07-25T19:00:20  <lightningbot> Meeting started Thu Jul 25 19:00:20 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3332019-07-25T19:00:20  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3342019-07-25T19:00:24  <sipa> ohai
3352019-07-25T19:00:26  <jonasschnelli> hi
3362019-07-25T19:00:26  <kanzure> hi
3372019-07-25T19:00:27  <jnewbery_> hi!
3382019-07-25T19:00:33  <achow101> hi
3392019-07-25T19:00:34  <amiti> hi
3402019-07-25T19:00:41  <andytoshi> hi
3412019-07-25T19:00:44  <meshcollider> hi
3422019-07-25T19:00:45  <BlueMatt> a wild jnewbery_ imposter apears
3432019-07-25T19:00:53  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
3442019-07-25T19:01:10  *** sdaftuar_ is now known as sdaftuar
3452019-07-25T19:01:18  <moneyball> Hi
3462019-07-25T19:01:18  <ariard> hi
3472019-07-25T19:01:19  <wumpus> one proposed topic today: Transaction Rebroadcasting https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba
3482019-07-25T19:01:26  <jonasschnelli> I have just a little topic/announcement suggestion: bitcoinbuilds.org (can be done at the end when time)
3492019-07-25T19:01:27  <promag> hi
3502019-07-25T19:01:51  <jamesob> hi
3512019-07-25T19:02:01  <jonatack> hi
3522019-07-25T19:02:16  <wumpus> hi everyone!
3532019-07-25T19:02:23  <wumpus> #topic High priority for review
3542019-07-25T19:02:43  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  6 blockers, 6 things waiting for concept ACK
3552019-07-25T19:02:46  <BlueMatt> #16421
3562019-07-25T19:02:48  <gribble> https://github.com/bitcoin/bitcoin/issues/16421 | Conservatively accept RBF bumps bumping one tx at the package limits by TheBlueMatt · Pull Request #16421 · bitcoin/bitcoin · GitHub
3572019-07-25T19:03:03  <sdaftuar> i'd like to review beg #15759, which is already a high priority for review item
3582019-07-25T19:03:07  <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | [p2p] Add 2 outbound blocks-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
3592019-07-25T19:03:21  <wumpus> BlueMatt: that's one you want to add I suppose?
3602019-07-25T19:03:44  <BlueMatt> yesplz
3612019-07-25T19:03:54  <wumpus> ok added
3622019-07-25T19:03:55  <jamesob> 15759 is a good PR, A+++++ 10/10 would review again
3632019-07-25T19:04:45  <sipa> do two jamesob ACKs count as two? i see a win-win situation here
3642019-07-25T19:06:01  <MarcoFalke> Can I add #16363
3652019-07-25T19:06:02  <jamesob> I'll read it in decreasing line number order this time
3662019-07-25T19:06:03  <wumpus> he did ack it twice so...
3672019-07-25T19:06:03  <gribble> https://github.com/bitcoin/bitcoin/issues/16363 | test: Add test for BIP30 duplicate tx by MarcoFalke · Pull Request #16363 · bitcoin/bitcoin · GitHub
3682019-07-25T19:06:38  <wumpus> MarcoFalke:sure, added
3692019-07-25T19:07:32  <wumpus> anything to add/remove from chasing concept ack?
3702019-07-25T19:08:38  <ariard> still need reviews for #15713, which is current step to go forward on removing cs_main locks in wallet
3712019-07-25T19:08:41  <gribble> https://github.com/bitcoin/bitcoin/issues/15713 | refactor: Replace chain relayTransactions/submitMemoryPool by higher method by ariard · Pull Request #15713 · bitcoin/bitcoin · GitHub
3722019-07-25T19:09:09  <ariard> (current tip ACKed by jnewbery and jonatack)
3732019-07-25T19:09:16  <MarcoFalke> ariard: Looks like you pushed a new commit today
3742019-07-25T19:09:26  <achow101> #16341 for Chasing Concept ACK?
3752019-07-25T19:09:28  <gribble> https://github.com/bitcoin/bitcoin/issues/16341 | WIP: Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
3762019-07-25T19:09:30  <wumpus> good to know, I see it's already on there
3772019-07-25T19:09:40  <MarcoFalke> Oh, I see they re-ACKed
3782019-07-25T19:09:51  <ariard> I took jnewbery cleanup commit for BroadcastTransaction
3792019-07-25T19:10:30  <MarcoFalke> ariard: It conflicts with #16452. So which one should go in first?
3802019-07-25T19:10:33  <gribble> https://github.com/bitcoin/bitcoin/issues/16452 | refactor: use RelayTransaction in BroadcastTransaction utility by ariard · Pull Request #16452 · bitcoin/bitcoin · GitHub
3812019-07-25T19:10:49  <jnewbery_> I think 15713 goes first
3822019-07-25T19:11:02  *** rh0nj has quit IRC
3832019-07-25T19:11:06  <jnewbery_> 16452 is a nice clean-up, but doesn't hold up the series of PRs
3842019-07-25T19:11:12  <wumpus> achow101:added
3852019-07-25T19:11:12  <ariard> #15713, so that's way I would be able to addreess nits in 16452
3862019-07-25T19:11:14  <gribble> https://github.com/bitcoin/bitcoin/issues/15713 | refactor: Replace chain relayTransactions/submitMemoryPool by higher method by ariard · Pull Request #15713 · bitcoin/bitcoin · GitHub
3872019-07-25T19:11:43  <MarcoFalke> Good, I'll take a look at 15713 :eyes:
3882019-07-25T19:11:55  <ariard> thanks!
3892019-07-25T19:12:28  <wumpus> #topic Transaction broadcasting (amiti)
3902019-07-25T19:12:28  *** gribble has quit IRC
3912019-07-25T19:12:33  <promag> +1 on 15713
3922019-07-25T19:12:47  <amiti> write up here: https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba
3932019-07-25T19:13:06  <amiti> tldr; want to improve privacy with updates to rebroadcast logic
3942019-07-25T19:13:37  <amiti> instead of nodes rebroadcasting only wallet txns, rebroadcast all txns it believes should have been in the last block
3952019-07-25T19:14:04  <amiti> looking for critical feedback, concept acks, any high level implementation thoughts
3962019-07-25T19:14:08  *** rh0nj has joined #bitcoin-core-dev
3972019-07-25T19:14:23  <wumpus> how much is this expected to increase bandwidth usage?
3982019-07-25T19:14:51  <amiti> choosing the parameters carefully will be important - dramatically impacts the worst case bandwidth usage
3992019-07-25T19:15:15  <wumpus> and does this help with privacy? the first node broadcasting something will still be the same one
4002019-07-25T19:15:24  <wumpus> as I see it, at least
4012019-07-25T19:16:14  <amiti> not necessarily. if a node has a txn in its mempool that should have been picked up in a block already (high fee rate and is old), it will rebroadcast. independent of originating wallet.
4022019-07-25T19:16:32  <MarcoFalke> wumpus: Yes, the first node (i.e. the wallet) will be the same one
4032019-07-25T19:16:40  <MarcoFalke> But hopefully not for rebroadcasts
4042019-07-25T19:16:42  <jnewbery_> wumpus: I think it does. Currently, if you see a peer brodcast a tx more than once, you can be almost certain that it originated the tx, and we rebroadcast our txs that are unconfirmed for more than half an hour
4052019-07-25T19:17:06  <sipa> i think it primarily addresses how currently we gratuitously rebroadcast, making it obvious continuously to every peer what our own transactions are
4062019-07-25T19:17:15  <sipa> it certainly doesn't address all forms of leaking that information
4072019-07-25T19:17:28  <MarcoFalke> small steps :)
4082019-07-25T19:17:44  <wumpus> so either every node does this, or it reveals which nodes have a hot wallet
4092019-07-25T19:18:13  <sipa> wumpus: the rebroadcast logic will be in the mempool, so even without wallet enabled, it will work
4102019-07-25T19:18:17  *** gribble has joined #bitcoin-core-dev
4112019-07-25T19:18:41  <wumpus> and if all nodes do it, that sounds very bad for bandwidth usage
4122019-07-25T19:19:02  <achow101> at first glance, this sounds like it will cause bandwidth usage greatly increase
4132019-07-25T19:19:09  <sdaftuar> wumpus: i think if we constrain it to old transactions at the top of themempool, it should be a small bandwidth effect?
4142019-07-25T19:19:28  <sipa> i suspect it's also filted by the knowninvs logic, so we wouldn't rebroadcast to the same peer twice
4152019-07-25T19:19:36  <wumpus> so basically all nodes would create noise for the nodes with a wallet to hide in, hmm
4162019-07-25T19:19:56  <MarcoFalke> sipa: The knowninvs will reset every couple of blocks, no?
4172019-07-25T19:19:59  <sdaftuar> wumpus: i think it's more than that, it's way to ensure that things that should be mined get relayed, eg to nodes with small mempools or recently started up
4182019-07-25T19:20:06  *** owowo has quit IRC
4192019-07-25T19:20:06  <sdaftuar> sort of like a mempool-sync might do
4202019-07-25T19:20:13  <achow101> would it be picking the oldest high fee rate transactions to rebroadcast, up to some n? Or would it pick some n transactions and choose the oldest and highest fee rate of them?
4212019-07-25T19:20:18  <wumpus> sdaftuar: oh good point
4222019-07-25T19:20:22  <sipa> right, full nodes have an incentives themselves to see their mempools match what it actually mined
4232019-07-25T19:20:29  <sipa> even without wallets
4242019-07-25T19:20:40  <amiti> achow: traverse top of mempool by ancestor fee rate, filter out recent transactions, rebroadcast remaining
4252019-07-25T19:20:58  <jnewbery_> if we consider the top of the mempool to be "transactions we expect to get mined soon" and they're not getting mined, rebroadcasting them to make sure miners are aware seems like sensible mempool logic
4262019-07-25T19:21:21  <jnewbery_> if not, then the mempool might as well expire them - they're doing our node no good
4272019-07-25T19:21:24  <sipa> i guess there could be some sort of exponential backoff, that after a tx has been rebroadcast multiple times, it becomes rarer (this may be especially relevant when peers may have other consensus/policy rules)
4282019-07-25T19:21:49  <achow101> amiti: so every rebroadcast would have the same number of transactions?
4292019-07-25T19:21:55  <sipa> though i guess that's done automatically by our own expiration logic
4302019-07-25T19:21:59  <achow101> or rather same amount of data being broadcast
4312019-07-25T19:22:17  <wumpus> so if every node broadcasts the transactions at the top of the mempool, this will be more or less the same transactions for every node
4322019-07-25T19:22:20  <MarcoFalke> achow101: No. Txs that were added to the mempool or to blocks are excluded
4332019-07-25T19:22:23  <sipa> achow101: i guess that depends on how well the mempool matches what is being mined
4342019-07-25T19:22:34  <MarcoFalke> wumpus: Yes, mostly
4352019-07-25T19:22:38  <wumpus> if someone broadcasts a *different* transaction, or one that would rank lower according to policy, this is suspect
4362019-07-25T19:22:41  <sdaftuar> sipa: i think a rebroadcast cap makes sense, also a cap on the number of things rebroadcast in one go (to prevent any kind of edge-case behavior)
4372019-07-25T19:22:51  <sipa> gleb: here?
4382019-07-25T19:22:59  <sdaftuar> he's away
4392019-07-25T19:23:02  <sipa> i'm wondering how to integrate this with erlay
4402019-07-25T19:23:20  <sipa> (which shouldn't be a blocker for this discussion of course, but it's nice to have things thought out)
4412019-07-25T19:23:33  <wumpus> I'm not entirely sure that this generates noise with enough variance to contribute to privacy
4422019-07-25T19:23:58  <sipa> wumpus: hmm?
4432019-07-25T19:24:12  <wumpus> it'd just change the logic to 'anyone that broadcasts a transaction that is not on the top of the mempool is broadcasting their own transaction'
4442019-07-25T19:24:15  <sipa> is your concern "this isn't enough" or "this doesn't contribute anything" (possible)
4452019-07-25T19:24:19  <provoostenator> In particular, this wouldn't benefit lowball fee transactions I assume?
4462019-07-25T19:24:32  <MarcoFalke> wumpus: The wallet rebroacast would be removed of course
4472019-07-25T19:24:34  <jnewbery_> wumpus: nodes would still relay new transactions they saw
4482019-07-25T19:24:41  <wumpus> MarcoFalke: ohhh!
4492019-07-25T19:24:45  <MarcoFalke> heh
4502019-07-25T19:24:47  <wumpus> MarcoFalke: okay then it makes a lot more sense
4512019-07-25T19:25:21  <MarcoFalke> Maybe we should introduce each topic with a three line summary
4522019-07-25T19:25:37  <provoostenator> (I mean: I would not add more privacy to wallet transactions with a low fee, but also doesn't make it worse)
4532019-07-25T19:25:41  * MarcoFalke meta
4542019-07-25T19:25:48  <provoostenator> *it
4552019-07-25T19:26:21  <achow101> how would this interact with prioritizetransaction? I assume it would be a privacy leak that you prioritize some particular transaction if that transaction was part of the rebroadcast but not the top for other nodes
4562019-07-25T19:26:24  <MarcoFalke> provoostenator: The fee rate should have no effect on privacy after the proposal is merged, no?
4572019-07-25T19:26:40  <amiti> provoostenator: my proposed changes would not rebroadcast wallet txns with a low fee until that txn makes it to the top of the mempool
4582019-07-25T19:26:43  *** owowo has joined #bitcoin-core-dev
4592019-07-25T19:26:44  *** owowo has joined #bitcoin-core-dev
4602019-07-25T19:26:45  <sipa> hmm, so how will low-feerate transactions get broadcast at all?
4612019-07-25T19:26:47  <sdaftuar> achow101: i think we'd have to use a sort on actual feerate, and not modified feerate
4622019-07-25T19:26:56  <MarcoFalke> sipa: When they are created
4632019-07-25T19:26:57  <sdaftuar> sipa: pacakge relay, or wait til they get to the top of the mempool, i think?
4642019-07-25T19:26:59  <MarcoFalke> (once)
4652019-07-25T19:27:08  <sipa> oh, nvm; the normal "just entered the mempool" relay will do that, not rebroadcast logic
4662019-07-25T19:27:13  <amiti> sdaftuar: correct
4672019-07-25T19:27:34  *** gribble has quit IRC
4682019-07-25T19:28:17  <provoostenator> So IIUC (I should read the whole thing): we still broadcast the first time as per usual, but we only *rebroadcast* top of mempool?
4692019-07-25T19:28:27  <harding> So if I create a low fee transaction that doesn't get relayed initially for some reason, my wallet would never broadcast it unless I just happened to have my node open at the point where fees have dropped?
4702019-07-25T19:28:39  <amiti> provoostenator: correct
4712019-07-25T19:28:56  <wumpus> harding: it would broadcast it the first time
4722019-07-25T19:29:08  <harding> wumpus: right, but what if it wasn't relayed the first time?
4732019-07-25T19:29:25  <achow101> harding: I think it's the same situation now. you'd still have to wait for the fees to drop and have your wallet be open so that other nodes will accept it
4742019-07-25T19:29:40  <MarcoFalke> harding: Right, but we can improve inital relay as well
4752019-07-25T19:29:49  <MarcoFalke> (workin on it)TM
4762019-07-25T19:31:11  <wumpus> concept ACK on the idea from me
4772019-07-25T19:31:12  <harding> achow101: to overcome the dynamic minimum relay fee, that's true.  I'm thinking of the case where I generate a transaction with a (say) 288-block estimatesmartfee target.  That's only rarely going to be near the top of the mempool.  Right now, my wallet will rebroadcast that every hour or so (random delay); with this change, it'd only rebroadcast it if my wallet was open at the right time.
4782019-07-25T19:31:36  <sipa> harding: but on the other hand, your peers will do the rebroadcast for you
4792019-07-25T19:31:50  <sipa> those who heard the initial broadcast at least
4802019-07-25T19:32:39  <sipa> you can argue that that's relying on their altruistic behaviour, but right now we're already kinda doing that hoping for them to relay it at all
4812019-07-25T19:32:42  <sdaftuar> it seems reasonable for the wallet to try to ensure that the transaction was relayed to at least one peer, perhaps
4822019-07-25T19:32:43  <harding> An actual usecase of my is that I sendrawtransaction spends from my cold wallet with my network disabled so that I can do a final inspection of the transaction in my local mempool (mainly to check that I didn't forget an output and spend all to fees).  That means I always use wallet rebroadcasting in those cases.
4832019-07-25T19:32:43  <jnewbery_> harding: s/it'd only rebroadcast it if my wallet was open at the right time/it'd only rebroadcast if your node was online at the right time
4842019-07-25T19:32:49  <jnewbery_> but I think your point stil lstands
4852019-07-25T19:33:45  <achow101> harding: use testmempoolaccept instead?
4862019-07-25T19:33:49  <sipa> harding: that seems like a reasonable use case (though personally i'm using analyzepsbt for that now, before even broadcasting it)
4872019-07-25T19:34:06  <amiti> harding: you are right. in the circumstance where a low fee rate txn was not relayed the first time and none of your peers have it, these changes would make it take longer until your txn got rebroadcast, and potentially your node has to be online the right time.
4882019-07-25T19:34:14  <sipa> i do think we need a way for this to work when a tx is submitted to your mempool while you're offline
4892019-07-25T19:34:39  <provoostenator> One consideration I've seen discussed in a PR recently is that the node doesn't tell the wallet what happened.
4902019-07-25T19:34:43  <harding> sipa: I also do that now too.  When dealing with thousands of my money, it's belts, suspenders, extra belts, and extra suspenders.  :-)
4912019-07-25T19:34:44  <provoostenator> And one thing to also consider is that with dynamic loading, a user might unload their wallet after initial broadcast.
4922019-07-25T19:34:57  <sipa> wow thousands of moneys
4932019-07-25T19:35:08  <sdaftuar> a lot of ico's these days
4942019-07-25T19:35:24  <sipa> the mempool could have a per-tx flag "ever broadcast"
4952019-07-25T19:35:27  <MarcoFalke> Could the mempool keep track if the txs was pushed to at least one peer?
4962019-07-25T19:35:32  <sipa> jinx
4972019-07-25T19:35:55  <wumpus> IIRC the wallet used to keep track of number of broadcasts of a transaction, this was removed at some point
4982019-07-25T19:35:56  <sipa> in that case, even the initial broadcast of a tx could become pure mempool responsibility
4992019-07-25T19:36:02  <sipa> wumpus: correct
5002019-07-25T19:36:12  <achow101> sipa: isn't it already?
5012019-07-25T19:36:14  <sipa> though it was just used for showing in the UI whether a tx had propagated
5022019-07-25T19:36:19  <MarcoFalke> wumpus: That wouldn't work if the wallet is on a different node than the mempool
5032019-07-25T19:36:26  <sdaftuar> sipa: if you're the last of your peers to learn of a transaction, was it "ever broadcast"?
5042019-07-25T19:36:29  <wumpus> which wasa arguably somewhat useful :) but yes
5052019-07-25T19:36:31  <sipa> achow101: well i mean *the mempool* rather than ATMP
5062019-07-25T19:37:06  <sipa> sdaftuar: anything you've learned from the network would never get that flag, only rpc/wallet submissions
5072019-07-25T19:37:07  *** ajonas has joined #bitcoin-core-dev
5082019-07-25T19:37:19  <MarcoFalke> sdaftuar: If you get the tx from the network it was broadcast
5092019-07-25T19:37:20  <wumpus> MarcoFalke: is that even possible?
5102019-07-25T19:37:39  *** gribble has joined #bitcoin-core-dev
5112019-07-25T19:37:39  <wumpus> the wallet will always submit the transaction to the local mempool first right?
5122019-07-25T19:37:46  <sipa> right
5132019-07-25T19:37:49  <MarcoFalke> Sure. Use signrawtransaction on the one with the wallet and sendrawtransaction on the one with the mempool
5142019-07-25T19:38:14  <wumpus> oh sure, but in that case you're handling everything manually anyway
5152019-07-25T19:38:29  <provoostenator> Well, that makes the sendrawtransaction node's mempool is responsible?
5162019-07-25T19:38:35  <wumpus> yes
5172019-07-25T19:38:49  <MarcoFalke> You'd still want your node to broadcast at least once (even if at the time of ATMP you were offline)
5182019-07-25T19:39:09  <sipa> right now if you use sendrawtransaction, it gets submitted to the mempool/network directly, from which your own wallet may learn it, who will then take over rebroadcasting
5192019-07-25T19:39:21  <sipa> because sendrawtransaction is a node RPC not a wallet RPC afaik
5202019-07-25T19:39:28  <wumpus> correct
5212019-07-25T19:39:44  <wumpus> there's no addrawwallettransaction or something like that
5222019-07-25T19:40:11  <wumpus> sendrawtransaction will unconditionally broadcast the transaction as well, so it's sometimes used for manual rebroadcast
5232019-07-25T19:40:56  <MarcoFalke> sendrawtransaction should mention that this is privacy leaking, maybe?
5242019-07-25T19:41:44  <wumpus> yes, the help could mention that
5252019-07-25T19:42:25  <sipa> amiti: what do you think about the "ever broadcast" flag idea?
5262019-07-25T19:42:29  <provoostenator> From the gist: "The wallet will attempt to resubmit unconfirmed transactions to the node on a scheduled timer" - does the node remember previously dropped txs?
5272019-07-25T19:42:44  <sipa> provoostenator: the wallet always remembers all its own transactions
5282019-07-25T19:42:49  <amiti> sipa: sounds great! noted.
5292019-07-25T19:42:59  <sipa> the mempool is completely neutral and doesn't treat our own txn different from anyone else's
5302019-07-25T19:43:09  <provoostenator> sipa: yes, but wouldn't this behavior just cause the node to do a fresh broadcast of all wallet transactions?
5312019-07-25T19:43:12  <amiti> well. if we add the flag, it wont be completely neutral anymore
5322019-07-25T19:43:16  <MarcoFalke> sipa: I like it. It sounds even orthogonal to amiti's proposed change
5332019-07-25T19:43:22  <sipa> MarcoFalke: indeed
5342019-07-25T19:43:32  <sipa> amiti: good point
5352019-07-25T19:43:48  <sipa> but at some point we have to treat our own txn different our they wouldn't be broadcast at all :)
5362019-07-25T19:43:51  <jnewbery_> sipa: we're wondering if the wallet rebroadcasting txs that it learns from the mempool is also true for txs received over p2p
5372019-07-25T19:44:07  <amiti> but, given the circumstances harding pointed out, it seems worth it
5382019-07-25T19:44:09  <jnewbery_> ie that your wallet can be dust-attacked and it'll start rebroadcasting the dust txs
5392019-07-25T19:44:12  *** EagleTM has joined #bitcoin-core-dev
5402019-07-25T19:44:20  <MarcoFalke> jnewbery_: It should
5412019-07-25T19:44:34  <MarcoFalke> s/should/probably does/
5422019-07-25T19:44:43  <sipa> jnewbery_: i think a tx learned through the network (wallet or not) should not be treated differently
5432019-07-25T19:44:57  <sipa> only things learned from the wallet or rpc, and never broadcast before
5442019-07-25T19:45:12  <MarcoFalke> jnewbery_:  I think this has been done in the past
5452019-07-25T19:45:13  <amiti> provoostenator: if I understand your question correctly, the node will not remember the txns it previously dropped. it would rely on the wallet to resubmit if needed
5462019-07-25T19:45:38  <MarcoFalke> Oh, no. It has been done to get the coinselection include the dust
5472019-07-25T19:45:58  <jnewbery_> I guess we want this flag to be saved to mempool.dat so we don't rebroadcast our own txs every time we restart
5482019-07-25T19:46:03  <sipa> jnewbery_: yeah
5492019-07-25T19:46:26  <sipa> that's scary because mempool saving is only done periodically (or even only at shutdown)
5502019-07-25T19:46:43  <sipa> so an unclean shutdown could result in unnecessary rebroadcast
5512019-07-25T19:46:47  <MarcoFalke> -nopersistmempool :eyses:
5522019-07-25T19:47:06  <provoostenator> Unnecessary rebroadcast as a result of a crash doesn't seem like a huge issue.
5532019-07-25T19:47:40  <MarcoFalke> rebroadcast on every start because you don't persist the mempool does sound like an issue
5542019-07-25T19:47:50  <harding> You could put the flag on the transaction in the wallet instead?  was_relayed_to_at_least_one_peer
5552019-07-25T19:48:08  <sipa> harding: a bit of a layer violation but yeah
5562019-07-25T19:48:23  <MarcoFalke> harding: That wouldn't work where the wallet is separate from the mempool (two nodes)
5572019-07-25T19:48:25  <sipa> it means that the "submit to mempool" function needs to return a bool broadcast or not
5582019-07-25T19:48:33  <sipa> oh right, it doesn't work for RPC
5592019-07-25T19:48:34  <provoostenator> Maybe the wallet could ask the node "Do you have this in your mempool?"
5602019-07-25T19:49:16  <provoostenator> And maybe also "Put in your mempool, but skip initial broadcast"
5612019-07-25T19:49:37  <sipa> right but it needs to work even when there is no wallet involved at all
5622019-07-25T19:49:42  <provoostenator> That moves responsibility to the wallet, which maybe makes sense because it cares about its own privacy.
5632019-07-25T19:50:03  <provoostenator> sipa: true, that's the downside
5642019-07-25T19:50:44  <MarcoFalke> We should remove broadcast logic from the wallet and the rpc and tell users to copy-paste the tx into a block explorer over tor
5652019-07-25T19:51:16  <wumpus> at least if their node is not connected to tor already
5662019-07-25T19:51:17  <sipa> ha
5672019-07-25T19:51:18  <provoostenator> Node->WalletTransactionBroadcastDelegate
5682019-07-25T19:51:39  <wumpus> but yes, this was kind of my point with -walletbroadcast=0
5692019-07-25T19:51:55  <sipa> do we have other topics? :p
5702019-07-25T19:52:40  <wumpus> #topic bitcoinbuilds.org (jonasschnelli)
5712019-07-25T19:52:45  <hugohn> question: if there are empty blocks (could be consecutive), will every node rebroadcast top of the mempool?
5722019-07-25T19:52:52  <jonasschnelli> It's a custom built open source CI that is/can-be-further tailored to our needs. Super slim.
5732019-07-25T19:52:55  <MarcoFalke> hugohn: I think so
5742019-07-25T19:52:58  <jonasschnelli> bitcoinbuilds.org
5752019-07-25T19:53:02  <jonasschnelli> Feature wise its on the same level then travis. Builds fast or even faster then travis on a 50EUR/month machine.
5762019-07-25T19:53:07  <jonasschnelli> Additionally, one can download the build results and it logs times per task (install/compile-depends/configure/compile/run-tests/etc.)
5772019-07-25T19:53:10  <wumpus> jonasschnelli: nice !
5782019-07-25T19:53:13  <jonasschnelli> Sources are here: https://github.com/jonasschnelli/bitcoin-core-ci
5792019-07-25T19:53:17  <jonasschnelli> Intention is not to replace travis. Just to have a backup option for times when we need it.
5802019-07-25T19:53:17  <wumpus> so we can trash travis now? :)
5812019-07-25T19:53:23  <wumpus> oh
5822019-07-25T19:53:38  <jonasschnelli> Maybe at some point.. but not now
5832019-07-25T19:53:44  <jonasschnelli> I added a github hook.
5842019-07-25T19:53:48  <wumpus> github integration is probably the most difficult part
5852019-07-25T19:53:54  <jonasschnelli> So it builds are PRs (master after merges soon)
5862019-07-25T19:54:01  <jonasschnelli> Integration with github is easy
5872019-07-25T19:54:03  <wumpus> (e.g. reporting the status on github)
5882019-07-25T19:54:23  <wumpus> oh! it used to be pretty much impossible for custom tools
5892019-07-25T19:54:24  <jonasschnelli> In general... I was surprised how easy it is to "clone travis"
5902019-07-25T19:54:48  <MarcoFalke> reply from travis: "Thank you for getting in touch and for raising this issue as well. I apologise for the frustration caused over the last month regarding the problems, and I can assure you we are committed to improving your overall experience while using the platform."
5912019-07-25T19:54:49  <jonasschnelli> (though tailored)
5922019-07-25T19:55:20  <jonasschnelli> However,.. feel free to check your PR build on bitcoinbuilds.org and contribute to futher extend it to our needs.
5932019-07-25T19:55:43  <meshcollider> Currently it just compiles I guess, are you planning on adding test execution?
5942019-07-25T19:55:44  <jonasschnelli> cfields more detailed dependency cache would certainly be a build-performance booster (for some types of builds)
5952019-07-25T19:55:50  <wumpus> MarcoFalke: hopefully that means anything
5962019-07-25T19:55:56  <jonasschnelli> meshcollider; it runs the test on linux64/32
5972019-07-25T19:56:07  <MarcoFalke> wumpus: I'd guess its a template response
5982019-07-25T19:56:16  <meshcollider> Oh nice :)
5992019-07-25T19:56:17  <jonasschnelli> I have also plans to allow running tests on other machines over the internet (like run the ARM tests on a odroid or so)
6002019-07-25T19:56:42  <MarcoFalke> Nice
6012019-07-25T19:56:49  <jonasschnelli> Contributions welcome...
6022019-07-25T19:57:04  <jnewbery_> jonasschnelli: does it use the same travis.yaml format for configuration?
6032019-07-25T19:57:12  <jonasschnelli> almost...
6042019-07-25T19:57:24  <jonasschnelli> https://github.com/jonasschnelli/bitcoin-core-ci/blob/master/default.yml
6052019-07-25T19:57:32  <jonasschnelli> It's static for now to not pollute our git
6062019-07-25T19:58:08  <wumpus> oh that's neat!
6072019-07-25T19:58:21  <sipa> ideally our travis.yml doesn't really contain any logic apart from "invoke CI step 1", "invoke CI step 2.a", and caching ... which are implemented as a shell script
6082019-07-25T19:58:50  <jonasschnelli> yes
6092019-07-25T19:58:53  <jnewbery_> sipa: for logic yes, but there's various config in there too
6102019-07-25T19:58:55  <MarcoFalke> Some of the variables in the script are travis specific, but it shouldn't be too hard to replace them
6112019-07-25T19:59:05  <sipa> right
6122019-07-25T19:59:18  <MarcoFalke> Happy to review a pull if someone wants to pull them out
6132019-07-25T19:59:42  <jonasschnelli> We could use the .travis folder in the custom CI,.. sure.
6142019-07-25T19:59:56  <jnewbery_> jonasschnelli: do you plan to update https://github.com/jonasschnelli/bitcoin-core-ci/blob/master/default.yml if the travis.yml file changes
6152019-07-25T20:00:01  * sipa -> lunch
6162019-07-25T20:00:11  <jonasschnelli> jnewbery_: I could..
6172019-07-25T20:00:16  * MarcoFalke -> tea
6182019-07-25T20:00:17  <jonasschnelli> or we add one in our github
6192019-07-25T20:00:23  <jonasschnelli> or we load .travis
6202019-07-25T20:00:29  <jonasschnelli> *dong*
6212019-07-25T20:00:40  <wumpus> #endmeeting
6222019-07-25T20:00:40  <lightningbot> Meeting ended Thu Jul 25 20:00:40 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6232019-07-25T20:00:40  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-07-25-19.00.html
6242019-07-25T20:00:40  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-07-25-19.00.txt
6252019-07-25T20:00:40  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-07-25-19.00.log.html
6262019-07-25T20:00:48  <jnewbery_> jonasschnelli: thanks for doing this! Definitely useful to have an alternative
6272019-07-25T20:01:01  <instagibbs> oh whoops, meeting, I thought you guys were really just havin a productive normal discussion
6282019-07-25T20:01:09  <jonasschnelli> heh
6292019-07-25T20:01:14  <amiti> thank you everyone for all the feedback :)
6302019-07-25T20:02:05  <jonasschnelli> jnewbery_: also, eventually travis builds other stuff then bitcoinbuilds.org does (if both are running fine)...
6312019-07-25T20:02:16  <jonasschnelli> so the .travis file doesn't need to be directly synced
6322019-07-25T20:03:42  <hugohn> amiti: should there be a check for minimum of empty blocks seen before triggering rebroadcast ? seems bad to have every node rebroadcast top of the mempool as soon as there's one empty block. (Granted, empty blocks would not be a problem post-subsidy, but might still be a problem now.)
6332019-07-25T20:06:16  <instagibbs> single empty blocks are still quite common, not due to lack of mempool contents
6342019-07-25T20:06:23  <instagibbs> (I haven't read the latest proposal, sorry)
6352019-07-25T20:06:34  <sipa> if there is per-tx mempool tracking anyway, there could be a "point sysyem" where every time a tx was expected to have been in a block but wasn't, it gets a point; if the number of points exceeds some threshold, rebroadcast and increment a counter that next time more points are needed
6362019-07-25T20:15:15  <lightlike> is it also common that non-empty blocks are mined that include many low-fee txes even if higher ones are available? or is it mostly either empty or fee-efficient?
6372019-07-25T20:17:06  *** bitcoin-git has joined #bitcoin-core-dev
6382019-07-25T20:17:06  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fcc4025c1255...a54a12046e98
6392019-07-25T20:17:07  <bitcoin-git> bitcoin/master 248e22b fanquake: depends: disable unused Qt features
6402019-07-25T20:17:07  <bitcoin-git> bitcoin/master a54a120 Wladimir J. van der Laan: Merge #16386: depends: disable unused Qt features
6412019-07-25T20:17:09  *** bitcoin-git has left #bitcoin-core-dev
6422019-07-25T20:22:47  *** ezegom has quit IRC
6432019-07-25T20:27:08  <amiti> hugohn: the current thinking is not to trigger rebroadcast based on block timing, but rather an independent timer. the idea is if we choose the param of "is txn recent" to be long enough, we should be able to avoid excessive broadcast of txns even in edge cases.
6442019-07-25T20:27:08  <amiti> sipa: thats an interesting idea. I'll add it to considerations. there are a lot of options for strategies to mitigate excessive rebroadcasting (and bandwidth usage) with the main tradeoffs being memory / code complexity. another way of storing per-tx mempool data would be a stamp of the `last_rebroadcast_at` and enforce a minimum there.
6452019-07-25T20:27:20  <hugohn> lightlike: high-fee txns could get skipped simply due to timing/relaying issues, so I can see that happening. In fact, it sounds like amiti's proposal is geared towards solving that kind of scenario. Normally you would not expect miners to skip high-fee txns as it does not make economic sense to do so.
6462019-07-25T20:29:57  <wumpus> MarcoFalke: looks like it's not picking up the "needs gitian build" on #16441
6472019-07-25T20:29:58  <gribble> https://github.com/bitcoin/bitcoin/issues/16441 | build: remove qt libjpeg check from bitcoin_qt.m4 by fanquake · Pull Request #16441 · bitcoin/bitcoin · GitHub
6482019-07-25T20:34:48  <MarcoFalke> wumpus: Thx. Looking
6492019-07-25T20:35:14  *** emilengler has quit IRC
6502019-07-25T20:35:29  <MarcoFalke> FileNotFoundError: [Errno 2] No such file or directory: 'make': 'make'
6512019-07-25T20:36:26  <MarcoFalke> I transferred to a new vm. I guess the host needs make to make the depends
6522019-07-25T20:36:39  <jonasschnelli> lol
6532019-07-25T20:37:06  <wumpus> hehe
6542019-07-25T20:38:15  <MarcoFalke> Fixed. Let's check back in two days. (it is half a cpu)
6552019-07-25T20:39:08  <hugohn> > not to trigger rebroadcast based on block timing, but rather an independent timer
6562019-07-25T20:39:09  <hugohn> amiti: I see, looks like rebroadcast is triggered once / hour based on the current proposal. Would there be an issue though if there is a sudden drop in hash rate? I suppose an hour should give plenty of room to account for hash rate drop.
6572019-07-25T20:40:11  *** vincenzopalazzo has joined #bitcoin-core-dev
6582019-07-25T20:42:28  *** ajonas has quit IRC
6592019-07-25T20:42:39  <wumpus> MarcoFalke: thanks!
6602019-07-25T20:48:45  *** vincenzopalazzo has quit IRC
6612019-07-25T20:55:51  <elichai2> jonasschnelli: btw, this might interest you: https://github.com/drone/drone it's also open source and it's dockerized, I used it in the past when I wanted to host my own CI, so you don't have to pay anything except your server(then you can take a powerful one for fast compilation time)
6622019-07-25T20:56:37  <amiti> hugohn: I think more relevant than the frequency of the rebroadcast job is the definition of "recent" transaction. the current proposal has that defined as 30 minutes, which may be too low.
6632019-07-25T20:56:37  <amiti> right now with the params chosen (enforce max rebroadcast of 1000 txns/hour) my back-of-the-envelope math has the worst case as 36 kb max of inv message / hour.
6642019-07-25T20:56:37  <amiti> I'd be curious to hear evaluations of how impactful that seems.
6652019-07-25T20:56:37  <amiti> The worst case bandwidth usage would be very tune-able by choosing conservative params.
6662019-07-25T21:00:02  *** fredcooke1 has quit IRC
6672019-07-25T21:05:45  *** bitcoin-git has joined #bitcoin-core-dev
6682019-07-25T21:05:46  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #16465: test: Test p2sh-witness and bech32 in wallet_import_rescan (master...1907-testAllAddressTypesImport) https://github.com/bitcoin/bitcoin/pull/16465
6692019-07-25T21:05:58  *** bitcoin-git has left #bitcoin-core-dev
6702019-07-25T21:09:59  *** jonatack has quit IRC
6712019-07-25T21:19:17  *** liberiga has joined #bitcoin-core-dev
6722019-07-25T21:20:06  *** phyll1s_work has joined #bitcoin-core-dev
6732019-07-25T21:29:56  *** michaelsdunn1 has quit IRC
6742019-07-25T21:42:31  *** captjakk has joined #bitcoin-core-dev
6752019-07-25T21:47:47  *** goatpig has quit IRC
6762019-07-25T22:30:10  *** EagleTM has quit IRC
6772019-07-25T22:36:44  *** ptiyoyip has joined #bitcoin-core-dev
6782019-07-25T22:39:12  *** Zenton has quit IRC
6792019-07-25T22:40:28  *** ryufghj has quit IRC
6802019-07-25T23:01:00  *** liberiga has quit IRC
6812019-07-25T23:01:55  *** itsiku has quit IRC
6822019-07-25T23:06:19  *** DeanGuss has quit IRC
6832019-07-25T23:07:44  *** DeanGuss has joined #bitcoin-core-dev
6842019-07-25T23:10:52  *** vincenzopalazzo has joined #bitcoin-core-dev
6852019-07-25T23:15:08  *** AaronvanW has quit IRC
6862019-07-25T23:20:50  *** davterra has quit IRC
6872019-07-25T23:21:10  *** liberiga has joined #bitcoin-core-dev
6882019-07-25T23:22:42  *** ryufghj has joined #bitcoin-core-dev
6892019-07-25T23:25:34  *** ptiyoyip has quit IRC
6902019-07-25T23:37:44  *** d_t has joined #bitcoin-core-dev
6912019-07-25T23:37:49  *** vincenzopalazzo has quit IRC
6922019-07-25T23:38:28  *** vincenzopalzzo has joined #bitcoin-core-dev
6932019-07-25T23:40:03  *** vincenzopalazzo has joined #bitcoin-core-dev
6942019-07-25T23:53:46  *** vincenzopalazzo has quit IRC