--- Day changed Thu Jun 29 2017
00:00 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
00:00 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
00:04 -!- j_ybt [~j_ybt@192.161.48.22] has quit [Ping timeout: 260 seconds]     
00:09 -!- j_ybt [~j_ybt@192.161.48.22] has joined #bitcoin-core-dev     
00:19 -!- harrymm1 [~wayne@223.206.167.217] has joined #bitcoin-core-dev     
00:19 -!- j_ybt [~j_ybt@192.161.48.22] has quit [Ping timeout: 260 seconds]     
00:21 -!- harrymm [~wayne@60-249-19-76.HINET-IP.hinet.net] has quit [Ping timeout: 268 seconds]     
00:24 -!- arowser [~quassel@45.32.248.113] has joined #bitcoin-core-dev     
00:24 -!- harrymm1 [~wayne@223.206.167.217] has quit [Ping timeout: 276 seconds]     
00:39 -!- harrymm [~wayne@211-22-154-35.HINET-IP.hinet.net] has joined #bitcoin-core-dev     
00:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ubltmaldgimjxmco] has joined #bitcoin-core-dev     
00:43 -!- baldur [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has quit [Ping timeout: 258 seconds]     
01:02 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
01:04 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
01:14 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:18 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
01:30 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev     
01:42 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
01:53 -!- sjums [~nick@2001:41d0:1:b51c::1] has quit [Quit: Connection reset by beer]     
01:56 -!- sjums [~nick@2001:41d0:1:b51c::1] has joined #bitcoin-core-dev     
01:57 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
01:59 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
02:05 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/90a002ea647d...080ec5209172
02:05 < bitcoin-git> bitcoin/master 3c85332 Wladimir J. van der Laan: contrib: Update laanwj key...
02:05 < bitcoin-git> bitcoin/master 080ec52 MarcoFalke: Merge #10688: contrib: Update laanwj key...
02:06 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10688: contrib: Update laanwj key (master...2017_06_laanwj_key) https://github.com/bitcoin/bitcoin/pull/10688
02:13 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
02:50 -!- baldur [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
02:56 < wumpus> cfields: btw any idea what to do here? https://github.com/bitcoin/bitcoin/issues/10670   arguably the openbsd case is worst-case, they use an ancient GNU binutils
02:57 < wumpus> would be possible to detect this in configure, I guess, and then not disable the sse-reliant stuff
02:57 < wumpus> s/disable/enable
03:10 -!- bincap [~vd@85-222-72-154.dynamic.chello.pl] has joined #bitcoin-core-dev     
03:10 -!- bincap [~vd@85-222-72-154.dynamic.chello.pl] has quit [Client Quit]     
03:25 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
03:26 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
03:26 -!- LeMiner2 is now known as LeMiner     
03:36 -!- Guest20283 is now known as haakonn     
03:36 -!- haakonn [~haakonn@146.185.155.218] has quit [Changing host]     
03:36 -!- haakonn [~haakonn@pdpc/supporter/active/haakonn] has joined #bitcoin-core-dev     
04:09 < bitcoin-git> [bitcoin] practicalswift opened pull request #10701: Remove the virtual specifier for functions with the override specifier (master...virtual-override) https://github.com/bitcoin/bitcoin/pull/10701
04:22 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
04:35 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 260 seconds]     
04:35 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
04:38 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:44 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:44 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
04:45 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 260 seconds]     
04:46 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
04:54 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
04:59 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 276 seconds]     
05:00 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
05:05 -!- unholymachine [~quassel@2601:8c:c003:9f16:80ad:9d66:dec5:c8be] has joined #bitcoin-core-dev     
05:09 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 255 seconds]     
05:09 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
05:26 < bitcoin-git> [bitcoin] MeshCollider opened pull request #10702: [Trivial] Improve end-of-namespace comment consistency (master...improve-end-of-namespace-comment-consistence) https://github.com/bitcoin/bitcoin/pull/10702
05:28 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
05:29 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
05:33 < wumpus> what is people's obsession with en-of-namespace comments
05:33 < wumpus> we've just merged one three days ago (#9544), and now we need another PR?
05:33 < gribble> https://github.com/bitcoin/bitcoin/issues/9544 | [trivial] Add end of namespace comments. Improve consistency. by practicalswift · Pull Request #9544 · bitcoin/bitcoin · GitHub
05:55 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
06:04 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/080ec5209172...4c72cc33ebcc
06:04 < bitcoin-git> bitcoin/master fd9599b practicalswift: [qt] Avoid potential null pointer dereference in TransactionView::exportClicked()
06:04 < bitcoin-git> bitcoin/master 4c72cc3 Wladimir J. van der Laan: Merge #10673: [qt] Avoid potential null pointer dereference in TransactionView::exportClicked()...
06:04 < bitcoin-git> [bitcoin] laanwj closed pull request #10673: [qt] Avoid potential null pointer dereference in TransactionView::exportClicked() (master...null-pointer-dereference) https://github.com/bitcoin/bitcoin/pull/10673
06:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:36 < bitcoin-git> [bitcoin] jnewbery opened pull request #10703: [tests] Allow tests to pass when stderr is non-empty (master...test_stderr) https://github.com/bitcoin/bitcoin/pull/10703
06:57 < bitcoin-git> [bitcoin] jnewbery opened pull request #10704: [tests] nits in dbcrash.py (master...dbcrashtestnits) https://github.com/bitcoin/bitcoin/pull/10704
07:11 -!- nemgun [~nemgun@105.101.186.166] has joined #bitcoin-core-dev     
07:16 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
07:23 -!- Guest8908 [~triplesla@173-165-23-217-Illinois.hfc.comcastbusiness.net] has quit [Remote host closed the connection]     
07:24 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds]     
07:24 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds]     
07:25 -!- tripleslash [~triplesla@173-165-23-217-Illinois.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
07:25 -!- tripleslash is now known as Guest86952     
07:28 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
07:29 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
07:30 -!- mol [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev     
07:36 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
07:37 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
07:40 -!- mol- [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev     
07:43 -!- mol [~IRCIdent@unaffiliated/molly] has quit [Ping timeout: 276 seconds]     
07:43 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 240 seconds]     
07:43 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
07:58 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 255 seconds]     
07:59 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:03 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
08:11 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
08:14 -!- mol- [~IRCIdent@unaffiliated/molly] has quit [Ping timeout: 258 seconds]     
08:15 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
08:18 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Ping timeout: 240 seconds]     
08:18 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 276 seconds]     
08:20 < jonasschnelli> Should we crate a "trivial" label?
08:20 -!- molz [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev     
08:20 < jonasschnelli> or something that point concludes "typo only fixes / comments / etc."?
08:25 < wumpus> we had a trivial label in the past, I removed that at some point because it didn't add anything that 'docs/output' or 'refactoring' doesn't do
08:25 < wumpus> it made people have the idea that labeling something 'trivial' would make it accepted sooner, prompting the creating of tons of trivial changes
08:26 < wumpus> in any case, better to label specifically. 'trivial' doesn't really tell anything about the change
08:27 < wumpus> e.g. a comment change would be a documentation change
08:31 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
08:32 -!- eenoch_ [~eenoch@unaffiliated/eenoch] has quit [Ping timeout: 246 seconds]     
08:33 -!- eenoch [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev     
08:37 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Remote host closed the connection]     
08:37 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
08:39 < wumpus> dbcrash.py travis troubles https://github.com/bitcoin/bitcoin/pull/10704#issuecomment-312005841
08:40 < bitcoin-git> [bitcoin] MarcoFalke pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/4c72cc33ebcc...65cc7aacfbfc
08:41 < bitcoin-git> bitcoin/master 37065d2 John Newbery: [tests] remove unused imports from utils.py
08:41 < bitcoin-git> bitcoin/master f1fe536 John Newbery: [tests] fix flake8 warnings in test_framework.py and util.py
08:41 < bitcoin-git> bitcoin/master cad967a John Newbery: [tests] Move stop_node and start_node methods to BitcoinTestFramework...
08:41 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10556: Move stop/start functions from utils.py into BitcoinTestFramework (master...testframeworkstopstart) https://github.com/bitcoin/bitcoin/pull/10556
08:44 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:49 < jonasschnelli> wumpus: I see, good point about the "trivial" label.
08:59 < sdaftuar> wumpus: thanks for the heads up, i'll investigate the dbcrash issue
09:00 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
09:00 < wumpus> sdaftuar: they look like different problems; 248398016 seems a race issue (sending command to terminated process), 248398018 is a timeout while running `generate`. It's a tad strange that both problems happen to be in dbcrash.
09:00 < sdaftuar> wumpus: it looks like the issue in 248398016 may just be that i got the exception name wrong somehow
09:01 < sdaftuar> https://travis-ci.org/bitcoin/bitcoin/jobs/248398016#L3321
09:03 < sdaftuar> we can bump the rpctimeout for the test to fix that second problem
09:04 < wumpus> sdaftuar: oops, good catch, didn't notice that between all the errors
09:06 < wumpus> yes that seems just a case of 'travis VM too slow for timeout'
09:10 -!- mol [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev     
09:12 -!- molz [~IRCIdent@unaffiliated/molly] has quit [Ping timeout: 276 seconds]     
09:24 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
09:32 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
09:34 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
09:36 < cfields> wumpus: hmm
09:36 < cfields> wumpus: re the openbsd assembler, i think we could patch it to use the hex, same as rdrand? :(
09:38 < cfields> (i don't know enough about assemblers, but i figured that was done that way for exactly this reason)
09:38 < cfields> but yes, we could also check during configure
09:39 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
09:42 -!- bincap [~vd@85-222-72-154.dynamic.chello.pl] has joined #bitcoin-core-dev     
09:48 < sipa> cfields: yeah, i tried using rdrand as a mnemonic, but the osx assembler didn't accept it on travis
09:49 < sipa> hex always works, but the downside is that you must hardcode the registers
09:50 < wumpus> cfields: I don't particularly care if the sse-accelerated code is not used on openbsd
09:50 < wumpus> cfields: they have to use openssl -no-asm as well
09:51 < cfields> heh, really? That's a big hit
09:51 < wumpus> we definitely shouldn't dumb down the code just for this case, there's a large chance that openbsd will switch to clang at some pointa different as
09:51 < wumpus> yes, really
09:52 < cfields> yikes, ok
09:52 < wumpus> I don't want to get involved in the politics here, they choose to use an old as that doens't support modern instructions, they get slower code. It does need to compile, though.
09:53 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
09:53 < cfields> ok. let's just add an inline-compile check rather than trying to hunt down the assembler though. some (clang, at least) let you choose between an internal assembler or external
09:53 < sipa> using hex asm also has the advantage of not needing separately compiled objects just to have access to one asm instruction
09:53 < wumpus> their gcc is also -  by choice - an ancient version
09:54 < wumpus> ok, just don't do this for openbsd, it's likely a temporary issue
09:54 < sipa> agree
10:12 -!- JackH [~laptop@46.231.18.66] has quit [Remote host closed the connection]     
10:19 -!- Aaronvan_ is now known as AaronvanW     
10:21 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
10:24 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
10:30 -!- owowo [ovovo@gateway/vpn/mullvad/x-ohdrhpvnwfxtfocy] has joined #bitcoin-core-dev     
10:35 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has joined #bitcoin-core-dev     
10:49 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Remote host closed the connection]     
10:49 < bitcoin-git> [bitcoin] ka7 opened pull request #10705: Trivial: spelling fixes (master...feature/spelling) https://github.com/bitcoin/bitcoin/pull/10705
10:56 < bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/65cc7aacfbfc...0c3542e5dec3
10:56 < bitcoin-git> bitcoin/master 00cb69b Jonas Schnelli: [Qt] allow to execute a callback during splashscreen progress
10:56 < bitcoin-git> bitcoin/master ae09d45 Jonas Schnelli: Allow to shut down during txdb upgrade
10:56 < bitcoin-git> bitcoin/master 316fcb5 Jonas Schnelli: Allow to cancel the txdb upgrade via splashscreen callback
10:57 < bitcoin-git> [bitcoin] laanwj closed pull request #10660: Allow to cancel the txdb upgrade via splashscreen keypress 'q' (master...2017/06/chainstate_update_prog) https://github.com/bitcoin/bitcoin/pull/10660
11:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds]     
11:18 < bitcoin-git> [bitcoin] morcos opened pull request #10706: Improve wallet fee logic and fix GUI bugs (master...improveWalletFeeLogic) https://github.com/bitcoin/bitcoin/pull/10706
11:20 < bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/0c3542e5dec3...2935b469ae96
11:20 < bitcoin-git> bitcoin/master 6d22b2b Matt Corallo: Pull script verify flags calculation out of ConnectBlock
11:20 < bitcoin-git> bitcoin/master b5fea8d Matt Corallo: Cache full script execution results in addition to signatures...
11:20 < bitcoin-git> bitcoin/master eada04e Matt Corallo: Do not print soft-fork-script warning with -promiscuousmempool
11:20 < bitcoin-git> [bitcoin] laanwj closed pull request #10192: Cache full script execution results in addition to signatures (master...2017-04-cache-scriptchecks) https://github.com/bitcoin/bitcoin/pull/10192
11:24 < sipa> w00t
11:24 < BlueMatt> hey, neat
11:24 < BlueMatt> 0.15 is coming together :)
11:25 < Dizzle> Definitely. I'm sad unix sockets aren't in. Looking forward to that for my electrum server.
11:29 < wumpus> Dizzle: good to hear at least someone was waiting for the UNIX sockets stuff, did you review/test the PR?
11:29 < Dizzle> wumpus: I will be this weekend, am getting an electrumx patch ready for it.
11:29 < wumpus> awesome
11:33 < wumpus> Dizzle: are you going to use P2P or RPC over unix sockets?
11:33 < wumpus> (or both)
11:33 < Dizzle> RPC     
11:35 < Dizzle> Electrum servers tend to maintain their own utxo DB. Syncing with your node's db over RPC is a bit of a bottleneck. Using asynchronous i/o speeds things along but there is plenty of overhead using the TCP loopback when both softwares are in the same operating environment.
11:37 < bitcoin-git> [bitcoin] morcos opened pull request #10707: Better API for estimatesmartfee RPC  (master...bettersmartfeeapi) https://github.com/bitcoin/bitcoin/pull/10707
11:37 < wumpus> oh interesting, I had mostly seen the UNIX sockets as security improvement, not so much for performance, but yes avoiding local TCP might save some overhead
11:48 < gmaxwell> wumpus: well for p2p it would be a performance improvement if we changed the protocol and dropped the 'crc', but I don't think we were planning on doing that. 
11:49 < jcorgan> i have a non-bitcoin related application that communicates between two processes using a unix socket at a continuous 5Gbps data rate
11:49 < jcorgan> uses zmq over unix socket
11:50 < gmaxwell> jcorgan: yea, right now though for us the fact that every p2p message gets sha2ed is way more overhead than TCP.
11:50 < wumpus> http://bhavin.directi.com/unix-domain-sockets-vs-tcp-sockets/
11:50 < jcorgan> oh, sure, i was just commenting that unix sockets are pretty fast
11:51 < wumpus> so there's really a performance gain in both latency and throughput because no local network needs to be emulates, I never realized that
11:51 < wumpus> makes sense though
11:51 < gmaxwell> perhaps an input to the BIP151 stuff... that it should be possible to run it in a mode that turns off the auth for use over a domain socket at least.
11:52 < wumpus> well one of the uses for UNIX would be for tor; in that case we certainly don't want to disable the crcing, or auth. But agree it'd be nice to have it as possibility.
11:52 < gmaxwell> yea. and one always needs to worry about downgrade attacks.
11:53 < jonasschnelli> gmaxwell: great idea
11:53 < wumpus> it'd be another kind of whitebind 'nocrcbind' 'noauthbind'
11:53 < jonasschnelli> gmaxwell: But then there would be no checksum... if you disable the poly1305 mac?
11:53 < wumpus> bindflags extension
11:53 < gmaxwell> jonasschnelli: right but there isn't any need for one with a purely local unix domain socket.
11:54 < wumpus> jonasschnelli: over a local socket, when communicating with local software, there's no point
11:54 < jonasschnelli> Indeed.
11:54 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:54 < jonasschnelli> Corruption through socket coms is not possible I guess?
11:54 < wumpus> and the permissions of the socket itself are used for authentication
11:54 < jonasschnelli> *domain sockets
11:54 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving]     
11:54 < gmaxwell> jonasschnelli: no, not any more than any random memory anywhere.
11:54 < wumpus> no, unless memory/cpu corruption, in which case there's other issues
11:55 < wumpus> this is a SOCK_STREAM AF_UNIX socket, so neither reordering nor corruption nor packet loss should happen
11:55 < jonasschnelli> I see... yes. That mode would be awesome... especially for wallets (stuff I'm writing into libbtc) that downloads everything from the local peer
11:55 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
11:56 < wumpus> it's theoretically possible for SOCK_DGRAM AF_UNIX sockets to deliver packets out of order, though I've never heard of an OS that does that (but anyhow not an issue for us)
11:57 < jcorgan> one nice thing about ZMQ is that with a parameter change I can do the same thing between network endpoints on different hosts or two processes on the same host over a unix socket
11:57 < jcorgan> no code changes
11:57 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 258 seconds]     
11:57 < jcorgan> (or even two threads using zmq over shared memory)
11:57 < wumpus> yes, that's nice
11:58 < jcorgan> anyway, carry on
11:59 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev     
11:59 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
12:00 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Jun 29 19:00:12 2017 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:00 < sipa> oi     
12:00 < instagibbs> #meetingbegin
12:00 < wumpus> topics?
12:00 < morcos> i'd like to discuss the fee changes needed for 0.15
12:01 < sipa> i have a few topics
12:01 < instagibbs> morcos, ack
12:01 < sipa> short update on signature aggregation
12:01 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev     
12:01  * BlueMatt wants to change priority review to #10652
12:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
12:01 < gmaxwell> hurray for merges. 
12:01 < sipa> the need for the watchonly rpc flag after multiwallet
12:01 < cfields> hi, here
12:02 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
12:02 < sipa> rolling utxo hashes
12:02 < wumpus> thanks for the topic suggestions, yes let's as usual start with high priority for review
12:02 < wumpus> #topic high priority for review
12:02 < wumpus> https://github.com/bitcoin/bitcoin/projects/8
12:02 < jonasschnelli> suggesting: again multiwallet endpoint vs json parameter
12:02 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
12:03 < wumpus> BlueMatt: instead of #10179?
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
12:03 < BlueMatt> correct
12:03 < kanzure> hi.     
12:03 < BlueMatt> well, actually, its built on
12:03 < jonasschnelli> Replaced BlueMatt's 10179 with 10652
12:03 < BlueMatt> so...ehh
12:03 < BlueMatt> but, yea
12:03 < jonasschnelli> aha.. double pull binding strategy. :)
12:04 < BlueMatt> i mean 10179 is like one ack away, just want cfields to confirm i addressed his feedback sufficiently
12:04 < morcos> So I don't think I've had any there for a couple weeks, if I could add two?  It would be the first two of the fee changes, both have been open a little while, #10543 and #10589
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/10543 | Change API to estimaterawfee by morcos · Pull Request #10543 · bitcoin/bitcoin · GitHub
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/10589 | More economical fee estimates for RBF and RPC options to control by morcos · Pull Request #10589 · bitcoin/bitcoin · GitHub
12:04 < morcos> I apologize I have not been around to do more reviewing recently
12:05 < wumpus> BlueMatt: yes, as we discussed: it should still be merged, but it's no longer high-priority because you don't expect the dependent PR to get in in time to be safe for 0.15
12:05 < jonasschnelli> morcos: which one di you want to add to the high-prio list?
12:05 < jonasschnelli> *do     
12:05 < wumpus> both
12:05 < morcos> both! :)  but i suppose 10589, if i can only have one
12:05 < jonasschnelli> Good
12:06 < BlueMatt> wumpus: well I want some glances at 10652 pre-15 to see if its too much or if it can go ahead...if its small enough for 15 I do want it for 15
12:06 < cfields> BlueMatt: yes, good enough. Will ACK it.
12:06 < jonasschnelli> We need both for 0.15
12:06 < BlueMatt> (since it fixes the kinda-not-a-big-deal provide-invalid-block attack thing)
12:07 < wumpus> ok - any other suggestions?
12:07 < wumpus> enough other topics otherwise
12:07 < wumpus> #topic short update on signature aggregation
12:07 < sipa> hi     
12:07 < wumpus> (sipa)
12:07 < praxeology> Whats the status on the mempool data structure change?
12:08 < praxeology> woops not mempool
12:08 < sipa> this is just a status update of what gmaxwell, apoelstra and me have been working on lately
12:08 < praxeology> utxo
12:08 < wumpus> praxeology: you're interrupting a meeting
12:08 < sipa> i presented on this in milan, and later we wrote a paper for bitcoin17
12:08 < gmaxwell> praxeology: long since done.
12:08 < sipa> the paper was rejected with the very valuable feedback that a solution already existed
12:09 < sipa> namely a paper by Bellare & Neven from 2006
12:09 < sipa> it only solves one of the problems we were trying to solve (signature aggregation, not key aggregation)... but that's the only consensus-critical part if we'd want aggregation in bitcoin trnasactions
12:09 < gmaxwell> (which irritatingly never turned up in eons of searching for us)
12:10 < wumpus> so that solution is usable for bitcoin?
12:10 < sipa> yes     
12:10 < sipa> the advantage is that this is peer-reviewed scheme with a strong security proof under very wide assumptions
12:10 < wumpus> nice!
12:10 < gmaxwell> Their solution is almost equivilent to ours (or is equivient with the right kind of squinting about hash function definitions). 
12:10 < jonasschnelli> https://eprint.iacr.org/2006/285.pdf
12:10 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has joined #bitcoin-core-dev     
12:10 < gmaxwell> so thats good too.
12:11 < wumpus> yes     
12:11 < wumpus> good news
12:11 < gmaxwell> jonasschnelli: doesn't look like the right paper (though maybe its one they published to another venue)
12:11 < BlueMatt> cool!
12:11 < sipa> so what this scheme gives us is a way for transactions to have a single signature (as long as all signers cooperate, so even in the case of coinjoin) overall... regardless of the number of inputs or multisig
12:11 < wumpus> do we have a good link?
12:12 < sipa> https://cseweb.ucsd.edu/~mihir/papers/multisignatures-ccs.pdf
12:12 < sipa> ^     
12:12 < gmaxwell> ^ thats it.
12:12 < wumpus> #link https://cseweb.ucsd.edu/~mihir/papers/multisignatures-ccs.pdf
12:12 < sipa> what it does not do is an ability to turn multisig into signle sig (but that could be added on top later, as it's purely a wallet interaction thing)
12:12 < sipa> it also supports batch validation
12:12 < cfields> ooh     
12:12 < sipa> meaning that a whole block (or even multiple blocks) could be validated at once
12:13 < sipa> the speedup depends on the size of the batch, but may go as high as 5x (for 4000 signatures)
12:13 < gmaxwell> Unfortunately our paper isn't available because we need to update it to reflect that work,  but it is much more targeted for the Bitcoin application (and would probably be much more clear for people here).
12:13 < sipa> in the batch validation case (without aggregated signatures) the speedup would likely be restricted to 3.5x or so
12:13 < morcos> gmaxwell: is that something that'll happen?  can we just wait to read yours?
12:14 < sipa> yes, we'll definitely finish up the paper
12:14 < sipa> and discuss the change more widely
12:14 < sipa> just wanted to give a heads up here
12:14 < wumpus> yes, thanks for the update!
12:14 < morcos> if i could have next topic, i have to leave early
12:14 < cfields> sipa: what about that per-block aggregation that was briefly discussed? does this get us any closer to that?
12:14 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
12:14 < cfields> nm, will follow-up after meeting
12:15 < wumpus> morcos: what was your topic?
12:15 < gmaxwell> ~2.3x speedup for 32 signatures in the aggregate, fwiw.
12:15 < morcos> Fee changes for 0.15
12:15 < wumpus> #topic fee changes needed for 0.15
12:15 < wumpus> morcos: sorry, missed that one
12:15 < wumpus> morcos: you were actually first to propose a topic :)
12:16 < morcos> I'll be relatively quick for my part, I think I've got all the PR's out now that I think need to go in for 0.15, but I want to encourage people to think about a bunch of the RPC API changes so they are good in their first release
12:16 < morcos> But the other thign is there is one piece of missing functionality wheich I think is needed
12:16 -!- goatpig [5a5c653a@gateway/web/freenode/ip.90.92.101.58] has quit [Quit: Page closed]     
12:16 < morcos> #10590
12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/10590 | Access to longer fee estimates using GUI · Issue #10590 · bitcoin/bitcoin · GitHub
12:17 < morcos> Given how volatile fee estimates are and how much they change between short targets and long, I think it's important to give the GUI access to longer fee estimates
12:17 < morcos> But someone more familar with QT can probably whip that up a lot quicker than me
12:17 < morcos> Might be best to build it on top of all my other changes, #10707 shoudl have everything in one
12:17 < gribble> https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
12:17 < jonasschnelli> I'll have a look.
12:18 < morcos> Thanks!  That's what I was hoping for. :)  instagibbs might have more on this topic?
12:18 < instagibbs> #10333 for fee bug fix :)
12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
12:18 < instagibbs> not much else, maybe I'll summon energy to review your PRs
12:18 < morcos> is that the only thing you feel is critical for 0.15?
12:18 < instagibbs> only realistic merge yeah 
12:18 < morcos> most of mine are now easy to review i think
12:18 < gmaxwell> Do we have a feel for when bump will be generally usable enough to start making replacability a default? (or at least more visible?)
12:19 < instagibbs> some of my other work has been sucked up by achow101 so waiting on 0.16 for that stuff
12:19 < morcos> gmaxwell: at least it'll be easily accessible to choose RBF given the RPC and GUI options in 0.15
12:20 < instagibbs> I'd really like it to be able to add additional inputs as needed
12:20 < gmaxwell> Oh!  I often miss gui changes, I'll check that out.
12:20 < jonasschnelli> Yes. Not sure if we persist the RBF state across restarts (in the GUI)
12:20 < morcos> Might help us learn if there are other bump features needed...   
12:20 < instagibbs> but it seems to me the logic is much simpler with effective value....
12:20 < jonasschnelli> Ideally we should
12:20 < instagibbs> some disagree
12:20 < gmaxwell> instagibbs: IIRC that was the big usability blocker for further use.
12:21 < wumpus> gmaxwell: https://github.com/bitcoin/bitcoin/pull/9527#issuecomment-311659024
12:21 < instagibbs> it randomly doesn't work which is disappointing UX
12:21 < morcos> gmaxwell: the ability to addother inputs?  isn't it pretty rare to not have change?
12:21 < jonasschnelli> But can happen...
12:21 < wumpus> no, we don't persist RBF state, it has to be selected per transaction
12:22 < jonasschnelli> wumpus: maybe the GUI should remember it
12:22 < instagibbs> morcos, we are going to target more exact matches in future, fwiw
12:22 < wumpus> the only way to make it persist is the command line option
12:22 < morcos> wumpus: the gui initializes with the the command line argument, and then persists during the session
12:22 < wumpus> jonasschnelli: meh, better to have it as "option" then
12:22 < gmaxwell> FWIW, I believe electrum defaults to replacable now and pushes pretty hard in that direction, though users can flip it off on a per tx basis.
12:22 < morcos> via checkbox
12:22 < wumpus> jonasschnelli: persisting non-option settings between restarts would be unexpected
12:23 < jonasschnelli> Yes. I guess your right..
12:23 < gmaxwell> In any case, I think the default is kind of moot until bumping is sufficiently mature.
12:23 < wumpus> between transactions in the same session makes sense I guess
12:23 < morcos> I suppose I have one more question on that
12:23 < jonasschnelli> Yes. If the bump won't work because it can't add another input the default should remain at the current state
12:23 < wumpus> yes     
12:23 < jonasschnelli> It can happen quickly when fees are rising
12:23 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev     
12:23 < achow101> hi. I'm late
12:24 < morcos> Right now there are no options to the "Increase transaction fee" option in the GUI and it uses the default tx confirm target.  Should it instead use whatever the slider is set to?
12:24 < jonasschnelli> Yes     
12:24 < morcos> If the slider is not in use and custom fee is set, shoudl it use that?
12:24 < wumpus> morcos: the slider is on another tab
12:24 < jonasschnelli> I'd like to work on the replacability in the GUI for 0.16
12:24 < morcos> Those would be easy changes to make after my PR
12:24 < BlueMatt> the slider is in another tab, thats strange
12:24 < wumpus> morcos: not sure that would be intuitive, people assume the slider is for new transactions, the bump option should probably have its own choice dialog
12:24 < jonasschnelli> First I though of bringing back to tx to the original send-tx screen (you could even add recipients... ) but meh
12:25 < morcos> wumpus: that seems maybe too much optionality
12:25 < jonasschnelli> The bump window should just be lager and has the slider
12:25 < wumpus> jonasschnelli: yes
12:25 < morcos> ok, thats fine.. so leave it as the wallet default confirm target for now?
12:25 < wumpus> yes     
12:25 < BlueMatt> yea, sucks, but its easy and reasonable
12:25 < jonasschnelli> And also we have never really discussed the pre-signed bumps.. but that we should probably do in another meeting
12:25 < BlueMatt> yea, that sounds like a 16
12:25 < instagibbs> jonasschnelli, that will involve new strategy
12:26 < instagibbs> :)     
12:26 < instagibbs> reasonably diff from after the fact fix imo
12:26 < jonasschnelli> I'd say focus on fee opt. in 0.15, rbf in 0.16
12:27 < wumpus> agreed
12:27 < wumpus> #topic the need for the watchonly rpc flag after multiwallet (sipa)
12:27 < sipa> hi!     
12:27 < wumpus> (we need to move forward a bit, lots of topics)
12:27 < sipa> currently many RPCs have an optional flag "include watchonly"
12:27 < jonasschnelli> is that similar to the -disablehot?
12:27  * jonasschnelli is listening
12:28 < sipa> at the time the need for that flag existed because of a desire to keep your "hot" wallet separated from your "watch only" wallet
12:28 < sipa> i think that was a mistake
12:28 < wumpus> disablehot: #9662
12:28 < gribble> https://github.com/bitcoin/bitcoin/issues/9662 | Add `-disablehot` mode: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub
12:28 < wumpus> sipa: yes, on the long term I agree with you
12:28 < jonasschnelli> sipa: you think with multiwallet the wallet should either be watch or hot?
12:28 < sipa> jonasschnelli: no
12:29 < wumpus> sipa: makes more sense to have a wallet either full-watchonly or has-keys
12:29 < sipa> wumpus: perhaps, but that's orthogonal
12:29 < wumpus> sipa: I don't understand you then
12:29 < instagibbs> ok get to the point :)
12:29 < BlueMatt> why is that a mistake?
12:29 < jonasschnelli> Let sipa explain...
12:29 < sipa> what i'm trying to get at is that the within-a-wallet separation is no longer needed
12:29 < wumpus> how is that different from what I said?
12:30 < wumpus> instead of watchonly within a wallet you'd have a watchonly wallet and a normal wallet
12:30 < sipa> i'm not arguing to remove the ability to have both keys and watchonly in one wallet
12:30 < gmaxwell> because if you want to have a mixed thing thats fine too, then you just have a mixed thing. No need to flag, if you want seperation, use two wallets.
12:30 < jonasschnelli> but I fail to see the difference then between only allowing watch-only or hot
12:30 < sipa> just that there is no need to just select coins that affect one part
12:30 < gmaxwell> you're suggesting an extra restriction.
12:30 < sipa> or see a 'balance' of just one part
12:30 < sipa> a wallet is a wallet, and has a single balance
12:31 < sipa> some of the keys may require decrypting your wallet
12:31 < wumpus> oh, right
12:31 < sipa> some of the keys may require a hardware wallet
12:31 < jonasschnelli> I see... yes.
12:31 < sipa> some of the key may be just watchonly and you need to use raw transactions to interact with thing
12:31 < BlueMatt> fair, this sounds like an 0.17 or 0.18 thing, though
12:31 < gmaxwell> Now, logically you probably will seperate or something, for convience, but I don't see a particular reason to require that right now. 
12:31 < BlueMatt> are you asking if we should deprecate?
12:31 < sipa> i was hoping 0.15
12:31 < wumpus> BlueMatt: agree, long term
12:31 < sipa> just make the watchonly flag ignored and always set it to true
12:31 < wumpus> this is not something we're going to change in the RPC interface pre-0.15
12:31 < sipa> ok     
12:31 < wumpus> peopel rely on this 
12:32 < wumpus> we could document it as deprecated
12:32 < BlueMatt> we'd need to mark it deprecated
12:32 < morcos> sipa: that seems reasonable except what about identifying which things you have keys for and which you dont.. 
12:32 < BlueMatt> probably deprecate after we have working multiwallet that is stable
12:32 < wumpus> then remove the flag for 0.16 or 0.17, but this seems over-hurried
12:32 < BlueMatt> so maybe deprecate in 0.16...
12:32 < morcos> that seems a useful distinction to keep to me
12:32 < gmaxwell> with 0.15 and multiwallet we can start deprication at least-- e.g. advise that this will happen in the future, suggest people use seperate wallets. . The one problem with that however is that your seperate watchonly wallet still needs the stupid flag everywhere. :(
12:32 < BlueMatt> remove in 17 or 18
12:32 < wumpus> let's focus on actually getting multiwallet into 0.15
12:32 < jonasschnelli> I somehow think mixed wallets can be a footgun source... but right, it orthogonal 
12:32 < instagibbs> related topic: some way to signal that the funds are "safe" when you expect a hardware wallet to have the privkey
12:32 < instagibbs> post-0.15 ofc
12:32 < sipa> maybe i haven't made this clear, but how do you deal with hardware wallets, for example?
12:33 < jonasschnelli> we need a standard!
12:33 < sipa> add a 2nd option everyone 'include hw wallet keys'
12:33 < morcos> +1 better support for hardware wallets!
12:33 < sipa> jonasschnelli: orthogonal
12:33 < wumpus> hardware wallets in bitcoin core is a different topic
12:33 < BlueMatt> we dont need to add a flag for hw wallets
12:33 < sipa> BlueMatt: then why do we need a flag for watchonly?
12:33 < wumpus> important, but certainly not one that's going to make it into 0.15
12:33 < BlueMatt> we can say "hw wallets are always included in balance, flag for watchonly is deprecated" starting in the version that supports hw wallets
12:33 < gmaxwell> sipa is pointing out that the model of 'watch only' when applied to also having hardware wallets starts adding combinitoric blowup.
12:33 < sipa> BlueMatt: fair enough
12:34 < jonasschnelli> If a wallet has no clear cur between hot and cold (watch-only), a code-level guarantee, I would not use it for hot funds...
12:34 < BlueMatt> yes, agreed, we should not make it worse, but we dont need to worry about this until at least 16, I think
12:34 < jonasschnelli> *cut
12:34 < wumpus> agree on not making it worse
12:34 < BlueMatt> need useable working good multiwallet first, which likely wont be 15
12:34 < gmaxwell> BlueMatt: thats a point. now just give me a flag for importmulti that gives me a watching key imported that way and it's good to go. :P
12:34 < sipa> jonasschnelli: again, orthogonal
12:34 < instagibbs> I have a working Core+Ledger system, and have a couple thoughts, but this is a different topic yep
12:34 < gmaxwell> BlueMatt: uhh, it's like done.
12:34 < jonasschnelli> sipa: but why not just separating pure watch-only wallets from hot wallets? Why would that be orthogonal?
12:35 < BlueMatt> gmaxwell: I know, but we need a cycle of finding more use-cases and making sure we've got it all covered, was my piont
12:35 < wumpus> yes multiwallet is almost done, but in 0.15 it will at least be experimental
12:35 < BlueMatt> eg createwallet flows within rpc, disconectwallet, etc
12:35 < sipa> jonasschnelli: "orthogonal" means you can still do that
12:35 < sipa> jonasschnelli: it has nothing to do with this issue
12:35 < wumpus> it's the first release it is in, after all
12:35 < gmaxwell> jonasschnelli: because that is an additional restriction that AFAIK isn't needed. maybe later its needed to not support mixed but it seems like a seperate issue to me.
12:35 < jonasschnelli> Okay
12:36 < BlueMatt> ok, so we all agree, eventually push people towards multiwallet away from watchonly :)
12:36 < BlueMatt> next topic? :p
12:36 < sipa> what i want to get add is that a wallet is just a collection of keys it considers "mine" - independent of its ability to actually fully sign
12:36 < sipa> BlueMatt: yes, agree
12:36 < wumpus> #topic rolling utxo hashes
12:36 < wumpus> (sipa again)
12:36 < sipa> hi!     
12:36 < instagibbs> sipa, ISMINE_* tho :)
12:36 < instagibbs> ok next topic
12:36 < sipa> with pertxout we changed the serialized_hash because the new format no longer maintains the tx version of the utxo
12:37 < sipa> i posted about rolling utxo hashes a while ago on the ML
12:37 < sipa> i'm not proposing actually implementing that, but would it be worthwhile to immediately switch to a scheme that is compatible with it?
12:37 < sipa> so that there is no need to break the API again
12:38 < gmaxwell> sipa: as in don't do the rolling thing, but have the oneshot thing compute the same hash?
12:38 < sipa> yes     
12:38 < sipa> downside: makes gettxoutsetinfo slower
12:38 < wumpus> how much slower?
12:38 < sipa> upside: allows us to make gettxoutsetinfo super fast in the future
12:38 < gmaxwell> lots slower. 
12:38 < sipa> several times
12:38 < wumpus> could add a new RPC for it
12:39 < gmaxwell> sipa: Well a challenge there is that I'm not sure that we've settled on the field. So that isn't a guarentee of compatiblity.
12:39 < wumpus> instead of gettxoutsetinfo
12:39 < sipa> interesting, i hadn't considered that
12:39 < sipa> gmaxwell: yeah, i know
12:39 < gmaxwell> actually if we drop the hash from gettxoutsetinfo i think thats the only thing now that requires scanning the whole thing.
12:39 < sipa> no, everything does
12:40 < sipa> (txout count etc)
12:40 < wumpus> yes it's all aggregate statistics
12:40 < gmaxwell> yes but it wouldn't have to with rather trivial changes.
12:40 < sipa> though those things can be maintained on the fly
12:40 < gmaxwell> which would be robust and wouldn't change.
12:40 < sdaftuar> i think we will want an RPC that can scan the disk to calculate the answer, even if we are able to calculate everything on the fly
12:40 < sdaftuar> so that we know our on-disk data is correct
12:40 < sipa> sdaftuar: good point
12:40 < gmaxwell> sdaftuar: restart your node. :P
12:41 < sipa> an advantage of the fast hash is that you can compare it with a recompute-the-whole-thing
12:41 < gmaxwell> okay interesting points.
12:41 < wumpus> that'd be very nice
12:41 < wumpus> a utxo hash that would be quick to compute for every block would be very nice to have
12:42 < gmaxwell> (I was momentarily overestimating how easy it would be to switch to summary statistics, I forgot that they have to be saved and loaded across restart... or otherwise every startup needs the equal of a stats call)
12:43 < gmaxwell> wumpus: right thats the goal of pieter's work. It's just a bit immature now, and if we implmenet it at the moment we may want to switch to an incompatible version later.
12:43 < wumpus> I like to check that all my nodes have the same utxo hash, but calling getutxosetinfo for every block takes too much time, I've tried and given up :)
12:43 < gmaxwell> Assuming we stay with the multiplicative group hash,  we need to pick a prime where multiplication mod that prime is as fast as possible.  Sipa has done some work there, but it's a research project that can sink as much time as we want to put into it.
12:44 < sipa> or we could just use the elliptic curve version, which can probably be made ~2 slower than the GMP-based MuHash
12:44 < sipa> which is just a few lines of code
12:44 < wumpus> now doing it intermittently, but that means that when it fails we don't know exacly where it started to diverge
12:45 < gmaxwell> right, I want to have UpdateTip log the value.
12:45 < sipa> ^ that
12:45 < sdaftuar> wumpus: it's actually not clear to me how much the fast utxo hash calculation helps in comparing running nodes
12:46 < sipa> well the fast utxo hash lets you do a consistency check on just a single node
12:46 < sdaftuar> but what is exactly being compared as consistent?
12:46 < sipa> by having a fast incrementally-updated version, and a slow recompute-from-scratch one
12:46 < gmaxwell> sdaftuar: because you can log the utxo hash at each point, and so if they diverge in a way that the hash sees (e.g. not underlying disk corruption) you'll learn.   Also you could run a command that checks the disk against the running value to catch that disk corrouption.
12:46 < gmaxwell> so  your disk <> your running <> my running <> my disk
12:47 < sdaftuar> yes, i agree if you do the comparison with disk, then you get something valuable
12:47 < sdaftuar> but just comparing the fast calculation between nodes doesn't seem like it does much, does it?
12:47 < wumpus> hm yes good point
12:47 < gmaxwell> right now it is a PITA to compare you and I at disk because we have to do it at the same time (and hope there isn't a block at that instant. :P )
12:47 < sdaftuar> gmaxwell: agreed
12:47 < gmaxwell> sdaftuar: it depends on where the errors you're concerned about are happening.
12:48 < wumpus> gmaxwell: yes, even when you time the RPC command on blocknotify, it sometimes misses the block :)
12:48 < gmaxwell> if they're below the layer where the running hash runs you only gain if you also do periodic checks between it and the disk.  Above it, however, you have constant checking.
12:49 < gmaxwell> but the nice thing is that disk and running can be async checked... You and I don't need to do our disk comparisons at the same time.
12:49 < wumpus> indeed
12:49 < gmaxwell> sdaftuar: this is all also machinery we almost certantly need for a reasonable UTXO-assume-valid kind of sync in the future.
12:49 < wumpus> all in all a rolling utxo hash is an improvement, it creates more options, but you can still do the same as now if you want
12:50 < sdaftuar> gmaxwell: yeah i agree and that's the use case i'm most excited about :)  
12:50 < sdaftuar> i was just trying to figure out exactly how i'd use to compare my own nodes, and wasn't sure of the utility
12:50 < gmaxwell> wumpus: the challange though is that it isn't free. muhash on the whole utxo set takes CPU minutes. 
12:51 < wumpus> gmaxwell: yes I'm not sure it should replace the faster hash
12:51 < wumpus> maybe it should justb e an additional thing
12:51 < gmaxwell> well once it's a running hash its very fast. :P
12:51 < sdaftuar> hash_serialized_3? :P
12:51 < wumpus> OTOH we're already breaking the hash for 0.15
12:51 < wumpus> (which is kind of sad, as it makes it impossible to compare against older versions)
12:52 < gmaxwell> sipa backported the new hash to the old system for development testing, FWIW.
12:52 < gmaxwell> (it's a pretty trivial change, IIRC, just drop the version from it)
12:53 < wumpus> cool, that'd be useful, especially with the 0.14 to 0.15 database change it's important to be able to check synchronization
12:54 < gmaxwell> This patch existed at one point already, dunno if sipa still has it.
12:54 < sipa> the problem is that #10434 is quite a bit of intricate code
12:54 < gribble> https://github.com/bitcoin/bitcoin/issues/10434 | [WIP] 3072-bit MuHash based hash_serialized by sipa · Pull Request #10434 · bitcoin/bitcoin · GitHub
12:54 < sipa> the EC version would be many times less code (given that we already have secp256k1), but be a few times slower
12:55 < wumpus> I don't have a strong opinion on it
12:55 < sipa> on the other hand, MuHash is very simple to implement in anything that already has big integers (it's a few lines in python)
12:55 < sipa> ok     
12:56 -!- tmddzk [~tom@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
12:56 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]     
12:56 < wumpus> though in general I'd say higher performance seems preferable to the ability to re-use code
12:56 < sipa> in that case, some review would be welcome :)
12:56 < wumpus> but I haven't seen the code
12:56 < wumpus> yeah, hope to get around to it
12:56 < sipa> i can drop the asm optimized version from the first PR if wanted
12:57 < praxeology> Couldn't you put a delay on insert/remove from the rolling hash... say only for utxos that are 1 day of blocks old? isn't a hash for N blocks ago just about as good as the current hash?
12:57 < sipa> praxeology: totally irrelevant
12:57 < sipa> that would mean you need to keep those utxos around for processing later
12:57 < sipa> we have an approach that can combine them into a running hash in _microseconds_
12:58 < gmaxwell> All doing that does is perhaps saves you 1% of computation for blocks that are reorged out but at the expense of complexifying everything because the data is inconsistently available. 
12:58 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
12:58 < praxeology> What percent of utxos are spent within a day?
12:58 < instagibbs> 2 minutes left
12:58 < instagibbs> if anyone has microtopic
12:58 < wumpus> that seems irrelevant to this discussion
12:58 < wumpus> (although it's interesting to know in its own right)
12:59 < praxeology> Sounds like you guys are concerned about performance on the rolling hash
12:59 < wumpus> #endmeeting
12:59 < lightningbot> Meeting ended Thu Jun 29 19:59:24 2017 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/2017/bitcoin-core-dev.2017-06-29-19.00.html
12:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-29-19.00.txt
12:59 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-29-19.00.log.html
12:59 < gmaxwell> praxeology: delaying it doesn't change that.
12:59 < instagibbs> sipa, you still around?
12:59 < sipa> instagibbs: sure
12:59 < instagibbs> ok let me toss a wallet q to you
12:59 < gmaxwell> praxeology: its the same amount of computation if you do it now or 100 blocks ago. 
12:59 < midnightmagic> Man I wish people would end meetings elsewhere with that kind of precision..
13:00 < wumpus> yes it'd just move the computation in time
13:00  * midnightmagic shudders
13:00 < wumpus> midnightmagic: I guess they should hire me as meeting chair :p
13:00 < praxeology> gmaxwell:  delaying will reduce the number of things that are xored (err whatever math op you doing), since utxos that were spent before the delay window are never added
13:00 < gmaxwell> praxeology: if you imagine something which is never consistent with any actual state of the system, then that really isn't all that useful. 
13:00 < BlueMatt> I was gonna say something about the swiss leading the meeting, but its wumpus, not jonasschnelli
13:00 < instagibbs> sipa, so for hw wallets, would it be reasonable to have a new ISMINE type that means the wallet expects the output to be spendable by the wallet even though privkeys aren't physically present in the wallet.dat
13:00 < sipa> instagibbs: in my opinion, ISMINE should become a bool
13:01 < sipa> it's yours or not
13:01 < gmaxwell> praxeology: that isn't delayed. 
13:01 < instagibbs> ah ok, so no
13:01 < midnightmagic> wumpus: :-)  Your nickname shall be The Guillotine
13:01 < instagibbs> well in that case at least some of the logic could be moved elsewhere
13:01 < sipa> instagibbs: the ability to spend should be independent from what is considered yours
13:01 < sipa> instagibbs: (note, that's my personal opinion)
13:01 < gmaxwell> praxeology: I believe what you are suggesting doing is computing it sparsely so that there isn't a value computed at every block.
13:01 < wumpus> midnightmagic: :-)
13:01 < instagibbs> no it's fair, I'm just trying to get my wallet to understand what I consider mine
13:01 < instagibbs> and right now it's janky mess
13:02 < sipa> instagibbs: perhaps the solvable distinction is still useful
13:02 < instagibbs> so a new "consider yours" function would fix my current issue in a cleaner way
13:02 < sipa> cfields: still around?
13:02 < achow101> instagibbs: isn't there some combination of ISMINE_ types that indicate "no privkey in wallet but I can still spend it"
13:02 < gmaxwell> praxeology: this would reduce computation somewhat, but at the expense creating coordination points... and then you only perhaps get a 2x speedup, but you also add bursts of letency rather than being able to compute it continually.
13:02 < cfields> sipa: yes
13:03 < praxeology> gmaxwell: I'm suggesting only adding a utxo to the hash on the 144th confirmation
13:03 < instagibbs> achow101, there is solvable+watchonly
13:03 < instagibbs> but that doesn't mean you can spend it
13:03 < gmaxwell> praxeology: that would make something which is _never_ consistent with the utxo set at any point, I think this would be completely useless to us.
13:03 < instagibbs> so if you have a hw wallet, you expect to be able to sign for it, but there's no enum for it
13:03 < gmaxwell> praxeology: it couldn't be used to check database consistency, it couldn't be used to perform a sync from utxo.
13:04 < sipa> praxeology: that sort of approach may be useful for UTXO/TXO commitment like approaches, where updating the commitment is very expensive and cheaper when batched
13:04 < instagibbs> so in corner cases you consider that output untrusted, and get "insufficient amount"
13:04 < sipa> praxeology: but the rolling UTXO idea was specifically intended to not need that, because it's so fast
13:04 < praxeology> gmaxwell: if you have the last 144 blocks then you can do the remainder of the utxos from those blocks to finish the hash at a particular point
13:04 < achow101> instagibbs: oh
13:04 < bitcoin-git> [bitcoin] narula opened pull request #10708: Connecttrace fewer blocks (master...connecttrace-fewer-blocks) https://github.com/bitcoin/bitcoin/pull/10708
13:05 < sipa> praxeology: just looking up a utxo spent from disk is more work than updating the hash
13:05 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
13:05 < cfields> neha__: eh? :)
13:05 < instagibbs> achow101, I coded a fix for this corner issue, but only for p2sh multisig... current methodology kind of forces me to do janky fix or make another ismine enum :/
13:06 < praxeology> sipa: yes, well not sure the use case of when such would be needed
13:06 < achow101> just make ismine a bool :p
13:07 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
13:08 < praxeology> earlier you guys were talking about a tx just having one signature, even for multiple things that need to be signed.  You talked about computation performance.  What about impact on tx size?
13:08 < praxeology> particularly since... i hear that network bandwidth is the main bottlneck
13:09 < instagibbs> N signatures in 1 signature space possible, across inputs. Still need the pubkeys
13:10 -!- neha__ is now known as neha     
13:11 < praxeology> sure, still need public keys.  but what about the signature size?
13:11 < neha> cfields: BlueMatt gave me an issue to fix!
13:11 < sipa> 64 bytes instead of N*72
13:11 < sipa> praxeology: ^
13:11 < gmaxwell> praxeology: instagibbs said: one signature.
13:12 < sipa> praxeology: and bandwidth isn't all that much of a factor anymore single compact blocks etc
13:12 < cfields> neha: good to see! that's a rabbit hole. I'd be nervous if you didn't find more things to fix while you're down there :)
13:12 < instagibbs> achow101, sounds simple, but let's see all the interaction with current wallet stuff
13:12 < gmaxwell> (the signatures in bitcoin today are 72 instead of 64.125 just because they use a dumb encoding.
13:13 < gmaxwell> )     
13:13 < praxeology> sipa: do you have a layman link for "single compact block"? or anyone?
13:13 < sipa> praxeology: bip 152
13:14 < sipa> i'm sure there are better explanation online than the bip, though
13:14 < gmaxwell> I dunno the bit is pretty good.
13:14 < gmaxwell> bip     
13:14 < instagibbs> gmaxwell, speaking of which how is 0.5RTT going these days, any change?
13:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
13:14 < sipa> cfields: so the block-wide aggregation that adiabat proposed a while ago on the ML still applies to Bellare-Neven... allowing to have only 32 bytes of the signature in every tx, and another 32 byte block wide
13:14 < instagibbs> (if you're monitoring)
13:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
13:15 < sipa> cfields: the downside is that it doesn't play nicely with cached signature validation
13:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
13:15 < gmaxwell> instagibbs: meh, we need the skip-recent-txn things in mining.  It's gone up and down (in particular utility of the extrapool has gone up and down)
13:15 < sipa> cfields: as wtxids would change after inclusion in a block
13:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:15 < gmaxwell> instagibbs: during periods of long backlogs the extrapool is too small-- I see misses that my node had seen before.
13:15 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
13:16 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer]     
13:16 < cfields> sipa: hmm. Does parallel validation still apply as well?
13:16 < praxeology> sipa: oh, that is just where txs are not re-relayed with blocks.  Something  like a 1/2 bandwidth used improvement.
13:16 < cfields> *the parallel validation improvements
13:17 < praxeology> or is there something else I missed when skimming? something on the order of mimblewimble improvement?
13:17 < sipa> praxeology: yes, but the bandwidth needed to propagate a block quickly is massively reduced
13:17 < sipa> praxeology: overall data volume is reduced by 2
13:17 < gmaxwell> praxeology: typically at the tip blocks are transmitted with about 16kbytes.
13:18 < sipa> cfields: yes
13:18 < sipa> cfields: you can just shard and do the computation for a number of groups
13:18 < sipa> and then do a simple cheap combine operation
13:19 < gmaxwell> you lose some of the asymtoptic gains though we've been expirementing with parallel versions of the aggregate validation operation.
13:20 < gmaxwell> instagibbs: in the last 144 blocks I see 23% requiring a round trip. 13% were saved from needing one by the extra pool.  A week ago the extrapool saves were about half that I think.
13:21 -!- owowo [ovovo@gateway/vpn/mullvad/x-ohdrhpvnwfxtfocy] has quit [Read error: Connection reset by peer]     
13:22 < cfields> sipa: if we cached as much as possible otherwise (hashing mainly, i suppose) and completely dropped the pre-validated cache, do you have a sense of how it'd compare? I realize it'd be worth keeping the cache as it'd still have a good hit rate, i'm just curious.
13:23 < sipa> cfields: i don't understand
13:23 < gmaxwell> cfields: I'm unclear about what you're asking.
13:24 < cfields> trying to weight the benefits of parallel validation against losing some pre-cached hits
13:24 < sipa> well, do both
13:24 < gmaxwell> yea, there isn't any conflict. You parallel validate the things that miss the cache.
13:24 < sipa> oh, you mean with the block-wide aggregation
13:24 < gmaxwell> do you mean batch validation instead of parallel btw?
13:25 < sipa> my concern there is mostly the layering violation
13:25 < gmaxwell> the block wide aggregation stuff is ugh
13:25 < cfields> yes, sorry. i meant batch.
13:26 < BlueMatt> instagibbs: I think we'd actually see a bigger improvement by responding to getblocktxn requests in the background while connecting a block than making 0.5rtt more common
13:26 < BlueMatt> network-wide that is
13:26 < BlueMatt> though 0.15 may speed up block connection enough.....anyway
13:26 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
13:28 < instagibbs> BlueMatt, i was hoping for lazy improvements, like "it got better" :P
13:28 < instagibbs> yeah I reviewed a PR for that a long while ago
13:29 < sipa> cfields: so for batch validation... batch validate the txn in a block you haven't seen yet, and ignore the rest
13:29 < sipa> (assuming there is no block-wide anything going on)
13:29 < gmaxwell> BlueMatt: if you want to make that even faster: create a ReadBlockFromDisk that returns a blockblob (don't deseralize the transactions in it).
13:29 < gmaxwell> and use that for all getblocky kinds of requests.
13:30 < gmaxwell> (the cases not covered by the cached getblocktxn are whole block requests...)
13:30 < gmaxwell> (and we waste time deseralizing then reserializing the blocks...)
13:30 < cfields> sipa: ah, makes sense
13:31 < gmaxwell> cfields: there is a bit of a conflict right now because batch and parallel are in competition with each other... bigger batches get more speedup, but you want to use all your cores....
13:34 < cfields> is the batch operation itself not parallelizable?
13:34 < BlueMatt> gmaxwell: I'm less concerned about that w/ parallell ProcessMessages - if you ask for an old block its gonna be slow (though I agree that we should fix that, just less interesting for the latency improvements)
13:35 < BlueMatt> instagibbs: well that one got dropped in favor of "doing it cleanly"
13:35 < cfields> i suspect I'm misunderstanding the conflict
13:35 < BlueMatt> instagibbs: now its 10652 + the two other PRs that make up that branch, then an actual parallellization PR
13:35 < BlueMatt> so....16? maybe 17
13:35 < instagibbs> BlueMatt, ah k
13:35 < instagibbs> clearly behind the times
13:38 < sipa> cfields: a batch of 4000 signatures takes less than 8 times as much CPU as a batch of 500 signatures
13:38 < sipa> cfields: if you split the batch up in 8, and run those 8 on separate CPUs, you're going to do 8*batch(500) work, not 1*batch(4000) work
13:39 < gmaxwell> cfields: the algorithim is not naturally parallizable, though with lots of synchronization traffic it can be made parallel.
13:40 < gmaxwell> how much of the batch(4000) speed we can get out of something pushed to be made N-way parallel is an open question.
13:40 < gmaxwell> If synchronization between threads is free the answer is "almost all of it"
13:40 < cfields> ok that's what i was missing, thanks
13:40 < gmaxwell> If it is very expensive, the answer appears to be "almost none of it".
13:40 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]     
13:40 < cfields> i'll read the paper before discussing further
13:41 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
13:41 < gmaxwell> None of this is in the paper.
13:41 < cfields> oh. in that case, I already read the paper :p
13:41 < sipa> cfields: the 'hard' part of the computation is doing a huge n1*P1 + n2*P2 + n3*P3 + ... (where the n's are integers and the Ps are EC points)
13:42 < sipa> turns out, there is a very neat algorithm (multiple, in fact) that do this whole computation many times faster than just multiplying individually and adding
13:42 < gmaxwell> Same as for a normal signature validation except there it's  just n1 * P + n2 * G  ... so only two ecpoints.  in batch and aggregate validation there is  pubkeys + 1. 
13:46 < gmaxwell> done simply, a n1*P requires 256 EC additions (technically 256 doublings and 128 additions, but doublings are about twice as fast as an addition)-- using grade school long multiplication (in base 2).  The batch computation of n1*P1 + n2*P2 + n3*P3 + ... can do the job in about 26 additions per point for 4096 inputs.
13:46 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:47 < cfields> whoa
13:47 < cfields> oh, misread :)
13:47 < gmaxwell> yes per point, but still thats almost a 10x speedup over a dumb algorithim.
13:50 < cfields> are there further speedups if the result is known ahead of time and you're just attempting to verify correctness?
13:50 < gmaxwell> What we do in secp256k1 for validation (which is two points) is far from simplisic and takes much less than 256 adds worth of work per each.  I believe it's about equal to about 84 per point. 
13:51 < gmaxwell> cfields: the aggregate and batch both count on a property like that.
13:51 < gmaxwell> the R value in the signature is the result of this calculation.
13:52 < cfields> ah, so that's the 32bytes-per-block
13:54 < sipa> cfields: eh, i think you're confused
13:54 < sipa> cfields: perhaps we should move to #secp256k1
13:54 < cfields> sure
13:55 < gmaxwell> To be clear: Batch validation exploits ' the result is known ahead of time and you're just attempting to verify correctness'   --- because the signature (or each signature) has an R value that comes with it, and the signature validation is trying to verify that an R value it computes is the same as the provided one.
13:56 < gmaxwell> You can also encode signatures another way, like the wikipedia article on schnorr signatures does-- using "e,s" which is a hash and a scalar; and this form cannot be batch verified because you don't know the result of that multiexp equation in advance.
13:58 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has quit [Quit: Leaving]     
14:07 -!- awsom82 [~Igor@broadband-109-173-48-122.moscow.rt.ru] has joined #bitcoin-core-dev     
14:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
14:39 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
14:41 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
14:53 < cfields> BlueMatt: ok, i have the shared_ptr change hacked in, and it's pretty huge. Lots of stuff has to change at the same time... it's kinda hard to avoid a giant commit.
14:54 < cfields> BlueMatt: i have no problem doing your refcount change first, then undoing it with this big change next if you'd prefer.
15:07 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:10 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]     
15:15 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
15:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]     
15:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
15:41 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
15:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:42 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
15:44 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
15:50 -!- nemgun [~nemgun@105.101.186.166] has quit [Quit: Leaving]     
16:01 -!- awsom82 [~Igor@broadband-109-173-48-122.moscow.rt.ru] has left #bitcoin-core-dev []     
16:22 -!- jimhash [49a24c6d@gateway/web/freenode/ip.73.162.76.109] has joined #bitcoin-core-dev     
16:23 -!- rabidus [~rabidus@uhiainen.com] has quit [Ping timeout: 240 seconds]     
16:25 -!- rabidus [~rabidus@uhiainen.com] has joined #bitcoin-core-dev     
16:28 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
16:41 -!- jimhash [49a24c6d@gateway/web/freenode/ip.73.162.76.109] has left #bitcoin-core-dev []     
16:42 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 255 seconds]     
16:57 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
17:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:48 -!- praxeology [~praxeolog@unaffiliated/praxeology] has left #bitcoin-core-dev []     
17:48 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
17:56 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
18:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
18:02 -!- tmddzk [~tom@c-73-189-35-88.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
18:04 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
18:08 < BlueMatt> cfields: I mean mine's like 3 LOC long, but, really, I dont care....I have nothing in 15 which is in any way related to that, and only a 16 stretch goal which needs a fix there
18:09 < cfields> BlueMatt: ok. I'm actually finishing it up now
18:09 < cfields> it's really big, but very worth it imo. It'll just be a big one to review
18:09 < BlueMatt> cfields: I'm down for a touch-everything sharedptr change for 16 here
18:09 < BlueMatt> yea, I think its worth it
18:09 < BlueMatt> I mean isnt it mostly mechanical?
18:09 < cfields> nah, there's lots to it :\
18:10 < cfields> well, the shared-ptr part is pretty mechanical
18:10 < BlueMatt> hmm, ok, will reserve judgement for now, but the idea sounds good
18:10 < cfields> but then you still have the refcounting on top
18:10 < BlueMatt> and I'm totally for a big overhaul of that shit for 16
18:10 < cfields> and once you get rid of that, tons of LOCK(cs_vNodes) go away
18:10 < BlueMatt> why bother refcounting on top? just relay on ~CNode and use the shared_ptr refcounting for it?
18:11 < cfields> have to control the thread it deletes from
18:11 < BlueMatt> ah     
18:11 < BlueMatt> ok     
18:11 < cfields> anyway, it's nice and tidy imo. Very straigtforward. Just large.
18:11 < BlueMatt> alright, well will reserve judgement, sounds reasonably in principle, then
18:11 < BlueMatt> yea, large is ok...for 16
18:12 < BlueMatt> gonna sit for 1.5 months first, then, though :/
18:12 < cfields> i don't quite understand that arguement. We have a feature freeze for a reason. That's when stuff bakes. It's not a code freeze.
18:13 < BlueMatt> hmm? I mean i doubt this would land pre-15, and if it doesnt then we're all gonna be focused on getting lots of testing in on 15 and likely wont review/merge all that much before the final gets shipped
18:14 < cfields> sure, if there's no time, that's one thing. But I don't see any need for stuff to bake for a while before feature freeze just to let it bake
18:15 < BlueMatt> ohoh, you mean maybe this will land for 15? I mean id be surprised...lots to clean up and try to land before then that is probably higher prio, but, ok, fair :)
18:15 < BlueMatt> higher prio in the next 3 weeks with folks in the us on vacation for the next week, even :/
18:16 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
18:16 < cfields> well i'd like to do some benches before i push, but i'm thinking that cs_vNodes is blocking a significant percentage of the time
18:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
18:17 < BlueMatt> oh? alright, well may be worth pushing, then...still, two weeks to merge is an incredibly tight schedule
18:17 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Client Quit]     
18:17 < cfields> and i have other stuff that relies on this (I was just putting it off until last). But yea, I agree that it's not really hight priority. If it doesn't make it, it doesn't make it.
18:17 < cfields> *high
18:17 < cfields> I'm mainly just happy that I finally worked out an approach I like. It'll wear off in a few hours :)
18:18 < BlueMatt> pr quickly, then
18:18 < BlueMatt> and dont close it this time when it wears off :p
18:18 < cfields> hehe
18:19 < cfields> ok, back to coding/testing. I haven't actually run the thing yet. Time to see how badly it crashes/burns :)
18:19 < BlueMatt> lol, sg
18:21 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
18:22 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
18:32 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ubltmaldgimjxmco] has quit [Quit: Connection closed for inactivity]     
18:41 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
19:09 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
19:11 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
19:11 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
19:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]     
19:39 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
20:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
20:32 -!- goatpig [5a5c653a@gateway/web/freenode/ip.90.92.101.58] has joined #bitcoin-core-dev     
22:00 -!- Dotglum [~Mutter@2601:641:102:a8e0:7462:ab4d:af97:c610] has joined #bitcoin-core-dev     
22:06 -!- Dotglum [~Mutter@2601:641:102:a8e0:7462:ab4d:af97:c610] has quit [Remote host closed the connection]     
22:08 -!- flerpaderp [~florp@c-76-121-138-167.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
22:11 -!- wolfspra1l [~wolfsprau@bobbin.q-ag.de] has quit [Ping timeout: 260 seconds]     
22:12 -!- florpadorp [~florp@c-76-121-138-167.hsd1.wa.comcast.net] has quit [Ping timeout: 268 seconds]     
22:29 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
22:29 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 268 seconds]     
22:29 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
22:30 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 260 seconds]     
22:31 -!- jnewbery [~john@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
22:31 -!- zxzzt [~prod@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
22:31 -!- morcos [~morcos@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
22:31 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev     
22:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
22:33 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]     
23:48 -!- jouke [~worst@unaffiliated/komkommer] has quit [Remote host closed the connection]     
23:50 -!- jouke [~worst@2001:1c02:1600:9200:d5bc:4fbd:a6ff:7da0] has joined #bitcoin-core-dev     
23:50 -!- jouke [~worst@2001:1c02:1600:9200:d5bc:4fbd:a6ff:7da0] has quit [Changing host]     
23:50 -!- jouke [~worst@unaffiliated/komkommer] has joined #bitcoin-core-dev