--- Day changed Thu Apr 13 2017
00:04 -!- kexkey [~kexkey@68.168.119.228] has quit [Ping timeout: 240 seconds]     
00:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
00:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
00:30 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
00:31 -!- To7 [~theo@cpe-158-222-192-214.nyc.res.rr.com] has quit [Quit: Whatever]     
00:43 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:06 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
01:10 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds]     
01:12 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
01:22 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
01:29 < wumpus> "oh dear god lets not default to running random peoples' commitmsg scripts on wumpus' computer" yes that's not going to happen, I'm already paranoid with github-merge.py itself, I use a version outside the repository and only update it if I carefully reviewed changes inside the repo
01:31 < gmaxwell> lol, please only on pulltester which is already vulnerable as heck.
01:31 < MarcoFalke> The script could be run in a vm. Though, it comes with an overhead...
01:31 < gmaxwell> There are a LOT of vm escape exploits.
01:32 < wumpus> in any case I don't like the idea of adding more functionality to github-merge.py, please just keep it a merge script and not add any other hooks
01:32 < MarcoFalke> Running it on travis is not enough. travis is just an indicator that should not be trusted
01:32 < sipa> i doubt you can trigger any of them from a shell script in a way that it's obvious to cursory review, though
01:32 < gmaxwell> most recent one in QEMU was awful, with the instruction decoder. Esp since previously I'd intentionally avoided kvm to try to lower risk but that made it trivially exploitable.
01:32 < MarcoFalke> Just need to make sure the script is reviewed on every (ut)ACK 
01:33 < gmaxwell> sipa: doubt it enough to put a bounty on it though? :P 
01:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
01:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:50 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/de01da7cad32...c9ff4f8ee601
01:50 < bitcoin-git> bitcoin/master 714e4ad John Newbery: AddToWalletIfInvolvingMe should test pIndex, not posInBlock
01:50 < bitcoin-git> bitcoin/master d0cd0bd John Newbery: Make CWallet::SyncTransactions() interface friendlier
01:50 < bitcoin-git> bitcoin/master c9ff4f8 Wladimir J. van der Laan: Merge #10186: Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number...
01:51 < bitcoin-git> [bitcoin] laanwj closed pull request #10186: Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number (master...remove_SYNC_TRANSACTION_NOT_IN_BLOCK_magic_number) https://github.com/bitcoin/bitcoin/pull/10186
01:57 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
02:00 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
02:26 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
02:26 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
02:37 -!- vFSgrcFGBJHg [~rYUtdcvYT@2a02:2f0a:b0a0:567:4dc7:f812:601c:bac9] has quit [Quit: Leaving]     
02:38 -!- harrymm [~wayne@104.237.91.162] has quit [Ping timeout: 240 seconds]     
02:46 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has quit []     
02:53 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds]     
02:55 -!- harrymm [~wayne@104.237.91.142] has joined #bitcoin-core-dev     
03:07 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/55f641ca194b...06909df179e7
03:07 < bitcoin-git> bitcoin/0.14 b7caa30 Suhas Daftuar: Mention dbcache memory changes in 0.14.1 release notes
03:07 < bitcoin-git> bitcoin/0.14 06909df Wladimir J. van der Laan: Merge #10185: [0.14] Mention dbcache memory changes in release notes...
03:08 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9ff4f8ee601...70f6f56e9dde
03:08 < bitcoin-git> bitcoin/master fd44ac1 NicolasDorier: [Wallet] Rename std::pair<const CWalletTx*, unsigned int> to CInputCoin
03:08 < bitcoin-git> bitcoin/master e78bc45 NicolasDorier: [Wallet] Decouple CInputCoin from CWalletTx
03:08 < bitcoin-git> bitcoin/master f597dcb NicolasDorier: [Wallet] Simplify code using CInputCoin
03:09 < bitcoin-git> [bitcoin] laanwj closed pull request #10165: [Wallet] Refactoring by using CInputCoin instead of std::pair (master...inputcoin) https://github.com/bitcoin/bitcoin/pull/10165
03:10 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
03:20 -!- DarkAngel [~DarkAngel@host-91-192-91-170.elomza.pl] has joined #bitcoin-core-dev     
03:28 -!- DarkAngel [~DarkAngel@host-91-192-91-170.elomza.pl] has quit [Quit: Leaving]     
03:30 < wumpus> gmaxwell: one problem is that x86 is such a complex beast to emulate (or even write a instruction decoder for). If you induce the overhead of full emulation for security reasons, might as wll choose a simpler  platform to emulate
03:31 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
03:32 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
03:37 < wumpus> may also help to restrict what qemu can do through e.g. apparmor, so if a process manages to escape from the vm it isn't immediately able to do much more than the VM could. libvirt does that by default AFAIK
03:43 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
04:34 -!- To7 [~theo@cpe-158-222-192-214.nyc.res.rr.com] has joined #bitcoin-core-dev     
04:53 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
04:54 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev     
04:54 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
05:21 < sdaftuar> gmaxwell: i ran the sim, with 10 seconds / 50000 satoshi fee threshold, roughly 95% of CNB invocations included a recent transaction.
05:29 -!- goksinen [~goksinen@2604:2000:c591:8400:842c:943:f446:8955] has joined #bitcoin-core-dev     
05:33 -!- goksinen [~goksinen@2604:2000:c591:8400:842c:943:f446:8955] has quit [Ping timeout: 260 seconds]     
05:34 -!- Cheeseo [~x@208.167.254.227] has joined #bitcoin-core-dev     
05:34 -!- Cheeseo [~x@208.167.254.227] has quit [Changing host]     
05:34 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
05:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:02 -!- gielbier [~michiel@unaffiliated/gielbier] has quit [Ping timeout: 256 seconds]     
06:06 -!- gielbier [~michiel@unaffiliated/gielbier] has joined #bitcoin-core-dev     
06:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
06:23 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
06:27 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 255 seconds]     
06:38 < sdaftuar> gmaxwell: for comparison, i re-ran my patch with a setting of 10seconds, 0.2% fee drop, and less than 2% of CNB calls included recent transactions
06:45 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
06:45 < bitcoin-git> [bitcoin] mariodian opened pull request #10201: pass Consensus::Params& to ReceivedBlockTransactions() (master...consensusparams-receivedblocktransactions) https://github.com/bitcoin/bitcoin/pull/10201
06:47 < bitcoin-git> [bitcoin] NicolasDorier closed pull request #10068: [Wallet] FundRawTransaction accepts preset non-wallet inputs (master...nonwalletinputs) https://github.com/bitcoin/bitcoin/pull/10068
06:48 < bitcoin-git> [bitcoin] NicolasDorier opened pull request #10202: [Wallet] FundRawTransaction can fund a transaction with preset inputs found in the CoinView (master...fundrawtransaction) https://github.com/bitcoin/bitcoin/pull/10202
06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
06:55 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 260 seconds]     
06:59 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection]     
07:00 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-core-dev     
07:01 < BlueMatt> cfields: hmm, whats the status of #7522?
07:01 < gribble> https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
07:03 < BlueMatt> luke-jr: are you going to rebase #7289?
07:03 < gribble> https://github.com/bitcoin/bitcoin/issues/7289 | [WIP] Make arguments reconfigurable at runtime via RPC by luke-jr · Pull Request #7289 · bitcoin/bitcoin · GitHub
07:06 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
07:08 < bitcoin-git> [bitcoin] laanwj closed pull request #7148: [NO MERGE] Travis: Run nightly test suite (master...travis/nightly) https://github.com/bitcoin/bitcoin/pull/7148
07:12 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
07:15 < wumpus> I agree it's a bit strange but I can't be bothered to change it, it's not as if incidents ever get reported to it
07:15 -!- Samdney [~Samdney@178.162.209.139] has joined #bitcoin-core-dev     
07:15 < wumpus> eh, wrong key
07:16 < BlueMatt> wumpus: you have a key which types whole sentences? wow!
07:16 < BlueMatt> :p     
07:17 -!- dodomojo [~goksinen@2604:2000:c591:8400:81f3:fb80:c834:b228] has joined #bitcoin-core-dev     
07:17 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
07:18 < wumpus> yes this smart-keyboard has analyzed all of the text I've entered on it, put it into a  markov chain, and now generated it's own text with just one keypress :p
07:19 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
07:20 < BlueMatt> wumpus: you jest, but thats what fucking mobile phones do :(
07:21 < jnewbery> and your markov chain predicts that your most common response is "I agree it's a bit strange but I can't be bothered to change it". Seems pretty accurate :)
07:21 < wumpus> ah yes that's always the first thing I disable
07:22 -!- dodomojo [~goksinen@2604:2000:c591:8400:81f3:fb80:c834:b228] has quit [Ping timeout: 260 seconds]     
07:24 < wumpus> jnewbery: yep, the keyboard can almost replace me already :-)
07:27 < michagogo> Yeah, the keyboard auto correct is the best app that I can use on my iPhone and my phone is a very quiet app and the fact is that it doesn't have a plan to use Facebook to access the web for the past couple weeks
07:28 < michagogo> (I typed the first 4 words of that and selected the rest from the 3 suggestions)
07:32 < sipa> wumpus: it's annoying to create PRs against the bitcoin core leveldb repository
07:32 < sipa> because it's marked as 'forked from' the upstream google repo (which didn't exist at the time ours was created)
07:33 < sipa> *isn't marked
07:33 < sipa> seems the only way to fix that is to delete it and recreate it
07:33 < wumpus> that'll lose all the current issues and PRs though
07:33 < sipa> true
07:34 < sipa> maybe we can contact support to just fix it for us?
07:34 < wumpus> yes I think they can reparent repositories
07:36 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70f6f56e9dde...cf8a8b1028d6
07:36 < bitcoin-git> bitcoin/master c851be4 Cory Fields: net: define NodeId as an int64_t...
07:36 < bitcoin-git> bitcoin/master cf8a8b1 Wladimir J. van der Laan: Merge #10176: net: gracefully handle NodeId wrapping...
07:36 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
07:36 < bitcoin-git> [bitcoin] laanwj closed pull request #10176: net: gracefully handle NodeId wrapping (master...nodeid-no-wrap) https://github.com/bitcoin/bitcoin/pull/10176
07:37 < wumpus> are you going to contact support or should I?
07:37 < sipa> i can
07:41 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
07:43 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
07:52 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Ping timeout: 245 seconds]     
08:03 -!- BCBot_ [~BCBot@46.101.246.115] has joined #bitcoin-core-dev     
08:04 -!- Taek42 [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev     
08:04 -!- berndj-blackout [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
08:05 -!- Samdney [~Samdney@178.162.209.139] has quit [Read error: Connection reset by peer]     
08:05 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-aekblbhplougyavc] has quit [Quit: https://fnordserver.eu]     
08:06 -!- harding_ [~harding@mail.dtrt.org] has joined #bitcoin-core-dev     
08:07 -!- cfields_ [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev     
08:07 -!- mariorz_ [sid490@gateway/web/irccloud.com/x-dyuweljyfdppxtml] has joined #bitcoin-core-dev     
08:08 -!- warren_ [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev     
08:08 -!- Pat_Boy [xyz@192.99.249.194] has joined #bitcoin-core-dev     
08:08 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
08:09 -!- ryan-c- [~ryan@znc.rya.nc] has joined #bitcoin-core-dev     
08:09 -!- musalbas- [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev     
08:09 -!- NielsvG` [~Necrathex@2001:981:9573:1:60ce:77ff:fe2a:fdf5] has joined #bitcoin-core-dev     
08:10 -!- Netsplit *.net <-> *.split quits: ensign_, arubi, harding, mariorz, NielsvG, tunafizz, warren, nsh, Taek, murr4y,  (+10 more, use /NETSPLIT to show all of them)
08:10 -!- berndj-blackout is now known as berndj     
08:10 -!- Pat_Boy is now known as PatBoy     
08:10 -!- musalbas- is now known as musalbas     
08:11 -!- Netsplit over, joins: luke-jr
08:11 -!- Netsplit over, joins: tunafizz
08:11 -!- Netsplit over, joins: murr4y
08:12 < sdaftuar> wumpus: i just noticed #9665 has been sitting around for a couple of months, it has a few ACKs and I think could be merged
08:12 < gribble> https://github.com/bitcoin/bitcoin/issues/9665 | Use cached [compact] blocks to respond to getdata messages by TheBlueMatt · Pull Request #9665 · bitcoin/bitcoin · GitHub
08:15 -!- Netsplit over, joins: nsh
08:15 -!- ensign [~ensign@2001:41d0:8:d711::1] has joined #bitcoin-core-dev     
08:16 -!- mariorz_ is now known as mariorz     
08:18 < wumpus> sdaftuar: thanks
08:22 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf8a8b1028d6...eab00d96dfe9
08:22 < bitcoin-git> bitcoin/master efc135f Matt Corallo: Use cached [compact] blocks to respond to getdata messages
08:22 < bitcoin-git> bitcoin/master c47f5b7 Matt Corallo: Cache witness-enabled state with recent-compact-block-cache
08:22 < bitcoin-git> bitcoin/master b49ad44 Matt Corallo: Add comment about cs_most_recent_block coverage
08:23 < bitcoin-git> [bitcoin] laanwj closed pull request #9665: Use cached [compact] blocks to respond to getdata messages (master...2017-02-processgetdata-cache) https://github.com/bitcoin/bitcoin/pull/9665
08:24  * BlueMatt notes something similar for #9942 and #9480
08:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
08:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
08:25 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
08:30 -!- aantonop [~aantonop@50.235.109.194] has joined #bitcoin-core-dev     
08:33 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev     
08:33 -!- arubi [~ese168@unaffiliated/ese168] has joined #bitcoin-core-dev     
08:34 -!- Samdney [~Samdney@178.162.209.132] has joined #bitcoin-core-dev     
08:41 -!- talmai [~T@216.200.123.162] has joined #bitcoin-core-dev     
08:43 -!- goksinen_ [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
08:44 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
08:44 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
08:48 -!- goksinen_ [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
08:50 -!- Netsplit *.net <-> *.split quits: arubi, afk11
08:54 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
08:54 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
08:55 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:00 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
09:08 < sdaftuar> sipa: i was trying to review #9743, and i'm confused by the lockstack cleanup commit.  the boost documentation i'm reading suggests that by default, delete should be called already?
09:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9743 | Fix several potential issues found by sanitizers by sipa · Pull Request #9743 · bitcoin/bitcoin · GitHub
09:10 < sipa> sdaftuar: hmm
09:11 -!- talmai [~T@216.200.123.162] has quit [Read error: Connection reset by peer]     
09:12 < sdaftuar> i'm looking at this: http://www.boost.org/doc/libs/1_63_0/doc/html/thread/thread_local_storage.html
09:12 < sdaftuar> there is this comment: "Note: on some platforms, cleanup of thread-specific data is not performed for threads created with the platform's native API. On those platforms such cleanup is only done for threads that are started with boost::thread unless boost::on_thread_exit() is called manually from that thread.
09:13 < sipa> sdaftuar: but that would mean that the custom cleanup function is also not called?
09:13 < sdaftuar> sipa: that was my guess, but i wasn't sure!
09:14 < sipa> i seem to recall that fixed things
09:14 -!- aantonop [~aantonop@50.235.109.194] has quit [Ping timeout: 260 seconds]     
09:18 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 255 seconds]     
09:28 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
09:28 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
09:29 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
09:29 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 268 seconds]     
09:29 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
09:30 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
09:31 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev     
09:32 -!- Taek42 [~quassel@2001:41d0:1:472e::] has quit [Read error: Connection reset by peer]     
09:32 -!- Naphex [~naphex@naphex.rocks] has quit [Ping timeout: 252 seconds]     
09:32 -!- Naphex [~naphex@naphex.rocks] has joined #bitcoin-core-dev     
09:32 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
09:32 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Excess Flood]     
09:32 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 252 seconds]     
09:32 -!- Olen2 [~Olen@188.226.139.184] has joined #bitcoin-core-dev     
09:33 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #bitcoin-core-dev     
09:33 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
09:36 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Changing host]     
09:36 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
09:37 -!- Olen2 [~Olen@188.226.139.184] has quit [Ping timeout: 260 seconds]     
09:37 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
09:38 -!- aantonop [~aantonop@50.235.109.194] has joined #bitcoin-core-dev     
09:41 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
09:41 -!- Cortney [~Cortney@188.226.139.184] has joined #bitcoin-core-dev     
09:42 -!- belcher [~user@2a02:c7d:b93f:2300:bcca:32b1:acb7:e292] has joined #bitcoin-core-dev     
09:43 -!- belcher is now known as Guest66310     
09:52 -!- Guest66310 [~user@2a02:c7d:b93f:2300:bcca:32b1:acb7:e292] has quit [Quit: Leaving]     
09:52 -!- belcher_ [~user@2a02:c7d:b93f:2300:bcca:32b1:acb7:e292] has joined #bitcoin-core-dev     
09:52 -!- belcher_ is now known as Guest38408     
09:52 -!- Guest38408 [~user@2a02:c7d:b93f:2300:bcca:32b1:acb7:e292] has quit [Client Quit]     
09:54 -!- belcher [~user@2a02:c7d:b93f:2300:bcca:32b1:acb7:e292] has joined #bitcoin-core-dev     
09:54 -!- belcher [~user@2a02:c7d:b93f:2300:bcca:32b1:acb7:e292] has quit [Remote host closed the connection]     
09:57 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:13 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eab00d96dfe9...b7365f0545b1
10:13 < bitcoin-git> bitcoin/master f9c8807 Jeremy Rubin: Deduplicate SignatureCacheHasher...
10:13 < bitcoin-git> bitcoin/master b7365f0 Pieter Wuille: Merge #9480: De-duplicate SignatureCacheHasher...
10:13 < bitcoin-git> [bitcoin] sipa closed pull request #9480: De-duplicate SignatureCacheHasher (master...refactor-signaturecachehasher-visibility) https://github.com/bitcoin/bitcoin/pull/9480
10:14 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-vmxiimbpijzitomx] has quit [Quit: Connection closed for inactivity]     
10:15 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
10:23 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev     
10:24 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
10:33 < cfields_> sipa: for leveldb merge, whenever it's needed: https://github.com/theuni/bitcoin/commit/2cb7dda13884e44105f33c16e7e2c1a9aed46295
10:35 < cfields_> BlueMatt: hmm, i thought 7522 was merged a long time ago. Having a look.
10:40 -!- talmai [~T@216.200.123.162] has joined #bitcoin-core-dev     
10:40 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: jnewbery]     
10:41 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
10:47 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
10:50 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Quit: e4xit]     
10:53 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-xmjbbucaurjwxzep] has joined #bitcoin-core-dev     
10:57 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 245 seconds]     
10:58 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev     
11:01 -!- aantonop [~aantonop@50.235.109.194] has quit [Ping timeout: 252 seconds]     
11:03 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
11:04 -!- aantonop [~aantonop@50.235.109.194] has joined #bitcoin-core-dev     
11:06 < luke-jr> hm, thought I was late; am I early?
11:07 < gmaxwell> you are early
11:07 < luke-jr> cool
11:08 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
11:12 < aantonop> gmaxwell: apologies for the trolling by an "aantonop" imposter the other day. I hadn't turned on Nickserv enforcement. It's on now. 
11:13 < gmaxwell> aantonop: oh no problem, people should have just ignored him. :) trolls show up all the time.
11:15 -!- limpkin [sid20909@gateway/web/irccloud.com/x-mlktsrczigrgkjly] has quit []     
11:16 -!- limpkin [sid20909@gateway/web/irccloud.com/x-odbxkigobgirpscb] has joined #bitcoin-core-dev     
11:19 -!- talmai [~T@216.200.123.162] has quit [Quit: mining]     
11:25 -!- aantonop [~aantonop@50.235.109.194] has quit [Quit: leaving]     
11:30 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has joined #bitcoin-core-dev     
11:31 < spudowiar> Is there a good way to get a transaction input and find the BIP32 derivation path?
11:31 < spudowiar> I don't think the keystore stores BIP32 derivation information
11:33 < luke-jr> pretty sure it does..
11:33 < spudowiar> luke-jr: Well, I was looking in src/keystore.h but it seems I can only get a CKey or CPubKey out which I don't think stores derivation information
11:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zvdtqiaqmvrucvqd] has quit [Quit: Connection closed for inactivity]     
11:37 < sipa> CKeyMetaData or something stores ot
11:37 < sipa> *it     
11:39 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
11:39 < spudowiar> sipa: How do I get one of those from a public key?
11:45 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
12:00 < wumpus> meeting time?
12:00 < jonasschnelli> Yes. Hi all.
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Apr 13 19:00:17 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 < morcos> roger
12:00 < sdaftuar> hello
12:00 < CodeShark> hi     
12:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure blue
12:00 < wumpus> matt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
12:00 < kanzure> hi.     
12:00 < wumpus> hello
12:00 < cfields_> hi     
12:00 < instagibbs> hi     
12:00 < phantomcircuit> hi     
12:00 < wumpus> topics?
12:01 < gmaxwell> Hi!     
12:01 < wumpus> #topic 0.14.1
12:01 < wumpus> anyone had report of bugs with the rc1?
12:01 < cfields_> topic suggestion (after 0.14.1): scripted-diffs
12:01 < gmaxwell> Push the button?
12:01 < gmaxwell> wumpus: you know that the bug reports only come after releasing it. :P
12:01 < petertodd> hi     
12:02 < wumpus> gmaxwell: the serious ones, yes :p
12:02  * cfields_ scrambles to backport 10176
12:02 < wumpus> but apparently no one heard anything, so time to tag -final
12:03 < cfields_> wumpus: wait for ^^ ? doing now.
12:04 < wumpus> would be nice but I think that's not a regression since 0.14.0, so I'm not sure it warrants another rc
12:05 < gmaxwell> can talk about post meeting, certantly nothing but that is in the air.
12:05 < cfields_> ok     
12:05 < wumpus> if you think it's really important to do we can do another rc, no problem
12:06 < gmaxwell> I really don't want to delay 0.14.1 further.
12:06 < cfields_> wumpus: it was more of a since-we're-releasing-anyway kind of thing
12:06 < wumpus> I'd prefer not to either; we should fix the wrapping, but could just was well be included for 0.14.2
12:07 < wumpus> I agree it's something that should be backported to the 0.14 branch
12:07 < morcos> no opinion either way here
12:07 < wumpus> ok     
12:07 < BlueMatt> wumpus: I think we should do it in 0.14
12:08 < BlueMatt> .1     
12:08 < BlueMatt> because its free, we're already doing 0.14.1 and delaying 1 week isnt gonna kill us
12:08 -!- BlueMatt_ [~BlueMatt@178.62.68.75] has joined #bitcoin-core-dev     
12:08 < luke-jr> cfields_: new fixes = new rc required
12:08 < luke-jr> so not worth it in that scenario
12:09 < BlueMatt_> But delaying 1 week isn't too bad
12:09 < BlueMatt> wait, who is BlueMatt_ ?
12:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:10  * wumpus confused
12:10 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
12:10  * BlueMatt_ confused
12:10  * BlueMatt has no idea who BlueMatt_ is
12:10 < instagibbs> :/     
12:10  * BlueMatt_ has no idea who BlueMatt is
12:10 < kanzure> different timeline, carry on.
12:10 < luke-jr> whois says it's Matt Corallo
12:11 < jcorgan> digital ocean ip
12:11 < BlueMatt> not me
12:11  * BlueMatt has no digitalocean-lon vpses
12:11 < gmaxwell> wumpus: shoot the T1000 (BlueMatt_) and lets move on.
12:12 < sipa> BlueMatt_: this statement is false
12:12 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ     
12:12 < spudowiar> gmaxwell: I think that's the fake aantonop IP
12:12 < luke-jr> sipa: :D
12:12 < spudowiar> 2017-04-11 21:37:35 -- Mode #bitcoin [+b *!*@178.62.68.75] by gmaxwell
12:12 -!- mode/#bitcoin-core-dev [+b *!*@178.62.68.7] by wumpus     
12:12 < gmaxwell> We've got lots more to discuss.
12:12 < BlueMatt> yes, lets move on
12:12 -!- BlueMatt_ was kicked from #bitcoin-core-dev by wumpus [Kindergarten is elsewhere!]     
12:13 <@wumpus> so have we decided anything?
12:13 < sipa> 0.14.1 yay
12:13 <@wumpus> #topic scripted-diffs
12:14 < cfields_> yes, let's finish discussing after the meeting
12:14 < cfields_> ok, for reference: #10189
12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni · Pull Request #10189 · bitcoin/bitcoin · GitHub
12:14 < luke-jr> mv meeting/* after-meeting/
12:15 <@wumpus> haven't had a time to look at that one yet
12:15 < cfields_> the idea is for changes that are basically just search/replace, to allow a short script to be placed in the commit message, and verified by Travis
12:15 < cfields_> if they don't transform the old commit to the new one exactly, travis will reject
12:15 < cfields_> the aim is to make those kinds of changes easier to review
12:16 < BlueMatt> is ther emuch to discuss? I think its a good idea
12:16 -!- stoner19 [~stoner19@unaffiliated/stoner19] has joined #bitcoin-core-dev     
12:16 -!- tw2006 [~tw2006@2601:187:8480:2770:c87e:6085:a412:c844] has joined #bitcoin-core-dev     
12:16 < cfields_> example: https://github.com/bitcoin/bitcoin/pull/10189/commits/d04198309e7e9b21de1604cc4321148b37a46347
12:16 < luke-jr> IMO we shouldn't trust Travis
12:16 < gmaxwell> I'm fine with it so long as we don't expect commiters to be running it.  I think someone should write a list of examples, because when I've made mass programatic changes I haven't done it in ways that would look too tidy in a commit message.
12:16 <@wumpus> would that execute arbitrary scripts in commit messages?
12:16 < luke-jr> which is basicaly what you're suggesting)
12:16 < cfields_> BlueMatt: well, you brought up a good point about the safety of random scripts
12:16 <@wumpus> seems kind of dangerous, I certainly wouldn't want to run that locally
12:16 < cfields_> so i thought it might be worth discussing possibly constraining. Say to sed or so.
12:16 < BlueMatt> gmaxwell: there are already two examplesa
12:17 <@wumpus> I'm really careful what scripts I run, and wouldn't want anything to be run automatically
12:17 < BlueMatt> and, yes, agree, jtimon suggested that they only be run if there is a scripted prefix in the commit's title
12:17 < spudowiar> What sort of damage can be done with, say, sed or awk?
12:17 < BlueMatt> to make it much more obvious
12:17 -!- tw2006 [~tw2006@2601:187:8480:2770:c87e:6085:a412:c844] has quit [Read error: Connection reset by peer]     
12:17 < petertodd> wumpus: granted, if you ever compile bitcoin you're running stuff within the repo anyway
12:17 < gmaxwell> spudowiar: arbritary damage.
12:17 < spudowiar> I don't think you can do much with sed, not too sure about awk
12:17 < spudowiar> gmaxwell: I mean dangerous code execution
12:17 < cfields_> wumpus: sure, agreed. Travis can run them, and they can ofc be run manually as well.
12:17 < sipa> try applying sed to /etc/init.d files
12:17 < BlueMatt> see-also #10193
12:17 -!- tw2006 [~tw2006@2601:187:8480:2770:c87e:6085:a412:c844] has joined #bitcoin-core-dev     
12:17 < gribble> https://github.com/bitcoin/bitcoin/issues/10193 | scripted-diff: Remove #include foreach.hpp> by jtimon · Pull Request #10193 · bitcoin bitcoin · GitHub
12:18 < BlueMatt> (which is an example)
12:18 < jcorgan> maybe there should only be a predefined set of opcodes in the script that can run, with a stack...oh wait
12:18 <@wumpus> just make it create a ~/.bashrc, runs next time
12:18 < gmaxwell> in any case, if it's a travis mostly thing I think thats ducky. I would attempt to use it.
12:18 <@wumpus> I'd really prefer not to do this
12:18 < luke-jr> I don't see the value in a Travis-"mostly" thing.
12:18 < spudowiar> What are the benefits?
12:18 < gmaxwell> I guess the reason to just not commit the script is that they're one time things?
12:18 < cfields_> gmaxwell: that was my intention, yes.
12:19 < luke-jr> it gives a false sense of review
12:19 <@wumpus> if there's a script then reviewers can manually verify it too, after reviewing the script
12:19 < BlueMatt> gmaxwell: yes, if they're one-time things its annoying to commit them, also annoying to lose them
12:19 < sipa> when would these scripts be ru
12:19 < sipa> n     
12:20 < cfields_> yes, i got the idea from bac5c9cf643e9333479ac667426d0b70f8f3aa7f
12:20 < luke-jr> I wouldn't mind including the scripts in non-first-line commit msg, and having a dev tool to run them, but IMO better if Travis *doesn't* do it
12:20 < gmaxwell> luke-jr: but reviewers can test it. After reviewing the script. The challenge there is just that you normally don't critically review commit messages in that way. but it's kind of perfect-- in that its one time information about the change.
12:20 < cfields_> https://github.com/bitcoin/bitcoin/commit/bac5c9cf643e9333479ac667426d0b70f8f3aa7f
12:20 < gmaxwell> luke-jr: the purpose of travis doing it is for feedback that you've formated it right and it runs on computers other than yours. Not as a review step.
12:20 < cfields_> if we're going to include a transform in the message like that, I figured we may as well standardize it
12:21 < luke-jr> gmaxwell: as long as reviewers do test it, and don't trust Travis
12:21 <@wumpus> cfields_: the idea of that was to give reviewers a way to verify it, as well as make it easy for myself to repeat the work if it needs rebase
12:21 < spudowiar> You could create format like `*.cpp *.h | s/boost::filesystem/fs/g`
12:22 < sipa> spudowiar: little bobby tables will haunt you
12:23 < luke-jr> lol     
12:23 < petertodd> gmaxwell: note how this is rather like how a merkle sum tree works... the script is a function to transform input to output, and both input and final output are committed via the git commit object
12:23 < cfields_> ok, put a different way, then: if it could be done so that it worked on nothing but a dummy git index, with no access to the filesystem, would that be more acceptable?
12:23 <@wumpus> cfields_: if a transformation of the files could be perfectly sandboxed , I'd be all for it, but I'm kind of afraid of anything that will automatically execute scripts from commit messages, especially as most people review the code changes but not so much the messages :)
12:23 < petertodd> cfields_: I mean, with travis the compilation process can do anything anyway, so I don't see how this is a security risk on top of anything else
12:23 < gmaxwell> I don't know that sandboxing this is worth the effort. If you want to do that, knock yourself out, I guess?
12:23 < petertodd> cfields_: that's true for your local dev setup too
12:24 <@wumpus> I don't think it's worth the effort, no
12:24 < BlueMatt> wumpus: that was my concern, hence why I like jtimon's suggestion of only doing it if, eg, the commit title starts with "AUTO-SCRIPT: "
12:24 < BlueMatt> or something
12:24 < gmaxwell> petertodd: the only concern I have wrt security is that there is a new thing you need to review before running things. Not just the git diff but the commit messages.
12:24 < BlueMatt> then its obvious from the first line of the commit
12:24 < cfields_> petertodd: i agree. The concern here (I guess) is that we'd get a malicious script committed, then someone would run it locally.
12:24 < BlueMatt> and you will see it
12:24 < petertodd> cfields_: but that's already a problem anyway: I can commit a malicious commit that adds rm -rf / to the makefile
12:25 < gmaxwell> cfields_: I dunno about your workflow, but I could be tricked by this, because I'll pull and git diff <where I was before>  which won't show me the commit message(s).
12:25 < gmaxwell> otherwise I'd argue there is no change.
12:25 < cfields_> gmaxwell: but it wouldn't touch anything in that case. You'd have to actively run it.
12:25 <@wumpus> petertodd: you can, but changes to the makefile would be apparent to me at least
12:25 < petertodd> gmaxwell: so long as devs never have git hooks that run this automatically I think we're covered
12:26 < spudowiar> Why not have a script that manually does these checks, prints out each commit message beginning with "AUTO-SCRIPT: " and the commands it would run and asks if you want to run them?
12:26 < petertodd> wumpus: right, but see my reply to gmaxwell above
12:26 < gmaxwell> petertodd: yea, I'm not too concerned.
12:26 <@wumpus> yes, as long as it's not executed automatically outside of travis it's fine
12:26 <@wumpus> I don't care what is done in travis, that is already somebody else's sandbox
12:26 < cfields_> yes, that's the case as-is.
12:26 < petertodd> wumpus: +1
12:26 < gmaxwell> oh actually too spudowiar's suggestion is good  unless run with --force the script could ask for confirmation.
12:26 < cfields_> nothing is touched locally.
12:26 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
12:26 <@wumpus> my point was just that I just don't want e.g. github_merge.py to execute it automatically
12:26 <@wumpus> great
12:27 < petertodd> wumpus: yup, that'd be a bit crazy :)
12:27 < cfields_> wait, please back up, I'm not sure if there's a communication breakdown here.
12:27 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
12:27 -!- Samdney [~Samdney@178.162.209.132] has quit [Quit: Verlassend]     
12:27  * sipa makes backup
12:27 < cfields_> as-is, this is travis-only. Nothing runs automatically anywhere but there.
12:27 <@wumpus> cfields_: as said I haven't seen the actual PR, just rumors from this channel
12:28 < spudowiar> Well, Travis can run it with --force, github_merge.py can run it without --force?
12:28 <@wumpus> yes makes sense to me then cfields_
12:28 < spudowiar> Without --force, no actual commands are run
12:28 < spudowiar> Unless you interactively say so
12:28 < gmaxwell> spudowiar: no need to make merge run it at all. just an extra review step available.
12:28 < cfields_> spudowiar: there's nothing to run "it".
12:28 <@wumpus> no, github_merge.py won't run it at all, that is a merge script and shouldn't do anything else
12:29 <@wumpus> (I run that on the machine that has the gpg key, so I'm paranoid about it)
12:29 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
12:29 < gmaxwell> But I do think it would be nice if when you manually run that review step it shows you what it's going to run.. to avoid my workflow issue example.
12:29 < spudowiar> cfields_: I'm talking about a hypothetical script
12:29 < spudowiar> wumpus: Buy a PGP smartcard :)
12:29 < petertodd> spudowiar: adversary still can cause the PGP smartcard to sign something you didn't aprove
12:29 <@wumpus> ok. seems a communication breakdown here.
12:29 <@wumpus> let's just review the PR, and talk about it again next week
12:30 < gmaxwell> okay
12:30 < cfields_> heh, yes please :)
12:30 < sdaftuar> +1!     
12:30 <@wumpus> #action review #10193
12:30 < gribble> https://github.com/bitcoin/bitcoin/issues/10193 | scripted-diff: Remove #include foreach.hpp> by jtimon · Pull Request #10193 · bitcoin bitcoin · GitHub
12:30 < morcos> good thing our trolling coordination doesn't suffer from these communication problems
12:30 <@wumpus> other topics?
12:31 <@wumpus> #action review #10189 
12:31 < gribble> https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni · Pull Request #10189 · bitcoin/bitcoin · GitHub
12:31 < sdaftuar> topic suggestion: goals for 0.15
12:31 < cfields_> good one.
12:31 < BlueMatt> ok, so ryanofsky wanted to talk about multi-process, too, i think
12:31 < BlueMatt> and, ofc, pr review targets for the week
12:31 < BlueMatt> :)     
12:31 <@wumpus> #topic goals for 0.15
12:32 < BlueMatt> sdaftuar: my interpretation of "goals for 0.15" is "everyone has their own goals, and should mention the PRs they want reviewed to further their goals as review priorities, and we should all help them :)"
12:32 < gmaxwell> Per-txo dbcache and non-atomic flushing please...
12:32 <@wumpus> agree with BlueMatt, though people could state what their goals for 0.15 are
12:33 < jonasschnelli> My goals for 0.15 are: HD auto-restore, Qt feebumper and multiwallet
12:33 < spudowiar> Watch only HD wallets sound good for 0.15 :)
12:33 < gmaxwell> and multiwallet.
12:33 < jonasschnelli> Oh.. yes. That!
12:33 < sdaftuar> gmaxwell: agreed, also i think it would be good to get the new fee estimation in place
12:33 < jonasschnelli> (hd watch only)
12:33 < BlueMatt> multithreaded net_processing (and wallet) with CValidationInterface generating callbacks into it
12:33 < BlueMatt> ie disconnecting validation and everything else with CValidationInterface in betwene :)
12:34 < sipa> when is 0.15 feature freeze?
12:34 <@wumpus> luke-jr: are you planning to update the multiwallet prepare pull according to review comments, or should I take it over?
12:34 < achow101> is replacing accounts with labels planned for 0.15?
12:34 < gmaxwell> sdaftuar: I was going to bring that up. I think that we really need a high level description of the algorithim that we could give to non-developers (e.g. academics) to review.  I don't know if that should hold the improvements but we need to get to that.
12:34 <@wumpus> luke-jr: it's kind of blocking other things right now I think
12:34 < morcos> yes, re: fee estimation.. i understand its a giant pain in the ass to review...  and for little perceived gain.  but i do think its worth it, and merging it sooner rather than later is better in case there are any edge case improvements needed.
12:34 < luke-jr> wumpus: when I get home
12:34 < BlueMatt> I do NOT think its little perceived gain
12:34 < cfields_> my big goals are: finally move to libevent for connman, deterministic toolchain creator (so we can drop our reliance on ubuntu's toolchain)
12:34 <@wumpus> #link Release schedule for 0.15.0 https://github.com/bitcoin/bitcoin/issues/9961
12:35 < sipa> cfields_: woooh!
12:35 -!- dgenr8_ [63084175@gateway/web/freenode/ip.99.8.65.117] has joined #bitcoin-core-dev     
12:35 < BlueMatt> morcos: one of the topics discussed at the wallet dev meetup thing was about how shit fee estimates across the ecosystem are
12:35 <@wumpus> yes libevent please
12:35 < BlueMatt> and bitcoin core is a big part of that
12:35 < morcos> gmaxwell: heh... it's more art than science i think
12:35 < gmaxwell> jonasschnelli: I don't know about HD watch only, we have a lot of overhang in the HD change that isn't done yet. We really need to hammer out all these corner cases before we go adding more major new features in key management.
12:35 <@wumpus> I'd also really like to get the UNIX p2p/rpc stuff in
12:35 < jonasschnelli> gmaxwell: can you explain "a lot"?
12:35 < BlueMatt> morcos: your previous warrants to me about weekend fee estimates in your new design being good represent a huge win for the ecosystem
12:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]     
12:36 < luke-jr> wumpus: (tomorrow)
12:36 <@wumpus> it's all very low-risk and shouldn't affect non-unix-socket use cases
12:36 < sdaftuar> BlueMatt: I also think the ability to return non-conservative (ie, lower) fee estimates is important
12:36 < gmaxwell> jonasschnelli: all the things related to recovery are broken and we even don't know how to fix some of them.
12:36 < morcos> BlueMatt: yes, but exactly the kind of thing that need real world experimentation, b/c they change the real world conditions
12:36 <@wumpus> luke-jr: thanks
12:36 < sipa> i want pertxoutcache, remove memory peak at flushing, better dbcache eviction policy, ...
12:36 < jonasschnelli> gmaxwell: Yes. I'm working on the recover (one of my 0.15 goals: "HD auto-restore")
12:36 < BlueMatt> OKOK, so review priorities towards all these amazing things? whats up this week :)
12:36 < sipa> oh, and segwit activated? pretty please?
12:36 < gmaxwell> morcos: right but there are incentives and security implications in the design, that deserve wider review than we'll get from people who will infer it from the code. Even if the description wasn't completely precise it would help.
12:37 < BlueMatt> sipa: lol
12:37 < cfields_> wumpus: yes. I've looked over that and it kinda clashes with my libevent changes. But it makes sense to get yours in first, then I can adapt mine.
12:37  * BlueMatt registers #10179
12:37 < 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:37 <@wumpus> cfields_: the RPC pull (the first one) shouldn't collide
12:37 < gmaxwell> sipa: would likely help to get 0.14.1 out...
12:37 -!- talmai [~T@216.200.123.162] has joined #bitcoin-core-dev     
12:37 <@wumpus> cfields_: I'm fine with including that one only for now, it's most of the code
12:37 < sipa> gmaxwell: ack
12:37 < cfields_> wumpus: no, the other. But it's a non-issue either way.
12:38 <@wumpus> cfields_: the p2p-over-unix-socket is a very small patch on top of that, Im fine with doing that after libevent which means it can share the code with the RPC path
12:38 < morcos> gmaxwell: yes, writing up the high level design is actually simpler than explaining the actual implementation.  the high level design is pretty simple.. maybe i'll put more effort into the last commit which adds commentary
12:38 <@wumpus> cfields_: though it depends on the time frame I guess
12:38 < gmaxwell> morcos: I think that would be really helpful.
12:38 < cfields_> sounds good.
12:38 < gmaxwell> morcos: Also for general review, I've lost track of the overall design of the estimator.
12:39 < sipa> morcos: i would like to see a 1-page document explaining what it tries to accomplish
12:39 < gmaxwell> morcos: in any case I strongly support improving it, the current one is dumb on weekends.
12:39 < cfields_> sipa: let's activate segwit after the meeting. We only have 20 min left :p
12:39 < gmaxwell> cfields_: ack
12:39 <@wumpus> #action activate segwit
12:39 < morcos> sipa: ok
12:39 < gmaxwell> jinx
12:39 < sipa> (i have no clue how the estimator works, or ever worked, beside "something with buckets")
12:40 < morcos> gmaxwell: yes this is much better on weekends (optionally) 
12:40 < instagibbs> ack on explanation, I was asking really dumb questions about it yesterday, may help
12:40 < gmaxwell> So we should bring up again per-txo and non-atomic flushing.  These changes are straight forward but call for a lot of heroic crash testing.
12:41 < BlueMatt> gmaxwell: I'm waiting for non-atomic to support disconnects
12:41 < BlueMatt> then I'll re-review :)
12:41 < bitcoin-git> [bitcoin] jnewbery opened pull request #10204: [rpc] rename disconnectnode argument (master...rename_disconnect_node_argument) https://github.com/bitcoin/bitcoin/pull/10204
12:42 < sipa> gmaxwell: agree, it needs to support reorgs
12:42 < sipa> also... even harder to test
12:42 < cfields_> high-level question about per-txo: what's the desired/expected outcome when downgrading from 0.15 to 0.14 ?
12:42 < gmaxwell> sipa: hm? with the current code we finish the flush all at once.
12:42 < gmaxwell> needing to support reorgs is only an issue with the changes we discussed post per-txo.
12:43 < MarcoFalke> wumpus: The pull jnewbery just opened could go into 0.14.1 if we do another rc anyway
12:43 < sipa> gmaxwell: a crash in the middle a flush after a disconnect cannot be recovered from with the current code
12:43 <@wumpus> MarcoFalke: yep
12:43 < gmaxwell> cfields_: per-txo cannot be downgraded. reindex. Gotta take the cost at some point.  Non-atomic is downgradable on clean shutdown, reindex otherwise.
12:43 < jnewbery> MarcoFalke has suggested that I split off the non-backwards compatible rpc argument name change from #10143 into its own PR so it can be backported
12:43 < gribble> https://github.com/bitcoin/bitcoin/issues/10143 | [net] Allow disconnectnode RPC to be called with node id by jnewbery · Pull Request #10143 · bitcoin/bitcoin · GitHub
12:43 < gmaxwell> sipa: gotcha.
12:44 < gmaxwell> cfields_: We're going to have to take a non-downgradable change for per-txo at some point, I don't think never doing it is a realistic option, the improvement is too significant.
12:44 <@wumpus> jnewbery: makes sense, it's still fairly safe to rename named arguments now, but they should be backported
12:45 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
12:45 < gmaxwell> cfields_: the overall changes to the dbcache are too burdensom to realisitcally support a version that can support both.
12:45 < sipa> i still wish for non-atomic flush in 0.14.2
12:45 < cfields_> gmaxwell: sure, makes sense. is it worth trying to slip in a bit of smarts into 0.14.1/0.14.2 gracefully saying that (in the event of an attempted downgrade) the format has changed?
12:45  * sipa keeps dreaming
12:46 < gmaxwell> cfields_: yes, that would be more reasonable than getting a generic corruption message.
12:46 <@wumpus> cfields_: yes, something for 0.14.2
12:46 < sipa> cfields_: we could add a change in 0.14 that would make explicit downgrade easy
12:46 < morcos> sipa: too big a change
12:46 -!- gmaxwell_ [~BlueMatt@178.62.68.75] has joined #bitcoin-core-dev     
12:46 <@wumpus> no more new things for 0.14.1 please
12:46 < cfields_> .2, ignore for .1.
12:46 < gmaxwell> "Your database format is from the future, so sad for you. Please run reindex."
12:46 < cfields_> wumpus: sorry, realized my mistake too late :)
12:46 -!- gmaxwell_ is now known as Guest93648     
12:46 < sipa> morcos: i said wish, not demand :)
12:47 -!- Guest93648 [~BlueMatt@178.62.68.75] has left #bitcoin-core-dev []     
12:47 < sdaftuar> sipa: feature freeze for 0.15 is 2017-07-16
12:47 < luke-jr> sh AI sipa in 0.14.2
12:47 < gmaxwell> T1000 is back.
12:47 < sipa> sdaftuar: yeah, i saw, wumpus gave link 
12:47 -!- luke-jr_ [~BlueMatt@178.62.68.75] has joined #bitcoin-core-dev     
12:48 < luke-jr> I wish*
12:48 < gmaxwell>  /mode #bitcoin-dev +b *!*@178.62.68.75
12:48 < luke-jr_> :(     
12:48 < luke-jr_> I can't think of a good nick :(
12:49 <@wumpus> apparently we need to make meetings invite-to-speak only
12:49 <@wumpus> stupid childish trolls are why we can't have nice things
12:49 < kanzure> you used wrong ip address last time
12:49 < spudowiar> wumpus: If you did that, I wouldn't be able to participate :(
12:49 < gmaxwell> wumpus: lets discuss in the meta meeting. :P
12:49 < luke-jr_> spudowiar: Well, no one gives a fuck
12:49 < cfields_> kanzure: no need, they're easy to spot. just ignore.
12:49 < gmaxwell> (after the meeting)
12:50 -!- mode/#bitcoin-core-dev [+b *!*@178.62.68.75] by wumpus     
12:50 -!- luke-jr_ was kicked from #bitcoin-core-dev by wumpus [Kindergarten is elsewhere!]     
12:50 < gmaxwell> in any case, lots of good things in flight. I think progress for 15 is good right now.
12:50 < BlueMatt> ok, so 10 minutes left
12:50 < BlueMatt> ryanofsky: ?
12:50 < BlueMatt> did you want to talk about multi-proces
12:50 < BlueMatt> also please folks list your review-priority for this week :)
12:50 < spudowiar> If that gets merged I will hug ryanofsky :)
12:50 <@wumpus> spudowiar: I don't see why not; would just make it more work to invite everyone
12:51 < ryanofsky> not sure, what there is to say, #10102 is not complete, but the code that's there could use some review
12:51 < gribble> https://github.com/bitcoin/bitcoin/issues/10102 | bitcoin-qt: spawn bitcoind and communicate over pipe (Experimental, WIP) by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
12:51 < spudowiar> wumpus: No one would invite me :(
12:51 < sipa> i'm not sure what the appeal of multi process is
12:51 <@wumpus> #topic multiprocess
12:51 <@wumpus> process isolation
12:52 < sipa> i'd like to see the wallet go into a separate process from the networking
12:52 < jonasschnelli> sipa: #10102
12:52 < gribble> https://github.com/bitcoin/bitcoin/issues/10102 | bitcoin-qt: spawn bitcoind and communicate over pipe (Experimental, WIP) by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
12:52 < BlueMatt> sipa: then review my PRs, those do the first step of splitting it off neatly
12:52 < cfields_> ryanofsky: I've been wanting to split out net into a separate process, but the barrier was creating an IPC. So I'm all for it.
12:52 < BlueMatt> then we can use ryanofsky's multiprocess stuff to do the process :)
12:52 <@wumpus> not having the gui and the rest in one address space would be a good start
12:52 < sipa> that that's qt from the rest
12:52 < sipa> that seems like a pointless gimmick to me
12:53 < jonasschnelli> Yes. The wallet seems to be more important.
12:53 <@wumpus> sigh
12:53 < gmaxwell> If it could disconect and reconnect it would have some value.
12:53 < ryanofsky> agreed the wallet is more important
12:53  * BlueMatt wasnt sure whether folks would like the many-process approach, over two-processes (wallet, and other)
12:53 < jonasschnelli> not saying the Qt part is not important
12:53 < ryanofsky> reason for starting with qt is that wallet work will depend on matt's changes
12:53 < jnewbery> I'd like one process per wallet for multi-wallet
12:53 < spudowiar> Oh, I thought that was wallet as well (my offer of hug has been withdrawn, ryanofsky)
12:53 <@wumpus> the gui has more pressing problems though: too much happens synchronous with the core in the GUI loop
12:54 < jonasschnelli> wumpus: thats a good point
12:54 < ryanofsky> and qt seemed like it might be a less controversial place to start since we already have separate bitcoind and bitcoin-qt executables
12:54 <@wumpus> ryanofsky: yes I agree
12:54 -!- BCBot_ [~BCBot@46.101.246.115] has quit [Remote host closed the connection]     
12:54 < cfields_> i suspect this will probably go down like the scripted-diffs discussion. Maybe we should assign ourselves homework to read the PR fully and discuss next week?
12:54 < jonasschnelli> Architectural wise: splitting of Qt makes more sense.. security: wallet. Splitting of the wallet with something similar to an ssh/gpg-agent shouldn't be very complicated.
12:54 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev     
12:55 <@wumpus> ryanofsky: would make sense to not have them share all that code
12:55 < sipa> hmm, i withdraw my comment about it being pointless
12:55 < gmaxwell> I've read the PR.
12:55 <@wumpus> also having one example of IPC between process could make other splits easier
12:55 < gmaxwell> But this is not a good design.
12:55 < gmaxwell> as such an example.
12:55 < jnewbery> 5 minutes left.
12:55 < jnewbery> Suggested topic: PR review requests
12:56 <@wumpus> gmaxwell: have you commented about the design in the PR?
12:56 <@wumpus> #topic high-priority PR review requests
12:56 < BlueMatt> #10179
12:56 < 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:56 < BlueMatt> for me
12:57 < sipa> #9792 plz
12:57 < gribble> https://github.com/bitcoin/bitcoin/issues/9792 | FastRandomContext improvements and switch to ChaCha20 by sipa · Pull Request #9792 · bitcoin/bitcoin · GitHub
12:57 < morcos> wumpus: #9942 can be merged i think which will at least make the rest of the fee estimation changes smaller to review
12:57 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
12:57 < gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
12:57 -!- stoner19 [~stoner19@unaffiliated/stoner19] has left #bitcoin-core-dev ["Keep on keepin' on..."]     
12:57 < spudowiar> wumpus: For external signing, currently messing about with external command, using stdio but other IPC example would be useful
12:57 < spudowiar> Oops, topic's moved on, sorry
12:57 < gmaxwell> (What this PR does is pulls in a compat library to just break the function boundaries, to work across processes, it is not an actual IPC.  And for just making the GUI more concurrent and perhaps reconnectable that fine.  But that is not how we should seperate the wallet.
12:57 < gmaxwell> )     
12:57 < gmaxwell> wumpus: I can comment more if I haven't.
12:58 < spudowiar> Wallet communicating over the JSON-RPC interface would be quite good, but then you have the issue that wallet functionality is provided over the JSON-RPC interface?
12:58 <@wumpus> morcos: BlueMatt: ok added them to the project  https://github.com/bitcoin/bitcoin/projects/8
12:58 < jnewbery> I'd like some review on #10044. The concept had some ACKs in the meeting a few weeks ago.
12:58 < gribble> https://github.com/bitcoin/bitcoin/issues/10044 | Run functional tests in `make check` by jnewbery · Pull Request #10044 · bitcoin/bitcoin · GitHub
12:58 <@wumpus> also sipa's
12:58 < morcos> wumpus: ok, in 9942 case i think it has enough acks already
12:59 < cfields_> jnewbery: will do.
12:59 <@wumpus> jnewbery: also added
12:59 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
12:59 < luke-jr> spudowiar: JSON-RPC already provides wallet..
13:00 < BlueMatt> DONG
13:00 <@wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Apr 13 20:00:04 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-13-19.00.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-13-19.00.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-13-19.00.log.html
13:00 < BlueMatt> gmaxwell: so is your objection that qt and other things dont need separated, or that this isnt the right approach?
13:00 < spudowiar> luke-jr: That's the point I was making. If you have the wallet talking to the daemon over JSON-RPC, how can you provide the wallet functionality over JSON-RPC?
13:00 < spudowiar> luke-jr: I'm just really bad at wording stuff :)
13:00 < jnewbery> cfields_ wumpus thanks
13:00 < spudowiar> petertodd: That's why we need OpenPGP Card 4.0 :)
13:00 -!- harrymm [~wayne@104.237.91.142] has quit [Remote host closed the connection]     
13:00 < spudowiar> petertodd: So that the smart card can request bits of the data, etc. and display it on the display
13:00 < petertodd> spudowiar: it'll have to have a display at least... fudnemental probelm
13:00 < spudowiar> petertodd: TREZOR
13:01 < spudowiar> petertodd: I have a working OpenPGP implementation for TREZOR
13:01 < spudowiar> Only does ECDSA signing though
13:01 < spudowiar> Rewriting it in Rust though
13:01 < petertodd> spudowiar: heh, git support for trezor...
13:01 < spudowiar> petertodd: I signed a Git commit with it :)
13:01 < petertodd> spudowiar: oh, theres a rust impl for the trezor uc?
13:02 < gmaxwell> BlueMatt: QT being seperated can improve concurrency and ... if done right allow it to turn off and on, while the daemon keeps running. Which I think are moderately useful things.   And the way that it is done here is more or less okay for just accomplishing that.  But it not a way that we should seperate the wallet, it is HIGHLY trusting, it wouldn't support multiple concurrent users, it doesn'
13:02 < spudowiar> petertodd: Rust runs on pretty much anything (there's an LLVM backend for STM32*)
13:02 < gmaxwell> t provide for a stable interface. etc.
13:02 < petertodd> spudowiar: nice!
13:02 < luke-jr> bbl     
13:02 < gmaxwell> wumpus: metametting we should +v all the regulars and then if there is noise we can set the channel +m and +v the few extra non-regulars that aren't causing trouble.
13:02 < petertodd> spudowiar: I've got a big project I'm doing in rust right now
13:02 < spudowiar> !m petertodd 
13:02 < [b__b]> You're doing good work, petertodd!
13:02 < gribble> Error: "m" is not a valid command.
13:02 < spudowiar> Go away gribble 
13:03 < petertodd> heh     
13:03 < spudowiar> petertodd: https://pgp.mit.edu/pks/lookup?op=vindex&search=0xEDD78A88C5D03B56 is the key generated by my TREZOR
13:03 < luke-jr> (not sure if anyone's fixed 0.14.1 relnotes confusing ppl re miner signalling.. but it should probably get fixed befoe firal)
13:03 < petertodd> spudowiar: nice!
13:04 < spudowiar> https://github.com/trezor/trezor-mcu/pull/133 is the firmware code (written in C)
13:04 -!- dgenr8_ [63084175@gateway/web/freenode/ip.99.8.65.117] has quit [Quit: Page closed]     
13:04 < jonasschnelli> spudowiar: Yeah. Nice stuff... 
13:04 < spudowiar> Only thing stopping me from getting this all finished is school :(
13:05 < jonasschnelli> skip school
13:05 < spudowiar> lol     
13:05 < spudowiar> Wait...
13:05 < spudowiar> I actually have a video of this :)
13:05 < jcorgan> of you skipping school?
13:05 < petertodd> spudowiar: I dropped out of a physics degree for bitcoin (though I was doing it part time while working at a startup...)
13:05 <@wumpus> gmaxwell: yes, seems a good idea
13:06 < cfields_> petertodd: you had that lucrative art degree as a fallback, though :p
13:06 < petertodd> cfields_: lol
13:07 -!- harrymm [~wayne@104.237.91.107] has joined #bitcoin-core-dev     
13:07 < spudowiar> https://twitter.com/spudowiar/status/784429631545958400
13:07 < spudowiar> NO, THAT IS THE WRONG VIDEO
13:07 < spudowiar> https://twitter.com/spudowiar/status/802960101992759296
13:07 < spudowiar> Sorry
13:08 < jcorgan> petertodd: worst case you can always rely on bridgette's money
13:08 < spudowiar> Someone asked me if it worked on Windows so I recorded that for them :)
13:09 < petertodd> jcorgan: heh
13:09 < spudowiar> Wait... petertodd liked that video? When...?
13:09 < spudowiar> Oh wait, late Twitter notifications
13:09 < petertodd> spudowiar: just now :)
13:11 < spudowiar> petertodd: The firmware in the Pong video was written in Rust
13:12 < petertodd> spudowiar: nice! I'm rather excited for rust on embedded; I used to do a bunch of asm and C uC stuff, and it always kinda sucked
13:13 -!- g0d355__ [~lmao@104.131.75.159] has joined #bitcoin-core-dev     
13:17 < BlueMatt> re: splitting qt process: can we use our own serialization instead of capnproto, ryanofsky?
13:18 < ryanofsky> BlueMatt: yes we can, i'm working on splitting up the change into two prs, one adding ipc interface and another adding capnproto glue to show how separation works
13:18 <@wumpus> the gui has more pressing problems though: too much happens synchronous with the core in the GUI loop <- in any case, this needs to be addressed first, or as part of the move to a seprate process
13:19 <@wumpus> the GUI thread should never block on a IPC request
13:20 <@wumpus> (currently it blocks on calls to core, or while taking the cs_main lock, resulting in lack of user response for significant time)
13:21 < spudowiar> sipa: If I'm parsing a scriptPubKey using Solver, I get a CPubKey. How to get to a CKeyMetadata from there? (to get hdMasterKeyID)
13:21 < gmaxwell> wumpus: Can you explain shimming in the IPC address those blocks?-- if none of the dataflow is changed.
13:22 < ryanofsky> i'm not changing gui locking / blocking in my pr. if there are cases where gui is freezing up, the only way to address those is individually
13:22 <@wumpus> gmaxwell: shimming? 
13:23 < ryanofsky> the only impact my will have on gui responsiveness is there are a lot of ipc calls being called in a tight loop where they might be noticablely slower than current function calls
13:23 <@wumpus> ryanofsky: that's kind of my problem with it; it may compound thecurrent issues
13:23 < ryanofsky> or ipc calls that have to serialize / deserialize a large amount of data
13:23 < gmaxwell> my read on ryanofsky's patch is that it just inserts IPC dispatch at these communication points. The software would still block no less as a result.  By shimming I mean replacing  function() with  ipc->function->ipc. 
13:23 <@wumpus> gmaxwell: that's why I say that should be addressed first
13:23 < ryanofsky> wumpus, yes, we will have to see what performance will be
13:24 <@wumpus> gmaxwell: one everything the GUI does is asynchronous, making it work over IPC is also a lot easier
13:24 < ryanofsky> but i do think any performance problems that are uncovered can be dealt with
13:24 <@wumpus> gmaxwell: that was my original plan for the GUI but I never had time to finish it :(
13:24 < gmaxwell> wumpus: ah!
13:24 < ryanofsky> it seems to me a lot easier to fix performance problems that come up than "make everything asyncrhonous"
13:25 <@wumpus> easier, but not better
13:25 < gmaxwell> (I was thinking you thought the ipc changes did this already and thought I was confused).
13:25 <@wumpus> no, ideally IPC chnanges would do that
13:25 <@wumpus> but these don't, no
13:25 < gmaxwell> ryanofsky: is it your thought that eventually the GUI could be started and stopped independantly of the backend?
13:26 <@wumpus> making everything asynchronous would improve the user experience a lot
13:26 <@wumpus> as well as avoid silly things like the gui not coming up because it's blocked on one value that it needs to get under a cs_main
13:26 < ryanofsky> gmaxwell, supporting that would be pretty easy, but i don't know what the use-cases would be
13:27 <@wumpus> ryanofsky: the typical windows service idea: have a GUI to manage it, that runs only part of the time
13:27 < gmaxwell> If not then I really do not understand the purpose of IPC seperating it at all. Making it (largely)-async is an independant issue.  The kind of approach here is tightly coupled, so it couldn't really support a GUI in a seperate codebase, multiple GUI projects, or concurrent multiple GUIs. 
13:27 < gmaxwell> The advantage of being able to start and stop is so the GUI doesn't run when it's not needed.
13:27 < spudowiar> Oh, wait, I can call CWallet::LoadKeyMetadata!
13:27 <@wumpus> well the cap'n'proto thing could theoretically work with a separate process
13:27 <@wumpus> codebase*
13:28 <@wumpus> they only have to share the interface definition
13:28 < ryanofsky> gmaxwell, i think the approach can support all of those things. but my initial plan for the pr is just to change the infrastructure without exposing new features
13:28 < gmaxwell> wumpus: yes but without a designed and clean interface you can't reasonably support that.
13:28 <@wumpus> gmaxwell: maybe not in the first version
13:28 < gmaxwell> And you get the ZMQ like "everything has to run exactly the same version of ZMQ" issue.
13:28 <@wumpus> gmaxwell: but I think you want too much at the same time
13:29 < ryanofsky> gmaxwell, my pr defines an interface
13:29 < gmaxwell> ISTM if the goal is those things, what is needed is a RPC.  This just seems like a 170 degree turn from existing plans on seperating the wallet as a SPV client with special messages for mempool and whatnot.
13:29 <@wumpus> baby steps sometimes make sense so that there is at least progress, the interface he defines may not be super clean yet but it's at least a start
13:30 < gmaxwell> and replacing it with something that we'll never be able to precisely define or secure.
13:30 <@wumpus> anyhow I don't think we'll ever make progress here this way, we just all want too different things
13:30 < sipa> spudowiar: no
13:30 < ryanofsky> how is the interface not precisely designed & secure?
13:30 < ryanofsky> i mean defined not designed
13:30 < sipa> spudowiar: that method is for loading metadata into the wallet
13:31 < spudowiar> sipa: Yeah, I just saw that
13:31 < gmaxwell> ryanofsky: where is a wire specification for captin proto that can be independantly implemented?
13:32 < ryanofsky> oh this is just an objection to capnproto?
13:32 <@wumpus> ryanofsky: even then, you're not currently opening it up, this first experimental version in the PR is internal only
13:32 < ryanofsky> if capnproto is a real problem, a different protocol could be dropped in instead
13:33 < gmaxwell> ryanofsky: yea, a lot of my concern is the approach of taking an internal boundary and then wrapping it in captinproto (which I have specific concerns about which might be outdated).
13:33 <@wumpus> once you have a better idea of what you need you can improve the protocol, then eventually open it up to other applications maybe
13:33 < ryanofsky> most of the work i'm doing here is in making qt not call wallet/node functions directly
13:33 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has quit [Quit: WeeChat 1.7]     
13:33 < ryanofsky> if you have suggestions for another wire format to use instead of capnproto, that'd be helpful
13:33 < gmaxwell> ryanofsky: that stuff all sounds great to me independant of the rest.
13:34 <@wumpus> what I like about cap'n'proto is that the interface is cleanly defined in the .capnp file, other software could in principle use that interface definition and just communicate with it
13:34 < ryanofsky> there is a lot i like about capnproto, but so far it actually requires a lot more boilerplate than i was expected, and i'm not at all wedded to it
13:34 <@wumpus> e.g. https://github.com/bitcoin/bitcoin/pull/10102/files#diff-1832023b80d9337ec49f60646c7a9c5dR1
13:35 < gmaxwell> wumpus: yes so long as they also take all of captin proto, of the same vintage. 
13:35 <@wumpus> gmaxwell: yes, they have to use the same IPC library
13:36 <@wumpus> gmaxwell: you'd want an independent implementation of the protocol?
13:36 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
13:37 <@wumpus> I vaguely remember the wire format for capnp is documented, but can't find it quickly
13:37 < gmaxwell> that comes back to IPC vs RPC.  I believe the wallet seperation should be a RPC.  I don't really have any opinion in GUI IPC seperation, beyond being able to independantly start and stop it, I don't see the value-- but I acknoweldge and respect that people who know more about the GUI parts may see value in it that I don't.
13:37 < sipa> well it would be nice to just have bitcoind running, and occasionally connect your qt frontend to it
13:37 <@wumpus> https://capnproto.org/encoding.html
13:37 < gmaxwell> If it truly just is an IPC then I don't care much about requring the same versions or an interface that wasn't really designed and documented and supported as a public interface.
13:38 < gmaxwell> sipa: agreed.
13:38 < ryanofsky> i don't really see a significant difference between ipc / rpc here. either way you have bytes going across a socket. the only difference is whether you bind the socket to a port or not
13:38 < sipa> ryanofsky: i think what gmaxwell means is whether it's a well defined interface
13:38 < sipa> will the gui and server always be the same version
13:39 < sipa> or do they need to interact across different versions
13:39 <@wumpus> at first: no
13:39 < ryanofsky> sipa, that's up to us
13:39 < gmaxwell> Well defined and stable, right.
13:39 < sipa> ryanofsky: and i think gmaxwell means that for the Qt split, no well defined and stable interface is needed
13:39 <@wumpus> there's no reason that couldn't be added, but it doesn't seem required for doing this in the first place
13:39 < sipa> but for the wallet separation there is
13:40 < gmaxwell> Also how much do you trust the code you're talking to.  With captin proto, if the far end does something unexpected (much less malicious) access to the objects long after the IPC completes will throw exceptions.
13:40 < ryanofsky> capnproto supports extending interfaces in backwards compatible ways, that's the reason for all the field numbers & interface method numbers in the schema file
13:40 <@wumpus> ryanofsky: indeed, they have thought of this
13:41 < gmaxwell> And thats fine for gui/rest since it's all one codebase, from one group.. and of course function calls also do crazy things if you get anything wrong.
13:41 <@wumpus> but yes secure IPC for sandboxed code is difficult, and maybe cap'\n'proto is not the best suited for that
13:41 < gmaxwell> But that isn't what we want for wallet seperation.
13:41 < sipa> i think for wallet separation we should just use p2p
13:42 < sipa> and have the wallet side implement spv
13:42 < gmaxwell> That is what we've always planned, and I think it is good and as a side effect mostly written already.
13:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
13:42 < sipa> and designed for
13:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
13:44 <@wumpus> looked at chromium: for IPC they use a serialization system (like ours) called pickle, and serialize/deserialize using that in the IPC entry points where needed, no interface compiler
13:44 < gmaxwell> thats totally not confusing with python. :P
13:45 < BlueMatt> wumpus: i think you can remove the merged PRs from https://github.com/bitcoin/bitcoin/projects/8
13:45 < BlueMatt> luke-jr: where are you on #8694? looks like you have a bunch of comments to fix?
13:45 < gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
13:46 < ryanofsky> wumpus, chromium is in the middle of transitioning between ipc systems
13:46 <@wumpus> communication (on unix) is done over a SOCK_DGRAM or SOCK_SEQPACKET socketpair, they support some advanced things like sending over file descriptors
13:46 <@wumpus> ryanofsky: oh? 
13:46 < ryanofsky> older one is based on c macros, newer one is a stripped down fork of https://github.com/domokit/mojo
13:48 < ryanofsky> mojo is similar to capnproto, but supports passing file descriptors & shared memory over the socket, not just sending bytes
13:48 <@wumpus> didn't know about mojo
13:49 < ryanofsky> this page describes the older chromium ipc mechanism: https://www.chromium.org/developers/design-documents/inter-process-communication
13:49 < ryanofsky> yeah i actually looked into using mojo before capnproto
13:50 < ryanofsky> but the mojo project itself is actually dead
13:50 < ryanofsky> there are now two forks of mojo, one is internal to chromium, and the other is internal to google's fuschia os project
13:51 <@wumpus> so they don't use the project itself, just copied some files to their project?
13:51 < ryanofsky> copied & stripped out parts they didn't need
13:51 < ryanofsky> https://chromium.googlesource.com/chromium/src/+/master/mojo
13:57 <@wumpus> yes that seems quite close to cap'n'proto
13:57 -!- tw2006 [~tw2006@2601:187:8480:2770:c87e:6085:a412:c844] has quit [Remote host closed the connection]     
14:10 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-slgpojwlvtbwjbmc] has joined #bitcoin-core-dev     
14:19 < bitcoin-git> [bitcoin] theuni opened pull request #10205: net: define NodeId as an int64_t (0.14...10176-backport) https://github.com/bitcoin/bitcoin/pull/10205
14:24 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
14:37 -!- talmai [~T@216.200.123.162] has quit [Ping timeout: 255 seconds]     
14:42 < bitcoin-git> [bitcoin] dramaticbulgarian opened pull request #10206: Chainparams: In ReceivedBlockTransactions() (master...chainparams) https://github.com/bitcoin/bitcoin/pull/10206
14:52 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
14:55 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
15:00 -!- jcorgan is now known as jcorgan_     
15:01 -!- jcorgan_ is now known as jcorgan     
15:04 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
15:06 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
15:06 -!- LeMiner2 is now known as LeMiner     
15:06 -!- fao [~fao@106.120.101.38] has quit [Ping timeout: 260 seconds]     
15:07 -!- fao [~fao@106.120.101.38] has joined #bitcoin-core-dev     
15:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
15:13 -!- TheV01D [thev01d@btc.mining.ga] has joined #bitcoin-core-dev     
15:14 < TheV01D> lo     
15:35 -!- fao [~fao@106.120.101.38] has quit [Ping timeout: 258 seconds]     
15:36 -!- fao [~fao@106.120.101.38] has joined #bitcoin-core-dev     
15:36 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
15:39 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds]     
15:39 -!- LeMiner2 is now known as LeMiner     
15:39 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 255 seconds]     
15:41 -!- ryan-c- is now known as ryan-c     
15:46 -!- tw2006 [~tw2006@2601:187:8480:2770:e87b:d1a6:354:15ad] has joined #bitcoin-core-dev     
15:51 -!- tw2006 [~tw2006@2601:187:8480:2770:e87b:d1a6:354:15ad] has quit [Ping timeout: 258 seconds]     
15:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
15:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
16:17 < bitcoin-git> [bitcoin] dramaticbulgarian closed pull request #10206: Chainparams: In ReceivedBlockTransactions() (master...chainparams) https://github.com/bitcoin/bitcoin/pull/10206
16:20 -!- goksinen [~goksinen@2604:2000:c591:8400:fc05:6911:6cce:de75] has joined #bitcoin-core-dev     
16:24 -!- goksinen [~goksinen@2604:2000:c591:8400:fc05:6911:6cce:de75] has quit [Ping timeout: 258 seconds]     
16:25 -!- goksinen [~goksinen@2604:2000:c591:8400:30b7:d21b:3bfb:9c58] has joined #bitcoin-core-dev     
16:31 -!- goksinen [~goksinen@2604:2000:c591:8400:30b7:d21b:3bfb:9c58] has quit [Remote host closed the connection]     
16:32 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
16:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]     
16:41 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
16:42 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
16:54 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-xmjbbucaurjwxzep] has quit [Quit: Connection closed for inactivity]     
17:00 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
17:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
17:22 -!- tw2006 [~tw2006@2601:187:8480:2770:88f8:b70e:8fb8:35ec] has joined #bitcoin-core-dev     
17:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
17:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
17:42 < gmaxwell> Anyone have AMD Ryzen yet? apparently they implement the intel SHA extensions.
17:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-slgpojwlvtbwjbmc] has quit [Quit: Connection closed for inactivity]     
18:22 -!- tw2006 [~tw2006@2601:187:8480:2770:88f8:b70e:8fb8:35ec] has quit [Remote host closed the connection]     
18:24 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
18:47 -!- array [dsa@array.pm] has joined #bitcoin-core-dev     
18:48 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
18:58 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
19:00 -!- dermoth [~thomas@dsl-66-36-132-82.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
19:00 -!- dermoth [~thomas@dsl-66-36-132-82.mtl.aei.ca] has joined #bitcoin-core-dev     
19:08 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
19:21 -!- cfields_ is now known as cfields     
19:23 -!- tw2006 [~tw2006@2601:187:8480:2770:39d7:3779:b6bf:9ef5] has joined #bitcoin-core-dev     
19:23 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
19:24 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
19:25 -!- dodomojo [~goksinen@2604:2000:c591:8400:50f4:f30c:189b:d8b5] has joined #bitcoin-core-dev     
19:28 -!- tw2006 [~tw2006@2601:187:8480:2770:39d7:3779:b6bf:9ef5] has quit [Ping timeout: 258 seconds]     
19:30 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
19:37 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-core-dev     
19:43 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection]     
19:44 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
19:44 -!- juscamarena is now known as Guest28992     
19:45 -!- warren_ is now known as warren     
19:45 < warren> Yikes ... rescan is very slow.
19:51 -!- fauve [6b8556f9@gateway/web/freenode/ip.107.133.86.249] has joined #bitcoin-core-dev     
19:56 -!- Guest28992 is now known as juscamarean     
19:56 -!- juscamarean [~justin@47.148.176.74] has quit [Quit: Leaving]     
20:12 -!- fauve [6b8556f9@gateway/web/freenode/ip.107.133.86.249] has quit [Quit: Page closed]     
20:16 < bitcoin-git> [bitcoin] wtogami opened pull request #10207: Clarify importprivkey help text ... example of blank label without rescan (master...importprivkey) https://github.com/bitcoin/bitcoin/pull/10207
20:21 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 252 seconds]     
20:25 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer]     
20:25 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
20:26 < kallewoof> I think the PR review request part of the weekly meetings is a bad idea. It risks alienating the contributors who aren't hard core enough to participate and/or who aren't in a compatible time zone. I also don't think I would ever ask for a review for anything as I wouldn't consider my PRs important enough to take anyone's time at a specific time.
20:28 < kallewoof> At the same time it's a bit frustrating watching PRs just gather dust for no (to oneself) apparent reason. Maybe that's just me.
20:30 < kallewoof> Meetings start 4 in the morning where I am, FWIW.
20:36 < warren> kallewoof: you make a good point, although I don't have a good suggestion.  Asking for reviews during the meeting is not decision making.  It is merely humans asking other humans to take a look at something.  Perhaps folks here could volunteer to talk with you and others at other hours to better communication and coordination in other schedules.
20:38 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ocjbputfyhlhvvnp] has joined #bitcoin-core-dev     
20:38 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
20:41 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]     
20:41 < kallewoof> I am a bit surprised that there's no better method to keep the ball rolling so to say. After the initial comment spree (if any) it sort of just sits there. If you're like me, who hates bugging people for no particular reason, that can be a long time. E.g. #9517 is over 3 months old and I don't even know if people want it merged.
20:41 < gribble> https://github.com/bitcoin/bitcoin/issues/9517 | [refactor] Switched httpserver.cpp to use RAII wrapped libevents. by kallewoof · Pull Request #9517 · bitcoin/bitcoin · GitHub
20:41 < kallewoof> And it's a very simple PR. +8 lines -16 lines.
20:42 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
20:50 -!- str4d [~str4d@27.110.123.91] has quit [Ping timeout: 240 seconds]     
20:57 < gmaxwell> kallewoof: sometimes they get forgotten and you need to nag. It's suboptimal but there is often more in flight than we can really manage. squeaky wheel and all that.
21:00 < gmaxwell> kallewoof: in any case, sorry about that I will test now.
21:01 < gmaxwell> Recommended procedure is: (1) wait until we're not closing for a major release (e.g. now is fine), (2) nag.  (3) apologize for nagging by cross responding to other people's nags: end result everyone happy.
21:03 < kallewoof> gmaxwell: Yeah, I can sort of grasp that this is the approach, but for a newcomer I think it's very intimidating. (Not necessarily speaking about myself there, though i do hate nagging.) It'd be a pity for a bright individual to lose their steam and go somewhere else because they are too scared to bug you guys. That's more of an issue here since everyone here is a damn genius.
21:03 < kallewoof> Friendly geniuses, but that's not necessarily obvious to someone who hasn't spent a great deal of time watching you interact.
21:05 < kallewoof> My approach so far has been to jump to e.g. page 5-6 in the PR list and just go from bottom and upwards. But I am not exactly the most qualified to review a lot of the stuff there. :)
21:07 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
21:07 < gmaxwell> kallewoof: people do go and advocate for other PRs, which does rescue this case in some cases. But it happens at a much greater rate when they've taken some personal interest in the result; and so good cleanup work like the RAII wrapper takes a backseat because as good as it may be, it isn't sexy.
21:07 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev     
21:08 < gmaxwell> It's certantly something we need to improve-- and you can help improve it by also advocating for other people. I dunno about you but I find it less intimidating to ask for other people than for myself.
21:09 < kallewoof> That makes a lot of sense, yeah.
21:11 < kallewoof> TBH I think part of the problem is that you aren't sure if what you are suggesting is desired or not. Getting a concept ACK from someone goes a long way and makes the wait less of an issue, at least in my book.
21:11 < kallewoof> Or a concept NACK for that matter. 
21:12 < gmaxwell> kallewoof: ah, well in this case you got suggestions from wumpus that weren't a "don't do this", which was not a Concept NACK.
21:12 -!- tw2006 [~tw2006@2601:187:8480:2770:d870:ebc2:5ff5:cff9] has joined #bitcoin-core-dev     
21:12 < gmaxwell> Part of it is familarity with the codebase-- I would expect wumpus to be the person most opinionated with this code. (I believe he wrote all of it.)
21:13 < gmaxwell> well almost all of it.
21:13 < gmaxwell> if you don't already know its handy to run a git blame / git log on whatever your change and get an idea of who has been working on that part most recently, since they're most likely to have the most useful review and strongest opinions.
21:14 < kallewoof> *nods* this is true, but even a code suggestion can be less than a concept ACK. "Merge desire opinions aside, you can improve this code by doing XYZ". That's how I interpret it usually. I wouldn't be surprised to get a concept NACK later.
21:14 < kallewoof> Oh... I never thought of that, actually.
21:14 < kallewoof> That might make it easier to nag as it's sort of a suggestion on top of their work..
21:15 < gmaxwell> oh, I would not expect a person to suggest changes and then concept NACK for a simple patch. For a complex patch where the implications are unclear, perhaps.
21:15 < kallewoof> *nods*
21:15 < gmaxwell> Generally if people mildly dislike a change you'll get a thundering silence, not exactly useful feedback to you-- but often people would prefer to bite their tongue in case someone else likes it.
21:17 -!- tw2006 [~tw2006@2601:187:8480:2770:d870:ebc2:5ff5:cff9] has quit [Ping timeout: 258 seconds]     
21:17 < gmaxwell> Suggestions are an investment of resources into your change, in some sense they're better than an ACK in that an ACK can be a drive by review, while if someone makes suggesitons they've basically put themselves on the hook to explain the suggestions to you and collaborate. :)
21:18 < kallewoof> Right. I've learned a tremendous amount since becoming a contributor. I wish I'd joined an OSS project much earlier. In that sense even a NACK can be appreciated and feel rewarding.
21:20 < gmaxwell> I think the most important thing to learn is that-- at least once you're beyond a basic level of skill-- your real contribution is the attempt, it doesn't matter if the result ends up in the finished version or stays there, but we're all pushing towards an improved piece of software, and if we keep pushing we'll be successful, even though-- in fact, especially because-- not every change makes it
21:20 < gmaxwell>  in.
21:21 < gmaxwell> now, ... trying to test your patch and I'm bombing out with a perplexing multiple definition error that looks like you missed an include guard. But it has an include guard. 
21:22 < kallewoof> I agree that that's exactly the right approach to take, and you've given me feedback that I think will help me advocate my own stuff or stuff I feel about by others. Maybe I'll make a PR to the contribution doc summarizing what you said, cause some of it was NOT obvious, at least not to me.
21:22 < kallewoof> Weird. Testing.
21:22 < gmaxwell> test/test_test_bitcoin-raii_event_tests.o:/home/gmaxwell/src/bitcoin/src/./support/events.h:30: first defined here
21:22 < gmaxwell> libbitcoin_server.a(libbitcoin_server_a-httpserver.o): In function `obtain_event(event_base*, int, short, void (*)(int, short, void*), void*)':
21:22 < gmaxwell> /home/gmaxwell/src/bitcoin/src/support/events.h:37: multiple definition of `obtain_event(event_base*, int, short, void (*)(int, short, void*), void*)'
21:23 < gmaxwell> oh     
21:23 < gmaxwell> the test. missed that it was the test.
21:32 < kallewoof> Weird. I'm not getting that compile error (on lubuntu).
21:33 < gmaxwell> kallewoof: in any case, I went and made all the function definitions in that header static inline, it's fine then. AFAICT the duplicate symbol is real.
21:34 < gmaxwell> May just be that your linker is handling it differently.
21:34 < kallewoof> Yeah they should be static and/or inline for sure.
21:34 < gmaxwell> or moved out of the header.
21:35 < gmaxwell> (I tend to have relatively few optinions about these things, because I am not much of a C++ coder; and don't really have a sense of taste for such things beyond preferring almost everything to look like C, which is usually the wrong answer. :) )
21:36  * kallewoof laughs
21:38 < gmaxwell> in any case seems to work for me, I'll ACK when you've updated to do something about the duplicate function definitions.
21:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
21:40 < kallewoof> Thanks a lot :) I just pushed a commit that adds inline.
21:44 < cfields> kallewoof: you on osx?
21:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
21:45 < gmaxwell> kallewoof: obtain_event_base too. 
21:45 < kallewoof> cfields: Yep. I do have a linux box too though.
21:45 < kallewoof> gmaxwell: Yeah, sorry. I force-pushed a squash fix of that one. Was hoping you wouldn't grab before I did. 
21:46 < cfields> kallewoof: the osx linker is very forgiving. too much so, imo.
21:46 < NicolasDorier> kallewoof: Yeah, the solution to our time zone problem is called the ACK Begging. It works, just need to find the right balance to not get a kick in the butt while getting things committed.
21:46 < kallewoof> cfields: I compiled fine under lubuntu too, though.
21:46 < NicolasDorier> btcdrak taught me this technique. Now I think I surpassed the master.
21:46 < cfields> ah     
21:47 < cfields> kallewoof: fyi, I've written a pretty full-featured c++ wrapper for libevent. Maybe we should collaborate a bit to avoid stepping on eachother.
21:48 < kallewoof> cfields: That would be lovely. :)
21:48 < cfields> kallewoof: i'm getting ready to libevent-ify the net code, and I'd really rather not litter it with c code. I think we're probably in agreement there :)
21:49 < kallewoof> Isn't that what #9517 does already?
21:49 < gribble> https://github.com/bitcoin/bitcoin/issues/9517 | [refactor] Switched httpserver.cpp to use RAII wrapped libevents. by kallewoof · Pull Request #9517 · bitcoin/bitcoin · GitHub
21:49 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
21:51 < kallewoof> Oh wait, that's just the httpserver part.
21:51 < cfields> kallewoof: yea, but it doesn't handle refcounting, std::function, etc. I'd much prefer more native looking callbacks and functors.
21:53 < kallewoof> That sounds nice yeah. I'd love to help if there's anything I can do.
21:54 < cfields> kallewoof: for ex, the bufferevent wrapper looks like this: https://0bin.net/paste/1tIvDfqrmUlS5DZU#2y7U59tfCueh+QfprDlMv+5XBjGm2wWceUeKX-PZrTz
21:54 < gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
21:55 < cfields> (it's been a while since I've worked with it, I don't recall exactly what state it's in)
21:55 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
21:55 < kallewoof> Oh, wow.
21:56 < cfields> kallewoof: the goal would be to be able to cleanly work with events like: bufferevent.read_cb([](size_t bytes){printf("read %lu bytes\n", bytes);});
21:56 < kallewoof> Looks pretty neat. Would this be a separate library? It looks like it would be.
21:57 < cfields> it's intended to be a standalone wrapper, but included in our repo
21:58  * kallewoof nods
21:58 < cfields> kallewoof: anyway, that's the reason I haven't chimed in on your PRs. I'd like something a little different, but I don't like standing in the way of obvious improvements either.
22:00 < kallewoof> cfields: I initially started writing something like that (less elegant) but wumpus suggested he wanted something more light weight. I think a fully featured wrapper might be useful, but it adds some amount of maintainer load in case libevent changes. But then again, I doubt libevent will change a whole lot ever, so I don't think it would be a prob.
22:01 < cfields> kallewoof: yea, understandable. fwiw, I don't intend to wrap everything, just the stuff we use
22:02 < kallewoof> Yeah, uh, s/fully featured//
22:02 < cfields> kallewoof: the reason I ultimately decided on that route is I found my own code to be unreadble without it :(
22:03 < cfields> kallewoof: anyway, I'm open to whatever is cleanest/simplest. Maybe minimal would be better. But we should collaborate either way :)
22:03 < kallewoof> I admittedly haven't done a lot. I just fixed the stuff that had // TODO: RAII comments on them, in my never ending quest to find something that needs doing that I am capable of. :P
22:04 < kallewoof> cfields: I would love to collaborate! :)
22:05 < cfields> kallewoof: great, give me a few days and I'll push up what I have. Don't let me keep you from working on what you already have though, we can converge later
22:07 < cfields> kallewoof: one of the most important things (imo) is tracking ownership by passing objects around. For example, if an event needs a pointer to its base, it should hold a reference and keep the base alive. Otherwise, it gets very difficult to guarantee that everything will tear down safely.
22:09 < kallewoof> cfields: I noticed that too. I tried to do something clever but it kind of backfired and I simplified it. It ended up not being intuitive at all. (I think it was something like, a wrapper holding an object lost the object after a certain operation, but I can't remember.)
22:09 -!- dodomojo [~goksinen@2604:2000:c591:8400:50f4:f30c:189b:d8b5] has quit [Remote host closed the connection]     
22:10 < cfields> heh     
22:11 < cfields> in the example above, the CBufferEvent requires a CEventBase in its ctor. CEventBase contains a shared_ptr<event_base>. That way, the base lives at least as long as any bufferevents using it.
22:13 < cfields> so there's no way to create a bufferevent without a valid base, and no way for the base to be deleted out from under a bufferevent.
22:13 < kallewoof> In some cases the underlying libevent struct takes ownership of an argument, e.g. I believe the evhttp takes ownership of passed-in evhttp_requests. That is what got me.
22:14 < kallewoof> Even with shared pointers, the request should sometimes be deleted (if not passed into evhttp) and sometimes not (if passed in).
22:15 < cfields> ah yea, I remember seeing some wonky stuff in evhttp.
22:16 < cfields> (I didn't wrap that)
22:16 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
22:17 < kallewoof> cfields: This is the part, I was a bit off on the struct names, but: https://github.com/bitcoin/bitcoin/pull/9387/files#diff-321303fddcf725df060981d626a05df9R234
22:18 < cfields> kallewoof: is it just evhttp_make_request that does that?
22:18 < kallewoof> Or not... either way, an evhttp_request is stolen by an evhttp_request when calling evhttp_make_request().
22:18 < cfields> or.. just certain functions?
22:18 < kallewoof> Not sure. I think certain functions simply take ownership of stuff you pass in.
22:19 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
22:19 < kallewoof> So far this is the only case I ran into.
22:20 < cfields> kallewoof: well that'd be easy enough to wrap: http.Request(const CConn& conn, CRequest&& req)
22:20 < cfields> I think those could be handled with move semantics reasonably enough?
22:21 < kallewoof> I'm not sure. I talked to wumpus about it. See e.g. https://github.com/bitcoin/bitcoin/pull/9387#issuecomment-268213151
22:22 < kallewoof> I think part of the problem with my approach was that it wasn't especially elegant, so there was no reason for its existence other than simply wrapping libevent into C++ish fluff. Having a more solid solution like what you're proposing is probably more meaningful.
22:23 < cfields> oh i see, it's conditional on what happens in different places
22:23 < cfields> sorry, I really shouldn't speak on the evhttp code, I'm not familiar enough with it.
22:24 < kallewoof> To be honest, neither am I. I just learned enough to make it work replacing the stuff that was there already.
22:25 < cfields> kallewoof: well I agree with trying to keep it as minimal as possible. I think there's some middle ground that maintains the api while adding protection and type/memory safety.
22:25 < cfields> kallewoof: sounds like a good approach if it gets the job done :)
22:26 < cfields> kallewoof: I'll ping you in the next few days. keep up the good work :)
22:27 < kallewoof> Looking forward to it! :)
22:32 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
22:34 < bitcoin-git> [bitcoin] kallewoof closed pull request #9872: [qa] Multi-chain support in test framework (master...qa-multi-chain-support) https://github.com/bitcoin/bitcoin/pull/9872
22:55 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 252 seconds]     
23:01 -!- tw2006 [~tw2006@2601:187:8480:2770:2865:84a4:7af9:9e13] has joined #bitcoin-core-dev     
23:05 -!- zach_ [4944758a@gateway/web/freenode/ip.73.68.117.138] has joined #bitcoin-core-dev     
23:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
23:05 -!- zach_ [4944758a@gateway/web/freenode/ip.73.68.117.138] has quit [Client Quit]     
23:05 -!- tw2006 [~tw2006@2601:187:8480:2770:2865:84a4:7af9:9e13] has quit [Ping timeout: 258 seconds]     
23:07 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
23:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
23:32 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 258 seconds]     
23:42 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
23:48 < bitcoin-git> [bitcoin] kallewoof opened pull request #10208: [wallet] Rescan abortability (master...rescan-abortability) https://github.com/bitcoin/bitcoin/pull/10208
23:51 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
23:52 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]