Split semi-honest overview into two

Move everything that is a commonality into honest overview.

Author: arminsabouri

honest.md

@@ -0,0 +1,160 @@
+
+# Overview: Multiparty PayJoin for 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.
+
+Concretly peers are trusted with:
+
+* Liveness: peers are expected to follow the protocol flow and remain reachable. As a result, timeout-based progress assumptions implicitly rely on timely communication.
+
+* 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` (see Roles)
+
+## 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.
+
+Candidate instantiations include [Iroh gossip + set reconciliation](https://docs.iroh.computer/connecting/gossip), [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.
+
+// TODO refine this
+However, transport-level metadata privacy is still important against external observers. Content encryption alone does not prevent traffic analysis.
+
+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.
+
+### Message Reconciliation
+
+The channel must support message reconciliation for peers that temporarily disconnect or miss messages. A participant with an incomplete view can otherwise fail to converge on the unsigned transaction and will refuse to sign.
+
+Different instantiations provide this in different ways: replayable append-only logs, set-reconciliation overlays, etc... The protocol only requires the property that missed valid messages can be recovered during the session window; the mechanism is transport-specific.
+
+## Protocol Phases
+
+Input and output registration 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. A psuedo output may be encoded as a txout in a PSBT fragment where the scriptpubkey (spk) is set to empty bytes. This will fail standardness checks but pass consensus. Consensus invalid spk would introduce additional overhead -- such as creating as an output >= 10KB size limit.
+
+### 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 declare ready-to-sign.
+
+### Ready-to-sign (RTS) declarations
+
+For each input they control, participants post a RTS 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 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.