--- Log opened Sat Jan 22 00:00:37 2022
09:59 < darosior> Has anyone put thoughts into "internal" (from a participant in the script) malleability? I think it's a very interesting problem in the context of offchain contracts as participants distrust each other and being able to malleate the witness may have an impact on security (through the enforce-ability of the contract). 
10:33 < jeremyrubin> darosior is this an example of what you mean: OP_IF <pka> checksig OP_ELSE <pka2> checksig OP_ENDIF <pkb> checksig
10:52 < darosior> jeremyrubin: it is an instance of malleability as defined in https://bitcoin.sipa.be/miniscript/ (since A has access to 2 satisfactions), but i'm not sure how A would inflate the witness to decrease the feerate here?
10:53 < darosior> (as defined by https://bitcoin.sipa.be/miniscript/ but explicitly ruled out since A is a participant in the script)
10:54 <@sipa> Not sure what you mean... participants with private keys can always malleate by signing again, for example.
10:58 < darosior> I mean it in the context of this paragraph from the site:
10:58 < darosior> > The attacker does not have access to any of the private keys of public keys that participate in the Script. Participants with private keys inherently have the ability to produce different satisfactions by creating multiple signatures. While it is also interesting to study the impact rogue participants can have, we treat it as a distinct problem.
10:59 < darosior> Of course participants with keys can malleate, but does it allow them to decrease the feerate of the transaction?
11:00 <@sipa> In the case of ECDSA they could start by grinding signatures to make them a few bytes smaller, and then later sign without such grinding.
11:01 <@sipa> In the case of BIP340, they could start by signing with SIGHASH_DEFAULT and then later pick another sighash flag which is one byte larger.
11:01 <@sipa> Those only have a tiny impact of course.
11:03 < darosior> Something that came to me also while thinking about `rawnode(HEX)` for Taproot: for onchain you might sign if you agree with the transaction, no matter if there was other paths in the script you don't know about. For offchain you really want to know about all branches, and ideally have guarantees about the malleability of the satisfactions
11:03 < darosior> available to your distrusted counterparty/ies.
11:05 < darosior> (in worst cases, of course there are offchain cases where you don't but it's generally less interesting)
13:23 < jeremyrubin> darosior: i dont think MS can model this since we don't know who knows which keys
13:23 < jeremyrubin> e.g., OR(mulit(A, A2), pk(A))
13:23 < jeremyrubin> * pk(A3)
13:24 < jeremyrubin> to MS these are distinct keys, but party A could produce a number of satisfactions
13:24 < jeremyrubin> i dont think MS can handle this generically
--- Log closed Sun Jan 23 00:00:38 2022