Add semi-honest overview

semi-honest.md

@@ -0,0 +1,93 @@
+# Overview: Semi-honest multiparty PayJoin
+
+The following is a concrete description of the semi-honest multiparty PayJoin protocol. To understand why certain design choises were made, it is recommended to read the [overview document](./00_overview.md) first.
+
+## 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.
+
+## Threat model
+
+This protocol operates in a semi-honest (honest-but-curious) model. All participants are assumed to economically approximate 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 saftey is not compromised - i.e participants will only provide witness if their expected outputs are included in the final transaction.
+
+// TODO: describe different ways a peer can be byzantine
+
+## Communication model
+
+### 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 must support append semantics. Multiple participants must be able to write to the same mailbox, and peers must be able to poll and retrieve all appended messages. The mailbox effectively functions as an anonymous broadcast log of encrypted payloads. No direct peer-to-peer transport is required, and all coordination occurs through this mailbox.
+
+The directory is not trusted for confidentiality or correctness beyond the assumptions already present in BIP77. It is only required to relay ciphertexts.
+
+// TODO: Since mailboxes are variably sized this may leak information about the number of participants and the size of the transaction.
+
+Alternatives to appending have been discussed [here](https://github.com/payjoin/rust-payjoin/issues/365)
+
+## Protocol initiation
+
+### 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 (short id in bip77) and initialize their HPKE context with (S). The shared secret may be distributed out-of-band among intended participants. The protocol does not constrain how this distribution occurs -- only that it should be treated as sensative information. Parties who learn the key can both read and write to the mailbox.
+
+// TODO: describe bip21 / bip321 format
+
+All payloads are encrypted using HPKE (Same AEAD as BIP77).
+As a result, messages stored in the directory reveal neither sender identity nor linkability between messages. The directory only handles opaque ciphertext blobs.
+
+## 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 deterministicly sort the inputs and outputs.
+
+// TODO: supporting silent payments
+
+### Input Registration
+
+Each participant submits the transaction inputs they control. Inputs must be posted as independent messages.
+Inputs are not attributed to participants. Observers of the mailbox should not be able to determine which inputs originate from the same party.
+
+// TODO: introducing jitter? Waitign for some other messages?
+
+### Output Registration
+
+Participants submit their desired outputs as separate messages. Outputs are broadcast independently of inputs, and no explicit linkage is revealed between a participant’s inputs and outputs. Recepients may not substitute outputs for other desired outputs.
+
+At the end of this phase, all participants can construct a candidate unsigned transaction consistent with the collected inputs and outputs.
+
+### Ready-to-sign 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.
+
+// TODO: authentication on the ready-to-sign declarations? In the semi-honest setting can we simply count the number of ready-to-sign declarations and compare to the number of inputs provided.
+
+Example of the transaction construction state machine can be found in the [simulation codebase](https://github.com/payjoin/btsim/blob/master/src/tx_contruction.rs).
+
+### 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.
+
+### fault attribution
+
+Because messages are anonymous and there is no authenticated agreement on a transcript, participants cannot reliably determine the ommitting party or parties. In the semi-honest setting, there is no mechanism for blame assignment or exclusion.
+
+If the protocol stalls, the session must be abandoned. A new session must be created if participants wish to try again.
+
+// TODO: This is in the semi-synchronous / synchronous setting so we should talk about timeouts?