12019-04-11T00:05:05  *** bushstar has quit IRC
  22019-04-11T00:15:21  <achow101> jnewbery: yeah, i've been seeing that pretty often
  32019-04-11T00:17:29  *** ghost43 has quit IRC
  42019-04-11T00:25:47  *** ghost43 has joined #bitcoin-core-dev
  52019-04-11T00:30:17  *** DougieBot5000_ has joined #bitcoin-core-dev
  62019-04-11T00:32:15  *** DougieBot5000 has quit IRC
  72019-04-11T00:32:16  *** Cory has quit IRC
  82019-04-11T00:32:16  *** hardforkthis has quit IRC
  92019-04-11T00:32:16  *** spinza has quit IRC
 102019-04-11T00:32:17  *** shtirlic has quit IRC
 112019-04-11T00:32:26  *** hardforkthis has joined #bitcoin-core-dev
 122019-04-11T00:32:39  *** shtirlic has joined #bitcoin-core-dev
 132019-04-11T00:32:56  *** rafalcpp has quit IRC
 142019-04-11T00:33:39  *** rafalcpp has joined #bitcoin-core-dev
 152019-04-11T00:34:51  *** CubicEarth has quit IRC
 162019-04-11T00:35:16  *** DeanGuss has joined #bitcoin-core-dev
 172019-04-11T00:37:01  *** CubicEarth has joined #bitcoin-core-dev
 182019-04-11T00:37:23  *** spinza has joined #bitcoin-core-dev
 192019-04-11T00:38:53  *** Cory has joined #bitcoin-core-dev
 202019-04-11T00:41:59  *** Jackielove4u has quit IRC
 212019-04-11T01:04:52  *** DougieBot5000_ is now known as DougieBot5000
 222019-04-11T01:06:29  *** booyah has quit IRC
 232019-04-11T01:22:54  *** promag has joined #bitcoin-core-dev
 242019-04-11T01:27:00  *** promag has quit IRC
 252019-04-11T01:28:49  *** fanquake has joined #bitcoin-core-dev
 262019-04-11T01:33:43  *** egp__ has quit IRC
 272019-04-11T02:04:25  <gmaxwell> My node banlist has been updated and includes more than a few additions of spies, mass connectors, and other abusive nodes. https://people.xiph.org/~greg/banlist.cli.txt https://people.xiph.org/~greg/banlist.gui.txt
 282019-04-11T02:05:46  <wumpus> dongcarl: no, the name proxy is not for onion addresses, it is for DNS names where the network is not known, I think it ever only had one use (but I can be wrong) connecting to the DNS seeds for one-shot. It's kind of a hack and would be happy if it's no longer used and can go...
 292019-04-11T02:05:50  <wumpus> gmaxwell: thanks!
 302019-04-11T02:09:56  <wumpus> dongcarl: but last time I tried to I couldn't remove it because in the "fully behind behind tor proxy" case the one-shot connections were the only way to initially seed peers due to lack of DNS resolve support, I remember cfields_ was working on changing this flow at some point but not the details at the moment
 312019-04-11T02:11:37  <wumpus> (I think in practice it might be valid to replace use of the name proxy by use of the IPv4 one, as they're always the same)
 322019-04-11T02:14:09  *** dviola has quit IRC
 332019-04-11T02:14:20  <dongcarl> Oh I'm guessing the last time you tried to remove this, bitcoin only had support for SOCK4 and couldn't resolve thru the normal proxy?
 342019-04-11T02:15:30  <gmaxwell> my vague recollection is that we can never _resolve_ via a proxy, we can _connect to a name_ but conecting to a name isn't sufficient to get us the results of a dnsseed query...
 352019-04-11T02:15:45  <wumpus> no, I don't think so--it has always only supported SOCKS4A and SOCKS5 which both support name addresses
 362019-04-11T02:15:48  <wumpus> exactly ^^
 372019-04-11T02:16:09  <wumpus> that's the problem, you can connect to a name but you never learn the underlying address
 382019-04-11T02:17:21  <gmaxwell> so what one shot does is just connects to a name, gets addresses from it, and disconnects. (we don't want to throughly bias our connectivity to whatever unlucky hosts are in the dns seed output, as it risks overloading them, esp since some resolvers don't round robbin well)
 392019-04-11T02:17:22  <wumpus> Tor has an extension to the SOCKS5 protocol that adds an explicit RESOLVE command though: https://svn.torproject.org/svn/tor/tags/tor-0_2_1_7_alpha/doc/spec/socks-extensions.txt
 402019-04-11T02:17:25  <dongcarl> Ah I see, so the proxy does the lookup and you don't get any transparency in that
 412019-04-11T02:17:43  <wumpus> yes
 422019-04-11T02:19:15  <dongcarl> gmaxwell: oh like connects to a bitcoin node and briefly get some other peers we can connect to from it then say bye?
 432019-04-11T02:19:37  <wumpus> right
 442019-04-11T02:31:33  <wumpus> gmaxwell: for me it would be convenient if banlist.cli.txt had ${BITCOIN_CLI} or something on every line instead of ./bitcoin-cli, and allowed it to be overridden, for example to point to a custom bitcoin-cli path or providing a -datadir/-conf argument
 452019-04-11T02:32:20  <wumpus> (it could still default to ./bitcoin-cli ofc)
 462019-04-11T02:33:12  * luke-jr wonders how many people just curl and run the script blindly
 472019-04-11T02:40:06  <wumpus> I definitely don't run it blindly
 482019-04-11T03:02:05  *** bushstar has joined #bitcoin-core-dev
 492019-04-11T03:20:28  <gmaxwell> luke-jr: certantly wasn't my intent, at least the way I use it is copy and paste, so not blindly.
 502019-04-11T03:24:29  <luke-jr> I didn't mean to imply anyone *here* would run it blindly :x
 512019-04-11T03:28:01  <gmaxwell> luke-jr: perhaps I should make the first line of the file a sleep 10000000
 522019-04-11T03:30:03  *** ranefer has joined #bitcoin-core-dev
 532019-04-11T03:32:34  <luke-jr> heh
 542019-04-11T03:33:45  <luke-jr> do modern x86 systems still have PC speakers? maybe make it play a rickroll before that ;)
 552019-04-11T03:33:49  <echeveria> gmaxwell: if you want to be google. while true; do sleep 1000000; done. that was the standard format for bypassing vulnerabilities in Internet Explorer.
 562019-04-11T03:46:11  *** Eagle[TM] has joined #bitcoin-core-dev
 572019-04-11T03:48:22  *** EagleTM has quit IRC
 582019-04-11T03:56:21  *** chriswang2019 has joined #bitcoin-core-dev
 592019-04-11T04:04:49  *** chriswang2019 has quit IRC
 602019-04-11T04:23:20  <TD-Linux> luke-jr, they do, but it may be emulated in various ways (maybe even with smm)
 612019-04-11T04:27:02  <sipa>  /me has fond memories of the PLAY command in GW-BASIC
 622019-04-11T04:28:49  * luke-jr has Linux software to emulate the BASIC PLAY command <.<
 632019-04-11T04:29:13  <luke-jr> turns out there's actually a spec for it called MML
 642019-04-11T04:59:59  *** bushstar has quit IRC
 652019-04-11T05:07:07  *** pinheadmz has joined #bitcoin-core-dev
 662019-04-11T05:12:03  *** ranefer has quit IRC
 672019-04-11T05:45:43  *** bitcoin-git has joined #bitcoin-core-dev
 682019-04-11T05:45:44  <bitcoin-git> [bitcoin] benthecarman opened pull request #15790: [0.18] backport #15754 (0.18...0.18) https://github.com/bitcoin/bitcoin/pull/15790
 692019-04-11T05:45:51  *** bitcoin-git has left #bitcoin-core-dev
 702019-04-11T05:57:21  *** rex4539 has quit IRC
 712019-04-11T06:09:58  *** rex4539 has joined #bitcoin-core-dev
 722019-04-11T06:15:20  <emilr> speaking of seeds/peers I have bitcoin running in an isolated environment: it can't connect to anything except .onions and it has some peers added with addnode, the behaviour that I'm seeing is that bitcoind does not learn about other peers from its existing ones, possibly because dns seeds fail, the expected behaviour is that bitcoin learns about other peers from it's existing ones (the ones
 732019-04-11T06:15:26  <emilr> added with addnode, connect has the same behaviour)
 742019-04-11T06:26:32  *** Eagle[TM] has quit IRC
 752019-04-11T06:38:17  <emilr> wumpus: sed -e 's|./bitcoin-cli|ANYTHING -you -want|g' banlist.cli.txt
 762019-04-11T06:44:01  *** booyah has joined #bitcoin-core-dev
 772019-04-11T06:44:24  *** Jackielove4u has joined #bitcoin-core-dev
 782019-04-11T06:47:05  <gmaxwell> emilr: why do you say that it doesn't learn
 792019-04-11T06:47:51  *** ccdle12 has joined #bitcoin-core-dev
 802019-04-11T07:02:45  *** chriswang2019 has joined #bitcoin-core-dev
 812019-04-11T07:02:59  <emilr> peers.dat is 97K so basically empty and it doesn't connect to any other peer except the ones added with addnode
 822019-04-11T07:05:01  <gmaxwell> 97k is far from empty there aren't that many onion peers.
 832019-04-11T07:05:11  <gmaxwell> so that part isn't interesting.
 842019-04-11T07:06:22  <gmaxwell> any chance you have automatic connections disabled?  how is "it can't connect to anything except .onions" accomplished?
 852019-04-11T07:06:54  *** promag has joined #bitcoin-core-dev
 862019-04-11T07:08:05  <emilr> onlynet=onion and bitcoin user is blocked from making connections to the clearnet
 872019-04-11T07:10:47  *** pinheadmz has quit IRC
 882019-04-11T07:11:21  <emilr> also tor is configured with SocksPort 9050 OnionTrafficOnly
 892019-04-11T07:13:38  <gmaxwell> emilr: is it logging attempts to connect to things?
 902019-04-11T07:19:36  *** chriswang2019 has quit IRC
 912019-04-11T07:23:26  *** promag has quit IRC
 922019-04-11T07:25:38  <emilr> gmaxwell: I was under the impression it would fetch all peers regardless of net but it did indeed discover some peers, I see 190 different .onions in two weeks, I think what happened is that bitcoin gave up on a lot of those peers after few failures but failure to connect is a normality in the tor land
 932019-04-11T07:32:51  <emilr> I'll increase -timeout and wipe peers.dat to see if it makes much of a difference, I guess bitcoin needs to be more agressive when it has a limited number of peers
 942019-04-11T07:35:21  <gmaxwell> emilr: if it's onlynet=onion it'll only store onion peers
 952019-04-11T07:38:19  <wumpus> right, it discovers only .onion if that't the only enabled network
 962019-04-11T07:41:44  <emilr> makes sense, although other onlynet=tor nodes I ran had clearnet peers as well but those nodes weren't so isolated from clearnet
 972019-04-11T07:44:17  <DeanGuss> onlynet=onion is the only thing that works, not onlynet=tor -- is that why maybe it is ignoring your onlynet=tor ?
 982019-04-11T07:44:18  <wumpus> if onlynet=tor have clearnet peers (even tries to connect to anything non-clearnet) that's would be a bug, it definitely isn't my experience on the ones I run; though if the listening port is open to the internet, even without it advertizing your address, there's a chance peers might find you by random
 992019-04-11T07:44:47  <wumpus> onlynet=tor works too, it's equivalent
1002019-04-11T07:45:17  <DeanGuss> huh.  ok, I thought it didn't but I only tried a few releases ago
1012019-04-11T07:46:14  <wumpus> it's deprecated and will give a "Warning: net name 'tor' is deprecated and will be removed in the future. You should use 'onion' instead." error but it's definitely not going to silently ignore it
1022019-04-11T07:50:36  <wumpus> (onlynet isn't mentioned in doc/tor.md btw; would make sense to do so)
1032019-04-11T08:18:26  *** ccdle12 has quit IRC
1042019-04-11T08:18:36  *** ccdle12 has joined #bitcoin-core-dev
1052019-04-11T08:22:49  <kallewoof> Does the encryptwallet feature in bitcoin core relate to bip 38 in any way, or do they just look similar? It looks like it is basically doing the same thing but with scrypt replaced.
1062019-04-11T08:27:25  <wumpus> it does not relate to bip38 in any way; if anything, most people involved with bitcoin dev really dislike bip38 and it's per-key encryption
1072019-04-11T08:27:59  <jonasschnelli> what could be the reason for a null leveldb obfuscation key?
1082019-04-11T08:28:10  <jonasschnelli> Using obfuscation key for /btc/data/bitcoin/blocks/index: 0000000000000000
1092019-04-11T08:31:47  *** setpill has joined #bitcoin-core-dev
1102019-04-11T08:34:55  *** timothy has joined #bitcoin-core-dev
1112019-04-11T08:35:26  <wumpus> jonasschnelli: the block index isn't obfuscated is it? just the utxo set
1122019-04-11T08:36:21  <jonasschnelli> wumpus: Oh. NM. I missread it (was confused by an empty key)
1132019-04-11T08:37:57  *** ccdle12 has quit IRC
1142019-04-11T08:38:31  *** ccdle12 has joined #bitcoin-core-dev
1152019-04-11T08:40:16  <kallewoof> wumpus: Oh, okay. Thanks
1162019-04-11T08:44:17  *** fanquake has quit IRC
1172019-04-11T08:44:46  <wumpus> kallewoof: I think the only commonality is that it both involves some kind of loop for key-stretching
1182019-04-11T08:46:31  <kallewoof> wumpus: i finally spotted the "unanimously discouraged" part in comments and read thru the comments page on the bip. I kind of just want to combine a key and a user password into a password-protected-key. Seems the encryptwallet feature does basically that, though, unless I'm confused.
1192019-04-11T08:52:35  *** promag has joined #bitcoin-core-dev
1202019-04-11T08:53:07  <wumpus> it uses a standard mechanism at least
1212019-04-11T09:02:26  <wumpus> BIP38 has some really goofy things, it was never really peer-reviewed just dropped out there,but I don't remember what anymore-please don't use it, though
1222019-04-11T09:04:28  <kallewoof> I won't! Thanks
1232019-04-11T09:18:42  <emilr> the good news is that you can bootstrap bitcoind in a tor only environment from the hardcoded onion seeds, the bad news is that you can't using a rpi :) unless you use connect, it appears that the latency of the usb disk adds to negociation time thus making peer discovery unworkable, a sad day for the poor little guy
1242019-04-11T09:19:44  <wumpus> huh, I believe we didn't update the hardcoded seeds for 0.18
1252019-04-11T09:20:57  <wumpus> emilr: it shouldn't hold up network negotiation on disk access, does it time out on something?
1262019-04-11T09:25:49  *** bitcoin-git has joined #bitcoin-core-dev
1272019-04-11T09:25:49  <bitcoin-git> [bitcoin] MeshCollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6a135fbe5b30...f6120d40d583
1282019-04-11T09:25:50  <bitcoin-git> bitcoin/master 7a9046e John Newbery: [wallet] Refactor CWalletTx::RelayWalletTransaction()
1292019-04-11T09:25:50  <bitcoin-git> bitcoin/master f6120d4 MeshCollider: Merge #15728: [wallet] Refactor relay transactions
1302019-04-11T09:25:53  *** bitcoin-git has left #bitcoin-core-dev
1312019-04-11T09:26:32  *** bitcoin-git has joined #bitcoin-core-dev
1322019-04-11T09:26:32  <bitcoin-git> [bitcoin] MeshCollider merged pull request #15728: [wallet] Refactor relay transactions (master...2019_03_refactor_relay_transactions) https://github.com/bitcoin/bitcoin/pull/15728
1332019-04-11T09:26:33  *** bitcoin-git has left #bitcoin-core-dev
1342019-04-11T09:27:29  <emilr> most connections timeout at version handshake, takes about 10s for verack plus network latency, if bitcoin tor nodes run with the default timeout then you're out of luck
1352019-04-11T09:27:30  *** jonatack has joined #bitcoin-core-dev
1362019-04-11T09:28:56  *** AaronvanW has joined #bitcoin-core-dev
1372019-04-11T09:29:24  *** Skirmant has quit IRC
1382019-04-11T09:30:32  *** bitcoin-git has joined #bitcoin-core-dev
1392019-04-11T09:30:34  <bitcoin-git> [bitcoin] MeshCollider pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/f6120d40d583...c536dfbcb00f
1402019-04-11T09:30:34  <bitcoin-git> bitcoin/master fbc6bb8 Russell Yanofsky: bitcoin-wallet tool: Drop MakeChain calls
1412019-04-11T09:30:35  <bitcoin-git> bitcoin/master b874747 Russell Yanofsky: Remove access to node globals from wallet-linked code
1422019-04-11T09:30:36  <bitcoin-git> bitcoin/master 78a2fb5 Russell Yanofsky: bitcoin-wallet tool: Drop libbitcoin_server.a dependency
1432019-04-11T09:30:38  *** bitcoin-git has left #bitcoin-core-dev
1442019-04-11T09:31:00  <wumpus> that's interesting, which rpi are you using?
1452019-04-11T09:31:13  *** bitcoin-git has joined #bitcoin-core-dev
1462019-04-11T09:31:14  <bitcoin-git> [bitcoin] MeshCollider merged pull request #15639: bitcoin-wallet tool: Drop libbitcoin_server.a dependency (master...pr/link2) https://github.com/bitcoin/bitcoin/pull/15639
1472019-04-11T09:31:14  *** bitcoin-git has left #bitcoin-core-dev
1482019-04-11T09:31:29  <wumpus> I've never noticed that myself, just that block validation is slow, the network stuff seems to run at normal speed on my ARM boards
1492019-04-11T09:31:48  <wumpus> (well, maybe slower, but not thus slow it's self-sabotaging)
1502019-04-11T09:33:03  *** ccdle12 has quit IRC
1512019-04-11T09:33:05  <emilr> 3B+, I'm guessing it's not an issue if you don't sync over tor
1522019-04-11T09:33:21  <wumpus> same with tor—though the difference might be that I always bootstrap from the DNS seeds, I haven't tried the built-in seeds for a long time
1532019-04-11T09:33:23  <wumpus> I do
1542019-04-11T09:33:52  <wumpus> but it's been a while, could try again
1552019-04-11T09:34:02  <wumpus> first, seeds update for 0.18..
1562019-04-11T09:39:49  *** rex4539 has quit IRC
1572019-04-11T09:40:28  *** promag has quit IRC
1582019-04-11T10:03:29  *** jonatack has quit IRC
1592019-04-11T10:12:42  *** gelmutshmidt has joined #bitcoin-core-dev
1602019-04-11T10:19:43  *** bitcoin-git has joined #bitcoin-core-dev
1612019-04-11T10:19:43  <bitcoin-git> [bitcoin] laanwj opened pull request #15791: [do not merge] net: Hardcoded seeds update for 0.18 (master...2019_04_hardcoded_seeds_update) https://github.com/bitcoin/bitcoin/pull/15791
1622019-04-11T10:19:45  *** bitcoin-git has left #bitcoin-core-dev
1632019-04-11T10:36:03  <wumpus> ok something strange is happening here
1642019-04-11T10:36:32  <wumpus> it looks like sipa's seed does return onion peers but somehow, makeseeds.py throws all of them out
1652019-04-11T10:39:56  *** jonatack has joined #bitcoin-core-dev
1662019-04-11T10:42:15  <wumpus> so I *guess* the problem is that onion peers, due to relative unreliability of the medium, get sorted lower and dropped out of the uptime scores
1672019-04-11T10:43:06  <wumpus> but why this is suddenly an issue I don't know, maybe tor was down for a while on the crawler?
1682019-04-11T10:45:17  *** profmac has quit IRC
1692019-04-11T10:49:25  <emilr> pubmsg: or due to the fact that the number of peers increased pushing onions even further down the list, I'll check
1702019-04-11T10:51:55  *** spinza has quit IRC
1712019-04-11T10:52:00  <emilr> pubmsg: whats up with 450k seeds?, lol
1722019-04-11T10:58:26  *** profmac has joined #bitcoin-core-dev
1732019-04-11T11:15:10  *** Sentineo has joined #bitcoin-core-dev
1742019-04-11T11:15:48  <wumpus> added stats https://github.com/bitcoin/bitcoin/pull/15791#issuecomment-482072722
1752019-04-11T11:16:34  *** dviola has joined #bitcoin-core-dev
1762019-04-11T11:16:41  *** harrymm has quit IRC
1772019-04-11T11:21:57  <wumpus> maybe change the uptime requirement for onions?
1782019-04-11T11:23:56  *** promag has joined #bitcoin-core-dev
1792019-04-11T11:24:42  <wumpus> bah, even changing it to 25% with no other changes only gives 10 onions
1802019-04-11T11:26:17  *** spinza has joined #bitcoin-core-dev
1812019-04-11T11:27:07  *** rex4539 has joined #bitcoin-core-dev
1822019-04-11T11:27:57  *** promag has quit IRC
1832019-04-11T11:29:50  *** harrymm has joined #bitcoin-core-dev
1842019-04-11T11:31:26  <wumpus> it's better than nothing, I guess
1852019-04-11T11:31:29  <emilr> pubmsg: I think the whole process needs a bit of rework, I wouldn't trust whatever list the script generates
1862019-04-11T11:36:04  <emilr> pubmsg: version 17.0 has 120ish onion peers, this one generates just 2, theres no other checks for onion and ipv6, the input list is ripe with light clients and scanners, the uptime goes back only 30days which makes it easy to get a majority of nodes into the seed list, I will dedicate some time to it next week
1872019-04-11T11:36:47  *** chriswang2019 has joined #bitcoin-core-dev
1882019-04-11T11:43:02  *** bitcoin-git has joined #bitcoin-core-dev
1892019-04-11T11:43:02  <bitcoin-git> [bitcoin] jonatack opened pull request #15792: doc: describe onlynet option in doc/tor.md (master...add-onlynet-option-to-tor-docs) https://github.com/bitcoin/bitcoin/pull/15792
1902019-04-11T11:43:03  *** bitcoin-git has left #bitcoin-core-dev
1912019-04-11T11:45:42  *** chriswang2019 has quit IRC
1922019-04-11T11:46:27  *** chriswang2019 has joined #bitcoin-core-dev
1932019-04-11T11:48:45  *** chriswang2019 has quit IRC
1942019-04-11T12:01:13  <wumpus> emilr: I don't think that's very useful commentary, we need to know what step is causing problems, if the problem is with the script at all: if it's the DNS seed significantly under-reporting uptime for onion peers then it's not the script's fault at all
1952019-04-11T12:02:37  <wumpus> in itself, 50% uptime is a reasonable requirement
1962019-04-11T12:05:19  <wumpus> even using grep directly on the downloaded input I cannot corabborate your claim that "version 17.0 has 120ish onion peers"
1972019-04-11T12:05:29  <wumpus> grep \.onion seeds_main.txt|grep "/Satoshi:0.17" -> one result
1982019-04-11T12:07:07  <wumpus> unless you have a different source? if so, please let me know
1992019-04-11T12:11:41  *** ajtowns[m] has quit IRC
2002019-04-11T12:11:47  *** DavidMitchell[m] has quit IRC
2012019-04-11T12:11:52  *** TheFuzzStone[m] has quit IRC
2022019-04-11T12:12:02  *** stepa[m] has quit IRC
2032019-04-11T12:12:07  *** kewde[m] has quit IRC
2042019-04-11T12:16:45  <emilr> sorry, what I meant is that bitcoin core 0.17 has 120 hardcoded onion peers
2052019-04-11T12:21:07  <wumpus> oh!
2062019-04-11T12:21:32  <wumpus> yes, I misunderstood your sentence then
2072019-04-11T12:22:03  <wumpus> would make sense to do a scan on them and see how many are still functional, and if so, why the crawler is leaving them out
2082019-04-11T12:23:29  <emilr> doing that now in order to see how many of the peers from 0.17 are still up, so that if you're pressured to release you can use the old list
2092019-04-11T12:25:10  <wumpus> right
2102019-04-11T12:51:41  <emzy> how do I generate the seed.txt.gz file?
2112019-04-11T12:52:55  <emzy> ok found it: https://github.com/sipa/bitcoin-stats/blob/b1690b87a781a2bdd1b5f7e6fa284e1bc0e50541/update.sh#L104
2122019-04-11T12:55:29  <emilr> wumpus out of 109 hardcoded onion seeds, 72 responded at first check, and none of them are in sipa's seeds, in fact only 3 out of the 109 hardcoded seeds are in seeds_main.txt which has 712 onions
2132019-04-11T12:55:38  <wumpus> emilr: interesting
2142019-04-11T13:03:51  <emilr> something is missing from the picture, sipa's seeds has all nodes since 2013, where are the hardcoded onions from if they're not in seeds_main.txt ?
2152019-04-11T13:04:01  <emzy> I have no .onion
2162019-04-11T13:08:06  <wumpus> heh
2172019-04-11T13:10:06  <emzy> no idea what's the problem
2182019-04-11T13:10:24  <wumpus> emilr: i don't think "has all nodes since 2013" is true
2192019-04-11T13:11:44  <wumpus> for example the list doesn't include anything with zero uptime in last 30 days
2202019-04-11T13:12:01  <wumpus> and that would be *many* if so
2212019-04-11T13:12:37  <emilr> looks like it, once a node because unreachable it is not removed from the list, in fact most of the top 6500 servers by uptime were last updated in 12 Feb
2222019-04-11T13:12:55  <emilr> wumpus: thats because once a server goes stale, it keeps it's uptime history
2232019-04-11T13:14:07  <wumpus> in any case, for better or worse, everyting in the hardcoded seeds, ever, has come from sipa's crawler up to now
2242019-04-11T13:14:56  <wumpus> I think that's acceptable because it's only a fallback
2252019-04-11T13:17:30  <emilr> just check block height 2624 top nodes at 562647, and 4281 at 562646, that's the last time the list was updated
2262019-04-11T13:18:56  <wumpus> emilr: did you configure the crawler with tor? (I haven't ever run a DNS seed myself so I don't know the details, unfortunately)
2272019-04-11T13:20:06  <emilr> I didn't crawl, I downloaded http://bitcoin.sipa.be/seeds.txt.gz as per README
2282019-04-11T13:20:33  <wumpus> oh, sorry, that was meant for emzy
2292019-04-11T13:22:15  <emzy> wumpus: no, I have no crawler for tor configures. But a tor is running on the server.
2302019-04-11T13:22:38  <emzy> wumpus: do you have a readme for the crawler setup for me>
2312019-04-11T13:23:03  <wumpus> no, I don't
2322019-04-11T13:24:03  <wumpus> `bitcoin-seeder --help` seems to return some options https://github.com/sipa/bitcoin-seeder/blob/master/main.cpp#L37
2332019-04-11T13:24:13  <wumpus> (if that's what you're using)
2342019-04-11T13:24:29  <emzy> I will try -o
2352019-04-11T13:29:14  <emzy> It worked!
2362019-04-11T13:29:20  <wumpus> awesome!
2372019-04-11T13:31:50  <emzy> I will wait a litte. to get the seeds.txt filled.
2382019-04-11T13:50:04  <emzy> 81 .onion
2392019-04-11T13:51:16  <emzy> # zgrep \.onion seeds.txt.gz|grep "/Satoshi:0.17" | wc -l   ->>> 66
2402019-04-11T13:51:34  *** chriswang2019 has joined #bitcoin-core-dev
2412019-04-11T13:54:57  *** chriswang2019 has quit IRC
2422019-04-11T13:56:30  <Sentineo> we need 600 more :)
2432019-04-11T13:57:59  *** bitcoin-git has joined #bitcoin-core-dev
2442019-04-11T13:57:59  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c536dfbcb00f...570eb7b130c2
2452019-04-11T13:58:00  <bitcoin-git> bitcoin/master 0b3a654 Peter Bushnell: Avoid redefine warning
2462019-04-11T13:58:00  <bitcoin-git> bitcoin/master 570eb7b Wladimir J. van der Laan: Merge #15782: Avoid redefine warning
2472019-04-11T13:58:02  *** bitcoin-git has left #bitcoin-core-dev
2482019-04-11T13:58:57  *** bitcoin-git has joined #bitcoin-core-dev
2492019-04-11T13:58:57  <bitcoin-git> [bitcoin] laanwj merged pull request #15782: Avoid redefine warning (master...warning-redefine) https://github.com/bitcoin/bitcoin/pull/15782
2502019-04-11T13:58:58  *** bitcoin-git has left #bitcoin-core-dev
2512019-04-11T14:03:41  *** bitcoin-git has joined #bitcoin-core-dev
2522019-04-11T14:03:42  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/570eb7b130c2...bb68abe784b9
2532019-04-11T14:03:43  <bitcoin-git> bitcoin/master 303372c Carl Dong: docs: Improve netaddress comments
2542019-04-11T14:03:44  <bitcoin-git> bitcoin/master bb68abe Wladimir J. van der Laan: Merge #15718: docs: Improve netaddress comments
2552019-04-11T14:03:46  *** bitcoin-git has left #bitcoin-core-dev
2562019-04-11T14:04:24  *** bitcoin-git has joined #bitcoin-core-dev
2572019-04-11T14:04:25  <bitcoin-git> [bitcoin] laanwj merged pull request #15718: docs: Improve netaddress comments (master...2019-04-netaddr-comments) https://github.com/bitcoin/bitcoin/pull/15718
2582019-04-11T14:04:25  *** ranefer has joined #bitcoin-core-dev
2592019-04-11T14:04:25  *** bitcoin-git has left #bitcoin-core-dev
2602019-04-11T14:06:23  *** pinheadmz has joined #bitcoin-core-dev
2612019-04-11T14:16:40  *** bitcoin-git has joined #bitcoin-core-dev
2622019-04-11T14:16:41  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15779: test: Add wallet_balance benchmark (master...1904-benchWallet) https://github.com/bitcoin/bitcoin/pull/15779
2632019-04-11T14:16:51  *** bitcoin-git has left #bitcoin-core-dev
2642019-04-11T14:25:44  *** dviola has quit IRC
2652019-04-11T14:53:19  <stevenroose> "private key in base58-encoding" means WIF format, right?
2662019-04-11T14:53:30  <stevenroose> that's a cite from signrawtransactionwithkey
2672019-04-11T14:55:01  *** jarthur has joined #bitcoin-core-dev
2682019-04-11T14:55:15  <sipa> stevenroose: yes
2692019-04-11T15:07:26  *** Guyver2 has joined #bitcoin-core-dev
2702019-04-11T15:16:29  *** provoostenator has quit IRC
2712019-04-11T15:17:42  *** provoostenator has joined #bitcoin-core-dev
2722019-04-11T15:19:06  *** jarthur has quit IRC
2732019-04-11T15:19:17  *** setpill has quit IRC
2742019-04-11T15:27:55  *** jarthur has joined #bitcoin-core-dev
2752019-04-11T15:35:31  *** jb55 has joined #bitcoin-core-dev
2762019-04-11T15:53:00  *** jarthur has quit IRC
2772019-04-11T16:02:09  *** jarthur has joined #bitcoin-core-dev
2782019-04-11T16:06:12  <stevenroose> It appears that listtransactions returns a negative number of confirmatins for txs in orphaned blocks.
2792019-04-11T16:06:36  <stevenroose> Is this the case for other calls as well? I.e. should a client expect signed numbers always for confirmations?
2802019-04-11T16:07:26  <sipa> negative numbers indicate how deep the conflict is
2812019-04-11T16:08:23  <stevenroose>     return ((nIndex == -1) ? (-1) : 1) * (chainActive.Height() - pindex->nHeight + 1);
2822019-04-11T16:08:47  <stevenroose> So is that a generic thing? Like all calls can do that?
2832019-04-11T16:08:57  <sipa> i doubt that
2842019-04-11T16:09:02  <stevenroose> Like gettxout, getrawtransaction, getblockheader?
2852019-04-11T16:09:24  <stevenroose> Seems to come from CMerkleTx::GetDepthInMainChain
2862019-04-11T16:09:39  <sipa> are you sure that pindex is the block the tx is included in here?
2872019-04-11T16:09:51  <sipa> i think it's the block the _conflict_ is included in
2882019-04-11T16:10:22  <sipa> just an orphaned transaction should have 0 confirmations
2892019-04-11T16:10:36  <sipa> it's only when a doublespend of it gets confirmed that you get negative numbers
2902019-04-11T16:12:46  <sipa> gettxout only applies to actually existing UTXOs, so negative confirmations don't make sense there
2912019-04-11T16:12:59  <sipa> same for getrawtransaction
2922019-04-11T16:14:07  <sipa> and it doesn't apply at all to blocks
2932019-04-11T16:24:55  <wumpus> CMerkleTx is only used from the wallet; it'll be wallet calls at most that use that convention
2942019-04-11T16:25:25  <stevenroose> sipa: srry didn't see your response. thanks. will report to Alekos, who bumped into this. I think he indeed double-spent his own tx after forking
2952019-04-11T16:31:02  *** inersha has joined #bitcoin-core-dev
2962019-04-11T16:33:09  *** inersha has left #bitcoin-core-dev
2972019-04-11T16:43:47  *** jarthur has quit IRC
2982019-04-11T16:45:15  *** jarthur has joined #bitcoin-core-dev
2992019-04-11T16:55:18  *** bitcoin-git has joined #bitcoin-core-dev
3002019-04-11T16:55:19  <bitcoin-git> [bitcoin] dongcarl opened pull request #15794: docs: Clarify PR guidelines w/re documentation (master...2019-04-doc-doc) https://github.com/bitcoin/bitcoin/pull/15794
3012019-04-11T16:55:20  *** bitcoin-git has left #bitcoin-core-dev
3022019-04-11T17:02:30  *** bitcoin-git has joined #bitcoin-core-dev
3032019-04-11T17:02:31  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15795: scripted-diff: Avoid name collisions in CChainState (master...1904-m_chain) https://github.com/bitcoin/bitcoin/pull/15795
3042019-04-11T17:02:31  *** bitcoin-git has left #bitcoin-core-dev
3052019-04-11T17:16:55  *** bitcoin-git has joined #bitcoin-core-dev
3062019-04-11T17:16:55  <bitcoin-git> [bitcoin] instagibbs opened pull request #15796: CReserveKey should not allow passive key re-use, KeepKey in destructor (master...burn_reserve) https://github.com/bitcoin/bitcoin/pull/15796
3072019-04-11T17:16:56  *** bitcoin-git has left #bitcoin-core-dev
3082019-04-11T17:24:15  *** bitcoin-git has joined #bitcoin-core-dev
3092019-04-11T17:24:15  <bitcoin-git> [bitcoin] MarcoFalke pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/bb68abe784b9...0e9cb2d24dbf
3102019-04-11T17:24:16  <bitcoin-git> bitcoin/master fa4680e MarcoFalke: scripted-diff: Rename sync_blocks to send_blocks to avoid name collisions ...
3112019-04-11T17:24:16  <bitcoin-git> bitcoin/master fafe008 MarcoFalke: test: Pass at most one node group to sync_all
3122019-04-11T17:24:17  <bitcoin-git> bitcoin/master fa6dc7c MarcoFalke: test: Add BitcoinTestFramework::sync_* methods
3132019-04-11T17:24:18  *** bitcoin-git has left #bitcoin-core-dev
3142019-04-11T17:25:06  *** bitcoin-git has joined #bitcoin-core-dev
3152019-04-11T17:25:07  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15773: test: Add BitcoinTestFramework::sync_* methods (master...1904-qaSyncNew) https://github.com/bitcoin/bitcoin/pull/15773
3162019-04-11T17:25:07  *** bitcoin-git has left #bitcoin-core-dev
3172019-04-11T17:28:23  *** bitcoin-git has joined #bitcoin-core-dev
3182019-04-11T17:28:24  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15795: [WIP] scripted-diff: Avoid name collisions in CChainState (master...1904-m_chain) https://github.com/bitcoin/bitcoin/pull/15795
3192019-04-11T17:28:25  *** bitcoin-git has left #bitcoin-core-dev
3202019-04-11T17:46:44  *** bitcoin-git has joined #bitcoin-core-dev
3212019-04-11T17:46:45  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15797: travis: Bump second timeout to 33 minutes, Add rationale (master...1904-travisTime) https://github.com/bitcoin/bitcoin/pull/15797
3222019-04-11T17:46:57  *** bitcoin-git has left #bitcoin-core-dev
3232019-04-11T17:47:11  *** promag has joined #bitcoin-core-dev
3242019-04-11T17:49:37  *** hebasto has joined #bitcoin-core-dev
3252019-04-11T17:51:40  *** promag has quit IRC
3262019-04-11T17:59:33  *** hebasto has quit IRC
3272019-04-11T18:00:37  *** elichai2 has joined #bitcoin-core-dev
3282019-04-11T18:09:03  *** DeanGuss has quit IRC
3292019-04-11T18:17:14  *** bitcoin-git has joined #bitcoin-core-dev
3302019-04-11T18:17:14  <bitcoin-git> [bitcoin] theuni opened pull request #15798: RFC: Rust code integration (master...with-rust-example-working) https://github.com/bitcoin/bitcoin/pull/15798
3312019-04-11T18:17:15  *** bitcoin-git has left #bitcoin-core-dev
3322019-04-11T18:17:30  <cfields_> #proposedmeetingtopic Bitcoin CRust
3332019-04-11T18:17:36  <cfields_> #proposedmeetingtopic Potential platform deprecation
3342019-04-11T18:17:42  <luke-jr> Bitcoin CRust?
3352019-04-11T18:18:00  <luke-jr> are we deprecating Windows? :p
3362019-04-11T18:18:56  <cfields_> luke-jr: Heh. I have some proposals, but afaik we don't really have any policy. Figure it's worth discussing.
3372019-04-11T18:39:53  <wumpus> there was also a discussion about --disable-asm IIRC
3382019-04-11T18:42:48  <luke-jr> I don't really see what there is to discuss on that?
3392019-04-11T18:45:57  *** jeremyrubin has joined #bitcoin-core-dev
3402019-04-11T18:50:17  <MarcoFalke> There was some discussion in #13788, which is why it was removed from the 0.17. milestone
3412019-04-11T18:50:19  <gribble> https://github.com/bitcoin/bitcoin/issues/13788 | Fix --disable-asm for newer assembly checks/code by luke-jr · Pull Request #13788 · bitcoin/bitcoin · GitHub
3422019-04-11T18:51:12  <gmaxwell> sipa: did your crawler lose onion access? (see earlier discussion about nodes that are currently in the seeds list being no longer found by your crawler.
3432019-04-11T18:52:41  <luke-jr> MarcoFalke: seemed like everyone agreed on the interpretation except sipa who took it literally at first, and didn't really follow up with an objection later *shrug* can ask sipa to be explicit I guess
3442019-04-11T18:57:53  <sipa> luke-jr: i'm just unclear on the goal?
3452019-04-11T18:58:50  <sipa> is the goal disabling because (a) they're experimental and someone doesn't trust the optimizations (b) because no assembler is available and the build system incorrectly detects that or (c) the compiler doesn't support the intrinsics
3462019-04-11T18:58:58  <gmaxwell> disable machine specific crap that breaks weirdo compilers
3472019-04-11T18:59:03  <wumpus> working around build problems, and analysis tooling, basically
3482019-04-11T18:59:12  <sipa> the option was originally introduced because of (a), but i think that goal is gone
3492019-04-11T18:59:19  <gmaxwell> b/c.
3502019-04-11T18:59:22  <gmaxwell> yea, not a
3512019-04-11T18:59:31  <sipa> if it's for b/c both, it shouldn't be called asm
3522019-04-11T18:59:47  <gmaxwell> speaking of a, we don't enable asm for libsecp256k1 in the bitcoin core build, do we?
3532019-04-11T18:59:50  <wumpus> in any case, if the configure checks worked 100% (so, it would disable those things automatically if the compiler didn't understand them) it wouldn't be needed I think
3542019-04-11T19:00:01  <wumpus> gmaxwell: it does afaik
3552019-04-11T19:00:12  <sipa> gmaxwell: pretty sure we do, but not the arm asm
3562019-04-11T19:00:23  <wumpus> of course not the ARM asm :)
3572019-04-11T19:00:25  <wumpus> #startmeeting
3582019-04-11T19:00:25  <lightningbot> Meeting started Thu Apr 11 19:00:25 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3592019-04-11T19:00:25  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3602019-04-11T19:01:07  <wumpus> #topic 0.18.0
3612019-04-11T19:01:16  <wumpus> so it turns out we need another rc
3622019-04-11T19:01:29  <kanzure> hi
3632019-04-11T19:02:07  <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
3642019-04-11T19:02:21  <wumpus> (for #15776)
3652019-04-11T19:02:23  <gribble> https://github.com/bitcoin/bitcoin/issues/15776 | Expire inflight GETDATA requests by ajtowns · Pull Request #15776 · bitcoin/bitcoin · GitHub
3662019-04-11T19:02:31  <meshcollider> hi
3672019-04-11T19:02:35  <jonasschnelli> hi
3682019-04-11T19:02:39  <achow101> hi
3692019-04-11T19:02:42  <jamesob> hi
3702019-04-11T19:02:48  <cfields_> hi
3712019-04-11T19:02:49  <wumpus> the schedule was to tag final today, but we're not going to make that then I guess
3722019-04-11T19:02:51  <luke-jr> hi
3732019-04-11T19:02:54  <wumpus> let's at least tag a new rc?
3742019-04-11T19:02:57  <meshcollider> In that case, I think we should also backport #15749 ?
3752019-04-11T19:02:59  <gribble> https://github.com/bitcoin/bitcoin/issues/15749 | Fix: importmulti only imports origin info for PKH outputs by sipa · Pull Request #15749 · bitcoin/bitcoin · GitHub
3762019-04-11T19:03:10  <MarcoFalke> wumpus: nothging changed since rc3?
3772019-04-11T19:03:21  <sipa> 15776 is not yet merged
3782019-04-11T19:03:25  <wumpus> MarcoFalke: after 15776 ofc
3792019-04-11T19:03:33  <MarcoFalke> oh
3802019-04-11T19:03:57  <MarcoFalke> Doesn't look like it was reviewed
3812019-04-11T19:04:00  <wumpus> meshcollider: yea if all kinds of other bugs were found since, makes sense to include them
3822019-04-11T19:04:09  <wumpus> ok
3832019-04-11T19:04:40  <wumpus> well, 0.18.0 will be delayed a bit that's clear at least
3842019-04-11T19:04:46  <luke-jr> no big deal imo
3852019-04-11T19:05:14  <jonasschnelli> yes. acceptable
3862019-04-11T19:05:54  *** ranefer has quit IRC
3872019-04-11T19:06:09  <wumpus> no, it doesn't really matter, though I think review should focus on those PRs then
3882019-04-11T19:06:14  <sipa> agree
3892019-04-11T19:07:41  <wumpus> added #15749 to needs backport to 0.18.0
3902019-04-11T19:07:43  <gribble> https://github.com/bitcoin/bitcoin/issues/15749 | Fix: importmulti only imports origin info for PKH outputs by sipa · Pull Request #15749 · bitcoin/bitcoin · GitHub
3912019-04-11T19:08:17  <meshcollider> thanks
3922019-04-11T19:08:34  <wumpus> #topic Bitcoin CRust (cfields_)
3932019-04-11T19:09:10  <jnewbery> I'd request that #15750 gets considered for inclusion in the next rc. It completes a fix that is already in 0.18
3942019-04-11T19:09:11  <gribble> https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
3952019-04-11T19:09:31  <jeremyrubin> Hi! Also present
3962019-04-11T19:10:12  <instagibbs> hi
3972019-04-11T19:10:21  <luke-jr> jnewbery: that looks like removal of an API, not a fix; I don't really care though
3982019-04-11T19:10:35  <luke-jr> better to remove in 0.18.0 than 0.18.1
3992019-04-11T19:10:43  <cfields_> ah, sorry, irc went weird for me.
4002019-04-11T19:10:55  <cfields_> See #15798, lots of useful info there. tl;dr: This is a cool project from Jeremy Rubin that allows us to use rust code from inside of Bitcoin Core. No plan yet, I mostly just wanted to spread the word that people should try it out and report back. It pretty much just works. It is surprisingly complete, but has only been tested in a few environments so far.
4012019-04-11T19:10:57  <gribble> https://github.com/bitcoin/bitcoin/issues/15798 | RFC: Rust code integration by theuni · Pull Request #15798 · bitcoin/bitcoin · GitHub
4022019-04-11T19:11:13  <wumpus> jnewbery: looks like it's somewhat controversial, any reason to not do this for 0.19 instead?
4032019-04-11T19:11:15  <luke-jr> anyway, CRust.. I don't think including Rust inside Bitcoin Core is a good idea, even optionally, so long as Rust requires trusting third party binaries
4042019-04-11T19:11:18  <MarcoFalke> jnewbery: There shouldn't be any cost to only remove it in 0.19.0
4052019-04-11T19:11:19  <jonasschnelli> Nice work jnewbery and cfields_!
4062019-04-11T19:11:36  <jonasschnelli> luke-jr: it's an experiment AFAIK
4072019-04-11T19:11:37  <kanzure> which third party library is that
4082019-04-11T19:11:38  <wumpus> I really like the rust work
4092019-04-11T19:11:43  <jnewbery> Because the deprecation warning in the RPC help text is removed in 0.18
4102019-04-11T19:11:51  <luke-jr> jonasschnelli: experiments can be done outside Core
4112019-04-11T19:11:58  <cfields_> luke-jr: there are people working on that. This is experimental. This discussion is not helpful at this time.
4122019-04-11T19:11:59  <kanzure> you mean the rust binary?
4132019-04-11T19:12:01  <wumpus> jnewbery: wha-why ?
4142019-04-11T19:12:05  <luke-jr> kanzure: yes, rustc
4152019-04-11T19:12:05  <jonasschnelli> luke-jr: read the PR desc
4162019-04-11T19:12:09  <MarcoFalke> luke-jr: Bitcoin is experimental
4172019-04-11T19:12:10  <cfields_> luke-jr: it says right there. NOT FOR MERGE.
4182019-04-11T19:12:16  <cfields_> caps and everything :)
4192019-04-11T19:12:20  <jeremyrubin> luke-jr: did you see Marco's bootstrapping link as well?
4202019-04-11T19:12:33  <wumpus> it's an experiment, but it's good to have people aware of it
4212019-04-11T19:12:46  <cfields_> anyway, I'd like to get some feedback from people who have actually used rust.
4222019-04-11T19:12:56  <instagibbs> you'd want to ping #rust-bitcoin folks
4232019-04-11T19:13:01  <dongcarl> Hi
4242019-04-11T19:13:03  <luke-jr> jeremyrubin: as I understand it, mrustc only works on x86
4252019-04-11T19:13:05  <wumpus> dongcarl: ^^
4262019-04-11T19:13:07  <jamesob> rust is a pleasure to write - beyond that I don't have much input
4272019-04-11T19:13:16  <jonasschnelli> I don't disagree with luke-jr concerns,.. but an experiments needs to start somewhere and Rust will evolve over time
4282019-04-11T19:13:26  *** promag has joined #bitcoin-core-dev
4292019-04-11T19:13:42  <kanzure> don't we also use other compilers in deterministic builds..?
4302019-04-11T19:13:45  <jeremyrubin> luke-jr: can you not cross compile after bootstrap? Do you want to bootstrap on every platform?
4312019-04-11T19:13:50  <MarcoFalke> Yeah, it is good to see that the build system changes are smaller than anyone expected
4322019-04-11T19:13:59  <jeremyrubin> Anyways, as noted, this is just for enabling more experimentation
4332019-04-11T19:14:06  <cfields_> luke-jr's complaint has been heard. Let's move on please.
4342019-04-11T19:14:23  <gmaxwell> yeah, its not a for merge thing. Useful announcement.
4352019-04-11T19:14:29  <luke-jr> kanzure: hopefully we are moving away from that
4362019-04-11T19:14:45  <dongcarl> perhaps a good question is what parts of the code is memory safety the most critical
4372019-04-11T19:15:18  <wumpus> anything that interfaces to the hostile outside world (e.g. P2P code)
4382019-04-11T19:15:19  <gmaxwell> It would only be interesting to merge if there were some functionality written in rust that we wanted to include. It was surprising to me that it took as much as CRust in order to do that. (it isn't like we need anything special in the build system to link code written in C, for example)
4392019-04-11T19:15:21  <MarcoFalke> The parts that are not going to be rewritten in rust any time soon ;)
4402019-04-11T19:15:24  <cfields_> dongcarl: yes. also, what things are in-spec in rust that can only be undefined in c/c++.
4412019-04-11T19:15:25  <MarcoFalke> dongcarl: ^
4422019-04-11T19:15:28  <instagibbs> MarcoFalke, hah!
4432019-04-11T19:16:22  <jamesob> a while back BlueMatt had talked about doing a secondary fallback network stack in rust which would activate if the existing p2p code started acting weird
4442019-04-11T19:16:29  <jamesob> but that's obviously pretty speculative...
4452019-04-11T19:16:49  <wumpus> that's a pretty neat idea
4462019-04-11T19:16:58  <sipa> i don't understand the appeal of that idea
4472019-04-11T19:17:09  <sipa> the complexity is all in the interaction between network code and the rest
4482019-04-11T19:17:11  <meshcollider> I remember him bringing that up in tokyo
4492019-04-11T19:17:13  <jamesob> two is one and one is none, I guess
4502019-04-11T19:17:15  <luke-jr> gmaxwell: well, part of the concern is that people are more likely to write stuff others want in Rust than C++, with this; but maybe not a big deal if Rust is making good progress
4512019-04-11T19:17:15  <sipa> not in the network code itself
4522019-04-11T19:17:44  <luke-jr> jamesob: sounds more complex to detect "weird" than to just replace it
4532019-04-11T19:18:01  <jamesob> luke-jr: could be
4542019-04-11T19:18:09  <cfields_> sipa: I would think something like a rust-libevent would be pretty appealing. But yeah, that's a layer below us.
4552019-04-11T19:18:09  <wumpus> it's not so much about the complexity I think, but potential safety issues, rust would be safer for the network code
4562019-04-11T19:18:14  <luke-jr> if someone is compromising the original network stack, they can probably corrupt the alternate one too
4572019-04-11T19:18:44  <sipa> wumpus: in a way that we've actually ever had problems?
4582019-04-11T19:18:54  <cfields_> It's also worth considering that new tools could be written in rust. Doesn't have to be direct bitcoind integration.
4592019-04-11T19:19:09  <luke-jr> rewrite the node around libconsensus? ;)
4602019-04-11T19:19:10  <gmaxwell> IIRC. We have never had a bug in the network code that use of rust would have structurally prevented, we have however had many bugs of the same kind that occure in rust. see e.g. the somewhat recent parity (ethereum node software) network wide crasher vuln from memory exhaustion (I think ultimately stemming from livelocks)
4612019-04-11T19:19:22  <wumpus> sipa: that we haven't noticed any problems doesn't mean that they don't exist, but sure...
4622019-04-11T19:19:31  <sipa> iirc all scares we've had in the past were about unbounded data structures, processing interactions, buggy logic, ... not out of bounds issues or the sort
4632019-04-11T19:19:40  <wumpus> a lot of this is to rule out entire bug classes, not just to fix bugs that we've found
4642019-04-11T19:19:58  <sipa> wumpus: while introducing a complexity in making the two layers communicate
4652019-04-11T19:20:04  <wumpus> so in a sense it's speculative
4662019-04-11T19:20:06  <MarcoFalke> Doesn't rust fix uninitizlized reads? #14728
4672019-04-11T19:20:08  <gribble> https://github.com/bitcoin/bitcoin/issues/14728 | fix uninitialized read when stringifying an addrLocal by kazcw · Pull Request #14728 · bitcoin/bitcoin · GitHub
4682019-04-11T19:20:10  *** lnostdal has quit IRC
4692019-04-11T19:20:16  <dongcarl> Perhaps another useful property: Safe Rust guarantees an absence of data races.
4702019-04-11T19:20:17  <MarcoFalke> #6636
4712019-04-11T19:20:18  <gribble> https://github.com/bitcoin/bitcoin/issues/6636 | net: correctly initialize nMinPingUsecTime by laanwj · Pull Request #6636 · bitcoin/bitcoin · GitHub
4722019-04-11T19:20:24  <gmaxwell> at a cost of radically reducing the set of people who can review things, and more complexity from interfaces looking different on each side, however.
4732019-04-11T19:20:25  <wumpus> rust fixes undefined behavior at least,we've had plenty of that reported
4742019-04-11T19:20:25  <jeremyrubin> I think fixing some of the internal concurrent workers would be a good task
4752019-04-11T19:20:32  *** lnostdal has joined #bitcoin-core-dev
4762019-04-11T19:20:33  <jeremyrubin> E.g., the CheckQueue or Task QUeue
4772019-04-11T19:20:37  <sipa> my view is that if and when there is an actual project with useful code we'd like to introduce as a dependency, that happens to be written in rust, of course
4782019-04-11T19:20:41  <cfields_> gmaxwell: for now.
4792019-04-11T19:20:43  <jeremyrubin> As that can just be treated as a scheduler
4802019-04-11T19:20:44  <gmaxwell> Put it this way, however: I would much rather be linking a upnp library written in rust.
4812019-04-11T19:21:02  <sipa> but i have no interest in seeing bitcoin core becoming developed in a mix of languages
4822019-04-11T19:21:06  <jamesob> sipa: +1
4832019-04-11T19:21:12  <meshcollider> Agreed
4842019-04-11T19:21:26  * cfields_ banishes sipa from the testing framework :p
4852019-04-11T19:21:38  <wumpus> it'd be somewhat confusing, though I'd personally be happy to move away from c++, I've really grown to dislike it
4862019-04-11T19:21:46  <gmaxwell> testing framework being written in another language has a non-trivial cost. (not that I'd suggest otherwise!)
4872019-04-11T19:21:51  <cfields_> (That was a joke, I realize it's not the same thing)
4882019-04-11T19:22:05  <jamesob> cfields_: I'm working on a c++ rewrite as we speak
4892019-04-11T19:22:08  <sipa> wumpus: i realize that; but bitcoin core is a c++ project with c++ reviewers
4902019-04-11T19:22:20  <wumpus> sipa: yes, maybe it means I need to move to rust-bitcoin :-)
4912019-04-11T19:22:49  <cfields_> sipa: i think that's a fair point. But nearly every one of those reviewers that I've poked has mentioned that they'd like to learn rust.
4922019-04-11T19:22:51  <wumpus> anyhow, this is an experiment, I don't think merging it is even a question right now
4932019-04-11T19:22:58  <MarcoFalke> A lot of the reviewers know rust or wouldn't have a problem learning it
4942019-04-11T19:23:17  <gmaxwell> It appears to me that language proliferation is doing a lot of harm to open source communties.... lots of duplication of effort and half abandoned projects just because someone wanted to do the same thing over in another language. :(
4952019-04-11T19:23:21  <sipa> cfields_: sure, i'd like to learn rust; but i'm not going to be an expert in it even when i do to the extent that i'd feel like reviewing production ready code
4962019-04-11T19:23:29  <cfields_> wumpus: right. So the question for now is how to get eyes on it and keep it up to date. I guess we can just maintain it in a branch somewhere?
4972019-04-11T19:23:37  <wumpus> cfields_: yes
4982019-04-11T19:23:38  <meshcollider> Review quality would definitely go down if people are new to the language
4992019-04-11T19:23:42  <luke-jr> gmaxwell: if only everything used the same ABI
5002019-04-11T19:23:43  <cfields_> sipa: very fair point.
5012019-04-11T19:23:43  <jeremyrubin> Expertise in rust is easier to attain than c++
5022019-04-11T19:23:55  <jeremyrubin> The compiler catches most of the stuff you spend time revieiwing in c++ anyways
5032019-04-11T19:24:01  <wumpus> cfields_: as said I'm happy to maintain that branch
5042019-04-11T19:24:39  <gmaxwell> I am skeptical also about this motivation about structurally elimiating bugs, when development in bitcoin core continues to _introduce_ bug in the form of things like memory-unbounded asynchronous layers.
5052019-04-11T19:24:40  <cfields_> wumpus: ok, great, you're welcome to take it over.
5062019-04-11T19:25:08  <wumpus> gmaxwell: concurrent programming should be more straightforward in rust at least
5072019-04-11T19:25:39  <gmaxwell> wumpus: somewhat, but the problems we have like invisible queues that grow unboundedly exist exactly the same in rust.
5082019-04-11T19:25:41  <wumpus> a lot of the boilerplate we're introducing in bitcoin for queues, asyn handling,et c is simply part of rust already
5092019-04-11T19:26:05  <wumpus> gmaxwell: yes, no one is claiming it would eliminate all problems automatically, that would have been great
5102019-04-11T19:26:16  <gmaxwell> It's a lot easier to avoid writing data races, however, indeed
5112019-04-11T19:26:52  <gmaxwell> wumpus: not all problems, of course... but the problems we actually end up shipping.
5122019-04-11T19:26:54  <wumpus> right
5132019-04-11T19:27:29  <wumpus> I really don't know, like if you and sipa are 100% against including rust in bitcoin core, it's a done deal I guess
5142019-04-11T19:27:50  <sipa> i'm not; but it's a discussion to be had when there is code to include
5152019-04-11T19:27:54  <wumpus> yes
5162019-04-11T19:28:01  <gmaxwell> As I said before, I'd be much happier with a rust miniupnp than miniupnp.
5172019-04-11T19:28:04  <jonasschnelli> Let it be an experiment
5182019-04-11T19:28:09  <wumpus> so let's start with miniupnp
5192019-04-11T19:28:14  <gmaxwell> So certantly not 100% against it.
5202019-04-11T19:28:22  <jeremyrubin> I think the point of this PR is that if someone wanted to start exploring, they would have to spend a week just setting up building and linking
5212019-04-11T19:28:26  <wumpus> happy to write that in rust :)
5222019-04-11T19:28:37  <dongcarl> I can get boostrap working
5232019-04-11T19:28:40  <sipa> i'd be even happier with a minimal c++ reimplementation of miniupnp :p
5242019-04-11T19:28:51  <sipa> (but i have no problem with a rust one if it would exist)
5252019-04-11T19:29:07  <wumpus> you really want to make another c++ upnp implementation?
5262019-04-11T19:29:10  <sipa> and it's great that the build system issues are already out of the way
5272019-04-11T19:29:14  <jeremyrubin> So now that we have the demo build, someone can more easily show us motivation
5282019-04-11T19:29:33  <jeremyrubin> It's also good to know that rust work won't be shot down purely on the "another language" basis
5292019-04-11T19:29:36  <gmaxwell> I dunno, I think I'd rather a rust one,  ignoring the build related issues (like rust notes, the blind binary trust in rust toolchains, etc)
5302019-04-11T19:29:54  <wumpus> I'd not be inclined to trust that tbh, even if we wrote it ourselves, we're not perfect either it's not like we'd avoid all the problems in the original one automatically
5312019-04-11T19:30:10  <gmaxwell> jeremyrubin: has the proble of the rust ecosystem where cargo effectively forces you into getting nearly blind updates been resolved?
5322019-04-11T19:30:19  <sipa> i think we have a pretty good track record wrt the kind of bugs that miniupnp has
5332019-04-11T19:30:29  <wumpus> you mean, xml parsing?
5342019-04-11T19:30:35  <sipa> memory safety
5352019-04-11T19:30:48  <wumpus> nah
5362019-04-11T19:31:00  <gmaxwell> jeremyrubin: my expirence at blockstream was that it was very costly to not blindly take new software via cargo... because, yes you can ping versions, but then compiler updates would break deep dependencies, and you'd have to move forward your pins... and often move all of them at once because of interactions.
5372019-04-11T19:31:24  <gmaxwell> s/ping/pin/
5382019-04-11T19:31:28  <jeremyrubin> gmaxwell: I'm not sure? Crates.io is supposed to be append only
5392019-04-11T19:31:31  <sipa> wumpus: how so?
5402019-04-11T19:31:49  <jeremyrubin> gmaxwell: cargo also just added the ability to have your own crate registry, which would help
5412019-04-11T19:31:57  <wumpus> sipa: just having a good track record doesn't guarantee anything
5422019-04-11T19:32:01  <sipa> wumpus: of course
5432019-04-11T19:32:09  <jeremyrubin> gmaxwell: in the PR, I manually pinned the one dep (a build tool to auto-gen headers)
5442019-04-11T19:32:12  <wumpus> it doesn't mean you can do arbitrarily complex things and avoid bugs
5452019-04-11T19:32:13  <gmaxwell> jeremyrubin: append only doesn't help if it doesn't build anymore with new compilers.  (to be fair C++ also has this issue but on a 10x slower timescale)
5462019-04-11T19:32:39  <jeremyrubin> gmaxwell: I think what grin does is not update the compiler -- just fix the version to a known stable or nightly
5472019-04-11T19:33:12  <luke-jr> is it even possible to have multiple versions of Rustc installed on most distros?
5482019-04-11T19:33:14  <gmaxwell> jeremyrubin: yes, thats what we ended up doing at blockstream...  but then that runs into issues when you want to add something else and it depends on a new compiler.
5492019-04-11T19:33:15  <jeremyrubin> gmaxwell: updating to a new compiler can be annoying for anything
5502019-04-11T19:33:25  <jeremyrubin> luke-jr: yes look at the rustup toolchain manager
5512019-04-11T19:33:26  <gmaxwell> luke-jr: the tooling makes it possible to do that, yes.
5522019-04-11T19:33:39  <sipa> wumpus: to be clear, i say i'd prefer a c++ miniupnp because i'd be able to look at it; not because of innate qualities of the language
5532019-04-11T19:33:42  <wumpus> I'm just very skeptical of things like 'if we implemented it it'd be better', I'm sure the author of miniupnp thought the same, he also wanted to make a minimal upnp implementation
5542019-04-11T19:33:52  <jeremyrubin> gmaxwell: yeah -- it's a pity rust is adding so many exciting new features ;)
5552019-04-11T19:33:57  *** cfields_ has quit IRC
5562019-04-11T19:34:02  <wumpus> it's pretty much outside all our expertise
5572019-04-11T19:34:17  <sipa> but the whole question is pointless without an actual package to discuss
5582019-04-11T19:34:22  <wumpus> yes
5592019-04-11T19:34:23  *** cfields has joined #bitcoin-core-dev
5602019-04-11T19:35:02  <wumpus> (this is besides the rust issue btw)
5612019-04-11T19:35:10  <cfields> Sorry, was laggy, had to switch servers.
5622019-04-11T19:35:11  <gmaxwell> So there are essentially two infrastructure issues for using rust stuff for non-optional functionality: (1) bootstraping needing blobs, and (2)  ecosystem very strongly pressuring everyone to take blind software updates (ala JS train wreak).
5632019-04-11T19:35:53  <wumpus> I think using it for non-optional functionality is a bad idea right now
5642019-04-11T19:37:04  <wumpus> agree on gmaxwell's comments re: cargo
5652019-04-11T19:37:05  <cfields> gmaxwell: #1 is unfair and not worth discussing imo unless people are going to scream about us using ubuntu's toolchain as well.
5662019-04-11T19:37:07  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
5672019-04-11T19:37:12  <gmaxwell> for something like a miniupnp, the main argument against using rust is that we might get fewer reviewers (but might get more rust fad-followers to review? so maybe thats a tie),  the main argument I see for it, is that would be nice that there is a class of bugs that miniupnp had many of structurally prevented by the langauge.
5682019-04-11T19:37:43  <luke-jr> cfields: people who build their own bitcoind *don't* need to use Ubuntu's toolchain
5692019-04-11T19:37:44  <gmaxwell> cfields: we do use a toolchain that can be bit identically produced by many hetrogenious toolchains.
5702019-04-11T19:38:15  <jeremyrubin> gmaxwell: for 2, there are a lot of things that could be done w/o external deps
5712019-04-11T19:38:19  <luke-jr> gmaxwell: UPnP might be generic enough that non-Bitcoin devs are interested too
5722019-04-11T19:38:28  <gmaxwell> cfields: in particular we use a gcc binary that I can produce starting from clang.  (and I've independanty produced the compiler on my laptop from a disjoint toolchain)
5732019-04-11T19:38:36  <gmaxwell> luke-jr: exactly.
5742019-04-11T19:39:02  * dongcarl agrees, but needs help
5752019-04-11T19:39:03  <gmaxwell> It's exactly the sort of thing likely to get somewhat broad interest, thats part of why I used it as a positive example.
5762019-04-11T19:39:11  <cfields> Grr, I swore I wasn't going to take the bait on this :p
5772019-04-11T19:39:28  <wumpus> apparently there are already some projects to implement upnp in rust
5782019-04-11T19:39:30  <gmaxwell> cfields: I yield, I don't really need to argue this with you right now.
5792019-04-11T19:39:35  *** EagleTM has joined #bitcoin-core-dev
5802019-04-11T19:39:39  <wumpus> in any case -- let's move to other topics, this isn't so urgent now
5812019-04-11T19:39:46  <jnewbery> Can I quickly get back to #15750?
5822019-04-11T19:39:46  <gmaxwell> cfields: we can agree that there are at least concerns there, even if we disagree how much its really any different.
5832019-04-11T19:39:48  <gribble> https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
5842019-04-11T19:39:59  <wumpus> #topic Remove addresses field in getaddressinfo
5852019-04-11T19:40:03  <jnewbery> The addresses field was marked deprecated in v0.17 along with other changes to validateaddress and getaddressinfo (#10583)
5862019-04-11T19:40:07  <gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
5872019-04-11T19:40:09  <jnewbery> #12490 (V0.18) should have removed the all deprecated functionality (and depracation notes). This part was missed out.
5882019-04-11T19:40:11  <gribble> https://github.com/bitcoin/bitcoin/issues/12490 | [Wallet] [RPC] Remove deprecated wallet rpc features from bitcoin_server by jnewbery · Pull Request #12490 · bitcoin/bitcoin · GitHub
5892019-04-11T19:40:13  <cfields> gmaxwell: oh for sure, this really is just "here, this is possible, see if it's useful". It seems it was taken as more than that.
5902019-04-11T19:40:15  <jnewbery> So #15750 should fully remove it in v0.18.
5912019-04-11T19:40:17  <gribble> https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
5922019-04-11T19:40:19  <gmaxwell> cfields: +1000
5932019-04-11T19:40:25  <gmaxwell> cfields: thanks for bringing it up
5942019-04-11T19:40:30  <jnewbery> I don't think it counts as controversial if some random drops in and says "NEVER CHANGE RPCS". If we let that stop useful changes to Bitcoin Core we'd never do anything.
5952019-04-11T19:40:38  *** ranefer has joined #bitcoin-core-dev
5962019-04-11T19:40:45  <wumpus> jnewbery: I agree
5972019-04-11T19:41:02  <gmaxwell> cfields: also I hope it was useful to the people most interested in using rust to understand the kind of headwinds that are out there.  I don't think we can really have much useful discussion without talking about something specific.
5982019-04-11T19:41:09  <sipa> jnewbery: his comments also seem to be about the move from validateaddress to getaddressinfo in the first place
5992019-04-11T19:41:16  <sipa> which if anything are far too late
6002019-04-11T19:41:32  <luke-jr> jnewbery: "bugfixes only during RCs" is not "NEVER CHANGE RPCS"
6012019-04-11T19:41:32  <gmaxwell> It's unclear to me if he just needs help phrasing his argument.
6022019-04-11T19:41:40  <gmaxwell> But I agree the argument as stated should be ignored.
6032019-04-11T19:41:51  <wumpus> jnewbery: I was just reasoning 'what would it hurt to move this to 0.19', not trying to argue against the change!
6042019-04-11T19:41:52  <jnewbery> Right, I don't think he's concerned about this particular field
6052019-04-11T19:42:05  <wumpus> luke-jr: right
6062019-04-11T19:42:05  <instagibbs> 0.17 breakages were heavier than in the past fwiw
6072019-04-11T19:42:11  <gmaxwell> Sometimes people have a real complaint (like "I use that field, can't easily generate it myself, and you're taking it away") but just don't know how to state it, so we should be sensitive to that.
6082019-04-11T19:42:26  <instagibbs> not complaining, we just have delayed upgrading on some stuff due to it, which is fine
6092019-04-11T19:42:27  <jnewbery> The problem is that the deprecation notice goes away in v0.18
6102019-04-11T19:42:32  <wumpus> gmaxwell: yes, would make sense to add documentation for that
6112019-04-11T19:42:33  <gmaxwell> (life would be better if bug reporters were assigned a lawyer)
6122019-04-11T19:42:45  <sipa> gmaxwell: i'm... not sure
6132019-04-11T19:42:52  <wumpus> (which is also what I noted in the PR)
6142019-04-11T19:42:59  <instagibbs> are we suing people when they file issues :)
6152019-04-11T19:43:11  <MarcoFalke> no, they sue us
6162019-04-11T19:43:12  <gmaxwell> I just mean an advocate who would tell them how to state their issue in a way that makes sense to the process they're addressing.
6172019-04-11T19:43:20  <sipa> ah yes
6182019-04-11T19:43:21  <jnewbery> my point is that we should remove all of the deprecated parts of `deprecatedrpc=validateaddress` in one release or none at all
6192019-04-11T19:43:22  <luke-jr> we can always say "use 0.17 until you're ready" too
6202019-04-11T19:43:42  <achow101> jnewbery: ack
6212019-04-11T19:43:51  <jeremyrubin> instagibbs: is the issue csw not being satoshi
6222019-04-11T19:43:56  <sipa> jnewbery: i agree; but i also think it's a minor enough thing
6232019-04-11T19:44:14  <jnewbery> Yeah, I wouldn't bring it up if we weren't already doing another rc
6242019-04-11T19:44:28  <wumpus> yes, I don't care deeply either way, it just seems to cause a lot of discussion
6252019-04-11T19:45:00  <gmaxwell> when in doubt, add docs.
6262019-04-11T19:45:32  <wumpus> yes
6272019-04-11T19:46:17  <sipa> oh quick topic: there has been a bunch of improvements to https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft lately (thanks, harding); people may want to look over it before it becomes a last-minute thing before release
6282019-04-11T19:46:24  <gmaxwell> in any case, we should also consider it a good sign that we're getting compat complaints now.  None is the wrong number.
6292019-04-11T19:46:25  <wumpus> anyhow added "needs backport" for now
6302019-04-11T19:46:36  <jnewbery> wumpus: thanks!
6312019-04-11T19:46:38  <gmaxwell> sipa: thanks, will do
6322019-04-11T19:47:29  <sipa> achow101: in particular, i think the new psbt descriptions could use slightly more text
6332019-04-11T19:47:29  <wumpus> sipa: good idea
6342019-04-11T19:47:33  <sipa> *new psbt rpcs
6352019-04-11T19:47:55  <achow101> sipa: I can take a look at those
6362019-04-11T19:48:03  <wumpus> yes, as a general concept, documentation belongs in the doc/ folder, not in the release notes, could always add a link :)
6372019-04-11T19:48:25  <sipa> so also have a look at the updates in doc/psbt.md :p
6382019-04-11T19:48:58  <wumpus> it's good to meantion things in the release notes but indeed not to be too wordy
6392019-04-11T19:49:05  <wumpus> ok, cfields had another topic
6402019-04-11T19:49:15  <wumpus> #topic Platform deprecation (cfields)
6412019-04-11T19:49:18  <wumpus> sipa: will do
6422019-04-11T19:49:29  <cfields> We don't (afaik?) have any means of deprecating old platforms. Many of the TODOs left for rust integration revolve around pretty old/unused platforms. I'm not suggesting that we drop platforms just because rust may be integrated at some point in the future, only that now seems like a reasonable time to re-evaluate. I originally planned to do the work to hack together fixes either here or upstream, but it's worth asking first: are these
6432019-04-11T19:49:29  <cfields> platforms worth the effort?
6442019-04-11T19:49:38  <cfields> The actual issues are documented in the PR. In particular, the troubled platforms are 32bit Windows and glibc < 2.15. glibc distro versions (unverified google hit) can be seen here: https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa45b1
6452019-04-11T19:49:41  <wumpus> which platform?
6462019-04-11T19:50:17  <sipa> are all newly sold x86 CPUs these days 64-bit?
6472019-04-11T19:50:29  <wumpus> yess since 2005 or so?
6482019-04-11T19:50:37  <sipa> and do people run 64-bit OSes on them?
6492019-04-11T19:50:43  <cfields> sipa: I would think anything running windows especially.
6502019-04-11T19:50:45  <wumpus> for windows: yes
6512019-04-11T19:50:46  <sipa> (i have no clue about the windows ecosystem in this regard)
6522019-04-11T19:50:47  <gmaxwell> yes, though all still also capable of running in 32bit mode.
6532019-04-11T19:50:50  <luke-jr> cfields: AFAIK current policy is to freely drop support for all but the most recent stable release of major distros; I assume none of them use glibc <2.15 ?
6542019-04-11T19:51:14  <gmaxwell> for a long time people were still installing new systems as 32-bit but I think thats finally stopped as of about two years ago.
6552019-04-11T19:51:26  <cfields> luke-jr: see link above, I don't recall off the top of my head.
6562019-04-11T19:51:43  <gmaxwell> (e.g. two-ish years ago the default fedora download was 32-bit, in part because of compatiblity with #$@# binary only browser extensions)
6572019-04-11T19:51:50  <wumpus> 100% behind deprecating windows 32-bit
6582019-04-11T19:52:17  <jonasschnelli> me 2
6592019-04-11T19:52:41  <gmaxwell> unfortunately we don't run that well on 32-bit in any case,  I'm not currently aware of a reason we shouldn't depricate windows 32-bit but I am not a windows expert. :)
6602019-04-11T19:52:42  <wumpus> I've tried to raise the issue two years ago (or so?) and maybe one person complained on twitter, who was in the process of migrating things to a 64-bit OS later that year so…
6612019-04-11T19:52:46  <jonasschnelli> just don't deprecate the ARM 32bits
6622019-04-11T19:52:51  <wumpus> oh no not ARM
6632019-04-11T19:52:53  <wumpus> I mean x86
6642019-04-11T19:52:55  <cfields> jonasschnelli: right.
6652019-04-11T19:52:59  <wumpus> windows
6662019-04-11T19:53:07  *** bitcoin-git has joined #bitcoin-core-dev
6672019-04-11T19:53:07  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15799: doc: Clarify RPC versioning (master...1904-docRPC) https://github.com/bitcoin/bitcoin/pull/15799
6682019-04-11T19:53:08  *** bitcoin-git has left #bitcoin-core-dev
6692019-04-11T19:53:15  <meshcollider> Does that clean up any existing windows-only code or just for later
6702019-04-11T19:53:31  <wumpus> and for 0.19
6712019-04-11T19:53:49  <achow101> Windows does have 32 bit version still
6722019-04-11T19:53:51  <wumpus> meshcollider: I don't think it cleans up any code tbh
6732019-04-11T19:54:03  <cfields> Great, that was easy :)
6742019-04-11T19:54:04  <wumpus> it just leaves oneless configuration to maintain and test
6752019-04-11T19:54:06  <wumpus> which is good
6762019-04-11T19:54:15  <jeremyrubin> Is anyone even testing 32-bit windows?
6772019-04-11T19:54:18  <wumpus> no.
6782019-04-11T19:54:22  <jonasschnelli> I do
6792019-04-11T19:54:26  <cfields> wumpus: it's also the one that takes _forever_ to run.
6802019-04-11T19:54:26  <wumpus> oh!
6812019-04-11T19:54:31  <jonasschnelli> (VM though)
6822019-04-11T19:54:37  <luke-jr> maybe we should solicit feedback somehow?
6832019-04-11T19:54:42  <gmaxwell> 12:52:42 < wumpus> I've tried to raise the issue two years ago (or so?) and maybe one person complained on twitter, who was in the process of
6842019-04-11T19:54:47  <gmaxwell> ^ fantastic!
6852019-04-11T19:54:47  <luke-jr> open an issue to deprecate Win32, and put it in release notes?
6862019-04-11T19:55:05  <gmaxwell> luke-jr: I don't disagree but it also sounds like wumpus already did previously.
6872019-04-11T19:55:16  <wumpus> I mean we already dropped xp and vista support, which are the most likely to be 32 bit
6882019-04-11T19:55:21  <luke-jr> gmaxwell: a tweet isn't as loud as release notes
6892019-04-11T19:55:32  <sipa> luke-jr: i suspect more people read tweets :p
6902019-04-11T19:55:38  <luke-jr> sipa: could be :/
6912019-04-11T19:55:41  <sipa> (but maybe less relevant ones)
6922019-04-11T19:55:49  <cfields> sipa: haha
6932019-04-11T19:55:51  <sipa> windows 10 still has a 32-bit version it seems
6942019-04-11T19:56:01  <wumpus> windows 7/8 was already mostly 64-bit, windows 10 certainly
6952019-04-11T19:56:06  <wumpus> yes it exists but no one uses it
6962019-04-11T19:56:11  <luke-jr> sipa: how many people use it?
6972019-04-11T19:56:11  <sipa> okay.
6982019-04-11T19:56:25  <sipa> luke-jr: i have no clue!
6992019-04-11T19:56:27  *** bitcoin-git has joined #bitcoin-core-dev
7002019-04-11T19:56:27  <bitcoin-git> [bitcoin] jnewbery opened pull request #15800: [rpc] Remove the addresses field from the getaddressinfo return object (0.18...2019_04_remove_address_from_getaddressinfo_0.18) https://github.com/bitcoin/bitcoin/pull/15800
7012019-04-11T19:56:29  *** bitcoin-git has left #bitcoin-core-dev
7022019-04-11T19:56:42  <luke-jr> I'm sure Microsoft does :P
7032019-04-11T19:57:31  <luke-jr> maybe we could just neglect to post the Win32 binaries for 0.18 and see who complains?\
7042019-04-11T19:57:50  <wumpus> the kind of CPUs that only run 32-bit don't really run bitcoin, you'd be better off with a rpi at that point
7052019-04-11T19:57:57  <wumpus> +x86
7062019-04-11T19:57:58  <luke-jr> that way we can always upload them later if it's a problem
7072019-04-11T19:58:13  <meshcollider> Seems sensible
7082019-04-11T19:58:26  <wumpus> luke-jr: good idea
7092019-04-11T19:58:29  <wumpus> :D
7102019-04-11T19:58:39  <gmaxwell> 12:57:31 < luke-jr> maybe we could just neglect to post the Win32 binaries for 0.18 and see who complains?\
7112019-04-11T19:58:42  <gmaxwell> ^ I'd +1 that too
7122019-04-11T19:58:48  <instagibbs> wumpus, fwiw they croak when trying to run secp-zkp benchmarks too
7132019-04-11T19:58:51  <gmaxwell> that would be a nice way of measuring usage.
7142019-04-11T19:59:04  <wumpus> yes, let's do that
7152019-04-11T19:59:13  <wumpus> instagibbs: whoops
7162019-04-11T19:59:21  <harding> I'm not sure if people are serious, but if you are, please let me know in advance.  The BitcoinCore.org site tests check for missing binaries.
7172019-04-11T19:59:24  * luke-jr glares at the clock
7182019-04-11T19:59:27  <gmaxwell> if people complain about the binaries, then we can just go ahead and post them.
7192019-04-11T19:59:34  <instagibbs> harding, is that a complaint ;)
7202019-04-11T19:59:36  <wumpus> #endmeeting
7212019-04-11T19:59:36  <lightningbot> Meeting ended Thu Apr 11 19:59:36 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7222019-04-11T19:59:36  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-11-19.00.html
7232019-04-11T19:59:36  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-11-19.00.txt
7242019-04-11T19:59:36  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-11-19.00.log.html
7252019-04-11T19:59:40  <gmaxwell> harding: I think we're being serious.
7262019-04-11T19:59:43  <wumpus> harding: we're serious
7272019-04-11T19:59:52  <harding> Ok.  I'll disable the test for win32
7282019-04-11T19:59:54  <luke-jr> sipa: still here? can you post on --disable-asm issue?
7292019-04-11T20:00:09  <gmaxwell> harding: We don't believe 32-bit windows is getting any substantial usage, we have no real way to tell... one way to tell would be to just not post binaries until someone complaints.
7302019-04-11T20:00:10  <luke-jr> maybe we can rename it --disable-code-optimisations if you really don't like calling it asm
7312019-04-11T20:00:23  <sipa> luke-jr: or split it up
7322019-04-11T20:00:44  <gmaxwell> luke-jr: --boring-compiler
7332019-04-11T20:00:53  <luke-jr> gmaxwell: that sounds like autotools mess
7342019-04-11T20:01:19  <gmaxwell> There are two kinds of motivations that trigger wanting to disable asm: one is you're using an old/weird/limited/customized toolchain that can't handle them...
7352019-04-11T20:01:20  <harding> gmaxwell: right, I understand what's being discussed.  It just seems a bit weird to me.  I don't actually care though, except that wumpus doesn't have to debug a travis failure on BitcoinCore.org at the last minute when he's trying to release 0.18.
7362019-04-11T20:01:24  <sipa> luke-jr: i think i don't really care enough to argue :)
7372019-04-11T20:01:31  <gmaxwell> the other is you're worried someone messed up the handcoded asm and introduced bugs
7382019-04-11T20:01:49  <luke-jr> gmaxwell: another might be if you have some very interesting compiler you don't want asm to bypass?
7392019-04-11T20:02:03  <luke-jr> sipa: well, apparently your last comment is being treated as a blocker :P
7402019-04-11T20:02:59  <MarcoFalke> Looks like a rename will please sipa
7412019-04-11T20:03:45  <sipa> wumpus: btw, i shouldn't have brought up the rust vs c++ in context of miniupnp; i'm skeptical about a push for rust code, but if there was a upnp replacement in rust with reasonable assurances about production readiness, i'd be all for it
7422019-04-11T20:03:48  <luke-jr> release notes: I don't understand the change described in "Deprecated P2P messages"
7432019-04-11T20:04:01  <BlueMatt> do we have download counts/should we monitor download counts?
7442019-04-11T20:04:26  <luke-jr> BlueMatt: I have been fetching download counts from the PPA for a few releases now
7452019-04-11T20:04:38  <BlueMatt> that doesnt help much for 32-bit windows :p
7462019-04-11T20:04:54  <luke-jr> ah
7472019-04-11T20:05:40  <wumpus> so I"m removing two files from the upload: bitcoin-${VERSIONTO}-win32.zip and bitcoin-${VERSIONTO}-win32-setup.exe
7482019-04-11T20:05:52  <wumpus> @ harding
7492019-04-11T20:05:56  <luke-jr> wumpus: well, I expect we should still build/sign them, just not upload
7502019-04-11T20:06:11  <wumpus> luke-jr: that's what I'm saing
7512019-04-11T20:06:15  <luke-jr> k
7522019-04-11T20:06:25  <wumpus> not changing the gitian descriptor
7532019-04-11T20:06:56  <wumpus> can do that for 0.19
7542019-04-11T20:07:09  <luke-jr> can I put FIXME notes in the relnote wiki?
7552019-04-11T20:07:10  <harding> wumpus: received.  Thanks; I've already patched the test and will include it with the ready-for-release PR I'm opening today.
7562019-04-11T20:07:22  <luke-jr> or is there a better place for that?
7572019-04-11T20:07:24  <wumpus> harding: thanks!
7582019-04-11T20:07:52  <wumpus> luke-jr: only if you intend to make the fixes yourself before final, I guess
7592019-04-11T20:08:00  <luke-jr> wumpus: I'd just make the fixes, if I knew what they should be
7602019-04-11T20:08:08  <luke-jr> wumpus: the problem is I have no idea what changed :P
7612019-04-11T20:08:41  <luke-jr> (which IMO indicates the release note is insufficient in describing the change)
7622019-04-11T20:09:08  <wumpus> would be kind of awkaard to accidentally get people's fixme's and random notes *for the release notes* into the release notes
7632019-04-11T20:09:35  <harding> luke-jr: do you think it should be moved to the Planned Changes section?
7642019-04-11T20:09:39  <wumpus> sipa: makes sense
7652019-04-11T20:09:46  <luke-jr> harding: if that's all it is.
7662019-04-11T20:10:09  <harding> luke-jr: I didn't write that note, but I'm guessing it's there because we planned to disable it by default in this release and then backpeddled to planning to disable it by default next release.
7672019-04-11T20:10:24  <luke-jr> hm, that would make sense
7682019-04-11T20:11:57  <luke-jr> yeah, I'm not seeing anything else in the git log
7692019-04-11T20:12:51  <harding> I think the previous discussion was that we don't actually have any way to indicate that a P2P message is deprecated besides creating a release note.
7702019-04-11T20:14:20  <luke-jr> heh, there's already a TODO in there
7712019-04-11T20:15:20  <wumpus> a BIP would be the expected way I think
7722019-04-11T20:16:00  <luke-jr> dunno, this is just Core deciding not to support a BIP
7732019-04-11T20:16:11  <wumpus> true
7742019-04-11T20:16:19  <wumpus> it's a bit of a grey area in this case
7752019-04-11T20:17:09  <jnewbery> This was added after the meeting on March 14: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-14-19.00.log.html#l-132
7762019-04-11T20:17:50  <gmaxwell> We often decide to not support bips, less often decide to remove bips.
7772019-04-11T20:18:32  <wumpus> but I mean, theoretically a BIP could describe the reasons for not supporting a BIP anymore, for reconsidering its use
7782019-04-11T20:18:58  <luke-jr> gmaxwell: sure, but it's still an application-specific thing
7792019-04-11T20:19:10  <sipa> wumpus: i guess that would make sense if we believe there is a reason why others should also not support something
7802019-04-11T20:19:32  <wumpus> sipa: yes
7812019-04-11T20:19:34  <sipa> it's a proposal for improvement; if not supporting cam be argued to be an improvement, it deserves being a bip
7822019-04-11T20:19:36  <gmaxwell> Right, someone might want to make a case for "no one should support this"
7832019-04-11T20:19:38  <wumpus> so things like 'bandwidth overhead'
7842019-04-11T20:19:59  <wumpus> or potential privacy leaks
7852019-04-11T20:20:11  <luke-jr> gmaxwell: seems like a case for BIP Comments ;)
7862019-04-11T20:20:50  <gmaxwell> though some of the arguments are just structural, like in general returning normative or somewhat normative error codes imposes significant architecural obligations.
7872019-04-11T20:21:16  *** timothy has quit IRC
7882019-04-11T20:21:37  <gmaxwell> As a general principle, tests should be able to test all visible network behavior....   and refactoring your code shouldn't break tests ...  returning errors can make otherwise clean abstractions unclean.
7892019-04-11T20:30:23  <cfields> meshcollider: Were you going to look at getting rid of some of the win32 stuff?
7902019-04-11T20:30:42  <cfields> (if any)
7912019-04-11T20:31:09  <wumpus> I'm surprised qt still supports win32
7922019-04-11T20:31:45  <wumpus> though ok, qt is commonly used on embedded hardware so also not that surprised
7932019-04-11T20:31:58  <luke-jr> portability is (was?) kind of Qt's main selling point
7942019-04-11T20:33:57  <cfields> Yeah, I bet there's still a ton of embedded win32 stuff out there.
7952019-04-11T20:36:10  <cfields> I used embedded winxp in some microscope equipment at one point, that was wacky.
7962019-04-11T20:43:21  <luke-jr> but Qt did drop WinXP right?
7972019-04-11T20:43:32  <cfields> meshcollider: If you do take a look, I'd request that we maintain the multi-windows machinery and not just squash down to "windows" as a platform. That way we don't have to start all over if they pivot to some new arch.
7982019-04-11T20:44:22  <cfields> Basically, I'd suggest not doing something like s/#ifdef win64/#ifdef windows/.
7992019-04-11T20:45:11  <luke-jr> yeah, since ppc64 is taking over /s
8002019-04-11T20:45:35  <cfields> Heh
8012019-04-11T20:45:48  <cfields> I was thinking more like their 10th attempt at an arm platform.
8022019-04-11T20:46:31  <wumpus> windows rv64 would be a cursed combo
8032019-04-11T20:46:55  <wumpus> so I think it'll happen at some point
8042019-04-11T20:47:05  <cfields> lol
8052019-04-11T20:49:16  <luke-jr> as if RISC-V isn't wide open to being closed down
8062019-04-11T20:50:01  <cfields> gotta gotta get up to get down.
8072019-04-11T20:50:15  <gmaxwell> More likely to see google or oracle produce a embrace-and-extent RV than msft these days. :P
8082019-04-11T20:51:44  <cfields> gmaxwell: fuchsia seems poised to help with that.
8092019-04-11T20:52:48  *** jarthur has quit IRC
8102019-04-11T20:55:03  *** Guyver2 has quit IRC
8112019-04-11T20:57:17  <wumpus> google is definitely looking into RISC-V https://twitter.com/Kensan42/status/1110612910999511041
8122019-04-11T20:59:03  <wumpus> RISCV-CHERI is pretty interesting
8132019-04-11T20:59:15  <gmaxwell> oh is someone actually doing riscv-cheri now?!!?!?!
8142019-04-11T20:59:37  <gmaxwell> I was bummed when riscv didn't include cheri like features from day one, though I understood why...
8152019-04-11T21:03:15  <wumpus> right, would have been too complicated and experimental I think, but it might be part of the rationale behind RV128
8162019-04-11T21:08:53  <gmaxwell> ISTM its really hard to really compete with intel/amd x86_64 duooply for raw performance... basically only ppc does. But it would be easy to smoke x86_64 on security, and I think there are a lot of applications where even the in-order arms are fast enough, but more security would be desirable.
8172019-04-11T21:11:56  <wumpus> right, one exciting thing about RISC-V is that it allows for experimentation like that, it's no longer restricted to what AMD and Intel or ARM think as feasible commercially
8182019-04-11T21:12:56  <wumpus> a lot of things don't really don't need that much performance, or, if they do, it's better served using some FPGA or custom ASIC
8192019-04-11T21:14:36  <wumpus> also because it can give actual timing guarantees
8202019-04-11T21:16:02  <anddam> has issue #1390 ever been discussed again since 2012?
8212019-04-11T21:16:03  <gribble> https://github.com/bitcoin/bitcoin/issues/1390 | Comply with the XDG Base Directory Specification · Issue #1390 · bitcoin/bitcoin · GitHub
8222019-04-11T21:16:05  <wumpus> anyhow I hope CHERI will see more adoption, it's a lot more thorough approach than trying to manually sandbox every single thing
8232019-04-11T21:17:24  <wumpus> anddam: no, I don't think so, though some options have been added since to put different things in different dirs
8242019-04-11T21:18:06  <anddam> like --datadir, --wallet and the config file one?
8252019-04-11T21:18:32  <wumpus> yes and -blocksdir
8262019-04-11T21:18:48  <wumpus> -walletdir
8272019-04-11T21:19:03  <anddam> have there been rewrites of bitcoin-core in other languages?
8282019-04-11T21:19:04  <wumpus> it's very flexible where to put things
8292019-04-11T21:19:53  <anddam> wumpus: option in a config is what I ended doing, along with the small desktop file change to pass --datadir, I do not like program that write dotfiles in home, ls -a quickly becomes a mess
8302019-04-11T21:20:59  *** promag has quit IRC
8312019-04-11T21:21:35  <wumpus> it can also be useful because of backups, put the blocks on a large more-or-less throw-away partition, but the wallets in a secure place
8322019-04-11T21:34:36  *** DeanGuss has joined #bitcoin-core-dev
8332019-04-11T21:51:35  *** benthecarman has joined #bitcoin-core-dev
8342019-04-11T21:54:27  <anddam> wumpus: yep
8352019-04-11T21:54:45  <anddam> wumpus: when starting bitcoin-qt does a separate bitcoind process get spawnd?
8362019-04-11T21:54:54  <anddam> (I cannot start bitcoin-qt right now to check)
8372019-04-11T21:55:04  <anddam> I wonder how detached the Qt GUI and bitcoin core are
8382019-04-11T21:55:31  <sipa> anddam: no, one process
8392019-04-11T21:56:24  <anddam> ouch
8402019-04-11T21:56:33  <anddam> so not very detached
8412019-04-11T21:58:15  *** benthecarman_ has joined #bitcoin-core-dev
8422019-04-11T21:59:14  *** benthecarman has quit IRC
8432019-04-11T21:59:38  *** benthecarman has joined #bitcoin-core-dev
8442019-04-11T22:01:28  *** benthecarman_ has quit IRC
8452019-04-11T22:01:33  *** benthecarman has quit IRC
8462019-04-11T22:04:57  *** benthecarman has joined #bitcoin-core-dev
8472019-04-11T22:04:59  *** benthecarman has quit IRC
8482019-04-11T22:05:08  *** benthecarman has joined #bitcoin-core-dev
8492019-04-11T22:09:17  *** gelmutshmidt has quit IRC
8502019-04-11T22:18:59  *** DeanGuss has quit IRC
8512019-04-11T22:19:30  *** DeanGuss has joined #bitcoin-core-dev
8522019-04-11T22:22:27  *** spinza has quit IRC
8532019-04-11T22:24:37  *** DeanGuss has quit IRC
8542019-04-11T22:24:41  *** EagleTM has quit IRC
8552019-04-11T22:30:16  *** Zenton has quit IRC
8562019-04-11T22:45:34  *** bitcoin-git has joined #bitcoin-core-dev
8572019-04-11T22:45:34  <bitcoin-git> [bitcoin] madeken closed pull request #15752: Remove redundant shuffle in KnapsackSolver (master...master) https://github.com/bitcoin/bitcoin/pull/15752
8582019-04-11T22:45:35  *** bitcoin-git has left #bitcoin-core-dev
8592019-04-11T22:46:29  *** captjakk has joined #bitcoin-core-dev
8602019-04-11T22:48:54  *** owowo has quit IRC
8612019-04-11T22:53:55  *** riperk has joined #bitcoin-core-dev
8622019-04-11T23:06:49  *** spinza has joined #bitcoin-core-dev
8632019-04-11T23:21:37  *** promag has joined #bitcoin-core-dev
8642019-04-11T23:21:42  *** hardforkthis has quit IRC
8652019-04-11T23:21:42  *** harding has quit IRC
8662019-04-11T23:21:42  *** dqx__ has quit IRC
8672019-04-11T23:21:42  *** emilr has quit IRC
8682019-04-11T23:21:42  *** davec has quit IRC
8692019-04-11T23:21:42  *** gwillen has quit IRC
8702019-04-11T23:21:42  *** dgenr8 has quit IRC
8712019-04-11T23:21:42  *** Madars has quit IRC
8722019-04-11T23:21:42  *** jasonzhouu has quit IRC
8732019-04-11T23:26:28  *** promag has quit IRC
8742019-04-11T23:27:56  *** hardforkthis has joined #bitcoin-core-dev
8752019-04-11T23:27:56  *** harding has joined #bitcoin-core-dev
8762019-04-11T23:27:56  *** dqx__ has joined #bitcoin-core-dev
8772019-04-11T23:27:56  *** emilr has joined #bitcoin-core-dev
8782019-04-11T23:27:56  *** davec has joined #bitcoin-core-dev
8792019-04-11T23:27:56  *** gwillen has joined #bitcoin-core-dev
8802019-04-11T23:27:56  *** dgenr8 has joined #bitcoin-core-dev
8812019-04-11T23:27:56  *** Madars has joined #bitcoin-core-dev
8822019-04-11T23:27:56  *** jasonzhouu has joined #bitcoin-core-dev
8832019-04-11T23:36:54  *** TheV01d_ has quit IRC
8842019-04-11T23:37:18  *** TheV01d_ has joined #bitcoin-core-dev
8852019-04-11T23:38:25  <luke-jr> fwiw, found a (minor?) bug in 0.18
8862019-04-11T23:39:18  <sipa> luke-jr: impossible!
8872019-04-11T23:39:30  <sipa> (because 0.18 does not exist yet)
8882019-04-11T23:41:25  <luke-jr> 0.18 != 0.18.0
8892019-04-11T23:44:38  <sipa> ah!
8902019-04-11T23:49:13  *** bitcoin-git has joined #bitcoin-core-dev
8912019-04-11T23:49:14  <bitcoin-git> [bitcoin] luke-jr opened pull request #15801: Bugfix: GUI: Options: Initialise prune setting range before loading current value, and remove upper bound limit (master...bugfix_gui_prune_range) https://github.com/bitcoin/bitcoin/pull/15801
8922019-04-11T23:49:15  *** bitcoin-git has left #bitcoin-core-dev