Add scrubber bip - #12
Conversation
|
Maybe put this in a "BIPs" folder? Since we also have concurrent psbt bip that would be good put in same folder. |
i suggest |
| ## Fields | ||
|
|
||
| We categorize PSBT fields from the [BIP 174 type registry](https://github.com/bitcoin/bips/blob/master/bip-0174/type-registry.mediawiki) by privacy sensitivity. Each table lists the registry name, key type, minimum PSBT version, and the BIP that introduces the field. |
There was a problem hiding this comment.
this doesn't address ordering, but i think it probably should
given that bip 174 already requires canonical compact int encoding i believe that apart from the ordering, there are no degrees of freedom in the psbt format itself that would result in serializer fingerprints
within each map, if all fields are sorted by type, and then keydata (already the case for psbt_v2 library's output)
if the maps are also sorted, then the output should become canonical
bc1cindy
left a comment
bc1cindy
left a comment
There was a problem hiding this comment.
concecpt ACK, great work!
| /// Tapscript signatures must be treated as sensitive if they may not end up on-chain; i.e., the PSBT can be finalized in more than one way. | ||
| /// Contrived example: you have both a key-path spend signature and a tapscript signature. Some other party decides which to broadcast. That party learns your tap tree structure. |
There was a problem hiding this comment.
if the spend-path lands, this note is moot
There was a problem hiding this comment.
This is a comment. So wouldnt live in the final document
| // Tweak the input such that it can spend the output. | ||
| // If you reveal your tweak, an untrusting participant can link your input to a silent payment output and verify that the output is a silent payment. | ||
|
|
||
| // TODO: are these sensitive? Yes, partly because they label an output as a silent payment when untrusting parties would not otherwise know. | ||
| // Created when the input set is not unilateral. | ||
| // Created and shared when all inputs are owned by the same owner. | ||
| // This necessarily implies a common input owner. | ||
| // TODO: maybe these are sensitive because of the common-input-ownership heuristic, but the per-input ones are not? |
There was a problem hiding this comment.
suggestion:
Silent payment fields are sensitive because they reveal that an output is a silent payment, which on-chain is meant to be indistinguishable from a plain P2TR key-path spend. Revealing an input's tweak lets an untrusted party link that input to the silent payment output and confirm it is a silent payment. This applies equally to the global and per-input fields, so all are stripped. The global ECDH share is the aggregate of per-input shares and does not by itself imply common input ownership.
There was a problem hiding this comment.
yes.
silent payments outputs based on a payment code can't be constructed in the multiparty setting without cooperation from the other input owners. that can be done in a privacy preserving way, but involves additional round trips, zk proofs etc, and has not been specified yet or proven secure.
silent payments output derivation with knowledge of the private scanning key, on the other hand, are doable without cooperation and reccomended for self-spend outputs from coinjoin because that avoids address reuse statelessly and with no address gap issues (but with the requirement to re-download all coinjoins on recovery from seed).
since only the latter mode will be supported at first, it's best to not leak anything to do with silent payments, and explicitly allow it when/if blinded DH based SP derivation is specified in an extension to this spec.
5 participants
No description provided.