WIP - Psbt scrubbing#9
Conversation
nothingmuch
left a comment
nothingmuch
left a comment
There was a problem hiding this comment.
some high level suggestions:
-
define psbt sensitivity (see "class" comment below) mainly for clarity of reference within the doc
- sensitive
- public? insensitive? ;-) ... non-private is the best i can come up with but it's not great =/
-
introduce a notion of a trust domain (i don't love this term fwiw)
- generalizes untrusted vs. trusted roles
- it's a collection of entities/parties that have the same access rights, and wherein the combiner role and all other roles assigned to these entities can be used and the results shared within the domain
- where the rule is that (sensitive) psbt data may not cross the boundary and leave a trust domain,... except:
-
introduce additional "scrubber" role which copies over non-private information into a new psbt that is then allowed to cross the domain boundaries. that way there's a clear and completely defined procedure for scrubbing that can be easily implemented, and any additional fields added on a per app/protocol basis can be specified as extending this document's scrubbing procedure to include additional fields
| Wallet fingerinting: sharing application specific fields that never end up on chain allows your counterparty to | ||
| infer what client you are using (proprietary, unknown fields, taptree, etc...) | ||
|
|
||
| ## Roles |
There was a problem hiding this comment.
"roles" is perhaps a bit overloaded in the other psbt bips it's a set of actions that can be taken at a particular phase, whereas here it's a way of labeling...
i think "privacy domain" or "trust domain" might be the most abstract, and the generality suggests that multiple disjoint trusted domains might coexist
|
|
||
| - Untrusted: This is a peer we interact with to complete a transaction but only share what is neccecary to complete a transaction. | ||
|
|
||
| If a PSBT is being transfered from a trusting party to another trusted party, fields may not change. Otherwise, privacy sensative fields (listed below) must be removed. |
There was a problem hiding this comment.
what does "fields may not change" mean? doesn't this conflict with expected use of updater role?
| ### Input fields | ||
| ---- | ||
|
|
||
| BIP 370 permits treating the creator-to-constructor hop as trusted. Creator and constructor roles move only public PSBT records, so that hop does not leak signing metadata and you strip nothing for privacy there. |
There was a problem hiding this comment.
is "hop" the transition between creator and constructor or their composition? also a bit confusing to say that bip 370 permits it, maybe something like "because bip 370 only allows the creator and constructor roles to manipulate public PSBT records, there are no additional requirements for these roles"
|
|
||
| BIP 370 permits treating the creator-to-constructor hop as trusted. Creator and constructor roles move only public PSBT records, so that hop does not leak signing metadata and you strip nothing for privacy there. | ||
|
|
||
| Constructor-to-updater traffic stays in the same class: inputs, outputs, nSequence, nLockTime, and other public transaction structure only. Strip nothing on that hop for privacy reasons alone. |
There was a problem hiding this comment.
"class" - let's define this
- public information - that doesn't mean that leaking the psbt, particularly if it never gets fully signed, is not a privacy liability, only that these values will eventually be revealed and linked to the transaction when it is broadcast
- sensitive information - everything else
so the class can be "sensitive", but then saying the psbt is "public" because it only contains value that are public information as defined above perhaps sends the wrong connotation
|
|
||
| BIP 370 permits treating the creator-to-constructor hop as trusted. Creator and constructor roles move only public PSBT records, so that hop does not leak signing metadata and you strip nothing for privacy there. | ||
|
|
||
| Constructor-to-updater traffic stays in the same class: inputs, outputs, nSequence, nLockTime, and other public transaction structure only. Strip nothing on that hop for privacy reasons alone. |
There was a problem hiding this comment.
what does "privacy reasons alone" mean? there are other possible reasons to strip other fields?
|
|
||
| Updater-to-signer policy depends on how signers trust each other. The updater reads and writes signing fields. When each signer must validate other signers' signing material, those signers accept mutual trust and the updater may issue one merged PSBT to every signer. When signers do not mutually trust each other, the updater must attach signing fields only for the signer who receives that PSBT copy. | ||
|
|
||
| The combiner merges partial witness data. Partial-witness soundness checks do not require signing fields. Signers retain signing fields when the combiner is trusted; otherwise signers strip them before handoff. |
There was a problem hiding this comment.
BIP 174 describes the combiner as a part of the updater or signer roles, i think it would be clearer here to treat this as just the signer or updater combining rather than using an auxiliary combiner role that is its own separate entity
| ### Proprietary + Unknown Fields | ||
|
|
||
| Global, input or output proprietary fields can be shared but it is left to the judgment of the application. | ||
| By defintions, these are custom fields and their definition cannot be specified. |
There was a problem hiding this comment.
by default should probably be treated as sensitive, apps should specify exceptions explicitly
|
|
||
| The updater attaches the signing-related fields a given signer needs for the inputs and outputs that signer must authorize and validate. | ||
|
|
||
| When several signers participate, policy depends on how those signers trust each other. If every signer must inspect or verify other signers' signing material, those signers accept mutual trust and the updater may issue one merged PSBT to all of them. If signers do not mutually trust each other for privacy, the updater must build a separate PSBT per signer and attach only that signer's required signing fields on each copy. |
There was a problem hiding this comment.
seems more plausible that they would have their own associated updaters in this scenario?
|
|
||
| #### Finalizer and extractor | ||
|
|
||
| The finalizer consumes partial witness fields and writes finalization data the extractor turns into a broadcast-ready transaction. Finalization content mirrors what will appear on chain, so you may hand it to mutually distrusting parties at the same trust level you assign to the final transaction itself. |
There was a problem hiding this comment.
| The finalizer consumes partial witness fields and writes finalization data the extractor turns into a broadcast-ready transaction. Finalization content mirrors what will appear on chain, so you may hand it to mutually distrusting parties at the same trust level you assign to the final transaction itself. | |
| The finalizer consumes partial witness fields and writes finalization data the extractor turns into a broadcast-ready transaction. Extracted content is exactly what will appear on chain, so you may hand it to mutually distrusting parties at the same trust level you assign to the final transaction itself. |
iirc the finalizer may leave some sensitive data, so i think this needs to be hedged (suggestion) and elaborated (not in suggestion, because i'm not sure how without a whole paragraph)
|
The order in which fields in a PSBT are serialized, and in general any kind of non-canonical encoding potentially fingerprints the PSBT implementation (although i can't think of anything other than kvp order... extraneous trailing 0 bytes maybe? bip 174 specifies that compactsize encodings must be minimal) |
2 participants
Initially this document was started in #7. Still a collection of notes and many TODOs to resolve. But its starting to take shape