< 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
< 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
< 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
< 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 :)
< 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)