--- Day changed Tue Jan 03 2017
00:00 < jonasschnelli> *25519
00:01 < wumpus> well, it's not forbidden, but I can't count them right now (my gpg is at 1.4.20, ubuntu 16.04 lts)
00:02 < jonasschnelli> Yes. It's probably to early.
00:02 < wumpus> I can look at compiling my own for 0.14, but not for 0.13.2 today
00:02 < phantomcircuit> wumpus, you can install gnupg 2.x 
00:02 < phantomcircuit> it's like gnupg-2 or something
00:02 < jonasschnelli> gpg2
00:02 < wumpus> phantomcircuit: oh!
00:03 < jonasschnelli> I may start with signing with Ed25519, just to have some variety. 
00:03 < gmaxwell> jonasschnelli: distributions ship the table version of gpg, mostly (exclusively?) so AFAICT relatively few people have it.
00:03 < wumpus> phantomcircuit: jonasschnelli: that gets me 2.1.11
00:05 < jonasschnelli> I guess for all ecdsa curves (including secp256k1) you need 2.1.16 (or 2.1.17?)
00:05 < wumpus> gah, it doesn't use the debian alternatives system though, so I have to manually patch up scripts to use gpg2 instead of gpg
00:05 < jonasschnelli> But watch out when using gpg2
00:06 < jonasschnelli> It will upgrade you .gpg folder
00:06 < jonasschnelli> And will no longer be backward comp.
00:06 < jonasschnelli> So,... make a backup first
00:06 < wumpus> oops
00:06 < jcorgan> eww     
00:06 < jonasschnelli> maybe this was too late. :)
00:06 < CodeShark> lol     
00:06 < wumpus> let's see :) I only looked at the help message, didn't encrypt anything yet
00:07 < wumpus> good, v1 still works for verifying signatures
00:08 < wumpus> I'll look at this for 0.14 okay
00:08 < jonasschnelli> Yes. No hurry.
00:08 < jonasschnelli> If secp256k1 is supported through GPG, this would allow signing over a hardware wallet without new curves added to them.
00:11 < wumpus> yea that could be interesting, though it would have to assign a single purpose to keys, don't use keys for signing that are used for bitcoin
00:11 < jonasschnelli> Yes. Indeed.
00:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
00:12 < jonasschnelli> I'd also prefer Ed25519,... not supported by (all?) available hardware wallets I guess.
00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:14 < wumpus> ed25519 would have the advantage it can be used for ssh too
00:15 < jonasschnelli> Oh. Yes.
00:15 < wumpus> (even if you compile it without openssl :p)
00:16 < jonasschnelli> Right. ed25519 & chacha20Poly1305@openssh. Nice combo.
00:17 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 264 seconds]     
00:17 < wumpus> yes     
00:18 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has joined #bitcoin-core-dev     
00:32 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:32 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/53442af0aac3...510c0d9c79a5
00:32 < bitcoin-git> bitcoin/master 9e351c9 Jonas Schnelli: SetMerkleBranch: remove unused code, remove cs_main lock requirement
00:32 < bitcoin-git> bitcoin/master 510c0d9 Jonas Schnelli: Merge #9446: SetMerkleBranch: remove unused code, remove cs_main lock requirement...
00:32 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9446: SetMerkleBranch: remove unused code, remove cs_main lock requirement (master...2016/12/merklebranch) https://github.com/bitcoin/bitcoin/pull/9446
00:59 < wumpus> uploaded binaries and pushed 0.13.2 release announcement to the mailing lists, waiting for travis on bitcoin.org (https://github.com/bitcoin-dot-org/bitcoin.org/pull/1470), feel free to get the rest of the announcement cycle started
01:02 < gmaxwell> jonasschnelli: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013397.html  A spv wallet should _never_ be showing transactions from untrusted peers.
01:02 < gmaxwell> jonasschnelli: because the peers can feed them any garbage they want and the spv client has no idea about it.
01:02 < jonasschnelli> (phonecall, will response soon)
01:04 < gmaxwell> and you get lovely results like https://people.xiph.org/~greg/21mbtc.png
01:08 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
01:08 < sipa> gmaxwell: but what if you trust a peer enough to not relay invalid txn, but not enough to not spy on you?
01:08 < jonasschnelli> gmaxwell: I see.
01:09 < jonasschnelli> I mentioned this in the bitcoin-dev mail, because users relay on it,... even if its fundamentally broken.
01:09 < sipa> rely
01:09 < jonasschnelli> rely. Thanks sipa. :)
01:09 < jonasschnelli> Also,... it looked like, that my feeler PR: https://github.com/bitcoin/bitcoin/pull/9238 did get some rejects.
01:11 < jonasschnelli> In a long shot, I could imagine, BFD (filter digest / filter commitments) for filtering from untrusted peers, and BIP39 for filtering from trusted peers (once BIP150 has ben established).
01:11 < jonasschnelli> Even if BIP39 is not the most efficient way.
01:11 < sipa> BIP39?
01:11 < sipa> are you sure?
01:11 < jonasschnelli> 37! argh
01:11 < jonasschnelli> Bloom Filter
01:13 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
01:13 < jonasschnelli> But I think there is no solution for a non-BIP37 0-conf "filtering" without running into these privacy issues related to bip37
01:13 < gmaxwell> jonasschnelli: for your wokrin in 9238 just transfer all transactions, any filtering scheme will trash privacy, and transfering transactions is an aggregate of 14 kilobit/s.
01:13 < gmaxwell> But displaying unconfirmed transactions in any non-validating wallet is just an invite to abuse.
01:14 < gmaxwell> Many lite wallets that do this today are utterly crippled by it, because they also spend unconfirmed coins, so a single troublemaker giving them some fake payments makes them unusable. (or at least they did a half year ago.)
01:15 < jonasschnelli> gmaxwell: Yes. Agree. But the user-experience without displaying incoming funds will probably be not acceptable "in the field".
01:15 < gmaxwell> please.
01:16 < jonasschnelli> I don't know. I also don't like the 0-conf displaying. While working on the Core wallets SPV mode, I just had the feeling that people will not use it because of the missing 0-conf display.
01:16 < gmaxwell> I think it's a bad idea to release features that would require an emergency software update to disable them as soon as one board person spends an hour making a few like hack that sends out garbage transactions and spins up a bunch of sybil nodes.
01:17 < jonasschnelli> 0-conf / spv should probably only be possible in conjunction with BIP150 and a trusted peer (at home or somewhere)
01:18 < gmaxwell> In any case, just send all the data. As mentioned it's 14kbit/sec.  The history is really the only annoying part about that.
01:19 < jonasschnelli> gmaxwell: do you mean send all the data if someone request a filtered mempool?
01:19 < jonasschnelli> or just for tv invs?
01:19 < jonasschnelli> *tx     
01:20 < gmaxwell> I mean don't do any tx filtering. 
01:21 < gmaxwell> Same as we do today. Please. implementing spv mode in core doesn't mean implementing all the flaws and vulnerabilities in other software slavishly. Thats pointless. If someone wants something that is going to blast out there addresses, validate nothing, etc.. they can already use bitcoinj based software.
01:21 < jonasschnelli> Heh. True.
01:22 < gmaxwell> :) at least the spv behavior in core can be private.
01:22 < jonasschnelli> I have implemented the BFD relevant hooks. IsBlockRelevantToWallet(pindex).
01:23 < jonasschnelli> gmaxwell: The only usability issues are: catch-up a couple of weeks (144*<day> MBs, take a while) and the missing 0-conf. Maybe this is acceptable to prevent privacy.
01:24 < gmaxwell> I think it's not bad, especially if we had better facilities for keeping it caught up in the background.
01:24 < jonasschnelli> Though, I haven't fully understood the semi.-trusted oracle idea for the BDF. I would expect to have the BDF in the coinbase...
01:26 < jonasschnelli> But somehow the BFD is required for older blocks as well
01:26 < gmaxwell> It's not really great to go from nothing to consensus rule if it can be avoided: No design survives first contact with users.  Better to prove out the idea and refine it before its required, which is possible here.
01:27 < jonasschnelli> From where would you get the BFD (maybe its not bloom filters in the end)? A new p2p command?
01:28 < gmaxwell> just another type of element that you can getdata, perhaps more than one.
01:29 < jonasschnelli> this would result in trusting the peer, right? The whole signing thing of BFDs would still be a thing? Or just compare BFDs from the data retrived from other peers?
01:30 < jonasschnelli> Probably easy to sybil you with fake data
01:30 < gmaxwell> I thought you were referring to the filter itselt and not the hash root... Unclear, multiple models are possible and _all_ are better than BIP37.
01:31 < jonasschnelli> Right, tx withhold is also possible with BIP37.
01:32 < gmaxwell> and asking multiple peers is very inefficient with BIP37.. needs n-times the bandwidth.
01:33 < jonasschnelli> good point.
01:36 -!- slsdhl [~srd@185.115.102.2] has joined #bitcoin-core-dev     
01:36 -!- slsdhl [~srd@185.115.102.2] has quit [Client Quit]     
01:37 < btcdrak> Requesting review for release blog post https://github.com/bitcoin-core/bitcoincore.org/pull/305
01:40 < gmaxwell> jonasschnelli: but pulling data from peers is just one option, you could-- for example-- go get a hash root (root of a tree of digest hashes) from a website and pop that into a configuration.
01:41 < gmaxwell> (and then use that for filtering the past-- then the future, past that root, you just fetch whole blocks)
01:49 -!- jeremias [~jeremias@kangasbros.fi] has quit [Ping timeout: 250 seconds]     
01:50 -!- jeremias [~jeremias@kangasbros.fi] has joined #bitcoin-core-dev     
01:52 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Remote host closed the connection]     
01:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:01 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:12 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Remote host closed the connection]     
02:13 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:19 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Remote host closed the connection]     
02:19 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev     
02:23 < BlueMatt> cfields: ohhh, static CNodeState::cs....missed the static part
02:24 < BlueMatt> cfields: ok, I'll make it static in the pr and add a TODO: do something smarter
02:24 < BlueMatt> cfields: oh, wait, no, really dont want to do that
02:25 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #bitcoin-core-dev     
02:26 < BlueMatt> cfields: that would mean that #9375 + multithreaded processmessages wouldnt accomplish anything :/
02:26 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
02:28 < sipa> BlueMatt: but the same is true for the current code, no?
02:28 < sipa> which uses cs_main
02:31 < BlueMatt> sipa: no, I dont believe so, #9375 + #9419 + a fix for https://github.com/bitcoin/bitcoin/pull/9375#discussion_r94180477 (which just means making fWantsCmpctWitness atomic) + multithreaded ProcessMessages will work
02:31 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
02:31 < gribble> https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub
02:33 < sipa> BlueMatt: ah, i see
02:33 < sipa> right
02:33 < BlueMatt> it may be the case that we dont need State() at all for that, though
02:35 < BlueMatt> yea, no, so to make it all work we need to have a State()->fWantsCmpctWitness and pfrom->GetSendVersion() call without cs_main
02:40 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:51 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/77eaadb6c9619370b09513fecba13cfe656d63d6
02:51 < bitcoin-git> bitcoin/0.13 77eaadb Wladimir J. van der Laan: doc: Clean out release notes on 0.13.x branch...
02:52 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/03e1d6ce349cc83b92140fec7d0c5f88893c0a9c
02:52 < bitcoin-git> bitcoin/master 03e1d6c Wladimir J. van der Laan: doc: Add historical release notes for 0.13.2
02:54 < jonasschnelli> gmaxwell: thanks.
02:55 < jonasschnelli> gmaxwell: you mentioned here (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012637.html) a rough specs for a better filter structure then bloom
02:55 < jonasschnelli> Do you have any specification for that?
02:59 < BlueMatt> cfields: hmmm, regarding #9441, do we really want to run the entire ProcessMessages loop (calling SendMessages potentially umpteen times) just to process multiple messages from the same node?
02:59 < gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
02:59 < BlueMatt> (ie remove the loop inside ProcessMessages and move it to ThreadProcessMessages)
03:01 < timothy> buiding bitcoin-core 0.13.2 on archlinux...
03:03 < sipa> BlueMatt: i was wondering about that too
03:03 < sipa> BlueMatt: but there is hardly any (contentious) locking going on anymore in between
03:04 < BlueMatt> yea, but SendMessages.....
03:04 < sipa> Ah.     
03:04 < sipa> i hadn't considered that
03:04 < sipa> that defeats the purpose
03:05 < sipa> hmm, i was about to say that it negatively impacts batching of invs and addrs
03:05 < sipa> but since we have explicit random delays for those, i don't think that's really an issue anymore
03:05 < BlueMatt> yea, I dont think it breaks anything
03:05 < BlueMatt> just repeatedly calls SendMessages to do nothing
03:06 < sipa> oh, it won't break anything
03:06 < BlueMatt> I assume you didnt touch cs_vSend due to https://github.com/bitcoin/bitcoin/pull/9419/commits/c214d120a363a05ba9afdccff6b4bda6e29ae7c4, cfields?
03:10 < BlueMatt> cfields: other than that, I got through #9441 and it looks good to me
03:10 < gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
03:10  * BlueMatt will copy discussion into pr thread
03:10 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
03:10 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
03:10 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:17 < sipa> thanks
03:17  * sipa -> NYC
03:17 < BlueMatt> sipa: cool, see you tomorrow afternoon
03:17 < BlueMatt> anyone else at RWC? sipa, cfields and I likely will be
03:24 -!- bitcfan [4e15aa93@gateway/web/freenode/ip.78.21.170.147] has joined #bitcoin-core-dev     
03:25 -!- bitcfan [4e15aa93@gateway/web/freenode/ip.78.21.170.147] has quit [Client Quit]     
03:25 -!- Saucery [~Saucery@c110-20-8-231.rivrw8.nsw.optusnet.com.au] has quit []     
03:45 -!- tiago_ [5dc467a6@gateway/web/freenode/ip.93.196.103.166] has joined #bitcoin-core-dev     
03:51 < timothy> is MALLOC_ARENA_MAX=1 still "recommended" on linux?
04:01 < sipa> timothy: i expect that setting it so low may come with lower performancr
04:01 < sipa> but i don't think anyone ever benchmarked it
04:03 < sipa> it's certainly recommended if you are very tight on memory
04:03 < timothy> is -reindex-chainstate is faster than -reindex?
04:04 < timothy> without the second is :P
04:05 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 265 seconds]     
04:09 < sipa> yes     
04:09 < sipa> but it only works when your blocks and blocks/index are not corrupted
04:19 -!- Netsplit *.net <-> *.split quits: kadoban, jl2012, kinlo
04:19 -!- Netsplit over, joins: kinlo
04:19 -!- Netsplit over, joins: kadoban
04:20 -!- tiago_ [5dc467a6@gateway/web/freenode/ip.93.196.103.166] has quit [Quit: Page closed]     
04:20 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-wmrtocnolevvjlbw] has joined #bitcoin-core-dev     
04:32 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
04:36 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 264 seconds]     
04:36 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
05:21 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has quit [Quit: Leaving]     
05:25 -!- ryanofsky_ [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Remote host closed the connection]     
05:27 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
05:30 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer]     
05:30 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev     
05:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]     
05:33 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
05:46 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection]     
05:47 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
05:47 -!- Netsplit *.net <-> *.split quits: aj, jrayhawk, Aleph0, ybit
05:47 -!- Netsplit over, joins: aj
05:47 -!- Netsplit over, joins: Aleph0
05:47 -!- Netsplit over, joins: jrayhawk
05:47 -!- Netsplit over, joins: ybit
05:47 < jonasschnelli> bitcoin-qt tells me today when running with a fresh datadir: "Last received block was generated 7 year(s) and 52 week(s) ago."
05:47 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-vvasrnoejqsmtbeo] has quit [Ping timeout: 265 seconds]     
05:48 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Write error: Broken pipe]     
05:49 < wumpus> jonasschnelli: so it regards it as an edge case, 52 weeks but not a year yet. curious :)
05:50 < jonasschnelli> qint64 remainder = secs % YEAR_IN_SECONDS;
05:50 < jonasschnelli> Na. I don't fix that.
05:50 < wumpus> yeah it's silly but not a serious issue
05:51 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-caeftmjllkdipuja] has joined #bitcoin-core-dev     
05:55 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 258 seconds]     
05:56 -!- roasbeef [~root@104.131.26.124] has joined #bitcoin-core-dev     
05:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
05:58 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
05:58 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
06:07 < bitcoin-git> [bitcoin] laanwj opened pull request #9460: Fix a few typos in translated strings (master...2017_01_messages_update) https://github.com/bitcoin/bitcoin/pull/9460
06:13 -!- dermoth [~thomas@dsl-216-221-36-109.mtl.aei.ca] has joined #bitcoin-core-dev     
06:15 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
06:18 -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds]     
06:18 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds]     
06:41 < luke-jr> wumpus: btcdrak: bad signature on sendy release ann
06:42 < wumpus> luke-jr: are you checking the html or text attachment?
06:42 -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 245 seconds]     
06:43 < wumpus> in case of the html you should run gpg on the raw html file
06:43 < wumpus> (both attachments verify OK here)
06:44 < luke-jr> both
06:44 < luke-jr> how do you run GPG on the raw HTML file, seeing as the HTML is outside the signature? :/
06:44 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/03e1d6ce349c...e0dc3d70c6ec
06:44 < bitcoin-git> bitcoin/master a9d6151 Wladimir J. van der Laan: qt,wallet: Fix a few typos in messages...
06:44 < bitcoin-git> bitcoin/master d45b21e Wladimir J. van der Laan: qt: Fill in English numerusforms...
06:44 < bitcoin-git> bitcoin/master e0dc3d7 Wladimir J. van der Laan: Merge #9460: Fix a few typos in translated strings...
06:44 < btcdrak> luke-jr: matches for me
06:44 < bitcoin-git> [bitcoin] laanwj closed pull request #9460: Fix a few typos in translated strings (master...2017_01_messages_update) https://github.com/bitcoin/bitcoin/pull/9460
06:45 < wumpus> that mail has a text/plain as well as a text/html mime attachment - just save them to a file and run gpg on them?
06:46 < luke-jr> hmm, that works. I wonder what copy/paste is changing
06:46 < btcdrak> Thunderbird also automatically validated it for me.
06:47 < jonasschnelli> Same here
06:47 < luke-jr> my mail client normally auto-validates, but it didn't like the formatting or something
06:53 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9461: [Qt] Improve progress display during headers-sync and peer-finding (master...2017/01/qt_sync) https://github.com/bitcoin/bitcoin/pull/9461
07:14 -!- Cheeseo [~x@208.167.254.81] has joined #bitcoin-core-dev     
07:14 -!- Cheeseo [~x@208.167.254.81] has quit [Changing host]     
07:14 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
07:14 -!- Cheeseo [~x@unaffiliated/cheeseo] has left #bitcoin-core-dev []     
07:14 < jonasschnelli> luke-jr: I think squashing makes sense when one commit overwrites many lines from a former commit in the same PR.
07:14 < jonasschnelli> But Okay for #8877
07:14 < gribble> https://github.com/bitcoin/bitcoin/issues/8877 | Qt RPC console: history sensitive-data filter, and saving input line when browsing history by luke-jr · Pull Request #8877 · bitcoin/bitcoin · GitHub
07:15 < luke-jr> jonasschnelli: there are some cases where I think it may make sense, yes
07:15 -!- andytoshi [~apoelstra@wpsoftware.net] has left #bitcoin-core-dev []     
07:16 < jonasschnelli> But your right, squashing and loosing "logical history" is not ideal
07:17 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
07:20 < jonasschnelli> can anyone give https://github.com/bitcoin/bitcoin/pull/8877 a final review?
07:21 -!- chris2000 [~chris2000@p5DCB4F3D.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
07:34 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev     
07:37 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev     
07:40 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
07:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
07:45 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds]     
07:50 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev     
07:54 < cfields> BlueMatt: yes, cs_vSend wasn't touched because of your PR. I've just been operating under the assumption that the lock around SendMessages will be removed by one PR or another.
07:55 < btcdrak> jonasschnelli: done.
07:56 -!- jtimon [~quassel@197.red-88-0-200.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
07:57 < jonasschnelli> thanks btcdrak 
07:57 < jonasschnelli> now I own you a review. :)
07:57 < bitcoin-git> [bitcoin] jonasschnelli pushed 12 new commits to master: https://github.com/bitcoin/bitcoin/compare/e0dc3d70c6ec...6dc4c43d326e
07:57 < bitcoin-git> bitcoin/master fc95daa Jonas Schnelli: Qt/RPCConsole: Save current command entry when browsing history...
07:57 < bitcoin-git> bitcoin/master 9044908 Jonas Schnelli: Qt/RPCConsole: Don't store commands with potentially sensitive information in the history...
07:57 < bitcoin-git> bitcoin/master de8980d Luke Dashjr: Bugfix: Do not add sensitive information to history for real...
07:58 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #8877: Qt RPC console: history sensitive-data filter, and saving input line when browsing history (master...qt_console_history_filter) https://github.com/bitcoin/bitcoin/pull/8877
08:02 < jtimon> #9271 needs rebase but could still get some general feedback
08:02 < gribble> https://github.com/bitcoin/bitcoin/issues/9271 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
08:02 < instagibbs> can someone explain ProcessBlockAvailability? The comment for it is unclear: "/** Check whether the last unknown block a peer advertised is not yet known. */"
08:02 < instagibbs> check whether an unknown block is unknown... ok!
08:05 < jtimon> also, friendly reminder https://github.com/bitcoin/bitcoin/pull/8855 https://github.com/bitcoin/bitcoin/pull/9279 and https://github.com/bitcoin/bitcoin/pull/8498 still *don't* need rebase
08:07 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:07 < instagibbs> nevermind, think I got it
08:07 -!- xiangfu [~xiangfu@223.223.187.142] has quit [Ping timeout: 268 seconds]     
08:07 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 264 seconds]     
08:07 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds]     
08:08 -!- xiangfu [~xiangfu@223.223.187.142] has joined #bitcoin-core-dev     
08:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:13  * luke-jr rebases #9152 to add history filter before he forgets ☺
08:13 < gribble> https://github.com/bitcoin/bitcoin/issues/9152 | Wallet/RPC: sweepprivkeys method to scan UTXO set and send to local wallet by luke-jr · Pull Request #9152 · bitcoin/bitcoin · GitHub
08:19 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
08:25 < BlueMatt> cfields: hmmm...yes, re: moving the loop into net_processing I figured that was just due to not complicating that pr too much, thanks
08:26 < cfields> BlueMatt: np, thanks for review
08:26 < BlueMatt> cfields: as for not having a per-node loop....hum...can we re-add it in net.cpp with two lines so that its not a (proabbly barely noticeable) regression?
08:27 < BlueMatt> bool fMoreNodeWork = ... while (fMoreNodeWork) ProcessMessages
08:28 < cfields> BlueMatt: I'm not sure there's any actual change from the current behavior
08:28 < sdaftuar> instagibbs: ProcessBlockAvailability is for when you get block announcements via inv (before you have the header)
08:28 < BlueMatt> cfields: you mean like from current master or from current pr?
08:29 < BlueMatt> sdaftuar: we still have crap for that? can we just remove it and replace with "getheaders"
08:29 < cfields> BlueMatt: oh.. it doesn't swallow all messages at once for fairness. I'm pretty sure emptying the node's full queue before moving on would be a DDoS vector
08:29 < cfields> BlueMatt: from master
08:29 < sdaftuar> BlueMatt: i think we could!
08:29 < cfields> BlueMatt: see the comment here: https://github.com/bitcoin/bitcoin/pull/9441/commits/99599884147ea4db3f960b0e706b039ba1553c80#r94270593
08:32 < BlueMatt> cfields: I believe the improvements against master come largely from removing lock contention between the message processing loop and the read-from-wire loop?
08:32 < BlueMatt> or do I have that backwards?
08:33 < BlueMatt> cfields: re: swallowing from one node...that isnt how I read the old code?
08:34 < BlueMatt> I mean certainly if we got a packet which only had one message we'd not process more than one message at a time, but if the loop is slow to go around (it appears to be sometimes due to various messages being slow) then we might have multiple to process per-peer
08:34 < cfields> BlueMatt: sorry, by no change in current behavior, i meant the swallowing-one-message part. Obviously fixing the lock contention is a behavioural change :)
08:34 < BlueMatt> and in that case I think we'd prefer to only call SendMessages less often (though, to be fair, doing them back-to-back is less likely to be slow than otherwise)
08:35 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev     
08:35 < cfields> BlueMatt: take a look at the current code. I really don't think the new behavior is different, other than the case of corrupted messages
08:35 < BlueMatt> cfields: to answer in a different way: why do we need to change from the current behavior
08:35 < BlueMatt> cfields: whats the break you're referring to in that comment?
08:35 < BlueMatt> (line numbers are confusing here)
08:35 < BlueMatt> the !message.complete() one?
08:36 < cfields> and yes, sendmessages needs to be broken up and fixed in lots of different ways, but imo not here
08:36 < cfields> sec     
08:36 < BlueMatt> definitely agreed, not here
08:36 < cfields> BlueMatt: whoops, that should be 2538
08:36 < BlueMatt> just trying to figure out if re-adding a while somewhere in that pr is better or worse, since this is all we can hope for in 0.14 :)
08:36 < BlueMatt> ohhhhhh, I hadnt seen /that/ break
08:37 < cfields> yes. So the loop only continues in 2 cases, iirc.
08:37 < cfields> bad hash, or uhmm.. bad start chars maybe?
08:37 < BlueMatt> wait, so on current master we will continue the loop if the message is somehow corrupted, but otherwise wont? wtf.....
08:37 < BlueMatt> oh, no, just bad hash
08:38 < BlueMatt> yea, this makes no sense
08:38 < cfields> BlueMatt: indeed, those are the cases that the node should be punished for, but instead they get a free pass.
08:38 < cfields> go figure.
08:38 -!- xiangfu [~xiangfu@223.223.187.142] has quit [Ping timeout: 246 seconds]     
08:39 < BlueMatt> well, i guess if your checksum is bad its not like we did any work for you anyway...
08:39 < cfields> sure, but that should at least toss you to the back of the line
08:39 -!- xiangfu [~xiangfu@223.223.187.142] has joined #bitcoin-core-dev     
08:40 < cfields> BlueMatt: so you agree now that the loop behavior isn't changed here significantly? (or, at least, only for the better?)
08:41 < BlueMatt> yes, agreed
08:41 < cfields> ok     
08:41 < BlueMatt> I suppose I wouldnt want to go audit for whether it was a dos vuln to change it in this pr
08:41 < BlueMatt> so, good :)
08:42 < cfields> heh     
08:42 < cfields> BlueMatt: as a follow-up for 0.14, if you're concerned about it, we could add a quick hack to quickly exit SendMessages if it hasn't been at least x msec since the last call
08:42 < cfields> but i don't think there's any real need, since this has been the behavior all along
08:44 < BlueMatt> yea, I'm less concerned about that...still hoping for parallel processmessages but....that seems stretchy now :/
08:44 < cfields> :(     
08:45 < BlueMatt> depends on how many reviewers pop their heads up this week, I suppose
08:46 < cfields> BlueMatt: other than the current PRs, how much remains there? I think that 9441 should cut down on the scary races a good bit?
08:46 < BlueMatt> yea, I think after current PRs its just one or five std::atomics in CNode and then the one commit which fuckes around with the ProcessMessages loop
08:47 < BlueMatt> which would need rebased on your stuff, but probably wouldnt be too hard
08:47 < cfields> these are atomics that fix more than just CNodeStats which has always been racy anyway?
08:48 < BlueMatt> I havent looked as of the latest stuff so you'd know better than I
08:48 < BlueMatt> I mean we should probably atomic-ify CNodeStats...
08:48 < BlueMatt> easy enough
08:48 < cfields> I'll check out your branch again
08:48 < BlueMatt> cool
08:49 < BlueMatt> I'll probably not get much done until thurs....early flight tomorrow so will likely be super tired during the day at rwc
08:49 < cfields> yea, I was thinking about that yesterday. I think it may make sense to just actually keep the stats in CNodeStats with one lock. See nRecvBytes as an example
08:49 < cfields> then when we need the stats, just do a quick lock and copy out
08:49 < BlueMatt> iirc that like automagically ended up with lock inversions
08:50 < BlueMatt> i think i looked into that, but dont remember now
08:50 < BlueMatt> seems weird that it would, but....something something...
08:50 < cfields> hmm, not sure how. I'll look again
08:50 < cfields> BlueMatt: btw, you're good with the boost changes that 9441 include?
08:51 < BlueMatt> which boost changes? you mean #9289?
08:51 < cfields> if so, mind re-acking #9289 ?
08:51 < gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
08:51 < gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
08:51 < cfields> yes     
08:53 < BlueMatt> aww fuck, got rebased, yea, I'm pretty sure nothing changed that I didnt think was reasonable or good...I'll try to take another look tomorrow, but I'm pretty sure that ack is still valid
08:53 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9462: [qt] Do not translate tilde character (master...Mf1701-qtTransTilde) https://github.com/bitcoin/bitcoin/pull/9462
08:54 < cfields> BlueMatt: np, thanks
08:56 < cfields> BlueMatt: if i could fixup the racy stuff that would affect parallel processing, want me to PR? Or does that just complicate the current PR maze?
08:57 < BlueMatt> cfields: up to you...I had assumed you were waiting on the current prs to clean up a bit, but if you can do it without stepping on your own toes feel free
08:58 < cfields> ok. I'll at least try to get something ready on top of the queued-up changes. If it happens to not depend on them, I'll go ahead and submit it.
08:58 < BlueMatt> sounds good, thanks
08:59 < BlueMatt> I'll look into the same tomorrow on the flight if I'm not asleep the whole time
08:59 < cfields> heh, ok
09:00 < BlueMatt> ehh, by "the same" I meant redoing the parallel-processmessages pr
09:00 < BlueMatt> that was super unclear....
09:08 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:08 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
09:08 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has joined #bitcoin-core-dev     
09:08 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-core-dev     
09:09 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has quit [Client Quit]     
09:17 -!- lejitz1 [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving.]     
09:17 -!- lejitz [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev     
09:27 -!- xiangfu [~xiangfu@223.223.187.142] has quit [Ping timeout: 264 seconds]     
09:30 < instagibbs> is there a plan for multiwallet for 0.14, or is it too late
09:31 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds]     
09:35 < gmaxwell> we're not at the feature freeze yet, and it seems done +/- things that need to be fixed due to review.
09:35 < gmaxwell> Several people have said they would review it.
09:35 < gmaxwell> It would be really great it multiwallet and the utxo scriptpubkey index could make it in.
09:39 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev     
09:40 -!- lejitz [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 256 seconds]     
09:42 < instagibbs> #8694 needs rebase though
09:42 < gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
09:42 -!- xiangfu [~xiangfu@223.223.187.142] has joined #bitcoin-core-dev     
09:44 < luke-jr> instagibbs: #8776 goes first
09:44 < gribble> https://github.com/bitcoin/bitcoin/issues/8776 | Wallet refactoring leading up to multiwallet by luke-jr · Pull Request #8776 · bitcoin/bitcoin · GitHub
09:44 < instagibbs> ok, ill review
09:45 < luke-jr> actually #8776 looks ready to merge. 3 reviews already
09:45 < gribble> https://github.com/bitcoin/bitcoin/issues/8776 | Wallet refactoring leading up to multiwallet by luke-jr · Pull Request #8776 · bitcoin/bitcoin · GitHub
09:45 < luke-jr> yes we know gribble --.
09:46 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
09:49 < BlueMatt> luke-jr: good time to go rebase 8694 then :p
09:49 < luke-jr> sure
09:51 < luke-jr> oh, need #8775 still as well
09:51 < gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
09:52 < luke-jr> instagibbs: ^ could use review
10:03 < luke-jr> (once those two get in, looks reasonable to split up 8694 further into base/Qt/RPC PRs)
10:17 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
10:17 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
10:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
10:20 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 248 seconds]     
10:36 -!- dermoth [~thomas@dsl-216-221-36-109.mtl.aei.ca] has quit [Ping timeout: 256 seconds]     
10:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
10:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
10:50 -!- lainknight [~lainknigh@rrcs-96-10-59-58.se.biz.rr.com] has joined #bitcoin-core-dev     
10:55 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
11:05 -!- lejitz [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev     
11:09 -!- jtimon [~quassel@197.red-88-0-200.dynamicip.rima-tde.net] has quit [Ping timeout: 272 seconds]     
11:11 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
11:12 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
11:14 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer]     
11:31 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]     
11:35 -!- Netsplit *.net <-> *.split quits: Ylbam, nOgAnOo, _mn3monic, Taek, murr4y, kinlo, PaulCape_, Victorsueca, kadoban, jl2012,  (+2 more, use /NETSPLIT to show all of them)
11:35 -!- Netsplit over, joins: _mn3monic
11:35 -!- luke-jr [~luke-jr@2001:470:5:265:a45d:823b:2d27:961c] has joined #bitcoin-core-dev     
11:36 -!- luke-jr [~luke-jr@2001:470:5:265:a45d:823b:2d27:961c] has quit [Changing host]     
11:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
11:36 -!- Netsplit over, joins: murr4y
11:36 -!- Netsplit over, joins: Taek
11:36 -!- Netsplit over, joins: kadoban
11:37 -!- Netsplit over, joins: Victorsueca
11:37 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b89a:ee52:e255:ec7f] has joined #bitcoin-core-dev     
11:38 -!- profall [sid29922@gateway/web/irccloud.com/x-aazybhnwserjujnb] has quit [Ping timeout: 245 seconds]     
11:39 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-gdanbzyzmhdawgjl] has joined #bitcoin-core-dev     
11:40 -!- limpkin [sid20909@gateway/web/irccloud.com/x-iljunpguwpwmshbs] has joined #bitcoin-core-dev     
11:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vxcualxrjcjomysv] has joined #bitcoin-core-dev     
11:46 -!- profall [sid29922@gateway/web/irccloud.com/x-pnjfczzubyeplfgq] has joined #bitcoin-core-dev     
11:48 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-pohyphteesrtsgfy] has joined #bitcoin-core-dev     
11:49 -!- lejitz_ [uid205154@gateway/web/irccloud.com/x-xnpldnvwaaimiqdn] has joined #bitcoin-core-dev     
12:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]     
12:09 < sdaftuar> BlueMatt: if I understand 9375 correctly, I think that when there is a fork, and some nodes have tip A and others tip B, #9375 would cause all nodes to end up downloading both A and B.
12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
12:10 < sdaftuar> i guess that could result in a testnet DoS vector?
12:10 < sdaftuar> maybe that's the least of our testnet problems though
12:11 -!- lejitz1 [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev     
12:12 -!- lejitz [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: ZNC 1.6.4 - http://znc.in]     
12:12 -!- lejitz_ is now known as lejitz     
12:12 -!- wvr [~wvr@215.red-83-59-62.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
12:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:17 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
12:19 -!- lainknight [~lainknigh@rrcs-96-10-59-58.se.biz.rr.com] has quit [Read error: Connection reset by peer]     
12:20 -!- lejitz1 [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving.]     
12:40 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit []     
12:41 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
12:43 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
12:43 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [Client Quit]     
12:53 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has joined #bitcoin-core-dev     
12:53 -!- dermoth [~thomas@66.36.158.182] has joined #bitcoin-core-dev     
12:58 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
13:01 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
13:01 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
13:05 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
13:05 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:08 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
13:52 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/6dc4c43d326e...ce5c1f4acae4
13:52 < bitcoin-git> bitcoin/master 680b0c0 Suhas Daftuar: Release cs_main before calling ProcessNewBlock (cmpctblock handling)
13:52 < bitcoin-git> bitcoin/master bd02bdd Suhas Daftuar: Release cs_main before processing cmpctblock as header
13:52 < bitcoin-git> bitcoin/master ce5c1f4 Pieter Wuille: Merge #9252: Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling)...
13:52 < bitcoin-git> [bitcoin] sipa closed pull request #9252: Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) (master...cb-lock) https://github.com/bitcoin/bitcoin/pull/9252
14:11 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ce5c1f4acae4...2a524b8e8fe6
14:11 < bitcoin-git> bitcoin/master fb0c934 Luke Dashjr: Wallet: Let the interval-flushing thread figure out the filename
14:11 < bitcoin-git> bitcoin/master 5394b39 Luke Dashjr: Wallet: Split main logic from InitLoadWallet into CreateWalletFromFile
14:11 < bitcoin-git> bitcoin/master 2a524b8 Pieter Wuille: Merge #8776: Wallet refactoring leading up to multiwallet...
14:15 < gmaxwell> \O/     
14:16 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
14:18 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
14:19 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
14:21 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
14:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
14:31 < Chris_Stewart_5> Can we have OP_1NEGATE used as a push op code for witness program versioning?
14:32 < sipa> no, only OP_0, and OP_1..OP_16
14:34 < Chris_Stewart_5> Interesting, thanks sipa 
14:35 < Chris_Stewart_5> Actually, is there any reason for this?
14:35 < sipa> not really
14:35 < sipa> it was considered sufficient :)
14:38 < luke-jr> by some* maybe; IMO it was overlooked.
14:40 < Chris_Stewart_5> Defintely a protocol 'quirk' since the BIP does say '1 byte push opcodes' 
14:40 < luke-jr> not worth the effort to fix at this point though
14:41 < sipa> fix the bip :)
14:41 < sipa> (to match the code)
14:41 < Chris_Stewart_5> but it is so much easier to criticize! :P. I'll submit a pull req later.. 
14:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
14:45 < sipa> thanks!
15:12 < sipa> Chris_Stewart_5: the BIP clearly says "for 0 to 16", no?
15:12 < sipa> (i missed that when suggesting you send a PR, sorry)
15:12 < Chris_Stewart_5> sipa: What is '0 to 16'? Bytes? Technically OP_1 is 0x51 
15:13 < Chris_Stewart_5> I don't like the wording in that regard either. 
15:13 < sipa> the value being pushed
15:13 < Chris_Stewart_5> Why not explicitly state what ops they are?
15:13 < sipa> sure
15:13 < sipa> i trying to find the misunderstanding
15:13 < Chris_Stewart_5> instead having to do the conversion in your head?
15:13 < sipa> if it isn't clear, reformulating helps
15:14 < Chris_Stewart_5> I don't think I have a misunderstanding per se, but I think can be clearer. Instead of having to infer the op codes from the text I think they should just be explicitly stated
15:14 < Chris_Stewart_5> Plus it falls more inline with the actual implementation IMO
15:14 < sipa> fair enough
15:17 < fanquake> sipa You shouldn't see significant speedup with #8610 if you have a large -dbcache set (like 2048), should you?
15:17 < gribble> https://github.com/bitcoin/bitcoin/issues/8610 | Share unused mempool memory with coincache by sipa · Pull Request #8610 · bitcoin/bitcoin · GitHub
15:17 < sipa> fanquake: depends how large, but the effect should certainly be less dramativ
15:17 < sipa> *dramatic
15:19 < fanquake> Ok. Just ran through with -dbcache=2048 on master and that PR. Both basically the same (~800s) to reindex to 280k blocks.
15:19 < fanquake> I think I'll run through again without uping the dbcache at all. That seemed to show the most significant speedup.
15:20 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 252 seconds]     
15:21 < sipa> if you set dbcache to 10 i'm sure the difference will be spectacular :D
15:22 < luke-jr> Chris_Stewart_5: adding "valid" seems to make it less clear IMO
15:23 < Chris_Stewart_5> luke-jr: How so? A invalid 1 byte op code is OP_1NEGATE
15:23 < sipa> how about "a select subset of 1-byte push opcodes" ?
15:23 < Chris_Stewart_5> before it was a blanket statement, a 'one byte push op code' or something like that
15:23 < fanquake> heh yes I'm sure it would. When I first tested with 300mb dbcache there was something like a 30% speedup.
15:23 < sipa> oh, and OP_0 is not a 1-byte push
15:24 < Chris_Stewart_5> oo interesting
15:24 < Chris_Stewart_5> good point :/ 
15:24 < sipa> fanquake: if you feel like benchmarking, i have a few more utxo cache changes to test coming up :)
15:26 < fanquake> sipa sure
15:26 < Chris_Stewart_5> sipa: Then maybe just a 'select set of op codes' and then enumerate them like I have?
15:27 < sipa> Chris_Stewart_5: sgtm
15:28 < luke-jr> Chris_Stewart_5: OP_1NEGATE is valid though
15:28 < luke-jr> it's just not matched for witness purposes
15:29 < Chris_Stewart_5> (*this)[0] < OP_1 does it fail this predicate? 
15:31 < Chris_Stewart_5> luke-jr: Here: https://github.com/bitcoin/bitcoin/blob/14d01309bed59afb08651f2b701ff90371b15b20/src/script/script.cpp#L228
15:32 < sipa> Chris_Stewart_5: depends what *this is...
15:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
15:34 < BlueMatt> sdaftuar: yes, your comment about only calling NewPoWValidBlock on things that are better than our current tip is a good one
15:34 < BlueMatt> sdaftuar: and build on our tip
15:36 < BlueMatt> sdaftuar: re: https://github.com/bitcoin/bitcoin/pull/9375#discussion_r94483881 I think I'm missing your point here? did you mean to comment a bit further down where the check is to set bool send?
15:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:43 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
15:46 -!- kinlo [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev     
16:31 -!- Giszmo1 [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #bitcoin-core-dev     
16:32 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Read error: Connection reset by peer]     
16:34 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #bitcoin-core-dev     
16:34 -!- Giszmo1 [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Read error: Connection reset by peer]     
16:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]     
16:54 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
16:56 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
17:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vxcualxrjcjomysv] has quit [Quit: Connection closed for inactivity]     
17:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]     
17:59 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
18:23 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.]     
18:52 < morcos> BlueMatt: The remaining sdaftuar comment is in regards to the fact that you could announce two compact blocks via NewPoWValidBlock in quick succession even after the change to only announce potential new tips
18:55 < morcos> If those are tied at the same height, then one of them will not have ever become our tip and sp wpm
18:56 < morcos> oops..  and so won't be BLOCK_VALID_SCRIPTS or in our best chain and we'll stall any node asking for it
19:00 < morcos> but yes the change to BLOCK_VALID_TRANSACTIONS is in the later line where we set "send".  and the recently added code in getdata to fix my bug from 9447 can go away.
19:03 < gmaxwell> I've kinda wonered if we shouldn't just remember the NewPoWblock announcements that we've done e.g. {peer, hash} in a limitedmap, and then if we get in a request that is in that map, just blindly reply with the data on disk.
19:03 < gmaxwell> Similar to how the relay pool works.
19:05 < gmaxwell> (in that the relay pool means we'll give you a transaction we offered to you, even if we've since discarded it)
19:07 < morcos> gmaxwell: that's what i was thinking at first too, but i think sdaftuar's solution might just be more elegant
19:09 < morcos> as long as you lock cs_main if the requested hash doesn't match the cached block, that'll mean any announced block will be written to disk, and be available to be read..
19:10 < morcos> since these will be rare, i don' tthink there is a performance issue with reading them back from disk, the only existing problem is we weren't serving them b/c we weren't seeing them as BLOCK_VALID_SCRIPTS b/c they'd never been connected
19:10 < morcos> oh shoot... i keep forgetting... you can't serve them in that case
19:10 -!- MarcoFalke [~marco@5.199.182.203] has quit [Quit: MarcoFalke]     
19:10 < morcos> well if we're going to be pedantic about following the protocol we've got a problem
19:11 < morcos> b/c we're announcing blocks before we even now if we're going to test them for validity, so what do we do if we never test them
19:11 < morcos> also perhaps we never though through the case of what to do if we announce a block that turns out to be invalid... surely stalling the requester isn't the right course of action
19:17 < gmaxwell> (actually the deseralizzation is pretty slow, as an aside)
19:18 < gmaxwell> your concern is because we didn't really properly consider relaying unvalidated blocks, but we just glommed it on because it would have unfortunate to specify BIP152 another way.
19:18 < morcos> i hope thats a statement and not a question
19:18 < gmaxwell> We should specify a network message that says "I think block XYZ is invalid, if I told you about it before, forget about it, I'm not going to respond to requests about it."
19:19 < gmaxwell> statement.
19:19 < gmaxwell> A negative-inv if you will.
19:19 < morcos> yeah..   but we need to do something for now..  
19:20 < gmaxwell> though perhaps like the relay pool we ought to be willing to serve up data for any block we've pre-relayed, even if we never verified it and don't intend to. 
19:20 < gmaxwell> which we could do with a relay pool like strategy. even avoid putting them on disk... (who cares about a few megabytes of blocks in ram?) 
19:21 < morcos> yes but avoiding disk is an unnecessary optimization... we're talking about a rare race condition here (and we've already writtent them to disk before we've even decided whether to validate or not)
19:23 < gmaxwell> okay, from your comments above I was thinking there was some path where we didn't save to disk.
19:24 < gmaxwell> We don't generally want to allow arbritary peers to fetch blocks on disk that aren't in our best chain. (leads to fingerprinting attacks). Which was why I made the peer,hash suggestion above.
19:26 < morcos> gmaxwell: we already have other various protections that aren't always that it's in our best chain, in this case, we require non-best-chain blocks to be less than 30 days old
19:26 < morcos> but we also require BLOCK_VALID_SCRIPTS, if we just loosen that we're ok  (for the case of untested blocks)
19:27 < morcos> i still think we potentially have a problem about what to do with blocks that turn out to be invalid
19:27 < morcos> back in a bit
19:36 < gmaxwell> I think for now we should serve them if we've advertised them... but should make a protocol extension so we can refuse to. 
19:37 < gmaxwell> (we do ourselves no favors to help the network converge on things we think are invalid)
19:43 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has joined #bitcoin-core-dev     
19:53 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
19:58 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.5]     
19:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
20:05 -!- chris200_ [~chris2000@p5DCB4BBA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
20:08 -!- chris2000 [~chris2000@p5DCB4F3D.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]     
20:21 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 264 seconds]     
20:24 -!- Alina-malina [~Alina-mal@37.157.216.138] has joined #bitcoin-core-dev     
21:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.5]     
21:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:36 -!- grbs [~grubles@unaffiliated/grubles] has quit [Ping timeout: 250 seconds]     
21:49 -!- grbs [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev     
22:01 -!- grbs [~grubles@unaffiliated/grubles] has quit [Ping timeout: 248 seconds]     
22:14 -!- grbs [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev     
22:25 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has quit [Ping timeout: 245 seconds]     
22:33 < gmaxwell> why do we know have a birthday/rescan height for importaddress? 
22:33 < gmaxwell> I had thought this was going to get fixed with a range setting for the rescan rpc, but I see we closed that with 'you should import with birthdays' but there is no way to do that for a watching address import.
22:36 < gmaxwell> oh I see importmulti has a timestamp. cool.
22:38 < gmaxwell> midnightmagic: wrt the question someone was asking in #bitcoin about how do you handle an import backlog for a node that was offline: You use importmulti with the approrpiate birthdates, and it will handle any required rescan.
22:39 -!- grbs [~grubles@unaffiliated/grubles] has quit [Ping timeout: 258 seconds]     
22:39 < gmaxwell> perhaps the importaddress RPC help text should recommend you use importmulti instead.
22:52 -!- grbs [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev     
23:00 -!- dermoth [~thomas@66.36.158.182] has quit [Read error: Connection reset by peer]     
23:00 -!- dermoth [~thomas@dsl-66-36-158-182.mtl.aei.ca] has joined #bitcoin-core-dev     
23:21 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a524b8e8fe6...649cf5fe894b
23:21 < bitcoin-git> bitcoin/master fab6c5f MarcoFalke: [qt] Do not translate `~`
23:21 < bitcoin-git> bitcoin/master 649cf5f Wladimir J. van der Laan: Merge #9462: [qt] Do not translate tilde character...
23:21 < bitcoin-git> [bitcoin] laanwj closed pull request #9462: [qt] Do not translate tilde character (master...Mf1701-qtTransTilde) https://github.com/bitcoin/bitcoin/pull/9462
23:48 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]