fixup! Add honest overview

Author: arminsabouri

honest.md

@@ -1,6 +1,6 @@
 # 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.
+The following is a concrete description of the honest multiparty transaction construction protocol. To understand why certain choices design were made, it is recommended to read the [overview document](./00_overview.md) first.
 
 ## Motivation
 
@@ -18,7 +18,7 @@ Importantly, fund safety does not depend on peer honesty. Each participant signs
 
 ### 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.
+The Initiator signals willingness to batch to their counterparty over an authenticated 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
@@ -27,7 +27,7 @@ The Responder is the counterparty who receives this signal. If a peer does not s
 
 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_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 an 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`.
@@ -94,25 +94,23 @@ For this document, `balance` means the running value equation over the accumulat
 
 `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  
+For more information please refere to the [draft BIP](https://github.com/payjoin/multiparty-protocol-docs/pull/6)
 
 ## Communication model
 
 The protocol assumes an abstract session-scoped broadcast channel for disseminating PSBT fragments.
 
-Required channel properties:
+**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.
+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.
 
 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.
+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 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.
 
@@ -126,18 +124,17 @@ Different instantiations can satisfy this in different ways. Unordered gossip-st
 
 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.
+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 partition 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 partition 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?
+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.
 
@@ -156,7 +153,7 @@ Both output and pseudo output messages must carry a unique identifier to prevent
 
 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.
+When the `balance` reaches zero and receiver confirmations are received, 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.