1 2019-04-11T00:05:05  *** bushstar has quit IRC
  2 2019-04-11T00:15:21  <achow101> jnewbery: yeah, i've been seeing that pretty often
  3 2019-04-11T00:17:29  *** ghost43 has quit IRC
  4 2019-04-11T00:25:47  *** ghost43 has joined #bitcoin-core-dev
  5 2019-04-11T00:30:17  *** DougieBot5000_ has joined #bitcoin-core-dev
  6 2019-04-11T00:32:15  *** DougieBot5000 has quit IRC
  7 2019-04-11T00:32:16  *** Cory has quit IRC
  8 2019-04-11T00:32:16  *** hardforkthis has quit IRC
  9 2019-04-11T00:32:16  *** spinza has quit IRC
 10 2019-04-11T00:32:17  *** shtirlic has quit IRC
 11 2019-04-11T00:32:26  *** hardforkthis has joined #bitcoin-core-dev
 12 2019-04-11T00:32:39  *** shtirlic has joined #bitcoin-core-dev
 13 2019-04-11T00:32:56  *** rafalcpp has quit IRC
 14 2019-04-11T00:33:39  *** rafalcpp has joined #bitcoin-core-dev
 15 2019-04-11T00:34:51  *** CubicEarth has quit IRC
 16 2019-04-11T00:35:16  *** DeanGuss has joined #bitcoin-core-dev
 17 2019-04-11T00:37:01  *** CubicEarth has joined #bitcoin-core-dev
 18 2019-04-11T00:37:23  *** spinza has joined #bitcoin-core-dev
 19 2019-04-11T00:38:53  *** Cory has joined #bitcoin-core-dev
 20 2019-04-11T00:41:59  *** Jackielove4u has quit IRC
 21 2019-04-11T01:04:52  *** DougieBot5000_ is now known as DougieBot5000
 22 2019-04-11T01:06:29  *** booyah has quit IRC
 23 2019-04-11T01:22:54  *** promag has joined #bitcoin-core-dev
 24 2019-04-11T01:27:00  *** promag has quit IRC
 25 2019-04-11T01:28:49  *** fanquake has joined #bitcoin-core-dev
 26 2019-04-11T01:33:43  *** egp__ has quit IRC
 27 2019-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
 28 2019-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...
 29 2019-04-11T02:05:50  <wumpus> gmaxwell: thanks!
 30 2019-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
 31 2019-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)
 32 2019-04-11T02:14:09  *** dviola has quit IRC
 33 2019-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?
 34 2019-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...
 35 2019-04-11T02:15:45  <wumpus> no, I don't think so--it has always only supported SOCKS4A and SOCKS5 which both support name addresses
 36 2019-04-11T02:15:48  <wumpus> exactly ^^
 37 2019-04-11T02:16:09  <wumpus> that's the problem, you can connect to a name but you never learn the underlying address
 38 2019-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)
 39 2019-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
 40 2019-04-11T02:17:25  <dongcarl> Ah I see, so the proxy does the lookup and you don't get any transparency in that
 41 2019-04-11T02:17:43  <wumpus> yes
 42 2019-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?
 43 2019-04-11T02:19:37  <wumpus> right
 44 2019-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
 45 2019-04-11T02:32:20  <wumpus> (it could still default to ./bitcoin-cli ofc)
 46 2019-04-11T02:33:12  * luke-jr wonders how many people just curl and run the script blindly
 47 2019-04-11T02:40:06  <wumpus> I definitely don't run it blindly
 48 2019-04-11T03:02:05  *** bushstar has joined #bitcoin-core-dev
 49 2019-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.
 50 2019-04-11T03:24:29  <luke-jr> I didn't mean to imply anyone *here* would run it blindly :x
 51 2019-04-11T03:28:01  <gmaxwell> luke-jr: perhaps I should make the first line of the file a sleep 10000000
 52 2019-04-11T03:30:03  *** ranefer has joined #bitcoin-core-dev
 53 2019-04-11T03:32:34  <luke-jr> heh
 54 2019-04-11T03:33:45  <luke-jr> do modern x86 systems still have PC speakers? maybe make it play a rickroll before that ;)
 55 2019-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.
 56 2019-04-11T03:46:11  *** Eagle[TM] has joined #bitcoin-core-dev
 57 2019-04-11T03:48:22  *** EagleTM has quit IRC
 58 2019-04-11T03:56:21  *** chriswang2019 has joined #bitcoin-core-dev
 59 2019-04-11T04:04:49  *** chriswang2019 has quit IRC
 60 2019-04-11T04:23:20  <TD-Linux> luke-jr, they do, but it may be emulated in various ways (maybe even with smm)
 61 2019-04-11T04:27:02  <sipa>  /me has fond memories of the PLAY command in GW-BASIC
 62 2019-04-11T04:28:49  * luke-jr has Linux software to emulate the BASIC PLAY command <.<
 63 2019-04-11T04:29:13  <luke-jr> turns out there's actually a spec for it called MML
 64 2019-04-11T04:59:59  *** bushstar has quit IRC
 65 2019-04-11T05:07:07  *** pinheadmz has joined #bitcoin-core-dev
 66 2019-04-11T05:12:03  *** ranefer has quit IRC
 67 2019-04-11T05:45:43  *** bitcoin-git has joined #bitcoin-core-dev
 68 2019-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
 69 2019-04-11T05:45:51  *** bitcoin-git has left #bitcoin-core-dev
 70 2019-04-11T05:57:21  *** rex4539 has quit IRC
 71 2019-04-11T06:09:58  *** rex4539 has joined #bitcoin-core-dev
 72 2019-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
 73 2019-04-11T06:15:26  <emilr> added with addnode, connect has the same behaviour)
 74 2019-04-11T06:26:32  *** Eagle[TM] has quit IRC
 75 2019-04-11T06:38:17  <emilr> wumpus: sed -e 's|./bitcoin-cli|ANYTHING -you -want|g' banlist.cli.txt
 76 2019-04-11T06:44:01  *** booyah has joined #bitcoin-core-dev
 77 2019-04-11T06:44:24  *** Jackielove4u has joined #bitcoin-core-dev
 78 2019-04-11T06:47:05  <gmaxwell> emilr: why do you say that it doesn't learn
 79 2019-04-11T06:47:51  *** ccdle12 has joined #bitcoin-core-dev
 80 2019-04-11T07:02:45  *** chriswang2019 has joined #bitcoin-core-dev
 81 2019-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
 82 2019-04-11T07:05:01  <gmaxwell> 97k is far from empty there aren't that many onion peers.
 83 2019-04-11T07:05:11  <gmaxwell> so that part isn't interesting.
 84 2019-04-11T07:06:22  <gmaxwell> any chance you have automatic connections disabled?  how is "it can't connect to anything except .onions" accomplished?
 85 2019-04-11T07:06:54  *** promag has joined #bitcoin-core-dev
 86 2019-04-11T07:08:05  <emilr> onlynet=onion and bitcoin user is blocked from making connections to the clearnet
 87 2019-04-11T07:10:47  *** pinheadmz has quit IRC
 88 2019-04-11T07:11:21  <emilr> also tor is configured with SocksPort 9050 OnionTrafficOnly
 89 2019-04-11T07:13:38  <gmaxwell> emilr: is it logging attempts to connect to things?
 90 2019-04-11T07:19:36  *** chriswang2019 has quit IRC
 91 2019-04-11T07:23:26  *** promag has quit IRC
 92 2019-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
 93 2019-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
 94 2019-04-11T07:35:21  <gmaxwell> emilr: if it's onlynet=onion it'll only store onion peers
 95 2019-04-11T07:38:19  <wumpus> right, it discovers only .onion if that't the only enabled network
 96 2019-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
 97 2019-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 ?
 98 2019-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
 99 2019-04-11T07:44:47  <wumpus> onlynet=tor works too, it's equivalent
100 2019-04-11T07:45:17  <DeanGuss> huh.  ok, I thought it didn't but I only tried a few releases ago
101 2019-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
102 2019-04-11T07:50:36  <wumpus> (onlynet isn't mentioned in doc/tor.md btw; would make sense to do so)
103 2019-04-11T08:18:26  *** ccdle12 has quit IRC
104 2019-04-11T08:18:36  *** ccdle12 has joined #bitcoin-core-dev
105 2019-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.
106 2019-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
107 2019-04-11T08:27:59  <jonasschnelli> what could be the reason for a null leveldb obfuscation key?
108 2019-04-11T08:28:10  <jonasschnelli> Using obfuscation key for /btc/data/bitcoin/blocks/index: 0000000000000000
109 2019-04-11T08:31:47  *** setpill has joined #bitcoin-core-dev
110 2019-04-11T08:34:55  *** timothy has joined #bitcoin-core-dev
111 2019-04-11T08:35:26  <wumpus> jonasschnelli: the block index isn't obfuscated is it? just the utxo set
112 2019-04-11T08:36:21  <jonasschnelli> wumpus: Oh. NM. I missread it (was confused by an empty key)
113 2019-04-11T08:37:57  *** ccdle12 has quit IRC
114 2019-04-11T08:38:31  *** ccdle12 has joined #bitcoin-core-dev
115 2019-04-11T08:40:16  <kallewoof> wumpus: Oh, okay. Thanks
116 2019-04-11T08:44:17  *** fanquake has quit IRC
117 2019-04-11T08:44:46  <wumpus> kallewoof: I think the only commonality is that it both involves some kind of loop for key-stretching
118 2019-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.
119 2019-04-11T08:52:35  *** promag has joined #bitcoin-core-dev
120 2019-04-11T08:53:07  <wumpus> it uses a standard mechanism at least
121 2019-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
122 2019-04-11T09:04:28  <kallewoof> I won't! Thanks
123 2019-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
124 2019-04-11T09:19:44  <wumpus> huh, I believe we didn't update the hardcoded seeds for 0.18
125 2019-04-11T09:20:57  <wumpus> emilr: it shouldn't hold up network negotiation on disk access, does it time out on something?
126 2019-04-11T09:25:49  *** bitcoin-git has joined #bitcoin-core-dev
127 2019-04-11T09:25:49  <bitcoin-git> [bitcoin] MeshCollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6a135fbe5b30...f6120d40d583
128 2019-04-11T09:25:50  <bitcoin-git> bitcoin/master 7a9046e John Newbery: [wallet] Refactor CWalletTx::RelayWalletTransaction()
129 2019-04-11T09:25:50  <bitcoin-git> bitcoin/master f6120d4 MeshCollider: Merge #15728: [wallet] Refactor relay transactions
130 2019-04-11T09:25:53  *** bitcoin-git has left #bitcoin-core-dev
131 2019-04-11T09:26:32  *** bitcoin-git has joined #bitcoin-core-dev
132 2019-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
133 2019-04-11T09:26:33  *** bitcoin-git has left #bitcoin-core-dev
134 2019-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
135 2019-04-11T09:27:30  *** jonatack has joined #bitcoin-core-dev
136 2019-04-11T09:28:56  *** AaronvanW has joined #bitcoin-core-dev
137 2019-04-11T09:29:24  *** Skirmant has quit IRC
138 2019-04-11T09:30:32  *** bitcoin-git has joined #bitcoin-core-dev
139 2019-04-11T09:30:34  <bitcoin-git> [bitcoin] MeshCollider pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/f6120d40d583...c536dfbcb00f
140 2019-04-11T09:30:34  <bitcoin-git> bitcoin/master fbc6bb8 Russell Yanofsky: bitcoin-wallet tool: Drop MakeChain calls
141 2019-04-11T09:30:35  <bitcoin-git> bitcoin/master b874747 Russell Yanofsky: Remove access to node globals from wallet-linked code
142 2019-04-11T09:30:36  <bitcoin-git> bitcoin/master 78a2fb5 Russell Yanofsky: bitcoin-wallet tool: Drop libbitcoin_server.a dependency
143 2019-04-11T09:30:38  *** bitcoin-git has left #bitcoin-core-dev
144 2019-04-11T09:31:00  <wumpus> that's interesting, which rpi are you using?
145 2019-04-11T09:31:13  *** bitcoin-git has joined #bitcoin-core-dev
146 2019-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
147 2019-04-11T09:31:14  *** bitcoin-git has left #bitcoin-core-dev
148 2019-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
149 2019-04-11T09:31:48  <wumpus> (well, maybe slower, but not thus slow it's self-sabotaging)
150 2019-04-11T09:33:03  *** ccdle12 has quit IRC
151 2019-04-11T09:33:05  <emilr> 3B+, I'm guessing it's not an issue if you don't sync over tor
152 2019-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
153 2019-04-11T09:33:23  <wumpus> I do
154 2019-04-11T09:33:52  <wumpus> but it's been a while, could try again
155 2019-04-11T09:34:02  <wumpus> first, seeds update for 0.18..
156 2019-04-11T09:39:49  *** rex4539 has quit IRC
157 2019-04-11T09:40:28  *** promag has quit IRC
158 2019-04-11T10:03:29  *** jonatack has quit IRC
159 2019-04-11T10:12:42  *** gelmutshmidt has joined #bitcoin-core-dev
160 2019-04-11T10:19:43  *** bitcoin-git has joined #bitcoin-core-dev
161 2019-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
162 2019-04-11T10:19:45  *** bitcoin-git has left #bitcoin-core-dev
163 2019-04-11T10:36:03  <wumpus> ok something strange is happening here
164 2019-04-11T10:36:32  <wumpus> it looks like sipa's seed does return onion peers but somehow, makeseeds.py throws all of them out
165 2019-04-11T10:39:56  *** jonatack has joined #bitcoin-core-dev
166 2019-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
167 2019-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?
168 2019-04-11T10:45:17  *** profmac has quit IRC
169 2019-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
170 2019-04-11T10:51:55  *** spinza has quit IRC
171 2019-04-11T10:52:00  <emilr> pubmsg: whats up with 450k seeds?, lol
172 2019-04-11T10:58:26  *** profmac has joined #bitcoin-core-dev
173 2019-04-11T11:15:10  *** Sentineo has joined #bitcoin-core-dev
174 2019-04-11T11:15:48  <wumpus> added stats https://github.com/bitcoin/bitcoin/pull/15791#issuecomment-482072722
175 2019-04-11T11:16:34  *** dviola has joined #bitcoin-core-dev
176 2019-04-11T11:16:41  *** harrymm has quit IRC
177 2019-04-11T11:21:57  <wumpus> maybe change the uptime requirement for onions?
178 2019-04-11T11:23:56  *** promag has joined #bitcoin-core-dev
179 2019-04-11T11:24:42  <wumpus> bah, even changing it to 25% with no other changes only gives 10 onions
180 2019-04-11T11:26:17  *** spinza has joined #bitcoin-core-dev
181 2019-04-11T11:27:07  *** rex4539 has joined #bitcoin-core-dev
182 2019-04-11T11:27:57  *** promag has quit IRC
183 2019-04-11T11:29:50  *** harrymm has joined #bitcoin-core-dev
184 2019-04-11T11:31:26  <wumpus> it's better than nothing, I guess
185 2019-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
186 2019-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
187 2019-04-11T11:36:47  *** chriswang2019 has joined #bitcoin-core-dev
188 2019-04-11T11:43:02  *** bitcoin-git has joined #bitcoin-core-dev
189 2019-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
190 2019-04-11T11:43:03  *** bitcoin-git has left #bitcoin-core-dev
191 2019-04-11T11:45:42  *** chriswang2019 has quit IRC
192 2019-04-11T11:46:27  *** chriswang2019 has joined #bitcoin-core-dev
193 2019-04-11T11:48:45  *** chriswang2019 has quit IRC
194 2019-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
195 2019-04-11T12:02:37  <wumpus> in itself, 50% uptime is a reasonable requirement
196 2019-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"
197 2019-04-11T12:05:29  <wumpus> grep \.onion seeds_main.txt|grep "/Satoshi:0.17" -> one result
198 2019-04-11T12:07:07  <wumpus> unless you have a different source? if so, please let me know
199 2019-04-11T12:11:41  *** ajtowns[m] has quit IRC
200 2019-04-11T12:11:47  *** DavidMitchell[m] has quit IRC
201 2019-04-11T12:11:52  *** TheFuzzStone[m] has quit IRC
202 2019-04-11T12:12:02  *** stepa[m] has quit IRC
203 2019-04-11T12:12:07  *** kewde[m] has quit IRC
204 2019-04-11T12:16:45  <emilr> sorry, what I meant is that bitcoin core 0.17 has 120 hardcoded onion peers
205 2019-04-11T12:21:07  <wumpus> oh!
206 2019-04-11T12:21:32  <wumpus> yes, I misunderstood your sentence then
207 2019-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
208 2019-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
209 2019-04-11T12:25:10  <wumpus> right
210 2019-04-11T12:51:41  <emzy> how do I generate the seed.txt.gz file?
211 2019-04-11T12:52:55  <emzy> ok found it: https://github.com/sipa/bitcoin-stats/blob/b1690b87a781a2bdd1b5f7e6fa284e1bc0e50541/update.sh#L104
212 2019-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
213 2019-04-11T12:55:38  <wumpus> emilr: interesting
214 2019-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 ?
215 2019-04-11T13:04:01  <emzy> I have no .onion
216 2019-04-11T13:08:06  <wumpus> heh
217 2019-04-11T13:10:06  <emzy> no idea what's the problem
218 2019-04-11T13:10:24  <wumpus> emilr: i don't think "has all nodes since 2013" is true
219 2019-04-11T13:11:44  <wumpus> for example the list doesn't include anything with zero uptime in last 30 days
220 2019-04-11T13:12:01  <wumpus> and that would be *many* if so
221 2019-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
222 2019-04-11T13:12:55  <emilr> wumpus: thats because once a server goes stale, it keeps it's uptime history
223 2019-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
224 2019-04-11T13:14:56  <wumpus> I think that's acceptable because it's only a fallback
225 2019-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
226 2019-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)
227 2019-04-11T13:20:06  <emilr> I didn't crawl, I downloaded http://bitcoin.sipa.be/seeds.txt.gz as per README
228 2019-04-11T13:20:33  <wumpus> oh, sorry, that was meant for emzy
229 2019-04-11T13:22:15  <emzy> wumpus: no, I have no crawler for tor configures. But a tor is running on the server.
230 2019-04-11T13:22:38  <emzy> wumpus: do you have a readme for the crawler setup for me>
231 2019-04-11T13:23:03  <wumpus> no, I don't
232 2019-04-11T13:24:03  <wumpus> `bitcoin-seeder --help` seems to return some options https://github.com/sipa/bitcoin-seeder/blob/master/main.cpp#L37
233 2019-04-11T13:24:13  <wumpus> (if that's what you're using)
234 2019-04-11T13:24:29  <emzy> I will try -o
235 2019-04-11T13:29:14  <emzy> It worked!
236 2019-04-11T13:29:20  <wumpus> awesome!
237 2019-04-11T13:31:50  <emzy> I will wait a litte. to get the seeds.txt filled.
238 2019-04-11T13:50:04  <emzy> 81 .onion
239 2019-04-11T13:51:16  <emzy> # zgrep \.onion seeds.txt.gz|grep "/Satoshi:0.17" | wc -l   ->>> 66
240 2019-04-11T13:51:34  *** chriswang2019 has joined #bitcoin-core-dev
241 2019-04-11T13:54:57  *** chriswang2019 has quit IRC
242 2019-04-11T13:56:30  <Sentineo> we need 600 more :)
243 2019-04-11T13:57:59  *** bitcoin-git has joined #bitcoin-core-dev
244 2019-04-11T13:57:59  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c536dfbcb00f...570eb7b130c2
245 2019-04-11T13:58:00  <bitcoin-git> bitcoin/master 0b3a654 Peter Bushnell: Avoid redefine warning
246 2019-04-11T13:58:00  <bitcoin-git> bitcoin/master 570eb7b Wladimir J. van der Laan: Merge #15782: Avoid redefine warning
247 2019-04-11T13:58:02  *** bitcoin-git has left #bitcoin-core-dev
248 2019-04-11T13:58:57  *** bitcoin-git has joined #bitcoin-core-dev
249 2019-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
250 2019-04-11T13:58:58  *** bitcoin-git has left #bitcoin-core-dev
251 2019-04-11T14:03:41  *** bitcoin-git has joined #bitcoin-core-dev
252 2019-04-11T14:03:42  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/570eb7b130c2...bb68abe784b9
253 2019-04-11T14:03:43  <bitcoin-git> bitcoin/master 303372c Carl Dong: docs: Improve netaddress comments
254 2019-04-11T14:03:44  <bitcoin-git> bitcoin/master bb68abe Wladimir J. van der Laan: Merge #15718: docs: Improve netaddress comments
255 2019-04-11T14:03:46  *** bitcoin-git has left #bitcoin-core-dev
256 2019-04-11T14:04:24  *** bitcoin-git has joined #bitcoin-core-dev
257 2019-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
258 2019-04-11T14:04:25  *** ranefer has joined #bitcoin-core-dev
259 2019-04-11T14:04:25  *** bitcoin-git has left #bitcoin-core-dev
260 2019-04-11T14:06:23  *** pinheadmz has joined #bitcoin-core-dev
261 2019-04-11T14:16:40  *** bitcoin-git has joined #bitcoin-core-dev
262 2019-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
263 2019-04-11T14:16:51  *** bitcoin-git has left #bitcoin-core-dev
264 2019-04-11T14:25:44  *** dviola has quit IRC
265 2019-04-11T14:53:19  <stevenroose> "private key in base58-encoding" means WIF format, right?
266 2019-04-11T14:53:30  <stevenroose> that's a cite from signrawtransactionwithkey
267 2019-04-11T14:55:01  *** jarthur has joined #bitcoin-core-dev
268 2019-04-11T14:55:15  <sipa> stevenroose: yes
269 2019-04-11T15:07:26  *** Guyver2 has joined #bitcoin-core-dev
270 2019-04-11T15:16:29  *** provoostenator has quit IRC
271 2019-04-11T15:17:42  *** provoostenator has joined #bitcoin-core-dev
272 2019-04-11T15:19:06  *** jarthur has quit IRC
273 2019-04-11T15:19:17  *** setpill has quit IRC
274 2019-04-11T15:27:55  *** jarthur has joined #bitcoin-core-dev
275 2019-04-11T15:35:31  *** jb55 has joined #bitcoin-core-dev
276 2019-04-11T15:53:00  *** jarthur has quit IRC
277 2019-04-11T16:02:09  *** jarthur has joined #bitcoin-core-dev
278 2019-04-11T16:06:12  <stevenroose> It appears that listtransactions returns a negative number of confirmatins for txs in orphaned blocks.
279 2019-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?
280 2019-04-11T16:07:26  <sipa> negative numbers indicate how deep the conflict is
281 2019-04-11T16:08:23  <stevenroose>     return ((nIndex == -1) ? (-1) : 1) * (chainActive.Height() - pindex->nHeight + 1);
282 2019-04-11T16:08:47  <stevenroose> So is that a generic thing? Like all calls can do that?
283 2019-04-11T16:08:57  <sipa> i doubt that
284 2019-04-11T16:09:02  <stevenroose> Like gettxout, getrawtransaction, getblockheader?
285 2019-04-11T16:09:24  <stevenroose> Seems to come from CMerkleTx::GetDepthInMainChain
286 2019-04-11T16:09:39  <sipa> are you sure that pindex is the block the tx is included in here?
287 2019-04-11T16:09:51  <sipa> i think it's the block the _conflict_ is included in
288 2019-04-11T16:10:22  <sipa> just an orphaned transaction should have 0 confirmations
289 2019-04-11T16:10:36  <sipa> it's only when a doublespend of it gets confirmed that you get negative numbers
290 2019-04-11T16:12:46  <sipa> gettxout only applies to actually existing UTXOs, so negative confirmations don't make sense there
291 2019-04-11T16:12:59  <sipa> same for getrawtransaction
292 2019-04-11T16:14:07  <sipa> and it doesn't apply at all to blocks
293 2019-04-11T16:24:55  <wumpus> CMerkleTx is only used from the wallet; it'll be wallet calls at most that use that convention
294 2019-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
295 2019-04-11T16:31:02  *** inersha has joined #bitcoin-core-dev
296 2019-04-11T16:33:09  *** inersha has left #bitcoin-core-dev
297 2019-04-11T16:43:47  *** jarthur has quit IRC
298 2019-04-11T16:45:15  *** jarthur has joined #bitcoin-core-dev
299 2019-04-11T16:55:18  *** bitcoin-git has joined #bitcoin-core-dev
300 2019-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
301 2019-04-11T16:55:20  *** bitcoin-git has left #bitcoin-core-dev
302 2019-04-11T17:02:30  *** bitcoin-git has joined #bitcoin-core-dev
303 2019-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
304 2019-04-11T17:02:31  *** bitcoin-git has left #bitcoin-core-dev
305 2019-04-11T17:16:55  *** bitcoin-git has joined #bitcoin-core-dev
306 2019-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
307 2019-04-11T17:16:56  *** bitcoin-git has left #bitcoin-core-dev
308 2019-04-11T17:24:15  *** bitcoin-git has joined #bitcoin-core-dev
309 2019-04-11T17:24:15  <bitcoin-git> [bitcoin] MarcoFalke pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/bb68abe784b9...0e9cb2d24dbf
310 2019-04-11T17:24:16  <bitcoin-git> bitcoin/master fa4680e MarcoFalke: scripted-diff: Rename sync_blocks to send_blocks to avoid name collisions ...
311 2019-04-11T17:24:16  <bitcoin-git> bitcoin/master fafe008 MarcoFalke: test: Pass at most one node group to sync_all
312 2019-04-11T17:24:17  <bitcoin-git> bitcoin/master fa6dc7c MarcoFalke: test: Add BitcoinTestFramework::sync_* methods
313 2019-04-11T17:24:18  *** bitcoin-git has left #bitcoin-core-dev
314 2019-04-11T17:25:06  *** bitcoin-git has joined #bitcoin-core-dev
315 2019-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
316 2019-04-11T17:25:07  *** bitcoin-git has left #bitcoin-core-dev
317 2019-04-11T17:28:23  *** bitcoin-git has joined #bitcoin-core-dev
318 2019-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
319 2019-04-11T17:28:25  *** bitcoin-git has left #bitcoin-core-dev
320 2019-04-11T17:46:44  *** bitcoin-git has joined #bitcoin-core-dev
321 2019-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
322 2019-04-11T17:46:57  *** bitcoin-git has left #bitcoin-core-dev
323 2019-04-11T17:47:11  *** promag has joined #bitcoin-core-dev
324 2019-04-11T17:49:37  *** hebasto has joined #bitcoin-core-dev
325 2019-04-11T17:51:40  *** promag has quit IRC
326 2019-04-11T17:59:33  *** hebasto has quit IRC
327 2019-04-11T18:00:37  *** elichai2 has joined #bitcoin-core-dev
328 2019-04-11T18:09:03  *** DeanGuss has quit IRC
329 2019-04-11T18:17:14  *** bitcoin-git has joined #bitcoin-core-dev
330 2019-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
331 2019-04-11T18:17:15  *** bitcoin-git has left #bitcoin-core-dev
332 2019-04-11T18:17:30  <cfields_> #proposedmeetingtopic Bitcoin CRust
333 2019-04-11T18:17:36  <cfields_> #proposedmeetingtopic Potential platform deprecation
334 2019-04-11T18:17:42  <luke-jr> Bitcoin CRust?
335 2019-04-11T18:18:00  <luke-jr> are we deprecating Windows? :p
336 2019-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.
337 2019-04-11T18:39:53  <wumpus> there was also a discussion about --disable-asm IIRC
338 2019-04-11T18:42:48  <luke-jr> I don't really see what there is to discuss on that?
339 2019-04-11T18:45:57  *** jeremyrubin has joined #bitcoin-core-dev
340 2019-04-11T18:50:17  <MarcoFalke> There was some discussion in #13788, which is why it was removed from the 0.17. milestone
341 2019-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
342 2019-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.
343 2019-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
344 2019-04-11T18:57:53  <sipa> luke-jr: i'm just unclear on the goal?
345 2019-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
346 2019-04-11T18:58:58  <gmaxwell> disable machine specific crap that breaks weirdo compilers
347 2019-04-11T18:59:03  <wumpus> working around build problems, and analysis tooling, basically
348 2019-04-11T18:59:12  <sipa> the option was originally introduced because of (a), but i think that goal is gone
349 2019-04-11T18:59:19  <gmaxwell> b/c.
350 2019-04-11T18:59:22  <gmaxwell> yea, not a
351 2019-04-11T18:59:31  <sipa> if it's for b/c both, it shouldn't be called asm
352 2019-04-11T18:59:47  <gmaxwell> speaking of a, we don't enable asm for libsecp256k1 in the bitcoin core build, do we?
353 2019-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
354 2019-04-11T19:00:01  <wumpus> gmaxwell: it does afaik
355 2019-04-11T19:00:12  <sipa> gmaxwell: pretty sure we do, but not the arm asm
356 2019-04-11T19:00:23  <wumpus> of course not the ARM asm :)
357 2019-04-11T19:00:25  <wumpus> #startmeeting
358 2019-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.
359 2019-04-11T19:00:25  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
360 2019-04-11T19:01:07  <wumpus> #topic 0.18.0
361 2019-04-11T19:01:16  <wumpus> so it turns out we need another rc
362 2019-04-11T19:01:29  <kanzure> hi
363 2019-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
364 2019-04-11T19:02:21  <wumpus> (for #15776)
365 2019-04-11T19:02:23  <gribble> https://github.com/bitcoin/bitcoin/issues/15776 | Expire inflight GETDATA requests by ajtowns · Pull Request #15776 · bitcoin/bitcoin · GitHub
366 2019-04-11T19:02:31  <meshcollider> hi
367 2019-04-11T19:02:35  <jonasschnelli> hi
368 2019-04-11T19:02:39  <achow101> hi
369 2019-04-11T19:02:42  <jamesob> hi
370 2019-04-11T19:02:48  <cfields_> hi
371 2019-04-11T19:02:49  <wumpus> the schedule was to tag final today, but we're not going to make that then I guess
372 2019-04-11T19:02:51  <luke-jr> hi
373 2019-04-11T19:02:54  <wumpus> let's at least tag a new rc?
374 2019-04-11T19:02:57  <meshcollider> In that case, I think we should also backport #15749 ?
375 2019-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
376 2019-04-11T19:03:10  <MarcoFalke> wumpus: nothging changed since rc3?
377 2019-04-11T19:03:21  <sipa> 15776 is not yet merged
378 2019-04-11T19:03:25  <wumpus> MarcoFalke: after 15776 ofc
379 2019-04-11T19:03:33  <MarcoFalke> oh
380 2019-04-11T19:03:57  <MarcoFalke> Doesn't look like it was reviewed
381 2019-04-11T19:04:00  <wumpus> meshcollider: yea if all kinds of other bugs were found since, makes sense to include them
382 2019-04-11T19:04:09  <wumpus> ok
383 2019-04-11T19:04:40  <wumpus> well, 0.18.0 will be delayed a bit that's clear at least
384 2019-04-11T19:04:46  <luke-jr> no big deal imo
385 2019-04-11T19:05:14  <jonasschnelli> yes. acceptable
386 2019-04-11T19:05:54  *** ranefer has quit IRC
387 2019-04-11T19:06:09  <wumpus> no, it doesn't really matter, though I think review should focus on those PRs then
388 2019-04-11T19:06:14  <sipa> agree
389 2019-04-11T19:07:41  <wumpus> added #15749 to needs backport to 0.18.0
390 2019-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
391 2019-04-11T19:08:17  <meshcollider> thanks
392 2019-04-11T19:08:34  <wumpus> #topic Bitcoin CRust (cfields_)
393 2019-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
394 2019-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
395 2019-04-11T19:09:31  <jeremyrubin> Hi! Also present
396 2019-04-11T19:10:12  <instagibbs> hi
397 2019-04-11T19:10:21  <luke-jr> jnewbery: that looks like removal of an API, not a fix; I don't really care though
398 2019-04-11T19:10:35  <luke-jr> better to remove in 0.18.0 than 0.18.1
399 2019-04-11T19:10:43  <cfields_> ah, sorry, irc went weird for me.
400 2019-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.
401 2019-04-11T19:10:57  <gribble> https://github.com/bitcoin/bitcoin/issues/15798 | RFC: Rust code integration by theuni · Pull Request #15798 · bitcoin/bitcoin · GitHub
402 2019-04-11T19:11:13  <wumpus> jnewbery: looks like it's somewhat controversial, any reason to not do this for 0.19 instead?
403 2019-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
404 2019-04-11T19:11:18  <MarcoFalke> jnewbery: There shouldn't be any cost to only remove it in 0.19.0
405 2019-04-11T19:11:19  <jonasschnelli> Nice work jnewbery and cfields_!
406 2019-04-11T19:11:36  <jonasschnelli> luke-jr: it's an experiment AFAIK
407 2019-04-11T19:11:37  <kanzure> which third party library is that
408 2019-04-11T19:11:38  <wumpus> I really like the rust work
409 2019-04-11T19:11:43  <jnewbery> Because the deprecation warning in the RPC help text is removed in 0.18
410 2019-04-11T19:11:51  <luke-jr> jonasschnelli: experiments can be done outside Core
411 2019-04-11T19:11:58  <cfields_> luke-jr: there are people working on that. This is experimental. This discussion is not helpful at this time.
412 2019-04-11T19:11:59  <kanzure> you mean the rust binary?
413 2019-04-11T19:12:01  <wumpus> jnewbery: wha-why ?
414 2019-04-11T19:12:05  <luke-jr> kanzure: yes, rustc
415 2019-04-11T19:12:05  <jonasschnelli> luke-jr: read the PR desc
416 2019-04-11T19:12:09  <MarcoFalke> luke-jr: Bitcoin is experimental
417 2019-04-11T19:12:10  <cfields_> luke-jr: it says right there. NOT FOR MERGE.
418 2019-04-11T19:12:16  <cfields_> caps and everything :)
419 2019-04-11T19:12:20  <jeremyrubin> luke-jr: did you see Marco's bootstrapping link as well?
420 2019-04-11T19:12:33  <wumpus> it's an experiment, but it's good to have people aware of it
421 2019-04-11T19:12:46  <cfields_> anyway, I'd like to get some feedback from people who have actually used rust.
422 2019-04-11T19:12:56  <instagibbs> you'd want to ping #rust-bitcoin folks
423 2019-04-11T19:13:01  <dongcarl> Hi
424 2019-04-11T19:13:03  <luke-jr> jeremyrubin: as I understand it, mrustc only works on x86
425 2019-04-11T19:13:05  <wumpus> dongcarl: ^^
426 2019-04-11T19:13:07  <jamesob> rust is a pleasure to write - beyond that I don't have much input
427 2019-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
428 2019-04-11T19:13:26  *** promag has joined #bitcoin-core-dev
429 2019-04-11T19:13:42  <kanzure> don't we also use other compilers in deterministic builds..?
430 2019-04-11T19:13:45  <jeremyrubin> luke-jr: can you not cross compile after bootstrap? Do you want to bootstrap on every platform?
431 2019-04-11T19:13:50  <MarcoFalke> Yeah, it is good to see that the build system changes are smaller than anyone expected
432 2019-04-11T19:13:59  <jeremyrubin> Anyways, as noted, this is just for enabling more experimentation
433 2019-04-11T19:14:06  <cfields_> luke-jr's complaint has been heard. Let's move on please.
434 2019-04-11T19:14:23  <gmaxwell> yeah, its not a for merge thing. Useful announcement.
435 2019-04-11T19:14:29  <luke-jr> kanzure: hopefully we are moving away from that
436 2019-04-11T19:14:45  <dongcarl> perhaps a good question is what parts of the code is memory safety the most critical
437 2019-04-11T19:15:18  <wumpus> anything that interfaces to the hostile outside world (e.g. P2P code)
438 2019-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)
439 2019-04-11T19:15:21  <MarcoFalke> The parts that are not going to be rewritten in rust any time soon ;)
440 2019-04-11T19:15:24  <cfields_> dongcarl: yes. also, what things are in-spec in rust that can only be undefined in c/c++.
441 2019-04-11T19:15:25  <MarcoFalke> dongcarl: ^
442 2019-04-11T19:15:28  <instagibbs> MarcoFalke, hah!
443 2019-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
444 2019-04-11T19:16:29  <jamesob> but that's obviously pretty speculative...
445 2019-04-11T19:16:49  <wumpus> that's a pretty neat idea
446 2019-04-11T19:16:58  <sipa> i don't understand the appeal of that idea
447 2019-04-11T19:17:09  <sipa> the complexity is all in the interaction between network code and the rest
448 2019-04-11T19:17:11  <meshcollider> I remember him bringing that up in tokyo
449 2019-04-11T19:17:13  <jamesob> two is one and one is none, I guess
450 2019-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
451 2019-04-11T19:17:15  <sipa> not in the network code itself
452 2019-04-11T19:17:44  <luke-jr> jamesob: sounds more complex to detect "weird" than to just replace it
453 2019-04-11T19:18:01  <jamesob> luke-jr: could be
454 2019-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.
455 2019-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
456 2019-04-11T19:18:14  <luke-jr> if someone is compromising the original network stack, they can probably corrupt the alternate one too
457 2019-04-11T19:18:44  <sipa> wumpus: in a way that we've actually ever had problems?
458 2019-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.
459 2019-04-11T19:19:09  <luke-jr> rewrite the node around libconsensus? ;)
460 2019-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)
461 2019-04-11T19:19:22  <wumpus> sipa: that we haven't noticed any problems doesn't mean that they don't exist, but sure...
462 2019-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
463 2019-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
464 2019-04-11T19:19:58  <sipa> wumpus: while introducing a complexity in making the two layers communicate
465 2019-04-11T19:20:04  <wumpus> so in a sense it's speculative
466 2019-04-11T19:20:06  <MarcoFalke> Doesn't rust fix uninitizlized reads? #14728
467 2019-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
468 2019-04-11T19:20:10  *** lnostdal has quit IRC
469 2019-04-11T19:20:16  <dongcarl> Perhaps another useful property: Safe Rust guarantees an absence of data races.
470 2019-04-11T19:20:17  <MarcoFalke> #6636
471 2019-04-11T19:20:18  <gribble> https://github.com/bitcoin/bitcoin/issues/6636 | net: correctly initialize nMinPingUsecTime by laanwj · Pull Request #6636 · bitcoin/bitcoin · GitHub
472 2019-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.
473 2019-04-11T19:20:25  <wumpus> rust fixes undefined behavior at least,we've had plenty of that reported
474 2019-04-11T19:20:25  <jeremyrubin> I think fixing some of the internal concurrent workers would be a good task
475 2019-04-11T19:20:32  *** lnostdal has joined #bitcoin-core-dev
476 2019-04-11T19:20:33  <jeremyrubin> E.g., the CheckQueue or Task QUeue
477 2019-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
478 2019-04-11T19:20:41  <cfields_> gmaxwell: for now.
479 2019-04-11T19:20:43  <jeremyrubin> As that can just be treated as a scheduler
480 2019-04-11T19:20:44  <gmaxwell> Put it this way, however: I would much rather be linking a upnp library written in rust.
481 2019-04-11T19:21:02  <sipa> but i have no interest in seeing bitcoin core becoming developed in a mix of languages
482 2019-04-11T19:21:06  <jamesob> sipa: +1
483 2019-04-11T19:21:12  <meshcollider> Agreed
484 2019-04-11T19:21:26  * cfields_ banishes sipa from the testing framework :p
485 2019-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
486 2019-04-11T19:21:46  <gmaxwell> testing framework being written in another language has a non-trivial cost. (not that I'd suggest otherwise!)
487 2019-04-11T19:21:51  <cfields_> (That was a joke, I realize it's not the same thing)
488 2019-04-11T19:22:05  <jamesob> cfields_: I'm working on a c++ rewrite as we speak
489 2019-04-11T19:22:08  <sipa> wumpus: i realize that; but bitcoin core is a c++ project with c++ reviewers
490 2019-04-11T19:22:20  <wumpus> sipa: yes, maybe it means I need to move to rust-bitcoin :-)
491 2019-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.
492 2019-04-11T19:22:51  <wumpus> anyhow, this is an experiment, I don't think merging it is even a question right now
493 2019-04-11T19:22:58  <MarcoFalke> A lot of the reviewers know rust or wouldn't have a problem learning it
494 2019-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. :(
495 2019-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
496 2019-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?
497 2019-04-11T19:23:37  <wumpus> cfields_: yes
498 2019-04-11T19:23:38  <meshcollider> Review quality would definitely go down if people are new to the language
499 2019-04-11T19:23:42  <luke-jr> gmaxwell: if only everything used the same ABI
500 2019-04-11T19:23:43  <cfields_> sipa: very fair point.
501 2019-04-11T19:23:43  <jeremyrubin> Expertise in rust is easier to attain than c++
502 2019-04-11T19:23:55  <jeremyrubin> The compiler catches most of the stuff you spend time revieiwing in c++ anyways
503 2019-04-11T19:24:01  <wumpus> cfields_: as said I'm happy to maintain that branch
504 2019-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.
505 2019-04-11T19:24:40  <cfields_> wumpus: ok, great, you're welcome to take it over.
506 2019-04-11T19:25:08  <wumpus> gmaxwell: concurrent programming should be more straightforward in rust at least
507 2019-04-11T19:25:39  <gmaxwell> wumpus: somewhat, but the problems we have like invisible queues that grow unboundedly exist exactly the same in rust.
508 2019-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
509 2019-04-11T19:26:05  <wumpus> gmaxwell: yes, no one is claiming it would eliminate all problems automatically, that would have been great
510 2019-04-11T19:26:16  <gmaxwell> It's a lot easier to avoid writing data races, however, indeed
511 2019-04-11T19:26:52  <gmaxwell> wumpus: not all problems, of course... but the problems we actually end up shipping.
512 2019-04-11T19:26:54  <wumpus> right
513 2019-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
514 2019-04-11T19:27:50  <sipa> i'm not; but it's a discussion to be had when there is code to include
515 2019-04-11T19:27:54  <wumpus> yes
516 2019-04-11T19:28:01  <gmaxwell> As I said before, I'd be much happier with a rust miniupnp than miniupnp.
517 2019-04-11T19:28:04  <jonasschnelli> Let it be an experiment
518 2019-04-11T19:28:09  <wumpus> so let's start with miniupnp
519 2019-04-11T19:28:14  <gmaxwell> So certantly not 100% against it.
520 2019-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
521 2019-04-11T19:28:26  <wumpus> happy to write that in rust :)
522 2019-04-11T19:28:37  <dongcarl> I can get boostrap working
523 2019-04-11T19:28:40  <sipa> i'd be even happier with a minimal c++ reimplementation of miniupnp :p
524 2019-04-11T19:28:51  <sipa> (but i have no problem with a rust one if it would exist)
525 2019-04-11T19:29:07  <wumpus> you really want to make another c++ upnp implementation?
526 2019-04-11T19:29:10  <sipa> and it's great that the build system issues are already out of the way
527 2019-04-11T19:29:14  <jeremyrubin> So now that we have the demo build, someone can more easily show us motivation
528 2019-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
529 2019-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)
530 2019-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
531 2019-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?
532 2019-04-11T19:30:19  <sipa> i think we have a pretty good track record wrt the kind of bugs that miniupnp has
533 2019-04-11T19:30:29  <wumpus> you mean, xml parsing?
534 2019-04-11T19:30:35  <sipa> memory safety
535 2019-04-11T19:30:48  <wumpus> nah
536 2019-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.
537 2019-04-11T19:31:24  <gmaxwell> s/ping/pin/
538 2019-04-11T19:31:28  <jeremyrubin> gmaxwell: I'm not sure? Crates.io is supposed to be append only
539 2019-04-11T19:31:31  <sipa> wumpus: how so?
540 2019-04-11T19:31:49  <jeremyrubin> gmaxwell: cargo also just added the ability to have your own crate registry, which would help
541 2019-04-11T19:31:57  <wumpus> sipa: just having a good track record doesn't guarantee anything
542 2019-04-11T19:32:01  <sipa> wumpus: of course
543 2019-04-11T19:32:09  <jeremyrubin> gmaxwell: in the PR, I manually pinned the one dep (a build tool to auto-gen headers)
544 2019-04-11T19:32:12  <wumpus> it doesn't mean you can do arbitrarily complex things and avoid bugs
545 2019-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)
546 2019-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
547 2019-04-11T19:33:12  <luke-jr> is it even possible to have multiple versions of Rustc installed on most distros?
548 2019-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.
549 2019-04-11T19:33:15  <jeremyrubin> gmaxwell: updating to a new compiler can be annoying for anything
550 2019-04-11T19:33:25  <jeremyrubin> luke-jr: yes look at the rustup toolchain manager
551 2019-04-11T19:33:26  <gmaxwell> luke-jr: the tooling makes it possible to do that, yes.
552 2019-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
553 2019-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
554 2019-04-11T19:33:52  <jeremyrubin> gmaxwell: yeah -- it's a pity rust is adding so many exciting new features ;)
555 2019-04-11T19:33:57  *** cfields_ has quit IRC
556 2019-04-11T19:34:02  <wumpus> it's pretty much outside all our expertise
557 2019-04-11T19:34:17  <sipa> but the whole question is pointless without an actual package to discuss
558 2019-04-11T19:34:22  <wumpus> yes
559 2019-04-11T19:34:23  *** cfields has joined #bitcoin-core-dev
560 2019-04-11T19:35:02  <wumpus> (this is besides the rust issue btw)
561 2019-04-11T19:35:10  <cfields> Sorry, was laggy, had to switch servers.
562 2019-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).
563 2019-04-11T19:35:53  <wumpus> I think using it for non-optional functionality is a bad idea right now
564 2019-04-11T19:37:04  <wumpus> agree on gmaxwell's comments re: cargo
565 2019-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.
566 2019-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
567 2019-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.
568 2019-04-11T19:37:43  <luke-jr> cfields: people who build their own bitcoind *don't* need to use Ubuntu's toolchain
569 2019-04-11T19:37:44  <gmaxwell> cfields: we do use a toolchain that can be bit identically produced by many hetrogenious toolchains.
570 2019-04-11T19:38:15  <jeremyrubin> gmaxwell: for 2, there are a lot of things that could be done w/o external deps
571 2019-04-11T19:38:19  <luke-jr> gmaxwell: UPnP might be generic enough that non-Bitcoin devs are interested too
572 2019-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)
573 2019-04-11T19:38:36  <gmaxwell> luke-jr: exactly.
574 2019-04-11T19:39:02  * dongcarl agrees, but needs help
575 2019-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.
576 2019-04-11T19:39:11  <cfields> Grr, I swore I wasn't going to take the bait on this :p
577 2019-04-11T19:39:28  <wumpus> apparently there are already some projects to implement upnp in rust
578 2019-04-11T19:39:30  <gmaxwell> cfields: I yield, I don't really need to argue this with you right now.
579 2019-04-11T19:39:35  *** EagleTM has joined #bitcoin-core-dev
580 2019-04-11T19:39:39  <wumpus> in any case -- let's move to other topics, this isn't so urgent now
581 2019-04-11T19:39:46  <jnewbery> Can I quickly get back to #15750?
582 2019-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.
583 2019-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
584 2019-04-11T19:39:59  <wumpus> #topic Remove addresses field in getaddressinfo
585 2019-04-11T19:40:03  <jnewbery> The addresses field was marked deprecated in v0.17 along with other changes to validateaddress and getaddressinfo (#10583)
586 2019-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
587 2019-04-11T19:40:09  <jnewbery> #12490 (V0.18) should have removed the all deprecated functionality (and depracation notes). This part was missed out.
588 2019-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
589 2019-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.
590 2019-04-11T19:40:15  <jnewbery> So #15750 should fully remove it in v0.18.
591 2019-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
592 2019-04-11T19:40:19  <gmaxwell> cfields: +1000
593 2019-04-11T19:40:25  <gmaxwell> cfields: thanks for bringing it up
594 2019-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.
595 2019-04-11T19:40:38  *** ranefer has joined #bitcoin-core-dev
596 2019-04-11T19:40:45  <wumpus> jnewbery: I agree
597 2019-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.
598 2019-04-11T19:41:09  <sipa> jnewbery: his comments also seem to be about the move from validateaddress to getaddressinfo in the first place
599 2019-04-11T19:41:16  <sipa> which if anything are far too late
600 2019-04-11T19:41:32  <luke-jr> jnewbery: "bugfixes only during RCs" is not "NEVER CHANGE RPCS"
601 2019-04-11T19:41:32  <gmaxwell> It's unclear to me if he just needs help phrasing his argument.
602 2019-04-11T19:41:40  <gmaxwell> But I agree the argument as stated should be ignored.
603 2019-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!
604 2019-04-11T19:41:52  <jnewbery> Right, I don't think he's concerned about this particular field
605 2019-04-11T19:42:05  <wumpus> luke-jr: right
606 2019-04-11T19:42:05  <instagibbs> 0.17 breakages were heavier than in the past fwiw
607 2019-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.
608 2019-04-11T19:42:26  <instagibbs> not complaining, we just have delayed upgrading on some stuff due to it, which is fine
609 2019-04-11T19:42:27  <jnewbery> The problem is that the deprecation notice goes away in v0.18
610 2019-04-11T19:42:32  <wumpus> gmaxwell: yes, would make sense to add documentation for that
611 2019-04-11T19:42:33  <gmaxwell> (life would be better if bug reporters were assigned a lawyer)
612 2019-04-11T19:42:45  <sipa> gmaxwell: i'm... not sure
613 2019-04-11T19:42:52  <wumpus> (which is also what I noted in the PR)
614 2019-04-11T19:42:59  <instagibbs> are we suing people when they file issues :)
615 2019-04-11T19:43:11  <MarcoFalke> no, they sue us
616 2019-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.
617 2019-04-11T19:43:20  <sipa> ah yes
618 2019-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
619 2019-04-11T19:43:22  <luke-jr> we can always say "use 0.17 until you're ready" too
620 2019-04-11T19:43:42  <achow101> jnewbery: ack
621 2019-04-11T19:43:51  <jeremyrubin> instagibbs: is the issue csw not being satoshi
622 2019-04-11T19:43:56  <sipa> jnewbery: i agree; but i also think it's a minor enough thing
623 2019-04-11T19:44:14  <jnewbery> Yeah, I wouldn't bring it up if we weren't already doing another rc
624 2019-04-11T19:44:28  <wumpus> yes, I don't care deeply either way, it just seems to cause a lot of discussion
625 2019-04-11T19:45:00  <gmaxwell> when in doubt, add docs.
626 2019-04-11T19:45:32  <wumpus> yes
627 2019-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
628 2019-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.
629 2019-04-11T19:46:25  <wumpus> anyhow added "needs backport" for now
630 2019-04-11T19:46:36  <jnewbery> wumpus: thanks!
631 2019-04-11T19:46:38  <gmaxwell> sipa: thanks, will do
632 2019-04-11T19:47:29  <sipa> achow101: in particular, i think the new psbt descriptions could use slightly more text
633 2019-04-11T19:47:29  <wumpus> sipa: good idea
634 2019-04-11T19:47:33  <sipa> *new psbt rpcs
635 2019-04-11T19:47:55  <achow101> sipa: I can take a look at those
636 2019-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 :)
637 2019-04-11T19:48:25  <sipa> so also have a look at the updates in doc/psbt.md :p
638 2019-04-11T19:48:58  <wumpus> it's good to meantion things in the release notes but indeed not to be too wordy
639 2019-04-11T19:49:05  <wumpus> ok, cfields had another topic
640 2019-04-11T19:49:15  <wumpus> #topic Platform deprecation (cfields)
641 2019-04-11T19:49:18  <wumpus> sipa: will do
642 2019-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
643 2019-04-11T19:49:29  <cfields> platforms worth the effort?
644 2019-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
645 2019-04-11T19:49:41  <wumpus> which platform?
646 2019-04-11T19:50:17  <sipa> are all newly sold x86 CPUs these days 64-bit?
647 2019-04-11T19:50:29  <wumpus> yess since 2005 or so?
648 2019-04-11T19:50:37  <sipa> and do people run 64-bit OSes on them?
649 2019-04-11T19:50:43  <cfields> sipa: I would think anything running windows especially.
650 2019-04-11T19:50:45  <wumpus> for windows: yes
651 2019-04-11T19:50:46  <sipa> (i have no clue about the windows ecosystem in this regard)
652 2019-04-11T19:50:47  <gmaxwell> yes, though all still also capable of running in 32bit mode.
653 2019-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 ?
654 2019-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.
655 2019-04-11T19:51:26  <cfields> luke-jr: see link above, I don't recall off the top of my head.
656 2019-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)
657 2019-04-11T19:51:50  <wumpus> 100% behind deprecating windows 32-bit
658 2019-04-11T19:52:17  <jonasschnelli> me 2
659 2019-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. :)
660 2019-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…
661 2019-04-11T19:52:46  <jonasschnelli> just don't deprecate the ARM 32bits
662 2019-04-11T19:52:51  <wumpus> oh no not ARM
663 2019-04-11T19:52:53  <wumpus> I mean x86
664 2019-04-11T19:52:55  <cfields> jonasschnelli: right.
665 2019-04-11T19:52:59  <wumpus> windows
666 2019-04-11T19:53:07  *** bitcoin-git has joined #bitcoin-core-dev
667 2019-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
668 2019-04-11T19:53:08  *** bitcoin-git has left #bitcoin-core-dev
669 2019-04-11T19:53:15  <meshcollider> Does that clean up any existing windows-only code or just for later
670 2019-04-11T19:53:31  <wumpus> and for 0.19
671 2019-04-11T19:53:49  <achow101> Windows does have 32 bit version still
672 2019-04-11T19:53:51  <wumpus> meshcollider: I don't think it cleans up any code tbh
673 2019-04-11T19:54:03  <cfields> Great, that was easy :)
674 2019-04-11T19:54:04  <wumpus> it just leaves oneless configuration to maintain and test
675 2019-04-11T19:54:06  <wumpus> which is good
676 2019-04-11T19:54:15  <jeremyrubin> Is anyone even testing 32-bit windows?
677 2019-04-11T19:54:18  <wumpus> no.
678 2019-04-11T19:54:22  <jonasschnelli> I do
679 2019-04-11T19:54:26  <cfields> wumpus: it's also the one that takes _forever_ to run.
680 2019-04-11T19:54:26  <wumpus> oh!
681 2019-04-11T19:54:31  <jonasschnelli> (VM though)
682 2019-04-11T19:54:37  <luke-jr> maybe we should solicit feedback somehow?
683 2019-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
684 2019-04-11T19:54:47  <gmaxwell> ^ fantastic!
685 2019-04-11T19:54:47  <luke-jr> open an issue to deprecate Win32, and put it in release notes?
686 2019-04-11T19:55:05  <gmaxwell> luke-jr: I don't disagree but it also sounds like wumpus already did previously.
687 2019-04-11T19:55:16  <wumpus> I mean we already dropped xp and vista support, which are the most likely to be 32 bit
688 2019-04-11T19:55:21  <luke-jr> gmaxwell: a tweet isn't as loud as release notes
689 2019-04-11T19:55:32  <sipa> luke-jr: i suspect more people read tweets :p
690 2019-04-11T19:55:38  <luke-jr> sipa: could be :/
691 2019-04-11T19:55:41  <sipa> (but maybe less relevant ones)
692 2019-04-11T19:55:49  <cfields> sipa: haha
693 2019-04-11T19:55:51  <sipa> windows 10 still has a 32-bit version it seems
694 2019-04-11T19:56:01  <wumpus> windows 7/8 was already mostly 64-bit, windows 10 certainly
695 2019-04-11T19:56:06  <wumpus> yes it exists but no one uses it
696 2019-04-11T19:56:11  <luke-jr> sipa: how many people use it?
697 2019-04-11T19:56:11  <sipa> okay.
698 2019-04-11T19:56:25  <sipa> luke-jr: i have no clue!
699 2019-04-11T19:56:27  *** bitcoin-git has joined #bitcoin-core-dev
700 2019-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
701 2019-04-11T19:56:29  *** bitcoin-git has left #bitcoin-core-dev
702 2019-04-11T19:56:42  <luke-jr> I'm sure Microsoft does :P
703 2019-04-11T19:57:31  <luke-jr> maybe we could just neglect to post the Win32 binaries for 0.18 and see who complains?\
704 2019-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
705 2019-04-11T19:57:57  <wumpus> +x86
706 2019-04-11T19:57:58  <luke-jr> that way we can always upload them later if it's a problem
707 2019-04-11T19:58:13  <meshcollider> Seems sensible
708 2019-04-11T19:58:26  <wumpus> luke-jr: good idea
709 2019-04-11T19:58:29  <wumpus> :D
710 2019-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?\
711 2019-04-11T19:58:42  <gmaxwell> ^ I'd +1 that too
712 2019-04-11T19:58:48  <instagibbs> wumpus, fwiw they croak when trying to run secp-zkp benchmarks too
713 2019-04-11T19:58:51  <gmaxwell> that would be a nice way of measuring usage.
714 2019-04-11T19:59:04  <wumpus> yes, let's do that
715 2019-04-11T19:59:13  <wumpus> instagibbs: whoops
716 2019-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.
717 2019-04-11T19:59:24  * luke-jr glares at the clock
718 2019-04-11T19:59:27  <gmaxwell> if people complain about the binaries, then we can just go ahead and post them.
719 2019-04-11T19:59:34  <instagibbs> harding, is that a complaint ;)
720 2019-04-11T19:59:36  <wumpus> #endmeeting
721 2019-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)
722 2019-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
723 2019-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
724 2019-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
725 2019-04-11T19:59:40  <gmaxwell> harding: I think we're being serious.
726 2019-04-11T19:59:43  <wumpus> harding: we're serious
727 2019-04-11T19:59:52  <harding> Ok.  I'll disable the test for win32
728 2019-04-11T19:59:54  <luke-jr> sipa: still here? can you post on --disable-asm issue?
729 2019-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.
730 2019-04-11T20:00:10  <luke-jr> maybe we can rename it --disable-code-optimisations if you really don't like calling it asm
731 2019-04-11T20:00:23  <sipa> luke-jr: or split it up
732 2019-04-11T20:00:44  <gmaxwell> luke-jr: --boring-compiler
733 2019-04-11T20:00:53  <luke-jr> gmaxwell: that sounds like autotools mess
734 2019-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...
735 2019-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.
736 2019-04-11T20:01:24  <sipa> luke-jr: i think i don't really care enough to argue :)
737 2019-04-11T20:01:31  <gmaxwell> the other is you're worried someone messed up the handcoded asm and introduced bugs
738 2019-04-11T20:01:49  <luke-jr> gmaxwell: another might be if you have some very interesting compiler you don't want asm to bypass?
739 2019-04-11T20:02:03  <luke-jr> sipa: well, apparently your last comment is being treated as a blocker :P
740 2019-04-11T20:02:59  <MarcoFalke> Looks like a rename will please sipa
741 2019-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
742 2019-04-11T20:03:48  <luke-jr> release notes: I don't understand the change described in "Deprecated P2P messages"
743 2019-04-11T20:04:01  <BlueMatt> do we have download counts/should we monitor download counts?
744 2019-04-11T20:04:26  <luke-jr> BlueMatt: I have been fetching download counts from the PPA for a few releases now
745 2019-04-11T20:04:38  <BlueMatt> that doesnt help much for 32-bit windows :p
746 2019-04-11T20:04:54  <luke-jr> ah
747 2019-04-11T20:05:40  <wumpus> so I"m removing two files from the upload: bitcoin-${VERSIONTO}-win32.zip and bitcoin-${VERSIONTO}-win32-setup.exe
748 2019-04-11T20:05:52  <wumpus> @ harding
749 2019-04-11T20:05:56  <luke-jr> wumpus: well, I expect we should still build/sign them, just not upload
750 2019-04-11T20:06:11  <wumpus> luke-jr: that's what I'm saing
751 2019-04-11T20:06:15  <luke-jr> k
752 2019-04-11T20:06:25  <wumpus> not changing the gitian descriptor
753 2019-04-11T20:06:56  <wumpus> can do that for 0.19
754 2019-04-11T20:07:09  <luke-jr> can I put FIXME notes in the relnote wiki?
755 2019-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.
756 2019-04-11T20:07:22  <luke-jr> or is there a better place for that?
757 2019-04-11T20:07:24  <wumpus> harding: thanks!
758 2019-04-11T20:07:52  <wumpus> luke-jr: only if you intend to make the fixes yourself before final, I guess
759 2019-04-11T20:08:00  <luke-jr> wumpus: I'd just make the fixes, if I knew what they should be
760 2019-04-11T20:08:08  <luke-jr> wumpus: the problem is I have no idea what changed :P
761 2019-04-11T20:08:41  <luke-jr> (which IMO indicates the release note is insufficient in describing the change)
762 2019-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
763 2019-04-11T20:09:35  <harding> luke-jr: do you think it should be moved to the Planned Changes section?
764 2019-04-11T20:09:39  <wumpus> sipa: makes sense
765 2019-04-11T20:09:46  <luke-jr> harding: if that's all it is.
766 2019-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.
767 2019-04-11T20:10:24  <luke-jr> hm, that would make sense
768 2019-04-11T20:11:57  <luke-jr> yeah, I'm not seeing anything else in the git log
769 2019-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.
770 2019-04-11T20:14:20  <luke-jr> heh, there's already a TODO in there
771 2019-04-11T20:15:20  <wumpus> a BIP would be the expected way I think
772 2019-04-11T20:16:00  <luke-jr> dunno, this is just Core deciding not to support a BIP
773 2019-04-11T20:16:11  <wumpus> true
774 2019-04-11T20:16:19  <wumpus> it's a bit of a grey area in this case
775 2019-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
776 2019-04-11T20:17:50  <gmaxwell> We often decide to not support bips, less often decide to remove bips.
777 2019-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
778 2019-04-11T20:18:58  <luke-jr> gmaxwell: sure, but it's still an application-specific thing
779 2019-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
780 2019-04-11T20:19:32  <wumpus> sipa: yes
781 2019-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
782 2019-04-11T20:19:36  <gmaxwell> Right, someone might want to make a case for "no one should support this"
783 2019-04-11T20:19:38  <wumpus> so things like 'bandwidth overhead'
784 2019-04-11T20:19:59  <wumpus> or potential privacy leaks
785 2019-04-11T20:20:11  <luke-jr> gmaxwell: seems like a case for BIP Comments ;)
786 2019-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.
787 2019-04-11T20:21:16  *** timothy has quit IRC
788 2019-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.
789 2019-04-11T20:30:23  <cfields> meshcollider: Were you going to look at getting rid of some of the win32 stuff?
790 2019-04-11T20:30:42  <cfields> (if any)
791 2019-04-11T20:31:09  <wumpus> I'm surprised qt still supports win32
792 2019-04-11T20:31:45  <wumpus> though ok, qt is commonly used on embedded hardware so also not that surprised
793 2019-04-11T20:31:58  <luke-jr> portability is (was?) kind of Qt's main selling point
794 2019-04-11T20:33:57  <cfields> Yeah, I bet there's still a ton of embedded win32 stuff out there.
795 2019-04-11T20:36:10  <cfields> I used embedded winxp in some microscope equipment at one point, that was wacky.
796 2019-04-11T20:43:21  <luke-jr> but Qt did drop WinXP right?
797 2019-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.
798 2019-04-11T20:44:22  <cfields> Basically, I'd suggest not doing something like s/#ifdef win64/#ifdef windows/.
799 2019-04-11T20:45:11  <luke-jr> yeah, since ppc64 is taking over /s
800 2019-04-11T20:45:35  <cfields> Heh
801 2019-04-11T20:45:48  <cfields> I was thinking more like their 10th attempt at an arm platform.
802 2019-04-11T20:46:31  <wumpus> windows rv64 would be a cursed combo
803 2019-04-11T20:46:55  <wumpus> so I think it'll happen at some point
804 2019-04-11T20:47:05  <cfields> lol
805 2019-04-11T20:49:16  <luke-jr> as if RISC-V isn't wide open to being closed down
806 2019-04-11T20:50:01  <cfields> gotta gotta get up to get down.
807 2019-04-11T20:50:15  <gmaxwell> More likely to see google or oracle produce a embrace-and-extent RV than msft these days. :P
808 2019-04-11T20:51:44  <cfields> gmaxwell: fuchsia seems poised to help with that.
809 2019-04-11T20:52:48  *** jarthur has quit IRC
810 2019-04-11T20:55:03  *** Guyver2 has quit IRC
811 2019-04-11T20:57:17  <wumpus> google is definitely looking into RISC-V https://twitter.com/Kensan42/status/1110612910999511041
812 2019-04-11T20:59:03  <wumpus> RISCV-CHERI is pretty interesting
813 2019-04-11T20:59:15  <gmaxwell> oh is someone actually doing riscv-cheri now?!!?!?!
814 2019-04-11T20:59:37  <gmaxwell> I was bummed when riscv didn't include cheri like features from day one, though I understood why...
815 2019-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
816 2019-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.
817 2019-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
818 2019-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
819 2019-04-11T21:14:36  <wumpus> also because it can give actual timing guarantees
820 2019-04-11T21:16:02  <anddam> has issue #1390 ever been discussed again since 2012?
821 2019-04-11T21:16:03  <gribble> https://github.com/bitcoin/bitcoin/issues/1390 | Comply with the XDG Base Directory Specification · Issue #1390 · bitcoin/bitcoin · GitHub
822 2019-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
823 2019-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
824 2019-04-11T21:18:06  <anddam> like --datadir, --wallet and the config file one?
825 2019-04-11T21:18:32  <wumpus> yes and -blocksdir
826 2019-04-11T21:18:48  <wumpus> -walletdir
827 2019-04-11T21:19:03  <anddam> have there been rewrites of bitcoin-core in other languages?
828 2019-04-11T21:19:04  <wumpus> it's very flexible where to put things
829 2019-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
830 2019-04-11T21:20:59  *** promag has quit IRC
831 2019-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
832 2019-04-11T21:34:36  *** DeanGuss has joined #bitcoin-core-dev
833 2019-04-11T21:51:35  *** benthecarman has joined #bitcoin-core-dev
834 2019-04-11T21:54:27  <anddam> wumpus: yep
835 2019-04-11T21:54:45  <anddam> wumpus: when starting bitcoin-qt does a separate bitcoind process get spawnd?
836 2019-04-11T21:54:54  <anddam> (I cannot start bitcoin-qt right now to check)
837 2019-04-11T21:55:04  <anddam> I wonder how detached the Qt GUI and bitcoin core are
838 2019-04-11T21:55:31  <sipa> anddam: no, one process
839 2019-04-11T21:56:24  <anddam> ouch
840 2019-04-11T21:56:33  <anddam> so not very detached
841 2019-04-11T21:58:15  *** benthecarman_ has joined #bitcoin-core-dev
842 2019-04-11T21:59:14  *** benthecarman has quit IRC
843 2019-04-11T21:59:38  *** benthecarman has joined #bitcoin-core-dev
844 2019-04-11T22:01:28  *** benthecarman_ has quit IRC
845 2019-04-11T22:01:33  *** benthecarman has quit IRC
846 2019-04-11T22:04:57  *** benthecarman has joined #bitcoin-core-dev
847 2019-04-11T22:04:59  *** benthecarman has quit IRC
848 2019-04-11T22:05:08  *** benthecarman has joined #bitcoin-core-dev
849 2019-04-11T22:09:17  *** gelmutshmidt has quit IRC
850 2019-04-11T22:18:59  *** DeanGuss has quit IRC
851 2019-04-11T22:19:30  *** DeanGuss has joined #bitcoin-core-dev
852 2019-04-11T22:22:27  *** spinza has quit IRC
853 2019-04-11T22:24:37  *** DeanGuss has quit IRC
854 2019-04-11T22:24:41  *** EagleTM has quit IRC
855 2019-04-11T22:30:16  *** Zenton has quit IRC
856 2019-04-11T22:45:34  *** bitcoin-git has joined #bitcoin-core-dev
857 2019-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
858 2019-04-11T22:45:35  *** bitcoin-git has left #bitcoin-core-dev
859 2019-04-11T22:46:29  *** captjakk has joined #bitcoin-core-dev
860 2019-04-11T22:48:54  *** owowo has quit IRC
861 2019-04-11T22:53:55  *** riperk has joined #bitcoin-core-dev
862 2019-04-11T23:06:49  *** spinza has joined #bitcoin-core-dev
863 2019-04-11T23:21:37  *** promag has joined #bitcoin-core-dev
864 2019-04-11T23:21:42  *** hardforkthis has quit IRC
865 2019-04-11T23:21:42  *** harding has quit IRC
866 2019-04-11T23:21:42  *** dqx__ has quit IRC
867 2019-04-11T23:21:42  *** emilr has quit IRC
868 2019-04-11T23:21:42  *** davec has quit IRC
869 2019-04-11T23:21:42  *** gwillen has quit IRC
870 2019-04-11T23:21:42  *** dgenr8 has quit IRC
871 2019-04-11T23:21:42  *** Madars has quit IRC
872 2019-04-11T23:21:42  *** jasonzhouu has quit IRC
873 2019-04-11T23:26:28  *** promag has quit IRC
874 2019-04-11T23:27:56  *** hardforkthis has joined #bitcoin-core-dev
875 2019-04-11T23:27:56  *** harding has joined #bitcoin-core-dev
876 2019-04-11T23:27:56  *** dqx__ has joined #bitcoin-core-dev
877 2019-04-11T23:27:56  *** emilr has joined #bitcoin-core-dev
878 2019-04-11T23:27:56  *** davec has joined #bitcoin-core-dev
879 2019-04-11T23:27:56  *** gwillen has joined #bitcoin-core-dev
880 2019-04-11T23:27:56  *** dgenr8 has joined #bitcoin-core-dev
881 2019-04-11T23:27:56  *** Madars has joined #bitcoin-core-dev
882 2019-04-11T23:27:56  *** jasonzhouu has joined #bitcoin-core-dev
883 2019-04-11T23:36:54  *** TheV01d_ has quit IRC
884 2019-04-11T23:37:18  *** TheV01d_ has joined #bitcoin-core-dev
885 2019-04-11T23:38:25  <luke-jr> fwiw, found a (minor?) bug in 0.18
886 2019-04-11T23:39:18  <sipa> luke-jr: impossible!
887 2019-04-11T23:39:30  <sipa> (because 0.18 does not exist yet)
888 2019-04-11T23:41:25  <luke-jr> 0.18 != 0.18.0
889 2019-04-11T23:44:38  <sipa> ah!
890 2019-04-11T23:49:13  *** bitcoin-git has joined #bitcoin-core-dev
891 2019-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
892 2019-04-11T23:49:15  *** bitcoin-git has left #bitcoin-core-dev