--- Log opened Fri Jan 07 00:00:23 2022
04:42 -!- enick_368 [~afilini-m@2001:bc8:1828:245::2] has joined #bitcoin-rust
06:49 -!- trev [~trev@user/trev] has quit [Quit: trev]
08:22 < andytoshi> so it seems like people do want to do a new secp release with a better Parity
08:23 < andytoshi> kixunil makes a good observation that regardless of internal representation we shouldn't have a `from` method that takes a numeric, it should be `try_from`
09:33 -!- dr_orlovsky [~dr-orlovs@31.14.40.18] has quit [Ping timeout: 268 seconds]
10:37 < andytoshi> lol, let's just yank the new libsecp and do a new major rev
10:38 < andytoshi> now that we have tobin's "add a ton of missing derives" PR as well
14:12 < jeremyrubin> re https://github.com/rust-bitcoin/rust-bitcoin/pull/669 maybe something is getting lost in the mix
14:13 < jeremyrubin> my concern is that going from vec<u8> to ECDSASig breaks compatibility with the PSBT spec, as such you can no longer decode all valid PSBTs
14:14 < jeremyrubin> while you could encode whatever info you want for partial_sigs, the spec does say "as it is to appear on the stack" which implies no post-processing
14:14 < jeremyrubin> Because of the need for null dummy, the approach presented does not work.
14:14 < jeremyrubin> Am i missing something that would be easier to clear up via chat?
14:40 < andytoshi> the nulldummy should not appear in the PSBT as a signature
14:41 < andytoshi> what key would it be associated with?
14:42 < jeremyrubin> suppose you had the (non miniscript) <A> checksig IF <B> ELSE <C> ENDIF checksig (plz no comments on if this is a good script or not, wrong layer of concern) i would assume you'd have partial_sigs have A : Nulldummy?
14:43 < andytoshi> ah! i see
14:43 < andytoshi> achow101: have you ever thought about this?
14:43 < jeremyrubin> vec<u8> is fine for this type
14:43 < jeremyrubin> ECDSASig is not
14:43 < andytoshi> suppose you have a CHECKSIG which is embedded in a script such that it needs to fail
14:43 < andytoshi> should you put the empty-vec "signature" into a PSBT?
14:43 < andytoshi> i guess so
14:44 < jeremyrubin> it also helps because it can help you reason about what other sigs you're trying to get
14:44 < andytoshi> yeah this all makes sense
14:44 < jeremyrubin> e.g., if partial_sigs has A:nulldummy you know that you want <C>
14:44 < andytoshi> (i'm not sure if it was me you were arguing with on github, but i did fail to see this)
14:44 < jeremyrubin> if it has A:somesig you want B
14:44 < jeremyrubin> uhh more maxim (idk his IRC?)
14:44 < andytoshi> i think i was confusing nulldummy with the CHECKMULTISIG extra dummy push rule
14:45 < andytoshi> his irc is dr-orlovsky but it looks like he's not here :/
14:46 < jeremyrubin> yeah
14:46 < jeremyrubin> also i had a desire at some point to add to partial_sigs an actual partial sig
14:46 < jeremyrubin> that tells you what sighash flag to sign with
14:47 < jeremyrubin> (because right now you can't pick a sh flag per key)
14:47 < jeremyrubin> but i think that can happen in a separate field 
14:47 < jeremyrubin> but the nulldummy issue certainly seems to me to be blocking
14:47 < jeremyrubin> i'm not sure if miniscript can emit nulldummy for key clauses, but I think it can
14:48 < achow101> my assumption was that finalizers would determine which path to use and put a nulldummy appropriately
14:49 < jeremyrubin> usage aside, the spec currently supports NullDummy in partial_sig and the PR in question would not be able to deserialize those anymore
14:50 < achow101> core would allow it as it does not check the signature is der
14:51 < achow101> but that's really more of a side effect of der sigs being variable length
14:51 < jeremyrubin> i'm indifferent on if the right thing to do is to clean up the partial_sig spec or the rust-bitcoin to match the spec, but i think one or the other is a good idea.
14:51 < achow101> for sigs for tapscripts, it would not be allowed because of the size check
14:52 < achow101> imo it partial_sig should be an actual signature
14:52 < achow101> if you don't want to provide a signature, don't provide the field
14:53 < achow101> that should be implicitly whatever needs to be done to not provide a sig
14:53 < achow101> whether that be nulldummy or something else
14:53 < jeremyrubin> what if you want to provide the nulldummy to aid in inference of which path to sign?
14:55 < jeremyrubin> I'm OK with whatever, just worth having clear documented behaviors for these things.
14:56 < achow101> i'm of the opinion that a signer should sign all paths it can, or none at all
14:56 < achow101> either the signer agrees with the spend, or it does not.
14:56 < jeremyrubin> that's clearly wrong IMO
14:56 < achow101> if it agrees, then it should sign all it can and leave it up to the remaining parties
14:57 < jeremyrubin> imagine TR(n-n, {A B, A D}) 
14:57 < jeremyrubin> A might wish to sign *only* if it is D proposing the txn
14:57 < achow101> it's then up to the finalizer to figure out what paths are valid given the existing signatures
14:57 < jeremyrubin> if B is proposing the txn A is doing might be invalid
14:58 < andytoshi> 22:57 < jeremyrubin> A might wish to sign *only* if it is D proposing the txn
14:58 < jeremyrubin> E.g., imagine A is an escrow and B and D have different balances they can withdraw
14:58 < achow101> if D proposes the transaction, and B agrees with it, then what harm is there for the A B path to be taken?
14:58 < andytoshi> i think the presence/absense of signatures i s really the wrong place to signal something liek that
14:59 < achow101> assuming sighash all, A signing the AB path does not allow for B to take any unexpected action
14:59 < achow101> either B can accept the transaction and make it valid, or they can refuse it and it remains unfinished
14:59 < jeremyrubin> yes it certainly does if you only mean to delegate to D
14:59 < jeremyrubin> let me give another example:
15:00 < jeremyrubin> I have two recovery services, B and D that have different business logic policies and I select D to submit a transaction to *Knowing* they will validatie Important THings.
15:00 < jeremyrubin> But because i also signed B, and B does not validate that, then B signs and submits which is not what A wanted
15:01 < jeremyrubin> I think this can be handled at the descriptor level FWIW as i've commented elsehwere
15:01 < jeremyrubin> but signing all paths is to me clearly not what you want to do for many many use cases
15:02 < jeremyrubin> (another example, tr with `A <H> CTV` and `A <H> CTV` -- you should know *exactly* which one you want to do!)
15:03 < jeremyrubin> maybe that example is more clear, note that CTV can be 'used' today with a signing emulator so that maps onto the B/D signers 
15:03 < jeremyrubin> ofc A is signing a specific txn, which mitigates some of the concern
15:03 < achow101> i see...
15:03 < andytoshi> if you care about what path your signature is used on, i really think you should have distinct keys for those paths
15:04 < andytoshi> this business of looking at the existing transaction, then deciding whether to sign based on that, seems super fragile
15:04 < jeremyrubin> well, the scriptcode is comitted to in the signature
15:04 < jeremyrubin> and there are plenty of reasons to use a single key
15:04 < jeremyrubin> for example, suppose i have a bonded oracle where i use a chain of attestations based on key A
15:04 < jeremyrubin> it might be required that A is reused across branches to guarantee leaking of A to some part can be used across any of them 
15:05 < jeremyrubin> (perhaps straw-man example, but just 'you may want something else going on with key A to require it is exactly A')
15:05 < andytoshi> you can also use codeseparator to separate
15:05 < achow101> regardless, I don't think having nulldummy be in partial_sigs is the correct way to indicate that
15:05 < andytoshi> but what you're trying to do is morally sign something, that you're not actually signing
15:05 < andytoshi> which is dangerous in general
15:05 < jeremyrubin> idk what that means
15:06 < jeremyrubin> all i'm saying is that PSBT signing logic is probably the wrong layer to make the decision of 'sign anything you can'.
15:06 < achow101> I think it makes sense if you are not the one proposing the transaction
15:09 < jeremyrubin> this has scope creeped a lot
15:09 < jeremyrubin> i gtg, but i do think it's worth having a clear decision on ECDSASig vs vec<u8>
15:11 < andytoshi> i think it should be ECDSASig (or something similarly structured) and if the PSBT spec is not clear on that then it should be updated
15:11 < andytoshi> i'm really having trouble conceptualizing this "i indicate that i won't sign, by more than just not signing" usecase
15:13 < jeremyrubin> andytoshi i think it's helpful insofar as if there are e.g. a lot of branches someone might sign it's useful to track if another signer is going to decline
15:14 < andytoshi> yeah, ok, i see, although ofc this isn't a binding signal
15:14 < andytoshi> but i can believe that it'd be useful
15:14 < jeremyrubin> it also can help make certain signing programs based purely on PSBT terminate if there's a loop of "A: ask B first, B: ask A first, ..."
15:14 < andytoshi> but i also think it should be its own field
15:14 < jeremyrubin> andytoshi: i was noodling on being able to sign a wont_sign_this_tx
15:15 < jeremyrubin> i guess at a high level the question is "can a signer locally reason about if they should sign something or is the presence of other signers relevant"
15:16 < achow101> for psbt, i generally approach fields as a "it does exactly what it says on the tin" kind of thing and try to not overload meanings into one field
15:16 < andytoshi> i could believe that the presence of other signers might be relevant for non-crypto protocols like "do i need to access backup keys or call somebody else or halt the protocol" etc
15:16 < achow101> if you are trying to use a field to indicate something other than the obviously stated purpose, just add another field that has an obviously stated purpose for that other thing
15:16 < andytoshi> there is no cryptographically binding way to say "i won't sign X", except with nonce-reuse craziness maybe like in DLCs
15:17 < achow101> at least in the taproot world you can just omit the leaf scripts for the other paths that shouldn't be taken
15:18 < achow101> but that is also non-binding as someone could add them in later
19:49 -!- Guest28 [~Guest28@pw126167163196.32.panda-world.ne.jp] has joined #bitcoin-rust
19:50 -!- Guest28 [~Guest28@pw126167163196.32.panda-world.ne.jp] has quit [Client Quit]
23:12 -!- trev [~trev@user/trev] has joined #bitcoin-rust
23:25 -!- trev [~trev@user/trev] has quit [Remote host closed the connection]
23:27 -!- trev [~trev@user/trev] has joined #bitcoin-rust
23:56 -!- trev_ [~trev@46-138-89-118.dynamic.spd-mgts.ru] has joined #bitcoin-rust
23:56 -!- trev [~trev@user/trev] has quit [Ping timeout: 256 seconds]
--- Log closed Sat Jan 08 00:00:24 2022