< bitcoin-git> [bitcoin] promag opened pull request #18338: wip: Fix wallet unload race condition (master...notify-shared) https://github.com/bitcoin/bitcoin/pull/18338
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #18337: init: Remove boost::thread_group (master...2003-NoBoostThreadGroup) https://github.com/bitcoin/bitcoin/pull/18337
< bitcoin-git> [bitcoin] gzhao408 opened pull request #18339: wip [test] multiple reject reasons for test_witness_block (master...test_witness_block-multiple-reasons) https://github.com/bitcoin/bitcoin/pull/18339
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e2d36639ca87...3f9e6a3c1ce8
< bitcoin-git> bitcoin/master a33cffb Jon Atack: util: HelpExampleRpc formatting fixup
< bitcoin-git> bitcoin/master 3f9e6a3 fanquake: Merge #18316: util: HelpExampleRpc formatting
< bitcoin-git> [bitcoin] fanquake merged pull request #18316: util: HelpExampleRpc formatting (master...json-rpc-example-template-formatting) https://github.com/bitcoin/bitcoin/pull/18316
< sipa> MarcoFalke: lol at your github profile picture
< bitcoin-git> [bitcoin] fanquake opened pull request #18340: doc: mention MAKE=gmake workaround when building on a BSD (master...fixup_18129) https://github.com/bitcoin/bitcoin/pull/18340
< bitcoin-git> [bitcoin] fanquake closed pull request #18129: Doc: Fix BSD docs regarding gmake (master...bsddocs) https://github.com/bitcoin/bitcoin/pull/18129
< bitcoin-git> [bitcoin] fanquake closed pull request #16083: [WIP] transaction fees in getblock (master...201905_grt_prevout) https://github.com/bitcoin/bitcoin/pull/16083
< bitcoin-git> [bitcoin] promag closed pull request #18280: wallet: UnregisterValidationInterface before SyncWithValidationInterfaceQueue (master...2020-03-sync-unregistervalidationinterface) https://github.com/bitcoin/bitcoin/pull/18280
< bitcoin-git> [bitcoin] domob1812 opened pull request #18341: Replace remaining literal BTC with CURRENCY_UNIT. (master...currency-unit) https://github.com/bitcoin/bitcoin/pull/18341
< bitcoin-git> [bitcoin] practicalswift opened pull request #18342: doc: Add fuzzing quickstart guide (master...fuzzing-quick-start-guide) https://github.com/bitcoin/bitcoin/pull/18342
< bitcoin-git> [bitcoin] instagibbs opened pull request #18343: Use min relay value constant in QT (master...qt_min_relay) https://github.com/bitcoin/bitcoin/pull/18343
< bitcoin-git> [bitcoin] stevenroose opened pull request #18344: Fix nit in getblockchaininfo (master...nit-blockchaininfo) https://github.com/bitcoin/bitcoin/pull/18344
< bitcoin-git> [bitcoin] instagibbs closed pull request #18343: Use min relay value constant in QT (master...qt_min_relay) https://github.com/bitcoin/bitcoin/pull/18343
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18345: test: Bump timeouts to avoid valgrind failures (master...2003-qaBumpTimeoutsAgain) https://github.com/bitcoin/bitcoin/pull/18345
< emilengler> Does strprintf jusnt formats the string or also translates?
< fjahr> emilengler: you give the translated string to strprintf, example: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L3783
< wumpus> strprintf is simply an alias for tfm::format, it doesn't perform any kind of translation
< wumpus> luckily not; most of its uses are, and should be, completely independent of locale
< sipa> it uses c++ stream formatting under the hood though, so it could be affected by changing the c++ global locale (which afaik we don't do)
< wumpus> oh no...
< * wumpus> wants to really never use C++ again
< sipa> haha
< wumpus> I really thought we had avoided that but it's worse every time
< wumpus> in any case, it doesn't translate ...
< sipa> yes!
< meshcollider> Reminder: wallet meeting in 10 mins :)
< meshcollider> #startmeeting
< lightningbot> Meeting started Fri Mar 13 19:00:16 2020 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< achow101> hi
< sipa> hi
< meshcollider> #bitcoin-core-dev Wallet 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 ariard digi_james amiti fjahr
< meshcollider> jeremyrubin emilengler jonatack hebasto jb55
< jonatack> hi
< meshcollider> topics?
< sipa> i'm wondering how to integrate miniscript
< achow101> how so?
< meshcollider> #topic Miniscript Integration (sipa)
< wumpus> hi
< sipa> so the big question is what the relation between the miniscript c++ code/library i have, and its integration in core
< sipa> as it's written currently, it relies on core's script.h and a few other utilities, to avoid code duplication
< sipa> but that makes it harder to use as a standalone separate library (you'd need to copy files)
< sipa> so i was wondering if it wouldn't be better to make it an actual standalone thing, which can be subtree'd or whatever instead, but is also fully functional on its own - even though that implies some code duplication
< meshcollider> ( Link for reference: https://github.com/sipa/miniscript )
< sipa> indeed
< achow101> how much duplication would there be?
< hebasto> hi
< luke-jr> sipa: another possibility could be to make a library for script stuff, shared by both
< sipa> luke-jr: right, that is a possibility - though probably pretty far off
< sipa> achow101: at least CScript and all opcode definitions
< sipa> there is probably more
< achow101> would you need to have all opcodes though?
< sipa> no, but i don't think that's a material distinction
< wumpus> if it's going to be consensus code, it would be good to avoid code duplication and aim for tight integration into bitcoin core, I think
< sipa> none of this should ever need to be consensus code
< ryanofsky> how would the duplication work? would there be functions to convert one cscript struct to the other?
< wumpus> okay, then that's not an issue
< sipa> ryanofsky: right, by treating them as byte arrays
< wumpus> I was just afraid of ballooning complexity of some things, which are already complex to test/verify/ by having them multiple times
< sipa> which they affectively are
< wumpus> yes, CScript is effectively a byte array, wasn't there a PR to separate the script functions from the storage?
< ryanofsky> is the serialization framework duplicated too?
< achow101> sipa: that would seem to make other areas more complicated where conversions between miniscript's cscript and core's cscript are necessary
< sipa> #13062
< gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
< wumpus> right
< sipa> ryanofsky: no, the serialization framework isn't used internally to script
< meshcollider> The alternative is to just include the miniscript code directly into core right?
< luke-jr> could always split it out later :x
< sipa> yeah, better reusable generic script code would be useful
< luke-jr> (eg, when we finally split out the wallet)
< sipa> and as luke-jr suggested, maybe the miniscript logic could evolve into that
< sipa> (which i guess would mean we keep the existing CScript or a stripped-down version of it in consensus, but not for signing/... etc)
< achow101> would it be possible to just have it link against core's cscript while still keeping miniscript's cscript when people want to use it as a separate library?
< wumpus> I was about to say, the advantage of duplication in this case wouldb e that no code affecting consensus needs to be changed for something not affecting consensus
< sipa> achow101: maybe- but i'm not sure there is much benefit to that
< sipa> because now you need to test miniscript with both
< sipa> ryanofsky: actually the code i have right now does copy serialize.h, though if i remember correctly it's just because CScript's serializers need it, despite not being used
< sipa> maybe i should just try to make it something independent, and see how bad it is
< luke-jr> make it a dependency of the library, and only support using it within Core for now?
< sipa> the same code is used for the policy compiler i have on my site
< luke-jr> (eg, so other code using the library needs to provide a compatible CScript)
< sipa> that's what i'm doing now, but it's kinda painful
< sipa> especially to keep the library itself testable
< luke-jr> sounds like something to fix in the test framework / build system
< luke-jr> or at least fixable
< sipa> i don't think having 2 separate CScript-and-opcodes implementations is beneficial
< sipa> they're effectively trivial modulus, with only boilerplate code
< sipa> if somehow one side of things needs to provide a compatible interface, it would just copy it
< achow101> how about we integrate miniscript into core, then library-ize script, and then library-ize miniscript?
< sipa> achow101: so also include the policy compiler in core?
< achow101> sure
< sipa> i'm not opposed to that, but i'm not sure it's the right approach
< meshcollider> Mhm I think trying to make miniscript independent first and seeing how it goes would be better
< sipa> i think i prefer that- especially the idea that it could perhaps evolve into something of a "non-consensus script subtree" is appealing
< sipa> any other topics?
< sipa> meshcollider: intro to hyperelliptic curves?
< achow101> ha
< meshcollider> sipa: lol someone already wrote a blog post about it so I don't need to :p
< sipa> i know :)
< meshcollider> achow101 any other reviews/merge begs for me to add to my to-do list for the next 2 days?
< achow101> meshcollider: every PR i have open :)
< jonatack> any last-minute feature freeze reviews? i'll be doing those this weekend
< achow101> meshcollider: #18204
< gribble> https://github.com/bitcoin/bitcoin/issues/18204 | descriptors: improve descriptor cache and cache xpubs by achow101 · Pull Request #18204 · bitcoin/bitcoin · GitHub
< meshcollider> Yeah I already have that one down :p
< achow101> #16946 and #16463 are both tagged 0.20 but neither have gotten review, so I don't think they'll make it
< gribble> https://github.com/bitcoin/bitcoin/issues/16946 | wallet: include a checksum of encrypted private keys by achow101 · Pull Request #16946 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16463 | [BIP 174] Implement serialization support for GLOBAL_XPUB field. by achow101 · Pull Request #16463 · bitcoin/bitcoin · GitHub
< jonatack> maybe #17509
< gribble> https://github.com/bitcoin/bitcoin/issues/17509 | gui: save and load PSBT by Sjors · Pull Request #17509 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18346: rpc: Document an RPCResult for all calls; Enforce at compile time (master...2003-docAllRpcRes) https://github.com/bitcoin/bitcoin/pull/18346
< achow101> 17509 would be nice to have for 0.20
< meshcollider> Yep 17509 is very nice
< meshcollider> Ok that's all for the meeting then
< meshcollider> #endmeeting
< lightningbot> Meeting ended Fri Mar 13 19:29:56 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< meshcollider> sipa: I'm updating the paper at the moment btw, at the moment I'm trying to create a convincing argument that for large prime field order, the proportion of non-simple isogeny classes of Jacobians is pretty negligible (those which cover an elliptic curve)
< sipa> :)
< achow101> meshcollider: do you think we can get #17681 into 0.20? it's kind of a bug fix, kind of a feature
< gribble> https://github.com/bitcoin/bitcoin/issues/17681 | wallet: Keep inactive seeds after sethdseed and derive keys from them as needed by achow101 · Pull Request #17681 · bitcoin/bitcoin · GitHub
< meshcollider> Um it's not looking good since it only has concept ACKs
< meshcollider> Depends if you can bribe enough people for a fast review today/tomorrow :p
< sipa> if it's a bug fix it can go in after the feature freeze
< meshcollider> Im not sure it's really bug-fix-y enough to be a "bugfix"?
< meshcollider> Ok yeah why not, its a good change, I think we can get it in
< instagibbs> oh yeah meeting stuff
< instagibbs> I'd prefer subtree or something for miniscript, just for the "let's not touch consensus" reasons
< instagibbs> and #17509 is quite easy to test and would be nice, please review :)
< gribble> https://github.com/bitcoin/bitcoin/issues/17509 | gui: save and load PSBT by Sjors · Pull Request #17509 · bitcoin/bitcoin · GitHub
< sipa> instagibbs: to be clear, i don't think any of this, regardless of what approach is used, should ever affect consensus code
< instagibbs> of course
< instagibbs> I guess I just think it'd be cleaner to be a separate project :shrug:
< instagibbs> s/proj/repo/
< sipa> yeah, i think so too
< instagibbs> You may also get a bit more downstream usage/contribution/feedback that way too if it's really a library
< bitcoin-git> [bitcoin] jnewbery closed pull request #17485: WIP: net processing: Don't reach into CBlockIndex to check for block mutation (master...2019-11-processnewblock-early-return2) https://github.com/bitcoin/bitcoin/pull/17485
< bitcoin-git> [bitcoin] jnewbery closed pull request #17562: WIP: Validation: Remove ConnectTrace and PerBlockConnectTrace (master...2019-11-remove-connect-trace) https://github.com/bitcoin/bitcoin/pull/17562
< instagibbs> I would like a real C++ miniscript library :)
< jnewbery> #18002 has 6 ACKs. I think it's good for merge
< gribble> https://github.com/bitcoin/bitcoin/issues/18002 | Abstract out script execution out of VerifyWitnessProgram() by sipa · Pull Request #18002 · bitcoin/bitcoin · GitHub
< jnewbery> #16902 also has 5 ACKs and should be RFM
< gribble> https://github.com/bitcoin/bitcoin/issues/16902 | O(1) OP_IF/NOTIF/ELSE/ENDIF script implementation by sipa · Pull Request #16902 · bitcoin/bitcoin · GitHub
< jnewbery> (I left some comment nits on 16902 which can easily be added in a follow-up PR if people think they're helpful)
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3f9e6a3c1ce8...e5cb0dffd5ac
< bitcoin-git> bitcoin/master c8e24dd Pieter Wuille: [REFACTOR] Abstract out script execution out of VerifyWitnessProgram()
< bitcoin-git> bitcoin/master e5cb0df Wladimir J. van der Laan: Merge #18002: Abstract out script execution out of VerifyWitnessProgram()
< bitcoin-git> [bitcoin] laanwj merged pull request #18002: Abstract out script execution out of VerifyWitnessProgram() (master...202001_execute_witness) https://github.com/bitcoin/bitcoin/pull/18002
< ysangkok> instagibbs: when you say "real library", does that include version numbers and API/ABI stability? ;)
< sipa> one problem with doing so at this point that it'd need reviewers...
< bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/e5cb0dffd5ac...7f8176a1ebd0
< bitcoin-git> bitcoin/master 474ea3b Andrew Chow: Introduce DescriptorCache struct which caches xpubs
< bitcoin-git> bitcoin/master df55d44 Andrew Chow: Track the index of the key expression in PubkeyProvider
< bitcoin-git> bitcoin/master 66c2cad Andrew Chow: Rename BIP32PubkeyProvider.m_extkey to m_root_extkey
< bitcoin-git> [bitcoin] laanwj merged pull request #18204: descriptors: improve descriptor cache and cache xpubs (master...desc-xpub-cache) https://github.com/bitcoin/bitcoin/pull/18204
< aj> instagibbs: c++, not c or rust?
< achow101> \o/ I think there's no pre-reqs left for descriptor wallets
< bitcoin-git> [bitcoin] joe-rodgers opened pull request #18347: Update all occurences of 2009-2019 to be 2009-2020 (master...master) https://github.com/bitcoin/bitcoin/pull/18347
< sipa> aj: one challenge is that so far it has seemed very useful to have miniscript types with parametrized key types (in the compiler they're strings, in signing logic they're CKeyIDs, in descriptors they're pubkey expressions...), which seems hard to accomodate with a simple C-callable API
< jonatack> achow101: hoorah! :)
< luke-jr> instagibbs: non-consensus shouldn't be subtreed at all, though we might have to in this case
< sipa> luke-jr: well it'd be pretty much a headers-only library anyway, there wouldn't really be anything to dynamically link
< luke-jr> :x
< luke-jr> metaprogramming/templates kinda do force static linking by nature
< sipa> (that doesn't mean it needs to be subtreed, but the advantages of not doing it go down significantly)
< bitcoin-git> [bitcoin] fanquake closed pull request #18347: Update all occurences of 2009-2019 to be 2009-2020 (master...master) https://github.com/bitcoin/bitcoin/pull/18347