12017-05-04T00:04:29 *** tw2006 has joined #bitcoin-core-dev
22017-05-04T00:09:04 *** tw2006 has quit IRC
32017-05-04T00:20:32 *** btcdrak has joined #bitcoin-core-dev
42017-05-04T00:22:35 *** Ylbam has quit IRC
52017-05-04T00:28:50 *** tw2006 has joined #bitcoin-core-dev
62017-05-04T00:50:28 *** anthonyjd has joined #bitcoin-core-dev
72017-05-04T00:51:10 *** kadoban has quit IRC
82017-05-04T00:51:39 *** kadoban has joined #bitcoin-core-dev
92017-05-04T00:57:44 *** kadoban has quit IRC
102017-05-04T00:58:46 *** kadoban has joined #bitcoin-core-dev
112017-05-04T01:05:21 *** PaulCape_ has joined #bitcoin-core-dev
122017-05-04T01:05:33 *** PaulCapestany has quit IRC
132017-05-04T01:06:17 *** kadoban has quit IRC
142017-05-04T01:06:25 <cfields> sipa: you're going to hate me for this...
152017-05-04T01:07:31 <bitcoin-git> [bitcoin] theuni opened pull request #10335: back-compat: add fallback getentropy implementation (master...getentropy-back-compat) https://github.com/bitcoin/bitcoin/pull/10335
162017-05-04T01:12:01 <sipa> cfields: we don't use getentropy on linux
172017-05-04T01:12:22 <warren> cfields: btw, Ubuntu 12.04 Precise is hitting EOL, will gitian switch to a newer base soon?
182017-05-04T01:12:46 <sipa> cfields: or we shouldn't, i guess
192017-05-04T01:13:26 <sipa> if getrandom isn't available on linux, i think we should fallback to using /dev/urandom directly rather than through a fallback for a wrapper for a BSD function :)
202017-05-04T01:16:00 <cfields> sipa: atm it's being used in linux, best i can tell
212017-05-04T01:16:19 <cfields> (i get a runtime link error, so it must be)
222017-05-04T01:17:21 <cfields> warren: gitian uses Trusty currently
232017-05-04T01:17:36 <warren> oops
242017-05-04T01:18:59 *** Alina-malina has quit IRC
252017-05-04T01:19:05 <sipa> cfields: yes, we compile in code to use getrandom whenever configure detects it
262017-05-04T01:19:57 <cfields> sipa: sorry, i was referring to getentropy
272017-05-04T01:20:05 <sipa> eh, i mean getentropy
282017-05-04T01:20:30 <sipa> cfields: the getentropy implementation in glibc on Linux just uses SYS_getrandom, just like we already do directly
292017-05-04T01:21:19 <sipa> so a fallback that just returns 0 should be fine
302017-05-04T01:21:23 <sipa> we check the return status
312017-05-04T01:21:58 *** kadoban has joined #bitcoin-core-dev
322017-05-04T01:22:21 <sipa> ah, no
332017-05-04T01:22:22 <sipa> hmm
342017-05-04T01:23:25 *** Alina-malina has joined #bitcoin-core-dev
352017-05-04T01:27:22 <cfields> sipa: looks like getentropy needs to check for ENOSYS, and do GetDevURandom as a fallback. Then the weak getentropy just returns ENOSYS.
362017-05-04T01:27:27 <cfields> I think that works?
372017-05-04T01:28:06 <sipa> cfields: yup
382017-05-04T01:28:25 <cfields> ok, will do.
392017-05-04T01:28:25 <sipa> cfields: i think our GetOSEntropy call should always compile in the GetDevURandom fallback
402017-05-04T01:28:40 <sipa> (so move it out of the #ifdef ... #elif .. #endif switch)
412017-05-04T01:28:54 <cfields> yep, agreed
422017-05-04T01:29:01 <sipa> then the getrandom/getentropy calls can fail without problems
432017-05-04T01:29:26 <sipa> and agreed, a simple fallback returning ENOSYS is perfect then
442017-05-04T01:57:12 *** tw2006 has quit IRC
452017-05-04T01:58:21 *** tw2006 has joined #bitcoin-core-dev
462017-05-04T02:00:12 *** dermoth has quit IRC
472017-05-04T02:01:02 *** dermoth has joined #bitcoin-core-dev
482017-05-04T02:02:05 *** juscamarena_ has joined #bitcoin-core-dev
492017-05-04T02:06:07 *** harrymm1 has joined #bitcoin-core-dev
502017-05-04T02:08:32 *** harrymm has quit IRC
512017-05-04T02:30:10 *** tripleslash has quit IRC
522017-05-04T02:35:40 *** molz_ has quit IRC
532017-05-04T02:38:18 *** moli_ has joined #bitcoin-core-dev
542017-05-04T03:02:59 *** QBcrusher__ has joined #bitcoin-core-dev
552017-05-04T03:05:58 *** vicenteH` has joined #bitcoin-core-dev
562017-05-04T03:08:19 *** xHire has joined #bitcoin-core-dev
572017-05-04T03:09:44 *** Dyaheon- has joined #bitcoin-core-dev
582017-05-04T03:10:06 *** kcud_dab has joined #bitcoin-core-dev
592017-05-04T03:11:46 *** vicenteH has quit IRC
602017-05-04T03:11:46 *** xhire_ has quit IRC
612017-05-04T03:11:46 *** Dyaheon has quit IRC
622017-05-04T03:11:47 *** fao3 has quit IRC
632017-05-04T03:11:47 *** justanotheruser has quit IRC
642017-05-04T03:11:47 *** Naphex has quit IRC
652017-05-04T03:11:47 *** instagibbs has quit IRC
662017-05-04T03:11:47 *** Madars has quit IRC
672017-05-04T03:11:47 *** profall has quit IRC
682017-05-04T03:11:47 *** bad_duck has quit IRC
692017-05-04T03:11:47 *** QBcrusher_ has quit IRC
702017-05-04T03:11:47 *** chjj has quit IRC
712017-05-04T03:12:46 *** instagibbs has joined #bitcoin-core-dev
722017-05-04T03:14:20 *** tw2006 has quit IRC
732017-05-04T03:18:30 *** chjj has joined #bitcoin-core-dev
742017-05-04T03:19:11 *** Madars has joined #bitcoin-core-dev
752017-05-04T03:19:19 *** fao3 has joined #bitcoin-core-dev
762017-05-04T03:22:11 *** justanotheruser has joined #bitcoin-core-dev
772017-05-04T03:32:36 <cfields> <sipa> cfields: i think our GetOSEntropy call should always compile in the GetDevURandom fallback
782017-05-04T03:32:42 <cfields> sipa: looking again, I'm not sure what you meant by that
792017-05-04T03:33:02 <cfields> we always compile GetDevURandom, except for win32
802017-05-04T03:34:38 <sipa> cfields: i mean the GetDevURandom call at the bottom of GetOSEntropy
812017-05-04T03:35:01 <sipa> which is only compiled if getrandom and getentropy are not availablr
822017-05-04T03:35:04 <sipa> that should change
832017-05-04T03:35:51 <cfields> sipa: so you want early returns for any better function, and fallback if one isn't hit by the end?
842017-05-04T03:36:08 <sipa> right
852017-05-04T03:36:28 <cfields> makes sense, will do
862017-05-04T03:37:18 <sipa> getrandom currently has a fallback already
872017-05-04T03:37:21 <sipa> but not the rest
882017-05-04T03:43:45 <Lightsword> so I should remove the fallback here as well? https://github.com/bitcoin/bitcoin/pull/10301/files#diff-35f8a407f8c21cda300a45f50b6e9c74R172
892017-05-04T03:50:49 *** talmai has joined #bitcoin-core-dev
902017-05-04T04:15:14 *** tw2006 has joined #bitcoin-core-dev
912017-05-04T04:19:47 *** tw2006 has quit IRC
922017-05-04T04:32:12 *** aantonop has joined #bitcoin-core-dev
932017-05-04T04:43:03 *** d_t has joined #bitcoin-core-dev
942017-05-04T05:06:22 *** fao3 has quit IRC
952017-05-04T05:08:17 *** fao3 has joined #bitcoin-core-dev
962017-05-04T05:11:10 *** Giszmo has quit IRC
972017-05-04T05:13:05 *** profall has joined #bitcoin-core-dev
982017-05-04T05:14:10 *** Dyaheon- has quit IRC
992017-05-04T05:14:28 *** Dyaheon has joined #bitcoin-core-dev
1002017-05-04T05:16:10 *** tw2006 has joined #bitcoin-core-dev
1012017-05-04T05:20:40 *** tw2006 has quit IRC
1022017-05-04T05:24:25 *** fao3 has quit IRC
1032017-05-04T05:24:51 *** fao3 has joined #bitcoin-core-dev
1042017-05-04T05:31:56 *** PaulCape_ has quit IRC
1052017-05-04T05:35:57 *** PaulCapestany has joined #bitcoin-core-dev
1062017-05-04T05:39:43 *** aantonop has quit IRC
1072017-05-04T05:47:32 *** tripleslash has joined #bitcoin-core-dev
1082017-05-04T05:51:28 *** mol has joined #bitcoin-core-dev
1092017-05-04T05:53:48 *** moli_ has quit IRC
1102017-05-04T05:59:51 *** talmai has quit IRC
1112017-05-04T06:00:12 *** RubenSomsen has joined #bitcoin-core-dev
1122017-05-04T06:00:12 *** dermoth has quit IRC
1132017-05-04T06:00:48 *** dermoth has joined #bitcoin-core-dev
1142017-05-04T06:07:41 *** Ylbam has joined #bitcoin-core-dev
1152017-05-04T06:17:10 *** tw2006 has joined #bitcoin-core-dev
1162017-05-04T06:21:56 *** tw2006 has quit IRC
1172017-05-04T06:25:13 *** afk11 has quit IRC
1182017-05-04T06:26:05 *** afk11 has joined #bitcoin-core-dev
1192017-05-04T06:28:13 *** Alina-malina has quit IRC
1202017-05-04T06:28:14 *** Alina-malina has joined #bitcoin-core-dev
1212017-05-04T06:35:27 <jonasschnelli> Grml... if we enforce a min HD recover gap limit (currently 20 keypool keys), all tests are broken (mosts tests run with a keypool of size 1). I guess I have to add a -hdignoregaplimit and set it to true by default for the tests.
1222017-05-04T06:35:50 *** harrymm1 has quit IRC
1232017-05-04T06:37:22 *** harrymm has joined #bitcoin-core-dev
1242017-05-04T06:40:20 *** harrymm has quit IRC
1252017-05-04T06:48:12 *** BashCo has quit IRC
1262017-05-04T06:54:23 *** JackH has quit IRC
1272017-05-04T07:12:39 *** d_t has quit IRC
1282017-05-04T07:12:49 *** BashCo has joined #bitcoin-core-dev
1292017-05-04T07:18:02 *** tw2006 has joined #bitcoin-core-dev
1302017-05-04T07:22:28 *** tw2006 has quit IRC
1312017-05-04T07:28:52 <jonasschnelli> wumpus: Re multiple tx-row-entries after a Qt bump: https://github.com/bitcoin/bitcoin/pull/9697#issuecomment-298339022
1322017-05-04T07:29:12 <jonasschnelli> At the moment, list transactions has the same behavior, though you can see conflicts there.
1332017-05-04T07:29:17 <jonasschnelli> Not sure how we should "solve" that in Qt...
1342017-05-04T07:29:37 <jonasschnelli> I think I once had a PR that marked conflicted tx with a special color (maybe orange or something)
1352017-05-04T07:30:00 <jonasschnelli> Or should we hide them completely (only the own bump conflicts)
1362017-05-04T07:30:02 <jonasschnelli> ?
1372017-05-04T07:36:18 *** jtimon has quit IRC
1382017-05-04T07:36:39 *** mol has quit IRC
1392017-05-04T07:36:47 *** moli_ has joined #bitcoin-core-dev
1402017-05-04T07:42:47 *** aantonop has joined #bitcoin-core-dev
1412017-05-04T07:47:58 *** aantonop has quit IRC
1422017-05-04T07:48:55 *** justanotheruser has quit IRC
1432017-05-04T07:52:40 <wumpus> jonasschnelli: the problem is that the transactions are only marked after a restart IMO
1442017-05-04T07:53:27 <wumpus> not so much the marking itself
1452017-05-04T07:54:08 <jonasschnelli> wumpus: Hmm.. you mean the opacity change, right?
1462017-05-04T07:55:06 <jonasschnelli> Yes. The opacity is only changes after restart,... though, that's solvable.
1472017-05-04T07:55:37 <wumpus> jonasschnelli: or how the amounts are shown (e.g. [] around it)
1482017-05-04T07:55:38 <jonasschnelli> In a follow up PR we could introduce a new icon like this: https://github.com/bitcoin/bitcoin/pull/7826#issuecomment-220644102
1492017-05-04T07:55:53 <jonasschnelli> Ah.. yes. the [] is also part of it. Will fix that now
1502017-05-04T07:58:33 <wumpus> yeah :)
1512017-05-04T08:00:37 *** Dyaheon has quit IRC
1522017-05-04T08:02:39 *** Dyaheon has joined #bitcoin-core-dev
1532017-05-04T08:18:15 <wumpus> I don't understand why we'd need *yet another* workaround for getentropy on linux
1542017-05-04T08:18:44 <wumpus> man if it's really that difficult let's just use /dev/urandom and give this up
1552017-05-04T08:19:02 *** tw2006 has joined #bitcoin-core-dev
1562017-05-04T08:22:08 <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?
1572017-05-04T08:22:42 <wumpus> well the idea is that it can be run in a jail/container without /dev
1582017-05-04T08:23:25 <jonasschnelli> I see...
1592017-05-04T08:23:37 <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...)
1602017-05-04T08:23:37 *** tw2006 has quit IRC
1612017-05-04T08:24:14 <wumpus> I just don't see the point in a getentropy() implementation that reads /dev/iurandom anyway
1622017-05-04T08:24:25 <wumpus> we already have a function for that
1632017-05-04T08:24:33 <wumpus> this is getting way more complicated than I imaginedc
1642017-05-04T08:37:45 *** JackH has joined #bitcoin-core-dev
1652017-05-04T08:38:48 *** harrymm has joined #bitcoin-core-dev
1662017-05-04T08:44:42 *** mturquette has quit IRC
1672017-05-04T08:44:59 *** mturquette has joined #bitcoin-core-dev
1682017-05-04T08:46:41 *** jannes has joined #bitcoin-core-dev
1692017-05-04T08:52:00 *** timothy has joined #bitcoin-core-dev
1702017-05-04T09:11:27 *** elkalamar_ has joined #bitcoin-core-dev
1712017-05-04T09:11:33 *** elkalamar has quit IRC
1722017-05-04T09:11:41 *** twistedline_ has quit IRC
1732017-05-04T09:13:23 *** Guyver2 has joined #bitcoin-core-dev
1742017-05-04T09:16:47 *** twistedline has joined #bitcoin-core-dev
1752017-05-04T09:19:58 *** tw2006 has joined #bitcoin-core-dev
1762017-05-04T09:24:49 *** tw2006 has quit IRC
1772017-05-04T09:45:24 *** e4xit has quit IRC
1782017-05-04T10:07:12 *** e4xit has joined #bitcoin-core-dev
1792017-05-04T10:14:56 *** nejon has quit IRC
1802017-05-04T10:15:10 *** nejon has joined #bitcoin-core-dev
1812017-05-04T10:20:51 *** tw2006 has joined #bitcoin-core-dev
1822017-05-04T10:25:31 *** tw2006 has quit IRC
1832017-05-04T10:31:28 *** chjj has quit IRC
1842017-05-04T10:38:24 *** face has quit IRC
1852017-05-04T10:44:32 *** chjj has joined #bitcoin-core-dev
1862017-05-04T11:10:34 *** tw2006 has joined #bitcoin-core-dev
1872017-05-04T11:18:24 <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
1882017-05-04T11:27:44 *** jouke has quit IRC
1892017-05-04T11:55:58 *** tw2006 has quit IRC
1902017-05-04T11:56:35 *** tw2006 has joined #bitcoin-core-dev
1912017-05-04T12:10:22 *** tw2006 has quit IRC
1922017-05-04T12:11:04 *** tw2006 has joined #bitcoin-core-dev
1932017-05-04T12:14:38 * jonasschnelli wishes a special IDE editing mode where editing a line directly amend edits & rebase and older commit
1942017-05-04T12:23:35 *** harrymm1 has joined #bitcoin-core-dev
1952017-05-04T12:24:30 *** harrymm1 has joined #bitcoin-core-dev
1962017-05-04T12:25:39 *** harrymm has quit IRC
1972017-05-04T12:35:29 *** laurentmt has joined #bitcoin-core-dev
1982017-05-04T12:58:54 *** n1ce has joined #bitcoin-core-dev
1992017-05-04T12:59:44 *** n1ce has quit IRC
2002017-05-04T13:00:34 *** n1ce has joined #bitcoin-core-dev
2012017-05-04T13:06:22 *** marcoagner has quit IRC
2022017-05-04T13:19:38 *** marcoagner has joined #bitcoin-core-dev
2032017-05-04T13:21:01 <jonasschnelli> morcos: ping re mempool stats: https://github.com/bitcoin/bitcoin/pull/8501#issuecomment-270714233
2042017-05-04T13:22:35 *** chjj has quit IRC
2052017-05-04T13:23:20 *** davec has quit IRC
2062017-05-04T13:25:22 <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.
2072017-05-04T13:25:30 *** davec has joined #bitcoin-core-dev
2082017-05-04T13:26:07 <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)
2092017-05-04T13:26:29 <jonasschnelli> same for older then 24h (maybe ensure a min-delta of 2min), etc.
2102017-05-04T13:27:13 <jonasschnelli> The question then is, if we should interpolate fix time steps during cleanup/purge. Because the samples may be distributed "randomly" over time.
2112017-05-04T13:30:11 *** Sosumi has joined #bitcoin-core-dev
2122017-05-04T13:34:38 *** moli_ has quit IRC
2132017-05-04T13:34:54 *** harrymm1 has quit IRC
2142017-05-04T13:35:53 *** chjj has joined #bitcoin-core-dev
2152017-05-04T13:35:53 *** harrymm has joined #bitcoin-core-dev
2162017-05-04T13:36:41 *** harrymm has joined #bitcoin-core-dev
2172017-05-04T13:39:09 <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)
2182017-05-04T13:39:21 <morcos> periodic cleanup just seems weird
2192017-05-04T13:40:31 <jonasschnelli> morcos: Separate vectors would require move samples from one to another vector... though not sure if this bad or good. :)
2202017-05-04T13:40:32 <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
2212017-05-04T13:40:42 <morcos> i don't understand that
2222017-05-04T13:41:28 <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
2232017-05-04T13:41:42 <morcos> there is some very small data duplication, but no moving, cleaning or reorganizing
2242017-05-04T13:41:48 <jonasschnelli> Oh. Yes. I overcomplicated.
2252017-05-04T13:42:02 <jonasschnelli> Yes. Some duplication.. but I guess that okay.
2262017-05-04T13:42:11 <morcos> very little
2272017-05-04T13:42:38 <jonasschnelli> Yeah. Use shared pointers *duck*
2282017-05-04T13:43:04 <jonasschnelli> About the periodic cleanup:
2292017-05-04T13:43:26 *** goksinen has joined #bitcoin-core-dev
2302017-05-04T13:43:34 <jonasschnelli> I though calculating the dynamic allocation on each added sample seems a bit to expansive,.. that's why I added the periodic check
2312017-05-04T13:43:57 <jonasschnelli> But if we have fixed timespans with a thread, then this can be solved simpler.
2322017-05-04T13:44:30 <jonasschnelli> Though I wanted to avoid grabbing the cs_mempool to calculate the dynamic mempool size, etc.
2332017-05-04T13:45:00 <jonasschnelli> Stats could then have an more significan impact on the mempool performance then with "passive collecting"
2342017-05-04T13:47:18 *** davec has quit IRC
2352017-05-04T13:50:18 *** chjj has quit IRC
2362017-05-04T13:50:34 *** d_t has joined #bitcoin-core-dev
2372017-05-04T13:50:51 <sipa> wumpus: presumably his configure did not detect getrandom (old kernel headers?), but did detect getentropy?
2382017-05-04T13:52:32 <morcos> jonasschnelli: you could cache the latest value for things that were being calculated anyway, and then only record it on the periodic sample
2392017-05-04T13:53:56 <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
2402017-05-04T13:54:40 <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
2412017-05-04T13:55:08 *** d_t has quit IRC
2422017-05-04T13:56:40 <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.
2432017-05-04T13:57:13 <jonasschnelli> morcos: Yes. No hurry... I'll ping you once I have more...
2442017-05-04T13:57:30 *** davec has joined #bitcoin-core-dev
2452017-05-04T13:58:56 <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
2462017-05-04T13:59:37 <jonasschnelli> Yes. fair enough... thanks for your inputs
2472017-05-04T14:03:20 *** chjj has joined #bitcoin-core-dev
2482017-05-04T14:06:15 <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
2492017-05-04T14:06:43 <sipa> wumpus: or, alternatively, just never use getentropy on Linux
2502017-05-04T14:13:45 *** goksinen has quit IRC
2512017-05-04T14:14:22 *** goksinen has joined #bitcoin-core-dev
2522017-05-04T14:16:40 *** moli_ has joined #bitcoin-core-dev
2532017-05-04T14:18:24 *** RubenSomsen has quit IRC
2542017-05-04T14:23:03 *** Giszmo has joined #bitcoin-core-dev
2552017-05-04T14:28:40 *** BashCo has quit IRC
2562017-05-04T14:44:56 *** RubenSomsen has joined #bitcoin-core-dev
2572017-05-04T14:45:04 *** str4d has quit IRC
2582017-05-04T14:49:21 *** resi has joined #bitcoin-core-dev
2592017-05-04T14:56:17 *** talmai has joined #bitcoin-core-dev
2602017-05-04T14:59:21 <wumpus> sipa: not using getentropy on linux would make sense, after all there is a specific syscall handling for thatt
2612017-05-04T14:59:50 * wumpus is probably not going to make today's meeting, can anyone else chair please?
2622017-05-04T15:06:50 *** d_t has joined #bitcoin-core-dev
2632017-05-04T15:09:20 <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?
2642017-05-04T15:09:22 <gribble> https://github.com/bitcoin/bitcoin/issues/10238 | Change setKeyPool to hold flexible entries by jonasschnelli · Pull Request #10238 · bitcoin/bitcoin · GitHub
2652017-05-04T15:09:23 <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
2662017-05-04T15:10:06 *** BashCo has joined #bitcoin-core-dev
2672017-05-04T15:10:11 *** elkalamar_ has quit IRC
2682017-05-04T15:12:54 *** talmai has quit IRC
2692017-05-04T15:18:10 <sipa> wumpus: will do
2702017-05-04T15:21:56 *** laurentmt has quit IRC
2712017-05-04T15:45:17 *** jtimon has joined #bitcoin-core-dev
2722017-05-04T15:48:36 *** abpa has joined #bitcoin-core-dev
2732017-05-04T15:49:55 <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
2742017-05-04T15:50:05 <jonasschnelli> (with HD restore)
2752017-05-04T15:50:31 <jonasschnelli> I shouldn't conceptually conflict with your 10235
2762017-05-04T15:50:50 <BlueMatt> ahh, ok, i was missing the motivation part, thanks
2772017-05-04T15:51:28 <jonasschnelli> I though the description was good... need to check...
2782017-05-04T15:51:34 <BlueMatt> oh, maybe i missed that
2792017-05-04T15:51:45 <jonasschnelli> Currently we only keep the keypool index in memory.. the rest is database AFAIK
2802017-05-04T15:53:24 <morcos> wumpus: jonasschnelli: does anyone care about the QT option in Custom fee to pay "total at least"?
2812017-05-04T15:54:26 <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
2822017-05-04T15:54:52 <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
2832017-05-04T15:55:17 <jonasschnelli> morcos: not sure... I'm not sure if we want this feature...
2842017-05-04T15:55:21 <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
2852017-05-04T15:55:48 <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
2862017-05-04T15:56:53 <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
2872017-05-04T16:02:48 *** Giszmo has quit IRC
2882017-05-04T16:09:21 *** goksinen has quit IRC
2892017-05-04T16:15:13 *** goksinen has joined #bitcoin-core-dev
2902017-05-04T16:20:39 *** laurentmt has joined #bitcoin-core-dev
2912017-05-04T16:22:29 *** Giszmo has joined #bitcoin-core-dev
2922017-05-04T16:24:00 <gmaxwell> The total at least stuff makes no sense, it should go. Feerate at least, sure. Total no more than, sure.
2932017-05-04T16:31:13 *** resi has left #bitcoin-core-dev
2942017-05-04T16:35:40 *** nejon has quit IRC
2952017-05-04T16:35:40 *** mturquette has quit IRC
2962017-05-04T16:35:48 <morcos> gmaxwell:hmm... total no more than... you mean just the existing maxtxfee? shoot.. i had forgotten about that
2972017-05-04T16:36:48 <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..
2982017-05-04T16:37:36 <morcos> i suppose it would make some sense to have the -maxtxfee failsafe, but maybe that is at a different place in the code
2992017-05-04T16:37:58 <gmaxwell> Yes, I think thats at a different place in the code.
3002017-05-04T16:38:49 <morcos> no its not now, but i could move it to a different place.. like repeat coin selection if your coin selection violated maxtxfee
3012017-05-04T16:38:59 <morcos> i want to also get rid of the knapsack solver
3022017-05-04T16:39:53 <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
3032017-05-04T16:40:44 <morcos> the idea that you are trying to get exactly target + CENT is stupid. target + 3.5 CENTS is just as good or whatever
3042017-05-04T16:41:07 <gmaxwell> getting a result with no change is also attractive, but I think that should be a seperate algorithim run first.
3052017-05-04T16:41:45 <morcos> gmaxwell: hmm.. i think thats rare enough that i'm not sure its worth trying to hard for
3062017-05-04T16:42:24 <gmaxwell> I don't think it should be, at least if we're reasonable about how much fee we'll throw away.
3072017-05-04T16:42:48 <morcos> its the way we do that now that is kind of causing the super high fees i think
3082017-05-04T16:42:49 <BlueMatt> so apparently the coin selection dialog's "received by" address is, essentially, complete gibberish
3092017-05-04T16:43:03 <morcos> but that is fixable while still trying to do that, for sure
3102017-05-04T16:43:04 *** mturquette has joined #bitcoin-core-dev
3112017-05-04T16:43:20 <BlueMatt> and its "tree" (which I thought was supposed to group things ala listaddressgroupings) does not at all do that, and is equally useless
3122017-05-04T16:45:24 *** RubenSomsen has quit IRC
3132017-05-04T16:45:44 *** nejon has joined #bitcoin-core-dev
3142017-05-04T16:48:10 <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?
3152017-05-04T16:49:13 <morcos> i think its pretty plausible
3162017-05-04T16:49:50 <morcos> if nTotalLower is < target + CENT, then you have a decent chance of the problem happening
3172017-05-04T16:50:14 <morcos> once nTotalLower < target + CENT, the knapsack algorithm tries to find you exactly target
3182017-05-04T16:50:23 <morcos> which leads to decent chance that your change is dust
3192017-05-04T16:50:28 <morcos> so your change gets eliminated
3202017-05-04T16:51:04 <morcos> then when you callculate the fee and you need to go re-find inputs which meet target_2 (= target + fee)
3212017-05-04T16:51:30 <morcos> you end up choosing fewer different inputs, have a lower fee, and now no change to dump the excess fee on
3222017-05-04T16:52:49 <sipa> why does CENT even still occur in the algorithm?
3232017-05-04T16:53:04 <morcos> actually, i used to hate that, now i think its the best part of the algorithm!
3242017-05-04T16:53:26 <morcos> its the goal size for change, it shouldn't be an exact target, but a minimum as i mentioned above
3252017-05-04T16:53: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
3262017-05-04T16:54:47 <morcos> what's silly is that if you can't get CENT, then you aim for 0.
3272017-05-04T16:54:48 *** Giszmo has quit IRC
3282017-05-04T16:55:25 *** Giszmo has joined #bitcoin-core-dev
3292017-05-04T16:55:29 <morcos> but i think the key improvement is to look at the net value of inputs in coin selection given the desired fee rate
3302017-05-04T16:56:20 *** timothy has quit IRC
3312017-05-04T16:56:37 <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
3322017-05-04T16:56:53 <morcos> the current algorithm throws in stupid inputs whose net_input_value is 0
3332017-05-04T16:56:58 <morcos> i mean negative
3342017-05-04T16:59:10 <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
3352017-05-04T17:04:28 *** Giszmo has quit IRC
3362017-05-04T17:05:25 *** anthonyjd has quit IRC
3372017-05-04T17:05:32 *** anthonyjd has joined #bitcoin-core-dev
3382017-05-04T17:14:22 <gmaxwell> morcos: I'd rather two two total solutions, e.g. a change and no-change solution, and then use post selection.
3392017-05-04T17:15:53 <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?
3402017-05-04T17:19:05 <bitcoin-git> [bitcoin] sipa opened pull request #10338: Maintain state across GetStrongRandBytes calls (master...stateful_rng) https://github.com/bitcoin/bitcoin/pull/10338
3412017-05-04T17:21:45 *** Giszmo has joined #bitcoin-core-dev
3422017-05-04T17:21:57 <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.
3432017-05-04T17:22:24 <gmaxwell> e.g. because the extra output increases the size, and then an extra input is needed... which increases the size further.
3442017-05-04T17:22:56 <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.
3452017-05-04T17:23:01 <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
3462017-05-04T17:23:10 <morcos> granted, the change output vs no change is strictly worse
3472017-05-04T17:23:29 <morcos> but that in my mind is a bit how you would go about figuring out whether you have an acceptable no change solution
3482017-05-04T17:23:38 <gmaxwell> it's true that you'll pay the fees eventually.
3492017-05-04T17:24:35 <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.
3502017-05-04T17:24:50 <morcos> yeah, that last part is important, but i think a complicated optimization
3512017-05-04T17:24:57 <morcos> maybe not ready for that yet
3522017-05-04T17:25:21 <morcos> i'm including a tiny bit of that in not being willing to spend most of inputs unless its a low confirm target
3532017-05-04T17:25:51 <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
3542017-05-04T17:26:20 <gmaxwell> it's a fair point that you don't want to tie up all your inputs on a rare 25-confirm-target payment.
3552017-05-04T17:26:21 <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
3562017-05-04T17:26:40 <morcos> yeah.. so many ways to so grade tx selection
3572017-05-04T17:26:41 <gmaxwell> Fair enough.
3582017-05-04T17:28:26 <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
3592017-05-04T17:29:35 <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
3602017-05-04T17:30:17 <instagibbs> sure, that seems to mesh. He said he got 50x more exact matches than Core. Which means it might be worth it.
3612017-05-04T17:30:33 <instagibbs> (on a real world scrubbed dataset)
3622017-05-04T17:31:40 <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.
3632017-05-04T17:32:08 <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.
3642017-05-04T17:33:12 <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.
3652017-05-04T17:33:53 <sipa> gmaxwell: but aiming for no change probably requires that every wallet permanently has a set of utxos of various sizes
3662017-05-04T17:34:02 <sipa> gmaxwell: which on itself may not be ideal
3672017-05-04T17:34:40 <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.
3682017-05-04T17:36:10 <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.
3692017-05-04T17:43:07 <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.
3702017-05-04T17:43:32 <gmaxwell> people get spazzy about automatic fees because they don't know what it could pay.
3712017-05-04T17:43:39 <gmaxwell> omg what if it pays all my monies!
3722017-05-04T17:46:33 *** Giszmo has quit IRC
3732017-05-04T18:05:05 *** Giszmo has joined #bitcoin-core-dev
3742017-05-04T18:10:36 *** elkalamar has joined #bitcoin-core-dev
3752017-05-04T18:27:20 *** d_t has joined #bitcoin-core-dev
3762017-05-04T18:27:31 <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
3772017-05-04T18:27:36 *** laurentmt has quit IRC
3782017-05-04T18:33:26 <cfields> sipa: ironic how?
3792017-05-04T18:34:59 <sipa> cfields: in that it would seem that getentropy is never useful on linux
3802017-05-04T18:35:14 <sipa> s/ironic/surprising/
3812017-05-04T18:35:18 <cfields> ah
3822017-05-04T18:37:45 *** talmai has joined #bitcoin-core-dev
3832017-05-04T18:38:18 <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 :)
3842017-05-04T18:38:59 *** talmai has quit IRC
3852017-05-04T18:39:01 <sipa> we could of course just hardcode the SYS_getrandom constant :p
3862017-05-04T18:39:05 * sipa ducks
3872017-05-04T18:39:12 <cfields> I suppose we could add a weak getrandom() that does the syscall and avoid the loops
3882017-05-04T18:39:15 <cfields> haha
3892017-05-04T18:39:27 *** d_t has quit IRC
3902017-05-04T18:45:27 <cfields> sipa: i find the logic harder to follow in your version :\
3912017-05-04T18:46:58 <cfields> i'm not sure if we want to cascade like that?
3922017-05-04T18:53:17 <sipa> ok, just a suggestion
3932017-05-04T18:57:43 *** PaulCapestany has quit IRC
3942017-05-04T19:00:12 *** praxeology has joined #bitcoin-core-dev
3952017-05-04T19:00:48 <sipa> yow
3962017-05-04T19:00:56 <sipa> meeting?
3972017-05-04T19:01:07 <sdaftuar> did anyone volunteer to chair?
3982017-05-04T19:01:13 <sipa> #startmeeting
3992017-05-04T19:01:13 <lightningbot> Meeting started Thu May 4 19:01:13 2017 UTC. The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
4002017-05-04T19:01:13 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4012017-05-04T19:01:23 <sipa> topics?
4022017-05-04T19:01:36 <BlueMatt> oh, wumpus is out?
4032017-05-04T19:01:41 <sipa> he is
4042017-05-04T19:01:45 <instagibbs> hi
4052017-05-04T19:01:51 <BlueMatt> #10337
4062017-05-04T19:01:52 <gribble> https://github.com/bitcoin/bitcoin/issues/10337 | Coin Control Dialog is not (very) useful for manual privacy protection · Issue #10337 · bitcoin/bitcoin · GitHub
4072017-05-04T19:01:56 <BlueMatt> :(
4082017-05-04T19:02:06 <jonasschnelli> Proposed low prio topic: HD restore update / questions
4092017-05-04T19:02:11 <sipa> #topic #10337
4102017-05-04T19:02:12 <gribble> https://github.com/bitcoin/bitcoin/issues/10337 | Coin Control Dialog is not (very) useful for manual privacy protection · Issue #10337 · bitcoin/bitcoin · GitHub
4112017-05-04T19:02:22 <sipa> gmaxwell: ping people?
4122017-05-04T19:02:30 <luke-jr> BlueMatt: I agree change shouldn't be grouped as it is, but I don't understand how "received by address" is wrong
4132017-05-04T19:02:38 <BlueMatt> turns out the coin control dialog is almost entirely useless
4142017-05-04T19:03:01 <jonasschnelli> BlueMatt: entierly useless? I disagree
4152017-05-04T19:03:08 <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
4162017-05-04T19:03:11 <luke-jr> BlueMatt: seems plenty useful to me
4172017-05-04T19:03:20 <BlueMatt> so it, essentially, picks an address at random if the output is change
4182017-05-04T19:03:24 <luke-jr> BlueMatt: I see different "received by address" for change too
4192017-05-04T19:03:34 <BlueMatt> and groups by it, which obviously isnt what you want for privacy
4202017-05-04T19:03:45 <BlueMatt> luke-jr: for addresses marked as change in the wallet? no
4212017-05-04T19:04:02 *** elkalamar has quit IRC
4222017-05-04T19:04:05 <luke-jr> BlueMatt: yes..
4232017-05-04T19:04:08 <BlueMatt> for random addresses of yours it should work, but not for addresses via getrawchangeaddress
4242017-05-04T19:04:23 <luke-jr> I don't use that RPC, but it works for normal change
4252017-05-04T19:04:26 <jtimon> hi
4262017-05-04T19:04:28 <BlueMatt> (or, ofc, normal change)
4272017-05-04T19:05:04 <BlueMatt> https://github.com/bitcoin/bitcoin/blob/master/src/qt/walletmodel.cpp#L620
4282017-05-04T19:05:35 <sipa> it sounds to me like it is doing a mix of "receive by address" and "linked grouping"
4292017-05-04T19:05:44 <sipa> both are perhaps useful
4302017-05-04T19:05:56 <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
4312017-05-04T19:06:06 <BlueMatt> sipa: well the change-output-results-in-random-grouping thing is kinda strange
4322017-05-04T19:06:20 <sipa> right, it shouldn't walk for receive address
4332017-05-04T19:06:35 <luke-jr> BlueMatt: I have nfc what that code does, but it *looks* right in the end window :/
4342017-05-04T19:06:39 <sipa> and it should alwaya walk (to some deterministic representative) for grouping
4352017-05-04T19:06:45 <sipa> *alwaya
4362017-05-04T19:06:48 <sipa> *alwayS
4372017-05-04T19:06:53 <BlueMatt> *always
4382017-05-04T19:07:11 <BlueMatt> but, yea, anyway, I think this should really emulate the grouping rpc
4392017-05-04T19:07:38 <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
4402017-05-04T19:07:38 <sipa> a "received by address" is still useful i think, but it's not the same as grouping
4412017-05-04T19:07:50 <kanzure> hi.
4422017-05-04T19:07:51 <BlueMatt> yes, but if it is not received directly, it should be "Change"
4432017-05-04T19:08:03 <sipa> BlueMatt: seems reasonable to me
4442017-05-04T19:08:28 <BlueMatt> anyway, other topics?
4452017-05-04T19:08:39 <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
4462017-05-04T19:08:47 <sipa> #topic HD restore update
4472017-05-04T19:08:57 <jonasschnelli> #10240
4482017-05-04T19:08:58 <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
4492017-05-04T19:09:14 <jonasschnelli> I have worked out a solution that seems to work for encrypted and encrypted&pruned wallets.
4502017-05-04T19:09:17 * BlueMatt wonders why we cant have a derivation key which is not encrypted in our wallet so taht we dont have to pause sync
4512017-05-04T19:09:24 <jonasschnelli> It can halt the sync / validation progress.
4522017-05-04T19:09:34 <jonasschnelli> But,.. I'm not sure what gap limit and default keypool size we should use
4532017-05-04T19:09:35 <BlueMatt> (to generate new keys)
4542017-05-04T19:09:38 <jonasschnelli> 100 and 20 seems very little
4552017-05-04T19:10:10 <sipa> BlueMatt: that requires non-hardened derivation
4562017-05-04T19:10:19 <jonasschnelli> BlueMatt: IMO encryption (private key wallets) with public key derivation should be avoided
4572017-05-04T19:10:32 <BlueMatt> sipa: yes, is that a concern?
4582017-05-04T19:10:41 <sipa> BlueMatt: yes, we have a dumpprivkey command
4592017-05-04T19:10:54 <jonasschnelli> We should aim â longterm â for watchonly-hd (see NicolasDorier workd) and add a signing-agent ala gpg / ssh
4602017-05-04T19:10:56 <sipa> leaking one private key means you leak your whole walley
4612017-05-04T19:11:09 <BlueMatt> jonasschnelli: why? your list of funds is already public to the encrypted wallet holders? that wouldnt change?
4622017-05-04T19:11:13 <jonasschnelli> But that is alredy the next topic. :)
4632017-05-04T19:11:25 <luke-jr> sipa: dumpprivkey isn't supposed to be safe
4642017-05-04T19:11:32 <sipa> luke-jr: i know
4652017-05-04T19:11:36 <luke-jr> but we could make it fail for non-hardened keys?
4662017-05-04T19:11:43 <sipa> luke-jr: but it breaks expectations
4672017-05-04T19:11:52 <sipa> people have a mental model about how it works
4682017-05-04T19:12:15 <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?
4692017-05-04T19:12:19 <BlueMatt> sipa: and then that would not be the case
4702017-05-04T19:12:21 <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
4712017-05-04T19:12:32 <BlueMatt> (dont know the format of HD, but we could do something else if its way better)
4722017-05-04T19:12:47 <sipa> BlueMatt: if you have the parent public key + private child key, you can compute all private child keys
4732017-05-04T19:12:57 <jonasschnelli> If we would do child pubkey derivation, keypools could be removed (at least for HD)
4742017-05-04T19:13:05 <sipa> BlueMatt: that is an inevitable weakness of EC based derivation
4752017-05-04T19:13:19 <jonasschnelli> What sipa said
4762017-05-04T19:13:20 <sipa> BlueMatt: and it is reason why bip32 has hardened keys
4772017-05-04T19:13:30 <sipa> which core uses
4782017-05-04T19:13:31 <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?
4792017-05-04T19:13:53 <sipa> BlueMatt: then you lose public derivation
4802017-05-04T19:14:13 <sipa> (the ability to compute child pubkeys without knowing the parent privkey)
4812017-05-04T19:14:25 <BlueMatt> lets take this offline
4822017-05-04T19:14:29 <sipa> sounds good
4832017-05-04T19:14:35 <jonasschnelli> back to the topic: what GAP limit should we enforce by default?
4842017-05-04T19:14:45 <BlueMatt> 1000
4852017-05-04T19:14:52 <BlueMatt> default keypool 10k
4862017-05-04T19:14:54 <jonasschnelli> Yeah.. I like this
4872017-05-04T19:15:01 <jonasschnelli> But only for encrypted wallets?
4882017-05-04T19:15:09 <jonasschnelli> IMO we should (only encrypted)
4892017-05-04T19:15:10 <sipa> but in general i believe that most cases where the public derivation is wanted, just use huge precomputed key lists
4902017-05-04T19:15:14 <jonasschnelli> non encrypted can say with 100
4912017-05-04T19:15:18 <sipa> jonasschnelli: meh
4922017-05-04T19:15:26 <sipa> why bother differentiating?
4932017-05-04T19:15:28 <gmaxwell> why only encryption? I don't think that makes sense.
4942017-05-04T19:15:36 <jonasschnelli> True, the gap limit must be the same.. right
4952017-05-04T19:15:41 <jonasschnelli> sry
4962017-05-04T19:15:42 <gmaxwell> less complexity please, and keys are cheap.
4972017-05-04T19:15:59 <jonasschnelli> Okay, ... I'll bump it to 1000
4982017-05-04T19:16:10 <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
4992017-05-04T19:16:29 <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
5002017-05-04T19:16:30 <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
5012017-05-04T19:16:34 <jonasschnelli> Is that a problem?
5022017-05-04T19:16:36 <gmaxwell> jtimon: thanks for working on that.
5032017-05-04T19:17:22 <jonasschnelli> (but maybe take the test question offline).
5042017-05-04T19:17:37 <jonasschnelli> Well,.. keypool size is answered... all good. Thanks for reviews. :p
5052017-05-04T19:17:51 <jtimon> gmaxwell: no problem, thank you for pointing it out the other day
5062017-05-04T19:18:16 *** tripleslash has quit IRC
5072017-05-04T19:19:09 <jonasschnelli> other topics?
5082017-05-04T19:19:43 <BlueMatt> review, review, review, review, review :)
5092017-05-04T19:19:53 <sipa> yes, let's go over priority reviews
5102017-05-04T19:20:04 <jonasschnelli> https://github.com/bitcoin/bitcoin/projects/8
5112017-05-04T19:20:05 <sipa> #topic review requests
5122017-05-04T19:20:17 <Chris_Stewart_5> Can #9980 be merged? Might be some what controversial
5132017-05-04T19:20:23 <gribble> https://github.com/bitcoin/bitcoin/issues/9980 | Fix mem access violation merkleblock by Christewart · Pull Request #9980 · bitcoin/bitcoin · GitHub
5142017-05-04T19:20:35 <BlueMatt> Chris_Stewart_5: we're super backlogged on review right now :(
5152017-05-04T19:20:40 <Chris_Stewart_5> I thought jnewberry did a good job with the comments
5162017-05-04T19:20:53 *** tripleslash has joined #bitcoin-core-dev
5172017-05-04T19:20:56 <jonasschnelli> Chris_Stewart_5: I can't see an tested or untested ACK there
5182017-05-04T19:21:10 <BlueMatt> like, super backlogged-not-gonna-get-everything-for-0.15 backlogged :(
5192017-05-04T19:21:30 <Chris_Stewart_5> That's fine :-). Thought I would bring it up since asking for topics
5202017-05-04T19:21:39 <BlueMatt> we can add it to the review heap
5212017-05-04T19:22:10 <BlueMatt> can we remove #8694 until it gets fixed+rebased?
5222017-05-04T19:22:13 <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
5232017-05-04T19:22:25 <BlueMatt> it seems to have been in a constant state of not-reviewable since it was added to the "high priority for review"
5242017-05-04T19:22:26 <instagibbs> sorry, when it 0.15 feature freeze
5252017-05-04T19:22:31 <jonasschnelli> luke-jr: plans to rebase it?
5262017-05-04T19:22:50 <BlueMatt> instagibbs: 2017-07-16
5272017-05-04T19:22:58 <instagibbs> eep, ok
5282017-05-04T19:23:25 <jonasschnelli> I though MW was one of the high profiled features targets for 0.15..
5292017-05-04T19:23:27 <jtimon> is there anything else that needs to be done for #9494 ?
5302017-05-04T19:23:28 <luke-jr> I just did? :/
5312017-05-04T19:23:28 <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
5322017-05-04T19:23:29 <BlueMatt> sdaftuar: asks for #9208
5332017-05-04T19:23:31 <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
5342017-05-04T19:23:56 <luke-jr> not really sure how to address the mapMultiArgs thing
5352017-05-04T19:24:03 <luke-jr> besides refactoring everything using it
5362017-05-04T19:24:06 <jonasschnelli> I add 9208 to the review-prio-list
5372017-05-04T19:24:09 <jtimon> on the list we have #8855 from me, which remains being simple to review
5382017-05-04T19:24:11 <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
5392017-05-04T19:24:27 <BlueMatt> jonasschnelli: you already have one
5402017-05-04T19:24:39 <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.
5412017-05-04T19:24:39 <jonasschnelli> BlueMatt: It's sdaftuar. :P
5422017-05-04T19:24:47 *** tripleslash has quit IRC
5432017-05-04T19:24:52 <BlueMatt> ohoh
5442017-05-04T19:24:54 <BlueMatt> yes, sorry
5452017-05-04T19:24:55 <jtimon> luke-jr: refactoring everything that uses mapMultiArgs is what #9494 does
5462017-05-04T19:24:57 <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
5472017-05-04T19:24:57 <jonasschnelli> No worries... I protect the ratio. :)
5482017-05-04T19:25:05 <BlueMatt> jonasschnelli: I read that as "add for me", not "added"
5492017-05-04T19:25:05 <luke-jr> jtimon: k, I'll take a look
5502017-05-04T19:25:09 <instagibbs> jtimon, will review
5512017-05-04T19:25:18 <cfields> gmaxwell: agreed
5522017-05-04T19:25:20 <jtimon> awesome, thanks
5532017-05-04T19:25:58 <sipa> let's put 9494 on the list this week
5542017-05-04T19:26:04 <BlueMatt> either way, #8694 probably needs deleted
5552017-05-04T19:26:04 *** tripleslash has joined #bitcoin-core-dev
5562017-05-04T19:26:06 <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
5572017-05-04T19:26:11 <luke-jr> BlueMatt: why?
5582017-05-04T19:26:12 <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)
5592017-05-04T19:26:20 <BlueMatt> luke-jr: because its not reviewable?
5602017-05-04T19:26:20 <luke-jr> oh, from the list only, ok
5612017-05-04T19:26:25 <BlueMatt> yeayea
5622017-05-04T19:26:34 <sipa> i want to keep 8694 as a priority for 0.15
5632017-05-04T19:26:51 <jonasschnelli> #8855 is already in the list by jtimon
5642017-05-04T19:26:52 <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
5652017-05-04T19:26:52 <jtimon> sipa: there's already one from me on the list
5662017-05-04T19:27:08 <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
5672017-05-04T19:27:23 <sipa> BlueMatt: agree
5682017-05-04T19:27:44 <sipa> jtimon: let's focus on the args refactoring first... it seems that that will more easily go stale
5692017-05-04T19:27:49 <luke-jr> 0.15 and priority-review are two diff lists for a reason; let's do jtimon's PR first
5702017-05-04T19:28:09 <sipa> luke-jr: agree
5712017-05-04T19:28:59 <sipa> any further topics?
5722017-05-04T19:29:13 <gmaxwell> sipa: where are things with per-txo?
5732017-05-04T19:29:31 <jonasschnelli> #10195
5742017-05-04T19:29:33 <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
5752017-05-04T19:29:37 <BlueMatt> gmaxwell: needs more review, could use side-by-side benchmarks incl: memory usage, disk usage, performance numbers
5762017-05-04T19:29:50 <sipa> yes, i'm planning to do benchmarks
5772017-05-04T19:30:19 <gmaxwell> BlueMatt: "much faster"
5782017-05-04T19:30:28 <sipa> other todos are better upgrade code (with a fancy progress bar...), that doesn't leave gigabytes of uncompacted data in the chainstate
5792017-05-04T19:30:41 <sipa> but i believe it is functionally complete and tested
5802017-05-04T19:31:00 *** Sosumi has quit IRC
5812017-05-04T19:31:45 <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
5822017-05-04T19:31:46 <sipa> it seems to make the chainstate some 20% larger
5832017-05-04T19:32:18 <sipa> i'll report numbers on the PR, no need to discuss here
5842017-05-04T19:32:24 <sipa> BlueMatt: ack
5852017-05-04T19:32:31 <sipa> #endmeeting
5862017-05-04T19:32:31 <lightningbot> Meeting ended Thu May 4 19:32:31 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5872017-05-04T19:32:31 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-04-19.01.html
5882017-05-04T19:32:31 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-04-19.01.txt
5892017-05-04T19:32:31 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-04-19.01.log.html
5902017-05-04T19:32:38 <sipa> #topic lunch
5912017-05-04T19:32:54 <luke-jr> ._.
5922017-05-04T19:33:08 <jonasschnelli> sipa: those 120% happens also for the in-memory dbcache?
5932017-05-04T19:33:15 <jonasschnelli> *those +20%
5942017-05-04T19:33:18 <sipa> jonasschnelli: in memory it's much more
5952017-05-04T19:33:31 <sipa> but that's not a fair comparison
5962017-05-04T19:33:46 <jtimon> of "preparation PRs" for 10195: 10249 10250 have been merged, 10248 has not, still 24 commits...
5972017-05-04T19:33:58 <sipa> as it's much more granular, fewer cached outputs may have better performamce
5982017-05-04T19:34:12 <sipa> #10248
5992017-05-04T19:34:13 <gribble> https://github.com/bitcoin/bitcoin/issues/10248 | Introduce CHashVerifier to hash while deserializing by sipa · Pull Request #10248 · bitcoin/bitcoin · GitHub
6002017-05-04T19:34:31 <sipa> jtimon: most are small, but yes, it's a big change
6012017-05-04T19:35:08 <BlueMatt> also #10199 is pretty critical for 0.15
6022017-05-04T19:35:10 <gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
6032017-05-04T19:35:16 <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
6042017-05-04T19:35:22 * BlueMatt votes for 10199 as most-critical user-facing feature, maybe multiwallet too
6052017-05-04T19:35:24 <cfields> I think #10189 is ready to go, and it's blocking a few people. jtimon at least.
6062017-05-04T19:35:26 <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
6072017-05-04T19:35:55 <sipa> i could use 10189 for some of the changes in 10195 as well
6082017-05-04T19:38:07 <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
6092017-05-04T19:41:38 <sipa> jtimon: looks like something for developer-notes.md
6102017-05-04T19:41:40 <cfields> jtimon: thanks!
6112017-05-04T19:42:00 <cfields> jtimon: not sure what 3) is saying through
6122017-05-04T19:42:22 <jtimon> sipa: right, well, cfields feel free to use whatever parts of it make sense to you
6132017-05-04T19:42:57 <cfields> jtimon: lgtm, I'm just not following that one part
6142017-05-04T19:43:54 <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
6152017-05-04T19:44:13 <jtimon> maybe we can keep it out, I don't know
6162017-05-04T19:45:22 <cfields> jtimon: oh, i see.
6172017-05-04T19:47:04 <cfields> jtimon: maybe just say "1) Writer: apply your script to a clean tree and commit with an appropriate message:"
6182017-05-04T19:47:30 <cfields> then list the other steps. I was confused because you mention committing before running the script :)
6192017-05-04T19:50:26 <praxeology> While upgrading the chainstate to keying on id+o.ix, does it pretty much freeze the init process of the program?
6202017-05-04T19:50:37 <sipa> praxeology: yeah...
6212017-05-04T19:50:45 <sipa> praxeology: and it takes a while
6222017-05-04T19:51:03 <praxeology> Sounds like you are using the same db, not trying to make a new one?
6232017-05-04T19:51:09 <sipa> indeed
6242017-05-04T19:51:11 <jtimon> cfields: yeah that may do it without explicitly saying the "git checkout ." trick
6252017-05-04T19:51:32 <sipa> praxeology: it's an in-place upgrade, and it is interruotible
6262017-05-04T19:53:09 <praxeology> interruptible? so you make the new entries, then delete the old ones? and if interrupt, you delete the new ones?
6272017-05-04T19:56:10 <sipa> it adds and deletes simultaneously, atomically
6282017-05-04T19:56:19 <sipa> you can just kill it at any point
6292017-05-04T19:57:25 <praxeology> so the new code can handle lookup and editing of both kinds of entries?
6302017-05-04T20:00:03 *** tripleslash has quit IRC
6312017-05-04T20:00:04 <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
6322017-05-04T20:00:47 <sipa> praxeology: no, at startup it just iterates through all old entries and converts them
6332017-05-04T20:01:03 <sipa> if you interrupt during that conversion, you need to continue later
6342017-05-04T20:01:16 *** tripleslash has joined #bitcoin-core-dev
6352017-05-04T20:01:18 <sipa> but by interruptible i mean you don't lose progress from doing that
6362017-05-04T20:01:56 <praxeology> "need to continue later" or else your client doesn't process new blocks/transactions?
6372017-05-04T20:02:22 <gmaxwell> when the software restarts it will continue where it left off.
6382017-05-04T20:02:34 <gmaxwell> this is all in the init process before it even makes any connections to anything.
6392017-05-04T20:02:48 <sipa> praxeology: by interrupt i mean you quit during the conversion
6402017-05-04T20:02:59 <sipa> praxeology: the node can't do anything until the conversion is complete
6412017-05-04T20:03:09 <praxeology> ok I see
6422017-05-04T20:04:05 *** jtimon has quit IRC
6432017-05-04T20:04:13 <sipa> it would be possible to do the conversion on the fly, but it would result in a long term slowdown
6442017-05-04T20:04:38 <praxeology> also more complicated code that only need be used once
6452017-05-04T20:05:26 <praxeology> Are you making the upgrade optional?
6462017-05-04T20:05:30 <sipa> no
6472017-05-04T20:06:07 <sipa> the new database code cannot read or write the old format anymore, and supporting that would be complicated and slow
6482017-05-04T20:06:10 <gmaxwell> It's optional: don't use newer software if you don't want it upgrading.
6492017-05-04T20:06:13 <gmaxwell> :)
6502017-05-04T20:06:24 <praxeology> Alrighty... I can see why this would be a delayed commit to the main branch.
6512017-05-04T20:07:48 *** Dyaheon has quit IRC
6522017-05-04T20:08:03 <praxeology> I wish I could clone myself
6532017-05-04T20:08:15 <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.
6542017-05-04T20:08:35 *** Dyaheon has joined #bitcoin-core-dev
6552017-05-04T20:09:32 <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?
6562017-05-04T20:10:18 <sipa> maybe an hour on slow hardware
6572017-05-04T20:10:29 <sipa> slow disk, mostly
6582017-05-04T20:10:47 <gmaxwell> 15 minutes minutes on fast hardware, I'd guess?
6592017-05-04T20:10:53 <sipa> yeah
6602017-05-04T20:10:54 <praxeology> and then is leveldb optimized to handle such a db transformation? And does it compress well after deleting all the old entries?
6612017-05-04T20:11:23 <sipa> nope, it seems
6622017-05-04T20:11:31 <sipa> but there is an explicit call to ask it to compact
6632017-05-04T20:11:36 <sipa> which i'll experiment with
6642017-05-04T20:11:47 <praxeology> Why not create a new db?
6652017-05-04T20:12:05 <sipa> Why create a new db?
6662017-05-04T20:12:22 <praxeology> if leveldb has bad performance w/ this sort of transformation
6672017-05-04T20:12:58 <sipa> calling db.CompactRange(); is much simpler than dealing with multiple database at once during the conversion
6682017-05-04T20:13:28 <praxeology> because you want atomic?
6692017-05-04T20:13:32 <gmaxwell> praxeology: it doesn't have bad performance.
6702017-05-04T20:13:40 <sipa> praxeology: no...
6712017-05-04T20:14:00 <sipa> praxeology: the argument you're bringing up in favor of multiple databases is because leveldb doesn't deal well with the conversion
6722017-05-04T20:14:15 <sipa> i offer an alternative to having multiple databases at once which also deals well with the conversion
6732017-05-04T20:14:27 <sipa> which is simpler
6742017-05-04T20:14:31 <praxeology> ok
6752017-05-04T20:14:43 <gmaxwell> You need to ask it to free the space or its very lazy about it, thats all.
6762017-05-04T20:15:45 <gmaxwell> Unrelated, while watching a debug=1 logging rescan.. why is it battering out leveldb activity during rescan?
6772017-05-04T20:16:01 <sipa> gmaxwell: huh
6782017-05-04T20:16:55 <gmaxwell> https://0bin.net/paste/VZ72NOA3G8n-lgpF#FXx9b3te-4BbUbBH7BfGjjpXOOWUiJmL1YToCU6HRHG
6792017-05-04T20:17: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
6802017-05-04T20:17:22 <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.
6812017-05-04T20:17:40 <gmaxwell> praxeology: ya, thats what he's going to have it do now.
6822017-05-04T20:17:58 <sipa> gmaxwell: that looks like just background compactions
6832017-05-04T20:18:05 <gmaxwell> e.g. every time the leading byte of the key changes, compact.
6842017-05-04T20:21:09 <praxeology> I've heard rumors that leveldb is unreliable. Is that still true?
6852017-05-04T20:21:50 <sipa> praxeology: see my answer here https://bitcoin.stackexchange.com/a/51446/208
6862017-05-04T20:22:57 *** tw2006 has quit IRC
6872017-05-04T20:25:07 <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
6882017-05-04T20:25:13 <gmaxwell> or not handling crashes given worst case behavior of the the VFS contract that they inferred.
6892017-05-04T20:25:45 <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.
6902017-05-04T20:26:19 <gmaxwell> When we do get reliablity reports from users we sometimes investigate them in detail, and frequently find actual disk corruption.
6912017-05-04T20:26:37 <gmaxwell> Unfortunately, there is a lot of windows-grade hardware out there.
6922017-05-04T20:26:38 <sipa> or overheating CPUs
6932017-05-04T20:27:03 <praxeology> I would guess memory failure would be more common that cpu failure in my experience
6942017-05-04T20:27:32 <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).
6952017-05-04T20:28:00 <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)
6962017-05-04T20:29:09 <gmaxwell> well it could be ram which behaves more poorly with the cpu taxing the power rails and making things hot. who knows.
6972017-05-04T20:30:23 <praxeology> I've had terrible experience with cheap consumer memory from lower cost computer brands, when operating under load
6982017-05-04T20:30:53 <sipa> i think we're seeing fewer db corruptions than a few years ago
6992017-05-04T20:31:07 <praxeology> Are you saying there are still issues with crash recovery in windows?
7002017-05-04T20:31:08 <sipa> that may be due to better windows env support in leveldb
7012017-05-04T20:31:20 <sipa> or due to people running on better hardware
7022017-05-04T20:31:49 <sipa> or just fewer people running bitcoin core on windows
7032017-05-04T20:32:09 <sipa> not all corruption reports are on windows, to be clear
7042017-05-04T20:32:17 <sipa> but historically those were a majority
7052017-05-04T20:32:53 <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
7062017-05-04T20:34:47 <sipa> praxeology: ha, that's good to know
7072017-05-04T20:35:01 <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
7082017-05-04T20:35:12 <sipa> thanks regardless!
7092017-05-04T20:35:29 *** jtimon has joined #bitcoin-core-dev
7102017-05-04T20:36:41 <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.
7112017-05-04T20:46:40 *** chjj has quit IRC
7122017-05-04T20:47:52 <BlueMatt> jonasschnelli: you might kill me for #10340, sorry :/
7132017-05-04T20:47:53 <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
7142017-05-04T20:47:54 <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
7152017-05-04T20:54:57 *** Guyver2 has quit IRC
7162017-05-04T20:59:24 *** chjj has joined #bitcoin-core-dev
7172017-05-04T21:23:58 *** tw2006 has joined #bitcoin-core-dev
7182017-05-04T21:28:29 *** tw2006 has quit IRC
7192017-05-04T21:45:15 *** laurentmt has joined #bitcoin-core-dev
7202017-05-04T21:57:22 *** goksinen has quit IRC
7212017-05-04T21:57:30 <luke-jr> hmm, master doesn't seem to build for me
7222017-05-04T21:58:27 <sipa> what error?
7232017-05-04T22:00:26 <luke-jr> wallet/rpcwallet.cpp:732:98: error: taking address of temporary [-fpermissive]
7242017-05-04T22:02:14 <luke-jr> I'm not entirely clear why this shouldn't be okay
7252017-05-04T22:02:23 <luke-jr> it's returning a reference
7262017-05-04T22:03:24 <gmaxwell> you can't return a reference to something on the stack.. which is what that sounds like?
7272017-05-04T22:03:59 <luke-jr> no, the univalue method is returning a reference to a member
7282017-05-04T22:04:01 <luke-jr> const std::string* account = request.params[0].get_str() != "*" ? &request.params[0].get_str() : nullptr;
7292017-05-04T22:04:10 <luke-jr> GCC doesn't like us taking the pointer of it for some reason
7302017-05-04T22:04:18 <sipa> that's invalid
7312017-05-04T22:04:28 <sipa> it's taking a pointer to a temporary
7322017-05-04T22:04:42 <sipa> ah, wait
7332017-05-04T22:05:36 <luke-jr> FWIW, this didn't fail until I disabled ccache, so I suspect it's a new error
7342017-05-04T22:05:54 <luke-jr> GCC 5.4
7352017-05-04T22:06:35 *** elkalamar has joined #bitcoin-core-dev
7362017-05-04T22:11:33 *** goksinen has joined #bitcoin-core-dev
7372017-05-04T22:16:27 *** goksinen has quit IRC
7382017-05-04T22:24:58 *** tw2006 has joined #bitcoin-core-dev
7392017-05-04T22:29:41 *** tw2006 has quit IRC
7402017-05-04T22:37:35 <ryanofsky> i think i added the line causing that error, but i also don't see why it's an error
7412017-05-04T22:40:09 *** justanotheruser has joined #bitcoin-core-dev
7422017-05-04T22:58:44 *** vicenteH` has quit IRC
7432017-05-04T23:14:15 *** juscamarena_ has quit IRC
7442017-05-04T23:14:20 *** jannes has quit IRC
7452017-05-04T23:25:42 *** tw2006 has joined #bitcoin-core-dev
7462017-05-04T23:30:26 *** tw2006 has quit IRC
7472017-05-04T23:32:54 *** Dyaheon has quit IRC
7482017-05-04T23:33:21 *** Dyaheon has joined #bitcoin-core-dev
7492017-05-04T23:43:43 *** str4d has joined #bitcoin-core-dev
7502017-05-04T23:57:11 *** str4d has quit IRC
7512017-05-04T23:58:31 *** abpa has quit IRC