--- Day changed Sat Aug 15 2020
03:46 -!- jeremyrubin [~jr@2601:645:c200:f539:f85e:a648:fc27:2225] has quit [Ping timeout: 244 seconds]     
04:53 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript     
04:53 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
04:53 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript     
07:17 < sgeisler> sanket1729, andytoshi: did you ever actually test the psbt finalizer in rust-miniscript? The unimplemented extract function below makes me a bit wary. 
08:54 -!- afilini [~user@gateway/tor-sasl/afilini] has joined ##miniscript     
10:46 -!- jeremyrubin [~jr@2601:645:c200:f539:1d25:1a55:e644:5c4d] has joined ##miniscript     
10:46 < andytoshi> heh no, i did not
10:46 < andytoshi> that module has always been basically a stub
10:47 < andytoshi> we were briefly planning to use the finalizer in liquid but then we would up writing our own finalization code because our usecase didn't quite match PSBT
10:48 < andytoshi> we instead started using "transaction proposals" which are like precursors to unsigned txes ... they are lists of inputs, pegouts and change, with specific rules for deriving a transaction from them
10:49 < jeremyrubin> is there a spec for that somewhere?
10:53 < andytoshi> no     
10:53 < andytoshi> it's really specific to the liquid functionaries
11:12 < sgeisler> Ok, so from what I see to be able to finalize PSBTs spending inputs from arbitrary descriptors the finalizer needs to know the descriptor as it can't be reconstructed from the script (other than plain miniscript, for which the current finalizer seems to be made)
11:14 < sgeisler> andytoshi: I feel like I remember someone talking about including the descriptor in the input, is that right? 
11:16 < sgeisler> My personal quick fix would otherwise be to give the finalizer a `Descriptor<DescriptorKey>` so it can use the derivation path in the PSBT to derive the right descriptor. This would limit this particular implementation to one descriptor for inputs, but afaik that's the use case in 90% of the cases (1 wallet=1 descriptor).
11:18 < sgeisler> achow101: is the finalizer the right place to generate the witness/script sig btw? It felt like it, even though core seems to do that automatically when signing a tx.
11:20 < achow101> sgeisler: yes. Core just does some weird things to avoid changing too many things from legacy behavior
11:21 < andytoshi> sgeisler: you should be able to construct the descriptor from a PSBT
11:21 < andytoshi> what data is missing?
11:22 < andytoshi> you have the witness/redeem script
11:22 < andytoshi> attached to inputs
11:23 < sgeisler> Ok, I might be doing it wrong. At which point should these be attached to the input?
11:23 < andytoshi> they're the job of the Updater role
11:23 < andytoshi> i don't think there's really a standard workflow which specifies "when"
11:23 < andytoshi> but, before finalization :P
11:24 < andytoshi> after creation
11:24 < sgeisler> ok, till now I perceived the updater as a public-data thing
11:24 < sgeisler> so it doesn't have access to e.g. the redeem script for a p2sh tx
11:24 < andytoshi> no, the updater provides data that's needed to facilitate the other roles
11:25 < andytoshi> typically a wallet will act as updater for its own inputs
11:25 < andytoshi> er rather
11:25 < andytoshi> a PC host will Update a PSBT before giving it to a hw device which can act as Signer
11:26 < andytoshi> for the purpose of our API i think it's fine for the Finalizer to just fail if this data is missing
11:26 < sgeisler> ok, and the redeem script/witness would be partially "empty" at that point? Because the signatures still have to be created?
11:27 < andytoshi> and users can figure out when/how to insert it
11:27 < andytoshi> sgeisler: ??
11:27 < andytoshi> redeem/witness scripts have nothing to do with signatures
11:27 < andytoshi> they're not needed to sign and they don't include signatures
11:31 < sgeisler> ok, I might have gotten a bit confused by the indirection of *2sh
11:32 < andytoshi> oh actually .. let me remember what the scriptCode (which gets signed) actually is
11:32 < andytoshi> i think it might be the witness/redeem script
11:32 < andytoshi> err     
11:32 < andytoshi> pre-segwit it is the scriptPubKey and post-segwit it is the witness script?
11:33 < andytoshi> so i guess for wsh and p2wsh you do actually need the witness script
11:33 < andytoshi> to sign
11:36 < sgeisler> Yeah, I'll try to play around with it a bit more and build a miniscript wallet using the new PSBT traits to test them. That will hopefully highlight any misconceptions I might still have.
11:36 < andytoshi> ah, heh, no, the scriptCode is always the script being executed, from the most-recently-executed CODESEP to the end
11:36 < andytoshi> so it is the redeem script for p2sh, the witness script for p2wsh or wsh, and the scriptpubkey for bare outputs
11:37 < andytoshi> and if CODESEP is used, the signer needs to figure this out, and the finalizer also needs to understand it
11:37 < andytoshi> anyway CODESEP is out of scope for rust-miniscript
11:39 < andytoshi> it's tempting to add codeseparator as an optional feature to miniscript to make signatures be usable only in specific branches
11:39 < andytoshi> but this doesn't work with thresholds
12:13 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]     
12:24 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript     
15:19 < shesek> why does `and(pk(A),thresh(2,sha256(H),sha256(H),sha256(H)))` result in a compile error (with sipa's implementation)? a bug or something that I'm missing?
15:20 < shesek> while `and(pk(A),thresh(2,sha256(H),sha256(H)))` works
15:21 -!- mblackmblack [~matt@178.128.230.221] has joined ##miniscript     
15:22 < sipa> shesek: that's assumed to be malleable
15:22 < sipa> as all three hash preimages may be available to third parties
15:23 < shesek> is that a fair assumption? couldn't there be protocols where it could be assumed to be safe?
15:24 < shesek> a simpler example that fails compilation is `pk(A) && (sha256(H) || sha256(H))`
15:24 < sipa> yes     
15:24 < sipa> at every point at most one choice can be available that has no signature
15:25 < sipa> so (pk(A) && SHA256(H1) || pk(B) && SHA256(H2)) would work
15:25 < sipa> it gets really hard to reason about malleability if you drop these rules
15:26 < sipa> you could just drop the nonmalleability requirements if you know this isn't a problem
15:27 < shesek> can as in by changing the source code, or is there a config option that could be given to the policy compiler for this?
15:27 < sipa> eh, at this point anything you want to do with the C++ code will mean changing the source
15:27 < sipa>     auto res = compilation.Query("Bms"_mstf);
15:27 < sipa> if you drop the m there, it should work
15:28 < sipa> though, do you really have a use case for this?
15:29 < shesek> I don't personally, but I ran into an example in the wild that uses it, that atomic.loans contract I shared on twitter yesterday
15:29 < shesek> one of the folks from there just let me know that both of the examples I posted don't actually compile from policy to miniscript/script (https://twitter.com/shesek/status/1294119081046663168)
15:30 < sipa> i could make it optional on the site
15:31 < sipa> though it would be good if someone was actually working on the codebase and getting it integrated in core etc
15:31  * sipa too many things to do
15:32 < shesek> that would be useful I think. :) how would you word the warning next to it? I should probably have one too
15:32 < shesek> I guess "don't use this unless you really know what you're doing" could work :p
15:33 < sipa> our thinking before was that in general we'd want it for the compiler
15:33 < shesek> though that's the case for everything there really
15:33 < sipa> but in generic signing code you may be ok with signing something that isn't provably nonmalleable
15:33 < sipa> as in the damage is already done and there is no reason not to try getting your money out
15:42 < shesek> malleability could potentially be dealt with by tweaking the pubkeys, similarly to what I suggested for avoiding key reuse. would doing this make sense here? (i.e. `pk(A) && (sha256(H1) || sha256(H2))` -> `(pk(tweak(A, H1)) && sha256(H1)) || (pk(tweak(A, H2)) && sha256(H2))`)
15:44 < sipa> yes, or by using codesep
15:44 < sipa> or post-taproot, splitting them into separate branches
16:24 < shesek> does rust-miniscript behave similarly in this aspect?
20:45 -!- Davterra [~Davterra@89.45.90.48] has quit [Quit: Leaving]     
22:05 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]