--- Log opened Thu Apr 11 00:00:41 2019
00:02 -!- chriswang2019 [~Mutter@61.144.119.144] has joined #bitcoin-core-dev
00:02 < emilr> peers.dat is 97K so basically empty and it doesn't connect to any other peer except the ones added with addnode
00:05 < gmaxwell> 97k is far from empty there aren't that many onion peers.
00:05 < gmaxwell> so that part isn't interesting.
00:06 < gmaxwell> any chance you have automatic connections disabled?  how is "it can't connect to anything except .onions" accomplished?
00:06 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
00:08 < emilr> onlynet=onion and bitcoin user is blocked from making connections to the clearnet
00:10 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
00:11 < emilr> also tor is configured with SocksPort 9050 OnionTrafficOnly
00:13 < gmaxwell> emilr: is it logging attempts to connect to things?
00:19 -!- chriswang2019 [~Mutter@61.144.119.144] has quit [Remote host closed the connection]
00:23 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection]
00:25 < 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
00:32 < 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
00:35 < gmaxwell> emilr: if it's onlynet=onion it'll only store onion peers 
00:38 < wumpus> right, it discovers only .onion if that't the only enabled network
00:41 < emilr> makes sense, although other onlynet=tor nodes I ran had clearnet peers as well but those nodes weren't so isolated from clearnet
00:44 < DeanGuss> onlynet=onion is the only thing that works, not onlynet=tor -- is that why maybe it is ignoring your onlynet=tor ?
00:44 < 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
00:44 < wumpus> onlynet=tor works too, it's equivalent
00:45 < DeanGuss> huh.  ok, I thought it didn't but I only tried a few releases ago
00:46 < 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
00:50 < wumpus> (onlynet isn't mentioned in doc/tor.md btw; would make sense to do so)
01:18 -!- ccdle12 [~ccdle12@223.197.137.165] has quit [Read error: Connection reset by peer]
01:18 -!- ccdle12 [~ccdle12@223.197.137.165] has joined #bitcoin-core-dev
01:22 < 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.
01:27 < 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
01:27 < jonasschnelli> what could be the reason for a null leveldb obfuscation key?
01:28 < jonasschnelli> Using obfuscation key for /btc/data/bitcoin/blocks/index: 0000000000000000
01:31 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:34 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:35 < wumpus> jonasschnelli: the block index isn't obfuscated is it? just the utxo set
01:36 < jonasschnelli> wumpus: Oh. NM. I missread it (was confused by an empty key)
01:37 -!- ccdle12 [~ccdle12@223.197.137.165] has quit [Ping timeout: 245 seconds]
01:38 -!- ccdle12 [~ccdle12@223.197.137.165] has joined #bitcoin-core-dev
01:40 < kallewoof> wumpus: Oh, okay. Thanks
01:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
01:44 < wumpus> kallewoof: I think the only commonality is that it both involves some kind of loop for key-stretching
01:46 < 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.
01:52 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
01:53 < wumpus> it uses a standard mechanism at least
02:02 < 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
02:04 < kallewoof> I won't! Thanks
02:18 < 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
02:19 < wumpus> huh, I believe we didn't update the hardcoded seeds for 0.18
02:20 < wumpus> emilr: it shouldn't hold up network negotiation on disk access, does it time out on something?
02:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:25 < bitcoin-git> [bitcoin] MeshCollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6a135fbe5b30...f6120d40d583
02:25 < bitcoin-git> bitcoin/master 7a9046e John Newbery: [wallet] Refactor CWalletTx::RelayWalletTransaction()
02:25 < bitcoin-git> bitcoin/master f6120d4 MeshCollider: Merge #15728: [wallet] Refactor relay transactions
02:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:26 < 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
02:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:27 < 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
02:27 -!- jonatack [d598a24a@gateway/web/freenode/ip.213.152.162.74] has joined #bitcoin-core-dev
02:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:29 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Ping timeout: 250 seconds]
02:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:30 < bitcoin-git> [bitcoin] MeshCollider pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/f6120d40d583...c536dfbcb00f
02:30 < bitcoin-git> bitcoin/master fbc6bb8 Russell Yanofsky: bitcoin-wallet tool: Drop MakeChain calls
02:30 < bitcoin-git> bitcoin/master b874747 Russell Yanofsky: Remove access to node globals from wallet-linked code
02:30 < bitcoin-git> bitcoin/master 78a2fb5 Russell Yanofsky: bitcoin-wallet tool: Drop libbitcoin_server.a dependency
02:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:30 < wumpus> that's interesting, which rpi are you using?
02:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:31 < 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
02:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:31 < 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
02:31 < wumpus> (well, maybe slower, but not thus slow it's self-sabotaging)
02:33 -!- ccdle12 [~ccdle12@223.197.137.165] has quit [Remote host closed the connection]
02:33 < emilr> 3B+, I'm guessing it's not an issue if you don't sync over tor
02:33 < 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
02:33 < wumpus> I do
02:33 < wumpus> but it's been a while, could try again
02:34 < wumpus> first, seeds update for 0.18..
02:39 -!- rex4539 [~rex4539@2a02:587:3511:5a00:1d87:a47e:b8fe:bfb8] has quit [Quit: rex4539]
02:40 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection]
03:03 -!- jonatack [d598a24a@gateway/web/freenode/ip.213.152.162.74] has quit [Ping timeout: 256 seconds]
03:12 -!- gelmutshmidt [~gelmutshm@188.113.22.211] has joined #bitcoin-core-dev
03:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:19 < 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
03:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:36 < wumpus> ok something strange is happening here
03:36 < wumpus> it looks like sipa's seed does return onion peers but somehow, makeseeds.py throws all of them out
03:39 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has joined #bitcoin-core-dev
03:42 < 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
03:43 < wumpus> but why this is suddenly an issue I don't know, maybe tor was down for a while on the crawler?
03:45 -!- profmac [~ProfMac@2001:470:1f0f:226:4486:edcd:5c56:c311] has quit [Ping timeout: 250 seconds]
03:49 < emilr> pubmsg: or due to the fact that the number of peers increased pushing onions even further down the list, I'll check
03:51 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:52 < emilr> pubmsg: whats up with 450k seeds?, lol 
03:58 -!- profmac [~ProfMac@2001:470:1f0f:226:e941:42df:c6c2:47d3] has joined #bitcoin-core-dev
04:15 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #bitcoin-core-dev
04:15 < wumpus> added stats https://github.com/bitcoin/bitcoin/pull/15791#issuecomment-482072722
04:16 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
04:16 -!- harrymm [~harrymm@209.58.188.77] has quit [Ping timeout: 258 seconds]
04:21 < wumpus> maybe change the uptime requirement for onions?
04:23 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
04:24 < wumpus> bah, even changing it to 25% with no other changes only gives 10 onions
04:26 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
04:27 -!- rex4539 [~rex4539@athedsl-171280.home.otenet.gr] has joined #bitcoin-core-dev
04:27 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 245 seconds]
04:29 -!- harrymm [~harrymm@209.58.188.77] has joined #bitcoin-core-dev
04:31 < wumpus> it's better than nothing, I guess
04:31 < emilr> pubmsg: I think the whole process needs a bit of rework, I wouldn't trust whatever list the script generates
04:36 < 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
04:36 -!- chriswang2019 [~Mutter@223.104.64.211] has joined #bitcoin-core-dev
04:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:43 < 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
04:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:45 -!- chriswang2019 [~Mutter@223.104.64.211] has quit [Quit: Mutter: www.mutterirc.com]
04:46 -!- chriswang2019 [~Mutter@223.104.64.211] has joined #bitcoin-core-dev
04:48 -!- chriswang2019 [~Mutter@223.104.64.211] has quit [Client Quit]
05:01 < 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
05:02 < wumpus> in itself, 50% uptime is a reasonable requirement
05:05 < wumpus> even using grep directly on the downloaded input I cannot corabborate your claim that "version 17.0 has 120ish onion peers"
05:05 < wumpus> grep \.onion seeds_main.txt|grep "/Satoshi:0.17" -> one result
05:07 < wumpus> unless you have a different source? if so, please let me know
05:11 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-lajetrfezxisickr] has quit [Ping timeout: 252 seconds]
05:11 -!- DavidMitchell[m] [davidfedii@gateway/shell/matrix.org/x-wvgkoassdosngyif] has quit [Ping timeout: 240 seconds]
05:11 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-ibznohmkvugkqpop] has quit [Ping timeout: 252 seconds]
05:12 -!- stepa[m] [stepamatri@gateway/shell/matrix.org/x-ksbuhrmqikrnxqiu] has quit [Ping timeout: 252 seconds]
05:12 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-rgtboodqstzgmxkm] has quit [Ping timeout: 264 seconds]
05:16 < emilr> sorry, what I meant is that bitcoin core 0.17 has 120 hardcoded onion peers
05:21 < wumpus> oh!
05:21 < wumpus> yes, I misunderstood your sentence then
05:22 < 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
05:23 < 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
05:25 < wumpus> right
05:51 < emzy> how do I generate the seed.txt.gz file?
05:52 < emzy> ok found it: https://github.com/sipa/bitcoin-stats/blob/b1690b87a781a2bdd1b5f7e6fa284e1bc0e50541/update.sh#L104
05:55 < 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
05:55 < wumpus> emilr: interesting
06:03 < 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 ?
06:04 < emzy> I have no .onion
06:08 < wumpus> heh
06:10 < emzy> no idea what's the problem
06:10 < wumpus> emilr: i don't think "has all nodes since 2013" is true
06:11 < wumpus> for example the list doesn't include anything with zero uptime in last 30 days
06:12 < wumpus> and that would be *many* if so
06:12 < 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
06:12 < emilr> wumpus: thats because once a server goes stale, it keeps it's uptime history
06:14 < wumpus> in any case, for better or worse, everyting in the hardcoded seeds, ever, has come from sipa's crawler up to now
06:14 < wumpus> I think that's acceptable because it's only a fallback
06:17 < emilr> just check block height 2624 top nodes at 562647, and 4281 at 562646, that's the last time the list was updated
06:18 < 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)
06:20 < emilr> I didn't crawl, I downloaded http://bitcoin.sipa.be/seeds.txt.gz as per README
06:20 < wumpus> oh, sorry, that was meant for emzy
06:22 < emzy> wumpus: no, I have no crawler for tor configures. But a tor is running on the server. 
06:22 < emzy> wumpus: do you have a readme for the crawler setup for me>
06:23 < wumpus> no, I don't
06:24 < wumpus> `bitcoin-seeder --help` seems to return some options https://github.com/sipa/bitcoin-seeder/blob/master/main.cpp#L37
06:24 < wumpus> (if that's what you're using)
06:24 < emzy> I will try -o
06:29 < emzy> It worked!
06:29 < wumpus> awesome!
06:31 < emzy> I will wait a litte. to get the seeds.txt filled.
06:50 < emzy> 81 .onion
06:51 < emzy> # zgrep \.onion seeds.txt.gz|grep "/Satoshi:0.17" | wc -l   ->>> 66
06:51 -!- chriswang2019 [~Mutter@223.104.64.211] has joined #bitcoin-core-dev
06:54 -!- chriswang2019 [~Mutter@223.104.64.211] has quit [Remote host closed the connection]
06:56 < Sentineo> we need 600 more :)
06:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:57 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c536dfbcb00f...570eb7b130c2
06:58 < bitcoin-git> bitcoin/master 0b3a654 Peter Bushnell: Avoid redefine warning
06:58 < bitcoin-git> bitcoin/master 570eb7b Wladimir J. van der Laan: Merge #15782: Avoid redefine warning
06:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:58 < bitcoin-git> [bitcoin] laanwj merged pull request #15782: Avoid redefine warning (master...warning-redefine) https://github.com/bitcoin/bitcoin/pull/15782
06:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:03 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/570eb7b130c2...bb68abe784b9
07:03 < bitcoin-git> bitcoin/master 303372c Carl Dong: docs: Improve netaddress comments
07:03 < bitcoin-git> bitcoin/master bb68abe Wladimir J. van der Laan: Merge #15718: docs: Improve netaddress comments
07:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:04 < bitcoin-git> [bitcoin] laanwj merged pull request #15718: docs: Improve netaddress comments (master...2019-04-netaddr-comments) https://github.com/bitcoin/bitcoin/pull/15718
07:04 -!- ranefer [~ranefer@2601:281:c000:b92:6438:3b6e:cad9:95] has joined #bitcoin-core-dev
07:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:06 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:16 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #15779: test: Add wallet_balance benchmark (master...1904-benchWallet) https://github.com/bitcoin/bitcoin/pull/15779
07:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:25 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4]
07:53 < stevenroose> "private key in base58-encoding" means WIF format, right?
07:53 < stevenroose> that's a cite from signrawtransactionwithkey
07:55 -!- jarthur [~jarthur@2605:6000:1019:41ab:f1f2:4a65:98ca:904e] has joined #bitcoin-core-dev
07:55 < sipa> stevenroose: yes
08:07 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:16 -!- provoostenator [~vwDZ2BYsc@2a05:d014:5f:e100:fd30:8af7:2d6a:cbb1] has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
08:17 -!- provoostenator [~vwDZ2BYsc@2a05:d014:5f:e100:fd30:8af7:2d6a:cbb1] has joined #bitcoin-core-dev
08:19 -!- jarthur [~jarthur@2605:6000:1019:41ab:f1f2:4a65:98ca:904e] has quit [Remote host closed the connection]
08:19 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
08:27 -!- jarthur [~jarthur@2605:6000:1019:41ab:f1f2:4a65:98ca:904e] has joined #bitcoin-core-dev
08:35 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
08:53 -!- jarthur [~jarthur@2605:6000:1019:41ab:f1f2:4a65:98ca:904e] has quit [Remote host closed the connection]
09:02 -!- jarthur [~jarthur@2605:6000:1019:41ab:24d0:8873:cd14:3e38] has joined #bitcoin-core-dev
09:06 < stevenroose> It appears that listtransactions returns a negative number of confirmatins for txs in orphaned blocks.
09:06 < stevenroose> Is this the case for other calls as well? I.e. should a client expect signed numbers always for confirmations?
09:07 < sipa> negative numbers indicate how deep the conflict is
09:08 < stevenroose>     return ((nIndex == -1) ? (-1) : 1) * (chainActive.Height() - pindex->nHeight + 1);
09:08 < stevenroose> So is that a generic thing? Like all calls can do that?
09:08 < sipa> i doubt that
09:09 < stevenroose> Like gettxout, getrawtransaction, getblockheader?
09:09 < stevenroose> Seems to come from CMerkleTx::GetDepthInMainChain
09:09 < sipa> are you sure that pindex is the block the tx is included in here?
09:09 < sipa> i think it's the block the _conflict_ is included in
09:10 < sipa> just an orphaned transaction should have 0 confirmations
09:10 < sipa> it's only when a doublespend of it gets confirmed that you get negative numbers
09:12 < sipa> gettxout only applies to actually existing UTXOs, so negative confirmations don't make sense there
09:12 < sipa> same for getrawtransaction
09:14 < sipa> and it doesn't apply at all to blocks
09:24 < wumpus> CMerkleTx is only used from the wallet; it'll be wallet calls at most that use that convention
09: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
09:31 -!- inersha [~greg@193.28.36.25] has joined #bitcoin-core-dev
09:33 -!- inersha [~greg@193.28.36.25] has left #bitcoin-core-dev []
09:43 -!- jarthur [~jarthur@2605:6000:1019:41ab:24d0:8873:cd14:3e38] has quit [Remote host closed the connection]
09:45 -!- jarthur [~jarthur@2605:6000:1019:41ab:24d0:8873:cd14:3e38] has joined #bitcoin-core-dev
09:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:55 < 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
09:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:02 < 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
10:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:16 < 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
10:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:24 < bitcoin-git> [bitcoin] MarcoFalke pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/bb68abe784b9...0e9cb2d24dbf
10:24 < bitcoin-git> bitcoin/master fa4680e MarcoFalke: scripted-diff: Rename sync_blocks to send_blocks to avoid name collisions ...
10:24 < bitcoin-git> bitcoin/master fafe008 MarcoFalke: test: Pass at most one node group to sync_all
10:24 < bitcoin-git> bitcoin/master fa6dc7c MarcoFalke: test: Add BitcoinTestFramework::sync_* methods
10:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:25 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15773: test: Add BitcoinTestFramework::sync_* methods (master...1904-qaSyncNew) https://github.com/bitcoin/bitcoin/pull/15773
10:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:28 < 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
10:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:46 < 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
10:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:47 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
10:49 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
10:51 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
10:59 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
11:00 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cuaqqjoxrlrhvpmj] has joined #bitcoin-core-dev
11:09 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
11:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:17 < bitcoin-git> [bitcoin] theuni opened pull request #15798: RFC: Rust code integration (master...with-rust-example-working) https://github.com/bitcoin/bitcoin/pull/15798
11:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:17 < cfields_> #proposedmeetingtopic Bitcoin CRust
11:17 < cfields_> #proposedmeetingtopic Potential platform deprecation
11:17 < luke-jr> Bitcoin CRust?
11:18 < luke-jr> are we deprecating Windows? :p
11:18 < cfields_> luke-jr: Heh. I have some proposals, but afaik we don't really have any policy. Figure it's worth discussing.
11:39 < wumpus> there was also a discussion about --disable-asm IIRC
11:42 < luke-jr> I don't really see what there is to discuss on that?
11:45 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:50 < MarcoFalke> There was some discussion in #13788, which is why it was removed from the 0.17. milestone
11:50 < 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
11:51 < 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.
11:52 < 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
11:57 < sipa> luke-jr: i'm just unclear on the goal?
11:58 < 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
11:58 < gmaxwell> disable machine specific crap that breaks weirdo compilers
11:59 < wumpus> working around build problems, and analysis tooling, basically
11:59 < sipa> the option was originally introduced because of (a), but i think that goal is gone
11:59 < gmaxwell> b/c.
11:59 < gmaxwell> yea, not a
11:59 < sipa> if it's for b/c both, it shouldn't be called asm
11:59 < gmaxwell> speaking of a, we don't enable asm for libsecp256k1 in the bitcoin core build, do we?
11:59 < 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
12:00 < wumpus> gmaxwell: it does afaik
12:00 < sipa> gmaxwell: pretty sure we do, but not the arm asm
12:00 < wumpus> of course not the ARM asm :)
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Apr 11 19:00:25 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < wumpus> #topic 0.18.0
12:01 < wumpus> so it turns out we need another rc
12:01 < kanzure> hi
12:02 < 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
12:02 < wumpus> (for #15776)
12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/15776 | Expire inflight GETDATA requests by ajtowns · Pull Request #15776 · bitcoin/bitcoin · GitHub
12:02 < meshcollider> hi
12:02 < jonasschnelli> hi
12:02 < achow101> hi
12:02 < jamesob> hi
12:02 < cfields_> hi
12:02 < wumpus> the schedule was to tag final today, but we're not going to make that then I guess
12:02 < luke-jr> hi
12:02 < wumpus> let's at least tag a new rc?
12:02 < meshcollider> In that case, I think we should also backport #15749 ?
12:02 < 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
12:03 < MarcoFalke> wumpus: nothging changed since rc3?
12:03 < sipa> 15776 is not yet merged
12:03 < wumpus> MarcoFalke: after 15776 ofc
12:03 < MarcoFalke> oh
12:03 < MarcoFalke> Doesn't look like it was reviewed
12:04 < wumpus> meshcollider: yea if all kinds of other bugs were found since, makes sense to include them
12:04 < wumpus> ok
12:04 < wumpus> well, 0.18.0 will be delayed a bit that's clear at least
12:04 < luke-jr> no big deal imo
12:05 < jonasschnelli> yes. acceptable
12:05 -!- ranefer [~ranefer@2601:281:c000:b92:6438:3b6e:cad9:95] has quit [Ping timeout: 268 seconds]
12:06 < wumpus> no, it doesn't really matter, though I think review should focus on those PRs then
12:06 < sipa> agree
12:07 < wumpus> added #15749 to needs backport to 0.18.0
12:07 < 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
12:08 < meshcollider> thanks
12:08 < wumpus> #topic Bitcoin CRust (cfields_)
12:09 < jnewbery> I'd request that #15750 gets considered for inclusion in the next rc. It completes a fix that is already in 0.18
12:09 < 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
12:09 < jeremyrubin> Hi! Also present 
12:10 < instagibbs> hi
12:10 < luke-jr> jnewbery: that looks like removal of an API, not a fix; I don't really care though
12:10 < luke-jr> better to remove in 0.18.0 than 0.18.1
12:10 < cfields_> ah, sorry, irc went weird for me.
12:10 < 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.
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/15798 | RFC: Rust code integration by theuni · Pull Request #15798 · bitcoin/bitcoin · GitHub
12:11 < wumpus> jnewbery: looks like it's somewhat controversial, any reason to not do this for 0.19 instead?
12:11 < 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
12:11 < MarcoFalke> jnewbery: There shouldn't be any cost to only remove it in 0.19.0
12:11 < jonasschnelli> Nice work jnewbery and cfields_!
12:11 < jonasschnelli> luke-jr: it's an experiment AFAIK
12:11 < kanzure> which third party library is that
12:11 < wumpus> I really like the rust work
12:11 < jnewbery> Because the deprecation warning in the RPC help text is removed in 0.18
12:11 < luke-jr> jonasschnelli: experiments can be done outside Core
12:11 < cfields_> luke-jr: there are people working on that. This is experimental. This discussion is not helpful at this time.
12:11 < kanzure> you mean the rust binary?
12:12 < wumpus> jnewbery: wha-why ?
12:12 < luke-jr> kanzure: yes, rustc
12:12 < jonasschnelli> luke-jr: read the PR desc
12:12 < MarcoFalke> luke-jr: Bitcoin is experimental
12:12 < cfields_> luke-jr: it says right there. NOT FOR MERGE.
12:12 < cfields_> caps and everything :)
12:12 < jeremyrubin> luke-jr: did you see Marco's bootstrapping link as well?
12:12 < wumpus> it's an experiment, but it's good to have people aware of it
12:12 < cfields_> anyway, I'd like to get some feedback from people who have actually used rust.
12:12 < instagibbs> you'd want to ping #rust-bitcoin folks
12:13 < dongcarl> Hi
12:13 < luke-jr> jeremyrubin: as I understand it, mrustc only works on x86
12:13 < wumpus> dongcarl: ^^
12:13 < jamesob> rust is a pleasure to write - beyond that I don't have much input
12:13 < jonasschnelli> I don't disagree with luke-jr concerns,.. but an experiments needs to start somewhere and Rust will evolve over time
12:13 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
12:13 < kanzure> don't we also use other compilers in deterministic builds..?
12:13 < jeremyrubin> luke-jr: can you not cross compile after bootstrap? Do you want to bootstrap on every platform?
12:13 < MarcoFalke> Yeah, it is good to see that the build system changes are smaller than anyone expected
12:13 < jeremyrubin> Anyways, as noted, this is just for enabling more experimentation
12:14 < cfields_> luke-jr's complaint has been heard. Let's move on please.
12:14 < gmaxwell> yeah, its not a for merge thing. Useful announcement.
12:14 < luke-jr> kanzure: hopefully we are moving away from that
12:14 < dongcarl> perhaps a good question is what parts of the code is memory safety the most critical 
12:15 < wumpus> anything that interfaces to the hostile outside world (e.g. P2P code)
12:15 < 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)
12:15 < MarcoFalke> The parts that are not going to be rewritten in rust any time soon ;)
12:15 < cfields_> dongcarl: yes. also, what things are in-spec in rust that can only be undefined in c/c++.
12:15 < MarcoFalke> dongcarl: ^
12:15 < instagibbs> MarcoFalke, hah!
12:16 < 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
12:16 < jamesob> but that's obviously pretty speculative...
12:16 < wumpus> that's a pretty neat idea
12:16 < sipa> i don't understand the appeal of that idea
12:17 < sipa> the complexity is all in the interaction between network code and the rest
12:17 < meshcollider> I remember him bringing that up in tokyo
12:17 < jamesob> two is one and one is none, I guess
12:17 < 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
12:17 < sipa> not in the network code itself
12:17 < luke-jr> jamesob: sounds more complex to detect "weird" than to just replace it
12:18 < jamesob> luke-jr: could be
12:18 < cfields_> sipa: I would think something like a rust-libevent would be pretty appealing. But yeah, that's a layer below us.
12:18 < wumpus> it's not so much about the complexity I think, but potential safety issues, rust would be safer for the network code
12:18 < luke-jr> if someone is compromising the original network stack, they can probably corrupt the alternate one too
12:18 < sipa> wumpus: in a way that we've actually ever had problems?
12:18 < cfields_> It's also worth considering that new tools could be written in rust. Doesn't have to be direct bitcoind integration.
12:19 < luke-jr> rewrite the node around libconsensus? ;)
12:19 < 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)
12:19 < wumpus> sipa: that we haven't noticed any problems doesn't mean that they don't exist, but sure...
12:19 < 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
12:19 < wumpus> a lot of this is to rule out entire bug classes, not just to fix bugs that we've found
12:19 < sipa> wumpus: while introducing a complexity in making the two layers communicate 
12:20 < wumpus> so in a sense it's speculative
12:20 < MarcoFalke> Doesn't rust fix uninitizlized reads? #14728
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/14728 | fix uninitialized read when stringifying an addrLocal by kazcw · Pull Request #14728 · bitcoin/bitcoin · GitHub
12:20 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 268 seconds]
12:20 < dongcarl> Perhaps another useful property: Safe Rust guarantees an absence of data races.
12:20 < MarcoFalke> #6636
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/6636 | net: correctly initialize nMinPingUsecTime by laanwj · Pull Request #6636 · bitcoin/bitcoin · GitHub
12:20 < 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.
12:20 < wumpus> rust fixes undefined behavior at least,we've had plenty of that reported
12:20 < jeremyrubin> I think fixing some of the internal concurrent workers would be a good task
12:20 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
12:20 < jeremyrubin> E.g., the CheckQueue or Task QUeue
12:20 < 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
12:20 < cfields_> gmaxwell: for now.
12:20 < jeremyrubin> As that can just be treated as a scheduler
12:20 < gmaxwell> Put it this way, however: I would much rather be linking a upnp library written in rust.
12:21 < sipa> but i have no interest in seeing bitcoin core becoming developed in a mix of languages
12:21 < jamesob> sipa: +1
12:21 < meshcollider> Agreed
12:21  * cfields_ banishes sipa from the testing framework :p
12:21 < wumpus> it'd be somewhat confusing, though I'd personally be happy to move away from c++, I've really grown to dislike it
12:21 < gmaxwell> testing framework being written in another language has a non-trivial cost. (not that I'd suggest otherwise!)
12:21 < cfields_> (That was a joke, I realize it's not the same thing)
12:22 < jamesob> cfields_: I'm working on a c++ rewrite as we speak
12:22 < sipa> wumpus: i realize that; but bitcoin core is a c++ project with c++ reviewers
12:22 < wumpus> sipa: yes, maybe it means I need to move to rust-bitcoin :-)
12:22 < 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.
12:22 < wumpus> anyhow, this is an experiment, I don't think merging it is even a question right now
12:22 < MarcoFalke> A lot of the reviewers know rust or wouldn't have a problem learning it
12:23 < 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. :(
12:23 < 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
12:23 < 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?
12:23 < wumpus> cfields_: yes
12:23 < meshcollider> Review quality would definitely go down if people are new to the language
12:23 < luke-jr> gmaxwell: if only everything used the same ABI
12:23 < cfields_> sipa: very fair point.
12:23 < jeremyrubin> Expertise in rust is easier to attain than c++
12:23 < jeremyrubin> The compiler catches most of the stuff you spend time revieiwing in c++ anyways
12:24 < wumpus> cfields_: as said I'm happy to maintain that branch
12:24 < 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.
12:24 < cfields_> wumpus: ok, great, you're welcome to take it over.
12:25 < wumpus> gmaxwell: concurrent programming should be more straightforward in rust at least
12:25 < gmaxwell> wumpus: somewhat, but the problems we have like invisible queues that grow unboundedly exist exactly the same in rust.
12:25 < wumpus> a lot of the boilerplate we're introducing in bitcoin for queues, asyn handling,et c is simply part of rust already
12:26 < wumpus> gmaxwell: yes, no one is claiming it would eliminate all problems automatically, that would have been great
12:26 < gmaxwell> It's a lot easier to avoid writing data races, however, indeed
12:26 < gmaxwell> wumpus: not all problems, of course... but the problems we actually end up shipping.
12:26 < wumpus> right
12:27 < 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
12:27 < sipa> i'm not; but it's a discussion to be had when there is code to include
12:27 < wumpus> yes
12:28 < gmaxwell> As I said before, I'd be much happier with a rust miniupnp than miniupnp.
12:28 < jonasschnelli> Let it be an experiment
12:28 < wumpus> so let's start with miniupnp
12:28 < gmaxwell> So certantly not 100% against it.
12:28 < 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
12:28 < wumpus> happy to write that in rust :)
12:28 < dongcarl> I can get boostrap working
12:28 < sipa> i'd be even happier with a minimal c++ reimplementation of miniupnp :p
12:28 < sipa> (but i have no problem with a rust one if it would exist)
12:29 < wumpus> you really want to make another c++ upnp implementation?
12:29 < sipa> and it's great that the build system issues are already out of the way
12:29 < jeremyrubin> So now that we have the demo build, someone can more easily show us motivation
12:29 < jeremyrubin> It's also good to know that rust work won't be shot down purely on the "another language" basis
12:29 < 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)
12:29 < 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
12:30 < gmaxwell> jeremyrubin: has the proble of the rust ecosystem where cargo effectively forces you into getting nearly blind updates been resolved?
12:30 < sipa> i think we have a pretty good track record wrt the kind of bugs that miniupnp has
12:30 < wumpus> you mean, xml parsing?
12:30 < sipa> memory safety
12:30 < wumpus> nah
12:31 < 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.
12:31 < gmaxwell> s/ping/pin/
12:31 < jeremyrubin> gmaxwell: I'm not sure? Crates.io is supposed to be append only
12:31 < sipa> wumpus: how so?
12:31 < jeremyrubin> gmaxwell: cargo also just added the ability to have your own crate registry, which would help
12:31 < wumpus> sipa: just having a good track record doesn't guarantee anything
12:32 < sipa> wumpus: of course
12:32 < jeremyrubin> gmaxwell: in the PR, I manually pinned the one dep (a build tool to auto-gen headers)
12:32 < wumpus> it doesn't mean you can do arbitrarily complex things and avoid bugs
12:32 < 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)
12:32 < jeremyrubin> gmaxwell: I think what grin does is not update the compiler -- just fix the version to a known stable or nightly 
12:33 < luke-jr> is it even possible to have multiple versions of Rustc installed on most distros?
12:33 < 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.
12:33 < jeremyrubin> gmaxwell: updating to a new compiler can be annoying for anything
12:33 < jeremyrubin> luke-jr: yes look at the rustup toolchain manager
12:33 < gmaxwell> luke-jr: the tooling makes it possible to do that, yes.
12:33 < 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
12:33 < 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
12:33 < jeremyrubin> gmaxwell: yeah -- it's a pity rust is adding so many exciting new features ;) 
12:33 -!- cfields_ [~cfields@unaffiliated/cfields] has quit [Quit: cfields_]
12:34 < wumpus> it's pretty much outside all our expertise
12:34 < sipa> but the whole question is pointless without an actual package to discuss
12:34 < wumpus> yes
12:34 -!- cfields [~cfields@unaffiliated/cfields] has joined #bitcoin-core-dev
12:35 < wumpus> (this is besides the rust issue btw)
12:35 < cfields> Sorry, was laggy, had to switch servers.
12:35 < 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).  
12:35 < wumpus> I think using it for non-optional functionality is a bad idea right now
12:37 < wumpus> agree on gmaxwell's comments re: cargo
12:37 < cfields> gmaxwell: #1 is unfair and not worth discussing imo unless people are going to scream about us using ubuntu's toolchain as well.
12:37 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
12:37 < 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.
12:37 < luke-jr> cfields: people who build their own bitcoind *don't* need to use Ubuntu's toolchain
12:37 < gmaxwell> cfields: we do use a toolchain that can be bit identically produced by many hetrogenious toolchains.
12:38 < jeremyrubin> gmaxwell: for 2, there are a lot of things that could be done w/o external deps
12:38 < luke-jr> gmaxwell: UPnP might be generic enough that non-Bitcoin devs are interested too
12:38 < 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)
12:38 < gmaxwell> luke-jr: exactly.
12:39  * dongcarl agrees, but needs help
12:39 < 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.
12:39 < cfields> Grr, I swore I wasn't going to take the bait on this :p
12:39 < wumpus> apparently there are already some projects to implement upnp in rust
12:39 < gmaxwell> cfields: I yield, I don't really need to argue this with you right now.
12:39 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
12:39 < wumpus> in any case -- let's move to other topics, this isn't so urgent now
12:39 < jnewbery> Can I quickly get back to #15750?
12:39 < gmaxwell> cfields: we can agree that there are at least concerns there, even if we disagree how much its really any different.
12:39 < 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
12:39 < wumpus> #topic Remove addresses field in getaddressinfo
12:40 < jnewbery> The addresses field was marked deprecated in v0.17 along with other changes to validateaddress and getaddressinfo (#10583)
12:40 < gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
12:40 < jnewbery> #12490 (V0.18) should have removed the all deprecated functionality (and depracation notes). This part was missed out.
12:40 < 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
12:40 < 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.
12:40 < jnewbery> So #15750 should fully remove it in v0.18.
12:40 < 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
12:40 < gmaxwell> cfields: +1000
12:40 < gmaxwell> cfields: thanks for bringing it up
12:40 < 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.
12:40 -!- ranefer [~ranefer@2601:281:c000:b92:6438:3b6e:cad9:95] has joined #bitcoin-core-dev
12:40 < wumpus> jnewbery: I agree
12:41 < 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.
12:41 < sipa> jnewbery: his comments also seem to be about the move from validateaddress to getaddressinfo in the first place
12:41 < sipa> which if anything are far too late
12:41 < luke-jr> jnewbery: "bugfixes only during RCs" is not "NEVER CHANGE RPCS"
12:41 < gmaxwell> It's unclear to me if he just needs help phrasing his argument.
12:41 < gmaxwell> But I agree the argument as stated should be ignored.
12:41 < wumpus> jnewbery: I was just reasoning 'what would it hurt to move this to 0.19', not trying to argue against the change!
12:41 < jnewbery> Right, I don't think he's concerned about this particular field
12:42 < wumpus> luke-jr: right
12:42 < instagibbs> 0.17 breakages were heavier than in the past fwiw
12:42 < 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.
12:42 < instagibbs> not complaining, we just have delayed upgrading on some stuff due to it, which is fine
12:42 < jnewbery> The problem is that the deprecation notice goes away in v0.18
12:42 < wumpus> gmaxwell: yes, would make sense to add documentation for that
12:42 < gmaxwell> (life would be better if bug reporters were assigned a lawyer)
12:42 < sipa> gmaxwell: i'm... not sure
12:42 < wumpus> (which is also what I noted in the PR)
12:42 < instagibbs> are we suing people when they file issues :)
12:43 < MarcoFalke> no, they sue us
12:43 < 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.
12:43 < sipa> ah yes
12:43 < jnewbery> my point is that we should remove all of the deprecated parts of `deprecatedrpc=validateaddress` in one release or none at all
12:43 < luke-jr> we can always say "use 0.17 until you're ready" too
12:43 < achow101> jnewbery: ack
12:43 < jeremyrubin> instagibbs: is the issue csw not being satoshi
12:43 < sipa> jnewbery: i agree; but i also think it's a minor enough thing
12:44 < jnewbery> Yeah, I wouldn't bring it up if we weren't already doing another rc
12:44 < wumpus> yes, I don't care deeply either way, it just seems to cause a lot of discussion
12:45 < gmaxwell> when in doubt, add docs.
12:45 < wumpus> yes
12:46 < 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
12:46 < gmaxwell> in any case, we should also consider it a good sign that we're getting compat complaints now.  None is the wrong number.
12:46 < wumpus> anyhow added "needs backport" for now
12:46 < jnewbery> wumpus: thanks!
12:46 < gmaxwell> sipa: thanks, will do
12:47 < sipa> achow101: in particular, i think the new psbt descriptions could use slightly more text
12:47 < wumpus> sipa: good idea
12:47 < sipa> *new psbt rpcs
12:47 < achow101> sipa: I can take a look at those
12:48 < wumpus> yes, as a general concept, documentation belongs in the doc/ folder, not in the release notes, could always add a link :)
12:48 < sipa> so also have a look at the updates in doc/psbt.md :p
12:48 < wumpus> it's good to meantion things in the release notes but indeed not to be too wordy
12:49 < wumpus> ok, cfields had another topic
12:49 < wumpus> #topic Platform deprecation (cfields)
12:49 < wumpus> sipa: will do
12:49 < 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 
12:49 < cfields> platforms worth the effort?
12:49 < 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
12:49 < wumpus> which platform?
12:50 < sipa> are all newly sold x86 CPUs these days 64-bit?
12:50 < wumpus> yess since 2005 or so?
12:50 < sipa> and do people run 64-bit OSes on them?
12:50 < cfields> sipa: I would think anything running windows especially.
12:50 < wumpus> for windows: yes
12:50 < sipa> (i have no clue about the windows ecosystem in this regard)
12:50 < gmaxwell> yes, though all still also capable of running in 32bit mode.
12: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 ?
12:51 < 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.
12:51 < cfields> luke-jr: see link above, I don't recall off the top of my head.
12:51 < gmaxwell> (e.g. two-ish years ago the default fedora download was 32-bit, in part because of compatiblity with #$@# binary only browser extensions)
12:51 < wumpus> 100% behind deprecating windows 32-bit
12:52 < jonasschnelli> me 2
12:52 < 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. :)
12:52 < 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…
12:52 < jonasschnelli> just don't deprecate the ARM 32bits
12:52 < wumpus> oh no not ARM
12:52 < wumpus> I mean x86
12:52 < cfields> jonasschnelli: right.
12:52 < wumpus> windows
12:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:53 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15799: doc: Clarify RPC versioning (master...1904-docRPC) https://github.com/bitcoin/bitcoin/pull/15799
12:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:53 < meshcollider> Does that clean up any existing windows-only code or just for later
12:53 < wumpus> and for 0.19
12:53 < achow101> Windows does have 32 bit version still
12:53 < wumpus> meshcollider: I don't think it cleans up any code tbh
12:54 < cfields> Great, that was easy :)
12:54 < wumpus> it just leaves oneless configuration to maintain and test
12:54 < wumpus> which is good
12:54 < jeremyrubin> Is anyone even testing 32-bit windows?
12:54 < wumpus> no.
12:54 < jonasschnelli> I do
12:54 < cfields> wumpus: it's also the one that takes _forever_ to run.
12:54 < wumpus> oh!
12:54 < jonasschnelli> (VM though)
12:54 < luke-jr> maybe we should solicit feedback somehow?
12:54 < 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 
12:54 < gmaxwell> ^ fantastic!
12:54 < luke-jr> open an issue to deprecate Win32, and put it in release notes?
12:55 < gmaxwell> luke-jr: I don't disagree but it also sounds like wumpus already did previously.
12:55 < wumpus> I mean we already dropped xp and vista support, which are the most likely to be 32 bit
12:55 < luke-jr> gmaxwell: a tweet isn't as loud as release notes
12:55 < sipa> luke-jr: i suspect more people read tweets :p
12:55 < luke-jr> sipa: could be :/
12:55 < sipa> (but maybe less relevant ones)
12:55 < cfields> sipa: haha
12:55 < sipa> windows 10 still has a 32-bit version it seems
12:56 < wumpus> windows 7/8 was already mostly 64-bit, windows 10 certainly
12:56 < wumpus> yes it exists but no one uses it
12:56 < luke-jr> sipa: how many people use it?
12:56 < sipa> okay.
12:56 < sipa> luke-jr: i have no clue!
12:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:56 < 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
12:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:56 < luke-jr> I'm sure Microsoft does :P
12:57 < luke-jr> maybe we could just neglect to post the Win32 binaries for 0.18 and see who complains?\
12:57 < 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
12:57 < wumpus> +x86
12:57 < luke-jr> that way we can always upload them later if it's a problem
12:58 < meshcollider> Seems sensible
12:58 < wumpus> luke-jr: good idea
12:58 < wumpus> :D
12:58 < gmaxwell> 12:57:31 < luke-jr> maybe we could just neglect to post the Win32 binaries for 0.18 and see who complains?\
12:58 < gmaxwell> ^ I'd +1 that too
12:58 < instagibbs> wumpus, fwiw they croak when trying to run secp-zkp benchmarks too
12:58 < gmaxwell> that would be a nice way of measuring usage.
12:59 < wumpus> yes, let's do that
12:59 < wumpus> instagibbs: whoops
12:59 < 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.
12:59  * luke-jr glares at the clock
12:59 < gmaxwell> if people complain about the binaries, then we can just go ahead and post them.
12:59 < instagibbs> harding, is that a complaint ;)
12:59 < wumpus> #endmeeting
12:59 < lightningbot> Meeting ended Thu Apr 11 19:59:36 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:59 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-11-19.00.html
12:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-11-19.00.txt
12:59 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-11-19.00.log.html
12:59 < gmaxwell> harding: I think we're being serious. 
12:59 < wumpus> harding: we're serious
12:59 < harding> Ok.  I'll disable the test for win32
12:59 < luke-jr> sipa: still here? can you post on --disable-asm issue?
13:00 < 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.
13:00 < luke-jr> maybe we can rename it --disable-code-optimisations if you really don't like calling it asm
13:00 < sipa> luke-jr: or split it up
13:00 < gmaxwell> luke-jr: --boring-compiler
13:00 < luke-jr> gmaxwell: that sounds like autotools mess
13:01 < 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...
13:01 < 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.
13:01 < sipa> luke-jr: i think i don't really care enough to argue :)
13:01 < gmaxwell> the other is you're worried someone messed up the handcoded asm and introduced bugs
13:01 < luke-jr> gmaxwell: another might be if you have some very interesting compiler you don't want asm to bypass?
13:02 < luke-jr> sipa: well, apparently your last comment is being treated as a blocker :P
13:02 < MarcoFalke> Looks like a rename will please sipa
13:03 < 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
13:03 < luke-jr> release notes: I don't understand the change described in "Deprecated P2P messages"
13:04 < BlueMatt> do we have download counts/should we monitor download counts?
13:04 < luke-jr> BlueMatt: I have been fetching download counts from the PPA for a few releases now
13:04 < BlueMatt> that doesnt help much for 32-bit windows :p
13:04 < luke-jr> ah
13:05 < wumpus> so I"m removing two files from the upload: bitcoin-${VERSIONTO}-win32.zip and bitcoin-${VERSIONTO}-win32-setup.exe
13:05 < wumpus> @ harding 
13:05 < luke-jr> wumpus: well, I expect we should still build/sign them, just not upload
13:06 < wumpus> luke-jr: that's what I'm saing
13:06 < luke-jr> k
13:06 < wumpus> not changing the gitian descriptor
13:06 < wumpus> can do that for 0.19
13:07 < luke-jr> can I put FIXME notes in the relnote wiki?
13:07 < harding> wumpus: received.  Thanks; I've already patched the test and will include it with the ready-for-release PR I'm opening today.
13:07 < luke-jr> or is there a better place for that?
13:07 < wumpus> harding: thanks!
13:07 < wumpus> luke-jr: only if you intend to make the fixes yourself before final, I guess
13:08 < luke-jr> wumpus: I'd just make the fixes, if I knew what they should be
13:08 < luke-jr> wumpus: the problem is I have no idea what changed :P
13:08 < luke-jr> (which IMO indicates the release note is insufficient in describing the change)
13:09 < wumpus> would be kind of awkaard to accidentally get people's fixme's and random notes *for the release notes* into the release notes
13:09 < harding> luke-jr: do you think it should be moved to the Planned Changes section?
13:09 < wumpus> sipa: makes sense
13:09 < luke-jr> harding: if that's all it is.
13:10 < 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.
13:10 < luke-jr> hm, that would make sense
13:11 < luke-jr> yeah, I'm not seeing anything else in the git log
13:12 < 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.
13:14 < luke-jr> heh, there's already a TODO in there
13:15 < wumpus> a BIP would be the expected way I think
13:16 < luke-jr> dunno, this is just Core deciding not to support a BIP
13:16 < wumpus> true
13:16 < wumpus> it's a bit of a grey area in this case
13:17 < 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
13:17 < gmaxwell> We often decide to not support bips, less often decide to remove bips.
13:18 < wumpus> but I mean, theoretically a BIP could describe the reasons for not supporting a BIP anymore, for reconsidering its use
13:18 < luke-jr> gmaxwell: sure, but it's still an application-specific thing
13:19 < sipa> wumpus: i guess that would make sense if we believe there is a reason why others should also not support something
13:19 < wumpus> sipa: yes
13:19 < sipa> it's a proposal for improvement; if not supporting cam be argued to be an improvement, it deserves being a bip
13:19 < gmaxwell> Right, someone might want to make a case for "no one should support this"
13:19 < wumpus> so things like 'bandwidth overhead'
13:19 < wumpus> or potential privacy leaks
13:20 < luke-jr> gmaxwell: seems like a case for BIP Comments ;)
13:20 < gmaxwell> though some of the arguments are just structural, like in general returning normative or somewhat normative error codes imposes significant architecural obligations.
13:21 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
13:21 < 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.
13:30 < cfields> meshcollider: Were you going to look at getting rid of some of the win32 stuff?
13:30 < cfields> (if any)
13:31 < wumpus> I'm surprised qt still supports win32
13:31 < wumpus> though ok, qt is commonly used on embedded hardware so also not that surprised
13:31 < luke-jr> portability is (was?) kind of Qt's main selling point
13:33 < cfields> Yeah, I bet there's still a ton of embedded win32 stuff out there.
13:36 < cfields> I used embedded winxp in some microscope equipment at one point, that was wacky.
13:43 < luke-jr> but Qt did drop WinXP right?
13:43 < 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.
13:44 < cfields> Basically, I'd suggest not doing something like s/#ifdef win64/#ifdef windows/.
13:45 < luke-jr> yeah, since ppc64 is taking over /s
13:45 < cfields> Heh
13:45 < cfields> I was thinking more like their 10th attempt at an arm platform.
13:46 < wumpus> windows rv64 would be a cursed combo
13:46 < wumpus> so I think it'll happen at some point
13:47 < cfields> lol
13:49 < luke-jr> as if RISC-V isn't wide open to being closed down
13:50 < cfields> gotta gotta get up to get down.
13:50 < gmaxwell> More likely to see google or oracle produce a embrace-and-extent RV than msft these days. :P
13:51 < cfields> gmaxwell: fuchsia seems poised to help with that.
13:52 -!- jarthur [~jarthur@2605:6000:1019:41ab:24d0:8873:cd14:3e38] has quit []
13:55 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:57 < wumpus> google is definitely looking into RISC-V https://twitter.com/Kensan42/status/1110612910999511041
13:59 < wumpus> RISCV-CHERI is pretty interesting
13:59 < gmaxwell> oh is someone actually doing riscv-cheri now?!!?!?!
13:59 < gmaxwell> I was bummed when riscv didn't include cheri like features from day one, though I understood why...
14:03 < wumpus> right, would have been too complicated and experimental I think, but it might be part of the rationale behind RV128
14:08 < 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.
14:11 < 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
14:12 < 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
14:14 < wumpus> also because it can give actual timing guarantees
14:16 < anddam> has issue #1390 ever been discussed again since 2012?
14:16 < gribble> https://github.com/bitcoin/bitcoin/issues/1390 | Comply with the XDG Base Directory Specification · Issue #1390 · bitcoin/bitcoin · GitHub
14:16 < wumpus> anyhow I hope CHERI will see more adoption, it's a lot more thorough approach than trying to manually sandbox every single thing
14:17 < wumpus> anddam: no, I don't think so, though some options have been added since to put different things in different dirs
14:18 < anddam> like --datadir, --wallet and the config file one? 
14:18 < wumpus> yes and -blocksdir
14:18 < wumpus> -walletdir
14:19 < anddam> have there been rewrites of bitcoin-core in other languages?
14:19 < wumpus> it's very flexible where to put things
14:19 < 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 
14:20 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection]
14:21 < 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
14:34 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
14:51 -!- benthecarman [~benthecar@2610:130:110:1412:d1ea:944f:6788:ee5f] has joined #bitcoin-core-dev
14:54 < anddam> wumpus: yep
14:54 < anddam> wumpus: when starting bitcoin-qt does a separate bitcoind process get spawnd? 
14:54 < anddam> (I cannot start bitcoin-qt right now to check)
14:55 < anddam> I wonder how detached the Qt GUI and bitcoin core are
14:55 < sipa> anddam: no, one process
14:56 < anddam> ouch
14:56 < anddam> so not very detached
14:58 -!- benthecarman_ [~benthecar@2610:130:110:1512:f40b:3394:6043:ef4c] has joined #bitcoin-core-dev
14:59 -!- benthecarman [~benthecar@2610:130:110:1412:d1ea:944f:6788:ee5f] has quit [Quit: Leaving]
14:59 -!- benthecarman [~benthecar@2610:130:110:1412:d1ea:944f:6788:ee5f] has joined #bitcoin-core-dev
15:01 -!- benthecarman_ [~benthecar@2610:130:110:1512:f40b:3394:6043:ef4c] has quit [Client Quit]
15:01 -!- benthecarman [~benthecar@2610:130:110:1412:d1ea:944f:6788:ee5f] has quit [Client Quit]
15:04 -!- benthecarman [~benthecar@2610:130:110:1512:f40b:3394:6043:ef4c] has joined #bitcoin-core-dev
15:04 -!- benthecarman [~benthecar@2610:130:110:1512:f40b:3394:6043:ef4c] has quit [Client Quit]
15:05 -!- benthecarman [~benthecar@2610:130:110:1512:f40b:3394:6043:ef4c] has joined #bitcoin-core-dev
15:05 -!- benthecarman [~benthecar@2610:130:110:1512:f40b:3394:6043:ef4c] has quit [Client Quit]
15:09 -!- gelmutshmidt [~gelmutshm@188.113.22.211] has quit [Remote host closed the connection]
15:18 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
15:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
15:22 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:24 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
15:24 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds]
15:30 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds]
15:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:45 < bitcoin-git> [bitcoin] madeken closed pull request #15752: Remove redundant shuffle in KnapsackSolver (master...master) https://github.com/bitcoin/bitcoin/pull/15752
15:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:46 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
15:48 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 255 seconds]
15:53 -!- riperk [uid352992@gateway/web/irccloud.com/x-ipkdkamidhcxxohb] has joined #bitcoin-core-dev
16:06 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
16:21 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
16:21 -!- Netsplit *.net <-> *.split quits: emilr, gwillen, jasonzhouu, harding, dqx__, davec, hardforkthis, Madars, dgenr8
16:26 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
16:28 -!- Netsplit over, joins: harding, gwillen, jasonzhouu, hardforkthis, Madars, dqx__, emilr, davec, dgenr8
16:36 -!- TheV01d_ [thev01d@btc.mining.ga] has quit [Quit: ZNC - http://znc.in]
16:37 -!- TheV01d_ [thev01d@2001:19c0:1:801:851:ff00:1:6] has joined #bitcoin-core-dev
16:38 < luke-jr> fwiw, found a (minor?) bug in 0.18
16:39 < sipa> luke-jr: impossible!
16:39 < sipa> (because 0.18 does not exist yet)
16:41 < luke-jr> 0.18 != 0.18.0
16:44 < sipa> ah!
16:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:49 < 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
16:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:06 -!- davterra [~none@185.156.175.171] has quit [Quit: Leaving]
17:11 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
17:15 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has quit [Ping timeout: 256 seconds]
17:29 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 245 seconds]
17:38 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
17:38 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cuaqqjoxrlrhvpmj] has quit [Quit: Connection closed for inactivity]
17:39 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
17:53 -!- Demian- [~D@190.189.135.39] has joined #bitcoin-core-dev
18:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:18 < bitcoin-git> [bitcoin] JimmyMow opened pull request #15802: doc: create application support bitcoin folder (master...fix/macos-docs) https://github.com/bitcoin/bitcoin/pull/15802
18:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:19 -!- Tralfaz [~androirc@199.249.223.130] has joined #bitcoin-core-dev
18:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:42 < bitcoin-git> [bitcoin] meshcollider opened pull request #15803: [0.18] Backport 15749: importmulti only imports origin info for PKH outputs (0.18...201904_backport_15749) https://github.com/bitcoin/bitcoin/pull/15803
18:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:57 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
19:01 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
19:09 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
19:13 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
19:17 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 252 seconds]
19:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
19:48 -!- chriswang2019 [~Mutter@61.144.119.144] has joined #bitcoin-core-dev
19:51 -!- davterra [~none@185.156.175.35] has joined #bitcoin-core-dev
19:51 -!- Tralfaz [~androirc@199.249.223.130] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
19:53 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 246 seconds]
20:00 -!- chriswang2019 [~Mutter@61.144.119.144] has quit [Remote host closed the connection]
20:01 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 264 seconds]
20:07 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
20:53 -!- riperk [uid352992@gateway/web/irccloud.com/x-ipkdkamidhcxxohb] has quit [Quit: Connection closed for inactivity]
21:03 -!- brianhoffman [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer]
21:04 -!- brianhoffman [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has joined #bitcoin-core-dev
21:31 -!- ranefer [~ranefer@2601:281:c000:b92:6438:3b6e:cad9:95] has quit [Ping timeout: 250 seconds]
21:46 -!- Squidicc [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
21:46 -!- Squidicuz [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer]
22:22 -!- Demian- [~D@190.189.135.39] has quit [Quit: Leaving]
22:35 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
22:36 -!- chriswang2019 [~Mutter@61.144.119.144] has joined #bitcoin-core-dev
22:39 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
22:42 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
22:47 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Ping timeout: 252 seconds]
23:04 -!- chriswang2019 [~Mutter@61.144.119.144] has quit [Quit: Mutter: www.mutterirc.com]
--- Log closed Fri Apr 12 00:00:42 2019