--- Day changed Thu Jul 06 2017
00:10 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
00:12 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
00:15 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds]     
00:15 -!- LeMiner2 is now known as LeMiner     
00:21 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
00:22 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
00:31 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
00:39 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
00:46 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/191d12b07377393c9eb67770ff5cb8e9a1c5cd7c
00:46 < bitcoin-git> bitcoin/master 191d12b Wladimir J. van der Laan: qt: First translations update for 0.15
00:48 < wumpus> transifex copy was successful this time - copied translations (+metadata) from 0.14 to 0.15, and updated 0.15 resource with new messages, set to auto-update from master (don't forget to change when 0.15 branches off), unlocked - should be good to go
00:48 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev     
00:49 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Ping timeout: 260 seconds]     
00:51 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
00:52 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit]     
01:01 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
01:08 < wumpus> https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2017-July/000042.html
01:16 < luke-jr> I guess 0.15 will probably miss multiwallet :/
01:17 < luke-jr> (at least in terms of it being actually usable in the GUI)
01:18 -!- instagibbs [~instagibb@pool-72-83-36-237.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
01:19 -!- instagibbs [~instagibb@pool-72-83-36-237.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
01:25 -!- elkalamar_ [~elkalamar@84.126.69.179.dyn.user.ono.com] has quit [Remote host closed the connection]     
01:46 -!- NotME_ [b4fee33f@gateway/web/freenode/ip.180.254.227.63] has joined #bitcoin-core-dev     
01:47 -!- NotME_ [b4fee33f@gateway/web/freenode/ip.180.254.227.63] has quit [Client Quit]     
02:02 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
02:17 -!- JackH [~laptop@79-73-189-176.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
02:18 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has joined #bitcoin-core-dev     
02:29 < wumpus> we should aim for basic RPC multiwallet
02:29 < wumpus> full GUI multiwallet is not realistic for 0.15
02:30 < wumpus> darn, forgot to add a tree-sha512 to the last commit on master
02:32 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev     
02:35 < wumpus> why don't we have a "skip these commits for treesha512 check" and only "treesha512 root commit"?
02:36 -!- bordeaux_facile is now known as toinetoine     
02:38 -!- toinetoine is now known as bordeaux_facile     
02:39 < wumpus> argh updating the root commit didn't work, it also checks the root
02:43 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds]     
02:44 < wumpus> BlueMatt: how to fix this?
02:46 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 240 seconds]     
02:46 < wumpus> ... I guess merging a PR with a treehash, then updating the root commit to that would work
02:46 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
02:49 < wumpus> another option would be to force-push the last commit with a treehash, but it's been in master too long
02:49 < wumpus> neither is really nice
02:51 < luke-jr> take the last one with a treehash, and merge the current master into it?
02:52 < luke-jr> could force-push the last commit and open a PR with the real master, if that makes it easier
02:55 < wumpus> that's a smart idea, your first idea is fully fast-forwardable, right?
03:03 < wumpus> seems to work locally, thanks
03:03 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
03:04 < wumpus> here goes nothing...
03:04 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/a5cd829a0b51b69a2e7d5e93f55196f7d67a7462
03:04 < bitcoin-git> bitcoin/master a5cd829 Wladimir J. van der Laan: Merge branch qt-translations into master...
03:13 -!- city22 [~textual@211.94.117.2] has quit [Quit: Textual IRC Client: www.textualapp.com]     
03:16 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 240 seconds]     
03:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:19 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
03:24 -!- marcoagner [~user@179.177.240.114] has quit [Ping timeout: 248 seconds]     
03:24 < wumpus> yay Fixed: bitcoin/bitcoin#19612 (master - a5cd829)
03:24 < gribble> https://github.com/bitcoin/bitcoin/issues/19612 | HTTP Error 404: Not Found
03:36 -!- marcoagner [~user@177.41.194.197] has joined #bitcoin-core-dev     
04:01 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 246 seconds]     
04:03 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:44 -!- Alina-malina [~Alina-mal@37.157.223.81] has quit [Changing host]     
04:44 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
04:48 -!- F2ee [~chatzilla@200.128.9.146] has joined #bitcoin-core-dev     
04:57 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
04:58 -!- F2ee [~chatzilla@200.128.9.146] has quit [Quit: ChatZilla 0.9.93 [Firefox 54.0.1/20170628075643]]     
05:02 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
05:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds]     
05:47 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
05:53 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 260 seconds]     
05:54 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 248 seconds]     
05:54 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev     
05:57 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 248 seconds]     
06:10 -!- unholymachine [~quassel@2601:8c:c003:9f16:b1d7:a2c7:8682:1931] has quit [Ping timeout: 246 seconds]     
06:13 -!- unholymachine [~quassel@2601:8c:c003:9f16:759a:593f:c3b3:7d73] has joined #bitcoin-core-dev     
06:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:19 < bitcoin-git> [bitcoin] laanwj opened pull request #10753: test: Check RPC argument mapping (master...2017_07_rpc_argument_check) https://github.com/bitcoin/bitcoin/pull/10753
06:29 -!- dseg [79737e1b@gateway/web/freenode/ip.121.115.126.27] has joined #bitcoin-core-dev     
06:50 -!- dseg [79737e1b@gateway/web/freenode/ip.121.115.126.27] has quit [Quit: Page closed]     
06:51 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has joined #bitcoin-core-dev     
06:54 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
06:54 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 276 seconds]     
06:55 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a5cd829a0b51...be824984626f
06:55 < bitcoin-git> bitcoin/master bd00fa5 John Newbery: [test] don't run dbcrash.py on Travis
06:55 < bitcoin-git> bitcoin/master be82498 Wladimir J. van der Laan: Merge #10743: [test] don't run dbcrash.py on Travis...
06:56 < bitcoin-git> [bitcoin] laanwj closed pull request #10743: [test] don't run dbcrash.py on Travis (master...dontrundbcrash) https://github.com/bitcoin/bitcoin/pull/10743
07:20 -!- tiagotrs [~tiago@pD9FD69F5.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
07:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:22 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
07:57 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving]     
08:05 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
08:07 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
08:07 -!- Guyver2_ is now known as Guyver2     
08:07 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:22 -!- tiagotrs [~tiago@pD9FD69F5.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]     
08:24 -!- tiagotrs [~tiago@pD9FD69F5.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
08:31 < BlueMatt> wumpus: ugh, please add the pre-push-hook locally
08:32  * BlueMatt goes to check whats up
08:45 < BlueMatt> wumpus: oh, yes, thanks luke-jr, clever solution
08:45 < morcos> achow101: instagibbs: Murch:  I have a couple questions about branch&bound, effective value and change
08:46 < Murch> okay
08:46 < morcos> So I see how we are accounting for output size via output_fee and input_size via nInputBytes
08:46 < morcos> But how are we accounting for fees paid on the fixed part of a tx
08:47 < morcos> Won't we necessarily fail if we get too close to an exact match?
08:47 < morcos> Second question: Why are we using the longest possible estimate for the creation of change?
08:47 < Murch> We first get an estimate for the fee rate. Since we know which outputs we want to create for recipients, we can calculate the amount of fee for the outputs.
08:48 < Murch> We add that and the cost of the transaction overhead to the target
08:48 < Murch> So, when we select inputs, we can deduct the cost of the inputs from each that we select and thus we have accumulated all fees necessary.
08:48 < morcos> The transaction overhead piece is the part I was missing
08:48 < morcos> maybe i just missed it
08:49 < Murch> Do you mean specifically in the code? I think that achow101 was missing something there, and we discovered the bug in review recently. I'm not sure if he already fixed it.
08:50 < morcos> ok. yeah thats what i meant
08:50 < morcos> i'm mostly asking questions about his code
08:50 < Murch> Re 2nd Q: BnB only creates transactions without change outputs. Since we can account for the fees of the overhead and outputs in advance, and the fees for the inputs on the fly, we're good. So I don't get what you mean with "creation of change".
08:51 < morcos> I mean the cost of change_
08:51 < morcos> we're calculating it using a smart fee estimate for 1008 blocks
08:51 < morcos> when in reality it'll cost us whatever fee we're using for this transaction creation
08:51 < Murch> Well, actually, this is the part that I'm not comfortable with yet.
08:52 < Murch> Obviously, the only amount that we're clearly saving is the cost of creating a change output.
08:53 < Murch> However, in my simulation, I got a cost reduction by allowing the larger window of "cost of input+output". I was assuming _fixed feerates_ though.
08:53 < morcos> ah i see, i'd missed that
08:53 < morcos> well what i'm saying is something different again
08:53 < Murch> I think that it would need some experimentation to determine whether it is actually a net-benefit to have the larger window and thus save the change more often or not.
08:53 < morcos> actually waht we might want is something similar to what i did in #10712
08:53 < gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
08:54 < morcos> but my point was the change_feerate we are using is possibly too low
08:54 < Murch> One of the Trezor people implemented BnB for BitcoinJS this week, and came to the conclusion that "cost of change = change * current feerate" has greater savings.
08:54 < morcos> maybe that is a good feerate to use for assumption of spending the change output in the future
08:54 < Murch> So I would suggest that we go with that first.
08:55 < morcos> might it make sense to cache the best result found so far and keep searching 
08:55 < morcos> and have two thresholds, one which is good enough to stop searching further, and one which is good enough if its the best thing we came to at the end of the exhaustive search (or hitting max tries)
08:56 < morcos> In any case we're possibly willing to just throw away the amount of fees determined by change_feerate right?  i'd be very hesitant to just use 1008 for that
08:57  * instagibbs reading backlog
08:57 < morcos> I've seen that number as high as 100 sat/byte, not sure poeple would want to throw away that much, at least not without looking for a better exact match
08:57 < Murch> My gut feeling is that this would increase the size of the selected input sets. That would both increase the variance of the input set size, and perhaps reduce the utxo pool more quickly, perhaps reducing overall effectiveness of BnB.
08:58 < morcos> sorry, what would?
08:58 < Murch> More experiments would inform us, I guess.
08:58 < Murch> finding the "best solution".
08:58 < Murch> Also would probably increase the search times a lot
08:58 < Murch> mh     
08:58 < Murch> sorry, I'm too slow
08:58 < morcos> yeah i was a bit concerned about that
08:59 < Murch> So 1) for the window of determining the exact match, I would use the same fee rate as for the transaction * size of a change output.
09:00 < morcos> Yes even plus the dust threshold of the output itself
09:00 < morcos> as done in 10712
09:00 < instagibbs> Murch, im sorry you mean don't consider a future spend of it?
09:00 < Murch> 2) I would go with the first solution instead of the best solution, because it reduces variance in input set size, reduces computation time, and will probably be more conducive to finding many exact matches.
09:00 < instagibbs> oh sorry, you mean use same feerate for both output size and future input
09:00 < morcos> I'll defer to your judgement on that
09:01 < morcos> no instagibbs i think he means don't consider future input
09:01 < instagibbs> due to the bitcoinjs experiments?
09:01 < morcos> but i'm suggesting we should consider future input via GetDustThreshold
09:01 < Murch> instagibbs: I'm concerned that we're overestimating the saved cost
09:01 < morcos> In addition to current fee rate times size of creating output
09:01 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
09:01 < instagibbs> Murch, explain?
09:02 < Murch> @instagibbs: Yeah.
09:02 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
09:03 < morcos> I think it's exactly this calculation we should use: https://github.com/bitcoin/bitcoin/pull/10712/files#diff-b2bb174788c7409b671c46ccc86034bdR2762
09:03 < Murch> So, my experiments for my thesis assumed a fixed fee rate for the whole cycle. This allows me to be sure of the saved cost of "input + output"
09:03 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
09:04 < Murch> Fixed fee rate is not a valid assumption IRL, so it's hard to estimate the saved cost for the input.
09:04 -!- Guyver2_ is now known as Guyver2     
09:04 < Murch> We see frequent changes in fees in a range of factor 50.
09:04 < instagibbs> Yes, but if fees really do move up on longer-term I don't see why we'd ignore it
09:05 < Murch> Now, currently there are four implementations of BnB that I'm aware of: My science project, Core, BitcoinJS, and what I'm working on for BitGo right now.
09:05 < instagibbs> more aggressive non-change making has privacy advantages on top that I don't think we should ignore
09:05 < morcos> I think we have to distinguish between giving up and generating the change (in which case htere is a cost) and saying ok well this solution isn't close enough that we're willing to just discard the difference
09:05 < Murch> Karel implementing the BitcoinJS one, has done some more experiments and informed me that just using the "output as cost of change" resulted in lower total fees.
09:06 < Murch> instagibbs: Smaller window might cause larger input sets, so it might actually work towards that end. It's hard to tell. ;)
09:06 < instagibbs> Murch, what about how many change outputs are made vs
09:06 < morcos> and potentially trying again
09:06 < instagibbs> and how much are you saving
09:07 < instagibbs> not asking for an answer right here, just think it's important to consider
09:07 < Murch> instagibbs: I don't know. Maybe I was overestimating that effect myself, as I asked Karel whether the rate dropped significantly by making the window smaller.
09:08 -!- owowo [ovovo@gateway/vpn/mullvad/x-ejxryjtfszumjmgm] has quit [Ping timeout: 240 seconds]     
09:08 < Murch> instagibbs AFAIU, it didn't though.
09:08 < morcos> This all depends on assumptions about the distributions of the utxos in the pool.   It's going to be different for different people.  In some cases making window larger will just cause you to waste money
09:08 < Murch> instagibbs: Yes definitely need to consider that. Also the average input size and whether it exhausts our smaller inputs too quickly to do later exact matches.
09:08 < morcos> B/c you would have found a smaller exact match.  In other cases a larger window will allow you to find an exact match when you otherwise wouldn't have
09:09 < morcos> Do we have any good data sets for a large number of users to evaluate this on at all
09:09 < Murch> morcos "…wasting money…" exactly.
09:09 < instagibbs> not public ones
09:09 < instagibbs> :P     
09:09 < Murch> instagibbs: yep.
09:10 < Murch> I'm gonna do a little more experiments in the coming week to evaluate the algorithm for our internal use. I also have another project though, so I can't give you a timeline. I might have more information on some point though.
09:10 < Murch> Can't share the data of course. ;)
09:10 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
09:13 < morcos> Does the KnapsackSolver still try to find an exact match if BnB fails?
09:13 < morcos> Is that worth doing still?
09:14 < instagibbs> likely not worth it
09:14 < morcos> I'm just trying to figure out whether we cna assume we'll probably have change if BnB fails
09:14 < instagibbs> I think we should toss all of that and assume we get change
09:14 < instagibbs> we can definitely get data for that once we have BnB being used...
09:14 < morcos> If so, then we definitely at least want to use the current fee rate times the size of the change out put, plus dustthreshold of output size
09:15 < morcos> Whether we want to do that on a first pass or maybe do two passes or something, I don't know...
09:15 < instagibbs> "use" in what sense, sorry
09:16 < morcos> for the cost_of_change
09:16 < instagibbs> k     
09:16 < instagibbs> remind me what the second term is accomplishing?
09:17 < morcos> Also I think we need a lot more reasoning about how we intermingle the (BNB, knapsack) ordering with the (MinConf=6, MinConf=1, MinConf=0 (various chain lengths) ..) ordering
09:17 < instagibbs> just a small window on top?
09:17 < morcos> You can't create a change output smaller than DustThreshold anyway
09:18 < instagibbs> I just need to read the branch again, ignore my q
09:18 < morcos> so if you found a match where once you paid for the fees required to create the change output (at the feerate this tx is using) you only have < dust left for the change, then you'd just eliminate the change later anyway.  So why not look for an exact match
09:18 < instagibbs> yep     
09:18 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 240 seconds]     
09:18 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/be824984626f...30bc0f672626
09:18 < bitcoin-git> bitcoin/master b8bb425 Michael Rotarius: REST/RPC example update
09:19 < bitcoin-git> bitcoin/master 30bc0f6 Wladimir J. van der Laan: Merge #10710: REST/RPC example update...
09:19 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
09:19 < bitcoin-git> [bitcoin] laanwj closed pull request #10710: REST/RPC example update (master...docupt) https://github.com/bitcoin/bitcoin/pull/10710
09:19 < morcos> Right now it looks to me at a cursory glance like we first try using BNB on all of the minConf orderings...   So potentially we are going to create a long chain of unconfirmed txs just b/c they don't generate change (luckily that's anti-self-reinfocing)
09:20 < morcos> That doesn't seem to me necessarily what the user wants?  But I don't know what the right order is.
09:20 < morcos> It would be good if there was a lot more documentation about the logic in that PR.   The old code was already way under documented, lets not repeat that mistake
09:21 < instagibbs> that block of SCMC could have a comment header explaining the steps
09:22 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:22 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
09:25 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
09:26 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit]     
09:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
09:29 < Murch> sorry, something came up. I agree that the KnapsackSolver should not try to find an exact match anymore. It's also not good at it anyway.
09:32 < Murch> In most cases when it would find an exact match, it would throw it out because it can't pay the fees in subsequence.
09:55 -!- Felipe2 [~Felipe@188.226.139.184] has quit [Remote host closed the connection]     
09:57 < bitcoin-git> [bitcoin] laanwj pushed 37 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/fc61c8322bd7...91be5e3c1e45
09:57 < bitcoin-git> bitcoin/0.14 d28d583 Suhas Daftuar: Bugfix: PrioritiseTransaction updates the mempool tx counter...
09:57 < bitcoin-git> bitcoin/0.14 71463a7 Suhas Daftuar: [qa] Test prioritise_transaction / getblocktemplate interaction...
09:57 < bitcoin-git> bitcoin/0.14 ef810c4 practicalswift: [trivial] Fix a typo (introduced two days ago) in the default fee warning...
10:02 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has joined #bitcoin-core-dev     
10:02 < spudowiar> To confirm, UniValues can only be appended to, not modified, right?
10:03 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
10:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
10:06 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
10:06 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]     
10:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
10:09 -!- tiagotrs [~tiago@pD9FD69F5.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
10:14 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:17 < instagibbs> seems that way
10:18 < spudowiar> Copying the object to modify it seems wrong
10:19 < spudowiar> I might copy the function from core_write to CWallet and modify it for my usecase
10:20 < spudowiar> There are quite a few neat changes I could make then
10:22 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has quit [Ping timeout: 260 seconds]     
10:26 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has joined #bitcoin-core-dev     
10:26 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
10:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
10:31 < wumpus> correct - you shouldn't need to edit univalue object, either consume them or generate them
10:32 < wumpus> they're meant for being used on the interface, not meant as a lasting data representation format
10:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:37 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
10:38 < instagibbs> morcos, interesting to note that a successful BnB on a long chain ends that chain for the user. Once we're using effective value everywhere you can do two quick SelectCoins calls, but then you still have that judgment call of which is better.
10:40 < morcos> instagibbs: yeah its not obvious to me what the right outcome is, but i think we explicitly need to think about it.  I think we'd do better creating change from confirmed outputs before extending a chain, at least until we do something smart with whole chain fee control.
10:40 < morcos> but for instance we might prefer to create no-change from 1-confirm inputs before creating change from 6-confirm inputs
10:41 < instagibbs> Indeed that would be better, but I'd still like to revisit BnB if we cant do knapsack w/ confirmed
10:41 -!- donaloconnor [~donal@149-13-247-10.c.wicklowbroadband.com] has joined #bitcoin-core-dev     
10:41 -!- donaloconnor [~donal@149-13-247-10.c.wicklowbroadband.com] has quit [Remote host closed the connection]     
10:42 < instagibbs> Throw-away idea: Let the transaction construction loop happen once, never accept the first result, then you can compare the two,
10:43 < instagibbs> the first will always fail anyways
10:44 < morcos> sipa: style ruling please, this time i think i checked developer notes first.  If I have a static class member like CWallet::fallbackFee should that be g_fallback_fee or m_fallback_fee?
10:45 < sipa> not a constant?
10:45 < morcos> well its a command line argument
10:46 < sipa> i guess technically that would be a member field, but personally i very much think we should avoid non-const static members, and make them globals instead
10:46 < wumpus> it's an interesting case
10:47 < morcos> ok, i'm happy to do that.  just global but declared in wallet.h ?
10:47 < sipa> sounds good to me
10:47 < wumpus> not convinced a global is better
10:47 < sipa> static class members effectively are globals
10:47 < sipa> they're just abusing the class as a namespace
10:47 < wumpus> at least the class provides some kind of scoping
10:47 < morcos> thats why my guess was CWallet::g_discard_rate
10:47 < wumpus> well it's better than throwing everything into the global namespace
10:48 < sipa> i guess the right approach is to actually have good namespacing
10:48 < wumpus> sure
10:48 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
10:48 < wumpus> but now it could collide with something e.g. outside of wallet, it's not clear it's for the wallet
10:49 < wumpus> m_fallback_fee could be anything, also a mempool thing
10:49 < gmaxwell> Keep in mind that we avoid spending third party unconfirmed inputs for security reasons; and our own for privacy (otherwise the change is immediately distinguishable)
10:50 < morcos> so what am i doing then?
10:50 < morcos> the existing similar variables are static class members for now
10:50 < sipa> if it's a static member variable, call it CWallet::m_fallback_fee
10:51 < wumpus> better to keep it consistent and make this one too, morcos, I'd say
10:51 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
10:51 < wumpus> and yes call it m_fallback_fee
10:51 < morcos> ok, i'll do that for now..  if we want to , we can clean up all of them later
10:51 < sipa> ack     
10:51 < morcos> btw, i think it would be nice to have helper functions for all these command line arguments
10:51 < sipa> yes...
10:52 < morcos> so we could sort of declare the argument, its help string, its min and max value, etc.. all in one place
10:52 < wumpus> we have a PR that improves argument handling IIRC
10:52 < wumpus> would be nice post-0.15
10:57 < wumpus> would be nice to finally be able to close #1044
10:57 < gribble> https://github.com/bitcoin/bitcoin/issues/1044 | Problems with command-line options silently ignored · Issue #1044 · bitcoin/bitcoin · GitHub
10:57 < sipa> yes...
10:58 < wumpus> which should be easy if all command line arguments are registered
10:58 < spudowiar> Yea or nay: Adding a const CWallet& parameter to TxToUniv which adds hdKeypath to your own inputs and the change outputs?
10:58 < spudowiar> Or should I create a new version of TxToUniv?
11:00 < instagibbs> I don't think that function has any knowledge of wallet
11:01 < wumpus> yes it is not a wallet function, core_io etc has no wallet dependency
11:02 < wumpus> if you need one for the wallet, define your own
11:02 < spudowiar> instagibbs: Hence adding the const CWallet& parameter :)
11:02 < sipa> spudowiar: that would make the function dependent on the wallet, which we want to avoid
11:02 < instagibbs> I more mean it's a layer violation
11:02 < spudowiar> sipa: Only if you provide the wallet parameter
11:03 < wumpus> one that takes a CWalletTx, defined in the wallet library
11:03 < sipa> spudowiar: you don't understanf
11:03 < morcos> gmaxwell: This is the discard_rate idea: https://github.com/morcos/bitcoin/commit/fd8104a9f074ca588d44defe015b0ace77dbc7fc
11:03 < wumpus> spudowiar: no, he means a compile-time dependency
11:03 < spudowiar> Oh, gotcha, sorry :)
11:03 < spudowiar> I just realised :)
11:03 < wumpus> spudowiar: core_io etc do not include wallet.h at all ,they don't link against the wallet stuff
11:03 < spudowiar> I didn't realise it was in bitcoin-common
11:03 < sipa> spudowiar: if the function takes a wallet argument, it becomes code that cannot exist without the wallet code being present too
11:03 < morcos> gmaxwell: very simple, but i fear there are too many outstanding other wallet fee PR's to bother with that for now (i built it on top of them since it interacts)
11:04 < sipa> spudowiar: in general, the wallet is intended to be separated off at some point, and even if it isn't, it's good practices to reduce dependencies between modules
11:04 < wumpus> anyhow, functionality that should be present when buildilng without the wallet relies on TxToUniv
11:04 < gmaxwell> morcos: I like.
11:05 < morcos> instagibbs: Murch: achow101: It's this discard rate idea that I'd use to set your window in BnB as well.  In addition to the cost of creating the change at the current fee level.
11:06 < achow101> discard rate?
11:06 < achow101> (sorry, I've missed most of the conversation here)
11:06 < wumpus> cfields: could you take a look at #10508 - it is a tests PR, but involves some small build system changes, would be nice if you could take a look
11:06 < morcos> See link 10 lines up
11:06 < gribble> https://github.com/bitcoin/bitcoin/issues/10508 | Run Qt wallet tests on travis by ryanofsky · Pull Request #10508 · bitcoin/bitcoin · GitHub
11:06 < achow101> ah, ok
11:07 < cfields> wumpus: grr, i was thinking I was missing a reponse to a build PR, but I couldn't track it down. Sorry. Looking now.
11:09 < instagibbs> morcos, TLDR: max(min(1008 smart unconservative smart fee, static_discard_rate)), dustRelayFee)
11:09 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:10 < morcos> instagibbs: yes. GetDustThreshold(^ that)
11:12 < instagibbs> seems reasonable, user can always protect super-dustRelayFee change if they decide to
11:17 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
11:17 < Murch> morcos: That would be a good price estimate for the input cost of the saved change output.
11:19 < morcos> Murch: yes that's what i'm saying...  and after #10712 its the calculation that is used to say oh wow we're paying way too much fee, lets add change 
11:19 < gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
11:21 < morcos> I'm actually not 100% convinced 10712 is a good idea.. It will lead to a bit more utxo bloat. The true fix is to be smarter about never creating small change which requires effective fee rates.
11:25 < kanzure> is the sentiment that the 1008 block estimatesmartfee for change output size minimum threshold is a bad thing due to utxo bloat ?
11:25 < instagibbs> kanzure, right now the wallet is just really bad at targeting good change size outputs or exact matches
11:26 < instagibbs> so it kind of lands in the middle
11:27 < kanzure> in another 'wallet' (not core) (it's not a wallet) i was going to ask for two fee rates, one for the non-change outputs and another for an estimation of the minimum size of any possible change output below which to burn to miner fee.
11:27 < instagibbs> right, that's the above idea
11:27 < instagibbs> discardRate, where it's ok to drop it
11:28 < kanzure> if all outputs were required to be multisig p2sh then we could insist that everyone just transfers their change in the same output, and they can worry about spending it later. </joking, not practical>
11:30 < Murch> morcos: I don't think I have a good overview of what's going on yet, but generally I'd suggest that we aim for clearcut scenarios:
11:30 < Murch> 1) Try to create no change output (use BnB)
11:30 < Murch> 2) If fail: Try to create change output greater than min_change
11:31 < Murch> 3) small number of cases that don't fit in any other bucket: If change output is too small to keep discard.
11:31 < Murch> […], discard.
11:32 < morcos> Murch: 100% agree, but the real issue is once we have effective_value we can do both those things.  even part 2 requires a good effective value.
11:32 < Murch> what do you mean with "effective_value"?
11:32 < kanzure> instagibbs: unfortunately we edge up to this fundamental tradeoff between discardRate, utxo bloat minimization, and folks losing money because small outputs are essentially unspendable (some always, some intermittently).  essentially, certain payment amounts-- from certain inputs--  are simply not workable.  if 10 more seconds of coin selection computation could solve this for a user, i thi...
11:32 < kanzure> ...nk that's worth the face value of the output.
11:32 < morcos> An additionaly issue however is I don't think its the best idea in the world to add tons of inputs that have barely positive effective value when we are payin a high fee rate, but thats possibly a later improvement
11:33 < Murch> morcos: I think you're worrying too much about utxo bloat. In my simulation, BnB + RandomSelection as fallback had a much lower average UTXO Pool size than Core selection.
11:33 < Murch> BnB + Core as a fallback should be even smaller.
11:34 < gmaxwell> I don't think there is any bloat concern on BNB. Thats part of why we're doing it first.
11:34 < morcos> The big question is how often does BnB find an answer
11:34 < morcos> I have no insight into that
11:34 < instagibbs> Murch, could you just do dumb fallback
11:35 < instagibbs> I think you did right?
11:35 < Murch> morcos: In my simulation with 12k outgoing payments, I found ~39% exact matches with BnB and ~0.6% with Core.
11:35 < morcos> If murch's simulation is on a larger than typical spendable utxo set then it may overestimate the benfit we gain from BnB
11:35 < Murch> morcos: Saying we have no idea, seems a bit of a stretch.
11:35 < morcos> 12k outgoing payments from what utxo set per payment?
11:36 < morcos> is each one from the actual utxo set that that payment was made from?
11:36 < morcos> is that one big utxo set
11:36 < morcos> sure, i think BnB will make a huge difference for commercial applications with large utxo sets
11:36 < Murch> morcos: It's a sequence of 36k payments in total, 12k outgoing, 24k incoming.
11:37 < morcos> but all to the same utxo set?
11:37 < gmaxwell> morcos: he has a feed of input and output payment amounts simulate the wallet (e.g. how it's utxos evolve over time)
11:37 < Murch> yes     
11:37 < gmaxwell> its*
11:37 < morcos> so thats far from typical
11:37 < sipa> morcos: but perhaps very significant on the overall utxo set
11:37 < achow101> isn't that dataset from moneypot's payments?
11:37 < gmaxwell> morcos: well it's actual for at least one user, we don't know how it represents everyone but users like this are a non-trivial amount of the total network behavior.
11:37 < sipa> morcos: as in, perhaps a large portion of the actual network comes from large player's wallets
11:37 < morcos> sipa: unknown.  what % of utxos belong to a big wallet vs small
11:38 < sipa> morcos: yes, i don't know either
11:38 < Murch> I've also consolidated the incoming payments 4 to 1, to make a scenario with 6k incoming payments and 12k outgoing payments. It still did great on UTXO set reduction
11:38 < Murch> achow101: Yes, the same
11:38 < morcos> gmaxwell: don't get me wrong.  i'm very in favor of doing BnB. its certainly not hurting small wallets
11:38 < gmaxwell> Im not sure of the thrust of the discussion here, but I do not see how the BnB could be anything worse than a small improvement.
11:38 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/30bc0f672626...5af657253498
11:38 < bitcoin-git> bitcoin/master 928c681 Matt Corallo: Use "replaceable" instead of "optintorbf" in createrawtransaction....
11:38 < bitcoin-git> bitcoin/master fb915d5 Matt Corallo: Use "replaceable" instead of "optIntoRbf" in fundrawtransaction....
11:38 < bitcoin-git> bitcoin/master 73c942e Matt Corallo: Use "replaceable" instead of "rbfoptin" in bitcoin-tx....
11:38 < gmaxwell> morcos: okay good!
11:38 < morcos> all i'm arguing is we can't look at this increase to 39% exact matches and assume its going to have a huge effect on the overall utxo set which is made up of many smaller sets
11:39 < sipa> morcos: agree - we don't know the impact
11:39 < bitcoin-git> [bitcoin] laanwj closed pull request #10698: Be consistent in calling transactions "replaceable" for Opt-In RBF (master...2017-06-replaceable-rpc-args) https://github.com/bitcoin/bitcoin/pull/10698
11:39 < Murch> morcos: Coin selection in a wallet that has significantly more outgoing payments than incoming (i.e. most end-user cases) is trivial.
11:39 < morcos> so we still have to be worried about utxo bloat in the event BnB fails
11:39 < gmaxwell> oh sure, I think it's fair to say that we don't know how much of an improvement it will be in aggregate.
11:39 < morcos> This is what i'm talking about
11:39 < instagibbs> eh, economic node activity likely follows a power law
11:39 < gmaxwell> Just that it will do no harm and at least in some cases help a lot.
11:39 < Murch> morcos: Coin selection in a wallet that has more incoming payments than outgoing should do very well with BnB.
11:39 < instagibbs> maybe wont matter for small wallets you're right
11:39 < morcos> balancing users wasting their small utxos when they are getting very little to negative effective value from it vs at some point needing to aggregate those to avoid bloat
11:40 < morcos> Murch thought i was over worrying about bloat
11:40 < Murch> morcos: Well, but UTXO set being generally split over more different wallets is not something we can influence on the coinselection level in the first place. That's on the adoption level.
11:40 < gmaxwell> morcos: well in achow101's implementation he is using (and would switch to exactly) something just like the dustfee metric you just linked to, I don't think we have to worry about waste if using that.
11:41 < morcos> gmaxwell: the case i'm talking about is if we don't succeed in BnB, then what change do we aim for.  We certainly would like to get higher than something governed by the discard rate.
11:42 < gmaxwell> morcos: okay so BnB is basically unrelated.
11:42 < instagibbs> I think we're agreeing here. For fallback we should pick something significantly higher if possible
11:42 < morcos> gmaxwell: yes
11:43 < Murch> Yeayeah
11:43 < morcos> while we're on the subject
11:44 < morcos> gmaxwell and everyone did you see my above question about how (bnb, knapsack) should be intermingled with (selectcoinsminconf (different params))
11:44 < morcos> at what point do you prefer no change but less confirmations or longer unconfirmed chain
11:45 < gmaxwell> morcos: yes, I have some agreement though there are privacy implications.  We don't spend 6 conf or less from third parties for security reasons.  And we try to avoid spending our own at less than 6 conf to avoid blowing up any privacy change has.
11:45 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:45 < gmaxwell> But I think we should BNB longish chains for example.
11:45 < gmaxwell> because that ends them.
11:45 < gmaxwell> but obviously not overlong (24+) ones.
11:45 < morcos> but not before creating a tx which doesn't spend unconfirmed ?
11:46 < gmaxwell> OH on this subject. We need to consider the feerate of unconfirmed parents as part of their effective rate.
11:46 < gmaxwell> And CPFP them.
11:46 < morcos> actually, maybe it wouldn't be that hard to be kind of smart about it.
11:47 < morcos> yes , well before that step, you could only consider extending chains which pay a feerate at least as high as the one you are paying
11:47 < gmaxwell> For example if you managed to make a very low fee payment A, then make payment B with better fee settings. If B spends from A it needs to CPFP A up to B's target feerate.
11:47 < gmaxwell> Indeed.
11:47 < gmaxwell> I've seen some users screwed with this FWIW.
11:47 < morcos> i don't think you'd necessarily want to automatically CPFP a chain if you had other options
11:48 < gmaxwell> They made a payment with a very low rate shortly after startup, then the next day they made another payment that paid a reasonable rate, but was a child.
11:48 < instagibbs> you'd need to avoid bumping twice, by detecting if they are cousins in a chain
11:48 < gmaxwell> I think you might want to automatically CPFP any input that you set the same confirmed target or lower on.
11:49 < gmaxwell> instagibbs: well they won't be unless we're making multiple change outputs or paying ourselves.... but yes...
11:49 < gmaxwell> this suggests that perhaps we should be tracking what the fee settings were for those transactions.
11:49 < morcos> goodness, this is going to get complicated.
11:49 < gmaxwell> Hurray!
11:50 < gmaxwell> (this means we're starting to understand all that we don't know about the problem space)
11:50 < instagibbs> next we need to throw a general purpose optimizer at it
11:50 < rhavar> pretty sure that's the only sane solution if you want to automatically do CPFP and stuff
11:50 < gmaxwell> nah.
11:50 < gmaxwell> Other than having a bunch of conditionals I think this stuff isn't *that* gnarly. 
11:51 < instagibbs>  didn't close my statement with /s
11:51 < gmaxwell> The hurestic would be that you first consider unconfirmeds that either are at the target or higher feerate  or at the current target or lower... ... but always CPFP things up to the current destination rate.
11:51 < gmaxwell> and use the CPFP impact in the EV calculations.
11:52 < rhavar> I'm not sure it's a horrible idea to just write the whole thing up as a general purpose constrain solving problem 
11:52 < rhavar> and just not include a constrain solver :P
11:52 < rhavar> have it as a plugin or something
11:53 < gmaxwell> rhavar: I've done this previously, but the actual solving isn't really that big a deal.
11:53 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds]     
11:53 < rhavar> For casual wallet users, they're only going to have a couple of inputs and outputs -- you can pretty much brute force the space
11:53 < rhavar> And for commercial users, they can actually install some shared object plugin that calls out to a proper library 
11:54 < gmaxwell> it's not magic in any case.
11:54 < rhavar> That's what I'm doing right at this moment, I pretty much brute force solutions with a cost metric
11:54 < gmaxwell> I think there is a AMSL statement of a toy coinselection problem that I wrote floating around out there somewhere. 
11:54 < rhavar> and it does a *decent* job
11:55 < rhavar> I'll have a robust minizinc implementation pretty soon, if anyones interested
11:55 < gmaxwell> rhavar: sure and thats what it does internally, it's just using a different cost design than you.  (A dumb one that is optimizing under assumptions like addresses are never reused) :)
11:56 < gmaxwell> unfortunately, last I checked there are no sutable solvers that we can distribute... but I wouldn't have any issue with having an interface to call out to something.
11:56 < rhavar> I guess what I mean, is if you actually support loading a .so  plugin or something -- you can pretty much not worry about it
11:57 < gmaxwell> rhavar: except like, you know, we need to worry about that 99% of users (including commercial ones) that aren't going to solve this for themselves, and not better than we will. :)
11:57 < gmaxwell> but no issue supporting loadable things for people who want them.
11:57 < morcos> also the magic is in the metric isn't it
11:57 < rhavar> This is the cost function I use: https://gist.github.com/RHavar/0710144c713033d42f8f443a99fefbb7
11:58 < rhavar> I think it makes perfect sense for casual users too 
11:58 < rhavar> Just instead of using a proper constrain solver, they can use a brute forcer
11:58 < rhavar> which is pretty trivial to write
11:58 < jtimon> meeting?
11:58 < sipa> soon!
11:59 < gmaxwell> rhavar: you perhaps overestimate how far you can go with bruteforce... :P once you have more than two dozen inputs it starts becoming intractable.
11:59 < gmaxwell> (and my wallets have a lot more than two dozen inputs, and I'm just some guy)
12:00 < rhavar> I'm using a brute force search with ~2k inputs right now, and it does a *decent* job
12:00 < rhavar> not perfect though, that's why I'm paying for the minizinc impl
12:00 < rhavar> (I obviously don't search the entire space, I time out after 10 minutes) 
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Jul  6 19:00:44 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 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
12:00 < jonasschnelli> proposed topic: multiwallet endpoint vs json item
12:00 < sipa> LO     
12:00 < wumpus> topics?
12:01 < achow101> hi     
12:01 < cfields> hi     
12:01 < kanzure> hi.     
12:01 < wumpus> jonasschnelli: yeah, apparently we have to discuss that again, with all the competing PRs
12:01 < jonasschnelli> heh. Yes
12:01 < wumpus> jonasschnelli: though in principle we settled on endpoint a few weeks ago
12:01 < morcos> begging for review... lots of fee/wallet/estimate stuff that needs to make 0.15
12:01 < morcos> i already have 3 on high priority... sheepish grin
12:01 < wumpus> yes, high priority for review will as usual be first topic
12:01 < gmaxwell> morcos: We should do the things.
12:01 < jonasschnelli> We set endpoints, but some where also in favor of the JSON item solution
12:02 < wumpus> #topic high priority for review
12:02 < BlueMatt> PSA: if you're running master, be very careful not to swap -txindex on your db: the check to prevent you from doing so is broken and you could corrupt your chainstate
12:02 < wumpus> https://github.com/bitcoin/bitcoin/projects/8
12:02 < gmaxwell> by swap txindex he means turn it on/off on an already running node.
12:02 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]     
12:02 < jonasschnelli> I'll remove my #10240 from the list for now
12:02 < instagibbs> good to know...
12:02 < wumpus> without a reindex-chainstate I guess
12:02 < sipa> gmaxwell: you mean already created db?
12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
12:03 < wumpus> jonasschnelli: ok
12:03 < jonasschnelli> It's to big and will re-focus during early 0.16
12:03 < jtimon> maybe put #8498 in project 8 ?
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
12:03 < luke-jr> wumpus: the arguments for endpoint seem strong IMO
12:03 < instagibbs> morcos, doesn;t help that they're an unconfirmed chain of PRs :)
12:04 < morcos> instagibbs: i know! :)  high priority review ones arent though
12:04 < sipa> we need a chain length limit on PRs
12:04 < luke-jr> guess we're not on that topic yet
12:04 < wumpus> jtimon: is that high priority to get into 0.15?
12:04 < wumpus> luke-jr: next topic
12:04 < BlueMatt> wumpus: I think 10179 is ready(ish) for a merge, which makes my high-prio of 10652 cleaner
12:04 < jtimon> wumpus: I haven't benchmarked, but it's an optimization and now also a "near bugfix"
12:04 < morcos> BlueMatt: i was just rereviewing that, but don't wait on me, i'm out of sync these days and doing all posthumous review
12:05 < wumpus> BlueMatt: agree
12:06 < sipa> #10179
12:06 < 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:07 < BlueMatt> yes, second PSA: never shy away from postumous review! the feeling that its not contributing to moving things forward is wrong, if you think something got merged without enough acks, just review it!
12:07 < morcos> or if you want to be sure to understand the new code!
12:07 < BlueMatt> well, that too
12:07 < Murch> Or if you want to understand the code in the first place! :)
12:08 < wumpus> :)     
12:08 < wumpus> ok, so anything that needs to be added to project 8?
12:09 < morcos> i have other things needed for 0.15, but they are dependent on the ones i already have in 8
12:09 < morcos> also i already have 3
12:09 < wumpus> ok, just tag them for 0.15 then, don't need to be in that project
12:09 < wumpus> #topic RPC interface for multiwallet (again)
12:09 < jtimon> wumpus: doesn't that qualify for priority?
12:09 < instagibbs> can someone give an overview of what people are thinking on interface for multiwallet... i missed this
12:09 < wumpus> jtimon: if the gain is unclear, I don't think so
12:09 < jonasschnelli> Again we should decide wether we use Endpoints of JSON objects for multiwallet switch... helps to continue on PRs
12:10 < wumpus> instagibbs: please read the current PRs:
12:10 < sipa> wumpus: can we have #10571 #10579 in 0.15?
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/10571 | [RPC]Move transaction combining from signrawtransaction to new RPC by achow101 · Pull Request #10571 · bitcoin/bitcoin · GitHub
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
12:10 < jonasschnelli> The JSON object is simpler... less impect
12:10 < jtimon> wumpus: I think it's clearly a gain
12:10 < jonasschnelli> the endpoint approach may allow more in future...
12:11 < jtimon> I don't understand the criterion then
12:11 < wumpus> #10650 #10653  
12:11 < jonasschnelli> In the JSON object approach (where you choose the wallet bases on a JSON array item), I don't like that the actual switch in in the JSON layer.
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
12:11 -!- str4d [~str4d@c-24-218-248-188.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10653 | Simple, backwards compatible RPC multiwallet support by ryanofsky · Pull Request #10653 · bitcoin/bitcoin · GitHub
12:11 < luke-jr> I like the JSON interface, but I worry that when we split out the wallet it will break
12:11 < instagibbs> wumpus, add those to multiwallet project?
12:11 < wumpus> #10650
12:11 < jonasschnelli> It also only works with the new named based argumenst
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
12:11 < wumpus> eh what's the third one?
12:12 < luke-jr> endpoints seemed okay, until the API bump got tacked on..
12:12 < jonasschnelli> I guess the third one (based on Auth) has already been "rejected"? right?
12:12 < wumpus> I don't like the JSON based interface, having to add an optional wallet argument on every wallet call is easy to forget
12:12 < ryanofsky> #10661 works with positional arguments, not just named arguments
12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/10661 | Add optional wallet=filename arguments to wallet RPCs by ryanofsky · Pull Request #10661 · bitcoin/bitcoin · GitHub
12:12 < wumpus> and if you forget it it defaults to the 'default wallet'
12:12 < wumpus> that's just too easy to mess up
12:12 < jonasschnelli> ryanofsky: thanks for clearing this up... wasn't aware, sry
12:12 < wumpus> the endpoint makes sure you can be connected to only one wallet with one RPC connection
12:12 < wumpus> jonasschnelli: right!
12:12 < ryanofsky> i think we should just get rid of the concept of default wallet
12:13 < wumpus> ryanofsky: on the long run, yes, but that's no option for 0.15
12:13 < luke-jr> ryanofsky: definitely not in 0.15
12:13 < kanzure> what about, if more than one wallet, then default wallet must be explicitly specified
12:13 < ryanofsky> if there's more than one wallet, it should just be an error not to specify a wallet
12:13 < wumpus> let's focus on what we want to do now
12:13 < luke-jr> then you break all existing sw
12:13 < wumpus> I think for 0.15 we should simply do the endpoint-based interface
12:13 < ryanofsky> we can do that right now
12:13 < gmaxwell> wumpus: what do you think about the concern that the endpoint stuff establishes a new API that we'll be stuck supporting but haven't given much thought to?
12:13 < ryanofsky> no need to wait
12:13 < sipa> i think as an end goal, endpoint-based selection is awesome, because it prepares for process separation
12:13 < wumpus> gmaxwell: the same is true for any RPC change
12:13 < jonasschnelli> gmaxwell: we can mark it unstable?
12:14 < jonasschnelli> v1 == unstable?
12:14 < jonasschnelli> use / (v0) if you want stability
12:14 < sipa> but if endpoints can't for example remove the non-wallet RPCs, that's sort of not really achieving that goal anyway
12:14 < wumpus> gmaxwell: adding an argument to every wallet RPC call is also such a massive change
12:14 < sipa> wumpus: with named args it's trivial, no?
12:14 < jonasschnelli> I can work on splitting the RPC calls in wallet / nonwallet
12:14 < gmaxwell> (I don't have strong opinions, just raising it)
12:14 < jonasschnelli> if we agree on endpoints
12:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
12:14 < ryanofsky> wumpus, are you saying 10661 is a massive change?
12:14 < sipa> and it shouldn't be adding it to every RPC; just catch it in the rpc handler
12:14 < wumpus> but the point is that it'd be something that has to be supported virtually forever
12:14 < luke-jr> (only supporting the default wallet, per rpcauth user, seems the best for backward/forward compatibility still)
12:14 < wumpus> and imo it's poorly thought out
12:15 < wumpus> but I don't care deeply
12:15 < wumpus> at this point we should simply make a choice
12:15 < wumpus> if we don't make a choice today and stick with it
12:15 < gmaxwell> I don't really think named arguments is a great thing. It would make support easier in some software in the short term.
12:15 < wumpus> we can forget multiwallet for 0.15
12:15 < jonasschnelli> ack!
12:15 < gmaxwell> I think every criticism wumpus has on that one is spot on.
12:15 -!- str4d [~str4d@c-24-218-248-188.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds]     
12:15  * luke-jr suggests rpcauth-based default wallet, and we can figure out endpoints for 0.16
12:16 < wumpus> gmaxwell: indeed - most RPC client libraries don't even support named arguments yet
12:16 < luke-jr> that gives more time to think out API change
12:16 < wumpus> gmaxwell: while changing the endpoint is easy, just change the URI
12:16 < wumpus> luke-jr: please don't bring back a third option
12:16  * BlueMatt always kinda assumed named args would allow us to add things like multiwallet/different number precision/etc in the future, as a simple add-on to every RPC without any massive code change everywhere
12:16 < wumpus> luke-jr: that's not going to make it easier
12:16 < BlueMatt> but, ok
12:16 < kanzure> luke-jr: are wallets assigned per rpcauth user already?
12:17 < jonasschnelli> no     
12:17 < wumpus> no     
12:17 < kanzure> uh..
12:17 < BlueMatt> guess I had a different impression than everyone else, then
12:17 < luke-jr> kanzure: there is no way to use multiwallet right now
12:17 < wumpus> BlueMatt: it's possible, and not hard to implement, but just not the right choice for this IMO
12:17 < jonasschnelli> What about using v1/wallet/y<filename> and mark it unstable (experimental?) for 0.15?
12:17 < ryanofsky> BlueMatt, that was my impression too, it's the basis for 10661 & 10653
12:18 < jonasschnelli> -y     
12:18 < sipa> i officially no longer have an opibion on approach
12:18 < wumpus> jonasschnelli: sounds good to me
12:18 < BlueMatt> ok, I mean I dont have a very strong impression, i just always thought that seemed natural
12:18 < luke-jr> wumpus: we should have a per-user default wallet *regardless* of the other options; merging it first is a clean way to defer choosing between the others
12:18 < BlueMatt> but, really, can we flip a coin?
12:18 < sipa> 
12:18 < wumpus> let's just go with endpoints for now
12:18 < jonasschnelli> Somone disagree?
12:18 < midnightmagic> how the heck did you send a blank line
12:18 < jonasschnelli> Anyone
12:19 < gmaxwell> I think we could say that the endpoint version totally unstable and will change to answer the concern that we're setting an api there premately. 
12:19 < wumpus> if no one cares deeply, let's just stick with the decision of a few weeks ago
12:19 < instagibbs> gmaxwell, ack
12:19 < jonasschnelli> gmaxwell: we could mark the whole multiwallet (incl. endpoint) as experimental in 0.15
12:19 < jonasschnelli> And stable in 0.16
12:19 < wumpus> midnightmagic: that wasn't a blank line, it as \x7f characters 
12:19 < wumpus> gmaxwell: yes, multiwallet is unstable in 0.15, +1
12:19 < wumpus> gmaxwell: there's probably quite some things that need to change, still
12:19 < morcos> no opinon on the issue, but ACK on making a decision.
12:20 < jonasschnelli> ryanofsky: could you live with the endpoint solution?
12:20 < gmaxwell> I think in general we should get into a practice of new API's being explicitly unstable in their first release. We've mulliganed quite a few times.
12:20 < wumpus> gmaxwell: yes
12:20 < ryanofsky> of course, yeah
12:21 < jonasschnelli> okay. Let me finish the endpoint PR and hope it will make it into 0.15
12:21 < wumpus> jonasschnelli: great!
12:21 < jonasschnelli>   /topic
12:21 < wumpus> ryanofsky: thanks
12:21 < luke-jr> jonasschnelli: can you do it on top of 7b73f24311639fdc79c22608c21e4bfcbc6d4243 ?
12:22 < jonasschnelli> pr #?
12:22 < wumpus> any other topics?
12:22 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
12:22 < wumpus> remember morcos was saying something about fee PRs, but not sure it was aimed as a topic
12:22 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev     
12:22 < sipa> wifi just fied in the BS office
12:22 < luke-jr> jonasschnelli: it's part of #10615
12:22 < gmaxwell> I just want to say that master continues to be mostly awesome and performing great. I'm really excited about this next release. (esp if we get our act togeather on multiwallet) :)
12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
12:23 < luke-jr> https://github.com/bitcoin/bitcoin/pull/10615/commits/7b73f24311639fdc79c22608c21e4bfcbc6d4243
12:23 < wumpus> gmaxwell: yeah!
12:23 < jonasschnelli> luke-jr: 7b73f24311639fdc79c22608c21e4bfcbc6d4243 pollutes server.h with CWallet... :/
12:23 < jonasschnelli> (later)
12:23 < BlueMatt> there are a bunch of fee PRs which I think are very useful, and we should try desperately to make progress on them for 15
12:23 < gmaxwell> So yes, there are a number of fee/change handling PRs which are urgent for 0.15.
12:23 < morcos> yeah i don't really have a topic, but i need some review
12:23 < morcos> some are bug fixes
12:23 < gmaxwell> But I don't know what to say beyond that since they're already on the high prio list.
12:23 < wumpus> #topic fee PRs
12:23 < morcos> some are RPC api finalization which would be good to get right
12:24 < jonasschnelli> another topic proposal could be: txoutsbyaddress (it's marked with the 0.15 milestone)
12:24 < morcos> I'm not sure if I broke it up in the easiest way possible for review, but am hesitant to try to reorganize this late in the game...
12:24 < wumpus> jonasschnelli: bleh, server.h should definitely not get a CWallet reference, it's meant to be not specific to bitcoin, let alone wallet
12:25 < jonasschnelli> wumpus: yes. I think the same
12:25 < luke-jr> wumpus: jonasschnelli: I don't see a better alternative.
12:25 < morcos> sounds like jonasschnelli also has his hands full with multiwallet and i think it would have been nice to get access to longer fee estimates in the GUI
12:25 < luke-jr> (keep in mind not all calls will come from the RPC server)
12:25 < morcos> but seems like that is not going to happen
12:25 < jonasschnelli> luke-jr: https://github.com/bitcoin/bitcoin/pull/10650/files#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR36
12:26 < wumpus> luke-jr: there are certainly alternatives, more general ways to attach custom data to a structure, but let's leave this for another time
12:26 < gmaxwell> morcos: oh the gui doesn't have access to the new estimates?  thats unfortunate.
12:26 < gmaxwell> I guess I need to do some gui testing, haven't used it in a while.
12:26 < morcos> gmaxwell: no
12:26 < bitcoin-git> [bitcoin] ryanofsky closed pull request #10661: Add optional wallet=filename arguments to wallet RPCs (master...pr/multiopt) https://github.com/bitcoin/bitcoin/pull/10661
12:26 < jonasschnelli> gmaxwell: just not the conf target > 26+
12:26 < luke-jr> jonasschnelli: that doesn't work for GUI or tests
12:26 < morcos> no way to ask for non-conservative.  but at least after one of my PR's it'll default to that if tx is replaceable
12:26 < luke-jr> anyhow, later..
12:26 < jonasschnelli> non-conservative would be simple (a checkbox?)
12:27 < jonasschnelli> a slider with fix positions make little sense... sliders are ment to be linear
12:27 < jonasschnelli> A dropdown could make more sense
12:27  * luke-jr likes dropdown
12:27 < morcos> jonasschnelli: yes sort of.  the way it is implemented elsewhere is it defaults to the opposite of opt in rbf, but you coudl force it either way
12:27 < luke-jr> "ASAP", "today", "this week", "eventually"
12:28 < jonasschnelli> luke-jr: names tend to bikeshed... but at least "conf-target in block  |  time"
12:28  * luke-jr shrugs
12:28 < jonasschnelli> Or maybe "time | blocks | feerate"
12:28 < jonasschnelli> Ideally we would run coinselection when opening the dropdown to tell the (possible) absolute fee
12:29 < morcos> jonasschnelli: please no
12:29 < morcos> feerate selection first
12:29 < morcos> then coin selection 
12:29 < jonasschnelli> heh.. I though somebody will complain. :)
12:29 < achow101> coin selection needs fee rate..
12:29 < gmaxwell> we can't realistically do that. We need the feerate to perform selection.
12:29 < morcos> in the future coin selection may be different depending on feerate anyway
12:29 < gmaxwell> (and will need it more in the future)
12:29 < jonasschnelli> gmaxwell: do it for all options ... *duck*
12:29 < luke-jr> >_<     
12:29 < luke-jr> coin selection can be slow, unless that's been optimised
12:30 < jonasschnelli> Thoughs about the dropbox?
12:30 < sipa> "The next Bitcoin-Qt version requires a 4k screen for coin selection"
12:30 < morcos> in any case, i think _something_ simple would be ideal so users have access to longer than 25 confirms
12:30 < BlueMatt> lol     
12:30 < gmaxwell> jonasschnelli: well we'd like to be able to do good selections which won't be instant. thats something that could be expiremented with later.
12:30 < jonasschnelli> I'm happy to do it if it's general accaptable (the dropbown)
12:30 < BlueMatt> sipa: ooo, I have those, sounds gogod!
12:30 < BlueMatt> good
12:31 < gmaxwell> well we do want multiple near term options because of market effects.  e.g. 2,3,4,5,6,72,today,two days, three days, five days, 1 week... or something.
12:31 < jtimon> what about a box with number of blocks instead of a dropbox ?
12:31 < morcos> jonasschnelli: sure. something, anything.  but recommend you build off my other PR #10706
12:31 < gribble> https://github.com/bitcoin/bitcoin/issues/10706 | Improve wallet fee logic and fix GUI bugs by morcos · Pull Request #10706 · bitcoin/bitcoin · GitHub
12:31 < jonasschnelli> I'll try the dropdown and see how it feels.. should not be that hard
12:31 < jtimon> er dropdown
12:31 < jonasschnelli> morcos: will do
12:31 < sipa> do we have to do GUI design in this meeting?
12:31 < luke-jr> XD     
12:31 < Murch> gmawell, it could estimate with a blocktarget of ~6 and do that before the window opens? ;)
12:31 < morcos> no i was just hoping for someone else to volunteer since seems jonas has a lot to do
12:32 < Murch> or whatever the default is nowaays
12:32 < morcos> and 0.15 is fast approaching
12:32 < gmaxwell> sipa: that wasn't GUI design, quite the opposite, there are economic reasons that gui clumping people wouldn't be great.
12:32 < luke-jr> I could give it a shot, I guess.
12:32 < jonasschnelli> luke-jr: I just started... :)
12:32 < luke-jr> heh     
12:32 < morcos> either or, i'll let you guys work it out, but i'm bad at gUI, but i did make several changes already in the prior PR.   thanks!!
12:33 < wumpus> #topic txoutsbyaddress (it's marked with the 0.15 milestone)
12:33 < wumpus> I think we should remove that milestone
12:34 < gmaxwell> Sadly. Has anyone been working on it?
12:34 < wumpus> #9806  has been quite inactive
12:34 < gribble> https://github.com/bitcoin/bitcoin/issues/9806 | txoutsbyaddress index (take 3) by droark · Pull Request #9806 · bitcoin/bitcoin · GitHub
12:34 < jonasschnelli> I'm more interested about should we or or not add an index for that
12:34 < wumpus> not publicly at least
12:34 < jonasschnelli> The best index implementations is currently the one from Bitpay,.. not?
12:34 < gmaxwell> jonasschnelli: I think we should; unlike many other things it's actually sustainable.
12:34 < jonasschnelli> I tend to also think we should
12:35 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
12:35 < jonasschnelli> (after installed a BWS index)
12:35 < gmaxwell> the bitpay index stuff is utterly unmaintable and borderline abandonware; fwiw.
12:35 < jtimon> why not by scriptpubkey ? that seems more generic
12:35 < sipa> there is some indexd project
12:35 < jonasschnelli> The most stables index I could find so far is that one: https://github.com/bitcoin/bitcoin/pull/10370
12:35 < gmaxwell> jtimon: yes, I think that was suggested on the PR.
12:35 < instagibbs> dcousens has an external index project which I think sipa is referring to
12:35 < jonasschnelli> (it's the one BWS [Bitpay wallet service] is unsing in the fileld since a couple of years)
12:36 < gmaxwell> jonasschnelli: the UTXO indexes are special because they actually have viable scalablity...
12:36 < sipa> https://github.com/bitcoinjs/indexd
12:36 < gmaxwell> I think anyone depending on complete blockchain indexes will eventually be forced onto centeralized servers, unfortunately.
12:37 < gmaxwell> so I have much less interest in internal support (hooks for external things sound fine though)
12:37 < jonasschnelli> Agree. Maybe internal txoutsbyaddress and for the rest, use something like indexd that sipa mentioned 
12:38 < instagibbs> https://github.com/bitcoinjs/indexd
12:38 < wumpus> UTXO indexes would be nice, I'd love to have more query functionality for the UTXO set, we have to track that anyway with a full node
12:38 < jcorgan> i've taken to using zmq to notify of new txes/blocks and the REST API to retrieve parsed info about them, for indexing externally
12:38 < morcos> I've got to run, but someone please tag #10557 #10589 #10707 #10712 for 0.15  
12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/10557 | Make check to distinguish between orphan txs and old txs more efficient. by morcos · Pull Request #10557 · bitcoin/bitcoin · GitHub
12:38 < jonasschnelli> I guess one reason why some of the centralized services (like the BWS) still is based on 0.12.1 is because the indexes where never added to Core master branch
12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/10589 | More economical fee estimates for RBF and RPC options to control by morcos · Pull Request #10589 · bitcoin/bitcoin · GitHub
12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
12:39 < wumpus> huh what is gribble doing
12:39 < gmaxwell> wumpus: right. also if ever we support having pruned wallets (wallets that don't know their full history, but do have their full coins), the txout index is something we need for it... but not other indexes.
12:39 < wumpus> oh sure morcos
12:39 < morcos> (sorry)
12:39 < wumpus> gmaxwell: yes!
12:39 < jonasschnelli> tagged
12:39 < jonasschnelli> gmaxwell: yes. For HD restores in pruned env. the utxo index is handy
12:39 < wumpus> gmaxwell: would be very niec to instantly query the balance, if history isn't important
12:40 < gmaxwell> rescan has become so slow for me at least that I'm kinda desperate for something like that.
12:40 < gmaxwell> I've lost days of time waiting on rescans.
12:41 < wumpus> next topic?
12:42 < sipa> nope.
12:42 < gmaxwell> wumpus: can you remind me of the 0.15 schedule?
12:42 < luke-jr> eh, UTXO isn't a substitute for rescanning.. you'd miss historical txs
12:42 < BlueMatt> #9961
12:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9961 | Release schedule for 0.15.0 · Issue #9961 · bitcoin/bitcoin · GitHub
12:42 < gmaxwell> luke-jr: thus pruned wallet, ... it's fine to not have historical txs if you know you don't. 
12:43 < gmaxwell> BlueMatt: thanks!
12:43 < wumpus> luke-jr: what if you don't care about history, and just want balance + possibly spending?
12:43 < BlueMatt> T-10 days to branch
12:43 < luke-jr> gmaxwell: but you'd end up with *some* historical tx in this case, with no deterministic reason why some are missing
12:43 < gmaxwell> luke-jr: you can also say that txes found on the blockchain aren't a replacement for having their metadata... :)
12:43 < luke-jr> I suppose we could import them as all change-only or something? :/
12:43 < jonasschnelli> luke-jr: you can scan in the background for the history in a very slow manner once you have done it via the UTXO set index
12:43 < wumpus> BlueMatt: no, not to branch, to feature freeze
12:43 < sipa> wumpus: it'd be incompatible with hardware wallets, before segwit
12:43 < luke-jr> jonasschnelli: hmm, good idea
12:43 < sipa> as you need the full crediting txn
12:44 < gmaxwell> luke-jr: no you wouldn't: my suggestion is that a pruned wallet basically have a line shown in the UI where nothing is there before it except a move like ledger entry that shows the earlier balance.
12:44 < BlueMatt> oh, sorry, yes, freeze
12:44 < wumpus> BlueMatt: branch is 2017-08-06, so a month away
12:44 < gmaxwell> luke-jr: I made an issue describing some ideas for that a while back.
12:44 < luke-jr> gmaxwell: I see, makes sense
12:45 < achow101> wumpus: can #10571 and #10579 be tagged for 0.15?
12:45 < gribble> https://github.com/bitcoin/bitcoin/issues/10571 | [RPC]Move transaction combining from signrawtransaction to new RPC by achow101 · Pull Request #10571 · bitcoin/bitcoin · GitHub
12:45 < gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
12:45 < gmaxwell> There are other reasons why building such things are attractive... (e.g. UTXO based sync can't provide the data to give history...)
12:45 < wumpus> achow101: sure
12:45 < achow101> thanks
12:45 < gmaxwell> ack     
12:48 < sipa> early lunch?
12:49 < wumpus> ye fine with me
12:49 < wumpus> #endmeeting
12:49 < lightningbot> Meeting ended Thu Jul  6 19:49:54 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:49 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.html
12:49 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.txt
12:49 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.log.html
12:50 < spudowiar> Hardware wallet support rebased and now supports change addresses properly
12:50 < jtimon> so why is #8498 not to be tagged for 0.15 nor project 8 ? I want to understand the criterion
12:50 < gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
12:50 < jtimon> criteria
12:52 < wumpus> jtimon: well if others think it should be tagged 0.15 or be high priority for review it's fine with me
12:52 < spudowiar> There are a few things I need to tackle now
12:52 < spudowiar> a) How the plugin can tell whether it is Testnet or Mainnet
12:52 < wumpus> jtimon: I don't personally see it as urgent enough for that, it's an optimization without mentioning timings
12:53 < wumpus> jtimon: but that's just my opinion
12:53 < jtimon> I see, thanks
12:53 < spudowiar> b) How the plugin can show a UI? (e.g. TREZOR Pin Matrix)
12:53 < spudowiar> Maybe the plugin can just create a window itself
12:54 < wumpus> spudowiar: la) aunch it with a flag/option that specifies which block chain
12:54 < wumpus> spudowiar: b) yes, have it draw it itself
12:54 < jtimon> well, the timinigs changed over time. now acceptToMemoryPool is not as redundant in fee calculation as it sued to be, and the number of places where checkinouts have been called from has been varying as well
12:55 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
12:55 < spudowiar> c) Multiple devices (I'm going to add a device identifier parameter and a listhwwdevices method to the plugin)
12:55 < wumpus> spudowiar: or have a command askPin() from the plugin that shows a simple Qt message box with a prompt
12:55 < spudowiar> wumpus: It has a special GUI though
12:55 < spudowiar> Hence why I chose that example
12:55 < wumpus> spudowiar: if it has a special gui it should definitely draw it itself, bitcoin qt can't get into the UI delegation/embedding business
12:55 < jtimon> but there's more checkinputs calls now than when I first coded the thing
12:56 < spudowiar> d) Simplify usage (e.g. without command line parameters)
12:56 < spudowiar> This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)
12:56 < spudowiar> e) Need to test multisig
12:56 < wumpus> yes     
12:57 < spudowiar> yes to what?
12:57 < wumpus> "This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)"
12:58 < spudowiar> ok     
12:58 < jtimon> #10195 and #10192 likely changed how much of an improvement #8498 is as well
12:58 < gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
12:58 < gribble> https://github.com/bitcoin/bitcoin/issues/10192 | Cache full script execution results in addition to signatures by TheBlueMatt · Pull Request #10192 · bitcoin/bitcoin · GitHub
12:58 < gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
12:58 < spudowiar> Not going to bother with listhwwdevices for now (that would be useful for a GUI to select the hardware device)
12:59 < wumpus> jtimon: some kind of measurement would be nice, e.g. startup time with a large wallet
13:00 < wumpus> spudowiar: agreed, auto-detecting devices would be something for later
13:00 < jtimon> why a wallet? the improvements are in connectBlock and AcceptToMemoryPool
13:00 < jtimon> wumpus: specially on the latter
13:00 < wumpus> jtimon: I'm confused then - yes wallet would not be appropriate then
13:01 < spudowiar> Oh, and I need to get rid of boost::process dependency
13:01 < instagibbs> spudowiar, please do :P
13:01 < wumpus> I would first focus on functionality
13:02 < jonasschnelli> spudowiar: I think URI schema is the best option for the GUI
13:02 < spudowiar> instagibbs: Find me an alternative :) I don't know C++
13:02 < wumpus> then only when it works, on removing dependencies
13:02 < jonasschnelli> call sign://
13:02 < wumpus> too easy to get stuck in yak shaving dependencies
13:02 < jonasschnelli> or bitcoinsign://
13:02 < spudowiar> jonasschnelli: That overcomplicates things in my opinion
13:02 < instagibbs> wumpus, it's a super new module, only reason I care
13:02 < jonasschnelli> It's a clean separation... could work as a standard
13:02 < jonasschnelli> Otherwise other non-core application could not tab in
13:03 < spudowiar> jonasschnelli: How do you get the data back, anyway?
13:03 < instagibbs> I don't feel like installing it to test his work, so I've rolled my own solution until then
13:03 < spudowiar> jonasschnelli: Why can't non-Core applications use these plugins?
13:03 < jonasschnelli> Core sends: bitcoinsign://signtx?data=blabla&callback=bitcoincore
13:03 < jonasschnelli> spudowiar: you plugin would call back bitcoincore://
13:03 < sipa> why a URI...?
13:03 < spudowiar> So, Core needs to register its own protocol now?
13:03 < spudowiar> URIs are really unnecessary here
13:03 < jonasschnelli> sipa: URI is the only think that works in sandboxed env
13:04 < sipa> jonasschnelli: i don't understand
13:04 < jonasschnelli> (Android, iOS, OSX [soonish])
13:04 < sipa> ?     
13:04 < jonasschnelli> In sandboxed enviroments, interprocess communication is impossible, expect over URIs
13:04 < spudowiar> jonasschnelli: JSON-RPC is transport agnostic
13:04 < spudowiar> jonasschnelli: So you can do JSON-RPC over URI if you want, on those platforms
13:05 < spudowiar> I'd prefer not to register arbitrary protocols on my desktop though
13:05 < sipa> ok, so use some wrapper URI on those platforms
13:05 < spudowiar> Not when a perfectly suitable solution exists
13:05 < gmaxwell> what sipa said
13:05 < sipa> not as part of the IPC mechanism in general
13:05 < jonasschnelli> that makes sense....
13:06 < jonasschnelli> in my example: bitcoinsign://signtx?data=blabla&callback=bitcoincore the blabla elements could be the JSON/RPC layer 
13:06 < spudowiar> Yep     
13:06 < spudowiar> At the moment though, I require the JSON-RPC to be in roughly getrawtransaction format
13:07 < spudowiar> I want to strip parts of that out, then write documentation for the protocol
13:07 < jonasschnelli> I have a branch somewhere where the GUI can select watchonly unspents and create a hex-tx instead when signing... I once thought you may should be able to forware that unsigned hex tx (including utxos) to another app via URI-schema
13:08 < spudowiar> https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/src/wallet/wallet.cpp#L1500
13:08 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has quit [Quit: WeeChat 1.9]     
13:14 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
13:15 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Quit: mining]     
13:26 < bitcoin-git> [bitcoin] theuni opened pull request #10756: net processing: swap out signals for an interface class (master...no-net-signals2) https://github.com/bitcoin/bitcoin/pull/10756
13:27 < cfields> BlueMatt: I was holding off on ^^ because I thought it might stomp on some of your other PRs, but after taking a look, I think it might actually make your life a little easier
13:28 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:29 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
13:30 < gmaxwell> <3     
13:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
13:31 < gmaxwell> though it shows how much y'all have worn me down about C++ features that I'm cheering for inheretence. :)
13:32 < cfields> heh     
13:32 < gmaxwell> my backtraces thank you, however.
13:32 < gmaxwell> I believe this may be measurably faster too... when I ripped out signals and replaced it with direct function calls it was.
13:33 < gmaxwell> the signals stuff has thread synchronization inside it.
13:33 < cfields> yea. I should add that to the PR description.. that might actually be the nicest part of the change
13:33 < cfields> gmaxwell: yea, i've owed you this PR for months now. Sorry for the delay.
13:33 < gmaxwell> Don't worry, I didn't remember.
13:34 < cfields> heh ok
13:41 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Quit: mining]     
13:43 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
13:49 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Ping timeout: 268 seconds]     
13:54 -!- Aaronvan_ is now known as AaronvanW     
13:55 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
13:56 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
13:56 -!- Guyver2_ is now known as Guyver2     
14:12 -!- jamesob [4bbb4122@gateway/web/freenode/ip.75.187.65.34] has joined #bitcoin-core-dev     
14:13 < jamesob> any thoughts on adding a Dockerfile to the repo? might make setting up a dev environment marginally easier
14:20 -!- jamesob [4bbb4122@gateway/web/freenode/ip.75.187.65.34] has quit [Ping timeout: 260 seconds]     
14:22 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
14:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]     
14:46 -!- paracyst is now known as pex     
14:46 -!- pex is now known as paracyst     
15:17 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
15:17 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:19 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has quit [Quit: Page closed]     
15:20 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
15:23 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has joined #bitcoin-core-dev     
15:25 < stalictite> what's the armory dev irc?
15:26 < stalictite> nvm got it
15:27 -!- sanada` [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
15:28 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Ping timeout: 260 seconds]     
15:32 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
15:51 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
16:05 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:20 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 276 seconds]     
16:21 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
16:21 < bitcoin-git> [bitcoin] jtimon opened pull request #10757: RPC: Introduce getperblockstats to plot things (master...b15-rpc-plotter) https://github.com/bitcoin/bitcoin/pull/10757
16:27 < jtimon> I "had" to delete ~/.bitcoin yesterday until I learned how to cleanup things in docker (damm, should have just copied it to another disk), otherwise I could have seen the historic min fee and feerate per block that I've always wanted to see...
16:34 < jtimon> I hope it's well tested, I rarely introduce new features and didn't run the coverage thing, but I think I cover all the new code
16:35 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
16:40 < jtimon> not sure what the proper C++11 replacement for boost::split(plot_values, str_plot_values, boost::is_any_of(",")); would be
16:41 < sipa> i don't believe c++11 has a replacement for that
16:41 < jtimon> :(     
16:41 < jtimon> c++14 ?
16:41 < sipa> https://stackoverflow.com/a/5167799
16:43 < jtimon> yeah, I think the best I found was that or close to that, but it's still very ugly imo, you can still see the loop!
16:45 < jtimon> I would like a std::vector<std::string> std::string::split(std::string), like python
16:46 < sipa> you can write such a function :)
16:46 < jtimon> anyway, my build is failing to compile in some platforms, it seems univalue is not as multiplatform as I thought
16:47 < jtimon> yeah, I could write such a function and replace it everywhere I guess, instead of only using it in the new rpc function
16:48 < jtimon> oh, you mean for C++ ?
16:48 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:50 < jtimon> we don't use it all that much in bitcoin https://0bin.net/paste/p8nz4NJTOuyw622R#A-qZ020Wy3jsQcl6Py3H1KDYJkxjrO7QnCqmauzad7L but I guess that's another idea for a scripted-diff PR
16:57 < sipa> jtimon: in #10757 you're pushing a size_t into UniValue
16:57 < gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getperblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
16:57 < sipa> size_t is platform dependent
16:57 < sipa> cast it to int64_t first
16:57 < jtimon> yeah, I thought I had to use to constructor for all ints, it'sjust a simple cast
16:57 < jtimon> thanks
17:06 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
17:06 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 276 seconds]     
17:06 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10758: Fix some chainstate-init-order bugs. (master...2014-07-nonatomic-flush-fixes) https://github.com/bitcoin/bitcoin/pull/10758
17:10 < jtimon> jamesob just finally learning how to use docker on my own now. yeah, I think it could simplify development by not requiring to install the dependencies in your local system. perhaps it could help simplifying further the process for deterministic builds? maybe others prefer it on another repo, but I think it wouldn't hurt on contrib
17:11 < jtimon> in contrib
17:11 < jtimon> but I think you still need a VM for the deterministic builds...not sure
17:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:14 -!- tiagotrs [~tiago@pD9FD69F5.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
17:16 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
17:43 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has quit [Ping timeout: 260 seconds]     
17:50 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
17:53 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
17:53 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #bitcoin-core-dev     
17:54 -!- jamesob [453db302@gateway/web/freenode/ip.69.61.179.2] has joined #bitcoin-core-dev     
18:01 -!- tiagotrs_ [~tiago@pD9FD60CF.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
18:01 < jamesob> jtimon: is the need for deterministic builds obviated by the hash related to each docker image build? i.e. can we reference a single docker image in lieu of doing the vm builds?
18:01 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
18:02 < jtimon> no, I don't think docker's determinism is enough for bitcoin's deterministic builds is what I'm saying, but I'm no expert on either of them, just used them by following tutorials and reading other people's code
18:02 < jamesob> gotcha
18:03 < sipa> jamesob: i think we want to push it the other direction really... where the build becomes deterministic even when not run in any controlled environment
18:03 < sipa> (apart from compiler versions)
18:03 < jamesob> sipa: yeah, makes sense... relying on a single trusted image is probably the counterpoint to the purpose of the build process :)
18:04 -!- tiagotrs [~tiago@pD9FD69F5.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]     
18:04 < sipa> jamesob: exactly
18:04 < jtimon> right, the point is everyone creating the same image on their own
18:04 < sipa> jamesob: and it's already the case for the OSX build pretty much (as it builds the compiler etc as part of the build process)
18:05 < jamesob> ah interesting
18:06 < jtimon> my doubt was if docker could maybe remove the need for a VM
18:06 < sipa> isn't docker effectively creating a VM?
18:06 < sipa> (/me docket noob)
18:06 < jamesob> I think there may be promise there... running a single container is less memory consumptive than, say, virtualbox afaik
18:07 < jamesob> and certainly much faster for anyone who has the docker daemon already running
18:07 < sipa> no need for virtualbox
18:07 < jtimon> I mean, in the deterministic build tutorial for bitcoin, which I found easy to follow, you are required to create a debian vm
18:08 < jtimon> perhaps that's just good habit, but it looked like a requirement
18:08 < sipa> sure, because that's easiest to make sure the environment matches
18:08 < sipa> but you can just use typical desktop linux environments as host
18:08 < jtimon> well, that's where I wonder if docker could simplify things
18:09 < sipa> i'm sure it can simlify things
18:09 < sipa> but i'm questioning how it could replace the need for a VM... when (afaik) it internally runs things in a VM
18:09 < jtimon> just use debian:jessie container or something
18:09 < jamesob> jtimon right
18:10 < jamesob> sipa docker is almost closer to a chroot than a VM IMO
18:11 < sipa> jamesob: so is LXC
18:11 < sipa> gitian right now has no need for a VM anywhere
18:11 < jamesob> yep -- I think docker used to ride on top of LXC; think they may have ditched it recently
18:11 < jamesob> gotcha
18:12 < sipa> the instructions tell you to create a debian VM because that's an easy way to get a system in a simple to describe state
18:12 < sipa> so if you can simplify that process with docker, feel free
18:13 < jamesob> cool, I'll take a look
18:13 < sipa> but at this point, i think can't avoid gitian
18:14 < sipa> so you'd describe some docker system in which gitian can be run
18:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
18:15 < jtimon> jamesob: yeah, if you modify the gitian guide to use docker instead of a VM and hopefully having to copy and paste less things I will be more than happy to try it locally
18:16 < jtimon> https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md 
18:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
18:17 -!- jamesob [453db302@gateway/web/freenode/ip.69.61.179.2] has quit [Ping timeout: 260 seconds]     
18:17 < jtimon> mhmm, "LXC, see also Gitian host docker container[ https://github.com/gdm85/tenku/blob/master/docker/gitian-bitcoin-host/README.md ] .
18:18 < jtimon> perhaps that last link is what we're talking about and it's already done? then why the VM ?
18:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nueqomslgqulspku] has quit [Quit: Connection closed for inactivity]     
18:48 < grubles> i think that is out of date (2015). i tried following it the other day and it seems some of the scripts are maybe in the wrong directories? (https://github.com/gdm85/tenku/blob/master/docker/gitian-bitcoin-host/scripts/spawn-gitian-bitcoin-host.sh in particular 404s as it is in the wrong dir)
18:57 -!- tiagotrs_ [~tiago@pD9FD60CF.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]     
19:06 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10759: Fix multi_rpc test for hosts that dont default to utf8 (master...2017-07-fix-mult-rpc-test) https://github.com/bitcoin/bitcoin/pull/10759
19:40 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
19:42 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
19:43 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
19:45 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
19:50 -!- stevenroose [~steven@vps.weuste.club] has quit [Ping timeout: 255 seconds]     
19:51 -!- Lauda_ [~quassel@2a06:8ec0:3::1:b224] has quit [Quit: No Ping reply in 180 seconds.]     
19:52 -!- Lauda_ [~quassel@2a06:8ec0:3::1:b224] has joined #bitcoin-core-dev     
19:53 -!- stevenroose [~steven@vps.weuste.club] has joined #bitcoin-core-dev     
20:04 -!- arowser [~quassel@45.32.248.113] has quit [Remote host closed the connection]     
20:10 -!- arowser [~quassel@45.32.248.113] has joined #bitcoin-core-dev     
20:11 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]     
20:16 -!- florpadorp [~florp@c-76-121-138-167.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]     
20:22 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
20:24 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Quit: Leaving]     
21:16 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
21:21 -!- Guest2_ [~textual@2601:14d:8701:d6a0:54dd:b100:b9f6:ad84] has joined #bitcoin-core-dev     
21:25 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
21:31 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
21:34 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
21:41 -!- Guest2_ [~textual@2601:14d:8701:d6a0:54dd:b100:b9f6:ad84] has quit [Quit: Textual IRC Client: www.textualapp.com]     
21:56 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
22:08 -!- harrymm [~wayne@125-227-200-195.HINET-IP.hinet.net] has quit [Ping timeout: 248 seconds]     
22:09 -!- harrymm [~wayne@125-227-200-195.HINET-IP.hinet.net] has joined #bitcoin-core-dev     
22:14 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: lp0 on fire]     
22:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
22:31 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
22:32 -!- echonaut5 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
22:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
23:08 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kmenyeyxxngqrueo] has joined #bitcoin-core-dev     
23:20 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has quit [Ping timeout: 246 seconds]     
23:35 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev     
23:36 -!- phantomcircuit [~phantomci@192.241.205.97] has quit [Ping timeout: 240 seconds]     
23:37 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 240 seconds]     
23:38 -!- kcud_dab [~arthur@area51.powaaa.com] has quit [Ping timeout: 255 seconds]     
23:38 -!- Anduck [~Anduck@unaffiliated/anduck] has quit [Ping timeout: 240 seconds]     
23:38 -!- bad_duck [~arthur@2001:bc8:c087:1001::1] has joined #bitcoin-core-dev     
23:38 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev     
23:38 -!- bitbee [~bitbee@138.197.209.248] has quit [Ping timeout: 240 seconds]     
23:39 -!- rabidus [~rabidus@uhiainen.com] has quit [Ping timeout: 240 seconds]     
23:39 -!- Anduck [~Anduck@unaffiliated/anduck] has joined #bitcoin-core-dev     
23:40 -!- rabidus [~rabidus@uhiainen.com] has joined #bitcoin-core-dev     
23:40 -!- bitbee [~bitbee@138.197.209.248] has joined #bitcoin-core-dev     
23:45 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev