19:00:16 <meshcollider> #startmeeting
19:00:16 <lightningbot> Meeting started Fri Mar 13 19:00:16 2020 UTC.  The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:16 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:24 <achow101> hi
19:00:25 <sipa> hi
19:00:26 <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
19:00:27 <meshcollider> jeremyrubin emilengler jonatack hebasto jb55
19:00:36 <jonatack> hi
19:00:38 <meshcollider> topics?
19:01:10 <sipa> i'm wondering how to integrate miniscript
19:02:23 <achow101> how so?
19:02:23 <meshcollider> #topic Miniscript Integration (sipa)
19:02:46 <wumpus> hi
19:03:04 <sipa> so the big question is what the relation between the miniscript c++ code/library i have, and its integration in core
19:03:33 <sipa> as it's written currently, it relies on core's script.h and a few other utilities, to avoid code duplication
19:03:53 <sipa> but that makes it harder to use as a standalone separate library (you'd need to copy files)
19:04:59 <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
19:05:44 <meshcollider> ( Link for reference: https://github.com/sipa/miniscript )
19:05:51 <sipa> indeed
19:06:17 <achow101> how much duplication would there be?
19:06:44 <hebasto> hi
19:06:49 <luke-jr> sipa: another possibility could be to make a library for script stuff, shared by both
19:07:09 <sipa> luke-jr: right, that is a possibility - though probably pretty far off
19:07:19 <sipa> achow101: at least CScript and all opcode definitions
19:07:27 <sipa> there is probably more
19:07:43 <achow101> would you need to have all opcodes though?
19:08:07 <sipa> no, but i don't think that's a material distinction
19:08:46 <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
19:09:10 <sipa> none of this should ever need to be consensus code
19:09:11 <ryanofsky> how would the duplication work? would there be functions to convert one cscript struct to the other?
19:09:24 <wumpus> okay, then that's not an issue
19:09:56 <sipa> ryanofsky: right, by treating them as byte arrays
19:10:02 <wumpus> I was just afraid of ballooning complexity of some things, which are already complex to test/verify/ by having them multiple times
19:10:07 <sipa> which they affectively are
19:10:32 <wumpus> yes, CScript is effectively a byte array, wasn't there a PR to separate the script functions from the storage?
19:10:35 <ryanofsky> is the serialization framework duplicated too?
19:10:36 <achow101> sipa: that would seem to make other areas more complicated where conversions between miniscript's cscript and core's cscript are necessary
19:10:48 <sipa> #13062
19:10:52 <gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
19:10:53 <wumpus> right
19:11:09 <sipa> ryanofsky: no, the serialization framework isn't used internally to script
19:11:20 <meshcollider> The alternative is to just include the miniscript code directly into core right?
19:11:43 <luke-jr> could always split it out later :x
19:11:56 <sipa> yeah, better reusable generic script code would be useful
19:12:04 <luke-jr> (eg, when we finally split out the wallet)
19:12:08 <sipa> and as luke-jr suggested, maybe the miniscript logic could evolve into that
19:12:33 <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)
19:12:52 <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?
19:13:17 <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
19:13:27 <sipa> achow101: maybe- but i'm not sure there is much benefit to that
19:13:41 <sipa> because now you need to test miniscript with both
19:14:15 <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
19:15:04 <sipa> maybe i should just try to make it something independent, and see how bad it is
19:15:22 <luke-jr> make it a dependency of the library, and only support using it within Core for now?
19:16:30 <sipa> the same code is used for the policy compiler i have on my site
19:16:43 <luke-jr> (eg, so other code using the library needs to provide a compatible CScript)
19:17:00 <sipa> that's what i'm doing now, but it's kinda painful
19:17:09 <sipa> especially to keep the library itself testable
19:18:44 <luke-jr> sounds like something to fix in the test framework / build system
19:18:44 <luke-jr> or at least fixable
19:19:23 <sipa> i don't think having 2 separate CScript-and-opcodes implementations is beneficial
19:19:36 <sipa> they're effectively trivial modulus, with only boilerplate code
19:20:15 <sipa> if somehow one side of things needs to provide a compatible interface, it would just copy it
19:20:39 <achow101> how about we integrate miniscript into core, then library-ize script, and then library-ize miniscript?
19:20:53 <sipa> achow101: so also include the policy compiler in core?
19:21:12 <achow101> sure
19:21:23 <sipa> i'm not opposed to that, but i'm not sure it's the right approach
19:22:38 <meshcollider> Mhm I think trying to make miniscript independent first and seeing how it goes would be better
19:23:46 <sipa> i think i prefer that- especially the idea that it could perhaps evolve into something of a "non-consensus script subtree" is appealing
19:24:36 <sipa> any other topics?
19:25:57 <sipa> meshcollider: intro to hyperelliptic curves?
19:26:07 <achow101> ha
19:26:32 <meshcollider> sipa: lol someone already wrote a blog post about it so I don't need to :p
19:26:50 <sipa> i know :)
19:27:05 <meshcollider> achow101 any other reviews/merge begs for me to add to my to-do list for the next 2 days?
19:27:22 <achow101> meshcollider: every PR i have open :)
19:27:24 <jonatack> any last-minute feature freeze reviews? i'll be doing those this weekend
19:27:38 <achow101> meshcollider: #18204
19:27:42 <gribble> https://github.com/bitcoin/bitcoin/issues/18204 | descriptors: improve descriptor cache and cache xpubs by achow101 · Pull Request #18204 · bitcoin/bitcoin · GitHub
19:27:54 <meshcollider> Yeah I already have that one down :p
19:28:25 <achow101> #16946 and #16463 are both tagged 0.20 but neither have gotten review, so I don't think they'll make it
19:28:26 <gribble> https://github.com/bitcoin/bitcoin/issues/16946 | wallet: include a checksum of encrypted private keys by achow101 · Pull Request #16946 · bitcoin/bitcoin · GitHub
19:28:28 <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
19:28:59 <jonatack> maybe #17509
19:29:02 <gribble> https://github.com/bitcoin/bitcoin/issues/17509 | gui: save and load PSBT by Sjors · Pull Request #17509 · bitcoin/bitcoin · GitHub
19:29:19 <bitcoin-git> [13bitcoin] 15MarcoFalke opened pull request #18346: rpc: Document an RPCResult for all calls; Enforce at compile time (06master...062003-docAllRpcRes) 02https://github.com/bitcoin/bitcoin/pull/18346
19:29:28 <achow101> 17509 would be nice to have for 0.20
19:29:34 <meshcollider> Yep 17509 is very nice
19:29:50 <meshcollider> Ok that's all for the meeting then
19:29:56 <meshcollider> #endmeeting