< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18757: test: Remove enumeration of expected deserialization exceptions in ProcessMessage(...) fuzzer (master...remove-EXPECTED_DESERIALIZATION_EXCEPTIONS) https://github.com/bitcoin/bitcoin/pull/18757
< jonatack>
MarcoFalke: am trying to reproduce the stack use-after-return in validationinterface in #18742 with added 500us delay. how long did it take for you to see it while looping the test?
< meshcollider>
Yes ^ so that's exciting, maybe we can even get it merged this weekend
< kanzure>
hi
< instagibbs>
hi
< achow101>
I would like that to be merged soon
< achow101>
I have a couple of followups already planned
< meshcollider>
If anyone else has time for review in the next few days, please review that
< instagibbs>
achow101, what did we arrive on with respect to descriptor export? Are we just conisdering descriptor wallets experimental and fixing as we go?
< achow101>
instagibbs: that's my plan
< sipa>
seems reasonable
< jnewbery>
hi
< meshcollider>
It's good to have it ready so early in the 0.21 release cycle too
< instagibbs>
ok I'll go through one more time and give my ACK/follow-up rec
< meshcollider>
Any other things to discuss?
< fjahr>
I suggested adding a warning to createwallet that it's experimental, that was my only open suggestion, but can be merged as is as well :)
< achow101>
fjahr: I'm planning on opening a PR with release notes. I can add that warning at that time too
< meshcollider>
Yep that's an easy followup
< instagibbs>
post-merge then #18027 can be rebased one more time
< jonatack>
fjahr: yeah, PRs like that one highlight the limitations of GitHub, 6 separate clicks and loads of "hidden items, Load more..." just to read semi-recent comments
< luke-jr>
isn't there a way to show all?
< instagibbs>
gotta get it merged so i dont have to click "see more discussion" 50 times on that PR
< instagibbs>
:/
< jonatack>
it's highly annoying...if there is a way to show all, i'd be happy to learn of it
< meshcollider>
Not that I know of, someone could write a browser extension for it ;)
< sipa>
just use your email interface instead
< fjahr>
jonatack: I actually researched that, and github added some load all feature but then it is again deactivated for 200+ messages or something like that, so annoying
< jonatack>
i'm hoping github's cli client will get there eventually...speaking of which, it's been a month or more since i last tried it
< instagibbs>
anyhoo, I re-ack'd it lightly imo ready for a nice early in cycle merge
< fjahr>
meshcollider: jonatack: https://github.com/sindresorhus/refined-github is an extension that adds it with alt+click on the 'load more' link, it works, but it's a big extension for such a small feature
< instagibbs>
meshcollider, over weekend merge would be nice
< achow101>
I was going to say he should merge it now, before the weekend. but then I remembered that kiwis live in the future and it's already saturday for him
< jonatack>
fjahr: thanks TIL will check it out
< jeremyrubin>
oops I had a wallet question
< jeremyrubin>
Has anyone been working on a spec for script finalizers?
< jeremyrubin>
with psbt stuff it seems like that's kinda "left to the reader"
< sipa>
jeremyrubin: it depends on what scripts you support
< jeremyrubin>
All of them?
< jeremyrubin>
suppose it's possible to enumerate all possible stack parameter configurations.
< sipa>
you could write a spec for P2PK, P2PKH, P2WPKH, multisig, P2SH/P2WSH versions of those, ...
< jeremyrubin>
Right now I'm just encoding things into the witness stack with a known prefix and then appending metadata
< sipa>
miniscript has generic signing logic for all its supported scripts, ...
< jeremyrubin>
But that's hardly robust
< sipa>
what are you trying to do?
< instagibbs>
solve bitcoin script, obviously
< jeremyrubin>
Well I have my own script compiler that emits checktemplateverify based programs.
< jeremyrubin>
Miniscript is better at the actual script compilation part for sure, but it was harder to integrate it with the other components in my system so I made my own restricted script subset.
< sipa>
this has nothing to do with compilation
< sipa>
it's given a script and a bunch of signatures/keys, construct a witness
< jeremyrubin>
Well what I output from my compiler is a list of all witness templates.
< sipa>
compilation happens before the address even exists
< jeremyrubin>
I'm merely asking if there's already a standard format for witness templates
< sipa>
ah, well perhaps you need a private PSBT extension to keep that template information around?
< sipa>
or the input to the compiler, and then have the finalizer re-run the compiler
< jeremyrubin>
Yes both can be done
< jeremyrubin>
But it seems like it's a common enough thing?
< sipa>
miniscript doesn't need it :)
< jeremyrubin>
Miniscript takes the additional compilation pass to emit witness?
< jeremyrubin>
How does miniscript avoid it?
< sipa>
miniscript's signing algorithm works with just the compiled script
< sipa>
taproot will need extensions too, to store all possible scripts in the merkle tree
< jeremyrubin>
Yeah I can do that too.
< jeremyrubin>
There's no problem with what I'm doing right now and it all works fine
< jeremyrubin>
I am just curious if there's a standard format for it
< sipa>
i don't think there can be
< sipa>
it's highly dependent on what kind of script constructions you're talking about
< sipa>
especially if you take future hypothetical script semantics changes into account
< jeremyrubin>
What's wrong with a list of tuples of arrays of metadata or witness element?
< sipa>
psbt is basically a huge dict
< sipa>
you can store whatever you need in it
< sipa>
i'm not sure what "list of tuples of arrays of metadata" means otherwise
< jeremyrubin>
Ah. So the difference is that it seems that the data in PSBT is unordered?
< jeremyrubin>
And you only store *one* witness (transaction level) not all possible ones
< sipa>
it's a global dict, and one dict per input, and one dict per output
< jeremyrubin>
instagibbs: I'm aware!
< jeremyrubin>
But that's not a standard
< sipa>
i have honestly no idea what you want a standard for
< jeremyrubin>
It's fine we don't need to get into the specifics my question is well answered already
< sipa>
or what you're suggesting
< jeremyrubin>
So from miniscript I should be able to output a list of all possible witness stacks, with specific data stubbed out correct?
< sipa>
given a script, yes
< jeremyrubin>
Right.
< sipa>
though the signing algorithm is much smarter than that (it will take into account what signatures are available or not, try to guarantee non-malleability, ...)
< jeremyrubin>
So let's say I want to transport that set of possible stacks to someone, so they can pick and sign.
< sipa>
eh
< sipa>
the number of possible stacks can be intractable
< sipa>
combinatorial explosion
< jeremyrubin>
Sure! There are situations where it isn't though, and I think they are relatively common. Or at least you can output a non exhaustive list.
< jeremyrubin>
with a representative of each malleable set
< sipa>
possibly, but you'd need to encode under which conditions each can be used as well
< sipa>
e.g. known hash preimages, timelocks, currently
< sipa>
but that too could easily be expanded in future extensions
< jeremyrubin>
Ok so here's a scenario that I think is hard with PSBT
< sipa>
also, what are the stubbed out things in your model? public keys + sighash?
< jeremyrubin>
Just signatures and hashes at the moment, but it supports arbitrary extensions for whatever "leaves nothing on the stack" fragment you want to add
< sipa>
my suggestion is to first build something that works
< bitcoin-git>
bitcoin/master c4027e7 Sebastian Falbesoner: refactor: test: use wait_for_getdata() in p2p_compactblocks.py
< bitcoin-git>
bitcoin/master a215c61 MarcoFalke: Merge #18756: refactor: test: use wait_for_getdata() in p2p_compactblocks....
< sipa>
and then talk about standardization
< jeremyrubin>
Already there :)
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18756: refactor: test: use wait_for_getdata() in p2p_compactblocks.py (master...20200424-test-use-wait_for_getdata-in-p2p_compactblocks) https://github.com/bitcoin/bitcoin/pull/18756
< jeremyrubin>
Ah I think I see where there's some confusion on the enumerablity; I'm compiling the scripts from DNF form right now
< jeremyrubin>
Inherently that makes their satisfiability easy to look at
< sipa>
so here is another angle: signers need to understand what they're signing, which generally means that can't be given too processed data (e.g. you can't give them a sighash to sign, or they'd risk signing something crazy)
< sipa>
you only need a finalizer for a specific type of script to participate, if there is actually such a script involved
< sipa>
which likely one of the signers or updaters needs logic for anyway
< sipa>
so i think there isn't much need for grand generic finalizer logic
< sipa>
some of the people involved with signing will understand the script (and whatever crazy things it does) anyway, so they can finalize
< jeremyrubin>
BTW do you have any thoughts on if I add CTV support to miniscript? It's relatively I think and can be macro'd in or something...
< sipa>
i'm not even interested in adding taproot support until that's active on the network
< jeremyrubin>
To be fair that's a lot more involved. I want people to be able to start testing more stuff; kallewoof has been setting up a signet with both iirc.
< sipa>
feel free to make your own branch or something
< jeremyrubin>
Will do. What's the state of bindings BTW. Has anyone put together python/js bindings yet or still c/rust?
< sipa>
there is a python implementation
< jeremyrubin>
Oh? It's not on the site
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18759: bench: Start nodes with -nodebuglogfile (master...2004-benchNoDebugLog) https://github.com/bitcoin/bitcoin/pull/18759
< sipa>
the code is also outdated, actually
< jeremyrubin>
In the python one
< sipa>
all of them
< jeremyrubin>
Oh where is the latest stuff?
< sipa>
the site is up to date with the latest spec, i have a PR to my c++ repo that implements those changes, but the rust code hasn't been updated for them
< sipa>
i think the python code is based on an even older version
< sipa>
note that for things like generic signing this does not matter
< jeremyrubin>
Do you have what the diffs of the specs are?
< jeremyrubin>
What sort of changes -- if it's just improvements for creating better scripts that's OK
< sipa>
jeremyrubin: i mean, you could have the ctv hash as an opaque blob in a descriptor of course, and update them for every step
< jeremyrubin>
Yeah that makes sense... maybe I should... do something about that
< sipa>
which would work, but it wouldn't be very interesting
< Kiminuo>
too bad Andytoshi is so busy, I would gladly finish that
< jeremyrubin>
Anyways I don't need to work on it immediately, my stuff works fine as is. But I'd rather put the effort in to an existing tool than polishing out Yet Another Bitcoin Script TOol
< sipa>
in a similar way that you can have descriptors with raw pubkeys, but things work much more nicely if you can just dump xpubs etc in them
< ariard>
MarcoFalke: reviewing again 18038 rn
< andytoshi>
Kiminuo: heh oops i forgot to review this