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