12019-03-07T00:22:13  *** fanquake has joined #bitcoin-core-dev
  22019-03-07T00:29:50  *** bitcoin-git has joined #bitcoin-core-dev
  32019-03-07T00:29:50  <bitcoin-git> [bitcoin] fanquake closed pull request #15544: Comment typo "iff" (master...master) https://github.com/bitcoin/bitcoin/pull/15544
  42019-03-07T00:29:51  *** bitcoin-git has left #bitcoin-core-dev
  52019-03-07T00:53:13  <wumpus> cfields_: thanks!
  62019-03-07T00:55:33  <gwillen> does anybody with QT magic want to talk to me about the label used for alerts in overviewpage.ui
  72019-03-07T00:55:53  <gwillen> I want something similar (a label that appears when I want to put text in it, and disappears otherwise)
  82019-03-07T00:56:10  <gwillen> and I can't really figure out how you did it, and also when I try to edit the label in QT creator it gets ... glitchy, so I wonder if you edited the XML.
  92019-03-07T00:57:22  *** captjakk has quit IRC
 102019-03-07T00:57:57  *** captjakk has joined #bitcoin-core-dev
 112019-03-07T01:02:07  *** captjakk has quit IRC
 122019-03-07T01:06:11  *** AaronvanW has quit IRC
 132019-03-07T01:10:14  *** zhangzf has joined #bitcoin-core-dev
 142019-03-07T01:18:22  *** dgenr8 has joined #bitcoin-core-dev
 152019-03-07T01:25:59  *** makey40 has quit IRC
 162019-03-07T01:26:15  <promag_> gwillen: what's the purpose?
 172019-03-07T01:26:24  *** makey40 has joined #bitcoin-core-dev
 182019-03-07T01:28:30  <gwillen> hmm, maybe I should just use a modal instead
 192019-03-07T01:28:58  <gwillen> I think I am being too web-influenced
 202019-03-07T01:29:16  <gwillen> (this is for messages like "successfully signed" and "successfully broadcast"
 212019-03-07T01:30:51  <achow101> gwillen: wouldn't a dialog box work better for that?
 222019-03-07T01:34:58  <gwillen> like I said, perhaps I am being too web-influenced
 232019-03-07T01:40:39  <promag_> agree :)
 242019-03-07T01:41:58  <gwillen> I think the web-influenced version is _nicer_
 252019-03-07T01:42:06  <gwillen> but it's not really in keeping with the bitcoin-qt aesthetic
 262019-03-07T01:44:44  *** echeveria has quit IRC
 272019-03-07T01:48:02  *** echeveria has joined #bitcoin-core-dev
 282019-03-07T01:49:37  *** promag has quit IRC
 292019-03-07T01:50:51  *** promag_ has quit IRC
 302019-03-07T01:51:06  *** alexalex has joined #bitcoin-core-dev
 312019-03-07T01:52:32  *** EagleTM has quit IRC
 322019-03-07T02:01:39  *** alexalex has quit IRC
 332019-03-07T02:03:39  *** pinheadmz has quit IRC
 342019-03-07T02:19:32  *** millerti has quit IRC
 352019-03-07T02:21:34  *** promag has joined #bitcoin-core-dev
 362019-03-07T02:26:07  *** promag has quit IRC
 372019-03-07T02:28:27  *** justanotheruser has quit IRC
 382019-03-07T02:44:00  *** justanotheruser has joined #bitcoin-core-dev
 392019-03-07T02:59:33  *** pinheadmz has joined #bitcoin-core-dev
 402019-03-07T03:10:32  *** fcc977 has joined #bitcoin-core-dev
 412019-03-07T03:13:49  *** fcc977 has quit IRC
 422019-03-07T03:14:35  *** pinheadmz has quit IRC
 432019-03-07T03:21:09  *** pinheadmz has joined #bitcoin-core-dev
 442019-03-07T03:24:00  *** mn9495881 has joined #bitcoin-core-dev
 452019-03-07T03:24:09  *** rafalcpp has quit IRC
 462019-03-07T03:25:43  *** rafalcpp has joined #bitcoin-core-dev
 472019-03-07T03:39:42  *** pinheadmz has quit IRC
 482019-03-07T03:44:13  *** pinheadmz has joined #bitcoin-core-dev
 492019-03-07T04:00:35  *** pinheadmz has quit IRC
 502019-03-07T04:06:36  *** DeanWeen has quit IRC
 512019-03-07T04:07:06  *** DeanWeen has joined #bitcoin-core-dev
 522019-03-07T04:26:32  *** Sentineo has quit IRC
 532019-03-07T04:26:32  *** cryptapus has quit IRC
 542019-03-07T04:26:32  *** rockhouse has quit IRC
 552019-03-07T04:26:32  *** bashco has quit IRC
 562019-03-07T04:26:32  *** jimpo has quit IRC
 572019-03-07T04:26:32  *** nodweber2 has quit IRC
 582019-03-07T04:26:32  *** BGL has quit IRC
 592019-03-07T04:26:33  *** molz has quit IRC
 602019-03-07T04:26:33  *** gwillen has quit IRC
 612019-03-07T04:26:33  *** eenoch has quit IRC
 622019-03-07T04:26:33  *** sturles has quit IRC
 632019-03-07T04:26:33  *** da2ce7 has quit IRC
 642019-03-07T04:28:32  *** gwillen has joined #bitcoin-core-dev
 652019-03-07T04:29:08  *** BlueMatt has quit IRC
 662019-03-07T04:31:43  *** BlueMatt has joined #bitcoin-core-dev
 672019-03-07T04:32:12  *** hebasto has quit IRC
 682019-03-07T04:36:15  *** irc_viewer_test has joined #bitcoin-core-dev
 692019-03-07T04:41:06  *** pinheadmz has joined #bitcoin-core-dev
 702019-03-07T04:44:03  *** irc_viewer_test has quit IRC
 712019-03-07T04:44:29  *** DeanWeen has quit IRC
 722019-03-07T04:53:15  *** promag has joined #bitcoin-core-dev
 732019-03-07T04:53:37  *** Sentineo has joined #bitcoin-core-dev
 742019-03-07T04:53:37  *** cryptapus has joined #bitcoin-core-dev
 752019-03-07T04:53:37  *** rockhouse has joined #bitcoin-core-dev
 762019-03-07T04:53:37  *** bashco has joined #bitcoin-core-dev
 772019-03-07T04:53:37  *** jimpo has joined #bitcoin-core-dev
 782019-03-07T04:53:37  *** nodweber2 has joined #bitcoin-core-dev
 792019-03-07T04:53:37  *** BGL has joined #bitcoin-core-dev
 802019-03-07T04:53:37  *** molz has joined #bitcoin-core-dev
 812019-03-07T04:53:37  *** eenoch has joined #bitcoin-core-dev
 822019-03-07T04:53:37  *** sturles has joined #bitcoin-core-dev
 832019-03-07T04:53:37  *** da2ce7 has joined #bitcoin-core-dev
 842019-03-07T04:58:00  *** promag has quit IRC
 852019-03-07T05:08:51  *** pinheadmz has quit IRC
 862019-03-07T05:09:57  *** pinheadmz has joined #bitcoin-core-dev
 872019-03-07T05:21:02  *** rh0nj has quit IRC
 882019-03-07T05:22:07  *** rh0nj has joined #bitcoin-core-dev
 892019-03-07T05:30:23  *** cubancorona has quit IRC
 902019-03-07T05:30:42  *** cubancorona has joined #bitcoin-core-dev
 912019-03-07T05:42:29  *** DeanWeen has joined #bitcoin-core-dev
 922019-03-07T05:46:05  *** promag has joined #bitcoin-core-dev
 932019-03-07T06:15:20  *** pinheadmz has quit IRC
 942019-03-07T06:17:57  *** nullptr| has quit IRC
 952019-03-07T06:25:41  *** nullptr| has joined #bitcoin-core-dev
 962019-03-07T06:49:07  *** spinza has quit IRC
 972019-03-07T06:49:13  *** promag has quit IRC
 982019-03-07T07:09:04  <luke-jr>            ├─sshd(941)─┬─sshd(3366)───bash(3459)───apt-get(3464)───dpkg(6288)───linux-firmware.(9226)───update-initramf(9227)───update-initramf(17424)───m+
 992019-03-07T07:09:13  <luke-jr> wumpus: ^ what is slowing the gitian system update for me
1002019-03-07T07:09:18  <gmaxwell>  /join #bitcoin
1012019-03-07T07:23:09  *** d_t has quit IRC
1022019-03-07T07:24:24  *** mildly_risky has joined #bitcoin-core-dev
1032019-03-07T07:25:07  *** spinza has joined #bitcoin-core-dev
1042019-03-07T07:27:19  *** mildly_risky has quit IRC
1052019-03-07T07:27:44  *** mildly_risky has joined #bitcoin-core-dev
1062019-03-07T07:32:01  *** mildly_risky has quit IRC
1072019-03-07T07:44:13  *** fanquake has quit IRC
1082019-03-07T08:02:28  *** bluelee has joined #bitcoin-core-dev
1092019-03-07T08:10:58  *** bluelee has quit IRC
1102019-03-07T08:18:47  *** jungly has joined #bitcoin-core-dev
1112019-03-07T08:35:05  *** fanquake has joined #bitcoin-core-dev
1122019-03-07T09:09:15  *** setpill has joined #bitcoin-core-dev
1132019-03-07T09:17:18  *** timothy has joined #bitcoin-core-dev
1142019-03-07T09:29:53  *** Guest20 has joined #bitcoin-core-dev
1152019-03-07T09:31:21  *** rafalcpp has quit IRC
1162019-03-07T09:31:48  *** rafalcpp has joined #bitcoin-core-dev
1172019-03-07T09:33:59  *** promag has joined #bitcoin-core-dev
1182019-03-07T09:46:21  *** jonatack has quit IRC
1192019-03-07T09:51:33  *** Guest20 has quit IRC
1202019-03-07T09:54:48  *** CoffeeElixir has joined #bitcoin-core-dev
1212019-03-07T10:02:09  *** kexkey has quit IRC
1222019-03-07T10:10:25  <fanquake> Looks like we've got 6 sets of signed sigs for macOS and Windows rc1 builds.
1232019-03-07T10:10:57  <fanquake> No "new" builders yet
1242019-03-07T10:11:26  *** rex4539 has joined #bitcoin-core-dev
1252019-03-07T10:20:25  *** spinza has quit IRC
1262019-03-07T10:27:00  *** EagleTM has joined #bitcoin-core-dev
1272019-03-07T10:30:05  *** bitcoin-git has joined #bitcoin-core-dev
1282019-03-07T10:30:06  <bitcoin-git> [bitcoin] cisba opened pull request #15554: docs: binary tar improvement (master...improve-tar) https://github.com/bitcoin/bitcoin/pull/15554
1292019-03-07T10:30:09  *** bitcoin-git has left #bitcoin-core-dev
1302019-03-07T10:37:32  *** spinza has joined #bitcoin-core-dev
1312019-03-07T10:45:19  *** IGHOR has quit IRC
1322019-03-07T10:46:53  *** IGHOR has joined #bitcoin-core-dev
1332019-03-07T10:50:56  *** setpill has quit IRC
1342019-03-07T10:52:05  *** zhangzf has quit IRC
1352019-03-07T10:52:20  *** zhangzf has joined #bitcoin-core-dev
1362019-03-07T10:52:51  *** setpill has joined #bitcoin-core-dev
1372019-03-07T10:57:35  *** jonatack_ has joined #bitcoin-core-dev
1382019-03-07T10:59:33  *** EagleTM has quit IRC
1392019-03-07T10:59:55  <CoffeeElixir> Hi, where can I find the changelog of 0.18.0?
1402019-03-07T11:01:36  <wumpus> PSA 0.18.0rc1 binaries up https://bitcoincore.org/bin/bitcoin-core-0.18.0/test.rc1/
1412019-03-07T11:02:47  <wumpus> CoffeeElixir: preliminary changelog is at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
1422019-03-07T11:03:46  <CoffeeElixir> wumpus thank you!
1432019-03-07T11:04:30  *** EagleTM has joined #bitcoin-core-dev
1442019-03-07T11:23:04  <wumpus> yw
1452019-03-07T11:25:02  *** DeanWeen has quit IRC
1462019-03-07T11:42:10  *** DeanWeen has joined #bitcoin-core-dev
1472019-03-07T11:50:03  *** AaronvanW has joined #bitcoin-core-dev
1482019-03-07T11:52:09  <wumpus> whoa at least the wumpus-announce list (i mean, bitcoin-core-dev) is still working
1492019-03-07T11:55:19  <luke-jr> wumpus: the main one seems to be as well for the moment
1502019-03-07T11:55:59  <wumpus> oh nice!
1512019-03-07T12:08:58  *** zhangzf has joined #bitcoin-core-dev
1522019-03-07T12:14:08  *** CoffeeElixir has quit IRC
1532019-03-07T12:28:05  *** jonatack_ has quit IRC
1542019-03-07T12:40:53  *** keymone has quit IRC
1552019-03-07T12:45:43  *** keymone has joined #bitcoin-core-dev
1562019-03-07T12:53:23  *** b10c has joined #bitcoin-core-dev
1572019-03-07T13:06:06  *** promag has quit IRC
1582019-03-07T13:09:28  *** zhangzf has quit IRC
1592019-03-07T13:12:10  *** fanquake has quit IRC
1602019-03-07T13:34:12  *** CoffeeElixir has joined #bitcoin-core-dev
1612019-03-07T13:44:30  *** CoffeeElixir has quit IRC
1622019-03-07T13:50:17  *** zhangzf has joined #bitcoin-core-dev
1632019-03-07T14:03:51  *** mmgen has joined #bitcoin-core-dev
1642019-03-07T14:05:49  *** promag has joined #bitcoin-core-dev
1652019-03-07T14:10:11  *** CoffeeElixir has joined #bitcoin-core-dev
1662019-03-07T14:10:26  *** promag has quit IRC
1672019-03-07T14:26:33  *** Deinogalerix21 has joined #bitcoin-core-dev
1682019-03-07T14:30:47  *** promag has joined #bitcoin-core-dev
1692019-03-07T14:33:01  *** promag_ has joined #bitcoin-core-dev
1702019-03-07T14:33:45  *** Bullit has quit IRC
1712019-03-07T14:34:17  *** Bullit has joined #bitcoin-core-dev
1722019-03-07T14:35:31  *** arubi has quit IRC
1732019-03-07T14:37:32  *** promag_ has quit IRC
1742019-03-07T14:41:14  *** Deinogalerix21 has quit IRC
1752019-03-07T14:41:17  *** Emcy has quit IRC
1762019-03-07T14:41:47  *** Emcy has joined #bitcoin-core-dev
1772019-03-07T14:42:44  *** arubi has joined #bitcoin-core-dev
1782019-03-07T14:59:00  *** setpill has quit IRC
1792019-03-07T15:08:24  *** wolfspraul has quit IRC
1802019-03-07T15:08:32  *** wolfspraul has joined #bitcoin-core-dev
1812019-03-07T15:11:43  *** hebasto has joined #bitcoin-core-dev
1822019-03-07T15:23:36  *** d_t has joined #bitcoin-core-dev
1832019-03-07T15:27:00  *** zhangzf has quit IRC
1842019-03-07T15:34:10  *** pinheadmz has joined #bitcoin-core-dev
1852019-03-07T15:41:38  *** anome has joined #bitcoin-core-dev
1862019-03-07T15:46:43  <promag> please give your ack/nak in #15493
1872019-03-07T15:46:44  <gribble> https://github.com/bitcoin/bitcoin/issues/15493 | rfc: Add -printconfig arg to bitcoind by promag · Pull Request #15493 · bitcoin/bitcoin · GitHub
1882019-03-07T15:51:47  *** CoffeeElixir has quit IRC
1892019-03-07T15:52:26  <wumpus> heh everyone is retweeting the 0.18.0 rc1 announcement, thought i was sneaky enough to only post it on the ML and mastodon... well hope that people realize it's for testing and not a final release
1902019-03-07T15:53:47  *** b10c has quit IRC
1912019-03-07T15:54:11  *** ap4lmtree has quit IRC
1922019-03-07T15:54:30  *** ap4lmtree has joined #bitcoin-core-dev
1932019-03-07T15:56:42  *** b10c has joined #bitcoin-core-dev
1942019-03-07T15:57:41  *** b10c has quit IRC
1952019-03-07T16:14:44  *** Guyver2 has joined #bitcoin-core-dev
1962019-03-07T16:16:29  *** shesek has joined #bitcoin-core-dev
1972019-03-07T16:16:29  *** shesek has joined #bitcoin-core-dev
1982019-03-07T16:18:20  *** bitcoin-git has joined #bitcoin-core-dev
1992019-03-07T16:18:20  <bitcoin-git> [bitcoin] laanwj closed pull request #15549: gitian: Improve error handling (master...2019_03_gitian_error_handling) https://github.com/bitcoin/bitcoin/pull/15549
2002019-03-07T16:18:31  *** bitcoin-git has left #bitcoin-core-dev
2012019-03-07T16:19:16  *** captjakk has joined #bitcoin-core-dev
2022019-03-07T16:20:55  *** bitcoin-git has joined #bitcoin-core-dev
2032019-03-07T16:20:55  <bitcoin-git> [bitcoin] laanwj reopened pull request #15549: gitian: Improve error handling (master...2019_03_gitian_error_handling) https://github.com/bitcoin/bitcoin/pull/15549
2042019-03-07T16:20:56  *** bitcoin-git has left #bitcoin-core-dev
2052019-03-07T16:27:26  *** spinza has quit IRC
2062019-03-07T16:31:22  *** kexkey has joined #bitcoin-core-dev
2072019-03-07T16:35:08  *** jarthur has joined #bitcoin-core-dev
2082019-03-07T16:35:45  *** bitcoin-git has joined #bitcoin-core-dev
2092019-03-07T16:35:45  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3515612e069e...726d0668ff78
2102019-03-07T16:35:46  <bitcoin-git> bitcoin/master faebd2e MarcoFalke: doc: Move wallet lock annotations to header
2112019-03-07T16:35:46  <bitcoin-git> bitcoin/master 726d066 MarcoFalke: Merge #15530: doc: Move wallet lock annotations to header
2122019-03-07T16:35:50  *** bitcoin-git has left #bitcoin-core-dev
2132019-03-07T16:36:40  *** bitcoin-git has joined #bitcoin-core-dev
2142019-03-07T16:36:40  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15530: doc: Move wallet lock annotations to header (master...Mf1902-walletLocks) https://github.com/bitcoin/bitcoin/pull/15530
2152019-03-07T16:36:41  *** bitcoin-git has left #bitcoin-core-dev
2162019-03-07T16:41:25  *** bitcoin-git has joined #bitcoin-core-dev
2172019-03-07T16:41:26  <bitcoin-git> [bitcoin] laanwj pushed 12 commits to master: https://github.com/bitcoin/bitcoin/compare/726d0668ff78...3db0cc394730
2182019-03-07T16:41:27  <bitcoin-git> bitcoin/master 9d6dcc5 Pieter Wuille: Abstract EraseBlockData out of RewindBlockIndex
2192019-03-07T16:41:28  <bitcoin-git> bitcoin/master 32b2696 Pieter Wuille: Move erasure of non-active blocks to a separate loop in RewindBlockIndex
2202019-03-07T16:41:28  *** EagleTM has quit IRC
2212019-03-07T16:41:29  <bitcoin-git> bitcoin/master 1d34287 Pieter Wuille: Merge the disconnection and erasing loops in RewindBlockIndex
2222019-03-07T16:41:30  *** bitcoin-git has left #bitcoin-core-dev
2232019-03-07T16:42:07  *** bitcoin-git has joined #bitcoin-core-dev
2242019-03-07T16:42:08  <bitcoin-git> [bitcoin] laanwj merged pull request #15402: Granular invalidateblock and RewindBlockIndex (master...201902_limitrewindinvalidate) https://github.com/bitcoin/bitcoin/pull/15402
2252019-03-07T16:42:10  *** bitcoin-git has left #bitcoin-core-dev
2262019-03-07T16:42:27  *** bitcoin-git has joined #bitcoin-core-dev
2272019-03-07T16:42:28  <bitcoin-git> [bitcoin] laanwj pushed 12 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/71ac4ebe4893...0fd3632868e2
2282019-03-07T16:42:29  <bitcoin-git> bitcoin/0.18 9d6dcc5 Pieter Wuille: Abstract EraseBlockData out of RewindBlockIndex
2292019-03-07T16:42:30  <bitcoin-git> bitcoin/0.18 32b2696 Pieter Wuille: Move erasure of non-active blocks to a separate loop in RewindBlockIndex
2302019-03-07T16:42:31  <bitcoin-git> bitcoin/0.18 1d34287 Pieter Wuille: Merge the disconnection and erasing loops in RewindBlockIndex
2312019-03-07T16:42:35  *** bitcoin-git has left #bitcoin-core-dev
2322019-03-07T16:42:52  *** bitcoin-git has joined #bitcoin-core-dev
2332019-03-07T16:42:53  <bitcoin-git> [bitcoin] laanwj merged pull request #15552: 0.18: Granular invalidateblock and RewindBlockIndex (0.18...201902_limitrewindinvalidate) https://github.com/bitcoin/bitcoin/pull/15552
2342019-03-07T16:42:58  *** bitcoin-git has left #bitcoin-core-dev
2352019-03-07T16:48:23  <michagogo> Quick question: was looking at the release notes and saw this: you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:8332:8332 (this is an extra :8332 over the normal Docker port specification).
2362019-03-07T16:48:37  <michagogo> Isn’t the normal port specification “-p 8332:8332”?
2372019-03-07T16:49:14  <michagogo> If you’re looking to bind to localhost, what you’re adding is the address
2382019-03-07T16:49:53  *** jonatack has joined #bitcoin-core-dev
2392019-03-07T16:52:08  *** spinza has joined #bitcoin-core-dev
2402019-03-07T16:58:48  *** Aaronvan_ has joined #bitcoin-core-dev
2412019-03-07T17:01:14  *** AaronvanW has quit IRC
2422019-03-07T17:02:35  *** anome has quit IRC
2432019-03-07T17:03:23  *** anome has joined #bitcoin-core-dev
2442019-03-07T17:06:14  *** ghost43 has quit IRC
2452019-03-07T17:06:34  *** ghost43 has joined #bitcoin-core-dev
2462019-03-07T17:12:14  *** bitcoin-git has joined #bitcoin-core-dev
2472019-03-07T17:12:15  <bitcoin-git> [bitcoin] Empact opened pull request #15556:  build: Optionally enable -Wthread-safety-attributes (master...wthread-safety-attributes) https://github.com/bitcoin/bitcoin/pull/15556
2482019-03-07T17:12:15  *** bitcoin-git has left #bitcoin-core-dev
2492019-03-07T17:19:06  <DeanWeen> michagogo: where are these release notes?
2502019-03-07T17:19:06  *** hebasto has quit IRC
2512019-03-07T17:28:03  *** hebasto has joined #bitcoin-core-dev
2522019-03-07T17:35:57  *** jungly has quit IRC
2532019-03-07T17:40:06  *** Aaronvan_ is now known as AaronvanW
2542019-03-07T17:40:57  *** dviola has joined #bitcoin-core-dev
2552019-03-07T17:42:31  <instagibbs> can someone remind me the current Core restriction on rbf input sourcing? ie can a transaction rbf another transaction with unconfirmed inputs?
2562019-03-07T17:44:04  <instagibbs> ah, got it I think "replacement-adds-unconfirmed" error
2572019-03-07T17:52:45  *** anome has quit IRC
2582019-03-07T17:59:31  *** anome has joined #bitcoin-core-dev
2592019-03-07T18:07:42  *** jb55 has quit IRC
2602019-03-07T18:08:00  *** Emcy has quit IRC
2612019-03-07T18:12:28  *** bitcoin-git has joined #bitcoin-core-dev
2622019-03-07T18:12:28  <bitcoin-git> [bitcoin] instagibbs opened pull request #15557: Enhance `bumpfee` to include inputs when targeting a feerate (master...bumpall) https://github.com/bitcoin/bitcoin/pull/15557
2632019-03-07T18:12:31  *** bitcoin-git has left #bitcoin-core-dev
2642019-03-07T18:16:19  <michagogo> DeanWeen: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
2652019-03-07T18:18:43  <instagibbs> 15557 should be of interest to some people ^
2662019-03-07T18:19:12  <instagibbs> finally sat down and just did it, very few loc, and I could delete a bunch more if we get rid of totalFee option for bumping :P
2672019-03-07T18:19:36  <promag> what's total fee?
2682019-03-07T18:21:03  <gmaxwell> <3
2692019-03-07T18:23:09  <instagibbs> promag, you say how much more, in satoshis, you want to give the tx
2702019-03-07T18:23:15  <instagibbs> it's... questionable imo
2712019-03-07T18:23:21  <instagibbs> but hey no need to delete :)
2722019-03-07T18:23:44  <promag> what is the reason to create a separate function?
2732019-03-07T18:23:54  <instagibbs> i found the previous one very hard to read tbh
2742019-03-07T18:23:58  <instagibbs> the flow is completely different
2752019-03-07T18:24:19  <instagibbs> it's doing manual surgery based on introspection of the old tx, rather than just trying to make a new tx
2762019-03-07T18:25:35  <instagibbs> *very manual*
2772019-03-07T18:27:59  <promag> maybe you should move the if (totalFee > 0) {} else {} to a function in feebumper.h?
2782019-03-07T18:28:30  <promag> otherwise you have the same check in interfaces/wallet and rpcwallet
2792019-03-07T18:28:39  <gmaxwell> I think the absolute fee bump amount wasn't well considered and could go away...
2802019-03-07T18:29:00  <gmaxwell> esp as part of an improvement that made bump much more useful...
2812019-03-07T18:29:37  <promag> gmaxwell: you suggest removing that in a different pr first?
2822019-03-07T18:30:22  <gmaxwell> no well, I'm suggesting that if someone making bumpfee better wants to remove it, then they should be empowered to make that call.
2832019-03-07T18:31:02  <gmaxwell> I don't think we should feel too obligated by prior decisions there-- as it stands bumpfee's usability is kinda so/so.
2842019-03-07T18:31:09  <dongcarl> cfields_ phantomcircuit: You guys online? Let's talk about libevent for node socket handling
2852019-03-07T18:31:46  <gmaxwell> why?
2862019-03-07T18:31:54  <promag> dongcarl: wanna ditch libevent?
2872019-03-07T18:32:30  <dongcarl> Mostly thinking about picking up #11227 again
2882019-03-07T18:32:32  <gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
2892019-03-07T18:33:11  <dongcarl> promag: It seems that we rely on libevent for torcontrol and httpserver correct?
2902019-03-07T18:33:24  <promag> dongcarl: yes
2912019-03-07T18:35:03  <phantomcircuit> dongcarl, yes
2922019-03-07T18:35:08  <dongcarl> Well I think we should use it for node socket handling as well, and wanted to talk about what people's thoughts are on that
2932019-03-07T18:35:13  <instagibbs> gmaxwell, the type of power-user can can use the totalFee option can already probably do it manually using pythong
2942019-03-07T18:35:21  <instagibbs> python* heh
2952019-03-07T18:36:01  <phantomcircuit> so one thing to consider, we currently do one connection at a time in another thread, there should be an fConnected flag so that doesn't need special handling
2962019-03-07T18:36:57  <dongcarl> phantomcircuit: fConnected flag on CNode?
2972019-03-07T18:37:22  <dongcarl> Could you point me to code?
2982019-03-07T18:40:16  <phantomcircuit> dongcarl, most of the stuff in netbase.{h,cpp}
2992019-03-07T18:40:33  <phantomcircuit> specifically ConnectSocketDirectly
3002019-03-07T18:40:46  <phantomcircuit> the annoying thing is is means building a SOCKS5 state machine
3012019-03-07T18:41:21  *** Aaronvan_ has joined #bitcoin-core-dev
3022019-03-07T18:41:44  <dongcarl> phantomcircuit: oooof that doesn't sound great
3032019-03-07T18:41:49  * dongcarl reading
3042019-03-07T18:42:50  <cfields_> dongcarl: sorry, screwed up time zones
3052019-03-07T18:43:00  <dongcarl> Haha hey no worries
3062019-03-07T18:43:05  <dongcarl> Glad you're here
3072019-03-07T18:43:44  <cfields_> dongcarl: After wrestling with about 20 different rewrites of the net code with libevent, it's hard to recommend...
3082019-03-07T18:43:55  <cfields_> You definitely end up fighting it more than using it.
3092019-03-07T18:44:20  <dongcarl> cfields_: Really? What kind of fights are you talking about?
3102019-03-07T18:44:22  *** AaronvanW has quit IRC
3112019-03-07T18:45:20  <cfields_> contexts, mainly. It expects you to feed a single pointer in for callbacks. C style. But you almost always want a callback into a function instance, meaning that you have to make weird 2xpointer mallocs all over the place
3122019-03-07T18:45:46  <cfields_> The threading model is also non-intuitive and error-prone
3132019-03-07T18:46:04  <cfields_> I'm happy to point you to the rewrites, I have lots of em :)
3142019-03-07T18:46:22  <phantomcircuit> cfields_, function instance?
3152019-03-07T18:46:33  <cfields_> phantomcircuit: sorry, class function
3162019-03-07T18:46:42  *** gkrizek has quit IRC
3172019-03-07T18:46:48  <phantomcircuit> cfields_, iirc all the libevent callbacks have a user data field basically for that purpose
3182019-03-07T18:46:51  <cfields_> All that said, I obviously wouldn't be opposed to someone else giving it a try.
3192019-03-07T18:47:00  <cfields_> phantomcircuit: yes, a single field.
3202019-03-07T18:47:01  <echeveria> dongcarl: #11227
3212019-03-07T18:47:05  <gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
3222019-03-07T18:47:32  * dongcarl taking notes
3232019-03-07T18:47:36  <cfields_> I also wrote an abstraction layer around libevent with the intention of plugging it into bitcoind
3242019-03-07T18:47:38  <cfields_> sec
3252019-03-07T18:47:41  <echeveria> #10285
3262019-03-07T18:47:41  *** DeanWeen has quit IRC
3272019-03-07T18:47:42  <gmaxwell> we've already held back improvmenets of the p2p protocol for years because of vaguely motivated aspirational rewrites.
3282019-03-07T18:47:44  <gribble> https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
3292019-03-07T18:48:25  <cfields_> dongcarl: https://github.com/theuni/libbtcnet
3302019-03-07T18:49:40  <cfields_> yeah, 10285 does a good job of showing how awkward it is imo. I struggled to come up with something reviewable, without too much spaghetti. And since it wasn't merged, apparently I didn't do so great :)
3312019-03-07T18:49:47  <dongcarl> cfields_: I haven't dove fully into it, but I know that libev is a lot simpler than libevent (~1 order of magnitude LOC) and claims to have a good interface
3322019-03-07T18:49:56  <dongcarl> http://software.schmorp.de/pkg/libev.html
3332019-03-07T18:50:53  <cfields_> dongcarl: Last time I looked, IIRC I decided that libev would've been a better choice. But grass is always greener. And it'd be a new dep. So I didn't go down that path.
3342019-03-07T18:51:18  <gmaxwell> What problem is any of this supposted to be solving?
3352019-03-07T18:52:37  <dongcarl> gmaxwell: "These changes remove our old select() loop for socket handling in favor of libevent, which uses epoll/kqueue/etc. as a back-end. In addition to being faster and more efficient, this allows us to drop some annoying restrictions, namely that select can only handle 1024 sockets in practice on most systems."
3362019-03-07T18:52:53  <cfields_> gmaxwell: more async, and more performant due to epoll/kqueue/etc.
3372019-03-07T18:53:34  <gmaxwell> dongcarl: we no longer have the 1024 socket restriction, because we switched to using poll.
3382019-03-07T18:54:05  <gmaxwell> (when finally people were convinced to stop waiting for a rewrite.)
3392019-03-07T18:56:08  <dongcarl> Do non-Linux kernels have the 1024 socket restriction? Or does poll solve it for all the ones we support? (genuinely asking)
3402019-03-07T18:56:32  <gmaxwell> dongcarl: windows select doesn't have a 1024 restriction (at it uses a linked list instead of a bitmap)
3412019-03-07T18:56:32  <cfields_> 1024 is an issue with select()
3422019-03-07T18:56:41  <wumpus> 1024 restriction is specific to UNIX implementations of select()
3432019-03-07T18:56:44  <wumpus> not only Linux
3442019-03-07T18:56:53  <cfields_> and not always 1024 :)
3452019-03-07T18:57:12  <gmaxwell> cfields_: more performant in what measuresable respect?  At most we handle just hundreds of waiting sockets and benchmarks I've seen show essentially equivilent (fast) performance beween all alternatives at this level: https://monkey.org/~provos/libevent/libevent-benchmark2.jpg
3462019-03-07T18:57:16  * rafalcpp screams in Finnish
3472019-03-07T18:57:18  <wumpus> poll() doesn't have any such restriction on any (AFAIK) OS
3482019-03-07T18:57:30  <dongcarl> We enable poll for BSD?
3492019-03-07T18:57:35  <cfields_> gmaxwell: we've had this discussion endless times.
3502019-03-07T18:57:37  <wumpus> yes, only not on windows
3512019-03-07T18:57:55  <gmaxwell> cfields_: yes, and it screwed the protocol development for years.
3522019-03-07T18:58:07  <cfields_> gmaxwell: guess you were right, then.
3532019-03-07T18:59:34  <phantomcircuit> so my interest is in doing very small changes
3542019-03-07T18:59:51  <phantomcircuit> i think the issue we've had in the past was having a grand plan
3552019-03-07T18:59:51  <gmaxwell> The cost right now to going back on this would likely be to delay development of p2p encryption/authentication for another year plus. If thats the case I think it would be an awful tradeoff.
3562019-03-07T18:59:57  <phantomcircuit> instead of doing smaller fixes
3572019-03-07T19:00:13  <sipa> gmaxwell: i think we indeed had an instance a while ago where some
3582019-03-07T19:00:21  <phantomcircuit> i brought up the connect stuff cause that did actually slow me down on changing  poll()
3592019-03-07T19:00:25  <sipa> gmaxwell: i think we indeed had an instance a while ago where some things were delayed because of an upcoming refactor which didn't happen
3602019-03-07T19:00:41  <wumpus> gmaxwell: I tend to agree at this point, years ago it was differnt but makes sense to prioritize BIP150/151 now
3612019-03-07T19:01:09  <wumpus> I doubt the main performance wins at this point are in the polling implementation, but in improving the protocol
3622019-03-07T19:01:14  <gmaxwell> We had many networking refactors which did happen too. And it has also taken a long time to restabalize the networking after changing it.
3632019-03-07T19:01:15  <wumpus> and implementation
3642019-03-07T19:01:25  *** gkrizek has joined #bitcoin-core-dev
3652019-03-07T19:01:46  <instagibbs> meeting time?
3662019-03-07T19:01:52  <dongcarl> meeting time.
3672019-03-07T19:01:54  <wumpus> the network code has to be *super optimized* for the bottleneck to be at the low level event level
3682019-03-07T19:01:56  <wumpus> #startmeeting
3692019-03-07T19:01:56  <lightningbot> Meeting started Thu Mar  7 19:01:56 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3702019-03-07T19:01:56  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3712019-03-07T19:01:59  <provoostenator> hi
3722019-03-07T19:02:00  <jonasschnelli> Hi
3732019-03-07T19:02:00  <gmaxwell> I'd love to be using epoll/kqueue where available, -- but  compared to many other possible improvements, I think these things would just be nice to have changes that make the system prettier and more technically perfect.
3742019-03-07T19:02:13  <achow101> hi
3752019-03-07T19:02:25  <meshcollider> hi
3762019-03-07T19:02:40  <jonasschnelli> topic proposal: txindex and prune
3772019-03-07T19:02:45  <jonasschnelli> (for later)
3782019-03-07T19:02:50  <wumpus> this is true for, say, simple HTTP servers that can handle connections at network-bound speed, we're definitely CPU bound in many cases
3792019-03-07T19:02:52  <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
3802019-03-07T19:02:56  <cfields_> At this point I obviously agree with all of the above.
3812019-03-07T19:02:57  <sipa> gmaxwell: i think people looking into integrating these (through libevent based network code or elsewhere) is useful; we just shouldn't let it stand in the way of protocol improvements
3822019-03-07T19:03:33  <gmaxwell> cfields_: it's not that I was right, hell I didn't know it would go out the way it did. :) I just don't want to repeat what happened before, and I can't see how (right now) that sort of change should be a priority worth delaying anything.
3832019-03-07T19:03:45  <wumpus> #topic P2P networking
3842019-03-07T19:03:59  <gmaxwell> sipa: sure, though I'm sure most people would prefer to work on suff that is going to get integrated soon! :P
3852019-03-07T19:04:07  <sipa> of course
3862019-03-07T19:04:46  <jonasschnelli> In case anyone wants to review the new v2 protocol (BIP151), including the new special ChaCha20Poly1305@bitcoin AEAD,... its here -> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
3872019-03-07T19:04:59  <gmaxwell> oh interesting, cool. Will do.
3882019-03-07T19:05:31  <sipa> jonasschnelli: interesting; this is the born-encrypted design, rather than upgrade-existing-connection one?
3892019-03-07T19:05:51  <jonasschnelli> yes. The born encrypted
3902019-03-07T19:05:59  <phantomcircuit> hi
3912019-03-07T19:06:06  <jonasschnelli> with NODE_ENCRYPTED and the 32byte key exchange before everything else
3922019-03-07T19:06:15  <jonasschnelli> but fallback to a version message
3932019-03-07T19:06:19  <wumpus> #topic BIP151
3942019-03-07T19:06:44  <echeveria> jonasschnelli: (minor, why is the command still possible to be null padded ASCII?)
3952019-03-07T19:06:44  <sipa> at this point it may be worth having it as a separate bip
3962019-03-07T19:06:50  *** promag_ has joined #bitcoin-core-dev
3972019-03-07T19:07:13  <jonasschnelli> echeveria: in v2 its a varstring or a short varint
3982019-03-07T19:07:16  <jonasschnelli> no padding
3992019-03-07T19:07:32  <echeveria> ok, same question.
4002019-03-07T19:07:34  <jonasschnelli> sipa: what as a seperate BIP? the handshake, or the NODE_ENCRYPTED?
4012019-03-07T19:08:11  <sipa> jonasschnelli: it looks like you plan to overwrite BIP151... given that it already has a bip number, and you're substantially changing the design, maybe it should be a separate one
4022019-03-07T19:08:32  <sipa> (and abandon bip151)
4032019-03-07T19:08:34  *** elichai2 has joined #bitcoin-core-dev
4042019-03-07T19:08:35  <jonasschnelli> Yes. I thought the same...
4052019-03-07T19:08:38  <gmaxwell> +1
4062019-03-07T19:08:48  <jonasschnelli> Though we must discourage to use BIP151
4072019-03-07T19:09:03  <gmaxwell> Sure.
4082019-03-07T19:09:05  <phantomcircuit> jonasschnelli, why is the command ascii and not just a integer?
4092019-03-07T19:09:16  <jonasschnelli> Also, there is a BIP150 weakness if used with plain (old) BIP151
4102019-03-07T19:09:21  <jonasschnelli> phantomcircuit: it is
4112019-03-07T19:09:28  <jonasschnelli> read the BIP linked above
4122019-03-07T19:09:48  <echeveria> from the BIP. "1-13 	encrypted command 	variable 	ASCII command (or one byte short command ID)"
4132019-03-07T19:09:50  <wumpus> phantomcircuit: extensibility I guess, names are much easier to work on on parallel instead of having to reserve small integers
4142019-03-07T19:10:12  <jonasschnelli> ASCII commands are still possible
4152019-03-07T19:10:32  <gmaxwell> Basically for extensibility, the existing normal commands get short IDs but then its possible to have longer ones for new/infrequent commands.
4162019-03-07T19:10:33  <wumpus> right
4172019-03-07T19:10:36  <sipa> this is probably not the place to discuss the details of the bip
4182019-03-07T19:10:46  <jonasschnelli> yes. Will move it to the ML
4192019-03-07T19:10:46  <gmaxwell> if you only have a small integer you end up with an allocation problem.
4202019-03-07T19:11:05  <jonasschnelli> I will rebase and overhaul the implementation #14032 asap
4212019-03-07T19:11:08  <gribble> https://github.com/bitcoin/bitcoin/issues/14032 | Add p2p layer encryption with ECDH/ChaCha20Poly1305 by jonasschnelli · Pull Request #14032 · bitcoin/bitcoin · GitHub
4222019-03-07T19:11:35  <jonasschnelli> In the meantime, reviews welcome for the puzzles required for the p2p enc. -> #15512, #15519, #14047, #14049
4232019-03-07T19:11:36  <gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
4242019-03-07T19:11:38  <gribble> https://github.com/bitcoin/bitcoin/issues/15519 | Add Poly1305 implementation by jonasschnelli · Pull Request #15519 · bitcoin/bitcoin · GitHub
4252019-03-07T19:11:40  <gribble> https://github.com/bitcoin/bitcoin/issues/14047 | Add HKDF_HMAC256_L32 and method to negate a private key by jonasschnelli · Pull Request #14047 · bitcoin/bitcoin · GitHub
4262019-03-07T19:11:42  <gribble> https://github.com/bitcoin/bitcoin/issues/14049 | Enable libsecp256k1 ecdh module, add ECDH function to CKey by jonasschnelli · Pull Request #14049 · bitcoin/bitcoin · GitHub
4272019-03-07T19:11:46  <jonasschnelli> (sry for the wall)
4282019-03-07T19:12:24  <gmaxwell> We should talk about a meta issue here. Whats our position on e.g. voskuil opposing any encryption?  My view is that he's free to not implement it, but we shouldn't let generalized opposition stand in the way of doing something like that.
4292019-03-07T19:12:44  <jonasschnelli> voskuil seems to be okay with the new BIP since its now fully backward comp.
4302019-03-07T19:12:52  <instagibbs> Is it authentication or encryption he has issues with?
4312019-03-07T19:13:05  <jonasschnelli> Auth. is BIP150 which is still in discussion
4322019-03-07T19:13:09  <gmaxwell> It was always backwards compatible... but okay...
4332019-03-07T19:13:23  <sipa> instagibbs: his position is that authentication without encryption is pointless (i agree, it mostly is), and that authentication of bitcoin connections is a slippery slope
4342019-03-07T19:13:24  <jonasschnelli> BIP151 (or the new #) is opportunistic encryption
4352019-03-07T19:13:29  <gmaxwell> instagibbs: he argued that encryption was pointless without authentication and authentication was bad.
4362019-03-07T19:13:37  <gmaxwell> what sipa says.
4372019-03-07T19:13:44  <gmaxwell> but if thats changed. fine!
4382019-03-07T19:14:01  <sipa> eh, encryption without authentication
4392019-03-07T19:14:07  <gmaxwell> I'd just ask that if we move discussion to the ML we not let stupid debates mire it down.
4402019-03-07T19:14:09  <instagibbs> sipa, yeah i figured :)
4412019-03-07T19:14:18  <wumpus> I... don't understand why such a high-level discussion of the desirability of those things comes now, while BIP150/151 have existed for ages
4422019-03-07T19:14:19  <jonasschnelli> I think there are basic benefits of encryption without authentication... but of course, with autrhentication there are more possibilities,... but we need to create puzzle piece by puzzle piece
4432019-03-07T19:15:07  <provoostenator> I like being able to detect when my ISP starts messing with my Bitcoin P2P traffic :-)
4442019-03-07T19:15:20  <jonasschnelli> indeed
4452019-03-07T19:15:23  <wumpus> would need to be a really good reason it's bad to stop now
4462019-03-07T19:15:42  <jonasschnelli> I like that my ISP(s) know that I can detect in case they want mess my p2p traffic
4472019-03-07T19:15:48  <sipa> jonasschnelli: fwiw, i do have a writeup on countersign (which allows authentication without a MitM knowing it was even attempted); it turns out to be fairly hard for multiple keys simultaneously, but for one key it's pretty simple; https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
4482019-03-07T19:15:49  <gmaxwell> yes yes, we're all in agreement here.
4492019-03-07T19:16:07  <sipa> jonasschnelli: also, hasn't had thorough review yet
4502019-03-07T19:16:15  <jonasschnelli> sipa: thanks... i'll look at it in a free minute
4512019-03-07T19:16:28  <gmaxwell> I was assumping sipa and I would advance countersign once the oppturnistic encryption was in.
4522019-03-07T19:16:50  <jonasschnelli> Yes. There is the possibility of multiple authentication shemes
4532019-03-07T19:16:53  <jonasschnelli> *schemes
4542019-03-07T19:17:26  <wumpus> I could see how a "connect only to authenticated, known peers" becoming general could be problematic, though, but I don't think it was ever to be the only option?
4552019-03-07T19:17:55  <sipa> jonasschnelli: the idea behind countersign is that you'd always use it; even when no authentication is desired (in which case you'd run it with a random pubkey)
4562019-03-07T19:18:11  <sipa> but a MitM can't tell whether it's for a real key or not
4572019-03-07T19:18:40  <gmaxwell> So that a MitM can't only selectively tamper with unauthenticated links.
4582019-03-07T19:18:45  <jonasschnelli> We currently authenticate peers by ips IPv4/IPv6... so..
4592019-03-07T19:18:52  <sipa> haha yes
4602019-03-07T19:18:53  <jonasschnelli> (addnode / connect)
4612019-03-07T19:19:09  <gmaxwell> So anyone using authentication creates a halo of protection against MitM for everyone.
4622019-03-07T19:19:11  <jonasschnelli> We don't change the uses cases
4632019-03-07T19:19:56  <jonasschnelli> Authentication just makes things more secure and reliable that are already possible
4642019-03-07T19:20:07  <gmaxwell> Indeed, we're clear on this. I only raised the concern in the context of the mailing list because of bad expirences before discussing this.
4652019-03-07T19:20:08  <sipa> preaching to the choir :)
4662019-03-07T19:21:17  <gmaxwell> I think if the industry (or other implementers) opposes the idea in general: we don't care, obviously we'll continue to support the old procol so long as it's needed, and obviously we'd hear out any concerns. But fundimentally P2P is non-consensus, we can implement any additional protocol we want and still interpo wih anyone who doesn't want to implement it.
4672019-03-07T19:21:55  <wumpus> right
4682019-03-07T19:22:01  <gmaxwell> So someone showing up demanding we don't implement crypto at all or use TLS can just be told after we hear their case, sorry, this project isn't interested in that.
4692019-03-07T19:22:56  <gmaxwell> jonasschnelli: the particular thing about countersign is that it makes it less attractive to MitM anyone, even people not actually using it. Though to get that benefit it has to be 'on' all the time, even when not used.
4702019-03-07T19:24:01  *** jonatack has quit IRC
4712019-03-07T19:25:08  <gmaxwell> I think that covers it? jonasschnelli's new writup needs review.
4722019-03-07T19:25:12  <wumpus> next topic I guess
4732019-03-07T19:25:19  <jonasschnelli> yes
4742019-03-07T19:25:21  <wumpus> #topic txindex and prune (jonasschnelli)
4752019-03-07T19:25:37  <gmaxwell> (and people might want to look at sipa's countersign writeup)
4762019-03-07T19:25:54  <jonasschnelli> I think there is demand to rund the txindex on pruned peers....
4772019-03-07T19:26:01  <jonasschnelli> *run
4782019-03-07T19:26:14  <jonasschnelli> I know its for development purposed only..
4792019-03-07T19:26:17  <gmaxwell> I don't understand how that makes logical sense?
4802019-03-07T19:26:42  <gmaxwell> txindex works by accessing the blocks, so what exactly would txindex+prune mean?
4812019-03-07T19:26:53  <jonasschnelli> Users running low cost devices (with pruning) may want to look up txids on their own system rather then use a blockexplorer
4822019-03-07T19:26:53  <gmaxwell> just returning errors on inaccessible blocks?
4832019-03-07T19:27:05  <achow101> jonasschnelli: I feel like people who want to do that have a fundamental misunderstanding of what pruning and txindex do
4842019-03-07T19:27:08  <jonasschnelli> The idea is that the index points to a blockhash, position (in the end)
4852019-03-07T19:27:12  <sipa> in a manual pruning it may make sense; some client applications knows how far it needs blocks, prunes them, but still expects to be able to lookup transactions in the unpruned one
4862019-03-07T19:27:14  <instagibbs> with manual pruning it can make sense
4872019-03-07T19:27:15  <jonasschnelli> So you can fetch it via p2p on pruned peers
4882019-03-07T19:27:18  <instagibbs> jynx sipa
4892019-03-07T19:27:30  <jonasschnelli> Its not efficient, its not fast... but it works for pesonal debug uses cases
4902019-03-07T19:27:44  <gmaxwell> ugh, fetching blocks in response to queries sounds kind of abusive on he network.
4912019-03-07T19:27:57  <gmaxwell> s/he/the/
4922019-03-07T19:27:59  <sipa> jonasschnelli: i don't understand the p2p side of things here
4932019-03-07T19:28:09  <provoostenator> That used to be useful for Lightning, but now there's a proposal to add SPV proofs to gossip, it's probably no longer useful for that.
4942019-03-07T19:28:15  <gmaxwell> sipa: he is suggesting you resolve missing blocks by fetching the block.
4952019-03-07T19:28:29  <sipa> provoostenator: oh that's great to hear
4962019-03-07T19:28:48  *** fabianfabian has joined #bitcoin-core-dev
4972019-03-07T19:28:57  <jonasschnelli> sipa: well,.. if the txindex resolves to blockhash/pos, one may want to fetch the tx, and since blocks are not available, fetch a single block in order to decompose and display the tx
4982019-03-07T19:29:03  <provoostenator> It's mentioned in the Lightning 1.1 meeting docs, not sure if anyone implemented it, but that's really useful for running Lightning on pruned nodes.
4992019-03-07T19:29:09  <gmaxwell> jonasschnelli: I suspect that if people start doing this, it would probably hasten the future where there are few to no non-limited peers on the future.
5002019-03-07T19:29:43  <sipa> jonasschnelli: so you expect the txindex to cover even the pruned blocks?
5012019-03-07T19:29:47  <gmaxwell> provoostenator: if you have a pruned node, why doesn't it just check the channel against the utxo set?
5022019-03-07T19:30:27  <jonasschnelli> sipa: initially, allow to move the index from disk pos to blockhash/pos to allow to resolve to something that is useful if you have the blocks _not_ on disl
5032019-03-07T19:30:40  <gmaxwell> Txindex being able to return txes or a "pruned error" when it hits a pruned block seems like an obvious +1 to me if it would actually be useful to anyone.. (though I do have a little doubt since we didn't really like 'probablistic' RPCs in the past)
5042019-03-07T19:30:40  <sipa> jonasschnelli: meh
5052019-03-07T19:30:59  <sipa> jonasschnelli: i think a txindex that just covers the blocks you have may make sense if there's a use case
5062019-03-07T19:31:05  <instagibbs> gmaxwell, gettxout is a bit weird in some uses.
5072019-03-07T19:31:10  <provoostenator> gmaxwell: I believe Lightning gossip messages don't contain the full transaction id, they use a short notation block height + part of tx id
5082019-03-07T19:31:19  <instagibbs> sipa, liquid could have used it(we rolled our own instead)
5092019-03-07T19:31:21  <gmaxwell> provoostenator: oy
5102019-03-07T19:31:43  <sipa> jonasschnelli: but if the txindex must cover all of history, it breaks the advantage that pruning was supposed to give
5112019-03-07T19:31:47  <jonasschnelli> sipa: I think the diskpos approach is great for non pruned peers,.. I don't propose to change this,.. just allow an alternative index value of hash/pos
5122019-03-07T19:31:56  <provoostenator> gmaxwell: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#requirements
5132019-03-07T19:32:03  <gmaxwell> provoostenator: that sounds like a protocol flaw in lightning. (and an example of the kind of design damage txindex does.. :P )
5142019-03-07T19:32:22  <jonasschnelli> Right now, pruned peers have no possibility to securily fetch a transaction by its ID,... they need to switch to a centralized API
5152019-03-07T19:32:23  <instagibbs> merkle proofs should fix that eh?
5162019-03-07T19:32:29  <jonasschnelli> and they did verify the blocks
5172019-03-07T19:33:02  <jonasschnelli> allowing the alternative blockhash/pos instead of diskpos would give the an opportunity to lookup a txid
5182019-03-07T19:34:33  <jonasschnelli> And its just so that users still want to fetch transactions not indexed by the wallet for semi-experimental purposes like lightning, etc.
5192019-03-07T19:34:54  *** ap4lmtree has quit IRC
5202019-03-07T19:35:07  <gmaxwell> that seems like it would just prolong eventually fatal but avoidable design flaws... like assuming you have a txindex.
5212019-03-07T19:35:30  <jonasschnelli> I agree for productive systems,...
5222019-03-07T19:35:54  <gmaxwell> txindex = eventually rely on a centeralized service, -- we've always known this.  By twiddling this or that you can change when you have to give up on not using a centeralized service...
5232019-03-07T19:36:28  <gmaxwell> Expecting random peers to serve up random blocks to you just to fetch a transaction is a pretty costly way to forestall the inevitable.
5242019-03-07T19:36:44  <jonasschnelli> IMO its already done on the p2p network...
5252019-03-07T19:36:55  <jonasschnelli> Also, compact block filters are pretty much the same
5262019-03-07T19:37:11  <gmaxwell> Yes, they make the data available but if people start using it, it'll eventually have to go away.
5272019-03-07T19:37:35  <gmaxwell> jonasschnelli: yes, which have been problematic, though disuse of them has limited the amount of problems they cause.
5282019-03-07T19:37:58  <provoostenator> (by the way, we skipped high prioirity issues and 0.18 release topics)
5292019-03-07T19:38:41  <wumpus> provoostenator: yea because everyone was already discussing things when the meeting started, if you have anything to discuss re: 0.18 please let us know
5302019-03-07T19:38:47  <jonasschnelli> I see all implications and somehow I think adding the p2p part could be done in a second step. Allowing the txindex to be hash/pos based would give pruned peer alternatives (not only the p2p fetch method). But I agree about the "meh",... but I personally see the usefulness
5312019-03-07T19:38:55  <gmaxwell> jonasschnelli: just your figures the other day were showing that >90% of your bandwidth is already expended serviging historic blocks.
5322019-03-07T19:38:56  <provoostenator> wumpus: I don't have anything
5332019-03-07T19:39:06  <jonasschnelli> gmaxwell: fair point
5342019-03-07T19:39:09  <wumpus> PSA: 0.18.0rc1 binaries were uploaded today and release announcement posted
5352019-03-07T19:39:16  <gmaxwell> jonasschnelli: it doesn't need to be hash based, fwiw, it could just be a reference into the blockindex I think, that would avoid bloating it.
5362019-03-07T19:39:16  <midnightmagic> \o/
5372019-03-07T19:39:49  <jonasschnelli> gmaxwell: yes. I think it has to to keep it compact. Was simplifying it for discussion purposes
5382019-03-07T19:40:23  <jonasschnelli> It would be more or less the same diskspace (for the index),.. also same database structure (reuse of existing fields)
5392019-03-07T19:40:42  <jonasschnelli> but I accept the "meh" but won't stop bother about it. :)
5402019-03-07T19:41:32  <gmaxwell> So there are two possibilties for pruned + txindex = whole tx index but returns "in pruned block X" when pruned, or just a txindex of the unpruned portion.  The former will radically increase disk usage, since it undermines pruning.  The latter seems easily viable, I'm not sure is actually useful to anyone (has anyone asked for something like that?)
5412019-03-07T19:42:01  <wumpus> re: "high priority for review" we haven't discussed that in the meeting for a while because around the 0.18.0 release, the obvious high-priority PRs are the ones tagged with that, but maybe now after the branch-off and rc1 is the time to start again (or next week)
5422019-03-07T19:42:20  <jonasschnelli> The main driver behind this are plug-n-play nodes (CasaHODL like consumer devices)
5432019-03-07T19:42:29  <gmaxwell> Either are better than the current "you just cant' combine these options", but dunno how important the improvement would be.
5442019-03-07T19:42:58  <gmaxwell> jonasschnelli: that _is_ production...
5452019-03-07T19:43:01  <provoostenator> jonasschnelli: I'm not convinced these plug-n-play nodes needs indexes.
5462019-03-07T19:43:10  <jonasschnelli> gmaxwell: its a debug option in a production device
5472019-03-07T19:43:28  <jonasschnelli> gmaxwell: thanks for the "in pruned block X" thought,... let me follow this a bit..
5482019-03-07T19:43:36  <jonasschnelli> I think there are other topics
5492019-03-07T19:43:46  <gmaxwell> (aside, CasaHODL has a 1TB drive.)
5502019-03-07T19:43:54  <gmaxwell> jonasschnelli: k
5512019-03-07T19:44:08  <jonasschnelli> gmaxwell: yes. But its a lame device,... I think we will see a bunch of fast devices with <64GB SSDs
5522019-03-07T19:44:20  <wumpus> are there other topics?
5532019-03-07T19:45:06  <gmaxwell> I would like to leave for lunch. :P
5542019-03-07T19:45:14  <jonasschnelli> ack
5552019-03-07T19:45:23  * sipa is generally in favor of food
5562019-03-07T19:45:25  <wumpus> ok :D
5572019-03-07T19:45:40  <wumpus> #endmeeting
5582019-03-07T19:45:40  <lightningbot> Meeting ended Thu Mar  7 19:45:40 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5592019-03-07T19:45:40  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.html
5602019-03-07T19:45:40  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.txt
5612019-03-07T19:45:40  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.log.html
5622019-03-07T19:45:53  <sipa> also, yay for 0.18.0rc1
5632019-03-07T19:46:04  <gmaxwell> \O/
5642019-03-07T19:46:06  <gwillen> sipa: countersign seems need to me, but the identity protection for the responder seems only good against relatively casual threats, if I'm understanding this right
5652019-03-07T19:46:06  <meshcollider> \o/
5662019-03-07T19:46:11  <wumpus> \o/
5672019-03-07T19:46:13  <gwillen> since a logarithmic number of sessions will break it
5682019-03-07T19:46:28  <jonasschnelli> gmaxwell: I think SSDs are a must for devices with lower end CPUs. And if one shipts a plug-n-play node, 1TB is already small
5692019-03-07T19:46:35  <gwillen> (much in the same way that one can break cloaks on freenode with a ~logarithmic amount of effort)
5702019-03-07T19:46:37  <sipa> gwillen: logarithmic?
5712019-03-07T19:46:40  <jonasschnelli> So pruning on such devices is more or less a must
5722019-03-07T19:46:56  <jonasschnelli> and not supporting txid lookups is not understandable for users
5732019-03-07T19:47:00  <gwillen> sipa: do a session with them where I accept half the identities I suspect they might be
5742019-03-07T19:47:00  <gmaxwell> gwillen: only if you have some database directory of identities.
5752019-03-07T19:47:05  <gwillen> sure, yeah
5762019-03-07T19:47:11  <gwillen> logarithmic in the size of the suspect-set
5772019-03-07T19:47:17  <gmaxwell> gwillen: what you can't do is just track random nodes around when you have no idea about identities.
5782019-03-07T19:47:26  <gwillen> hmmmmmmmmm okay that's a really good point
5792019-03-07T19:47:34  <sipa> jonasschnelli: what do users need txid lookups for?
5802019-03-07T19:47:36  <gwillen> if you've never seen a given pubkey before you can't track that person
5812019-03-07T19:47:52  <gmaxwell> it also protects you against checking against old transcripts even if you later learn some candidate identities.
5822019-03-07T19:47:56  <jonasschnelli> sipa: Various... ask youself the next time when you lookup a txid. :)
5832019-03-07T19:48:04  <gwillen> I am mostly responding to "Responder privacy also implies that C does not learn which of its acceptable public keys R's private key corresponded to. To see why this may be useful, note that the anti-surveillance property from the previous paragraph breaks down whenever C can run many instances of the protocol with separate acceptable keys, for a large set of (e.g. leaked) keys that may include R's public key. In order to combat this, R can
5842019-03-07T19:48:04  <gmaxwell> gwillen: right which is a problem in many protocols.
5852019-03-07T19:48:12  <jonasschnelli> And I bet you do that also often
5862019-03-07T19:48:22  <gwillen> I think it is infeasible for R to limit the number of independent protocol runs to a useful degree
5872019-03-07T19:48:35  <gwillen> but I still agree that there are useful privacy properties we get
5882019-03-07T19:48:38  <sipa> gwillen: the idea of the multiparty version is that you'd also only allow one per connection... though of course you can assume that connecting multiple times to the same IP will give you the same participant
5892019-03-07T19:48:45  <gwillen> right
5902019-03-07T19:49:01  <gmaxwell> Yes, though the responder isn't initiating the connection in that case.
5912019-03-07T19:49:06  <sipa> gwillen: in any case, i agree that it's hard to put guarantees on the non-leaking of identities of some large set of pubkeys to track
5922019-03-07T19:49:09  <gwillen> I need no more than a couple dozen connections to disambuguate you
5932019-03-07T19:49:14  <promag_> jonasschnelli: low hang fruit 15464
5942019-03-07T19:49:18  <gmaxwell> Though for the kind of usage we imagine there is no database.
5952019-03-07T19:49:18  <sipa> gwillen: my favor is just implementing the 1 key version, and running it multiple times
5962019-03-07T19:50:05  <midnightmagic> (gwillen: your IRC client isn't splitting lines properly.. I think?)
5972019-03-07T19:50:14  <jonasschnelli> promag_: thanks... will take a look (merge)
5982019-03-07T19:50:20  <gmaxwell> In the 'wallet server'  'wallet client'  model the multiple way use is essentially just a semi-honest protocol. Doesn't leak the identity of the user, if the server doesn't actively try.
5992019-03-07T19:50:23  <gwillen> midnightmagic: the IRC protocol does not include any provision for splitting lines
6002019-03-07T19:50:29  <gwillen> midnightmagic: I guess my paste was over the maximum length
6012019-03-07T19:50:41  <sipa> gwillen: irssi has a nice plugin to split too long lines :)
6022019-03-07T19:50:43  <gwillen> (there are some clients that will auto-split, mine does not)
6032019-03-07T19:50:48  <gwillen> yeah, I don't have it installed
6042019-03-07T19:51:22  <gmaxwell> Probably we wouldn't propose implementing the multi-key version for bitcoin, but we had to feel out the design to figure out if it would be useful or not.
6052019-03-07T19:51:23  <midnightmagic> (gwillen: older irssi used to do that. if you upgrade, FYI OTR has been implemented directly in mainline.)
6062019-03-07T19:51:25  <sipa> jonasschnelli: sure, but for recent transactions an index into unpruned blocks is sufficient
6072019-03-07T19:51:36  <midnightmagic> (a non-segfaulting one, too)
6082019-03-07T19:51:51  <sipa> jonasschnelli: and a full index of the chain is already 20 GB or so
6092019-03-07T19:52:13  <jonasschnelli> sipa: Yes. Which IMO is acceptable.
6102019-03-07T19:52:21  <sipa> jonasschnelli: it won't be for long
6112019-03-07T19:52:29  <sipa> if you're talking about 64 GB devices
6122019-03-07T19:52:30  *** captjakk has quit IRC
6132019-03-07T19:52:39  <gmaxwell> and in a year or two it will be 40.. and you'll be out of space on your 64gb drive.
6142019-03-07T19:53:06  * gmaxwell lunch &
6152019-03-07T19:53:12  <jonasschnelli> I see...
6162019-03-07T19:53:18  <sipa> fg gmaxwell
6172019-03-07T19:53:19  <instagibbs> pkill lunch
6182019-03-07T19:56:25  <sipa> gwillen: so if you assume you can make unlimited connections to the same node (in a way that gives high assurance it's the same identity you're reaching), then the privacy properties of multiple-singlekey-instances and single-multikey-instance is the same, i think
6192019-03-07T19:56:52  <midnightmagic> pfft. #!/usr/bin/perl, require "sys/ioctl.ph"; open my $tty_fh, '<', '/dev/gmaxtty' or die $!; foreach my $c (split //, "exit\n".'echo No lunch for you, $(whoami)'.$/) { ioctl($tty_fh, &TIOCSTI, $c); }
6202019-03-07T19:57:47  <sipa> that assumption doesn't necessarily hold for unreachable nodes though (when an unreachable client connecting over tor, authenticating itself to a server, and rate-limiting how frequently it reconnects would not, for example)
6212019-03-07T19:58:36  *** Emcy has joined #bitcoin-core-dev
6222019-03-07T19:58:36  <sipa> but the single key version lets you track an identity with O(n) in the set size, while the multikey version needs O(n log n)
6232019-03-07T19:58:42  <gwillen> sipa: well multiple-singlekey-instances require linear work in the size of the set, versus single-multikey-instance requiring logarithmic work, so if the set is ... right
6242019-03-07T19:58:48  <gwillen> er, n log n?
6252019-03-07T19:58:59  <sipa> gwillen: the multikey version has O(n) bandwidth
6262019-03-07T19:59:03  <sipa> and computation
6272019-03-07T19:59:06  <sipa> on both sides
6282019-03-07T19:59:16  <sipa> where n is the number of acceptable public keys
6292019-03-07T19:59:16  <gwillen> hmmm, I see "connections" as the limiting resource rather than bandwidth I guess
6302019-03-07T19:59:49  <sipa> for large sets the CPU usage may be the limiting factor
6312019-03-07T19:59:51  <gwillen> but I don't have a sense for what the constants are which could change my feeling
6322019-03-07T19:59:55  <gwillen> that makes sense
6332019-03-07T20:00:24  <sipa> 64 bytes per acceptable key from challenger to responder, 64 bytes constant from responder to challenger
6342019-03-07T20:00:57  <gwillen> ah, so the responder can see the set size
6352019-03-07T20:01:13  <gwillen> I guess I should have read further and I would have learned that.
6362019-03-07T20:01:49  <sipa> yup; though you can pad with extra randomly-generated pubkeys of course
6372019-03-07T20:01:55  <gwillen> *nod*
6382019-03-07T20:03:04  <sipa> and CPU usage is in the order of 2 signatures per acceptable key for the challenger, and a bit less for the responder (but still mostly proportional to the number of acceptable keys)
6392019-03-07T20:04:55  *** bitcoin-git has joined #bitcoin-core-dev
6402019-03-07T20:04:55  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3db0cc394730...d211edb34982
6412019-03-07T20:04:56  <bitcoin-git> bitcoin/master 28c86de João Barbosa: gui: Drop unused return values in WalletFrame
6422019-03-07T20:04:56  <bitcoin-git> bitcoin/master d211edb Jonas Schnelli: Merge #15464: gui: Drop unused return values in WalletFrame
6432019-03-07T20:05:02  *** bitcoin-git has left #bitcoin-core-dev
6442019-03-07T20:05:40  *** bitcoin-git has joined #bitcoin-core-dev
6452019-03-07T20:05:40  <bitcoin-git> [bitcoin] jonasschnelli merged pull request #15464: gui: Drop unused return values in WalletFrame (master...2019-02-walletframe) https://github.com/bitcoin/bitcoin/pull/15464
6462019-03-07T20:05:42  *** bitcoin-git has left #bitcoin-core-dev
6472019-03-07T20:06:02  *** wolfspraul has quit IRC
6482019-03-07T20:06:11  *** wolfspraul has joined #bitcoin-core-dev
6492019-03-07T20:07:07  *** AaronvanW has joined #bitcoin-core-dev
6502019-03-07T20:09:33  *** Aaronvan_ has quit IRC
6512019-03-07T20:10:26  *** mmgen has quit IRC
6522019-03-07T20:18:44  *** fabianfabian has quit IRC
6532019-03-07T20:22:24  *** DeanGuss has joined #bitcoin-core-dev
6542019-03-07T20:23:26  *** kexkey has quit IRC
6552019-03-07T20:23:56  *** hebasto has quit IRC
6562019-03-07T20:24:04  *** kexkey has joined #bitcoin-core-dev
6572019-03-07T20:24:38  <kanzure> no update about mailing list yet, still working on it
6582019-03-07T20:25:44  *** promag_ has quit IRC
6592019-03-07T20:26:19  <achow101> kanzure: at least it kind of works now
6602019-03-07T20:29:09  *** captjakk has joined #bitcoin-core-dev
6612019-03-07T20:29:49  *** captjakk has joined #bitcoin-core-dev
6622019-03-07T20:42:33  <DeanGuss> I assume you guys know but the SHA256SUMS.asc file for the 0.18.rc1 - gpg: NOTE: signature key 36C2E964 expired Thu 14 Feb 2019 11:24:36 AM UTC
6632019-03-07T20:42:34  <kanzure> it's not meant to last, this is temporary
6642019-03-07T20:42:44  <kanzure> achow101: ^
6652019-03-07T20:43:40  <achow101> DeanGuss: the key expiration was updated, do gpg --refresh-keys
6662019-03-07T20:44:29  <DeanGuss> ah k thanks
6672019-03-07T20:44:35  <DeanGuss> Also on the release notes, I don't see it mentioned but the encryptwallet rpc changed to erasing unencrypted keys from memory without requring bitcoind to shut down (which works awesomely btw)
6682019-03-07T20:47:00  *** anome has quit IRC
6692019-03-07T20:47:10  <shesek> is it likely for bitcoin core to produce transactions matching UIH-2? (https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2796539, basically means that some inputs could've been avoided and the transaction would still have enough funding to cover the larger output)
6702019-03-07T20:47:20  <achow101> DeanGuss: the release notes aren't final yet. they're in the wiki so people can edit them and add things that aren't there yet
6712019-03-07T20:48:31  <shesek> it looks like targeting MIN_CHANGE might be a reason for UIH-2 to be triggered. but I don't fully understand the coin selection algorithm and finding it hard to piece together information about its current state, it looks like it went through some iterations in the last couple years
6722019-03-07T20:49:36  <shesek> I'm asking in the context of a discussion about esplora detecting and notifying about UIH-2, and how useful it is to do so. https://github.com/Blockstream/esplora/issues/51
6732019-03-07T20:50:44  <shesek> oh, sorry, I think #bitcoin-dev would probably be a better place to ask, shall I move it there?
6742019-03-07T20:53:03  *** anome has joined #bitcoin-core-dev
6752019-03-07T20:53:20  <echeveria> uh
6762019-03-07T20:54:03  <echeveria> why is seed.bitcoinstats.com pointed to cloudflare?
6772019-03-07T20:57:17  <echeveria> that seems sort of undesirable honestly.
6782019-03-07T21:01:47  *** PatBoy has quit IRC
6792019-03-07T21:02:41  <sipa> echeveria: in what way?
6802019-03-07T21:06:16  <echeveria> given their proliferation into everything mostly. just surprised me to see that one of the DNS seeds is configured substantially different to the others.
6812019-03-07T21:08:31  <sipa> echeveria: i mean, in what way is seed.bitcoinstats.com pointing to cloudflare?
6822019-03-07T21:08:58  <echeveria> unless I'm mistaken, the nameserver is cloudflare.
6832019-03-07T21:09:21  <echeveria>    Name Server: ISLA.NS.CLOUDFLARE.COM
6842019-03-07T21:09:21  <echeveria>    Name Server: JAY.NS.CLOUDFLARE.COM
6852019-03-07T21:11:45  *** anome has quit IRC
6862019-03-07T21:15:09  *** spaced0ut has quit IRC
6872019-03-07T21:16:05  *** promag_ has joined #bitcoin-core-dev
6882019-03-07T21:17:29  *** promag_ has quit IRC
6892019-03-07T21:22:42  *** gkrizek has quit IRC
6902019-03-07T21:36:35  <gmaxwell> uh, thats a straig up violation of our dnsseeds policy.
6912019-03-07T21:36:53  *** gkrizek has joined #bitcoin-core-dev
6922019-03-07T21:37:12  <gmaxwell> echeveria: Please PR removing that seed.
6932019-03-07T21:38:26  <gmaxwell> I see the same thing, fwiw:
6942019-03-07T21:38:27  <gmaxwell> $ dig +short NS  bitcoinstats.com
6952019-03-07T21:38:27  <gmaxwell> jay.ns.cloudflare.com.
6962019-03-07T21:38:27  <gmaxwell> isla.ns.cloudflare.com.
6972019-03-07T21:38:30  *** morcos has quit IRC
6982019-03-07T21:39:09  <achow101> I don't see this
6992019-03-07T21:39:16  *** morcos has joined #bitcoin-core-dev
7002019-03-07T21:40:41  <achow101> I see cloudflare for bitcoinstats.com, not for seed.bitcoinstats.com
7012019-03-07T21:41:52  *** promag has quit IRC
7022019-03-07T21:41:56  <gmaxwell> achow101: the NS records are one record up, seed.bitcoinstats.com is just giving you the dnsseed results.
7032019-03-07T21:42:16  *** promag has joined #bitcoin-core-dev
7042019-03-07T21:42:52  <gmaxwell> The issue is that the queries are being satisfied by cloudflare, not that cloudflare is an A record resul.
7052019-03-07T21:44:52  <achow101> how is that a violation of the dnsseeds policy?
7062019-03-07T21:45:12  <sipa> gmaxwell: that's the NS for bitcoinstats.com, not seed.bitcoinstats.com, no?
7072019-03-07T21:45:47  <gmaxwell> sipa: seed.bitcoinstats.com is the last level.
7082019-03-07T21:45:48  <gmaxwell> src/chainparams.cpp:        vSeeds.emplace_back("seed.bitcoinstats.com"); // Christian Decker, supports x1 - xf
7092019-03-07T21:46:35  <gmaxwell> so your resolver consults the ns for com, to find the ns for bitcoinstats, which it then asks for seed.bitcoinstats.com and gets back a bunch of a records.
7102019-03-07T21:47:01  <gmaxwell> compare
7112019-03-07T21:47:02  <gmaxwell> src/chainparams.cpp:        vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
7122019-03-07T21:47:19  <sipa> dig -t seed.bitcoin.sipa.be gives me the name of the machine running my dns seed; dig -t NS bitcoin.sipa.be gives me nothing
7132019-03-07T21:47:26  <gmaxwell> [gmaxwell@bean ~]$ dig +short NS sipa.be
7142019-03-07T21:47:26  <gmaxwell> ns.ulyssis.student.kuleuven.be.
7152019-03-07T21:47:26  <gmaxwell> ns2.ulyssis.student.kuleuven.be.
7162019-03-07T21:47:26  <gmaxwell> ns3.ulyssis.student.kuleuven.be.
7172019-03-07T21:47:26  <gmaxwell> [gmaxwell@bean ~]$ dig +short NS bitcoin.sipa.be
7182019-03-07T21:47:26  <sipa> +NS
7192019-03-07T21:47:26  <gmaxwell> xps.sipa.be.
7202019-03-07T21:47:36  <sipa> but my dns seed runs on zps.sipa.be
7212019-03-07T21:47:46  <sipa> (and it is serving queries)
7222019-03-07T21:48:17  <sipa> xps is where the bitcoin.sipa.be site runs
7232019-03-07T21:48:17  <achow101> ping cdecker
7242019-03-07T21:51:14  <gmaxwell> I sure miss nslookup, dig is a lot more of a pain
7252019-03-07T21:53:25  *** ap4lmtree has joined #bitcoin-core-dev
7262019-03-07T21:57:10  <gmaxwell> SOA record clearly returns cloudflare, and if I flush my caches and firewall off cloudflare I am unable to resolve seed.bitcoinstats.com.
7272019-03-07T21:59:32  <sipa> $ dig -t NS seed.bitcoinstats.com @jay.ns.cloudflare.com
7282019-03-07T21:59:36  <sipa> seed.bitcoinstats.com.	300	IN	NS	seedns.bitcoinstats.com.
7292019-03-07T21:59:39  <sipa> seedns.bitcoinstats.com. 300	IN	A	46.101.246.115
7302019-03-07T21:59:47  <sipa> $ dig seed.bitcoinstats.com @46.101.246.115
7312019-03-07T21:59:57  <sipa> -> IN A responses
7322019-03-07T22:00:06  <sipa> so the dns server being queried is 46.101.246.115
7332019-03-07T22:01:11  *** anome has joined #bitcoin-core-dev
7342019-03-07T22:06:45  <echeveria> that's confusing.
7352019-03-07T22:07:44  <gmaxwell> It queries cloudflare and cloudflare redirects you to another nameserver to get the results for seed.bitcoinstats.com.
7362019-03-07T22:08:01  <gmaxwell> It does however mean that cloudflare is seeing the ip address of ~every bitcoin node.
7372019-03-07T22:08:08  <gmaxwell> I'm not really that comfortable with that.
7382019-03-07T22:08:34  <sipa> only the ISP's resolver, no?
7392019-03-07T22:08:46  <gmaxwell> (it's a 300s ttl at that level, but it's not like anyone else but bitcoin nodes are querying seeds.bitcoinstats.com )
7402019-03-07T22:08:55  <achow101> if cloudflare redirects you, then they don't see the results, no?
7412019-03-07T22:09:10  <sipa> achow101: not the result; they do see the query
7422019-03-07T22:09:11  *** Aaronvan_ has joined #bitcoin-core-dev
7432019-03-07T22:09:22  <gmaxwell> achow101: they see the query, the results aren't private whos quertying is.
7442019-03-07T22:09:23  <sipa> (if not cached through something else0
7452019-03-07T22:09:40  <achow101> right, doh!
7462019-03-07T22:09:47  *** Guyver2 has quit IRC
7472019-03-07T22:09:58  <gmaxwell> since it has a 300s ttl they'll avoid seeing some request, if you're behind a recursive resolve with multiple nodes.
7482019-03-07T22:10:29  *** Aaronva__ has joined #bitcoin-core-dev
7492019-03-07T22:11:07  *** arubi has quit IRC
7502019-03-07T22:11:41  <achow101> but don't they only see whoever the dns server is for a paticular node as that's the one that does the recursive resolve?
7512019-03-07T22:11:52  <achow101> so for most people, their ISP, not actually the node
7522019-03-07T22:11:55  *** wolfspraul has quit IRC
7532019-03-07T22:12:03  *** linzhi-sonia has joined #bitcoin-core-dev
7542019-03-07T22:12:14  *** AaronvanW has quit IRC
7552019-03-07T22:12:51  *** linzhi-sonia has quit IRC
7562019-03-07T22:13:27  *** Aaronvan_ has quit IRC
7572019-03-07T22:13:33  <gmaxwell> Indeed, you're right. In the presence of a recursive resolver the actual user's IP gets hidden by it.
7582019-03-07T22:13:59  <gmaxwell> (this was, in fact, why we weren't quite as worried about having dnsseeds in the first place)
7592019-03-07T22:14:22  *** anome has quit IRC
7602019-03-07T22:15:00  *** dviola has quit IRC
7612019-03-07T22:17:25  *** arubi has joined #bitcoin-core-dev
7622019-03-07T22:22:05  <gwillen> this also means cloudflare has full control over the results if they actually choose to exercise it
7632019-03-07T22:22:21  <gwillen> although it would be obvious if they did since they would have to do so by changing the NS records for seed.bitcoinstats.com
7642019-03-07T22:22:24  <gwillen> which is presumably not worth it to them
7652019-03-07T22:22:40  <gwillen> (they could do this selectiely, though.)
7662019-03-07T22:23:57  <phantomcircuit> gmaxwell, it's equivalent to other upstream nameservers except... cloudflare
7672019-03-07T22:34:39  *** spinza has quit IRC
7682019-03-07T22:34:46  <gmaxwell> yes, it's equivilent to other upstream nameservers. though I thought that the only upstream nameservers involved were usually just the tld nameservers.  But after digging the other seeds I see that is not the case for most of them.
7692019-03-07T22:36:39  <gwillen> I feel like people specifically distrust cloudflare more than the average nameserver
7702019-03-07T22:37:30  <gwillen> but for people who are already running their own nameservers for seeds, it seems like it would make sense for them to run their own nameservers priod
7712019-03-07T22:37:33  <gwillen> period*
7722019-03-07T22:38:12  <gmaxwell> cloudflare itself has managed to give a lot of people (myself included) a pretty bad taste. There is a widespread but not proven belief that US intelligence DOS services to get them onto cloudflare in order to intercept them, created by cloudflare sales mysteriously showing up with a very protection racket sounding sales pitch the moment you get DOS attacked, sometimes even before you notice
7732019-03-07T22:38:12  <gmaxwell> the dos attack. (we actually expirenced that ourselves).  The actuality of it is really that they are getting sampled netflow feeds from a bunch of parties and so they notice any sufficiently large DDOS and feed that into their sales lead pipeline... but it still leaves a bad taste.
7742019-03-07T22:38:39  <gmaxwell> (we meaning this channel, as in cloudflare sales showed up in here a couple years ago)
7752019-03-07T22:40:02  *** rockhouse has quit IRC
7762019-03-07T22:40:03  *** victorSN has quit IRC
7772019-03-07T22:40:30  <gmaxwell> gwillen: yeah, I had assumed they were.  matt and luke are (both with he.net providing secondaries) I don't believe any of the other ones are.
7782019-03-07T22:41:53  <gmaxwell> There is probably a little complication with both using the custom dnsseed nameserver software and running a nameserver on the same host...
7792019-03-07T22:44:28  *** spinza has joined #bitcoin-core-dev
7802019-03-07T22:44:36  <gwillen> hm that's true, I hadn't thought about that complication
7812019-03-07T22:44:57  <sipa> indeed
7822019-03-07T22:51:26  * gmaxwell votes to drop dnsseed discovery and just have bitcoin nodes scan the whole internet. :P
7832019-03-07T22:54:37  *** AaronvanW has joined #bitcoin-core-dev
7842019-03-07T22:57:21  <gmaxwell> shesek: thats a silly hurestic. Wallets sweeping up inputs will vioate it. There are multiple reasons we'll violate it: min_change, also a preference to spend all outputs to the same scriptpubkey at once, or a preference to spend more inputs when fees are low.
7852019-03-07T22:57:42  <phantomcircuit> gmaxwell, i was hit by a slow loris attack (when that was still novel) which had cloudflare sales people appear
7862019-03-07T22:57:51  *** Aaronva__ has quit IRC
7872019-03-07T22:57:54  <phantomcircuit> that wouldn't have appeared in netflow samples
7882019-03-07T22:59:42  <gmaxwell> (technically what they get is sampled sflow)
7892019-03-07T23:00:41  <gmaxwell> phantomcircuit: why wouldn't it be?  wouldn't you see e.g. the sequence numbers in a connection incrementing insanely slowly?
7902019-03-07T23:01:56  <phantomcircuit> gmaxwell, slow loris stuff is a tiny amount of traffic
7912019-03-07T23:02:12  <gmaxwell> yes, not very visable in sampled traffic but not invisible either.
7922019-03-07T23:02:53  <gmaxwell> In any case, I've been through this a bunch of times where it looked really suspect but it turns out there was some explination. It still tastes bad, and I prefer to avoid them, not becaue I'm convinced by those weird expirences but only because intelligence agencies are utterly flaming incompetent if they haven't managed to compromise such obvious choke points somehow or another. :)
7932019-03-07T23:03:00  <phantomcircuit> it's like 100 connections sending just enough to keep the connection alive
7942019-03-07T23:03:43  <gmaxwell> right but if you see even two samples that appear to be the same connection minutes apart that aren't advancing it... thats pretty conclusive.
7952019-03-07T23:04:09  <gmaxwell> (or at least conclusive enough to try connecting yourself! :) )
7962019-03-07T23:05:10  <gmaxwell> It's a dumb sales tactic regardless, I've met multiple people who paid for cloudflare for their business with the _belief_ that it was a protection racket.
7972019-03-07T23:06:09  <gmaxwell> Like is it ethical for an insurer to just provide plain old fire insurance but manage to wink wink nudge nudge their way into customers thinking its a protection racket, even if they never actually do set fires?
7982019-03-07T23:06:27  *** anome has joined #bitcoin-core-dev
7992019-03-07T23:16:18  *** anome has quit IRC
8002019-03-07T23:21:04  <echeveria> nope.
8012019-03-07T23:21:38  <echeveria> do I need to write a pull for brute for peer discovery? connect(rand(0,2**32) + ":8333")
8022019-03-07T23:22:51  <gmaxwell> IIRC phantomcircuit tried this years ago, (1) its too slow, and (2) it gets you scads of abuse complaints.
8032019-03-07T23:23:21  <gmaxwell> There are people that send offended "omg you tried connecting to my host" complaints. I wonder how they find time to eat dinner...
8042019-03-07T23:34:13  *** bitcoin-git has joined #bitcoin-core-dev
8052019-03-07T23:34:13  <bitcoin-git> [bitcoin] sipa opened pull request #15558: Query DNS seeds one by one (master...201903_dnsoneatatime) https://github.com/bitcoin/bitcoin/pull/15558
8062019-03-07T23:34:15  *** bitcoin-git has left #bitcoin-core-dev
8072019-03-07T23:34:24  <sipa> you may be interested ^
8082019-03-07T23:34:39  <Lightsword> should #15103 be set as a 0.18 milestone?
8092019-03-07T23:34:41  <gribble> https://github.com/bitcoin/bitcoin/issues/15103 | fix getentropy import check on osx by jameshilliard · Pull Request #15103 · bitcoin/bitcoin · GitHub
8102019-03-07T23:35:02  <gmaxwell> hm. that increases eclipse vulnerablity.
8112019-03-07T23:35:22  <sipa> hmm
8122019-03-07T23:35:35  <gmaxwell> e.g. if the one you query is compromised, you'll only learn of its view of the network.
8132019-03-07T23:36:00  *** Aaronvan_ has joined #bitcoin-core-dev
8142019-03-07T23:36:04  <sipa> what about querying in groups of 2 or 3?
8152019-03-07T23:37:00  <gmaxwell> That would be better.
8162019-03-07T23:37:38  <sipa> maybe more abstractly... assuming we'd find an increasingly large group of DNS seeds (all satisfying the same standards), i don't think we should keep querying all of them all the time
8172019-03-07T23:38:48  *** AaronvanW has quit IRC
8182019-03-07T23:43:46  <gmaxwell> yes, agreed. though the tor entry guard argument applies.
8192019-03-07T23:44:19  <gmaxwell> We probably don't want to randomly query them on each start, because if some are bad for your privacy (e.g. logging networks running bitcoin node) then you'll eventually hit them.
8202019-03-07T23:44:53  <gmaxwell> probably the things you want to do is take an order from your address hash, and query in that order or something analogous.
8212019-03-07T23:45:25  <sipa> well generally you wouldn't query the DNS seed on every start
8222019-03-07T23:45:38  <sipa> after you have a reasonably well-populated addrman
8232019-03-07T23:52:31  <gmaxwell> at least here I notice my node does query on every start lately, I'm not entirely sure why.
8242019-03-07T23:52:53  <gmaxwell> maybe it's some combination of feelers getting stuck and junk on the network.
8252019-03-07T23:53:26  <promag> got "Unable to open file .../regtest/blocks/rev00000.dat", any tips?
8262019-03-07T23:53:41  <gmaxwell> in any case, we have a random value stored in addrman, we could use that to decide on an order to query dnsseeds that was consistent for a single node.
8272019-03-07T23:55:05  <sipa> promag: pruned node?
8282019-03-07T23:55:48  <promag> sipa: no, and just calling some "generatetoaddress 1000 ..."
8292019-03-07T23:56:46  <sipa> promag: looks like you have a disk/FS problem
8302019-03-07T23:57:44  <promag> i'm stashing my changes