Add honest overview - #11
Conversation
|
@arminsabouri seeking concept ACK to supersede this with a proper overview (see #17 which used to be the overview) a lot of the foundational layers for honest, semi-honest and BFT are shared so i want to consolidate that into a single overview doc for all layers |
Concept ACK foundational layers being consolidated to a single document. is #17 that document? |
no, that was initially conceived as an overview, but most of the content is strawmen... it's more a strawman ladder, similar to the "protocol design" doc of privacy pass, and is a supplementary aid to the spec, that justifies the various details the overview needs to be narrower in scope, only focusing on the concrete, layered protocol suite here is a proposed outline, each layer inherits most of the previous layer's functionality and adds additional restrictions:
it should only summarize these topics, not go into detail, referring to the relevant documentation for the details, which will be defined later, including but not limited to:
i.e. a full accounting of the technical means for realizing the goals defined by the cost function |
bc1cindy
left a comment
bc1cindy
left a comment
There was a problem hiding this comment.
concept ACK, well scoped!
| @@ -0,0 +1,178 @@ | |||
| # Overview: Multiparty transaction construction in honest peer threat model | |||
There was a problem hiding this comment.
rescope this as the detail doc for the interactive-honest layer?
|
|
||
| ### `Initiator` and `Responder` | ||
|
|
||
| The `Initiator` signals willingness to batch to their counterparty over an authenticated bidirectional channel that may have been established prior to initiation. This document treats signaling `mppj=1` via BIP21 as one practical bootstrap example, not a normative long-term mechanism. Either the receiver or sender of a payment may be the Initiator. |
There was a problem hiding this comment.
could stay signaling-agnostic, the same abstract/concrete pattern as the broadcast channel from the communication model, with the BIP21/BIP77 material as a non-normative compat section
if the flag stays, what about mp=1? i see no technical reason to inherit the pj name
|
|
||
| Either an `Initiator` or a `Responder` may create the session. The party that does so is the `SessionCreator`. | ||
|
|
||
| In production, we rarely observe multiple concurrent `Initiator` and `Responder` pairings. After `T_intent`, most multiparty payjoin attempts therefore collapse to two-party payjoins. Clients should persist multiparty capability metadata for counterparties learned during interactive sends. Each `Initiator` fans out session requests to `Responder`s with prior payment history. `Responder`s in turn can fan out requests to their previous counterparties. |
There was a problem hiding this comment.
since "we" here no longer includes payjoin, I guess worth attributing this to two-party payjoin production data
| TODO: concurrent session creators ? How to prevent? What to do? | ||
|
|
||
| * Deterministic rule for picking? | ||
| * Participate in both sessions? |
There was a problem hiding this comment.
since fund safety doesn't depend on this, is prevention needed?
what if whoever discovers two overlapping sessions selects one based on the lower session ID?
same input in both just degrades to an accepted liveness failure?
|
|
||
| For this document, `balance` means the running value equation over the accumulated transaction view: | ||
|
|
||
| `balance = sum(inputs) - sum(outputs) - sum(pseudo outputs)` |
There was a problem hiding this comment.
if everyone pays exactly the minimum fee, nobody posts a pseudo output, the balance stays stuck at the total fee, and signing never triggers
maybe pseudo outputs should just declare the full fee contribution, always
that's how #16 defines PSBT_GLOBAL_EXPLICIT_FEE_CONTRIBUTION
makes sense?
|
|
||
| Before signing, each sender must receive explicit confirmation from all of its receivers of the PSBT’s unique ID (defined in the [draft BIP](https://github.com/payjoin/multiparty-protocol-docs/pull/6/)) which commits to the complete output set and verify that every confirmed ID matches the one computed locally. | ||
|
|
||
| In a cyclic payment graph, such as Alice pays Bob, Bob pays Carol, and Carol pays Alice, net-positive receivers can initiate safely and break the dependency cycle. Senders sign only after every receiver has confirmed the PSBT unique ID. Once all net-positive receivers confirm, the protocol can treat all funds as fully accounted for. |
There was a problem hiding this comment.
in a perfectly balanced cycle everyone is net-zero, so net-positive (read as > 0) selects nobody and this deadlocks
the intended meaning is >= 0 and #16 already says non-negative for who can confirm, so maybe just use that term here or be explicit
|
|
||
| Each participant submits the transaction inputs they control and outputs they wish to create. Inputs and outputs must be posted as independent messages. Participants should send all their inputs before the outputs. | ||
|
|
||
| To signal their intent to back out of the session, a participant can deliberately post outputs that exceed their input contribution, causing the transaction balance to overflow. This action makes the balance equation unsatisfiable and prompts all other participants to refuse to sign. |
There was a problem hiding this comment.
the abort mechanism was a MAX_MONEY pseudo output (global field, not a txout), a modest overflow as written here is indistinguishable from an output still waiting for inputs
|
|
||
| When the `balance` reaches zero and participants receive receiver confirmations, every participant can independently verify their outputs are present and proceed to witness provision. | ||
|
|
||
| This honest variant uses optimistic signing and does not require an explicit "Ready-to-Sign" (RTS) declaration on the success path. With pseudo-output accounting, readiness is implicit once participants converge on the same message set and each participant has contributed at least one input before final output/pseudo-output closure. |
There was a problem hiding this comment.
I think this diverges from past comments
"converge on the same message set" isn't observable and "closure" is undefined without RTS
|
|
||
| Inputs and outputs may arrive in arbitrary order. Define ordering semantics a priori. | ||
|
|
||
| All messages are raw binary encoded PSBT fragments. |
There was a problem hiding this comment.
#16 defines fields for inputs/outputs, removal, sort keys and fee contributions, but the unique-ID confirmation is only described in prose (no field), and the SP scan key / tweak shares aren't specified anywhere
are these meant to follow the same grow-only-set field pattern?
|
|
||
| ## Silent Payments | ||
|
|
||
| To support Silent Payments, the recipient broadcasts its [BIP 352 scan public key](https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) as an independent message instead of an output registration. Participants must share their ECDH tweak share once the silent payments output is known. Each participant derives the silent payment output from the shared transaction inputs and recipient scan public key. When the input set changes (new input and tweak), all participants recompute the Silent Payment output before signing. |
There was a problem hiding this comment.
a late input already invalidates all sigs under SIGHASH_ALL, but with SP it additionally changes the output itself
everyone must re-derive before re-signing, and finalization now depends on every input's tweak share being present, so one missing share blocks the whole session
worth noting SP couples convergence to the input set?
4 participants
Migrated from payjoin/multiparty-protocol-docs#4