--- Day changed Thu May 04 2017 00:12 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:18 -!- tw2006 [~tw2006@2601:187:8480:2770:b496:b36c:e6f2:e346] has joined #bitcoin-core-dev 00:22 -!- tw2006 [~tw2006@2601:187:8480:2770:b496:b36c:e6f2:e346] has quit [Ping timeout: 246 seconds] 00:28 < jonasschnelli> wumpus: Re multiple tx-row-entries after a Qt bump: https://github.com/bitcoin/bitcoin/pull/9697#issuecomment-298339022 00:29 < jonasschnelli> At the moment, list transactions has the same behavior, though you can see conflicts there. 00:29 < jonasschnelli> Not sure how we should "solve" that in Qt... 00:29 < jonasschnelli> I think I once had a PR that marked conflicted tx with a special color (maybe orange or something) 00:30 < jonasschnelli> Or should we hide them completely (only the own bump conflicts) 00:30 < jonasschnelli> ? 00:36 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds] 00:36 -!- mol [~molly@unaffiliated/molly] has quit [Remote host closed the connection] 00:36 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 00:42 -!- aantonop [~aantonop@122-57-23-131.jetstream.xtra.co.nz] has joined #bitcoin-core-dev 00:47 -!- aantonop [~aantonop@122-57-23-131.jetstream.xtra.co.nz] has quit [Quit: leaving] 00:48 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 00:52 < wumpus> jonasschnelli: the problem is that the transactions are only marked after a restart IMO 00:53 < wumpus> not so much the marking itself 00:54 < jonasschnelli> wumpus: Hmm.. you mean the opacity change, right? 00:55 < jonasschnelli> Yes. The opacity is only changes after restart,... though, that's solvable. 00:55 < wumpus> jonasschnelli: or how the amounts are shown (e.g. [] around it) 00:55 < jonasschnelli> In a follow up PR we could introduce a new icon like this: https://github.com/bitcoin/bitcoin/pull/7826#issuecomment-220644102 00:55 < jonasschnelli> Ah.. yes. the [] is also part of it. Will fix that now 00:58 < wumpus> yeah :) 01:00 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 246 seconds] 01:02 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 01:18 < wumpus> I don't understand why we'd need *yet another* workaround for getentropy on linux 01:18 < wumpus> man if it's really that difficult let's just use /dev/urandom and give this up 01:19 -!- tw2006 [~tw2006@2601:187:8480:2770:e1bc:db63:a2ed:3cef] has joined #bitcoin-core-dev 01:22 < jonasschnelli> wumpus: Agree. If /dev/urandom is not reliable, your OS is not and thus, getentropy doesn't give much more value... or do I misinterpret this? 01:22 < wumpus> well the idea is that it can be run in a jail/container without /dev 01:23 < jonasschnelli> I see... 01:23 < wumpus> it's not so much that the syscall is more reliable (though that may be the case) but that it's always available (if the OS happens to have it avaiable...) 01:23 -!- tw2006 [~tw2006@2601:187:8480:2770:e1bc:db63:a2ed:3cef] has quit [Ping timeout: 245 seconds] 01:24 < wumpus> I just don't see the point in a getentropy() implementation that reads /dev/iurandom anyway 01:24 < wumpus> we already have a function for that 01:24 < wumpus> this is getting way more complicated than I imaginedc 01:37 -!- JackH [~laptop@79.73.191.98] has joined #bitcoin-core-dev 01:38 -!- harrymm [~wayne@104.237.91.228] has joined #bitcoin-core-dev 01:44 -!- mturquette [sid66043@gateway/web/irccloud.com/x-mhwhvqovdklpxfrv] has quit [] 01:44 -!- mturquette [sid66043@gateway/web/irccloud.com/x-yrrntglvamfpvbig] has joined #bitcoin-core-dev 01:46 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 01:52 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 02:11 -!- elkalamar_ [~elkalamar@84.126.69.179] has joined #bitcoin-core-dev 02:11 -!- elkalamar [~elkalamar@84.126.69.179.dyn.user.ono.com] has quit [Read error: Connection reset by peer] 02:11 -!- twistedline_ [~quassel@unaffiliated/twistedline] has quit [Ping timeout: 258 seconds] 02:13 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:16 -!- twistedline [~quassel@unaffiliated/twistedline] has joined #bitcoin-core-dev 02:19 -!- tw2006 [~tw2006@2601:187:8480:2770:e482:8822:5b01:d9c6] has joined #bitcoin-core-dev 02:24 -!- tw2006 [~tw2006@2601:187:8480:2770:e482:8822:5b01:d9c6] has quit [Ping timeout: 260 seconds] 02:45 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Ping timeout: 260 seconds] 03:07 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev 03:14 -!- nejon [uid38993@gateway/web/irccloud.com/x-erkbptjtxgfiacrs] has quit [] 03:15 -!- nejon [uid38993@gateway/web/irccloud.com/x-cwhzldtvlzfesari] has joined #bitcoin-core-dev 03:20 -!- tw2006 [~tw2006@2601:187:8480:2770:b508:6aa7:9220:e46b] has joined #bitcoin-core-dev 03:25 -!- tw2006 [~tw2006@2601:187:8480:2770:b508:6aa7:9220:e46b] has quit [Ping timeout: 246 seconds] 03:31 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 03:38 -!- face [~face@mail.hmel.org] has quit [Ping timeout: 240 seconds] 03:44 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 04:10 -!- tw2006 [~tw2006@2601:187:8480:2770:fcb8:1655:8822:3ffd] has joined #bitcoin-core-dev 04:18 < bitcoin-git> [bitcoin] snvakula opened pull request #10336: Get actual path for EUID instead of HOME dir (master...contrib) https://github.com/bitcoin/bitcoin/pull/10336 04:27 -!- jouke [~worst@unaffiliated/komkommer] has quit [Ping timeout: 255 seconds] 04:55 -!- tw2006 [~tw2006@2601:187:8480:2770:fcb8:1655:8822:3ffd] has quit [Read error: Connection reset by peer] 04:56 -!- tw2006 [~tw2006@2601:187:8480:2770:fcb8:1655:8822:3ffd] has joined #bitcoin-core-dev 05:10 -!- tw2006 [~tw2006@2601:187:8480:2770:fcb8:1655:8822:3ffd] has quit [Read error: Connection reset by peer] 05:11 -!- tw2006 [~tw2006@2601:187:8480:2770:fcb8:1655:8822:3ffd] has joined #bitcoin-core-dev 05:14 * jonasschnelli wishes a special IDE editing mode where editing a line directly amend edits & rebase and older commit 05:23 -!- harrymm1 [~wayne@104.237.91.147] has joined #bitcoin-core-dev 05:23 -!- harrymm1 [~wayne@104.237.91.147] has quit [Max SendQ exceeded] 05:24 -!- harrymm1 [~wayne@104.237.91.147] has joined #bitcoin-core-dev 05:25 -!- harrymm [~wayne@104.237.91.228] has quit [Ping timeout: 260 seconds] 05:35 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 05:58 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev 05:59 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Remote host closed the connection] 06:00 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev 06:06 -!- marcoagner [~user@177.41.192.53] has quit [Ping timeout: 264 seconds] 06:19 -!- marcoagner [~user@177.41.200.138] has joined #bitcoin-core-dev 06:21 < jonasschnelli> morcos: ping re mempool stats: https://github.com/bitcoin/bitcoin/pull/8501#issuecomment-270714233 06:22 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 06:23 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 260 seconds] 06:25 < jonasschnelli> morcos: Would you say it makes sense to keep a singe samples vector and add fixed time-limits for sample frequency and purge out in-between values? Example: we add a sample whenever the mempool has changed while respecting a min delta of 2s, == no extra thread required. 06:25 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 06:26 < jonasschnelli> Then, during the cleanup (every 100 samples or so), we purge out in-between samples to ensure a min-frequency of, say, delta 30s for samples older then 2h (TBD) 06:26 < jonasschnelli> same for older then 24h (maybe ensure a min-delta of 2min), etc. 06:27 < jonasschnelli> The question then is, if we should interpolate fix time steps during cleanup/purge. Because the samples may be distributed "randomly" over time. 06:30 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 06:34 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 255 seconds] 06:34 -!- harrymm1 [~wayne@104.237.91.147] has quit [Remote host closed the connection] 06:35 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 06:35 -!- harrymm [~wayne@104.237.91.147] has joined #bitcoin-core-dev 06:35 -!- harrymm [~wayne@104.237.91.147] has quit [Max SendQ exceeded] 06:36 -!- harrymm [~wayne@104.237.91.147] has joined #bitcoin-core-dev 06:39 < morcos> jonasschnelli: that seems considerably messier to me than keeping several samples vectors (one for each time scale we might care about) and only recording a data point in the appropriate vector if its time to. i don't think that requires any extra thread either (althgough its not clear that it wouldn't be better in a separate thread) 06:39 < morcos> periodic cleanup just seems weird 06:40 < jonasschnelli> morcos: Separate vectors would require move samples from one to another vector... though not sure if this bad or good. :) 06:40 < morcos> i think the lack of precision in recording the data point at exactly the right time is just something i would ignore witht he exception of if we miss a sample period entirely we should do some sort of filling in 06:40 < morcos> i don't understand that 06:41 < morcos> every 2 seconds record in the short vector.. on the 60th second add the same sample point to the short vector and the medium vector at the same time.. on the hour add to all 3 06:41 < morcos> there is some very small data duplication, but no moving, cleaning or reorganizing 06:41 < jonasschnelli> Oh. Yes. I overcomplicated. 06:42 < jonasschnelli> Yes. Some duplication.. but I guess that okay. 06:42 < morcos> very little 06:42 < jonasschnelli> Yeah. Use shared pointers *duck* 06:43 < jonasschnelli> About the periodic cleanup: 06:43 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:43 < jonasschnelli> I though calculating the dynamic allocation on each added sample seems a bit to expansive,.. that's why I added the periodic check 06:43 < jonasschnelli> But if we have fixed timespans with a thread, then this can be solved simpler. 06:44 < jonasschnelli> Though I wanted to avoid grabbing the cs_mempool to calculate the dynamic mempool size, etc. 06:45 < jonasschnelli> Stats could then have an more significan impact on the mempool performance then with "passive collecting" 06:47 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 268 seconds] 06:50 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 06:50 < sipa> wumpus: presumably his configure did not detect getrandom (old kernel headers?), but did detect getentropy? 06:52 < morcos> jonasschnelli: you could cache the latest value for things that were being calculated anyway, and then only record it on the periodic sample 06:53 < morcos> but i'm not sure what you mean about the dynamic allocation for the added sample.. i'm assuming that at least for the smaller time scales you're going to have a limited time span for which you keep samples.. like just a recent buffer of the last couple hours at 2 sec sample periods or something.. so it seems like it should not really require much allocation 06:54 < morcos> anyway.. i'm happy to revisit it in a week or so.. but i'm mostly out of the office this week.. so just trying to keep head above water 06:55 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds] 06:56 < jonasschnelli> What I meant is the check against the set max memory size for the stats.... say someone has set 10MB as max memory for stats then you have to know when you overshoot it. Not sure if vector-size * sizeof(sample) and cutoff the unnecessary samples is very expansive... I though doing it every 100-added sample makes sense. 06:57 < jonasschnelli> morcos: Yes. No hurry... I'll ping you once I have more... 06:57 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 06:58 < morcos> jonasschnelli: yeah i was imagining you initially just calculate how many samples you're going to get to keep given their memory max and then have a ring buffer, but you coudl do it many ways.. personally i think its kind of an over configuration option. i'd have a -stats=0 option to save the memory, but then otherwise everyone gets whatever the default memory usage we think makes sense. not everything has to be con 06:59 < jonasschnelli> Yes. fair enough... thanks for your inputs 07:03 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 07:06 < sipa> wumpus: we don't need another wrapper around urandom though; only a weak alias to a function that always returns ENOSYS, and a change in GetOSEntropy that falls back to GetDevURandom in case getentropy fails 07:06 < sipa> wumpus: or, alternatively, just never use getentropy on Linux 07:13 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 07:14 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 07:16 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:18 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds] 07:23 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 07:28 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 07:44 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev 07:45 -!- str4d [~str4d@27.110.123.92] has quit [Ping timeout: 260 seconds] 07:49 -!- resi [~ident@ool-182ffabc.dyn.optonline.net] has joined #bitcoin-core-dev 07:56 -!- talmai [~T@216.200.123.162] has joined #bitcoin-core-dev 07:59 < wumpus> sipa: not using getentropy on linux would make sense, after all there is a specific syscall handling for thatt 07:59 * wumpus is probably not going to make today's meeting, can anyone else chair please? 08:06 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 08:06 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Max SendQ exceeded] 08:09 < BlueMatt> jonasschnelli: how is #10238 intended to interact with #10235? It looks like it was designed to be complementary, but which performance improvements are you envisioning using 10238 for? 08:09 < gribble> https://github.com/bitcoin/bitcoin/issues/10238 | Change setKeyPool to hold flexible entries by jonasschnelli · Pull Request #10238 · bitcoin/bitcoin · GitHub 08:09 < gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 08:10 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:10 -!- elkalamar_ [~elkalamar@84.126.69.179] has quit [Ping timeout: 240 seconds] 08:12 -!- talmai [~T@216.200.123.162] has quit [Ping timeout: 240 seconds] 08:18 < sipa> wumpus: will do 08:21 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 08:45 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 08:48 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:49 < jonasschnelli> BlueMatt: I wrote 10238 to ensure we have a fast way to lookup CKeyIds... without this, we have to read each keypool key from the database on each SyncTransaction 08:50 < jonasschnelli> (with HD restore) 08:50 < jonasschnelli> I shouldn't conceptually conflict with your 10235 08:50 < BlueMatt> ahh, ok, i was missing the motivation part, thanks 08:51 < jonasschnelli> I though the description was good... need to check... 08:51 < BlueMatt> oh, maybe i missed that 08:51 < jonasschnelli> Currently we only keep the keypool index in memory.. the rest is database AFAIK 08:53 < morcos> wumpus: jonasschnelli: does anyone care about the QT option in Custom fee to pay "total at least"? 08:54 < morcos> I've been looking at some of these recently reported issues with transations paying too high a fee, and they seem likely to be a result of coin selection logic 08:54 < morcos> I think it might make for a cleaner redesign to make all fee calcluations in terms of fee rate and then take that into account when selecting inputs the first time around 08:55 < jonasschnelli> morcos: not sure... I'm not sure if we want this feature... 08:55 < morcos> The "total at least" option only applies to pre-selected coins anyway, but it seems like it would make for cleaner code to just dump that 08:55 < morcos> I mean why does anyone care about a minimum amount of fee, only the rate matters, its not like there is a dust issue with fees 08:56 < morcos> Another thing that might be nice to clean up, is the fact that setting Custom Fee in the GUI changes the paytxfee used by the command line, that just seems like a mistake to me, but i suppose changing that now might be a surprise to some poeple 09:02 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 240 seconds] 09:09 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 09:15 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 09:20 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 09:22 -!- Giszmo [~leo@ip-146-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 09:24 < gmaxwell> The total at least stuff makes no sense, it should go. Feerate at least, sure. Total no more than, sure. 09:31 -!- resi [~ident@ool-182ffabc.dyn.optonline.net] has left #bitcoin-core-dev [] 09:35 -!- nejon [uid38993@gateway/web/irccloud.com/x-cwhzldtvlzfesari] has quit [Remote host closed the connection] 09:35 -!- mturquette [sid66043@gateway/web/irccloud.com/x-yrrntglvamfpvbig] has quit [Remote host closed the connection] 09:35 < morcos> gmaxwell:hmm... total no more than... you mean just the existing maxtxfee? shoot.. i had forgotten about that 09:36 < morcos> i wanted to reduce each coin by the fee needed to spend it before doing coin selection, and then we could be a bit smarter about which ones we added.. 09:37 < morcos> i suppose it would make some sense to have the -maxtxfee failsafe, but maybe that is at a different place in the code 09:37 < gmaxwell> Yes, I think thats at a different place in the code. 09:38 < morcos> no its not now, but i could move it to a different place.. like repeat coin selection if your coin selection violated maxtxfee 09:38 < morcos> i want to also get rid of the knapsack solver 09:39 < morcos> if you have enough inputs that are lower than the target to reach target + CENT, just start randomly adding them until you are > target+CENT, and then you're done 09:40 < morcos> the idea that you are trying to get exactly target + CENT is stupid. target + 3.5 CENTS is just as good or whatever 09:41 < gmaxwell> getting a result with no change is also attractive, but I think that should be a seperate algorithim run first. 09:41 < morcos> gmaxwell: hmm.. i think thats rare enough that i'm not sure its worth trying to hard for 09:42 < gmaxwell> I don't think it should be, at least if we're reasonable about how much fee we'll throw away. 09:42 < morcos> its the way we do that now that is kind of causing the super high fees i think 09:42 < BlueMatt> so apparently the coin selection dialog's "received by" address is, essentially, complete gibberish 09:43 < morcos> but that is fixable while still trying to do that, for sure 09:43 -!- mturquette [sid66043@gateway/web/irccloud.com/x-efgnzgvokruzrckp] has joined #bitcoin-core-dev 09:43 < BlueMatt> and its "tree" (which I thought was supposed to group things ala listaddressgroupings) does not at all do that, and is equally useless 09:45 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds] 09:45 -!- nejon [uid38993@gateway/web/irccloud.com/x-djsgcmeryghrsetz] has joined #bitcoin-core-dev 09:48 < gmaxwell> morcos: I've tried a bit and have not managed to make it cause high fees since the changes we made to fix the fees in later passes. How confident are we that there is still an issue? 09:49 < morcos> i think its pretty plausible 09:49 < morcos> if nTotalLower is < target + CENT, then you have a decent chance of the problem happening 09:50 < morcos> once nTotalLower < target + CENT, the knapsack algorithm tries to find you exactly target 09:50 < morcos> which leads to decent chance that your change is dust 09:50 < morcos> so your change gets eliminated 09:51 < morcos> then when you callculate the fee and you need to go re-find inputs which meet target_2 (= target + fee) 09:51 < morcos> you end up choosing fewer different inputs, have a lower fee, and now no change to dump the excess fee on 09:52 < sipa> why does CENT even still occur in the algorithm? 09:53 < morcos> actually, i used to hate that, now i think its the best part of the algorithm! 09:53 < morcos> its the goal size for change, it shouldn't be an exact target, but a minimum as i mentioned above 09:53 < morcos> but it's better to have a target like that, orders of magnitude higher than dust, rather than just randomly creating change ouputs that might barely pass dust 09:54 < morcos> what's silly is that if you can't get CENT, then you aim for 0. 09:54 -!- Giszmo [~leo@ip-146-233.219.201.nextelmovil.cl] has quit [Quit: Leaving.] 09:55 -!- Giszmo [~leo@ip-146-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 09:55 < morcos> but i think the key improvement is to look at the net value of inputs in coin selection given the desired fee rate 09:56 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 09:56 < morcos> i suppose i could have written this all up first (i still will) but my idea was you'd have some sort of economic threshold such as only use inputs whose net_input_value > total_input_value/2 unless your tx confirm target > 48, then you use all inputs whos net_input_value > 0 09:56 < morcos> the current algorithm throws in stupid inputs whose net_input_value is 0 09:56 < morcos> i mean negative 09:59 < morcos> btw.. i'm probably out for the meeting today.. so if anyone has any fee estimation questions, feel free to ask before.. i'm still working through comments on PR 10:04 -!- Giszmo [~leo@ip-146-233.219.201.nextelmovil.cl] has quit [Ping timeout: 240 seconds] 10:05 -!- anthonyjd [~Anthony@2001:470:daef:e1e1:27a3:b8c8:9db:79f6] has quit [Read error: Connection reset by peer] 10:05 -!- anthonyjd [~Anthony@2001:470:daef:e1e1:27a3:b8c8:9db:79f6] has joined #bitcoin-core-dev 10:14 < gmaxwell> morcos: I'd rather two two total solutions, e.g. a change and no-change solution, and then use post selection. 10:15 < morcos> What information would you use from the change solution to make that decision? It seems to me either you find a good no-change solution or you don't? 10:19 < bitcoin-git> [bitcoin] sipa opened pull request #10338: Maintain state across GetStrongRandBytes calls (master...stateful_rng) https://github.com/bitcoin/bitcoin/pull/10338 10:21 -!- Giszmo [~leo@ip-206-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 10:21 < gmaxwell> both may be 'less than perfect', e.g. no-change might give away more than we'd like, but change may involve higher fees, so it's no better. 10:22 < gmaxwell> e.g. because the extra output increases the size, and then an extra input is needed... which increases the size further. 10:22 < gmaxwell> and so you'd prefer the no change even though it gave away more than you might normally like, because the other option was worse. 10:23 < morcos> hmm.. so my way of thinking about it, which is i thought your logic, that a solution that is 10x as big and costs 10x as much is not worse 10:23 < morcos> granted, the change output vs no change is strictly worse 10:23 < morcos> but that in my mind is a bit how you would go about figuring out whether you have an acceptable no change solution 10:23 < gmaxwell> it's true that you'll pay the fees eventually. 10:24 < gmaxwell> but then there is another angle is that our strategy should be changing if we think the feerate is 'high' for the moment, vs 'low'... in the latter we should optimize for larger transactions. 10:24 < morcos> yeah, that last part is important, but i think a complicated optimization 10:24 < morcos> maybe not ready for that yet 10:25 < morcos> i'm including a tiny bit of that in not being willing to spend most of inputs unless its a low confirm target 10:25 < morcos> but then there get to be all kinds of complicated questiosn, what kinds of fee rates does this user usually use and compare to current market conditions and size of current transaction 10:26 < gmaxwell> it's a fair point that you don't want to tie up all your inputs on a rare 25-confirm-target payment. 10:26 < morcos> that was all kind of a next level in my mind... first level was meant to try to eliminate some stupid edge cases but not deviate too much from existing logic 10:26 < morcos> yeah.. so many ways to so grade tx selection 10:26 < gmaxwell> Fair enough. 10:28 < instagibbs> morcos, I think earlier you basically described murch's algorithm, first it does some quick search for "exact match", meaning sum of effective amounts of the inputs that don't create a change output, and then if that fails backs off to random selection 10:29 < morcos> instagibbs: ah yes, ok i'll go reread what he said... i wanted to keep random selection from the lower than target value inputs if possible.. and do them on net value... that seems to me the important improvements 10:30 < instagibbs> sure, that seems to mesh. He said he got 50x more exact matches than Core. Which means it might be worth it. 10:30 < instagibbs> (on a real world scrubbed dataset) 10:31 < instagibbs> I still think 10333 is complementary. Anytime we screw up somehow hitting the feerate we want, we can try and salvage. Hopefully will be much less important at least. 10:32 < gmaxwell> and exploiting no change is important for reducing the utxo set size; I think if payment amounts come from a unimodal distribution the utxo count will grow expoentially under any algorithim that minimizes input counts and always creates change. 10:33 < morcos> instagibbs: yes, i haven't read the code yet, but i'm not opposed to the idea... but i think if we consider net values for inputs, then there is no such thing as screwing up the fee. 10:33 < sipa> gmaxwell: but aiming for no change probably requires that every wallet permanently has a set of utxos of various sizes 10:34 < sipa> gmaxwell: which on itself may not be ideal 10:34 < gmaxwell> well then there is the extra change output, which I'd like to work out how to do, at least when the change would be large we should split the outputs. 10:36 < instagibbs> morcos, yeah I can't convince myself otherwise, but having a safety net feels better. It's not a lot of logic. Treating the cause is clearly fixing coin selection. 10:43 < gmaxwell> as far as the safty net, I think it's fine if it's just a dumb check at the end that aborts the transfer if it fails. 10:43 < gmaxwell> people get spazzy about automatic fees because they don't know what it could pay. 10:43 < gmaxwell> omg what if it pays all my monies! 10:46 -!- Giszmo [~leo@ip-206-233.219.201.nextelmovil.cl] has quit [Ping timeout: 260 seconds] 11:05 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 11:10 -!- elkalamar [~elkalamar@251.red-88-22-198.staticip.rima-tde.net] has joined #bitcoin-core-dev 11:27 -!- d_t [~textual@ip-64-134-238-233.public.wayport.net] has joined #bitcoin-core-dev 11:27 < sipa> cfields: a bit ironic... if you build with new glibc on an old kernel, but later run on a new kernel... using getentropy actually improves things 11:27 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:33 < cfields> sipa: ironic how? 11:34 < sipa> cfields: in that it would seem that getentropy is never useful on linux 11:35 < sipa> s/ironic/surprising/ 11:35 < cfields> ah 11:37 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 11:38 < cfields> well, it basically just forces the syscall to be tried on all systems, when built on something newish. but yea, the path isn't exactly obvious in all cases :) 11:38 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 11:39 < sipa> we could of course just hardcode the SYS_getrandom constant :p 11:39 * sipa ducks 11:39 < cfields> I suppose we could add a weak getrandom() that does the syscall and avoid the loops 11:39 < cfields> haha 11:39 -!- d_t [~textual@ip-64-134-238-233.public.wayport.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 11:45 < cfields> sipa: i find the logic harder to follow in your version :\ 11:46 < cfields> i'm not sure if we want to cascade like that? 11:53 < sipa> ok, just a suggestion 11:57 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:611c:e7bb:869d:a3e8] has quit [Quit: .] 12:00 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev 12:00 < sipa> yow 12:00 < sipa> meeting? 12:01 < sdaftuar> did anyone volunteer to chair? 12:01 < sipa> #startmeeting 12:01 < lightningbot> Meeting started Thu May 4 19:01:13 2017 UTC. The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:01 < sipa> topics? 12:01 < BlueMatt> oh, wumpus is out? 12:01 < sipa> he is 12:01 < instagibbs> hi 12:01 < BlueMatt> #10337 12:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10337 | Coin Control Dialog is not (very) useful for manual privacy protection · Issue #10337 · bitcoin/bitcoin · GitHub 12:01 < BlueMatt> :( 12:02 < jonasschnelli> Proposed low prio topic: HD restore update / questions 12:02 < sipa> #topic #10337 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/10337 | Coin Control Dialog is not (very) useful for manual privacy protection · Issue #10337 · bitcoin/bitcoin · GitHub 12:02 < sipa> gmaxwell: ping people? 12:02 < luke-jr> BlueMatt: I agree change shouldn't be grouped as it is, but I don't understand how "received by address" is wrong 12:02 < BlueMatt> turns out the coin control dialog is almost entirely useless 12:03 < jonasschnelli> BlueMatt: entierly useless? I disagree 12:03 < BlueMatt> the "received by address" thing works fine for coins you just received, but if it is a change output it walks back the first input until it finds a non-change output 12:03 < luke-jr> BlueMatt: seems plenty useful to me 12:03 < BlueMatt> so it, essentially, picks an address at random if the output is change 12:03 < luke-jr> BlueMatt: I see different "received by address" for change too 12:03 < BlueMatt> and groups by it, which obviously isnt what you want for privacy 12:03 < BlueMatt> luke-jr: for addresses marked as change in the wallet? no 12:04 -!- elkalamar [~elkalamar@251.red-88-22-198.staticip.rima-tde.net] has quit [Ping timeout: 255 seconds] 12:04 < luke-jr> BlueMatt: yes.. 12:04 < BlueMatt> for random addresses of yours it should work, but not for addresses via getrawchangeaddress 12:04 < luke-jr> I don't use that RPC, but it works for normal change 12:04 < jtimon> hi 12:04 < BlueMatt> (or, ofc, normal change) 12:05 < BlueMatt> https://github.com/bitcoin/bitcoin/blob/master/src/qt/walletmodel.cpp#L620 12:05 < sipa> it sounds to me like it is doing a mix of "receive by address" and "linked grouping" 12:05 < sipa> both are perhaps useful 12:05 < BlueMatt> more importantly, really, is that I've repeatedly seen the tree mode of the coin picker dialog as the same as listaddressgroupings, which it is clearly not 12:06 < BlueMatt> sipa: well the change-output-results-in-random-grouping thing is kinda strange 12:06 < sipa> right, it shouldn't walk for receive address 12:06 < luke-jr> BlueMatt: I have nfc what that code does, but it *looks* right in the end window :/ 12:06 < sipa> and it should alwaya walk (to some deterministic representative) for grouping 12:06 < sipa> *alwaya 12:06 < sipa> *alwayS 12:06 < BlueMatt> *always 12:07 < BlueMatt> but, yea, anyway, I think this should really emulate the grouping rpc 12:07 < BlueMatt> the "where did these coins come from" question is not really useful for anything but coins you just got, in which case they will already be ungrouped 12:07 < sipa> a "received by address" is still useful i think, but it's not the same as grouping 12:07 < kanzure> hi. 12:07 < BlueMatt> yes, but if it is not received directly, it should be "Change" 12:08 < sipa> BlueMatt: seems reasonable to me 12:08 < BlueMatt> anyway, other topics? 12:08 < 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:08 < sipa> #topic HD restore update 12:08 < jonasschnelli> #10240 12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub 12:09 < jonasschnelli> I have worked out a solution that seems to work for encrypted and encrypted&pruned wallets. 12:09 * BlueMatt wonders why we cant have a derivation key which is not encrypted in our wallet so taht we dont have to pause sync 12:09 < jonasschnelli> It can halt the sync / validation progress. 12:09 < jonasschnelli> But,.. I'm not sure what gap limit and default keypool size we should use 12:09 < BlueMatt> (to generate new keys) 12:09 < jonasschnelli> 100 and 20 seems very little 12:10 < sipa> BlueMatt: that requires non-hardened derivation 12:10 < jonasschnelli> BlueMatt: IMO encryption (private key wallets) with public key derivation should be avoided 12:10 < BlueMatt> sipa: yes, is that a concern? 12:10 < sipa> BlueMatt: yes, we have a dumpprivkey command 12:10 < jonasschnelli> We should aim – longterm – for watchonly-hd (see NicolasDorier workd) and add a signing-agent ala gpg / ssh 12:10 < sipa> leaking one private key means you leak your whole walley 12:11 < BlueMatt> jonasschnelli: why? your list of funds is already public to the encrypted wallet holders? that wouldnt change? 12:11 < jonasschnelli> But that is alredy the next topic. :) 12:11 < luke-jr> sipa: dumpprivkey isn't supposed to be safe 12:11 < sipa> luke-jr: i know 12:11 < luke-jr> but we could make it fail for non-hardened keys? 12:11 < sipa> luke-jr: but it breaks expectations 12:11 < sipa> people have a mental model about how it works 12:12 < BlueMatt> sipa: maybe I'm confused on the format of HD...seems you can build a list of derivation secrets which is based on a non-encrypted private key which is unexportable? 12:12 < BlueMatt> sipa: and then that would not be the case 12:12 < jonasschnelli> Yes. But I vaguely remember that we once said we don't want to mix private-key wallets with public key derivation... and this makes very much sense to me 12:12 < BlueMatt> (dont know the format of HD, but we could do something else if its way better) 12:12 < sipa> BlueMatt: if you have the parent public key + private child key, you can compute all private child keys 12:12 < jonasschnelli> If we would do child pubkey derivation, keypools could be removed (at least for HD) 12:13 < sipa> BlueMatt: that is an inevitable weakness of EC based derivation 12:13 < jonasschnelli> What sipa said 12:13 < sipa> BlueMatt: and it is reason why bip32 has hardened keys 12:13 < sipa> which core uses 12:13 < BlueMatt> sipa: even if your list of privkeys is based on adding a new random value to the previous privkey where the new random value is just a hashchain of a private secret? 12:13 < sipa> BlueMatt: then you lose public derivation 12:14 < sipa> (the ability to compute child pubkeys without knowing the parent privkey) 12:14 < BlueMatt> lets take this offline 12:14 < sipa> sounds good 12:14 < jonasschnelli> back to the topic: what GAP limit should we enforce by default? 12:14 < BlueMatt> 1000 12:14 < BlueMatt> default keypool 10k 12:14 < jonasschnelli> Yeah.. I like this 12:15 < jonasschnelli> But only for encrypted wallets? 12:15 < jonasschnelli> IMO we should (only encrypted) 12:15 < sipa> but in general i believe that most cases where the public derivation is wanted, just use huge precomputed key lists 12:15 < jonasschnelli> non encrypted can say with 100 12:15 < sipa> jonasschnelli: meh 12:15 < sipa> why bother differentiating? 12:15 < gmaxwell> why only encryption? I don't think that makes sense. 12:15 < jonasschnelli> True, the gap limit must be the same.. right 12:15 < jonasschnelli> sry 12:15 < gmaxwell> less complexity please, and keys are cheap. 12:15 < jonasschnelli> Okay, ... I'll bump it to 1000 12:16 < bitcoin-git> [bitcoin] jtimon opened pull request #10339: Optimization: Calculate block hash less times (master...b15-optimization-blockhash) https://github.com/bitcoin/bitcoin/pull/10339 12:16 < jonasschnelli> Next question: the tests are mostly running with a keypool size of 1... so the gap limit stuff is only enforced for the new test in #10240 12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub 12:16 < jonasschnelli> Is that a problem? 12:16 < gmaxwell> jtimon: thanks for working on that. 12:17 < jonasschnelli> (but maybe take the test question offline). 12:17 < jonasschnelli> Well,.. keypool size is answered... all good. Thanks for reviews. :p 12:17 < jtimon> gmaxwell: no problem, thank you for pointing it out the other day 12:18 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection] 12:19 < jonasschnelli> other topics? 12:19 < BlueMatt> review, review, review, review, review :) 12:19 < sipa> yes, let's go over priority reviews 12:20 < jonasschnelli> https://github.com/bitcoin/bitcoin/projects/8 12:20 < sipa> #topic review requests 12:20 < Chris_Stewart_5> Can #9980 be merged? Might be some what controversial 12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/9980 | Fix mem access violation merkleblock by Christewart · Pull Request #9980 · bitcoin/bitcoin · GitHub 12:20 < BlueMatt> Chris_Stewart_5: we're super backlogged on review right now :( 12:20 < Chris_Stewart_5> I thought jnewberry did a good job with the comments 12:20 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 12:20 < jonasschnelli> Chris_Stewart_5: I can't see an tested or untested ACK there 12:21 < BlueMatt> like, super backlogged-not-gonna-get-everything-for-0.15 backlogged :( 12:21 < Chris_Stewart_5> That's fine :-). Thought I would bring it up since asking for topics 12:21 < BlueMatt> we can add it to the review heap 12:22 < BlueMatt> can we remove #8694 until it gets fixed+rebased? 12:22 < gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub 12:22 < BlueMatt> it seems to have been in a constant state of not-reviewable since it was added to the "high priority for review" 12:22 < instagibbs> sorry, when it 0.15 feature freeze 12:22 < jonasschnelli> luke-jr: plans to rebase it? 12:22 < BlueMatt> instagibbs: 2017-07-16 12:22 < instagibbs> eep, ok 12:23 < jonasschnelli> I though MW was one of the high profiled features targets for 0.15.. 12:23 < jtimon> is there anything else that needs to be done for #9494 ? 12:23 < luke-jr> I just did? :/ 12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub 12:23 < BlueMatt> sdaftuar: asks for #9208 12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub 12:23 < luke-jr> not really sure how to address the mapMultiArgs thing 12:24 < luke-jr> besides refactoring everything using it 12:24 < jonasschnelli> I add 9208 to the review-prio-list 12:24 < jtimon> on the list we have #8855 from me, which remains being simple to review 12:24 < gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub 12:24 < BlueMatt> jonasschnelli: you already have one 12:24 < gmaxwell> I really would like to see us get per-txout + atomic merged sooner rather than later, so we can get more testing time on the code. 12:24 < jonasschnelli> BlueMatt: It's sdaftuar. :P 12:24 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection] 12:24 < BlueMatt> ohoh 12:24 < BlueMatt> yes, sorry 12:24 < jtimon> luke-jr: refactoring everything that uses mapMultiArgs is what #9494 does 12:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub 12:24 < jonasschnelli> No worries... I protect the ratio. :) 12:25 < BlueMatt> jonasschnelli: I read that as "add for me", not "added" 12:25 < luke-jr> jtimon: k, I'll take a look 12:25 < instagibbs> jtimon, will review 12:25 < cfields> gmaxwell: agreed 12:25 < jtimon> awesome, thanks 12:25 < sipa> let's put 9494 on the list this week 12:26 < BlueMatt> either way, #8694 probably needs deleted 12:26 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 12:26 < gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub 12:26 < luke-jr> BlueMatt: why? 12:26 < jonasschnelli> I guess soon we have to introduce a review/open-new-PR ratio (only allowed to open a PR is you have carefully reviewed other PRs) 12:26 < BlueMatt> luke-jr: because its not reviewable? 12:26 < luke-jr> oh, from the list only, ok 12:26 < BlueMatt> yeayea 12:26 < sipa> i want to keep 8694 as a priority for 0.15 12:26 < jonasschnelli> #8855 is already in the list by jtimon 12:26 < gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub 12:26 < jtimon> sipa: there's already one from me on the list 12:27 < BlueMatt> sipa: I'm just saying gotta remove it from the list because its not reviewable atm, even if we want it for 0.15 12:27 < sipa> BlueMatt: agree 12:27 < sipa> jtimon: let's focus on the args refactoring first... it seems that that will more easily go stale 12:27 < luke-jr> 0.15 and priority-review are two diff lists for a reason; let's do jtimon's PR first 12:28 < sipa> luke-jr: agree 12:28 < sipa> any further topics? 12:29 < gmaxwell> sipa: where are things with per-txo? 12:29 < jonasschnelli> #10195 12:29 < 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:29 < BlueMatt> gmaxwell: needs more review, could use side-by-side benchmarks incl: memory usage, disk usage, performance numbers 12:29 < sipa> yes, i'm planning to do benchmarks 12:30 < gmaxwell> BlueMatt: "much faster" 12:30 < sipa> other todos are better upgrade code (with a fancy progress bar...), that doesn't leave gigabytes of uncompacted data in the chainstate 12:30 < sipa> but i believe it is functionally complete and tested 12:31 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 12:31 < BlueMatt> alright, if there are no more topics I'd emplore people to keep reviewing the big 0.15 things, since it looks like we're gonna slip a few, which is sad 12:31 < sipa> it seems to make the chainstate some 20% larger 12:32 < sipa> i'll report numbers on the PR, no need to discuss here 12:32 < sipa> BlueMatt: ack 12:32 < sipa> #endmeeting 12:32 < lightningbot> Meeting ended Thu May 4 19:32:31 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:32 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-04-19.01.html 12:32 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-04-19.01.txt 12:32 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-04-19.01.log.html 12:32 < sipa> #topic lunch 12:32 < luke-jr> ._. 12:33 < jonasschnelli> sipa: those 120% happens also for the in-memory dbcache? 12:33 < jonasschnelli> *those +20% 12:33 < sipa> jonasschnelli: in memory it's much more 12:33 < sipa> but that's not a fair comparison 12:33 < jtimon> of "preparation PRs" for 10195: 10249 10250 have been merged, 10248 has not, still 24 commits... 12:33 < sipa> as it's much more granular, fewer cached outputs may have better performamce 12:34 < sipa> #10248 12:34 < gribble> https://github.com/bitcoin/bitcoin/issues/10248 | Introduce CHashVerifier to hash while deserializing by sipa · Pull Request #10248 · bitcoin/bitcoin · GitHub 12:34 < sipa> jtimon: most are small, but yes, it's a big change 12:35 < BlueMatt> also #10199 is pretty critical for 0.15 12:35 < gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub 12:35 < jtimon> yeah, I was just wondering if further preparations could be separated, to make review less scary, but in the end they will be the same commits 12:35 * BlueMatt votes for 10199 as most-critical user-facing feature, maybe multiwallet too 12:35 < cfields> I think #10189 is ready to go, and it's blocking a few people. jtimon at least. 12:35 < gribble> https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni · Pull Request #10189 · bitcoin/bitcoin · GitHub 12:35 < sipa> i could use 10189 for some of the changes in 10195 as well 12:38 < jtimon> cfields: not really blocking (scripted-diff PRs can be done without the script for travis being merged and review should be similar), but yeah, I think it's ready to go too. I drafted some documentation, maybe that helps: https://0bin.net/paste/mTtIoaSoedZ3al-y#dWgD7aBKElhKofVS5nHJBvuvlDLRFmgRy8a03KroOFM 12:41 < sipa> jtimon: looks like something for developer-notes.md 12:41 < cfields> jtimon: thanks! 12:42 < cfields> jtimon: not sure what 3) is saying through 12:42 < jtimon> sipa: right, well, cfields feel free to use whatever parts of it make sense to you 12:42 < cfields> jtimon: lgtm, I'm just not following that one part 12:43 < jtimon> well, I needed point 3 because I was some times editing the script trying to do more specific things, so I didn't want to keep changes done by an earlier version of the script or by me manually because I stupid and I forget the commit should only do what the script does and nothing else or something 12:44 < jtimon> maybe we can keep it out, I don't know 12:45 < cfields> jtimon: oh, i see. 12:47 < cfields> jtimon: maybe just say "1) Writer: apply your script to a clean tree and commit with an appropriate message:" 12:47 < cfields> then list the other steps. I was confused because you mention committing before running the script :) 12:50 < praxeology> While upgrading the chainstate to keying on id+o.ix, does it pretty much freeze the init process of the program? 12:50 < sipa> praxeology: yeah... 12:50 < sipa> praxeology: and it takes a while 12:51 < praxeology> Sounds like you are using the same db, not trying to make a new one? 12:51 < sipa> indeed 12:51 < jtimon> cfields: yeah that may do it without explicitly saying the "git checkout ." trick 12:51 < sipa> praxeology: it's an in-place upgrade, and it is interruotible 12:53 < praxeology> interruptible? so you make the new entries, then delete the old ones? and if interrupt, you delete the new ones? 12:56 < sipa> it adds and deletes simultaneously, atomically 12:56 < sipa> you can just kill it at any point 12:57 < praxeology> so the new code can handle lookup and editing of both kinds of entries? 13:00 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer] 13:00 < praxeology> I guess it doesn't matter that much if I understand how it works if I'm not going to help code review/test/code the progress UI 13:00 < sipa> praxeology: no, at startup it just iterates through all old entries and converts them 13:01 < sipa> if you interrupt during that conversion, you need to continue later 13:01 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 13:01 < sipa> but by interruptible i mean you don't lose progress from doing that 13:01 < praxeology> "need to continue later" or else your client doesn't process new blocks/transactions? 13:02 < gmaxwell> when the software restarts it will continue where it left off. 13:02 < gmaxwell> this is all in the init process before it even makes any connections to anything. 13:02 < sipa> praxeology: by interrupt i mean you quit during the conversion 13:02 < sipa> praxeology: the node can't do anything until the conversion is complete 13:03 < praxeology> ok I see 13:04 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds] 13:04 < sipa> it would be possible to do the conversion on the fly, but it would result in a long term slowdown 13:04 < praxeology> also more complicated code that only need be used once 13:05 < praxeology> Are you making the upgrade optional? 13:05 < sipa> no 13:06 < sipa> the new database code cannot read or write the old format anymore, and supporting that would be complicated and slow 13:06 < gmaxwell> It's optional: don't use newer software if you don't want it upgrading. 13:06 < gmaxwell> :) 13:06 < praxeology> Alrighty... I can see why this would be a delayed commit to the main branch. 13:07 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 13:08 < praxeology> I wish I could clone myself 13:08 < gmaxwell> praxeology: we do not do development in master. (few large OSS projects that use Git do)-- things that go into master are at least believed to be done and more or less releasable. 13:08 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 13:09 < praxeology> Yea I know. I am saying that I see why this feature is/may be pushed back to later and later release versions due to the requirement of locking up the node for... how long does it take to process that 2GB of data? 13:10 < sipa> maybe an hour on slow hardware 13:10 < sipa> slow disk, mostly 13:10 < gmaxwell> 15 minutes minutes on fast hardware, I'd guess? 13:10 < sipa> yeah 13:10 < praxeology> and then is leveldb optimized to handle such a db transformation? And does it compress well after deleting all the old entries? 13:11 < sipa> nope, it seems 13:11 < sipa> but there is an explicit call to ask it to compact 13:11 < sipa> which i'll experiment with 13:11 < praxeology> Why not create a new db? 13:12 < sipa> Why create a new db? 13:12 < praxeology> if leveldb has bad performance w/ this sort of transformation 13:12 < sipa> calling db.CompactRange(); is much simpler than dealing with multiple database at once during the conversion 13:13 < praxeology> because you want atomic? 13:13 < gmaxwell> praxeology: it doesn't have bad performance. 13:13 < sipa> praxeology: no... 13:14 < sipa> praxeology: the argument you're bringing up in favor of multiple databases is because leveldb doesn't deal well with the conversion 13:14 < sipa> i offer an alternative to having multiple databases at once which also deals well with the conversion 13:14 < sipa> which is simpler 13:14 < praxeology> ok 13:14 < gmaxwell> You need to ask it to free the space or its very lazy about it, thats all. 13:15 < gmaxwell> Unrelated, while watching a debug=1 logging rescan.. why is it battering out leveldb activity during rescan? 13:16 < sipa> gmaxwell: huh 13:16 < gmaxwell> https://0bin.net/paste/VZ72NOA3G8n-lgpF#FXx9b3te-4BbUbBH7BfGjjpXOOWUiJmL1YToCU6HRHG 13:17 < praxeology> ah, so CompactRange() will just clean up a sorted key range of the db? Which could be done incrementally along with a process that alters the format with a sorted key iterator 13:17 < gmaxwell> the repeatedbash is the some instrumentation I added to count repeated hashings of the block header.. every 6 or so of those is processing a new block. 13:17 < gmaxwell> praxeology: ya, thats what he's going to have it do now. 13:17 < sipa> gmaxwell: that looks like just background compactions 13:18 < gmaxwell> e.g. every time the leading byte of the key changes, compact. 13:21 < praxeology> I've heard rumors that leveldb is unreliable. Is that still true? 13:21 < sipa> praxeology: see my answer here https://bitcoin.stackexchange.com/a/51446/208 13:22 -!- tw2006 [~tw2006@2601:187:8480:2770:fcb8:1655:8822:3ffd] has quit [Remote host closed the connection] 13:25 < gmaxwell> praxeology: a lot of those rumors are a result of several things (1) (primary) leveldb has agressive checking and will actually catch lower level corruption that other things miss, (2) there there is no windows filesystem interface for leveldb and the one we previously used was incorrect, leading to unnecessary corruption with unclean shutdowns, (3) there is a usenix paper that panned leveldb f 13:25 < gmaxwell> or not handling crashes given worst case behavior of the the VFS contract that they inferred. 13:25 < gmaxwell> (3) appears to be completely inconsequential in practice, e.g. I left systems running for months in constant high load plus crash loops and it always recovered. 13:26 < gmaxwell> When we do get reliablity reports from users we sometimes investigate them in detail, and frequently find actual disk corruption. 13:26 < gmaxwell> Unfortunately, there is a lot of windows-grade hardware out there. 13:26 < sipa> or overheating CPUs 13:27 < praxeology> I would guess memory failure would be more common that cpu failure in my experience 13:27 < gmaxwell> yes, esp laptops, many brands of laptop cannot be run at full speed for an hour at a time without actually ending up with apparent 'memory' corruption. (presumably cpu caches). 13:28 < sipa> praxeology: i would think so too, but that's not very consistent with what we're seeing (for example, for some people, running with -par=1 actually improves things) 13:29 < gmaxwell> well it could be ram which behaves more poorly with the cpu taxing the power rails and making things hot. who knows. 13:30 < praxeology> I've had terrible experience with cheap consumer memory from lower cost computer brands, when operating under load 13:30 < sipa> i think we're seeing fewer db corruptions than a few years ago 13:31 < praxeology> Are you saying there are still issues with crash recovery in windows? 13:31 < sipa> that may be due to better windows env support in leveldb 13:31 < sipa> or due to people running on better hardware 13:31 < sipa> or just fewer people running bitcoin core on windows 13:32 < sipa> not all corruption reports are on windows, to be clear 13:32 < sipa> but historically those were a majority 13:32 < praxeology> I have like 3 windows machines running core on windows, and they haven't corrupted. But I have all very reliable machines that don't crash or shutdown unexpectedly 13:34 < sipa> praxeology: ha, that's good to know 13:35 < praxeology> Alright well best of luck w/ the utxo index change. I'd consider help testing or maybe doing some UI work on it. But I am very busy 13:35 < sipa> thanks regardless! 13:35 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 13:36 < praxeology> Maybe if you point me to the code and ask me for help directly I'll add it to my todo list and maybe I will do it if my priorities make it there. 13:46 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 13:47 < BlueMatt> jonasschnelli: you might kill me for #10340, sorry :/ 13:47 < gribble> https://github.com/bitcoin/bitcoin/issues/10340 | Add harmless missing cs_wallet lock in qt CoinControlDialog by TheBlueMatt · Pull Request #10340 · bitcoin/bitcoin · GitHub 13:47 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10340: Add harmless missing cs_wallet lock in qt CoinControlDialog (master...2017-05-fix-mapwallet-zap-runtime) https://github.com/bitcoin/bitcoin/pull/10340 13:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 13:59 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 14:23 -!- tw2006 [~tw2006@2601:187:8480:2770:5dbf:2a78:65c9:c047] has joined #bitcoin-core-dev 14:28 -!- tw2006 [~tw2006@2601:187:8480:2770:5dbf:2a78:65c9:c047] has quit [Ping timeout: 255 seconds] 14:45 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 14:57 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 14:57 < luke-jr> hmm, master doesn't seem to build for me 14:58 < sipa> what error? 15:00 < luke-jr> wallet/rpcwallet.cpp:732:98: error: taking address of temporary [-fpermissive] 15:02 < luke-jr> I'm not entirely clear why this shouldn't be okay 15:02 < luke-jr> it's returning a reference 15:03 < gmaxwell> you can't return a reference to something on the stack.. which is what that sounds like? 15:03 < luke-jr> no, the univalue method is returning a reference to a member 15:04 < luke-jr> const std::string* account = request.params[0].get_str() != "*" ? &request.params[0].get_str() : nullptr; 15:04 < luke-jr> GCC doesn't like us taking the pointer of it for some reason 15:04 < sipa> that's invalid 15:04 < sipa> it's taking a pointer to a temporary 15:04 < sipa> ah, wait 15:05 < luke-jr> FWIW, this didn't fail until I disabled ccache, so I suspect it's a new error 15:05 < luke-jr> GCC 5.4 15:06 -!- elkalamar [~elkalamar@84.126.69.179.dyn.user.ono.com] has joined #bitcoin-core-dev 15:11 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 15:16 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 15:24 -!- tw2006 [~tw2006@2601:187:8480:2770:ca:bec0:9f78:e536] has joined #bitcoin-core-dev 15:29 -!- tw2006 [~tw2006@2601:187:8480:2770:ca:bec0:9f78:e536] has quit [Ping timeout: 255 seconds] 15:37 < ryanofsky> i think i added the line causing that error, but i also don't see why it's an error 15:40 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:58 -!- vicenteH` [~user@135.234.15.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 16:14 -!- juscamarena_ [~justin@47.148.176.74] has quit [Ping timeout: 268 seconds] 16:14 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 16:25 -!- tw2006 [~tw2006@2601:187:8480:2770:d43c:bae7:283b:cbfc] has joined #bitcoin-core-dev 16:30 -!- tw2006 [~tw2006@2601:187:8480:2770:d43c:bae7:283b:cbfc] has quit [Ping timeout: 255 seconds] 16:32 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 16:33 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 16:43 -!- str4d [~str4d@27.110.123.92] has joined #bitcoin-core-dev 16:57 -!- str4d [~str4d@27.110.123.92] has quit [Ping timeout: 268 seconds] 16:58 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:12 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 17:12 < luke-jr> it seems that my system univalue returns a temporary, and for some reason Core is including that instead of the embedded univalue :| 17:13 < praxeology> Not sure how "garbage collection" works with std::string. Does that line make a string array on the stack or is it allocated in heap? 17:14 -!- marcoagner [~user@177.41.200.138] has quit [Read error: Connection reset by peer] 17:14 < sipa> praxeology: c++ has no garbage collection 17:14 -!- marcoagner [~user@177.41.200.138] has joined #bitcoin-core-dev 17:14 < sipa> when the variable goes out of scope, it is destroyed 17:14 < luke-jr> what is supposed to add src/univalue/include/ to the include path? it's not there.. 17:15 < sipa> praxeology: and strings are always allocated on the heap (in practice), but that's not relevant 17:15 < sipa> praxeology: there is no refcounting for references 17:16 < sipa> some c++ standard libraries implement refcounting for strings internally, but that still only works with different _string_ objects with the same content, not multiple references to the same one 17:16 < luke-jr> oh, system univalue is used by default, as expected, ok 17:17 < luke-jr> so I guess options are: 1) require newer univalue to use system, or 2) rewrite this code to work either way 17:17 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 17:18 < luke-jr> it's probably slightly optimised to do num 2 17:18 < luke-jr> is it valid to assign the return std::string temporary to a reference? or is G++ just extra tolerant? 17:18 < gmaxwell> 'system univalue' dear lord, why would that exist? 17:18 < luke-jr> const std::string& account_param = request.params[0].get_str(); 17:19 < luke-jr> gmaxwell: because that's the right way to do libraries 17:19 < sipa> luke-jr: it is valid 17:19 < sipa> (i commented on the PR) 17:20 < praxeology> sipa: yea thought so... "it's taking a pointer to a temporary", not sure why you used the word "temporary" there because if allocated on the heap, its not temporary in any way. 17:20 < luke-jr> which PR? 17:20 < luke-jr> praxeology: it's not. if there's no "new", it's not on the heap 17:20 < gmaxwell> luke-jr: if it were actually a library and not some unmaintained code dump that only we use... 17:21 < praxeology> luke-jr: are you sure there is no "new" deeper in the library? 17:21 < sipa> praxeology: 'heap' and 'stack' don't exist in the C++ spec, they're implementation details 17:21 < sipa> praxeology: 'temporary' however exists in the spec 17:22 < sipa> praxeology: a temporary is the result of an expression that returns something by-value, and isn't assigned to a variable 17:22 < bitcoin-git> [bitcoin] luke-jr opened pull request #10341: rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str (master...rpcwallet_uv_workaround) https://github.com/bitcoin/bitcoin/pull/10341 17:23 < sipa> praxeology: in practice, the std::string is allocated on the stack, but the string object itself allocates the string/length data on the heap 17:24 < sipa> but again, that doesn't matter 17:24 < sipa> the compiler may even optimize part out and not have such objects hit memory at all 17:25 < sipa> what matters is that it's returning an object and not storing it in a variable 17:26 < praxeology> Hm, yea I guess somehow with the automatic out-of scope clearing/freeing/deleting of the actual data... you need to assign the std::string to a stack variable for the duration you want it to exist 17:26 -!- tw2006 [~tw2006@2601:187:8480:2770:5c94:303c:3913:afe7] has joined #bitcoin-core-dev 17:26 < sipa> no, you don't 17:26 < sipa> that's what i just pointed out 17:27 < sipa> you can take a reference to a temporary, and in that case, the lifetime of the temporary is automatically extended as long as the reference exists 17:27 < sipa> but that's done by static analysis by the compiler, not by reference counting 17:28 < praxeology> its returning an object that becomes part of stack, but in order for that to happen you need to assign the object to a variable that exists in the stack 17:28 < sipa> stop talking about stacks, that doesn't matter 17:30 < praxeology> ok, scope somehow. but that is less clear to me how such works... I guess we don't have to discuss it here, I can look into it myself 17:31 -!- tw2006 [~tw2006@2601:187:8480:2770:5c94:303c:3913:afe7] has quit [Ping timeout: 255 seconds] 17:36 < praxeology> const std::string* account = nullptr; 17:37 < praxeology> woops sorry I'll leave you guys alone now 17:37 * luke-jr puts praxeology on the stack 17:40 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds] 17:46 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 17:48 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hflsokifwvjuxcti] has quit [Quit: Connection closed for inactivity] 17:56 -!- tw2006 [~tw2006@2601:187:8480:2770:653b:e279:451c:d0c7] has joined #bitcoin-core-dev 18:02 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 18:34 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 18:34 < dcousens> sipa: "its modifying rng_state, protected by the lock" --- I suppose, for an RNG, racing memcpy of random data isn't as much an issue? :D haha 18:36 < gmaxwell> it's very much an issue, as it could cause arbritary corruption. 18:36 < dcousens> gmaxwell: would it could corruption outside of rng_state though? 18:36 < gmaxwell> Yes. 18:37 < dcousens> OK, then yes, issue 18:37 < gmaxwell> yea, I was just being stupid and thought that was the copy into the output too. 18:39 < dcousens> gmaxwell: ooi, what could I lookup to understand the implications of that, I wasn't aware it could cause arbitrary corruption 18:39 < gmaxwell> dcousens: in C/C++ the compiler is allowed to assume that it has exclusive access to any variable it writes to in a scope for the duration of it (the technical guarentee is more complicated and I don't fully understand it, but this approximation is enough). So the compiler could do optimizations like temporarily store the stack pointer into memory that it knows it's going to later overwrite. t 18:39 < gmaxwell> hen copy it back out again before overwriting it. 18:39 < dcousens> gmaxwell: answered as I asked 18:40 < dcousens> cheers 18:40 < gmaxwell> Its very rare for it to _in practice_ cause arbritary corruption, but it's not unheared of.. intel's compiler is a little more prone to crazy stunts that expose things like that than GCC is, but presumably future versions of GCC will keep getting smarter until nothing runs. :) 18:40 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 18:40 < dcousens> ha 19:00 -!- dermoth [~thomas@dial-216-221-44-85.mtl.aei.ca] has quit [Read error: Connection reset by peer] 19:01 -!- dermoth [~thomas@dial-216-221-44-85.mtl.aei.ca] has joined #bitcoin-core-dev 19:03 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 19:13 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 19:17 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 19:17 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 20:01 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye] 20:02 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 20:02 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 20:12 -!- tw2006 [~tw2006@2601:187:8480:2770:653b:e279:451c:d0c7] has quit [Remote host closed the connection] 20:51 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection] 20:52 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-core-dev 21:13 -!- tw2006 [~tw2006@2601:187:8480:2770:e1f8:b222:c7f1:e5e1] has joined #bitcoin-core-dev 21:14 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 21:17 -!- tw2006 [~tw2006@2601:187:8480:2770:e1f8:b222:c7f1:e5e1] has quit [Ping timeout: 260 seconds] 21:18 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 21:27 -!- sw1f7 [~sw1f7@cpe-172-112-220-177.socal.res.rr.com] has joined #bitcoin-core-dev 21:41 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 21:50 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 258 seconds] 21:53 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 21:58 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 260 seconds] 22:03 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 22:08 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 246 seconds] 22:14 -!- tw2006 [~tw2006@2601:187:8480:2770:8c29:ca34:8463:61aa] has joined #bitcoin-core-dev 22:17 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 22:19 -!- tw2006 [~tw2006@2601:187:8480:2770:8c29:ca34:8463:61aa] has quit [Ping timeout: 255 seconds] 22:37 -!- iprokg [~Mutter@91.192.67.228] has joined #bitcoin-core-dev 22:38 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-bbinjwsyofogyeos] has joined #bitcoin-core-dev 22:44 -!- iprokg [~Mutter@91.192.67.228] has quit [Remote host closed the connection] 22:46 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev 22:49 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining] 23:00 -!- dermoth [~thomas@dial-216-221-44-85.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:00 < jonasschnelli> <*highlight> [22:47:52] jonasschnelli: you might kill me for #10340, sorry :/ 23:00 < gribble> https://github.com/bitcoin/bitcoin/issues/10340 | Add harmless missing cs_wallet lock in qt CoinControlDialog by TheBlueMatt · Pull Request #10340 · bitcoin/bitcoin · GitHub 23:00 -!- dermoth [~thomas@dial-216-221-44-85.mtl.aei.ca] has joined #bitcoin-core-dev 23:00 * jonasschnelli looking at 10340 23:02 < jonasschnelli> BlueMatt: seems reasonable to me (10340) 23:03 -!- moli_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 23:03 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 23:07 -!- moli_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 23:08 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 23:13 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 23:13 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 23:15 -!- tw2006 [~tw2006@2601:187:8480:2770:193e:63c5:3b24:571] has joined #bitcoin-core-dev 23:20 -!- tw2006 [~tw2006@2601:187:8480:2770:193e:63c5:3b24:571] has quit [Ping timeout: 255 seconds] 23:43 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 23:52 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]