From e4ff9fc3a99fa8797b22cb344222e626a1fc21b7 Mon Sep 17 00:00:00 2001 From: Armin Sabouri Date: Thu, 12 Feb 2026 15:24:55 -0500 Subject: [PATCH 1/2] Add semi-honest overview --- semi-honest.md | 191 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 semi-honest.md diff --git a/semi-honest.md b/semi-honest.md new file mode 100644 index 0000000..eba68bc --- /dev/null +++ b/semi-honest.md @@ -0,0 +1,191 @@ +# Overview: Semi-honest multiparty PayJoin + +The following is a concrete description of the semi-honest multiparty PayJoin protocol. To understand why certain choices design were made, it is recommended to read the [overview document](./00_overview.md) first. + +// TODO: supporting silent payments +// TODO: interaction / sequence diagram where we make a point of who is the initiator, responder, where they are both. + +// TODO: Two phases ?: you cannot add output until every input owner indicated no more OR we just say liveness is weak. +Since this is semi honest the only thing we need tolerate is crashes: someone has a delay and adds inputs at the last second + +## Motivation + +Two-party Payjoin preserves privacy of input/output ownership against third-party observers, but it does not preserve privacy from the view of the counterparty itself. In a two-party protocol, each participant can trivially attribute all unknown inputs and outputs to the other party. This reveals cluster information and requires counterparty trust. + +With n > 2, this privileged view is reduced. Payments and change outputs become ambiguous within the participant set. As a result, participants do not need to trust any specific counterparty with their clustering information. Increasing the number of parties therefore reduces counterparty trust and weakens clustering inferences. + +## Roles + +### Initiator and Responder + +The Initiator signals willingness to batch to their counterparty over a bidirectional channel. This signal is conveyed by including the mppj=1 parameter in the BIP21 URI. Either the BIP77 sender or receiver may be the Initiator. Parameters for their bi-directional channel may be encoded in the BIP21 (same as BIP77). + +The Responder is the counterparty who receives this signal. A Responder that does not support multiparty PayJoin will ignore the mppj=1 parameter and proceed with standard BIP77. A Responder that supports it waits for a session to be created. + +Two timeouts govern the phase of the whole protocol: + +* `T_intent`: the duration both parties are willing to wait for a session to be created after the intent to batch is signaled. If no session is created within T_intent, both parties MUST fall back to standard BIP77 over their existing bidirectional channel. +* `T_session`: the duration of the multiparty session itself, after which input and output registration closes and the protocol advances to signing. + +`T_session` is defined by the `SessionCreator` while `T_intent` is defined by the `Initiator`. + +// TODO: how do we indicate to sender/recv that we should join a mppj? out of band? New message? mailbox with more payment instructions? + +### SessionCreator + +Either the `Initiator` or the `Responder` may create the session. The party that does so is the `SessionCreator`. +The `SessionCreator` is responsible to creating session parameters (defined below), bootstrapping the transport mechanism and disseminating session information to the rest of the peers to the best of their capabilities. `SessionCreator` holds no special authority once the session is live. They simply become a participant. + +### Participant + +Once a party joins a session (defined below) they become a `Participant`. All participants share the same obligations as outlined below. + +### Diagrams + +Single receiver, two senders. Receiver is `Initiator` for both senders and becomes the `SessionCreator`. + +```mermaid +sequenceDiagram + participant R as Receiver (Initiator) + participant S1 as Sender 1 (Responder) + participant S2 as Sender 2 (Responder) + + Note over R,S1: T1 + R->>S1: BIP21 URI (mppj=1) + + Note over R,S2: T2 + R->>S2: BIP21 URI (mppj=1) + + Note over S1,S2: T3 - Receiver becomes SessionCreator + R->>S1: session invitation (s, session params) + R->>S2: session invitation (s, session params) +``` + +Sender 1 is the `Initiator` to the receiver who is an `Initiator` to sender 2. The receiver at time 3 becomes the `SessionCreator` + +```mermaid +sequenceDiagram + participant S1 as Sender 1 (Initiator) + participant R as Receiver (Responder / Initiator / SessionCreator) + participant S2 as Sender 2 (Responder) + + Note over S1,R: T1 + S1->>R: BIP21 URI (mppj=1) + + Note over R,S2: T2 + R->>S2: BIP21 URI (mppj=1) + + Note over S1,S2: T3 - Receiver becomes SessionCreator + R->>S1: session invitation (s, session params) + R->>S2: session invitation (s, session params) +``` + +## Threat model + +This protocol operates in a semi-honest (honest-but-curious) model. All participants are assumed to economically proximate and thus follow the protocol as specified. They are not expected to deviate from the rules or misbehave in any form. However, they may attempt to learn as much as possible from the messages they observe. + +Concretely, if any party learns the full plaintext transcript of messages, they should not be able to determine which inputs or outputs belong to which of the other participants. + +The protocol does not assume Byzantine robustness, and it does not attempt to detect or punish misbehavior. If a participant fails to follow through, the protocol may fail, but safety is not compromised - i.e participants will only provide witness if their expected outputs are included in the final transaction. + +Its possible for some participants to join late. If there are N-1 RTS messages and a participant then registers then inputs and outputs this trivially creates a input-output link. +Possible mitigation include ignoring this laggard when the effective balance condition and N RTS's have been collected. + +## PSBT CRDT + +### Session Parameters + +The SessionCreator fixes the following parameters before the session opens. All participants MUST verify that the final transaction conforms to these parameters before signing. + +* **Global transaction fields**: `nLocktime`, `nVersion` +* **Feerate**: each participant contributes fees proportional to the weight of their inputs and outputs +* **Input constraints**: `nSequence`, script type, segwit only +* **Timeouts**: `T_session` (see Roles) + +### Join Semantics + +Participants learn transaction fragments in arbitrary order and accumulate them as they arrive. In the semi-honest setting there are no conflicting writes: global fields are fixed by the session parameters and each participant controls disjoint inputs and outputs. Any two valid fragments can therefore be merged by union. + +If the accumulated transaction does not balance, or any fragment violates the session parameters, a participant MUST refuse to sign and abandon the session. + +// TODO: sorting semantics under transport option B +// TODO: refer to nothingmuch's document + +## Communication model + +### BIP77 Directory as anonymous broadcast channel + +Communication is mediated by a PayJoin directory accessed via OHTTP, following the same metadata privacy model as BIP77. For multiparty use, the directory mailbox supports append semantics. Multiple participants write to the same mailbox, and peers poll and retrieve all appended messages. The mailbox functions as an anonymous broadcast log of encrypted payloads. + +#### Shared session secret + +A session is defined by a single ephemeral shared secret s. Any participant who learns s can join the session. Knowledge of this secret is the only admission control mechanism. +Participants derive mailbox identifiers and initialize their HPKE context with s. The shared secret is distributed via the existing bidirectional channel. Parties who learn s can both read and write to the mailbox. All payloads are encrypted using HPKE, so the directory only handles opaque ciphertext blobs and cannot link messages to participants. + +### [p2p gossip via Iroh Gossip](https://docs.iroh.computer/connecting/gossip) + +Iroh supports message dissemination via gossip. Peers subscribe to the a topic id and connect to some subset of endpoints. +Peers will redundantly relay messages to peers that are not interested in a particular topic. The topic id can be a ephemeral secret embedded in the bip21 along side some bootstrapping endpoints. + +Iroh does not provide metadata privacy out the box. TBD when and why this can be problematic. + +Integrity and authenticity is provided out the box via TLS. This may be a blocker for TLS-less settings (bitcoin core). Perhaps HPKE (bip77) should be supported since iroh endpoints are just EC points. Some engineering work may be required to support secp256k1 if that is a blocker. + +// TODO: how to do discovery of other peers? +// TODO: yolo RAFT leader based agreement / lattice agreement. Trusted leader = "trusted with liveness". +// TODO; peers that are offline and missed input / output registration will leak them selves. +// TODO: peers need reconcile messages that they missed + +## Protocol phases + +Input and output registration can be sent in any order. Ordering and sorting semantics must be defined a priori. +One possible definition is to use the hash of the protocol transcript as a salt to sort the inputs and outputs. + +All messages are base64 encoded as PSBT fragments. + +### Message Timing + +To prevent timing correlation between a participant's messages, each message MUST be assigned a randomized delay before posting. + +If the total number of messages is known in advance, sample n uniform random times within the session window and post each message at its assigned time. If the count is not yet known, sample delays from an exponential distribution instead. + +Message publication times are assigned in two phases: + +1. Input registration, output registration, and RTS declarations are assigned publication times at the start of the session. +2. Witness provision messages MUST NOT be assigned publication times until registration closes. + +// TODO: coinselection strategy? do peers run their own coinselection based on their own target outputs? What if a recv doesnt have target outputs? + +### Input Registration + +Each participant submits the transaction inputs they control. Inputs must be posted as independent messages. +Inputs are not attributed to participants. Global observers should not be able to determine which inputs originate from the same party. + +### Psuedo Outputs + +A pseudo output is an anonymous declaration of fee contribution above the session-mandated minimum. It participates in the balance equation like a real output but does not appear in the final transaction. Participants MUST post a pseudo output only when their intended fee contribution exceeds what the session parameters require. + +When the global sum of inputs minus outputs minus pseudo outputs reaches zero, every participant can independently verify the transaction is balanced and proceed declare RTS. + +### Output Registration + +Participants post their desired outputs as independent messages. No explicit linkage between a participant's inputs and outputs is revealed. Output and pseudo output messages MUST carry a unique identifier to prevent double accounting. + +A participant who wishes to back out of the session posts an output that causes the transaction balance to overflow. That is, their declared outputs exceed their input contribution. This makes the balance equation unsatisfiable and MUST cause all other participants to refuse to sign. + +### Ready-to-sign (RTS) declarations + +For each input they control, participants post a ready-to-sign declaration. This signals that they accept the current transaction template and are prepared to sign it. +Only once all inputs have corresponding ready signals does the protocol advance. This ensures that all participants have finished contributing transaction fragments. + +When the global sum of inputs minus outputs minus pseudo outputs fee declarations hits zero, every participant can independently verify the transaction is balanced and sign. + +### Witness provision + +Participants provide witnesses for the inputs they control. Once all witnesses are available, any participant can assemble the fully signed transaction and broadcast it to the Bitcoin network. + +## Risks and limitations + +### Liveness fragility + +The protocol is fragile with respect to liveness. If even a single participant fails to provide witnesses in the final phase, the transaction cannot be completed. This is the worst-case outcome and is inherent to interactive multiparty transactions requiring unanimous signatures. From be495e703a171e8581e2ea12bcff4c5ed979636e Mon Sep 17 00:00:00 2001 From: Armin Sabouri Date: Thu, 23 Apr 2026 14:58:35 -0400 Subject: [PATCH 2/2] Split semi-honest overview into two Move everything that is a commonality into honest overview. --- honest.md | 169 +++++++++++++++++++++++++++++++++++++++++++++++++ semi-honest.md | 165 ++++++----------------------------------------- 2 files changed, 188 insertions(+), 146 deletions(-) create mode 100644 honest.md diff --git a/honest.md b/honest.md new file mode 100644 index 0000000..38c8660 --- /dev/null +++ b/honest.md @@ -0,0 +1,169 @@ +# Overview: Multiparty transaction construction in honest peer threat model + +The following is a concrete description of the honest multiparty PayJoin protocol. To understand why certain choices design were made, it is recommended to read the [overview document](./00_overview.md) first. + +## Motivation + +This protocol is best understood as a collaborative transaction construction protocol for mutually trusting parties. Its purpose is to let participants jointly build a transaction with potentially better privacy properties and cost savings than a unilateral construction. + +## Trust Model + +* Liveness: peers are expected to follow the protocol flow and remain reachable long enough for protocol messages to eventually disseminate and for participants to converge. Some deployments may use timeout-based progress under partial synchrony, while others may rely on eventual delivery without strict timing guarantees. + +* Privacy: peers are trusted not to leak or retain their sensitive observations learned during the protocol, including timing, message ordering, and transport metadata (for example IP-layer linkability data) beyond what is needed to complete the session. + +Importantly, fund safety does not depend on peer honesty. Each participant signs only a transaction they locally validate and accept under `SIGHASH_ALL`. Therefore, malformed or economically unacceptable constructions are treated as liveness failures, not fund-loss safety failures. + +## Roles + +### Initiator and Responder + +The Initiator signals willingness to batch to their counterparty over a bidirectional channel. In this document, signaling `mppj=1` via BIP21 is treated as one practical bootstrap example, not a normative long-term mechanism. Either BIP-77 receiver or sender may be the Initiator. + +For multiparty deployments, the preferred direction is richer payment instructions that can support post-quantum HPKE choices, sender-initiated interactions, and long-lived/reusable authenticated channels. +// TODO: elaborate more on payment instructions + +The Responder is the counterparty who receives this signal. If a peer does not support the chosen multiparty signaling mechanism, it falls back to standard BIP77 behavior. If it does support the mechanism, it waits for a session to be created. + +Two timeouts govern the phase of the whole protocol: + +* `T_intent`: the absolute expiration time After which if no session is created within `T_intent`, both parties must fall back to standard BIP77 over their existing bidirectional channel. Since the intent can be delivered over a async. channel this is an absolute expiration not a relative duration. +* `T_session`: the duration of the multiparty session itself, after which the session is considered expired. + +`T_session` is defined by the `SessionCreator` while `T_intent` is defined by the `Initiator`. + +// TODO: specify a concrete signaling/payment-instructions format once requirements for PQ HPKE, sender initiation, and reusable authenticated channels are finalized + +### SessionCreator + +Either an `Initiator` or a `Responder` may create the session. The party that does so is the `SessionCreator`. +The `SessionCreator` is responsible to creating session parameters (defined below), bootstrapping the transport mechanism and disseminating session information to the rest of the peers to the best of their capabilities. `SessionCreator` holds no special authority once the session is live. They simply become a participant. + +### Participant + +Once a party joins a session they become a `Participant`. All participants share the same obligations as outlined below in the phases section. + +### Diagrams + +Single receiver, two senders. Receiver is `Initiator` for both senders and becomes the `SessionCreator`. + +```mermaid +sequenceDiagram + participant R as Receiver (Initiator) + participant S1 as Sender 1 (Responder) + participant S2 as Sender 2 (Responder) + + R->>S1: BIP21 URI (mppj=1) + R->>S2: BIP21 URI (mppj=1) + + R->>S1: session invitation (s, session params) + R->>S2: session invitation (s, session params) +``` + +Sender 1 is the `Initiator` to the receiver who is an `Initiator` to sender 2. The receiver at time 3 becomes the `SessionCreator`. + +```mermaid +sequenceDiagram + participant S1 as Sender 1 (Initiator) + participant R as Receiver (Responder / Initiator / SessionCreator) + participant S2 as Sender 2 (Responder) + + S1->>R: BIP21 URI (mppj=1) + R->>S2: BIP21 URI (mppj=1) + + R->>S1: session invitation (s, session params) + R->>S2: session invitation (s, session params) +``` + +## Session Parameters + +The `SessionCreator` fixes the following parameters before the session opens. All participants must verify that the final transaction conforms to the relevant parameters before signing. Size limit cannot be enforced. The `SessionCreator` only knows their immediate neighborhood of peers but those peers may invite others. + +* **Global transaction fields**: `nVersion`, `locktype` (time or height based) +* **Feerate**: each participant contributes fees proportional to the weight of their inputs and outputs +* **Input constraints**: `nSequence` +* **Timeout**: `T_session` + +## PSBT CRDT + +### Join Semantics + +Participants learn transaction fragments in arbitrary order and accumulate them as they arrive. In the honest setting there are no conflicting writes: global fields are fixed by the session parameters and each participant controls disjoint inputs and outputs. Any two valid fragments can therefore be always merged. + +For this document, `balance` means the running value equation over the accumulated transaction view: + +`balance = sum(inputs) - sum(outputs) - sum(pseudo outputs)` + +where pseudo outputs default to zero until any are declared. + +If the accumulated transaction does not balance, or any fragment violates the session parameters, a participant can refuse to sign and abandon the session. + +// TODO: refer to nothingmuch's document + +## Communication model + +The protocol assumes an abstract session-scoped broadcast channel for disseminating PSBT fragments. + +Required channel properties: + +All participants can publish protocol messages to the same session channel, with messages authenticated and kept confidential within the participant set. Each participant is able to read and merge messages from all others into their own local transaction view. While message delivery may be delayed or received out of order, the protocol ensures eventual dissemination and reconciliation of all messages within the session window `T_session` if all parties behave honestly. + +In this honest setting, a separate agreement protocol is not required for the success path. Gossip dissemination plus deterministic transaction construction is sufficient: if participants receive the same valid fragments, they converge to the same unsigned transaction. Any temporary view differences are primarily a liveness concern (delay or retry), not a fund-safety concern. + +Candidate instantiations include [Iroh documents](https://docs.iroh.computer/protocols/documents), [MDK](https://github.com/marmot-protocol/mdk), or a shared append-only mailbox like a [BIP-77 Directory](https://github.com/bitcoin/bips/blob/master/bip-0077.md). These are examples, not normative requirements. + +This setting does not require transport-layer metadata privacy as a protocol requirement. Participants are already mutually trusted with privacy in the honest model, including trust not to retain or misuse linkability information learned during the session. As a result, unlike the [semi-honest](./semi-honest.md) setting, the protocol does not depend on anonymous transport primitives to maintain the intended privacy properties within the participant set. + +Note that encryption alone does not prevent traffic analysis, so an external passive adversary, and in particular a global passive adversary, may be able to infer the use of this protocol, potentially correlate its use to a transaction broadcast and even attribute particular inputs and outputs to the specific participants based on metadata such as message sizes. + +### Message Delivery + +The channel must provide reliable delivery at the session level: every valid protocol message must eventually be delivered to every participant within `T_session`, so all honest participants converge on the same message set before signing. + +Different instantiations can satisfy this in different ways. Unordered gossip-style channels may use set reconciliation. The protocol specifies only the delivery/convergence property, not the mechanism. + +### Network Partitions + +Network disruptions can partition the broadcast channel. If a partition occurs before session creation, each component can treat its activity as an independent session. + +The critical failure case is a partition during an active session. Disconnected components can each converge to a locally balanced transaction and sign independently. In arbitrary transaction construction, one component may temporarily over-declare outputs while waiting for missing inputs, or abort and restart after timeout. If value flows happen to balance differently across components, one branch may finalize while another stalls, and a sender can pay an unintended receiver. This is a safety failure. + +A global consensus protocol over the inputs set could prevent this class of error, but the honest setting does not assume a pre-established participant set or PKI needed to bootstrap that mechanism. + +To reduce partition-induced mispayment risk, require explicit receiver confirmation before any sender signs. Once a receiver gets a zero balance the send an acklowedgement to the sender including the hash of the canonical record of outputs. If the sender's hash matches they proceed to signing. + +// TODO should the reciever also include their output PSBT fragment in the same message? + +## Protocol Phases + +Inputs and outputs can be sent in any order. Ordering semantics must be defined a priori. +One possible definition is to use the hash of the protocol transcript as a salt to sort the inputs and outputs. + +All messages are raw binary encoded PSBT fragments. + +### Input Registration + +Each participant submits the transaction inputs they control. Inputs must be posted as independent messages. +Global passive observers should not be able to determine which inputs originate from the same party. + +### Psuedo Outputs + +A pseudo output is an declaration of fee contribution above the session-mandated minimum. It participates in the balance equation like a real output but does not appear in the final transaction. Participants must post a pseudo output only when their intended fee contribution exceeds what the session parameters require. Peers must be careful to exclude such outputs from size and fee calculations. And exclude them from the final serialized transaction to sign. + +### Output Registration + +Both output and pseudo output messages must carry a unique identifier to prevent double accounting. E.g a peer may read an output message multiple times. Since `TxOut`'s are not uniquely indentifiable that peer would have no ability to de-duplicate. + +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. + +When the `balance` reaches zero, every participant can independently verify the transaction is balanced and proceed to witness provision. + +This honest variant does not require an explicit Ready-to-Sign 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. + +### Witness provision + +Participants provide [finalized](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#user-content-Input_Finalizer) witnesses for the inputs they control. Once all witnesses are available, any participant can serve as the [BIP-174 combiner role](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#user-content-Combiner), assemble the fully signed transaction and broadcast it to the Bitcoin network. + +## 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 a independent message. Each participant derives the Silent Payment `scriptPubKey` from the shared transaction inputs and recipient scan public key. When the input set changes, all participants recompute the Silent Payment output before signing. diff --git a/semi-honest.md b/semi-honest.md index eba68bc..69dbb5a 100644 --- a/semi-honest.md +++ b/semi-honest.md @@ -1,117 +1,43 @@ -# Overview: Semi-honest multiparty PayJoin +# Overview: Multiparty PayJoin for semi-honest peer threat model -The following is a concrete description of the semi-honest multiparty PayJoin protocol. To understand why certain choices design were made, it is recommended to read the [overview document](./00_overview.md) first. +The following is a concrete description of the semi-honest multiparty PayJoin protocol. To understand why certain choices design were made, it is recommended to read the [overview document](./00_overview.md) and [honest protocol document](./honest.md) first. // TODO: supporting silent payments -// TODO: interaction / sequence diagram where we make a point of who is the initiator, responder, where they are both. - // TODO: Two phases ?: you cannot add output until every input owner indicated no more OR we just say liveness is weak. Since this is semi honest the only thing we need tolerate is crashes: someone has a delay and adds inputs at the last second ## Motivation -Two-party Payjoin preserves privacy of input/output ownership against third-party observers, but it does not preserve privacy from the view of the counterparty itself. In a two-party protocol, each participant can trivially attribute all unknown inputs and outputs to the other party. This reveals cluster information and requires counterparty trust. - -With n > 2, this privileged view is reduced. Payments and change outputs become ambiguous within the participant set. As a result, participants do not need to trust any specific counterparty with their clustering information. Increasing the number of parties therefore reduces counterparty trust and weakens clustering inferences. - -## Roles - -### Initiator and Responder - -The Initiator signals willingness to batch to their counterparty over a bidirectional channel. This signal is conveyed by including the mppj=1 parameter in the BIP21 URI. Either the BIP77 sender or receiver may be the Initiator. Parameters for their bi-directional channel may be encoded in the BIP21 (same as BIP77). - -The Responder is the counterparty who receives this signal. A Responder that does not support multiparty PayJoin will ignore the mppj=1 parameter and proceed with standard BIP77. A Responder that supports it waits for a session to be created. - -Two timeouts govern the phase of the whole protocol: - -* `T_intent`: the duration both parties are willing to wait for a session to be created after the intent to batch is signaled. If no session is created within T_intent, both parties MUST fall back to standard BIP77 over their existing bidirectional channel. -* `T_session`: the duration of the multiparty session itself, after which input and output registration closes and the protocol advances to signing. - -`T_session` is defined by the `SessionCreator` while `T_intent` is defined by the `Initiator`. - -// TODO: how do we indicate to sender/recv that we should join a mppj? out of band? New message? mailbox with more payment instructions? - -### SessionCreator - -Either the `Initiator` or the `Responder` may create the session. The party that does so is the `SessionCreator`. -The `SessionCreator` is responsible to creating session parameters (defined below), bootstrapping the transport mechanism and disseminating session information to the rest of the peers to the best of their capabilities. `SessionCreator` holds no special authority once the session is live. They simply become a participant. +Two-party and honest versions of the multi party Payjoin protocol preserves privacy of input/output ownership against third-party observers, but it does not preserve privacy from the view of the counterparty itself. E.g In a two-party protocol, each participant can trivially attribute all unknown inputs and outputs to the other party. This reveals cluster information and requires counterparty trust. -### Participant - -Once a party joins a session (defined below) they become a `Participant`. All participants share the same obligations as outlined below. - -### Diagrams - -Single receiver, two senders. Receiver is `Initiator` for both senders and becomes the `SessionCreator`. - -```mermaid -sequenceDiagram - participant R as Receiver (Initiator) - participant S1 as Sender 1 (Responder) - participant S2 as Sender 2 (Responder) - - Note over R,S1: T1 - R->>S1: BIP21 URI (mppj=1) - - Note over R,S2: T2 - R->>S2: BIP21 URI (mppj=1) - - Note over S1,S2: T3 - Receiver becomes SessionCreator - R->>S1: session invitation (s, session params) - R->>S2: session invitation (s, session params) -``` - -Sender 1 is the `Initiator` to the receiver who is an `Initiator` to sender 2. The receiver at time 3 becomes the `SessionCreator` - -```mermaid -sequenceDiagram - participant S1 as Sender 1 (Initiator) - participant R as Receiver (Responder / Initiator / SessionCreator) - participant S2 as Sender 2 (Responder) - - Note over S1,R: T1 - S1->>R: BIP21 URI (mppj=1) - - Note over R,S2: T2 - R->>S2: BIP21 URI (mppj=1) - - Note over S1,S2: T3 - Receiver becomes SessionCreator - R->>S1: session invitation (s, session params) - R->>S2: session invitation (s, session params) -``` +With n > 2 and metadata privacy, this privileged view is reduced. Payments and change outputs become ambiguous within the participant set. As a result, participants do not need to trust any specific counterparty with their clustering information. Increasing the number of parties therefore reduces counterparty trust and weakens clustering inferences. ## Threat model -This protocol operates in a semi-honest (honest-but-curious) model. All participants are assumed to economically proximate and thus follow the protocol as specified. They are not expected to deviate from the rules or misbehave in any form. However, they may attempt to learn as much as possible from the messages they observe. +This protocol operates in a semi-honest (honest-but-curious) model. All participants are assumed to economically proximate and thus follow the protocol as specified. They are not expected to deviate from the rules or misbehave. However, they may attempt to learn as much as possible from the messages they observe and the final transaction. Concretely, if any party learns the full plaintext transcript of messages, they should not be able to determine which inputs or outputs belong to which of the other participants. The protocol does not assume Byzantine robustness, and it does not attempt to detect or punish misbehavior. If a participant fails to follow through, the protocol may fail, but safety is not compromised - i.e participants will only provide witness if their expected outputs are included in the final transaction. -Its possible for some participants to join late. If there are N-1 RTS messages and a participant then registers then inputs and outputs this trivially creates a input-output link. -Possible mitigation include ignoring this laggard when the effective balance condition and N RTS's have been collected. - -## PSBT CRDT +Its possible for some participants to join late. If there are N RTS messages and a participant then registers then inputs and outputs this trivially creates a input-output link. +Possible mitigation include ignoring the laggard when the effective balance condition and N RTS's have been collected. -### Session Parameters +## Roles -The SessionCreator fixes the following parameters before the session opens. All participants MUST verify that the final transaction conforms to these parameters before signing. +The roles defined in the [honest protocol](./honest.md#roles) apply here without modification. The semi-honest model does not change who the Initiator, Responder, SessionCreator, or Participant are, nor how sessions are initiated. The only difference is that participants in this model are curious and may attempt to infer ownership links from observed messages and the final transaction. The communication model is therefore strengthened to prevent this. -* **Global transaction fields**: `nLocktime`, `nVersion` -* **Feerate**: each participant contributes fees proportional to the weight of their inputs and outputs -* **Input constraints**: `nSequence`, script type, segwit only -* **Timeouts**: `T_session` (see Roles) +## Communication model -### Join Semantics +In the semi-honest model, participants follow protocol rules but are still curious and may try to infer ownership links from any side channel available to them. For that reason, content encryption alone is not sufficient: if transport metadata reveals who posted which message and when, peers can correlate messages into participant-level clusters. -Participants learn transaction fragments in arbitrary order and accumulate them as they arrive. In the semi-honest setting there are no conflicting writes: global fields are fixed by the session parameters and each participant controls disjoint inputs and outputs. Any two valid fragments can therefore be merged by union. +Metadata privacy is therefore a protocol requirement in this setting. The communication layer must hide sender network identity and reduce linkability across messages, so that learning the transcript does not trivially reveal input-output ownership. -If the accumulated transaction does not balance, or any fragment violates the session parameters, a participant MUST refuse to sign and abandon the session. +This is why iroh gossip is not sufficient here as the primary transport. While iroh provides efficient dissemination, it does not by itself provide the metadata-hiding guarantees this threat model requires. -// TODO: sorting semantics under transport option B -// TODO: refer to nothingmuch's document +Separately, dissemination and agreement should be distinguished. Gossip is enough to disseminate messages and can still provide eventual convergence when deterministic merge rules are used. A separate agreement mechanism (some specific instantiation of a lattice agreement protocol) is only needed when stronger guarantees are required for intermediate consistency, timely termination, (crashes?) or recovery under communication disruptions. -## Communication model +Given those tradeoffs, using the BIP77 directory for total order is a simpler direction. A shared append-only mailbox gives participants a practical, common message order to process, which reduces the need to deploy and tune a separate distributed agreement layer. In other words, it combines the metadata privacy this model requires with a straightforward coordination primitive that is easier to implement and operate. ### BIP77 Directory as anonymous broadcast channel @@ -122,70 +48,17 @@ Communication is mediated by a PayJoin directory accessed via OHTTP, following t A session is defined by a single ephemeral shared secret s. Any participant who learns s can join the session. Knowledge of this secret is the only admission control mechanism. Participants derive mailbox identifiers and initialize their HPKE context with s. The shared secret is distributed via the existing bidirectional channel. Parties who learn s can both read and write to the mailbox. All payloads are encrypted using HPKE, so the directory only handles opaque ciphertext blobs and cannot link messages to participants. -### [p2p gossip via Iroh Gossip](https://docs.iroh.computer/connecting/gossip) - -Iroh supports message dissemination via gossip. Peers subscribe to the a topic id and connect to some subset of endpoints. -Peers will redundantly relay messages to peers that are not interested in a particular topic. The topic id can be a ephemeral secret embedded in the bip21 along side some bootstrapping endpoints. - -Iroh does not provide metadata privacy out the box. TBD when and why this can be problematic. - -Integrity and authenticity is provided out the box via TLS. This may be a blocker for TLS-less settings (bitcoin core). Perhaps HPKE (bip77) should be supported since iroh endpoints are just EC points. Some engineering work may be required to support secp256k1 if that is a blocker. - -// TODO: how to do discovery of other peers? -// TODO: yolo RAFT leader based agreement / lattice agreement. Trusted leader = "trusted with liveness". -// TODO; peers that are offline and missed input / output registration will leak them selves. -// TODO: peers need reconcile messages that they missed - ## Protocol phases -Input and output registration can be sent in any order. Ordering and sorting semantics must be defined a priori. -One possible definition is to use the hash of the protocol transcript as a salt to sort the inputs and outputs. - -All messages are base64 encoded as PSBT fragments. +For the canonical phase-by-phase flow, see the honest protocol document: [Overview: Honest multiparty PayJoin](./honest.md#protocol-phases). ### Message Timing -To prevent timing correlation between a participant's messages, each message MUST be assigned a randomized delay before posting. +To prevent timing correlation between a participant's messages, each message must be assigned a randomized delay before posting. -If the total number of messages is known in advance, sample n uniform random times within the session window and post each message at its assigned time. If the count is not yet known, sample delays from an exponential distribution instead. +If the total number of messages is known in advance, sample n uniform random times within the session window and post each message at its assigned time. Message publication times are assigned in two phases: 1. Input registration, output registration, and RTS declarations are assigned publication times at the start of the session. -2. Witness provision messages MUST NOT be assigned publication times until registration closes. - -// TODO: coinselection strategy? do peers run their own coinselection based on their own target outputs? What if a recv doesnt have target outputs? - -### Input Registration - -Each participant submits the transaction inputs they control. Inputs must be posted as independent messages. -Inputs are not attributed to participants. Global observers should not be able to determine which inputs originate from the same party. - -### Psuedo Outputs - -A pseudo output is an anonymous declaration of fee contribution above the session-mandated minimum. It participates in the balance equation like a real output but does not appear in the final transaction. Participants MUST post a pseudo output only when their intended fee contribution exceeds what the session parameters require. - -When the global sum of inputs minus outputs minus pseudo outputs reaches zero, every participant can independently verify the transaction is balanced and proceed declare RTS. - -### Output Registration - -Participants post their desired outputs as independent messages. No explicit linkage between a participant's inputs and outputs is revealed. Output and pseudo output messages MUST carry a unique identifier to prevent double accounting. - -A participant who wishes to back out of the session posts an output that causes the transaction balance to overflow. That is, their declared outputs exceed their input contribution. This makes the balance equation unsatisfiable and MUST cause all other participants to refuse to sign. - -### Ready-to-sign (RTS) declarations - -For each input they control, participants post a ready-to-sign declaration. This signals that they accept the current transaction template and are prepared to sign it. -Only once all inputs have corresponding ready signals does the protocol advance. This ensures that all participants have finished contributing transaction fragments. - -When the global sum of inputs minus outputs minus pseudo outputs fee declarations hits zero, every participant can independently verify the transaction is balanced and sign. - -### Witness provision - -Participants provide witnesses for the inputs they control. Once all witnesses are available, any participant can assemble the fully signed transaction and broadcast it to the Bitcoin network. - -## Risks and limitations - -### Liveness fragility - -The protocol is fragile with respect to liveness. If even a single participant fails to provide witnesses in the final phase, the transaction cannot be completed. This is the worst-case outcome and is inherent to interactive multiparty transactions requiring unanimous signatures. +2. Witness provision messages must not be assigned publication times until registration closes.