--- 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 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) checksig IF ELSE 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 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 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 CTV` and `A 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 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