12020-04-02T00:00:01 *** kenperkins has quit IRC
22020-04-02T00:18:07 *** AaronvanW has quit IRC
32020-04-02T00:19:30 *** millerti has quit IRC
42020-04-02T00:22:26 *** Wolfy87 has joined #bitcoin-core-dev
52020-04-02T00:23:31 <instagibbs> achow101, re https://github.com/bitcoin/bitcoin/pull/16528#issuecomment-607520569
62020-04-02T00:24:19 <instagibbs> We should think long and hard about use-cases that don't involve importing addresses. I think importing "mixed" descriptors where you own some privkeys but not all seems like something to look at?
72020-04-02T00:26:02 <achow101> instagibbs: sure
82020-04-02T00:26:17 <instagibbs> i dont think the "mutation" is as bad provided the user is asking for those sigs
92020-04-02T00:26:19 <instagibbs> fwiw
102020-04-02T00:26:45 <instagibbs> the ismine cleanup is much more important, making sure you don't think you got paid at an address you gave to someone
112020-04-02T00:27:22 <achow101> i guess we want the wallet to behave in two different ways: 1) deal with scripts and track transactions related to those scripts; and 2) be a signer that has keys and just signs things ignoring the scripts
122020-04-02T00:27:25 <instagibbs> sign loosely(provided user knows what they are signing), accept strictly
132020-04-02T00:29:00 <instagibbs> So I think it's probably ok to eagerly sign whatever you can when asked, and separately support importing descriptors where you don't have all the keys(this should just make signing easier?)
142020-04-02T00:29:40 <achow101> right
152020-04-02T00:30:24 <instagibbs> Hm, something to mull over.
162020-04-02T00:30:59 <achow101> there's also a bunch of places in the tests that use dumpprivkey to just get a private key for imports and stuff
172020-04-02T00:30:59 <instagibbs> Is it too asinine to only allow xpubs, then multiwallet to have the xprv in another wallet?
182020-04-02T00:31:15 <instagibbs> but yeah no export
192020-04-02T00:31:20 <instagibbs> that's the rub eh
202020-04-02T00:31:23 <achow101> but no export means those don't work
212020-04-02T00:31:39 <achow101> i suppose we could add something to the test framework to generate private keys
222020-04-02T00:31:55 <instagibbs> It seems like a very reasonable use-case to support.
232020-04-02T00:32:20 <instagibbs> Core-generated key being in a multisig :)
242020-04-02T00:32:44 <achow101> my original thoughts about the multisig stuff would be you have 2 wallets, one generated normally, and another watch only one for the multisig. so you then use psbt and multiwallet
252020-04-02T00:33:02 <instagibbs> what's the hold-up on export? feature creep?
262020-04-02T00:33:15 <achow101> security questions about unhardened derivation
272020-04-02T00:34:24 <instagibbs> oh im overthinking, use-case is supported, *if* you can get the account-level xpub
282020-04-02T00:34:31 <instagibbs> i can't recall what your PR supports
292020-04-02T00:34:51 <achow101> currently no exports at all whatoever
302020-04-02T00:35:17 <instagibbs> ok so I think public descriptor export is a thing we'd want to support
312020-04-02T00:35:31 <achow101> yeah
322020-04-02T00:35:36 <achow101> that'll be next
332020-04-02T00:38:01 *** ddustin_ has quit IRC
342020-04-02T00:38:31 *** ddustin has joined #bitcoin-core-dev
352020-04-02T00:42:57 *** ddustin has quit IRC
362020-04-02T00:45:34 <sipa> achow101: i don't think being able to sign for non-"ismine" things is a problem
372020-04-02T00:45:40 <sipa> as long as they're not counted
382020-04-02T00:49:03 *** captjakk has quit IRC
392020-04-02T01:15:56 *** promag_ has quit IRC
402020-04-02T01:17:55 *** Highway61 has joined #bitcoin-core-dev
412020-04-02T01:22:17 *** Highway61 has quit IRC
422020-04-02T01:29:28 *** mdunnio has quit IRC
432020-04-02T01:29:49 *** Karyon has quit IRC
442020-04-02T01:32:38 *** Karyon has joined #bitcoin-core-dev
452020-04-02T01:46:24 *** PaulTroon has joined #bitcoin-core-dev
462020-04-02T01:51:17 *** PaulTroon has quit IRC
472020-04-02T01:59:40 *** Highway61 has joined #bitcoin-core-dev
482020-04-02T02:04:20 *** Highway61 has quit IRC
492020-04-02T02:07:34 *** captjakk has joined #bitcoin-core-dev
502020-04-02T02:08:28 *** captjakk has quit IRC
512020-04-02T02:14:42 *** promag has joined #bitcoin-core-dev
522020-04-02T02:14:44 *** AaronvanW has joined #bitcoin-core-dev
532020-04-02T02:15:29 *** Karyon has quit IRC
542020-04-02T02:23:51 *** promag has quit IRC
552020-04-02T02:24:04 *** Highway61 has joined #bitcoin-core-dev
562020-04-02T02:24:31 *** ccdle12 has quit IRC
572020-04-02T02:30:34 *** Highway61 has quit IRC
582020-04-02T02:43:35 *** captjakk has joined #bitcoin-core-dev
592020-04-02T02:48:03 *** captjakk has quit IRC
602020-04-02T02:48:32 *** AaronvanW has quit IRC
612020-04-02T02:53:07 *** TheHoliestRoger has quit IRC
622020-04-02T02:54:43 *** promag__ has quit IRC
632020-04-02T03:00:01 *** Wolfy87 has quit IRC
642020-04-02T03:48:43 *** xrogaan has joined #bitcoin-core-dev
652020-04-02T03:49:07 *** xrogaan is now known as Guest17873
662020-04-02T03:53:27 *** Eagle[TM] has joined #bitcoin-core-dev
672020-04-02T03:55:05 *** EagleTM has quit IRC
682020-04-02T03:56:34 *** TheHoliestRoger has joined #bitcoin-core-dev
692020-04-02T04:05:29 *** mol has quit IRC
702020-04-02T04:30:41 *** oguzkoroglu has joined #bitcoin-core-dev
712020-04-02T04:41:23 *** andrewtoth has quit IRC
722020-04-02T04:45:33 *** AaronvanW has joined #bitcoin-core-dev
732020-04-02T05:15:18 *** oguzkoroglu has quit IRC
742020-04-02T05:18:13 *** AaronvanW has quit IRC
752020-04-02T05:25:19 *** jonatack__ has joined #bitcoin-core-dev
762020-04-02T05:25:27 *** oguzkoroglu has joined #bitcoin-core-dev
772020-04-02T05:27:27 *** ogu has joined #bitcoin-core-dev
782020-04-02T05:28:11 *** jonatack_ has quit IRC
792020-04-02T05:30:22 *** oguzkoroglu has quit IRC
802020-04-02T05:32:52 *** ogu has quit IRC
812020-04-02T05:33:05 *** ogu has joined #bitcoin-core-dev
822020-04-02T05:33:57 *** oguzkoroglu has joined #bitcoin-core-dev
832020-04-02T05:48:35 *** PaulTroon has joined #bitcoin-core-dev
842020-04-02T05:48:46 <fanquake> wumpus / sipa: can you block Angelika1920
852020-04-02T05:52:08 *** Kiminuo has quit IRC
862020-04-02T05:53:23 *** PaulTroon has quit IRC
872020-04-02T05:59:16 *** bitcoin-git has joined #bitcoin-core-dev
882020-04-02T05:59:17 <bitcoin-git> [bitcoin] fanquake closed pull request #18489: Rebrand to Bitcoin Corrr (master...2004-rebrandCorrr) https://github.com/bitcoin/bitcoin/pull/18489
892020-04-02T05:59:28 *** bitcoin-git has left #bitcoin-core-dev
902020-04-02T06:00:02 *** Guest17873 has quit IRC
912020-04-02T06:00:08 *** Kiminuo has joined #bitcoin-core-dev
922020-04-02T06:07:54 *** mol has joined #bitcoin-core-dev
932020-04-02T06:19:59 *** michal_kubenka has joined #bitcoin-core-dev
942020-04-02T06:32:39 *** ghost43 has quit IRC
952020-04-02T06:32:43 *** per has quit IRC
962020-04-02T06:32:54 *** per has joined #bitcoin-core-dev
972020-04-02T06:33:32 *** ghost43 has joined #bitcoin-core-dev
982020-04-02T06:52:18 *** PaulTroon has joined #bitcoin-core-dev
992020-04-02T07:04:30 *** mol has quit IRC
1002020-04-02T07:15:19 *** AaronvanW has joined #bitcoin-core-dev
1012020-04-02T07:19:56 *** captjakk has joined #bitcoin-core-dev
1022020-04-02T07:21:18 *** manantial has joined #bitcoin-core-dev
1032020-04-02T07:24:54 *** captjakk has quit IRC
1042020-04-02T07:24:59 <wumpus> fanquake: done
1052020-04-02T07:29:17 *** mrostecki has quit IRC
1062020-04-02T07:29:18 *** TheFuzzStone[m] has quit IRC
1072020-04-02T07:29:22 *** icota[m] has quit IRC
1082020-04-02T07:41:02 *** vasild_ has joined #bitcoin-core-dev
1092020-04-02T07:44:03 *** vasild has quit IRC
1102020-04-02T07:44:04 *** vasild_ is now known as vasild
1112020-04-02T07:44:58 *** ghost43 has quit IRC
1122020-04-02T07:46:17 *** ghost43 has joined #bitcoin-core-dev
1132020-04-02T07:48:39 *** AaronvanW has quit IRC
1142020-04-02T07:54:18 *** Guyver2 has joined #bitcoin-core-dev
1152020-04-02T07:56:03 *** TheFuzzStone[m] has joined #bitcoin-core-dev
1162020-04-02T08:02:35 *** icota[m] has joined #bitcoin-core-dev
1172020-04-02T08:02:35 *** mrostecki has joined #bitcoin-core-dev
1182020-04-02T08:14:36 *** jarthur_ has joined #bitcoin-core-dev
1192020-04-02T08:17:26 *** jarthur has quit IRC
1202020-04-02T08:25:28 *** AaronvanW has joined #bitcoin-core-dev
1212020-04-02T08:28:06 *** Talkless has joined #bitcoin-core-dev
1222020-04-02T08:31:16 *** marcoagner has joined #bitcoin-core-dev
1232020-04-02T08:31:52 *** ghost43 has quit IRC
1242020-04-02T08:33:09 *** ghost43 has joined #bitcoin-core-dev
1252020-04-02T08:34:48 *** AaronvanW has quit IRC
1262020-04-02T08:37:07 *** AaronvanW has joined #bitcoin-core-dev
1272020-04-02T08:37:30 *** emilengler has joined #bitcoin-core-dev
1282020-04-02T08:45:44 *** ccdle12 has joined #bitcoin-core-dev
1292020-04-02T09:00:01 *** michal_kubenka has quit IRC
1302020-04-02T09:01:10 *** guest534543 has joined #bitcoin-core-dev
1312020-04-02T09:01:26 *** ogu has joined #bitcoin-core-dev
1322020-04-02T09:03:52 *** Kiminuo has quit IRC
1332020-04-02T09:04:21 *** oguzkoroglu has quit IRC
1342020-04-02T09:06:20 *** mol has joined #bitcoin-core-dev
1352020-04-02T09:12:53 *** afk11 has quit IRC
1362020-04-02T09:13:26 *** afk11 has joined #bitcoin-core-dev
1372020-04-02T09:21:03 *** captjakk has joined #bitcoin-core-dev
1382020-04-02T09:22:20 *** MononcQc1 has joined #bitcoin-core-dev
1392020-04-02T09:24:37 *** captjakk has quit IRC
1402020-04-02T09:25:18 *** captjakk has joined #bitcoin-core-dev
1412020-04-02T09:29:47 *** captjakk has quit IRC
1422020-04-02T09:38:12 *** timothy has joined #bitcoin-core-dev
1432020-04-02T09:51:11 *** michaelfolkson has joined #bitcoin-core-dev
1442020-04-02T09:53:41 *** promag has joined #bitcoin-core-dev
1452020-04-02T09:53:45 *** promag_ has joined #bitcoin-core-dev
1462020-04-02T09:53:48 *** michaelfolkson has quit IRC
1472020-04-02T09:54:31 *** michaelfolkson has joined #bitcoin-core-dev
1482020-04-02T09:55:17 *** ccdle12 has quit IRC
1492020-04-02T09:56:55 *** captjakk has joined #bitcoin-core-dev
1502020-04-02T09:57:55 *** ccdle12 has joined #bitcoin-core-dev
1512020-04-02T09:58:45 *** promag_ has quit IRC
1522020-04-02T09:58:58 *** tryphe_ has joined #bitcoin-core-dev
1532020-04-02T09:59:25 *** promag_ has joined #bitcoin-core-dev
1542020-04-02T10:01:23 *** captjakk has quit IRC
1552020-04-02T10:01:52 *** tryphe has quit IRC
1562020-04-02T10:04:04 *** Gianni41Nicolas has joined #bitcoin-core-dev
1572020-04-02T10:05:49 *** promag_ has quit IRC
1582020-04-02T10:06:05 *** promag_ has joined #bitcoin-core-dev
1592020-04-02T10:13:42 *** Gianni41Nicolas has quit IRC
1602020-04-02T10:17:19 *** michaelfolkson has quit IRC
1612020-04-02T10:21:22 *** cdecker_ has quit IRC
1622020-04-02T10:21:33 *** cdecker has joined #bitcoin-core-dev
1632020-04-02T10:24:19 *** michaelfolkson has joined #bitcoin-core-dev
1642020-04-02T10:24:29 *** michaelfolkson has quit IRC
1652020-04-02T10:26:50 *** ghost43_ has joined #bitcoin-core-dev
1662020-04-02T10:27:23 *** ghost43 has quit IRC
1672020-04-02T10:44:39 <promag> wumpus: in #18482 kryvel verified that #18487 fixes the deadlock
1682020-04-02T10:44:40 <gribble> https://github.com/bitcoin/bitcoin/issues/18482 | RPC stuck on walletpassphrase call · Issue #18482 · bitcoin/bitcoin · GitHub
1692020-04-02T10:44:41 <gribble> https://github.com/bitcoin/bitcoin/issues/18487 | rpc: Fix rpcRunLater race in walletpassphrase by promag · Pull Request #18487 · bitcoin/bitcoin · GitHub
1702020-04-02T10:48:36 *** bitcoin-git has joined #bitcoin-core-dev
1712020-04-02T10:48:37 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/41fa2926d86a...5c1ba3a10a18
1722020-04-02T10:48:37 <bitcoin-git> bitcoin/master a46484c Ben Woosley: build: Detect gmtime_* definitions via configure
1732020-04-02T10:48:38 <bitcoin-git> bitcoin/master 5c1ba3a Wladimir J. van der Laan: Merge #18358: util: fix compilation with mingw-w64 7.0.0
1742020-04-02T10:48:40 *** bitcoin-git has left #bitcoin-core-dev
1752020-04-02T10:48:55 *** bitcoin-git has joined #bitcoin-core-dev
1762020-04-02T10:48:55 <bitcoin-git> [bitcoin] laanwj merged pull request #18358: util: fix compilation with mingw-w64 7.0.0 (master...mingw_w64_gmtime_s) https://github.com/bitcoin/bitcoin/pull/18358
1772020-04-02T10:48:57 *** bitcoin-git has left #bitcoin-core-dev
1782020-04-02T10:50:20 <promag> still thing #16923 is good for 0.20, hebasto and jonatack__ did a good review/test there
1792020-04-02T10:50:22 <gribble> https://github.com/bitcoin/bitcoin/issues/16923 | wallet: Handle duplicate fileid exception by promag · Pull Request #16923 · bitcoin/bitcoin · GitHub
1802020-04-02T11:09:00 *** ccdle12 has quit IRC
1812020-04-02T11:11:30 *** ccdle12 has joined #bitcoin-core-dev
1822020-04-02T11:15:09 *** SiAnDoG_ has joined #bitcoin-core-dev
1832020-04-02T11:16:03 *** SiAnDoG has quit IRC
1842020-04-02T11:17:41 <hebasto> wumpus: fanquake: it seems we need cd1e7bb064315ce909dfa1a0a14a5660d985f266 from 0.19 in the master before branching off to fix #17010, no?
1852020-04-02T11:17:42 <gribble> https://github.com/bitcoin/bitcoin/issues/17010 | Missing Boost::System on ARM Ubuntu 18.04 · Issue #17010 · bitcoin/bitcoin · GitHub
1862020-04-02T11:21:13 *** Highway61 has joined #bitcoin-core-dev
1872020-04-02T11:21:27 *** theStack has joined #bitcoin-core-dev
1882020-04-02T11:22:19 *** ghost43_ has quit IRC
1892020-04-02T11:22:37 *** ghost43 has joined #bitcoin-core-dev
1902020-04-02T11:23:12 <hebasto> https://github.com/bitcoin/bitcoin/commit/cd1e7bb064315ce909dfa1a0a14a5660d985f266
1912020-04-02T11:34:30 *** ghost43 has quit IRC
1922020-04-02T11:35:16 *** ghost43 has joined #bitcoin-core-dev
1932020-04-02T11:37:11 *** Highway62 has joined #bitcoin-core-dev
1942020-04-02T11:38:14 *** Highway61 has quit IRC
1952020-04-02T11:38:14 *** Highway62 is now known as Highway61
1962020-04-02T11:47:52 *** Highway61 has quit IRC
1972020-04-02T11:48:02 *** bitcoin-git has joined #bitcoin-core-dev
1982020-04-02T11:48:03 <bitcoin-git> [bitcoin] hebasto opened pull request #18501: build: Fix boost detection on Ubuntu ARM 18.04 (master...20200402-boost-arm) https://github.com/bitcoin/bitcoin/pull/18501
1992020-04-02T11:48:03 *** bitcoin-git has left #bitcoin-core-dev
2002020-04-02T11:48:16 *** Highway61 has joined #bitcoin-core-dev
2012020-04-02T11:54:59 *** nullptr| has quit IRC
2022020-04-02T11:55:41 *** nullptr| has joined #bitcoin-core-dev
2032020-04-02T11:55:56 *** oguz has joined #bitcoin-core-dev
2042020-04-02T11:57:37 *** captjakk has joined #bitcoin-core-dev
2052020-04-02T11:58:31 *** ogu has quit IRC
2062020-04-02T11:59:47 *** oguz has quit IRC
2072020-04-02T12:00:02 *** MononcQc1 has quit IRC
2082020-04-02T12:00:02 *** promag_ has quit IRC
2092020-04-02T12:00:34 *** promag_ has joined #bitcoin-core-dev
2102020-04-02T12:01:54 *** captjakk has quit IRC
2112020-04-02T12:04:50 *** kabaum has joined #bitcoin-core-dev
2122020-04-02T12:10:19 *** bitcoin-git has joined #bitcoin-core-dev
2132020-04-02T12:10:19 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #18500: chainparams: Bump assumed valid hash (master...2004-chainparamsBump) https://github.com/bitcoin/bitcoin/pull/18500
2142020-04-02T12:10:20 *** bitcoin-git has left #bitcoin-core-dev
2152020-04-02T12:10:39 *** bitcoin-git has joined #bitcoin-core-dev
2162020-04-02T12:10:39 <bitcoin-git> [bitcoin] MarcoFalke reopened pull request #18500: chainparams: Bump assumed valid hash (master...2004-chainparamsBump) https://github.com/bitcoin/bitcoin/pull/18500
2172020-04-02T12:10:40 *** bitcoin-git has left #bitcoin-core-dev
2182020-04-02T12:16:59 *** bitcoin-git has joined #bitcoin-core-dev
2192020-04-02T12:16:59 <bitcoin-git> [bitcoin] uzyn opened pull request #18502: doc: Update docs for getbalance (default minconf should be 0) (master...doc-getbalance) https://github.com/bitcoin/bitcoin/pull/18502
2202020-04-02T12:17:00 *** bitcoin-git has left #bitcoin-core-dev
2212020-04-02T12:17:39 *** bitcoin-git has joined #bitcoin-core-dev
2222020-04-02T12:17:39 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18503: init: Replace URL_WEBSITE with PACKAGE_URL (master...2004-initRebrand) https://github.com/bitcoin/bitcoin/pull/18503
2232020-04-02T12:17:40 *** bitcoin-git has left #bitcoin-core-dev
2242020-04-02T12:19:14 *** Highway61 has quit IRC
2252020-04-02T12:20:40 *** Highway61 has joined #bitcoin-core-dev
2262020-04-02T12:21:48 *** Fare has joined #bitcoin-core-dev
2272020-04-02T12:22:11 *** Fare is now known as Guest54802
2282020-04-02T12:35:48 *** kristapsk has joined #bitcoin-core-dev
2292020-04-02T12:38:10 <luke-jr> maybe we should just remove getbalance if it isn't going to get fixed :x
2302020-04-02T12:57:58 *** promag_ has quit IRC
2312020-04-02T12:58:13 *** promag_ has joined #bitcoin-core-dev
2322020-04-02T13:03:51 <instagibbs> I thought getbalances was going to replace it anyways
2332020-04-02T13:03:52 <wumpus> hebasto: if we don't want that in master, then we need to cherry-pick it *after* the branch off right?
2342020-04-02T13:03:52 <instagibbs> i guess i don't see any deprecation on that tho
2352020-04-02T13:04:01 *** Dean_Guss has joined #bitcoin-core-dev
2362020-04-02T13:04:26 *** emilengler has quit IRC
2372020-04-02T13:04:41 *** emilengler has joined #bitcoin-core-dev
2382020-04-02T13:06:03 *** DeanGuss has quit IRC
2392020-04-02T13:06:44 <luke-jr> instagibbs: yeah, that was my understanding as well
2402020-04-02T13:08:00 *** ghost43 has quit IRC
2412020-04-02T13:09:09 <wumpus> I don't think we should be deprecating wallet RPCs left and right tbh
2422020-04-02T13:09:23 *** afk11 has quit IRC
2432020-04-02T13:09:56 <wumpus> every change requires changes to all software using bitcoin core, sure, sometimes it's really unavoidable (APIs that don't make sense anymore given our implementation, or are a lot of bother to maintain), but I don't think `getbalance` is that
2442020-04-02T13:10:09 <hebasto> wumpus: https://github.com/autoconf-archive/autoconf-archive/pull/198 seems stalled. What plan do you suggest for master?
2452020-04-02T13:10:13 <luke-jr> wumpus: it's been broken for several releases now tho
2462020-04-02T13:12:52 <wumpus> if we can't find a way to handle this that is acceptable to autoconf upstream, we should probably drop it completely
2472020-04-02T13:13:23 <hebasto> ok
2482020-04-02T13:14:45 <luke-jr> eh, but the current upstream is broken?
2492020-04-02T13:15:09 <jonatack__> luke-jr: before removing getbalance, i began with removing getunconfirmedbalance with #18451
2502020-04-02T13:15:10 <gribble> https://github.com/bitcoin/bitcoin/issues/18451 | rpc: remove deprecated getunconfirmedbalance by jonatack · Pull Request #18451 · bitcoin/bitcoin · GitHub
2512020-04-02T13:15:33 <luke-jr> there's already autoconf stuff to handle this afaik
2522020-04-02T13:15:38 <jonatack__> but no hurry and they need to go through a deprecation process
2532020-04-02T13:16:33 *** jonatack__ has quit IRC
2542020-04-02T13:17:03 *** jonatack has joined #bitcoin-core-dev
2552020-04-02T13:19:49 *** ghost43 has joined #bitcoin-core-dev
2562020-04-02T13:21:20 <wumpus> well on the plus side, at some point we might not need boost anymore and can close the issue :')
2572020-04-02T13:24:04 <wumpus> in any case I don't have a strong opinion about it, if the build system ppl thing it's ok to merge our own version into master now and risk overwriting it later that's fine with me too
2582020-04-02T13:25:09 <aj> wumpus: (we need boost for multi_index_container in txmempool; seems hard to do away with)
2592020-04-02T13:25:23 *** mdunnio has joined #bitcoin-core-dev
2602020-04-02T13:25:44 *** kabaum has quit IRC
2612020-04-02T13:25:45 <luke-jr> is there a reason we need the boost lib path at all?
2622020-04-02T13:25:50 <luke-jr> why can't it just use -lboost_*
2632020-04-02T13:25:52 <luke-jr> ?
2642020-04-02T13:26:01 <wumpus> aj: sure but I mean if that's the only thing left, we can probably find a replacment
2652020-04-02T13:26:19 <wumpus> luke-jr: because -lboost_ doesn't work if the right -L is not specified
2662020-04-02T13:26:21 *** kabaum has joined #bitcoin-core-dev
2672020-04-02T13:26:34 <wumpus> boost libraries are not in the linker default library path
2682020-04-02T13:26:41 <luke-jr> wumpus: unlikely, we're probably going to add boost::process soon?
2692020-04-02T13:26:43 *** molly has joined #bitcoin-core-dev
2702020-04-02T13:26:49 <luke-jr> wumpus: yes they are?
2712020-04-02T13:27:01 <wumpus> in modern libraries this is solved by pkg-config and similar mechanisms but ofc boost needs to be special
2722020-04-02T13:27:23 <luke-jr> and this m4 stuff only checks the default library paths anyway
2732020-04-02T13:27:24 <aj> wumpus: sure, as far as i can tell, boost's is actually pretty good though
2742020-04-02T13:27:48 <wumpus> aj: okay it's fine if people want to stick with boost forever now that's ok with me too
2752020-04-02T13:27:58 <wumpus> this changes every few months
2762020-04-02T13:28:26 <aj> wumpus: boost forever would be a great pr idea in about 364 days i guess
2772020-04-02T13:28:26 *** emilengler has quit IRC
2782020-04-02T13:28:41 *** emilengler has joined #bitcoin-core-dev
2792020-04-02T13:29:02 <luke-jr> probably will be some time before all of our boost needs are in C++ std
2802020-04-02T13:29:11 *** afk11` has joined #bitcoin-core-dev
2812020-04-02T13:29:14 <wumpus> aj: I"m just tired of the back and forth, one day there's a flurry of 'move away form boost' PRs the next everyone is defending boost
2822020-04-02T13:30:09 <aj> wumpus: ah, sorry then. didn't mean to end up on the defending boost side
2832020-04-02T13:30:13 *** mol has quit IRC
2842020-04-02T13:31:11 <luke-jr> wumpus: it makes sense to migrate stuff from boost to C++ std, but C++ std doesn't do everything yet
2852020-04-02T13:31:19 <wumpus> aj: no problem, sorry, not feeling well at the moment shoudln't take it out on you
2862020-04-02T13:31:31 <aj> wumpus: i am feeling well, so it's fine :)
2872020-04-02T13:41:29 *** sdaftuar_ has quit IRC
2882020-04-02T13:41:43 *** vasild has quit IRC
2892020-04-02T13:41:55 *** sdaftuar_ has joined #bitcoin-core-dev
2902020-04-02T13:44:13 *** bitcoin-git has joined #bitcoin-core-dev
2912020-04-02T13:44:13 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6bdd515ccf1b...b83565625e32
2922020-04-02T13:44:14 <bitcoin-git> bitcoin/master 222253e MarcoFalke: chainparams: Bump assumed valid hash
2932020-04-02T13:44:14 <bitcoin-git> bitcoin/master b835656 Wladimir J. van der Laan: Merge #18500: chainparams: Bump assumed valid hash
2942020-04-02T13:44:16 *** bitcoin-git has left #bitcoin-core-dev
2952020-04-02T13:44:33 *** bitcoin-git has joined #bitcoin-core-dev
2962020-04-02T13:44:33 <bitcoin-git> [bitcoin] laanwj merged pull request #18500: chainparams: Bump assumed valid hash (master...2004-chainparamsBump) https://github.com/bitcoin/bitcoin/pull/18500
2972020-04-02T13:44:35 *** bitcoin-git has left #bitcoin-core-dev
2982020-04-02T14:02:50 *** ghost43 has quit IRC
2992020-04-02T14:04:05 *** ghost43 has joined #bitcoin-core-dev
3002020-04-02T14:17:17 *** vasild has joined #bitcoin-core-dev
3012020-04-02T14:26:42 *** bitcoin-git has joined #bitcoin-core-dev
3022020-04-02T14:26:42 <bitcoin-git> [bitcoin] laanwj opened pull request #18506: net: Hardcoded seeds update for 0.20 (master...2020_04_hardcoded_seeds) https://github.com/bitcoin/bitcoin/pull/18506
3032020-04-02T14:26:44 *** bitcoin-git has left #bitcoin-core-dev
3042020-04-02T14:52:34 *** guest534543 has quit IRC
3052020-04-02T14:53:54 *** captjakk has joined #bitcoin-core-dev
3062020-04-02T14:57:12 *** cryptapus has quit IRC
3072020-04-02T15:00:01 *** Guest54802 has quit IRC
3082020-04-02T15:13:49 *** cryptapus has joined #bitcoin-core-dev
3092020-04-02T15:13:49 *** cryptapus has quit IRC
3102020-04-02T15:13:49 *** cryptapus has joined #bitcoin-core-dev
3112020-04-02T15:17:06 *** bitcoin-git has joined #bitcoin-core-dev
3122020-04-02T15:17:07 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18507: test: Check that calling walletpasshprase does not freeze the node (master...2004-qaWalletFreeze) https://github.com/bitcoin/bitcoin/pull/18507
3132020-04-02T15:17:07 *** bitcoin-git has left #bitcoin-core-dev
3142020-04-02T15:21:03 <luke-jr> bleh, my comma removal screwed up other formatting
3152020-04-02T15:21:11 *** skorgon has joined #bitcoin-core-dev
3162020-04-02T15:23:40 *** molz_ has joined #bitcoin-core-dev
3172020-04-02T15:26:17 *** molly has quit IRC
3182020-04-02T15:30:22 <promag> MarcoFalke: I can pick your commit if you want
3192020-04-02T15:30:48 <promag> btw, comment added
3202020-04-02T15:31:16 *** bitcoin-git has joined #bitcoin-core-dev
3212020-04-02T15:31:16 <bitcoin-git> [bitcoin] luke-jr opened pull request #18508: RPC: Fix more formatting nits (master...rpcdoc_format_20200402) https://github.com/bitcoin/bitcoin/pull/18508
3222020-04-02T15:31:19 *** bitcoin-git has left #bitcoin-core-dev
3232020-04-02T15:42:45 *** captjakk has quit IRC
3242020-04-02T15:44:18 *** captjakk has joined #bitcoin-core-dev
3252020-04-02T16:09:36 *** stackingcore21 has quit IRC
3262020-04-02T16:13:24 *** kristapsk has quit IRC
3272020-04-02T16:13:36 *** kristapsk has joined #bitcoin-core-dev
3282020-04-02T16:23:25 *** tryphe_ is now known as tryphe
3292020-04-02T16:28:42 *** jarthur has joined #bitcoin-core-dev
3302020-04-02T16:29:42 *** jarthur has joined #bitcoin-core-dev
3312020-04-02T16:32:45 *** Kiminuo has joined #bitcoin-core-dev
3322020-04-02T16:41:05 *** justanotheruser has quit IRC
3332020-04-02T16:41:48 *** tryphe has quit IRC
3342020-04-02T16:42:13 *** tryphe has joined #bitcoin-core-dev
3352020-04-02T16:46:47 *** stackingcore21 has joined #bitcoin-core-dev
3362020-04-02T16:52:31 <MarcoFalke> Looks like #18487 , #18487 and #18487 are the last three things to get in before branch-off?
3372020-04-02T16:52:33 <gribble> https://github.com/bitcoin/bitcoin/issues/18487 | rpc: Fix rpcRunLater race in walletpassphrase by promag · Pull Request #18487 · bitcoin/bitcoin · GitHub
3382020-04-02T16:52:34 <gribble> https://github.com/bitcoin/bitcoin/issues/18487 | rpc: Fix rpcRunLater race in walletpassphrase by promag · Pull Request #18487 · bitcoin/bitcoin · GitHub
3392020-04-02T16:52:35 <gribble> https://github.com/bitcoin/bitcoin/issues/18487 | rpc: Fix rpcRunLater race in walletpassphrase by promag · Pull Request #18487 · bitcoin/bitcoin · GitHub
3402020-04-02T16:53:06 <MarcoFalke> * #18458 #18506
3412020-04-02T16:53:07 <gribble> https://github.com/bitcoin/bitcoin/issues/18458 | net: Add missing cs_vNodes lock by MarcoFalke · Pull Request #18458 · bitcoin/bitcoin · GitHub
3422020-04-02T16:53:08 <gribble> https://github.com/bitcoin/bitcoin/issues/18506 | net: Hardcoded seeds update for 0.20 by laanwj · Pull Request #18506 · bitcoin/bitcoin · GitHub
3432020-04-02T16:54:16 <MarcoFalke> Even if they miss, they can be backported. I think we should open the master branch again for merges for 0.21
3442020-04-02T16:57:31 <luke-jr> #18192 and #18465 should be fixed before rc1 IMO
3452020-04-02T16:57:33 <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
3462020-04-02T16:57:35 <gribble> https://github.com/bitcoin/bitcoin/issues/18465 | bitcoin-tx (and probably others) fails to build without libevent · Issue #18465 · bitcoin/bitcoin · GitHub
3472020-04-02T16:57:37 <promag> well no need to hold them, you can backport a revert \m/
3482020-04-02T16:59:08 *** justanotheruser has joined #bitcoin-core-dev
3492020-04-02T17:07:23 *** vasild has quit IRC
3502020-04-02T17:10:50 *** justanotheruser has quit IRC
3512020-04-02T17:19:01 *** justanotheruser has joined #bitcoin-core-dev
3522020-04-02T17:19:05 *** filchef has joined #bitcoin-core-dev
3532020-04-02T17:21:10 <MarcoFalke> There will always be bugs and bugfixes, which can be backported after sufficient review. But at some point we need to open master again.
3542020-04-02T17:21:54 *** promag has quit IRC
3552020-04-02T17:23:00 <achow101> instagibbs: sipa: it turns out that signing with all spkmans still doesn't work for traditional signrawtransaction* workflows. It should work with PSBTs though. Could we just tell everyone who wants to use descriptor wallets to use PSBT and just disable *rawtransaction RPCs for it as well?
3562020-04-02T17:25:06 *** jonatack_ has joined #bitcoin-core-dev
3572020-04-02T17:26:43 *** mdunnio has quit IRC
3582020-04-02T17:28:12 *** vasild has joined #bitcoin-core-dev
3592020-04-02T17:28:28 *** jonatack has quit IRC
3602020-04-02T17:29:25 *** promag has joined #bitcoin-core-dev
3612020-04-02T17:31:31 *** stackingcore21 has joined #bitcoin-core-dev
3622020-04-02T17:33:10 *** justanotheruser has quit IRC
3632020-04-02T17:34:18 <sipa> achow101: hmm, why not?
3642020-04-02T17:34:32 <sipa> (i don't actually understand the issue)
3652020-04-02T17:37:29 *** filchef|2 has joined #bitcoin-core-dev
3662020-04-02T17:38:37 *** filchef|2 has quit IRC
3672020-04-02T17:40:58 <achow101> We need to know the reddenScript but that would worker not be in the wallet, or be in a different spkman
3682020-04-02T17:41:19 <achow101> So the spkman currently attending to sign doesn't know the redeemScript
3692020-04-02T17:41:30 <achow101> *attempting
3702020-04-02T17:43:43 <sipa> can't you import it?
3712020-04-02T17:45:13 <sipa> oh, i see
3722020-04-02T17:45:27 <sipa> because the private key will be in a different spkman than the one that knows the redeemscript?
3732020-04-02T17:45:41 <achow101> Yes
3742020-04-02T17:46:43 <achow101> i suppose one method could be to convert everything into PSBTs internally and just pass around PSBTs between the spkmans
3752020-04-02T17:47:28 <sipa> or make private keys global for the entire wallet
3762020-04-02T17:48:45 <sipa> but converting everything to PSBTs internally seems like a good idea in any case
3772020-04-02T17:49:18 *** justanotheruser has joined #bitcoin-core-dev
3782020-04-02T17:50:04 <achow101> since descriptor wallets is currently an optional feature, I would be fine with requiring PSBTs for now
3792020-04-02T17:50:31 <achow101> then change the wallet to use PSBTs internally everywhere to solve this particular issue
3802020-04-02T17:50:53 <achow101> I do have a long term goal of making the wallet use PSBTs everywhere anyways
3812020-04-02T17:53:24 <sipa> agreed
3822020-04-02T17:55:03 *** mdunnio has joined #bitcoin-core-dev
3832020-04-02T17:57:25 *** dviola has joined #bitcoin-core-dev
3842020-04-02T18:00:02 *** skorgon has quit IRC
3852020-04-02T18:04:30 *** Dean_Guss has quit IRC
3862020-04-02T18:04:36 <promag> hi
3872020-04-02T18:04:55 *** Dean_Guss has joined #bitcoin-core-dev
3882020-04-02T18:05:35 <fjahr> I think meeting starts in one hour
3892020-04-02T18:05:41 *** mol has joined #bitcoin-core-dev
3902020-04-02T18:05:57 <promag> fjahr: right, summer time
3912020-04-02T18:06:02 *** filchef has quit IRC
3922020-04-02T18:06:07 <promag> thanks
3932020-04-02T18:06:19 *** filchef has joined #bitcoin-core-dev
3942020-04-02T18:09:04 *** molz_ has quit IRC
3952020-04-02T18:13:50 *** bitcoin-git has joined #bitcoin-core-dev
3962020-04-02T18:13:50 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b83565625e32...ff53433fe4ed
3972020-04-02T18:13:50 <bitcoin-git> bitcoin/master 6112a20 Jon Atack: test: replace (send_message + sync_with_ping) with send_and_ping
3982020-04-02T18:13:51 <bitcoin-git> bitcoin/master ff53433 MarcoFalke: Merge #18494: test: replace (send_message + sync_with_ping) with send_and_...
3992020-04-02T18:13:52 *** bitcoin-git has left #bitcoin-core-dev
4002020-04-02T18:14:10 *** bitcoin-git has joined #bitcoin-core-dev
4012020-04-02T18:14:10 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18494: test: replace (send_message + sync_with_ping) with send_and_ping (master...send_and_ping) https://github.com/bitcoin/bitcoin/pull/18494
4022020-04-02T18:14:12 *** bitcoin-git has left #bitcoin-core-dev
4032020-04-02T18:20:42 *** subdriven1 has joined #bitcoin-core-dev
4042020-04-02T18:25:17 <wumpus> emzy: your list contains no 0.19.x nodes at all, that's weird!
4052020-04-02T18:26:14 <emzy> strange. But I think I'm on master
4062020-04-02T18:27:42 <wumpus> but e.g. cat seeds_sipa.txt |grep "Satoshi:0\\.19"|wc gives 4026 matches, doing the same for your list gives none :/
4072020-04-02T18:28:16 <wumpus> I'm going to merge alle the lists and deduplicate so for me it's not a big deal, but it might indicate a problem with your crawler
4082020-04-02T18:28:22 <emzy> I will invastigate later.
4092020-04-02T18:31:14 <emzy> after update to master I have 0.19 clients
4102020-04-02T18:31:58 <emzy> so sorry wrong grep. there are still none.
4112020-04-02T18:34:58 <sipa> i wonder if i turned off tor after realizing it made crawling super slow
4122020-04-02T18:35:14 <sipa> my % of outgoing connections of my crawler is going up
4132020-04-02T18:40:00 <emzy> do I have to generate the seeds.txt.gz file?
4142020-04-02T18:41:47 <emzy> Ok seems to be this: dnsseed.dump S
4152020-04-02T18:42:03 <emzy> So it was my fault. I had a old seeds.txt.gz file.
4162020-04-02T18:42:14 <sipa> yeah, it's a gzip of the dnsseed.dump file
4172020-04-02T18:47:33 <emzy> like: gzip --best <dnsseed.dump >seeds.txt.gz
4182020-04-02T18:47:48 <emzy> I put a old file up. :(
4192020-04-02T18:49:45 <wumpus> emzy: no problem, can you post a new one please?
4202020-04-02T18:50:49 *** ahmed_ has joined #bitcoin-core-dev
4212020-04-02T18:51:27 <emzy> I also deleted my dnsseed.dump and all other files. So I will have to wait until it is full again. I only have 902 lines in the file.
4222020-04-02T18:53:05 <sipa> ah, that's unfortunate
4232020-04-02T18:54:03 <emzy> And no backup for that server :(
4242020-04-02T18:57:13 *** promag has quit IRC
4252020-04-02T18:57:26 *** emilengler has quit IRC
4262020-04-02T18:57:41 *** emilengler has joined #bitcoin-core-dev
4272020-04-02T19:00:00 <wumpus> hopefully someone has a list with recent onions in them
4282020-04-02T19:00:51 <emzy> no onions in my file now :(
4292020-04-02T19:01:12 <wumpus> #startmeeting
4302020-04-02T19:01:12 <lightningbot> Meeting started Thu Apr 2 19:01:12 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4312020-04-02T19:01:12 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4322020-04-02T19:01:16 <jonasschnelli> hi
4332020-04-02T19:01:21 <sipsorcery> hi
4342020-04-02T19:01:27 <hebasto> hi
4352020-04-02T19:01:28 <fjahr> hi
4362020-04-02T19:01:28 <cfields> hi
4372020-04-02T19:01:34 <sipa> hi
4382020-04-02T19:01:44 <amiti> hi
4392020-04-02T19:01:44 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
4402020-04-02T19:01:46 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
4412020-04-02T19:01:57 <jkczyz> hi
4422020-04-02T19:01:59 <jb55> hi
4432020-04-02T19:02:07 <achow101> hi
4442020-04-02T19:02:12 <jonatack_> hi
4452020-04-02T19:02:24 <nehan_> hi
4462020-04-02T19:02:43 <wumpus> no proposed topics for this week, it appears
4472020-04-02T19:02:46 <elichai2> Hi
4482020-04-02T19:02:48 <wumpus> any last minute ones?
4492020-04-02T19:03:07 <jeremyrubin> hi
4502020-04-02T19:03:14 <luke-jr> wumpus: I saw one earlier.. :p
4512020-04-02T19:03:17 <jeremyrubin> Hope everyone is safe & healthy :)
4522020-04-02T19:03:19 <luke-jr> 0.20 bugfixes
4532020-04-02T19:03:22 <luke-jr> or smth like that
4542020-04-02T19:03:33 <wumpus> FWIW it's time to do the branch-off for 0.20
4552020-04-02T19:03:38 <wumpus> and release rc1
4562020-04-02T19:03:59 <wumpus> luke-jr: don't see it in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt, but that makes sense
4572020-04-02T19:04:03 <luke-jr> IMO #18192 and #18465 should be fixed before rc1
4582020-04-02T19:04:05 <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
4592020-04-02T19:04:06 <gribble> https://github.com/bitcoin/bitcoin/issues/18465 | bitcoin-tx (and probably others) fails to build without libevent · Issue #18465 · bitcoin/bitcoin · GitHub
4602020-04-02T19:04:22 <luke-jr> could perhaps still branch off anyway, as they're not really ready :/
4612020-04-02T19:05:06 <luke-jr> 18192 only affects avoid-reuse wallets, but the harm is irrepairable once affected
4622020-04-02T19:05:13 <wumpus> those are not even tagged for 0.20
4632020-04-02T19:05:18 *** promag has joined #bitcoin-core-dev
4642020-04-02T19:05:30 <promag> hi
4652020-04-02T19:06:05 <wumpus> unless they're realy urgent might include them in a later rc or 0.20.1
4662020-04-02T19:06:19 <sipa> are they 0.20 regressions?
4672020-04-02T19:06:51 <dongcarl> hi
4682020-04-02T19:06:52 <luke-jr> not regressions, no
4692020-04-02T19:07:22 <luke-jr> I suppose 18465 has an easy workaround
4702020-04-02T19:07:39 <sipa> when was 18192 introduced?
4712020-04-02T19:07:49 <sipa> or when was the problem it solves introduced?
4722020-04-02T19:07:52 <luke-jr> when avoid-reuse wallets were introduced, 0.19.0 IIRC
4732020-04-02T19:08:44 <sipa> this sounds moderately serious... i suspect we just haven't heard about it much because few people enable that setting, i expect?
4742020-04-02T19:08:53 <luke-jr> maybe; I don't know how popular it is
4752020-04-02T19:09:19 <luke-jr> IMO if we don't fix it, we should at least put it in rel notes as a known issue
4762020-04-02T19:09:21 *** tryphe_ has joined #bitcoin-core-dev
4772020-04-02T19:09:27 <achow101> i doubt people really use multiwallet or create non-default wallets
4782020-04-02T19:09:41 <luke-jr> achow101: it's not multiwallet-related
4792020-04-02T19:09:54 <achow101> luke-jr: but you have to be using the multiwallet feature to enable it
4802020-04-02T19:10:06 <achow101> i.e. create a new wallet
4812020-04-02T19:10:10 <luke-jr> hmm
4822020-04-02T19:11:41 *** tryphe has quit IRC
4832020-04-02T19:11:51 *** filchef has quit IRC
4842020-04-02T19:12:13 <luke-jr> also from earlier [16:52:31] <MarcoFalke> Looks like #18487 , #18487 and #18487 are the last three things to get in before branch-off?
4852020-04-02T19:12:14 <achow101> oh wait, we can use the setwalletflag rpc to enable it. but that requires knowing what you're doing. it's not exposed in the gui
4862020-04-02T19:12:15 <gribble> https://github.com/bitcoin/bitcoin/issues/18487 | rpc: Fix rpcRunLater race in walletpassphrase by promag · Pull Request #18487 · bitcoin/bitcoin · GitHub
4872020-04-02T19:12:15 <gribble> https://github.com/bitcoin/bitcoin/issues/18487 | rpc: Fix rpcRunLater race in walletpassphrase by promag · Pull Request #18487 · bitcoin/bitcoin · GitHub
4882020-04-02T19:12:16 <gribble> https://github.com/bitcoin/bitcoin/issues/18487 | rpc: Fix rpcRunLater race in walletpassphrase by promag · Pull Request #18487 · bitcoin/bitcoin · GitHub
4892020-04-02T19:12:31 <luke-jr> rtt
4902020-04-02T19:12:33 <luke-jr> err*
4912020-04-02T19:12:38 <luke-jr> [16:53:06] <MarcoFalke> * #18458 #18506
4922020-04-02T19:12:40 <gribble> https://github.com/bitcoin/bitcoin/issues/18458 | net: Add missing cs_vNodes lock by MarcoFalke · Pull Request #18458 · bitcoin/bitcoin · GitHub
4932020-04-02T19:12:41 <gribble> https://github.com/bitcoin/bitcoin/issues/18506 | net: Hardcoded seeds update for 0.20 by laanwj · Pull Request #18506 · bitcoin/bitcoin · GitHub
4942020-04-02T19:13:00 <promag> lol
4952020-04-02T19:13:02 *** molly has joined #bitcoin-core-dev
4962020-04-02T19:13:04 *** filchef has joined #bitcoin-core-dev
4972020-04-02T19:13:06 *** ccdle12 has quit IRC
4982020-04-02T19:14:26 <wumpus> yes those are tagged https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.20.0
4992020-04-02T19:14:54 <luke-jr> 18192 & 18465 should probably at least get tagged, even if they end up slipping the release
5002020-04-02T19:15:43 <wumpus> ok
5012020-04-02T19:15:54 *** mol has quit IRC
5022020-04-02T19:17:02 <jonatack_> another avoid_reuse related bugfix is #17824 (2 acks)
5032020-04-02T19:17:06 <gribble> https://github.com/bitcoin/bitcoin/issues/17824 | wallet: Prefer full destination groups in coin selection by fjahr · Pull Request #17824 · bitcoin/bitcoin · GitHub
5042020-04-02T19:17:56 <wumpus> this adds way more things last-minute for 0.20 than I expected
5052020-04-02T19:18:03 <jonatack_> (not saying it's as urgent)
5062020-04-02T19:18:18 <sipa> 17824 seems like a bigger change
5072020-04-02T19:18:26 *** filchef has quit IRC
5082020-04-02T19:18:26 <wumpus> we could also add a note to the release notes that avoid-reuse is buggy
5092020-04-02T19:18:46 <wumpus> or disable it
5102020-04-02T19:18:56 *** filchef has joined #bitcoin-core-dev
5112020-04-02T19:19:07 <wumpus> oh wait it was introduced in 0.19 not 0.20
5122020-04-02T19:19:12 <wumpus> so not that
5132020-04-02T19:22:01 <sipa> maybe let's prioritize review on #18192, and see how far we get?
5142020-04-02T19:22:03 <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
5152020-04-02T19:22:10 <sipa> if not, a release note can always be added
5162020-04-02T19:23:12 <wumpus> let's set a new deadline for the branch-off then?
5172020-04-02T19:23:40 <wumpus> we missed yesterday at least :)
5182020-04-02T19:23:50 <luke-jr> why not just branch off now?
5192020-04-02T19:24:06 <promag> +1
5202020-04-02T19:24:13 <wumpus> I want to do rc1 release at the same time
5212020-04-02T19:24:18 <promag> oh kk
5222020-04-02T19:24:56 <sipa> seems reasonable to aim to do them simultaneously
5232020-04-02T19:24:58 <jeremyrubin> #proposedmeetingtopic limited use of boost in consensus for backports
5242020-04-02T19:25:02 * luke-jr shrugs
5252020-04-02T19:25:38 <wumpus> I don't see a reason to do a branch-off without immediately doing rc1, that would just result in more backporting work
5262020-04-02T19:26:03 <wumpus> oh no, no boost topic please
5272020-04-02T19:26:13 <jeremyrubin> lol :|
5282020-04-02T19:26:14 <sipa> at least not when we have known issues to solve still
5292020-04-02T19:26:38 <luke-jr> jeremyrubin: we'd need to adapt the build system.. isn't it avoidable?
5302020-04-02T19:26:46 <jeremyrubin> luke-jr: no it isn't
5312020-04-02T19:27:09 <wumpus> sipa: right
5322020-04-02T19:27:21 <luke-jr> what kind of bugfix requires boost? :/
5332020-04-02T19:27:33 <jeremyrubin> anyways we can discuss after the meeting if needed or when it's the topics turn
5342020-04-02T19:27:44 <jeremyrubin> but I don't think anyone wants to discuss it now
5352020-04-02T19:27:52 <jeremyrubin> Except maybe you and I
5362020-04-02T19:28:30 <wumpus> well it's not like we have other topics
5372020-04-02T19:28:42 <luke-jr> ^
5382020-04-02T19:28:45 <jeremyrubin> Ah I took your request literally
5392020-04-02T19:28:46 <wumpus> #topic limited use of boost in consensus for backports
5402020-04-02T19:29:16 <jeremyrubin> Well; I think on the 0.21 horizon is upgrading to c++17, one feature of which means things like std::option being available
5412020-04-02T19:29:34 <jeremyrubin> We're currently reviewing code for things like #18401
5422020-04-02T19:29:37 <gribble> https://github.com/bitcoin/bitcoin/issues/18401 | Refactor: Initialize PrecomputedTransactionData in CheckInputScripts by jnewbery · Pull Request #18401 · bitcoin/bitcoin · GitHub
5432020-04-02T19:29:56 <jeremyrubin> Which IMO should be properly written/refactored using option types
5442020-04-02T19:30:05 <jeremyrubin> See https://github.com/bitcoin/bitcoin/pull/17977#discussion_r370948973
5452020-04-02T19:30:09 <sipa> if it came at no cost, sure
5462020-04-02T19:30:36 <sipa> but the level of review necessary for those things already far outweighs the (imho) minimal complication of just splitting variables up into a bool + other var
5472020-04-02T19:30:48 <jeremyrubin> issue exists outside of taproot
5482020-04-02T19:31:05 <sipa> sure
5492020-04-02T19:31:16 <sipa> i wasn't speaking about that specifically
5502020-04-02T19:31:16 <jeremyrubin> at large, not just in this context -- if we need to gate development of features which touch consensus to not use c++17 features in consensus
5512020-04-02T19:31:27 <jeremyrubin> because it will interfere with backports
5522020-04-02T19:31:28 <luke-jr> IMO we should just not allow C++17 for consensus code where it would make this problem
5532020-04-02T19:32:03 *** mdunnio has quit IRC
5542020-04-02T19:32:05 <jeremyrubin> So there's three "solutions"
5552020-04-02T19:32:08 <sipa> right, until those are outside of backport window
5562020-04-02T19:32:15 <jeremyrubin> 1) No c++17 stuff for a while because of backports
5572020-04-02T19:32:20 *** mdunnio has joined #bitcoin-core-dev
5582020-04-02T19:32:45 <jeremyrubin> 2) Allow linking in boost c++17 API fill-ins that we already have until out of support window
5592020-04-02T19:32:55 <wumpus> I think we should either switch to C++17 for the entire codebase, or not at all
5602020-04-02T19:33:15 <luke-jr> jeremyrubin: we don't have in libconsensus
5612020-04-02T19:33:38 <sipa> i think that once master is c++17, we can switch backports to c++17 as well, actually
5622020-04-02T19:33:49 <wumpus> moderating which parts of the codebase C++17 features are allowed and where not makes things very complicated for reviewers and maintainers
5632020-04-02T19:33:51 <luke-jr> sipa: defeats one big point of backports?
5642020-04-02T19:33:55 <jeremyrubin> 3) upgrade backports to c++17 :)
5652020-04-02T19:34:00 <wumpus> so I'd prefer to not use C++17 at all then
5662020-04-02T19:34:08 <hebasto> Not switching from c++11 for the entire codebase could be a problem for Qt stuff on macOS
5672020-04-02T19:34:16 <luke-jr> IIRC backports only delays us an extra year, right?
5682020-04-02T19:34:17 <wumpus> it's not like we really need it
5692020-04-02T19:34:33 <sipa> wumpus: well that's a deadlock, because there will always be some backport to support
5702020-04-02T19:34:40 <wumpus> it'[s always 'it would be nice to use this new c++ standard'
5712020-04-02T19:34:46 <wumpus> which it would be, sure
5722020-04-02T19:34:50 *** mdunnio has quit IRC
5732020-04-02T19:34:51 <sipa> so independent of the urgency of c++17 or when it is introduced, it's a good question to address
5742020-04-02T19:35:41 <sipa> luke-jr: backports exist because introduced features introduce compatibility issues for people who want a safer upgrade path
5752020-04-02T19:35:42 <jeremyrubin> It's also the right time to start thinking about it IMO -- if 0.21 will be c++17 release
5762020-04-02T19:36:05 <jeremyrubin> Which I've seen wumpus say is feasible
5772020-04-02T19:36:09 <wumpus> yes, I just think using C++17 for only parts of the codebase is impractical
5782020-04-02T19:36:12 <luke-jr> sipa: one of those issues is C++ version compat
5792020-04-02T19:36:33 <sipa> but if there are a significant amount of people who wouldn't be able to upgrade to a new major version because of c++ language compatibility issues, we simply shouldn't update to c++17 (yet)
5802020-04-02T19:36:40 <luke-jr> how hard would it be to compile some of the codebase with C++17 enabled, and not others?
5812020-04-02T19:36:42 <sipa> wumpus: that's fair
5822020-04-02T19:36:52 <cfields> luke-jr: I really don't like that idea.
5832020-04-02T19:37:01 <wumpus> luke-jr: I'm sure it's *possible* but I fear all kinds of API conflicts
5842020-04-02T19:37:03 <jeremyrubin> luke-jr: would probably make binaries bigger
5852020-04-02T19:37:10 <luke-jr> hmm
5862020-04-02T19:37:11 <cfields> luke-jr: I think the threat of something like an uncaught exception is very real in that scenario.
5872020-04-02T19:37:13 <jeremyrubin> wumpus: yeah
5882020-04-02T19:37:19 <luke-jr> cfields: right, I see
5892020-04-02T19:37:35 <wumpus> cfields: yes, it's probably an unacceptable risk in our case
5902020-04-02T19:37:53 <jeremyrubin> How was this handled historically?
5912020-04-02T19:37:57 <wumpus> of course, if it's only for checking
5922020-04-02T19:38:04 <sipa> so maybe we can settle on: we don't update to c++17 until we're in a position where no new backport releases are expected
5932020-04-02T19:38:05 <wumpus> you could compile the consensus files with c++11 *as well*
5942020-04-02T19:38:06 <jeremyrubin> Or was the switch to 11 widely supported enough at the time
5952020-04-02T19:38:09 <wumpus> and throw away the result
5962020-04-02T19:38:41 <sipa> if then an emergency happens that causes us to revert on that - so be it
5972020-04-02T19:38:43 <jeremyrubin> Or we can turn on c++17 for 0.20, but compile both for checking as wumpus suggests
5982020-04-02T19:38:54 <jeremyrubin> That way we're "priming" our backport window
5992020-04-02T19:39:17 <wumpus> I'd still prefer not to do this (also because what is 'consensus code' is not very well isolated in our code base)
6002020-04-02T19:39:21 <jeremyrubin> I don't think c++17 has any *breaking* changes?
6012020-04-02T19:39:40 <jeremyrubin> wumpus: I'm saying the whole codebase not just consensus
6022020-04-02T19:40:10 <cfields> jeremyrubin: iirc ^^ is what we did for c++11.
6032020-04-02T19:40:12 <wumpus> compile the entire codebase with c++17 and c++11? that's a lot of cverhead
6042020-04-02T19:40:12 <jeremyrubin> We can upgrade to c++17 today but not accept code changes that break c++11 compat.
6052020-04-02T19:40:36 <sipa> wumpus: we did that for a while with c++11 i think, i actually?
6062020-04-02T19:40:48 <sipa> though i'm not sure this is the right time; our focus now is 0.20
6072020-04-02T19:40:51 <jeremyrubin> Releases etc can be c++17, but anyone can build for c++11. We probably need to do this for 1-2 releases
6082020-04-02T19:40:59 <jeremyrubin> sipa: it is the right time to start worrying about this
6092020-04-02T19:40:59 <sipa> and i think the discussion of when c++17 is a different one
6102020-04-02T19:41:03 *** vasild_ has joined #bitcoin-core-dev
6112020-04-02T19:41:06 <wumpus> sipa: oh you mean more like a travis run that compiles with c++17 instead of c++11?
6122020-04-02T19:41:12 <cfields> sipa: yea, that's what we did.
6132020-04-02T19:41:12 <sipa> wumpus: right
6142020-04-02T19:41:16 <jeremyrubin> Because if we do it for 0.20 it means 0.21 and 0.22 can use c++17
6152020-04-02T19:41:25 <cfields> sipa: we had a release that was "technically" c++11, but iirc we didn't force the flag on.
6162020-04-02T19:41:28 *** vincenzopalazzo has joined #bitcoin-core-dev
6172020-04-02T19:41:32 <cfields> Then we forced it on in master.
6182020-04-02T19:41:36 <sipa> cfields: right
6192020-04-02T19:41:52 <wumpus> makes sense to do that again then
6202020-04-02T19:41:54 <wumpus> for 0.21
6212020-04-02T19:41:57 <cfields> Don't remember for backports, I guess we were just kinda careful/reasonable about it?
6222020-04-02T19:42:09 <sipa> i guess if someone does the work for adding a c++17 travis build, and it passes with effectively no code changes... why not
6232020-04-02T19:42:21 *** luke-jr has quit IRC
6242020-04-02T19:42:39 <wumpus> I don't expect that to take a lot of changes
6252020-04-02T19:43:16 <sipa> i think so
6262020-04-02T19:44:01 <jeremyrubin> sounds like a plan to me?
6272020-04-02T19:44:11 <cfields> Also, we banned certain features when we started with c++11. thread_local is the obvious one that comes to mind, but IIRC there were others as well.
6282020-04-02T19:44:23 *** vasild has quit IRC
6292020-04-02T19:44:24 *** vasild_ is now known as vasild
6302020-04-02T19:44:34 <dongcarl> if there's consensus, can someone summarize the game plan?
6312020-04-02T19:45:38 <jeremyrubin> I can try...
6322020-04-02T19:46:00 <jeremyrubin> 1) Make 0.20 c++17 and c++11 buildable if easily doable
6332020-04-02T19:46:05 <wumpus> dongcarl: the idea is to add a travis run to compile the current code with c++17, do the minimum changes to be compatible with c++17 as well as c++11, for 0.21
6342020-04-02T19:46:08 *** ccdle12 has joined #bitcoin-core-dev
6352020-04-02T19:46:13 <sipa> trying a C++17 build now
6362020-04-02T19:46:24 <sipa> with gcc 9.3
6372020-04-02T19:46:37 <jeremyrubin> I thought we'd do it for 0.20 if it's a small patchset and we haven't branched it yet?
6382020-04-02T19:46:37 <wumpus> and delay the real switch to c++17 (like actually using new features) to 0.22
6392020-04-02T19:46:51 <wumpus> no, we're not going to do anything like that for 0.20
6402020-04-02T19:46:53 <jeremyrubin> Why not do it in 0.20 if it can be done?
6412020-04-02T19:47:05 <jeremyrubin> It has basically 0 functional changes?
6422020-04-02T19:47:08 <wumpus> 0.20.0rc1 should have been tagged yesterday
6432020-04-02T19:47:30 <wumpus> if anything is going in it's bugfixes
6442020-04-02T19:47:37 <cfields> fwiw, I'd like to do at least a small audit on the c++17/c++20 errata to see if there are any obvious implementation minefields to look out for.
6452020-04-02T19:47:41 <jeremyrubin> I mean it sort of doesn't really matter if it's in 0.20 or not as c++17 compat can be backported into a minor anyways...
6462020-04-02T19:48:29 <dongcarl> Okay, so what will gitian builds use? v0.20: c++11, v0.21: c++11, v0.22: c++17?
6472020-04-02T19:48:30 <cfields> (c++20 because presumably several c++17 issues were fixed there)
6482020-04-02T19:48:37 <dongcarl> cfields: Right, good call
6492020-04-02T19:49:01 <wumpus> dongcarl: gitian builds could use c++17 from 0.21 on
6502020-04-02T19:49:18 <wumpus> it just still has to be compatible with c++1
6512020-04-02T19:49:49 <sipa> wumpus: ah, so we can easily back out back to c++11 if issues are discovered?
6522020-04-02T19:49:51 <wumpus> so that things can be backported
6532020-04-02T19:49:57 <wumpus> sipa: that too
6542020-04-02T19:49:59 <sipa> right
6552020-04-02T19:50:05 <sipa> that seems reasonable
6562020-04-02T19:50:17 <cfields> Not sure about g++, but clang++ definitely has a switch for enforcing c++11 syntax/features for newer standards.
6572020-04-02T19:50:31 <cfields> So that'd be easy enough to lint/automate.
6582020-04-02T19:50:39 <sipa> oh the irony
6592020-04-02T19:50:46 <jeremyrubin> cfields: we only need one compiler to have that feature fortunately
6602020-04-02T19:50:55 <sipa> the only compile error i get with c++17 is Span related
6612020-04-02T19:51:00 <cfields> jeremyrubin: right
6622020-04-02T19:51:27 <dongcarl> Got it: v0.20: COMPAT with c++11 + c++17 only if easily doable, GITIAN with c++11; v0.21: COMPAT with c++11 + c++17, GITIAN with c++17; v0.22: COMPAT with c++17, GITIAN with c++17. Is this the plan?
6632020-04-02T19:51:51 <wumpus> sgtm
6642020-04-02T19:51:53 *** luke-jr has joined #bitcoin-core-dev
6652020-04-02T19:52:02 <sipa> dongcarl: ack
6662020-04-02T19:52:09 *** mdunnio has joined #bitcoin-core-dev
6672020-04-02T19:52:20 <dongcarl> Great. Will post on the c++17 issue
6682020-04-02T19:52:22 <jeremyrubin> Loks right. And backports from 0.22 only go to 0.21?
6692020-04-02T19:52:35 <jeremyrubin> Or to 0.20 too if we can get those builds up easily
6702020-04-02T19:52:57 <jeremyrubin> (depending on the feature using APIs that make backport non-trivial)
6712020-04-02T19:53:33 <wumpus> jeremyrubin: yes
6722020-04-02T19:53:40 <cfields> I think as long as we don't race to replace every line of code with a c++17ism we'll be fine, generally.
6732020-04-02T19:53:53 <wumpus> it's pretty rare in the first place to backport things two releases
6742020-04-02T19:54:01 <wumpus> cfields: also that
6752020-04-02T19:54:32 <jeremyrubin> cfields: noooo you can't just refactor the whole.... hahahah find and replace go refactorrrrrrrrrr
6762020-04-02T19:55:07 <sipa> refactorrrÌ
6772020-04-02T19:55:08 <wumpus> hehe I think we had a rule for that for C++11 as well, don't C++11-ize things for the sake of doing so
6782020-04-02T19:55:34 <sipa> right
6792020-04-02T19:57:10 <wumpus> is someone going to post this into the c++17 issue?
6802020-04-02T19:57:35 <jeremyrubin> dongcarl:
6812020-04-02T19:57:46 <sipa> FWIW, with #18468 + updating ax_cxx_compile_stdcxx.m4, everything compiles in c++17
6822020-04-02T19:57:48 <gribble> https://github.com/bitcoin/bitcoin/issues/18468 | Span improvements by sipa · Pull Request #18468 · bitcoin/bitcoin · GitHub
6832020-04-02T19:58:05 <dongcarl> Yeah making a little table now, perhaps jeremyrubin can add on about the backporting plan, not sure I understand it fully yet
6842020-04-02T19:58:30 <dongcarl> (add on in the issue)
6852020-04-02T19:59:10 <cncr04s> don't make me have to upgrade my distro to support new c++ versions
6862020-04-02T19:59:27 <sipa> cncr04s: what distro might that be?
6872020-04-02T19:59:44 <sipa> (we don't generally update c++ versions when it interferes with building on common platforms)
6882020-04-02T19:59:51 <cncr04s> ubuntu 14.04
6892020-04-02T20:00:10 <jeremyrubin> I'm not sure upgrading core is your largest concern there
6902020-04-02T20:00:14 <cfields> cncr04s: also, runtime is not affected. Releases are linked statically against lib(std)c++.
6912020-04-02T20:00:34 <cfields> So this is 99% a development decision.
6922020-04-02T20:00:43 <wumpus> #endmeeting
6932020-04-02T20:00:43 <lightningbot> Meeting ended Thu Apr 2 20:00:43 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6942020-04-02T20:00:43 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-02-19.01.html
6952020-04-02T20:00:43 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-02-19.01.txt
6962020-04-02T20:00:43 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-02-19.01.log.html
6972020-04-02T20:00:49 <wumpus> cfields: +1
6982020-04-02T20:01:06 <jeremyrubin> 14.04 has been EOL for a while so you want to upgrade anyways...
6992020-04-02T20:01:08 <wumpus> the binaries will still work on 14.04
7002020-04-02T20:01:12 <cncr04s> I should have said new gcc versions but, I stick with the versions that come from repo
7012020-04-02T20:01:42 <wumpus> but if you want to do development you'll need a gcc that supports c++17
7022020-04-02T20:02:19 <cncr04s> 18.04 likley then
7032020-04-02T20:02:22 <sipa> not that according to the plan, you'd need to do so at the earliest once 0.22 branches off (+- a year from now)
7042020-04-02T20:02:22 <wumpus> this is not unreasonable in these days, mind that this is a discussion for 0.22 at first which is a year away
7052020-04-02T20:02:50 <wumpus> 16.04 should have (can't find the issue right now tho)
7062020-04-02T20:02:52 <cfields> Yea, it's much simpler these days. c++11 took _years_ to gain compiler support.
7072020-04-02T20:03:03 <luke-jr> [19:38:06] <luke-jr> how about only building libconsensus with C++11?
7082020-04-02T20:03:04 <luke-jr> [19:38:25] <luke-jr> eg a dedicated Travis job that only builds that
7092020-04-02T20:03:06 <luke-jr> [19:38:39] <luke-jr> might be good to do anyway to ensure we don't accidentally boost-ify it
7102020-04-02T20:03:07 <cfields> so it was more understandable as a holdup imo.
7112020-04-02T20:03:07 <luke-jr> [19:38:46] <luke-jr> (don't install boost either)
7122020-04-02T20:03:08 <luke-jr> sorry, my internet cut out
7132020-04-02T20:03:27 <cncr04s> still using 0x only just over a year ago
7142020-04-02T20:03:37 <cncr04s> personally
7152020-04-02T20:03:51 <dongcarl> jeremyrubin: Updated issue description here: #16684
7162020-04-02T20:03:52 <gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
7172020-04-02T20:03:52 <sipa> c++14 is a very minor change; c++17 is somewhat bigger, but not nearly as big as c++03->c++11
7182020-04-02T20:04:07 <dongcarl> jeremyrubin: Perhaps you can write a little about the backporting situation
7192020-04-02T20:04:12 <cncr04s> mostly due to compilers and distros taking forever to update to them
7202020-04-02T20:04:15 <cfields> sipa: good point.
7212020-04-02T20:04:43 <sipa> also, all functional/unit tests run with c++17 (after 18468 )
7222020-04-02T20:08:39 <dongcarl> cfields: I think libstdc++ errata is the important one, yes?
7232020-04-02T20:08:54 <cfields> dongcarl: hmm?
7242020-04-02T20:09:42 <cfields> dongcarl: Sorry, I meant errata from the standard itself. Somewhere there's a collection of "oops, stuff we clearly got wrong in the spec".
7252020-04-02T20:10:00 <dongcarl> Ah okay I understand now
7262020-04-02T20:11:07 <cfields> dongcarl: but looking at implementation notes makes sense too.
7272020-04-02T20:15:57 <sipa> also compiles with clang++ 6.0 under c++17
7282020-04-02T20:18:29 <elichai2> So the time to start slowly replacing boost with c++17 is after 0.21 is branched off?
7292020-04-02T20:20:18 <jeremyrubin> elichai2: maybe; it kinda depends. If it takes 6+ months for your contribution to get reviewed and stuff to be merged you can do that... now! But you'd then possibly be merge gated until 0.21 is branched.
7302020-04-02T20:20:23 <elichai2> (I belive this isn't considered C++17-ize things just for the sake of doing so)
7312020-04-02T20:20:39 <jeremyrubin> It also depends on if your stuff has obvious backport shims
7322020-04-02T20:20:53 <jeremyrubin> We're already using option types for instance
7332020-04-02T20:21:41 <elichai2> Right. option should be easy to replace. I'm more thinking std::fs and the harder parts
7342020-04-02T20:22:00 <sipa> elichai2: after 0.22 is branched off
7352020-04-02T20:22:11 <sipa> eh, i guess that's ambiguous
7362020-04-02T20:22:28 <sipa> as soon as master branch is on the path to become 0.22, a year from now approximately
7372020-04-02T20:22:33 <jeremyrubin> sipa: there's a difference between the review window and the merge window
7382020-04-02T20:22:45 <sipa> oh no
7392020-04-02T20:22:55 <sipa> i'm confusing myself
7402020-04-02T20:23:00 <elichai2> Sipa, right so when 0.21 is branched off and master is 0.22 ;)
7412020-04-02T20:23:17 <sipa> so half a year from now, at the very earliest
7422020-04-02T20:23:55 *** PaulTroon has quit IRC
7432020-04-02T20:24:08 <sipa> this is funny in the list of deprecated c++17 features:
7442020-04-02T20:24:11 <sipa> P0618R0 Deprecate <codecvt> The entire header <codecvt> (which does not contain the class codecvt!) is deprecated, as are the utilities wstring_convert and wbuffer_convert. These features are hard to use correctly, and there are doubts whether they are even specified correctly. Users should use dedicated text-processing libraries instead.
7452020-04-02T20:26:11 <sipa> "this turns out to be hard; let someone else do it"
7462020-04-02T20:32:35 <elichai2> Loool
7472020-04-02T20:33:03 <elichai2> I think the new standards are cool on one hand, but on the other it seems like stl is just getting messier and messier
7482020-04-02T20:33:42 <jeremyrubin> messy stl > boost tho
7492020-04-02T20:35:14 <jeremyrubin> ugh github is kinda down
7502020-04-02T20:35:34 <sipa> elichai2: i think modern stl is pretty nice
7512020-04-02T20:35:39 <sipa> it's of course growing is features
7522020-04-02T20:35:52 <sipa> but they do seem to put a lot of work in making sure things work together nicely
7532020-04-02T20:36:11 <elichai2> jeremyrubin: oh that's a give. Boost is the kind of messy
7542020-04-02T20:36:28 *** manantial has quit IRC
7552020-04-02T20:36:41 <elichai2> sipa: right, Altough I'm not sure how I feel about their ADL overuse
7562020-04-02T20:36:48 <sipa> boost is really the STL sandbox :p
7572020-04-02T20:36:51 <sipa> ADL?
7582020-04-02T20:37:06 <elichai2> Argument dependent lookup
7592020-04-02T20:38:03 <elichai2> That you can have `void my_func(A& a);` and then you can just call `a.my_func()`
7602020-04-02T20:39:55 <sipa> elichai2: reading up on it
7612020-04-02T20:40:04 <jeremyrubin> Oh so you can patch in stuff to a class?
7622020-04-02T20:40:05 <sipa> it doesn't seem to be what you're saying
7632020-04-02T20:40:15 <jeremyrubin> Is it a syntax change?
7642020-04-02T20:40:19 <elichai2> Yeah I might be confusing 2 terms
7652020-04-02T20:40:30 <elichai2> Hard to see on my phone
7662020-04-02T20:40:39 <sipa> just that if you havea function A in namespace B, you can call `A(B::something)`, and it will attempt resolving it as "B::A(B::something)"
7672020-04-02T20:41:06 <sipa> without being in namespace B
7682020-04-02T20:46:40 <elichai2> what I remembered also doesn't seem to work hmm, maybe I'm confusing a c++2x proposal I've read, let me check
7692020-04-02T20:46:55 <promag> sorry, so when rc1?
7702020-04-02T20:47:49 <sipa> elichai2: it's hard to claim there is ADL overuse, when what you imagined ADL was isn't even possible :p
7712020-04-02T20:48:19 <elichai2> sipa: you're right hehe, I'm now doubting me memory lol
7722020-04-02T20:48:32 <elichai2> seeing way too many cppcon talks
7732020-04-02T20:49:11 <sipa> STL does use ADL for some things, for example the idion for calling swap on generic types is {using namespace std; swap(a, b); }
7742020-04-02T20:49:37 <sipa> which will use std::swap if possible, but also consider the namespaces a and b are to find a definition for a swap
7752020-04-02T20:50:12 <sipa> otherwise you'd need to inject swap into the std namespace for user-defined types
7762020-04-02T20:50:47 <sipa> arguably, it's saying that anything, in whatever namespace, with the name swap should have swap-like semantics, which is pretty polluting conceptually
7772020-04-02T20:52:01 <jonatack_> luke-jr: 18192 lgtm... github killed my review ack
7782020-04-02T20:53:16 <elichai2> sipa: Ok, at this point I honestly got no idea where that came into my mind. it seems non existent :O
7792020-04-02T20:53:36 <kanzure> hi/win 237
7802020-04-02T20:53:38 <elichai2> I should re-watch the C++17 talks
7812020-04-02T20:53:46 <dongcarl> GitHub is down! *crab dance*
7822020-04-02T20:53:46 <kanzure> ah crap
7832020-04-02T20:54:02 <jonatack_> github yay ð
7842020-04-02T20:54:22 <elichai2> dongcarl: that explains why cargo is giving me troubles :/
7852020-04-02T20:56:41 *** jonatack_ has quit IRC
7862020-04-02T20:56:52 *** filchef has quit IRC
7872020-04-02T20:57:01 <elichai2> Finally finished compiling stage2 clang-10 :D
7882020-04-02T20:58:09 <sipa> even gcc 9.3 doesn't have std::span :(
7892020-04-02T20:58:17 *** jonatack has joined #bitcoin-core-dev
7902020-04-02T20:58:22 <elichai2> yeah std::span is c++2x
7912020-04-02T20:58:37 <sipa> gcc 9.3 has some parts of c++2a
7922020-04-02T20:58:42 <sipa> but not std::span, it seems
7932020-04-02T20:58:45 <elichai2> right 2a not 2x
7942020-04-02T20:59:01 *** ddustin has joined #bitcoin-core-dev
7952020-04-02T20:59:07 <elichai2> yeah clang guys are really into experimental stuff where gcc seems less so
7962020-04-02T20:59:13 <sipa> it was c++1x(=11), c++1y(=14), c++1z(=17), c++a2(=20)
7972020-04-02T20:59:38 <dongcarl> std::span support starts with libstdc++ 10
7982020-04-02T20:59:54 <sipa> and in clang libc++ 7
7992020-04-02T21:00:02 *** subdriven1 has quit IRC
8002020-04-02T21:01:42 <elichai2> https://en.cppreference.com/w/cpp/header/experimental
8012020-04-02T21:07:36 *** bitcoin-git has joined #bitcoin-core-dev
8022020-04-02T21:07:37 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ff53433fe4ed...0d71395848bb
8032020-04-02T21:07:37 <bitcoin-git> bitcoin/master fa6e01f MarcoFalke: doc: block-relay-only is not blocksonly
8042020-04-02T21:07:38 <bitcoin-git> bitcoin/master 0d71395 MarcoFalke: Merge #18464: doc: block-relay-only vs blocksonly
8052020-04-02T21:07:40 *** bitcoin-git has left #bitcoin-core-dev
8062020-04-02T21:08:41 *** bitcoin-git has joined #bitcoin-core-dev
8072020-04-02T21:08:41 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18464: doc: block-relay-only vs blocksonly (master...2003-docBlockRelayOnly) https://github.com/bitcoin/bitcoin/pull/18464
8082020-04-02T21:08:42 *** bitcoin-git has left #bitcoin-core-dev
8092020-04-02T21:13:34 *** Guyver2 has quit IRC
8102020-04-02T21:19:47 *** vkmc1 has joined #bitcoin-core-dev
8112020-04-02T21:27:53 *** jarthur_ has joined #bitcoin-core-dev
8122020-04-02T21:28:22 *** ccdle12 has quit IRC
8132020-04-02T21:31:07 *** jarthur has quit IRC
8142020-04-02T21:32:59 *** emilengler has quit IRC
8152020-04-02T21:40:31 *** ccdle12 has joined #bitcoin-core-dev
8162020-04-02T21:45:21 *** jarthur has joined #bitcoin-core-dev
8172020-04-02T21:50:19 *** PaulTroon has joined #bitcoin-core-dev
8182020-04-02T22:00:04 *** ddustin has quit IRC
8192020-04-02T22:05:06 *** Talkless has quit IRC
8202020-04-02T22:19:13 *** DeanWeen has joined #bitcoin-core-dev
8212020-04-02T22:22:01 *** Dean_Guss has quit IRC
8222020-04-02T22:40:03 *** ahmed_ has quit IRC
8232020-04-02T22:48:57 <jeremyrubin> [13:50] <sipa> arguably, it's saying that anything, in whatever namespace, with the name swap should have swap-like semantics, which is pretty polluting conceptually
8242020-04-02T22:49:10 <jeremyrubin> sipa: I think this will be improved with concepts right?
8252020-04-02T22:51:36 *** bitcoin-git has joined #bitcoin-core-dev
8262020-04-02T22:51:36 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0d71395848bb...dce6f3b29b41
8272020-04-02T22:51:36 <bitcoin-git> bitcoin/master f65c9ad Elichai Turkel: Check for overflow when calculating sum of outputs
8282020-04-02T22:51:37 <bitcoin-git> bitcoin/master dce6f3b MarcoFalke: Merge #18383: refactor: Check for overflow when calculating sum of tx outp...
8292020-04-02T22:51:38 *** bitcoin-git has left #bitcoin-core-dev
8302020-04-02T22:51:56 *** bitcoin-git has joined #bitcoin-core-dev
8312020-04-02T22:51:56 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18383: refactor: Check for overflow when calculating sum of tx outputs (master...2020-03-value-overflow) https://github.com/bitcoin/bitcoin/pull/18383
8322020-04-02T22:51:57 *** bitcoin-git has left #bitcoin-core-dev
8332020-04-02T22:52:50 <sipa> jeremyrubin: partially maybe
8342020-04-02T22:54:04 *** sonofhan has joined #bitcoin-core-dev
8352020-04-02T22:54:08 <sipa> it still means that various stl libraries will try to invoke your user-defined namespace's swap functions if you're not careful
8362020-04-02T22:54:16 <sipa> *stl functions
8372020-04-02T22:54:21 <jeremyrubin> True.
8382020-04-02T22:54:48 <jeremyrubin> Also looking at c++20 swappable it looks wrong for accomplishing this
8392020-04-02T22:55:28 <jeremyrubin> But in theory you could have a concept which uses std::swap to delegate to the member function swap
8402020-04-02T22:56:04 <sipa> it seems c++20 actually explicitly allows user-defined std::swap (in the std namespace)
8412020-04-02T22:56:38 <jeremyrubin> Probably a better way to fix it as most existing code bases will take a long time to get any sort of concepts deeply integrated
8422020-04-02T22:57:44 <jeremyrubin> TBH one of the c++17 features I'm most excited for is the map/unordered_map node extract API :p
8432020-04-02T22:59:02 *** AaronvanW has quit IRC
8442020-04-02T23:05:52 *** mdunnio has quit IRC
8452020-04-02T23:08:07 *** sonofhan has quit IRC
8462020-04-02T23:08:53 *** mdunnio has joined #bitcoin-core-dev
8472020-04-02T23:13:34 *** owowo has quit IRC
8482020-04-02T23:15:44 <fanquake> jonatack: why did you remove parts of the release notes in the wiki? i.e dark mode support on macOS?
8492020-04-02T23:18:13 *** timothy has quit IRC
8502020-04-02T23:18:36 *** owowo has joined #bitcoin-core-dev
8512020-04-02T23:22:57 *** captjakk has quit IRC
8522020-04-02T23:23:29 *** captjakk has joined #bitcoin-core-dev
8532020-04-02T23:25:26 *** ccdle12 has quit IRC
8542020-04-02T23:27:41 *** captjakk has quit IRC
8552020-04-02T23:46:44 *** vincenzopalazzo has quit IRC
8562020-04-02T23:48:00 *** promag has quit IRC
8572020-04-02T23:49:43 *** marcoagner has quit IRC
8582020-04-02T23:50:23 *** molz_ has joined #bitcoin-core-dev
8592020-04-02T23:53:03 *** molly has quit IRC
8602020-04-02T23:56:53 *** justanotheruser has quit IRC
8612020-04-02T23:57:31 *** captjakk has joined #bitcoin-core-dev