Add an overview

[yuval-block]

This includes a high level description of the various components of the
protocol suite, focusing on the transaction construction.

Unlike the strawman ladder it replaced (previously described as an
overview, and now somewhat out of date at any rate) it is scoped to only
discuss actual things not strawman constructions which only benefit
exposition, to avoid confusion about what is actually being implemented.

Closes #21

[arminsabouri]

This walks a thin line between describing the solutions and the techincal "how" (as well as what the problems). My comments are mostly regarding continuitity / flow of ideas.

[arminsabouri]

nit: We either need a leading sentence that connects this section with the one before or just remove it or condense it into 2 sentences into the last section. e.g the interactive tx construction protocols may operate in these communication models blah blah it matters bc X.

[arminsabouri]

Edit: now that I see how the rest of the document builds these terms, I think its approriate to define them here. But a connector sentence would still cause less "whip lash" .

[arminsabouri]

Same comment about a connector sentence for this as well.

[arminsabouri]

just noticed this. Have not read the rest of this

[arminsabouri]

This reads well! I need to re-read the cordial miners / consitency section again. There is a lot of information packed in there that I am mainly not familiar with. But I think it gets the why across which is the important bit for this document.

[yuval-block]

about the links, we can:

• remove them, add later (risks forgetting)
• wait until the destinations are merged (leaves this PR open needlessly)
• merge with broken links, risks leaving them broken if there are typos etc

i'm leaning towards the latter, and after we're done with the backlog we can add a nix flake check that ensures there are no broken links... wdyt @bc1cindy ?

[github-actions]

range-diff for force push f9a0ded9d9 → 36dbec85c3 October 14, 2026 16:42 UTC: 1 modified, 1 added

^{reproduce: git range-diff 8ac4434..f9a0ded 8ac4434..36dbec8}

-:  ---------- > 1:  304120b2d0 Generate SUMMARY.md from an OKF index.md
1:  f9a0ded9d9 ! 2:  36dbec85c3 [WIP] Overview

1: f9a0ded9d9 ! 2: 36dbec85c3 [WIP] Overview

@@ Metadata
 Author: Yuval Kogman <nothingmuch@woobling.org>
 
  ## Commit message ##
-    [WIP] Overview
+    Add an overview
+
+    This includes a high level description of the various components of the
+    protocol suite, focusing on the transaction construction.
+
+    Unlike the strawman ladder it replaced (previously described as an
+    overview, and now somewhat out of date at any rate) it is scoped to only
+    discuss actual things not strawman constructions which only benefit
+    exposition, to avoid confusion about what is actually being implemented.
 
     Closes #21
 
- ## overview.md (new) ##
+ ## .typos.toml (new) ##
+@@
++[default.extend-identifiers]
++# Author of The Byzantine Generals Problem.
++Pease = "Pease"
+
+ ## docs/index.md ##
+@@
+ okf_version: "0.2"
+ ---
+ 
++# Protocol Suite
++
++* [Overview](overview.md) - Collaborative transaction construction, privacy, fault tolerance and coalition formation.
++
+ # BIP Drafts
+ 
+ * [PSBT Scrubber](bip-drafts/scrubber.md) - Which PSBT fields can be shared with trusted and untrusted parties such that privacy is preserved.
+
+ ## docs/overview.md (new) ##
 @@
 +# Fungi protocol overview
 +
@@ overview.md (new)
 +
 +## Consistency, safety and liveness
 +
-+Consistency has to do not just with peers synchronizing their states, but also detecting when they have been successfully synchronized. Two properties of distributed systems related to this are safety and liveness.[^safety-liveness]
++Consistency has to do not just with peers synchronizing their states, but also detecting when they have been successfully synchronized. Two properties of distributed systems related to this are safety and liveness: safety excludes unacceptable outcomes; liveness concerns whether the protocol eventually completes.[^safety-liveness]
 +
 +Because transactions are subject to the safety guarantees of the Bitcoin protocol, collaborative transaction construction can more or less take it for granted. In all transaction construction variants the consistency requirement is agreeing on the exact unsigned transaction. We assume `SIGHASH_ALL`, which means that a signature by an input only authorizes that exact transaction, with its full list of inputs and outputs. In order to combine the signatures and obtain a fully valid transaction, all of the signatures must be made against the same transaction data.
 +
@@ overview.md (new)
 +
 +What such a majority can provide, therefore, is a mechanism for agreeing on which inputs belong to peers that have failed to complete the protocol. Depending on the communication model, some kind of timeout or recovery condition will be reached, and any inputs for which signatures have not yet been provided can be defined as out of compliance with the protocol. A new transaction construction session can then be attempted, excluding those inputs.
 +
-+Under synchrony or partial synchrony (specifically the eventual synchrony variant), if a sufficient threshold of peers can all agree it has been too long, then they can initiate such a recovery session. A threshold of peers agreeing implies a majority of honest peers agreeing. Note that agreement by a majority of honest participants requires a supermajority threshold: given $n = 3f+1$ where at most $f$ are faulty, a quorum of $2f+1$ peers will have at least $f+1$ honest peers in it agreeing.
++Under synchrony or partial synchrony (specifically the eventual synchrony variant), if a sufficient threshold of peers can all agree it has been too long, then they can initiate such a recovery session. A threshold of peers agreeing implies a majority of honest peers agreeing. Note that agreement by a majority of honest participants requires a supermajority threshold. A quorum is a set of peers meeting the required agreement threshold. Given $n = 3f+1$ where at most $f$ are faulty, a quorum of $2f+1$ peers will have at least $f+1$ honest peers in it agreeing.
 +
-+So long as the notion of "too long" is well defined (consistent with the communication model) and agreed by a quorum, if there are $f$ inputs owned by misbehaving peers honest parties should be able to successfully complete a run of the protocol after $O(f)$ attempts by simply excluding those inputsn as it becomes apparent that they are unresponsive.
++So long as the notion of "too long" is well defined (consistent with the communication model) and agreed by a quorum, if there are $f$ inputs owned by misbehaving peers honest parties should be able to successfully complete a run of the protocol after $O(f)$ attemptsby simply excluding those inputs as it becomes apparent that they are unresponsive.
 +
 +## Synchronization protocol
 +
@@ overview.md (new)
 +
 +### Byzantine eventual consistency
 +
-+The simplest of these is Byzantine Eventual Consistency by Martin Kleppmann and Heidi Howard.[^bec] In this model, messages, or transaction fragments as in our case, are committed to a Merklized causal log. For example, if Alice is adding an output, the output itself would be the payload of her message, and the envelope would contain references to Alice's last message, as well as the messages of other peers, referenced by hash.
++The simplest of these is Byzantine Eventual Consistency by Martin Kleppmann and Heidi Howard.[^bec] In this model, messages, or transaction fragments as in our case, are committed to a [Merklized](https://en.wikipedia.org/wiki/Merkle_tree) causal log. For example, if Alice is adding an output, the output itself would be the payload of her message, and the envelope would contain references to Alice's last message, as well as the messages of other peers, referenced by hash.
 +
 +In the naive version of their protocol (they describe a more optimized version), whenever a message is received, if the receiving peer does not know what a hash in its references commits to, it will request the preimage from the peer which sent this message, and after a finite number of such recursive queries and round trips it will eventually reach a message it has already seen. Signatures on the messages authenticate their authorship, allowing messages to be relayed via intermediate peers, and for any equivocations to be detectable. If the payloads are subject to validity constraints and merging independently accepting updates preserves these constraints, as Kleppmann and Howard show, this is sufficient for *Byzantine* eventual consistency: loosely speaking, even in the presence of Byzantine nodes, honest peers will eventually converge on the same set of messages.
 +
-+For privacy-preserving transaction construction, the payload should be a list of transaction fragments delivered anonymously to the peer which constructs the message. In BEC, these messages form an unstructured DAG, with each honest peer's messages forming a linked list which also links into the linked lists of other peers. The depths of these lists are not synchronized or bounded.
++For privacy-preserving transaction construction, the payload should be a list of transaction fragments delivered anonymously to the peer which constructs the message. In BEC, these messages form an unstructured directed acyclic graph (DAG), with each honest peer's messages forming a linked list which also links into the linked lists of other peers. The depths of these lists are not synchronized or bounded.
 +
 +Because in our setting they collect several state-related messages submitted by other participants, we'll call these messages blocks, in line with conventions in similar protocols.
 +
@@ overview.md (new)
 +
 +By waiting to reconcile the set of fragments with neighboring peers before building a block, peers can adhere to the cordiality while minimizing the number of blocks sent overall, which is more appropriate for the goal of coming to consensus over a finite sequence of sets with minimal end-to-end latency, as opposed to maximizing throughput and minimizing confirmation latency, which is the more typical design goal for DAG consensus algorithms.
 +
-+Note that these restrictions on the structure still consist of a special case of Kleppmann and Howard's hash-consed DAG; every block DAG structure is also a valid Byzantine eventual consistency causal log structure. Because of the validity proofs on transaction fragments, and the concurrent PSBT semantics we do not need an ordering but only a set union.
++Note that these restrictions on the structure still consist of a special case of Kleppmann and Howard's [hash-consed](https://en.wikipedia.org/wiki/Hash_consing) DAG; every block DAG structure is also a valid Byzantine eventual consistency causal log structure. Because of the validity proofs on transaction fragments, and the concurrent PSBT semantics we do not need an ordering but only a set union.
 +
 +Whether or not eventual consistency will suffice for synchronizing a set union depends on the communication model. When it is not sufficient, the blocks which do arrive and their parent blocks can be used to coordinate failure recovery, identifying responsive peers. In any case we do not need to ensure the stronger notion of safety that cordial miners and other such protocols provide, because of the unanimity requirement, and the consensus machinery is only needed for coordinating failure recovery.
 +
@@ overview.md (new)
 +
 +All participants can submit their transactions to a designated validator, with all other validators' blocks simply acknowledging the designated validator's blocks. 
 +
-+In principle, it is possible to decouple the validator role from the participant role and setting $n = 1$, where blocks form a linked list. This instantiates a version of the protocol based on a trusted coordinator. Note that "trust" here is meant only with regard to liveness, not to privacy. If a coordinator is trusted with privacy, which is the norm  for such services, validity proofs and anonymous broadcast are little more than privacy theater. A centralized protocol where the server simply does not keep a permanent record would be strictly better because users would be informed and computational and bandwidth resources would not be pointlessly wasted, degrading reliabiliy (which itself a privacy concern).
++In principle, it is possible to decouple the validator role from the participant role and setting $n = 1$, where blocks form a linked list. This instantiates a version of the protocol based on a trusted coordinator. Note that "trust" here is meant only with regard to liveness, not to privacy. If a coordinator is trusted with privacy, which is the norm for such services,[^trusted-coordinators] validity proofs and anonymous broadcast are little more than privacy theater. A centralized protocol where the server simply does not keep a permanent record would be strictly better because users would be informed and computational and bandwidth resources would not be pointlessly wasted, degrading reliabiliy (which itself a privacy concern).
 +
-+Note that this does not actually require $n = 1$ to shift the communication and coordination complexity onto a more powerful node; clients who choose to follow a particular attested state can still submit ACKs to it, and simply echo the parent block set commitments of the attested blocks when ACKing the same height with minimal communication complexity. Therefore there is no need to actually decouple those roles, it is sufficient to just shift the workload to one validator, unless such a validator is not itself a participant in the transaction.
++Note that this does not actually require $n = 1$ to shift the communication and coordination complexity onto a more powerful node; clients who choose to follow a particular attested state can still submit acknowledgements to it, and simply echo the parent block set commitments of the attested blocks when acknowledging the same height with minimal communication complexity. Therefore there is no need to actually decouple those roles, it is sufficient to just shift the workload to one validator, unless such a validator is not itself a participant in the transaction.
 +
-+A trusted execution environment can realize this trust model concretely, and would then be able to provide an attested view of the protocol state to clients.
++A trusted execution environment (TEE) can shift this trust assumption from the service operator to the hardware vendor and its attestation infrastructure. Attestation provides verifiable evidence that designated validation code executed in the claimed protected environment. Clients can therefore accept its validation of the protocol state without trusting the operator to execute that code faithfully, instead trusting the vendor’s hardware isolation and attestation guarantees. This additional trust assumption can improve liveness and consistency under weaker quorum assumptions, while reducing clients’ validation work. It does not relax the requirement for unanimous transaction signing; private allocations and spending authority remain with the participants.
 +
 +This has two primary advantages. The first is that bandwidth or compute restricted devices can participate asymmetrically in dissemination, validation, etc. If the trust assumption fails, that is still only a liveness violation, and doesn't compromise on safety or privacy. Presumably such clients are too constrained for scalable Byzantine fault tolerance. On the other hand, if the TEE assumption holds, liveness can tolerate a dishonest majority allowing successful termination after $O(f)$ attempts even if $f = n - 2$ (note that $f = n - 1$ holds trivially, that's just falling back to a unilateral transaction).
 +
@@ overview.md (new)
 +
 +When preferences over the coalition structure are in play (the cost function), in so-called hedonic games, it is often very hard (also in an algorithmic sense) to find stable coalition structures, as the preferences of the participants may conflict. In their most general form, such game descriptions are enormous as the preferences are defined over a large combinatorial object but even when many assumptions are made, like constraining the kinds of preferences the participants may have, it is still generally hard to find stable equilibria.[^hedonic] Complicating matters further, sharing the preferences would itself be a privacy leak, so we would prefer to limit that as much as possible, and certainly we cannot assume a mechanism that optimizes outcomes by just being able to read these preferneces.
 +
-+Fortunately, some of these difficulties of hedonic games can be bypassed with the introduction of a transferrable utility, and assigning the coalition itself a payoff, which can be redistributed. In our use case this payoff originates from any blockspace savings from net settlement, and the privacy benefits from collaboration. This surplus is not observable, it is the sum of subjective payoffs depending on individual participants' preferences (which in turn depend on their circumstances, privacy threat model, etc). While this does not guarantee stability, if a stable coalition structure exists, a transferrable utility can make the process of finding one much easier by iterated bilateral negotiation. However much these benefits are worth it to participants, if this surplus exists, then it can be voluntarily redistributed as sats among the participants (i.e. via a fee mechanism) aligning incentives for collaborative transaction construction, so that all coalition members stand to gain from participating.
++Fortunately, some of these difficulties of hedonic games can be bypassed with the introduction of a transferable utility, and assigning the coalition itself a payoff, which can be redistributed. In our use case this payoff originates from any blockspace savings from net settlement, and the privacy benefits from collaboration. This surplus is not observable, it is the sum of subjective payoffs depending on individual participants' preferences (which in turn depend on their circumstances, privacy threat model, etc). While this does not guarantee stability, if a stable coalition structure exists, a transferable utility can make the process of finding one much easier by iterated bilateral negotiation. However much these benefits are worth it to participants, if this surplus exists, then it can be voluntarily redistributed as sats among the participants (i.e. via a fee mechanism) aligning incentives for collaborative transaction construction, so that all coalition members stand to gain from participating.
 +
 +This is exactly the mechanism that the coalition formation protocol attempts to build: co-spend proposals are anonymous and confidential proposals, each of which is a bundle of bilateral agreements between the proposer and the owner of the other UTXOs listed in the proposal. The distinguishing feature of co-spend proposals is that they can be aggregated together, which generalizes a JoinMarket-like fee mechanism: it allows multiple "takers" to pay a single "maker" as a kind of group buy, as well as multiple independent "makers", all in the same transaction. This generality means that the distinction between taker and maker is removed; any participant can play both roles in a single transaction, depending on the co-spend proposals it makes or accepts.
 +
@@ overview.md (new)
 +
 +[^dag-rider]: I. Keidar, E. Kokoris-Kogias, O. Naor and A. Spiegelman, [*All You Need is DAG*](https://arxiv.org/abs/2102.08325) (2021). DAG-Rider separates construction of a communication DAG from local ordering of its proposals.
 +
++[^trusted-coordinators]: Y. Kogman, [*Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks*](https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/w2B-RRdUCQAJ)
++
 +[^coinswap]: For example [CoinSwap](https://openswap.live/) is such a protocol which relies on atomic swap contracts, designed with privacy in mind.
 +
 +[^hedonic]: D. Peters and E. Elkind, [*Simple Causes of Complexity in Hedonic Games*](https://arxiv.org/abs/1507.03474) (2015). Shows how modest expressiveness in preferences can make deciding the existence of stable outcomes computationally hard.

[github-actions]

range-diff for force push 36dbec85c3 → c3a0f8d3da October 14, 2026 16:48 UTC: 1 modified, 1 unchanged

^{reproduce: git range-diff 8ac4434..36dbec8 8ac4434..c3a0f8d}

1:  304120b2d0 = 1:  304120b2d0 Generate SUMMARY.md from an OKF index.md
2:  36dbec85c3 ! 2:  c3a0f8d3da Add an overview

2: 36dbec85c3 ! 2: c3a0f8d3da Add an overview

@@ docs/overview.md (new)
 +
 +Fungi is a suite of protocols for collaborative Bitcoin transactions. Its goal is to support interactive payments and net settlement with counterparties, as well as decentralized, market-based CoinJoins with untrusted parties.
 +
-+While the protocols themselves support arbitrary transaction structures, obtaining privacy outcomes is a matter of participants acting in their own self-interest and cooperating with others to achieve the desired results. The [problem definition](https://github.com/fungi-protocol/docs/blob/problem-definition/collaborative_txn_privacy.md) <!-- FIXME relative link to file not http --> describes conditions for a transaction graph to preserve privacy on chain. The repository also discusses the definition of a [cost function](./cost_function_abstract.md) for optimizing for this outcome. That said, the protocols for collaborative transactions summarized in this document are agnostic to the details of such a cost function.
++While the protocols themselves support arbitrary transaction structures, obtaining privacy outcomes is a matter of participants acting in their own self-interest and cooperating with others to achieve the desired results. The [problem definition](../collaborative_txn_privacy.md) describes conditions for a transaction graph to preserve privacy on chain. The repository also discusses the definition of a [cost function](./cost_function_abstract.md) for optimizing for this outcome. That said, the protocols for collaborative transactions summarized in this document are agnostic to the details of such a cost function.
 +
 +Depending on whether peers must be considered adversarial, and the underlying transport mechanisms, different variations of transaction construction are defined. These are the honest, semi-honest (also known as honest-but-curious) and Byzantine settings.
 +
 +In the honest setting, we assume peers can be trusted to follow the protocol and never leak any information apart from the final transaction (deliberately or otherwise). In the semi-honest setting we no longer trust peers with privacy; privacy-preserving transports are used to hide the attribution of different transaction fragments. Finally, in the Byzantine setting we must tolerate arbitrarily malicious behavior from peers.
 +
-+Finally, the [coalition formation](https://github.com/fungi-protocol/docs/blob/coalition-formation/coalition_formation.md) <!-- FIXME relative link to file not http --> protocol provides a market-based mechanism to allow mutually distrusting strangers to anonymously start transaction construction together. Randomizing peer selection is a requirement for CoinJoin graphs with the desired privacy properties. Net settlement, while beneficial for privacy, does not obscure the community structure that is inherent in real-world economic networks.
++Finally, the [coalition formation](../coalition_formation.md) protocol provides a market-based mechanism to allow mutually distrusting strangers to anonymously start transaction construction together. Randomizing peer selection is a requirement for CoinJoin graphs with the desired privacy properties. Net settlement, while beneficial for privacy, does not obscure the community structure that is inherent in real-world economic networks.
 +
 +## Concurrent PSBTs
 +
@@ docs/overview.md (new)
 +
 +While BIP 174 has been used in several collaborative transaction protocols, as specified it can only represent a fully formed unsigned transaction. [BIP 370](https://bips.dev/370/) extends the format to explicitly allow the input and output lists to be modifiable. The fact that these lists are ordered presents a challenge for concurrent transaction construction.
 +
-+The first component of the Fungi protocol suite is the proposed [Concurrent PSBT specification](https://github.com/fungi-protocol/docs/blob/concurrent-psbt/psbt-concurrent.md) <!-- FIXME relative link to file not http -->. It treats these collections as unordered sets rather than lists, allowing fragments to be combined regardless of arrival order, not just when collecting signatures but also when authoring the transaction. A consistent ordering is established before signing.
++The first component of the Fungi protocol suite is the proposed [Concurrent PSBT specification](../psbt-concurrent.md). It treats these collections as unordered sets rather than lists, allowing fragments to be combined regardless of arrival order, not just when collecting signatures but also when authoring the transaction. A consistent ordering is established before signing.
 +
 +In the "sneakernet" setting participants can pass around a single PSBT file, editing it in turn before handing it to the next party, but with concurrent PSBTs they can also concurrently modify different copies and merge them as well. And anything in between. Because divergent copies can be merged into one coherent transaction, the details of communication don't need to be specified; it could be a shared directory on a server, or one or more USB sticks, perhaps files shared over email, or some combination of the above.
 +
@@ docs/overview.md (new)
 +
 +A motivating use case for interactive transaction construction, one of several, is more efficient and private on-chain payments. Several parties can batch arbitrarily many payments into one transaction. Each participant's inputs and outputs express only the net difference. Individual payment amounts need not appear on chain.
 +
-+Net settlement adds safety considerations. Before signing, a participant must know that its funds reach the intended destinations. It can check outputs returning funds to itself directly; for a payment, it needs the payee to confirm that the transaction satisfies their agreement. Within each payment cycle at least one party will receive as much as it sends or more, and can therefore safely initiate confirmation. See the [concurrent PSBT specification](https://github.com/fungi-protocol/docs/blob/concurrent-psbt/psbt-concurrent.md#confirmation-of-successful-payment-prior-to-signing) <!-- FIXME relative link to file not http --> for additional details. <!-- TODO will be split off into a separate BIP see #16 -->
++Net settlement adds safety considerations. Before signing, a participant must know that its funds reach the intended destinations. It can check outputs returning funds to itself directly; for a payment, it needs the payee to confirm that the transaction satisfies their agreement. Within each payment cycle at least one party will receive as much as it sends or more, and can therefore safely initiate confirmation. See the [concurrent PSBT specification](../psbt-concurrent.md#confirmation-of-successful-payment-prior-to-signing) for additional details.
 +
 +## The semi-honest setting: adding privacy-preserving communication
 +
@@ docs/overview.md (new)
 +
 +Payment communication has different requirements, which also must be provided by the underlying transport. A sender must authenticate its receiver and obtain confirmation that the proposed transaction satisfies their agreement. However, this authentication can rely on a one-time code or pseudonym. The receiver doesn't need to authenticate the sender in order to be paid securely. Both counterparties know their payment amount, but need not disclose that relationship to the group or identify their transaction inputs and outputs to one another.
 +
-+The privacy objective is to avoid revealing anything more than what is inherent in the transaction data to the world, and the minimal payment details to counterparties. Anonymous communication is a necessary but insufficient requirement for this; it does not prevent inference from amounts or transaction structure, nor from the wider transaction graph. The on-chain limitations described in the [problem definition](https://github.com/fungi-protocol/docs/blob/problem-definition/collaborative_txn_privacy.md) <!-- FIXME rel link --> still apply.
++The privacy objective is to avoid revealing anything more than what is inherent in the transaction data to the world, and the minimal payment details to counterparties. Anonymous communication is a necessary but insufficient requirement for this; it does not prevent inference from amounts or transaction structure, nor from the wider transaction graph. The on-chain limitations described in the [problem definition](../collaborative_txn_privacy.md) still apply.
 +
 +This setting is inherently more brittle, because when disruptive messages are shared anonymously not only is it unclear how to recover, in general it isn't possible to tell apart the disruptive messages from the honest ones.
 +

[bc1cindy]

about the links, we can:

• remove them, add later (risks forgetting)
• wait until the destinations are merged (leaves this PR open needlessly)
• merge with broken links, risks leaving them broken if there are typos etc

i'm leaning towards the latter, and after we're done with the backlog we can add a nix flake check that ensures there are no broken links... wdyt @bc1cindy ?

agreed, merge with broken links and #54 tracks adding the check once the backlog lands

non-blocking, but since the chapters move into docs/ per #50, the ../ links should be ./, otherwise they stay broken even after the destinations land:

- L5: ../collaborative_txn_privacy.md → ./collaborative_txn_privacy.md
- L11: ../coalition_formation.md → ./coalition_formation.md
- L19: ../psbt-concurrent.md → ./psbt-concurrent.md
- L71: ../psbt-concurrent.md#confirmation-... → ./psbt-concurrent.md#confirmation-...
- L83: ../collaborative_txn_privacy.md → ./collaborative_txn_privacy.md

[bc1cindy]

• L59: were not delivered.. → were not delivered.
• L129: attemptsby → attempts by
• L139: merging independently accepting updates → merging independently accepted updates
• L171: reliabiliy → reliability
• L171: (which itself a privacy concern) → (which is itself a privacy concern)
• L189: preferneces → preferences
• L193: the owner of the other UTXOs → the owners of the other UTXOs
• L195: peers which proposing → peers proposing

[oakagent]

This PR builds on work that is not on main yet (304120b ('Generate SUMMARY.md from an OKF index.md') from #50 (okf-index)). Setting its base to okf-index, or waiting for that work to land, keeps the diff to this PR's own commits.

[arminsabouri]

I disagree. We cannot share this document with broken links. removing the links might be better.

[bc1cindy]

I disagree. We cannot share this document with broken links. removing the links might be better.

we could drop the links and keep the text

[afsheenb]

Might be worth adding a sentence or two about what Kleppman and Howard show (invariant confluence, iiuc?) so that the reader doesn't have to leave the doc to look it up

[yuval-block]

i'm on the fence on this one, i had a short thing in there, but it seems a bit technical for the overview...

invariant confluence holds for the message domain since we are just dealing with sets closed under union (for which it is trivial), and the validity proofs ensure that no matter what set of messages is collected, maintaining the invariant that the set of messages can be flattened into a transaction that the honest users would not object to signing it so long as some bound on $f$ holds (we can't assume they will be happy if $f = n-2$ for example, defining this bound concretely is in the scope of the cost function's privacy metrics so let's just assume it's a reasonable bound for the sake of discussion)

this is actually a pretty subtle invariant that needs incentive compatibility and is rather insensitive to the state... so i have a detailed account of it in the DAG spec but for here i eventually gave up and just made "Byzantine" italic lol

[yuval-block]

btw if the bound on f doesn't hold - that's the same as not having a counterparties in the coalition formation, so that's an additional reason why clients in practice may place a limit on how many recovery attempts they do and elect to wait longer for market conditions to be more favorable instead of insisting on following through at any cost, but the protocol shouldn't make assumptions about that hence the desire to show that it is at least possible to obtain valid transaction output liveness in O(f) time, even if at the next level of abstraction some attempted coallitions just dissolve.

as far as i know the problem of byzantine fault tolerant coalition formation in non-cooperative games is not generally solvable, i think that follows from similar impossibility results in hedonic games so no sense in even discussing byzantine fault tolerance without defining a class of games for which a stable coalition structure is possible can be ensured where the payoff is always positive, etc. i believe there is a class of hedonic games that treats all agents as at least weakly preferring each others' company but i forget what it's called. i don't know if this has been studied in the setting where a transferrable utility is possible.

also note that treating bitcoin as a transferrable utility is also quite an assumption, i am also not familiar with any work that attempts to kind of reduce coalition formation to bilateral bargaining, all of the work i found always assumes some kind of mechanism that seems to preclude privacy in the permissionless setting. i also found some impossibility results on the optimality of bilateral bargaining i need to find again, which made me give up on trying to show optimality, empirically joinmarket is already good enough for coordinating coinjoins and uses bilateral negotiation so if market efficiency can be improved, which aggregation should support, then that's good enough as far as i'm concerned. in fact your tip a few years ago to read up on combinatorial clock auctions was what kind of prompted that, and inspired confidence that the aggregator role for coalition formation proposals is sufficient, the main difference is that it's not exclusive, which led to the realization that the aggregator should be able to propose arbitrary redistributions of the surplus, so thanks for that.

all this goes to say, ultimately it's up to the market, and while i suspect this can be made much more rigorous through more in depth game theoretical analysis, unlike rigor in regards to privacy i'm much more willing to defer doing that work until after "try it and see" fails to work, because of the evidence that joinmarket works

[afsheenb]

I think I grok why privacy is independent of the TEE ("private allocations remain with participants"). But does that hold against an actively malicious validator? E.g. thinking of a "spy validator" that selectively disseminates/withholds fragments and attempts to correlate acknowledgments with contributions

[yuval-block]

unless i misunderstand then already Kleppman & Howard's BEC, of which everything else is a special case, is byzantine fault tolerant against such behavior as far as preventing dissemination, so the main question is can the adversary force that to be a privacy leak

the answer is definitely yes, much like a network partition forces privacy leaks... there is a tension between liveness and this, otherwise BEC in the async communication model provides the best case for privacy from this privacy and everything on top of it can only try to improve liveness by improving the protocol participant's fidelity of information about who is doing what, which is why i believe this kind of leak is inherent

it can be mitigated to some extent by remembering what you acknowledged and noting that you can use your least compromising input to veto, or least damaging to be censored by if you are coerced into not publishing an output because acknowledgement would single you out as the owner of that input. in this scenario you sacrifice that one input's usability, but get an attempt to try something else instead of internalizing the harm of a privacy leak by insisting on liveness and not being punished.

the pragmatic solution, which i am also working on is to improve the resilience of the gossip layer and ensure honest peers can converge on the messages to include before producing blocks so that the probability of this happenning is pretty controllable if you are not too eager to produce blocks but are eager to gossip your messages anonymously until you are satisfied they have been disseminated. the details of this vary with the transport, for example in connection based channels we are limited to a more or less static local topology, whereas with a transport like nym you can send a message to any peer at any time, so it functions more like a low capacity clique graph or the traditional gossip topology (random telephone call model)

there is also recent work on censorship resistant byzantine broadcast, and related work on prefix consensus but afaict this doesn't actually buy much because the distinction between ackwnoledgement and inclusion that that work mainly pertains to total ordering, and we just need set union... still studying some of this work

[yuval-block]

if you are coerced

sorry, i mean, you just give up on that output to resist that coercsion and suffer the liveness consequences, you aren't actually coerced into the privacy leak

[yuval-block]

i've attempted to clarify this nuance in latest version

[yuval-block]

I disagree. We cannot share this document with broken links. removing the links might be better.

we could drop the links and keep the text

we can also consider create-missing

the reason i would rather go with the broken links is that there's no phrasing changes required, whereas if the text just becomes "Coalition formation is the protocol blah blah blah. In game theory coalition formation means blah blah blah" then it's unclear the first used to be a specific notion, i.e. the coalition formation protocol in the repository, and not just a general statement about game theory which would be incorrect. Addressing that means rephrasing things in ways that i usually am very bad at fixing later, because of dyslexic autocorrect, i remember what it was supposed to say and that's how my brain reads at as. since that kind of mistake will stick around indefinitely whereas a broken link will be repaired once the target is merged it seems like the more sensible option if we do want to merge this (otherwise we can rebase it and not merge until the link targets are ready and still avoid the rephrasing stuff)

Cindy - in the screenshot those look like links... are they just styled text? if so i think having a dashed underline kinda like wikis use for missing articles might be a decent compromise? but also i do expect the broken links to go away once stuff is merged and since mdbook doesn't have functionality for this, it sounds like this complicates the processing significantly more than what we should be doing long term which is #54

[yuval-block]

hmm, maybe the easiest compromise is to start implementing #54, but instead of having it error as a flake check, use it as part of a processing pipeline and just create every link, not just mdbook's create missing (which applies only to the summary) and put a little blurb in there that says that the mdbook is still a WIP and to look at the open PRs for the target page?

[bc1cindy]

did it in #57: links stay as they are, a chapter not merged yet gets a stub with a wip note and its pr, and once it lands in docs/ the same link opens it

this pr needs frontmatter in overview.md, ../ → ./, cost_function_abstract.md → cost_function.md, and $t < n$ fails in katex

please take a look when you can!

[xstoicunicornx]

Only read up to validity proofs so far... planning to get through the rest later today

[arminsabouri]

This last paragraph does seem a bit out of place. Its clear what the purpose of the validity proofs are i n the context of the protocol -- so i did not have this misconception. Maybe move this to a footer?

[yuval-block]

it's such a repeated talking point that's just harmful and wrong "wasabi's inputs are unlinkable because it uses anonymous credentials", i think it has to be addressed so i think i need to clear up what is meant by this paragraph rather than move it

[xstoicunicornx]

I re-jiggered the validity proof section a bit here and I think the last fragment reads better, what do you think?
#51 (comment)

[xstoicunicornx]

some more comments... more coming

edit: sorry if some of the things are not quite accurate.

[xstoicunicornx]

I think this section is a bit meandering and can read a bit better. I mostly just moved paragraphs around but rewrote a bit in the middle.

I removed the oversized fee contribution mention as it didn't seem to tie into validity proofs. If it will also leverage validity proofs we should add it back, otherwise we should add it to the relevant section that will mitigate oversized fee contribution.

---

Validity proofs

The purpose of the validity proofs is to enable the possibility of completion without sacrificing privacy, which is why they are zero-knowledge proofs. They mainly prevent the same funds from being claimed more than once. They do not replace each participant's final approval, nor can they compel any participant into providing the remaining proofs or signatures. They ensure that honest, responsive participants can successfully add all of their intended inputs and outputs to the shared state without obstruction.

Only valid transactions have consequences for the owners of the inputs. The sense in which the fragments themselves must be valid according to the proofs is that when combined they would result in a valid transaction if fully signed. Taken together with the incentive compatibility assumption, the lack of obstruction removes any reason for honest participants to withhold their signatures: by following the protocol the correct destination for all of their funds will be secured. If we also assume consistency of the shared state, validity proofs ensure there is no way to poison the state so the transaction will be invalid. This means the maximally disruptive manipulation that can be performed at zero cost by a malicious participant amounts to withholding a signature.

Using zero-knowledge proofs, each participant can establish to all other participants that their own contributed outputs are covered by input funds without needing to reveal any of their inputs or outputs. This includes payments between participants, and must not reveal the details of how each participant allocates its funds.

While validity proofs enable the possibility of completion without sacrificing privacy, they do not contribute to privacy themselves. All they do is enforce validity, and if done correctly, they can enforce validity without destroying privacy.

[yuval-block]

I removed the oversized fee contribution mention as it didn't seem to tie into validity proofs.

it kinda does, on two levels:

• the proofs cover the fees
• it's the trigger for proving

we have to prove that every sat is accounted for, and the only way to avoid doing the kind of scam kruw is doing with wasabi is for every client to validate that every sat they intended to go to fees provably and accountably does that

and it's not about oversized fee contributions it's that if everyone can observe that they sats they claim to allocate are all there, and no overflow has occurred, there's no need to prove anything, every individual user is happy and everyone has evidence that nobody tried to cheat, so if they can have unanimous agreement about that exact state, signing can just proceed

if there is some kind of imbalance or disagreement, that's when the proofs need to be made and posted, in order to filter out the contentious outputs or fee contributions that are doing the double spending

[xstoicunicornx]

I think this should titled "The honest setting: Interactive transaction construction" and be placed right before "The semi-honest setting" section. I think all 3 overviews of the different "settings" should read one right after another as that adds a lot of clarity.

Or if "Interactivity under different communication models" is supposed to be about honest setting in particular it should be subsection of this one.

[yuval-block]

yeah it's a bit inconsistent... fwiw the reasoning behind that is that the previous section described a state sharing based model, whereas everything from here on down is explicitly based on sending specific kinds of messages maybe it makes sense to discuss that a bit more explicitly in the first paragraph

[yuval-block]

i tried to make the headings a bit more consistent but differently than the suggestion

[xstoicunicornx]

I think "problem statement/definition" broken links definitely need to be resolved by creating it if it doesn't already exist. Seems highly relevant to the overview and referenced in multiple places. Let me know if I should create and issue for tracking this.

Other than the "problem statement/definition" link I agree with @arminsabouri that all broken links should be removed.

[bc1cindy]

@xstoicunicornx the broken links are being fixed in #50 , #57, #59 and #65

[github-actions]

range-diff for force push c3a0f8d3da → c278fa2252 October 19, 2026 19:24 UTC: 1 modified, 1 unchanged

^{reproduce: git range-diff 8ac4434..c3a0f8d 32edbfe..c278fa2}

1:  304120b2d0 = 1:  d20289ee35 Generate SUMMARY.md from an OKF index.md
2:  c3a0f8d3da ! 2:  c278fa2252 Add an overview

2: c3a0f8d3da ! 2: c278fa2252 Add an overview

@@ docs/index.md
 
  ## docs/overview.md (new) ##
 @@
++---
++type: Overview
++title: Fungi protocol overview
++description: Collaborative transaction construction, privacy, fault tolerance and coalition formation.
++status: draft
++stale_after: 2026-10-31T00:00:00Z
++---
++
 +# Fungi protocol overview
 +
 +Fungi is a suite of protocols for collaborative Bitcoin transactions. Its goal is to support interactive payments and net settlement with counterparties, as well as decentralized, market-based CoinJoins with untrusted parties.
 +
-+While the protocols themselves support arbitrary transaction structures, obtaining privacy outcomes is a matter of participants acting in their own self-interest and cooperating with others to achieve the desired results. The [problem definition](../collaborative_txn_privacy.md) describes conditions for a transaction graph to preserve privacy on chain. The repository also discusses the definition of a [cost function](./cost_function_abstract.md) for optimizing for this outcome. That said, the protocols for collaborative transactions summarized in this document are agnostic to the details of such a cost function.
++While the protocols themselves support arbitrary transaction structures, obtaining privacy outcomes is a matter of participants acting in their own self-interest and cooperating with others to achieve the desired results. The [problem definition](./collaborative_txn_privacy.md) describes conditions for a transaction graph to preserve privacy on chain. These conditions are specified in terms of properties of the graph, both the transactions that form it and its overall structure. The repository also discusses the definition of a [cost function](./cost_function_abstract.md) for optimizing for this outcome. That said, the protocols for collaborative transactions summarized in this document are agnostic to the details of such a cost function.
 +
 +Depending on whether peers must be considered adversarial, and the underlying transport mechanisms, different variations of transaction construction are defined. These are the honest, semi-honest (also known as honest-but-curious) and Byzantine settings.
 +
-+In the honest setting, we assume peers can be trusted to follow the protocol and never leak any information apart from the final transaction (deliberately or otherwise). In the semi-honest setting we no longer trust peers with privacy; privacy-preserving transports are used to hide the attribution of different transaction fragments. Finally, in the Byzantine setting we must tolerate arbitrarily malicious behavior from peers.
++In the honest setting, we assume peers can be trusted to follow the protocol and never leak any information apart from the final transaction (deliberately or otherwise). In the semi-honest setting we no longer trust peers with privacy; privacy-preserving transports are used to hide the attribution of different transaction fragments. In the Byzantine setting fault tolerance means tolerating arbitrary and potentially malicious behavior from peers, to the extent possible.
++
++These protocols are designed to allow interactive payments with net settlement. While net settlement on its own is beneficial for privacy in some ways, it does not adequately obscure the community structure that is inherent in real-world economic networks. Randomizing peer selection is one of the requirements for building CoinJoin graphs with the desired privacy enhancing properties.
 +
-+Finally, the [coalition formation](../coalition_formation.md) protocol provides a market-based mechanism to allow mutually distrusting strangers to anonymously start transaction construction together. Randomizing peer selection is a requirement for CoinJoin graphs with the desired privacy properties. Net settlement, while beneficial for privacy, does not obscure the community structure that is inherent in real-world economic networks.
++The last component needed is therefore the [coalition formation](./coalition_formation.md) protocol. It provides a market-based mechanism to allow mutually distrusting strangers to anonymously start an instance of the Byzantine fault tolerant (BFT) transaction construction protocol.
 +
-+## Concurrent PSBTs
++## PSBT concurrency
 +
 +[BIP 174](https://bips.dev/174/) defines Partially Signed Bitcoin Transactions (PSBTs), which allow a device with UTXO data to prepare a transaction for signing on a separate signing device. Signatures can be collected in any order, so multiple signing devices can be used, with a well-defined procedure for how to assemble everything into a signed transaction that can be broadcast.
 +
 +While BIP 174 has been used in several collaborative transaction protocols, as specified it can only represent a fully formed unsigned transaction. [BIP 370](https://bips.dev/370/) extends the format to explicitly allow the input and output lists to be modifiable. The fact that these lists are ordered presents a challenge for concurrent transaction construction.
 +
-+The first component of the Fungi protocol suite is the proposed [Concurrent PSBT specification](../psbt-concurrent.md). It treats these collections as unordered sets rather than lists, allowing fragments to be combined regardless of arrival order, not just when collecting signatures but also when authoring the transaction. A consistent ordering is established before signing.
++The first component of the Fungi protocol suite is the proposed [Concurrent PSBT specification](./psbt-concurrent.md). It treats these collections as unordered sets rather than lists, allowing fragments to be combined regardless of arrival order, not just when collecting signatures but also when authoring the transaction. A consistent ordering is established before signing.
 +
 +In the "sneakernet" setting participants can pass around a single PSBT file, editing it in turn before handing it to the next party, but with concurrent PSBTs they can also concurrently modify different copies and merge them as well. And anything in between. Because divergent copies can be merged into one coherent transaction, the details of communication don't need to be specified; it could be a shared directory on a server, or one or more USB sticks, perhaps files shared over email, or some combination of the above.
 +
@@ docs/overview.md (new)
 +
 +As a result, liveness is inherently brittle. Consistency is a liveness requirement, not a safety requirement, and all of the mechanisms described here are primarily concerned with enhancing liveness without breaking the privacy assurances made to honest participants.
 +
-+## Interactive transaction construction with honest participants
++## Interactive transaction construction in the honest setting
++
++All of the protocols described here, starting with this one, assume interactivity. The PSBT concurrency spec describes how to merge states without specifying how peers communicate, whereas the protocols perscribe specific messages to be exchanged between peers. Some of these messages correspond to unordered PSBT fragments, and can merged according the concurrent PSBT specification.
 +
-+An honest participant is one that complies with the protocol. Faulty peers may deviate by being unresponsive or by being actively malicious. In the honest setting, not only do we assume that the only kind of fault is being unresponsive, but peers are also expected to keep confidential all of the information pertaining to the protocol's execution.
++An *honest* participant is one that complies with the protocol. Faulty peers may deviate from the protocol, by being unresponsive or potentially with arbitrary, possibly malicious behavior. In the honest setting we assume that the only kind of fault is being unresponsive. Not only that, peers are additionally expected to keep confidential all of the information pertaining to the protocol's execution.
 +
-+When we do have some well-defined way to transmit messages from one peer to another, we can start to reason about how synchronization between peers can happen by using interactivity. Communication serves two purposes: peers exchange payment details directly with their counterparties, and send transaction contributions to the group as a whole.
++With some well-defined way to transmit messages from one peer to another, we can start to reason about how synchronization between peers can happen by using interactivity. Communication serves two purposes: peers exchange payment details directly with their counterparties, and send transaction contributions to the group as a whole.
 +
-+For peer-to-peer channels, any transport that provides authentication, integrity and confidentiality may be used. This allows peers to send messages to each other directly, for initiating as well as carrying out transaction construction.
++In order to realize peer-to-peer channels, any transport that provides authentication, integrity and confidentiality may be used. This allows peers to send messages to each other directly, for initiating as well as carrying out transaction construction.
 +
 +Group communication can be built out of peer-to-peer channels; this is known as gossip or rumor-spreading. Alternatively, a specialized broadcast channel implementation can be used. So long as each peer eventually receives all messages sent by every other peer, they will converge on the same transaction fragments, and combine them in the same way to obtain a consistent view of the unsigned transaction.
 +
-+The honest setting accommodates geographically separated multisig wallets, coordination between separately managed funds within an organization, and collaborative batching. Before signing, every participant checks this transaction, ensuring their funds end up in the destinations they intended. Although the model assumes no malicious edits to the transaction, performing these checks is what enforces safety. Doing this ensures that if the assumption does not hold, the system still fails closed, and any faults that aren't explicitly accounted for in the model will only lead to denial of service, not loss of funds. Needless to say, this check applies to the more adversarial settings described below.
++The honest setting accommodates geographically separated co-signers within a multisig wallet, coordination between separately managed funds within an organization, collaborative batching, and interactive payments. Before signing, every participant checks this transaction, ensuring their funds end up in the destinations they intended. Although the model assumes no malicious edits to the transaction, performing these checks is what enforces safety. Doing this ensures that if the assumption does not hold, the system still fails closed, and any faults that aren't explicitly accounted for in the model will only lead to denial of service, not loss of funds. Needless to say, this check also applies to the more adversarial settings described below.
 +
-+## Interactivity under different communication models
++## Net settlement
 +
-+Because of this unanimity condition, a peer which is offline will not be able to sign its inputs. If a subset of participants can all agree that some other peers are faulty, they could recover by restarting transaction construction without those peers' inputs, allowing them to produce a valid transaction without those peers.
++One of the motivating use cases for interactive transaction construction is more efficient and private on-chain payments. Several parties can batch arbitrarily many payments into one transaction. Each participant's inputs and outputs express only the net difference. Individual payment amounts need not appear on chain.
 +
-+Deciding when a peer is unresponsive, the only kind of fault that is tolerated in the honest threat model, largely depends on how messages are transmitted. The distributed systems literature typically divides this into three communication models: asynchrony, partial synchrony and synchrony.[^dls] Each demands a different approach to fault tolerance. These models also apply to the more adversarial settings.
++Net settlement adds both safety and liveness considerations. Before signing, a participant must know that its funds reach the intended destinations. It can check outputs returning funds to itself directly; for a payment, it needs the payee to confirm that the transaction satisfies their agreement. This can add sequential dependencies between peers. Within each payment cycle at least one party will receive as much as it sends or more, and can therefore safely initiate a cascade of confirmations. See the [concurrent PSBT specification](./psbt-concurrent.md#confirmation-of-successful-payment-prior-to-signing) for additional details.
 +
-+### Asynchronous
++## Fault tolerance under different communication models
 +
-+In the asynchronous communication model, messages may be delayed arbitrarily long, so when an expected message fails to arrive, we cannot assume the sender is faulty. This setting is the simplest in which correct behavior can be defined because it makes the weakest guarantees. If we assume all peers are honest, the only recourse is to keep waiting.
++Because of the unanimity condition, a peer which is offline and not able to sign its inputs essentially vetoes the transaction even if not intentionally. Transaction construction therefore naturally has two tracks: the *optimistic track*, which requires unanimity, and the *recovery track*, which facilitates restarting transaction construction with a subset of participants. Recovery is a permissioned instance of the coalition formation protocol described in more detail in the last section of this overview.
 +
-+### Synchronous
++If a subset of participants can all agree that some other peers are faulty, they could recover by restarting transaction construction without those peers' inputs, allowing them to produce a valid transaction without those peers. Deciding when a peer is unresponsive, the only kind of fault that is tolerated in the honest threat model, largely depends on how messages are transmitted. Depending on what can be assumed about message delivery, different guarantees about liveness or fault tolerance can be made.
 +
-+Intuitively, a peer that has been unresponsive for too long can be considered faulty. By adding timeouts, we can recover liveness by simply giving up coordinating with such peers.
++The distributed systems literature typically divides this into three communication models: asynchrony, synchrony, and partial synchrony.[^dls] Each demands a different approach to fault tolerance. These models also apply in the more adversarial settings.
 +
-+The synchronous communication model is typically in play whenever a protocol relies on specific timeout values, i.e. defining how long is "too long". This model assumes that the participants can agree on what time it is, and that all sent messages will arrive no later than some maximal delay. If a message that is expected to arrive fails to do so before the timeout elapses, the peer which was supposed to send is said to experience a crash fault, rendering it unresponsive for the remainder of the protocol, or an omission fault if it was temporarily unavailable and some of its messages were not delivered..
++### Asynchrony
 +
-+Note that such delays may be arbitrarily long, provided their bound is well defined, even if the underlying transport requires interactivity on a shorter time scale. For example, we might use TCP/IP with timeouts on the order of tens of seconds to interact with a store-and-forward service that allows peers to send each other messages with timeouts on the order of hours or days. The model assumed by the underlying transport or its parameters need not agree with the model assumed for transaction construction.
++In the asynchronous communication model, messages may be arbitrarily delayed, so when an expected message fails to arrive, we cannot conclude the sender is faulty because when that happens isn't well defined. This setting is the simplest in which correct behavior can be reasoned about, because it makes the weakest guarantees. If we assume all peers are honest, the only recourse is to keep waiting.
 +
-+### Partial synchrony
++### Synchrony
 +
-+Partial synchrony lies in between. Like the synchronous model, it assumes message delivery is timely, but unlike the synchronous model, the bound on the delay either isn't known or may not always apply, so simply waiting for a timeout duration will not suffice to obtain liveness. Typically this requires acknowledgement from some threshold fraction of participants in order for progress to be made.
++Intuitively, a peer that has been unresponsive for too long can be considered faulty. By adding timeouts, we can recover liveness by simply giving up coordinating with such peers.
 +
-+## Net settlement
++The synchronous communication model is typically in play whenever a protocol relies on specific timeout values, i.e. defining how long is "too long". This model assumes that the participants can agree on what time it is, and that all sent messages will arrive no later than some maximal delay. If a message that is expected to arrive fails to do so before the timeout elapses, the peer which was supposed to send is said to experience a crash fault, rendering it unresponsive for the remainder of the protocol, or an omission fault if it was temporarily unavailable and some of its messages were not delivered.
 +
-+A motivating use case for interactive transaction construction, one of several, is more efficient and private on-chain payments. Several parties can batch arbitrarily many payments into one transaction. Each participant's inputs and outputs express only the net difference. Individual payment amounts need not appear on chain.
++Note that such delays may be arbitrarily long, provided their bound is well defined, even if the underlying transport requires interactivity on a shorter time scale. For example, we might use TCP/IP with timeouts on the order of tens of seconds to interact with a store-and-forward service that allows peers to send each other messages with timeouts on the order of hours or days. The model assumed by the underlying transport or its parameters need not agree with the model assumed for transaction construction.
 +
-+Net settlement adds safety considerations. Before signing, a participant must know that its funds reach the intended destinations. It can check outputs returning funds to itself directly; for a payment, it needs the payee to confirm that the transaction satisfies their agreement. Within each payment cycle at least one party will receive as much as it sends or more, and can therefore safely initiate confirmation. See the [concurrent PSBT specification](../psbt-concurrent.md#confirmation-of-successful-payment-prior-to-signing) for additional details.
++### Partial synchrony
 +
-+## The semi-honest setting: adding privacy-preserving communication
++Partial synchrony lies in between. Like the synchronous model, it assumes message delivery is timely, but unlike the synchronous model, the bound on the delay either isn't known or may not always apply, so simply waiting for a timeout duration will not suffice to obtain liveness. Typically this requires acknowledgement from some threshold fraction of participants in order for progress to be made.
 +
-+An authenticated channel may identify the sender of a message, which can be problematic for privacy. Even if the sender isn't authenticated, transport-related metadata such as IP addresses can leak information about the sender. If transaction fragments are exchanged this way, this can indicate links between inputs and outputs that belong to the same user, even when the final transaction leaves those relationships ambiguous.
++## Transaction construction in the semi-honest setting
 +
 +In the semi-honest setting, participants are still assumed to cooperate, but are no longer trusted with privacy. Instead we assume the adversary can see their observations, regardless of whether this information is leaked accidentally or deliberately shared.[^honest-but-curious] 
 +
-+Preserving privacy requires anonymous broadcast to the group. Overlay networks such as Tor can be used to anonymously send messages to peers for relaying. The privacy guarantees of the underlying transport form the basis of message unlinkability, and once a message is not linked to its owner it can be relayed even on a non-anonymous channel.
++An authenticated channel may identify the sender of a message, which would be problematic for this notion of privacy. Even if the sender isn't authenticated, transport-related metadata such as IP addresses can leak information about the sender. If transaction fragments are exchanged this way, this can indicate links between inputs and outputs that belong to the same user, even when the final transaction would leave those relationships ambiguous to an outside observer. This is an undesirable trust assumption.
++
++Preserving privacy requires anonymous broadcast to the group. Overlay networks such as Tor can be used to anonymously send messages to peers for relaying. The privacy guarantees of the underlying transport form the basis of message unlinkability, and once a message is not linked to its owner it can be relayed even on a non-anonymous channel. While this can also be achieved without external dependencies, for example using DC-nets, this approach does not scale to large numbers of participants, and is hard to make fault tolerant in addition to still revealing transport-related metadata.
 +
 +Payment communication has different requirements, which also must be provided by the underlying transport. A sender must authenticate its receiver and obtain confirmation that the proposed transaction satisfies their agreement. However, this authentication can rely on a one-time code or pseudonym. The receiver doesn't need to authenticate the sender in order to be paid securely. Both counterparties know their payment amount, but need not disclose that relationship to the group or identify their transaction inputs and outputs to one another.
 +
-+The privacy objective is to avoid revealing anything more than what is inherent in the transaction data to the world, and the minimal payment details to counterparties. Anonymous communication is a necessary but insufficient requirement for this; it does not prevent inference from amounts or transaction structure, nor from the wider transaction graph. The on-chain limitations described in the [problem definition](../collaborative_txn_privacy.md) still apply.
++The privacy objective is to avoid revealing anything more than what is inherent in the transaction data to the world, and the minimal payment details to counterparties. Anonymous communication is a necessary but insufficient requirement for this; it does not prevent inference from amounts or transaction structure, nor from the wider transaction graph. The on-chain limitations described in the [problem definition](./collaborative_txn_privacy.md) still apply.
 +
-+This setting is inherently more brittle, because when disruptive messages are shared anonymously not only is it unclear how to recover, in general it isn't possible to tell apart the disruptive messages from the honest ones.
++This setting is inherently more brittle, because when disruptive messages are shared anonymously not only is it unclear how to recover, in general it isn't possible to tell apart the disruptive messages from the honest ones without some additional mechanism.
 +
-+## The Byzantine setting: resilience against malicious behavior
++## Byzantine fault tolerant transaction construction
 +
-+The semi-honest setting assumes that participants claim only what they are entitled to in outputs, and cooperate until the transaction is successfully constructed and signed. While crash faults can be detected depending on the communication model, there are of course many other ways participants can be disruptive, especially if they have malicious goals like preventing the other parties from transacting.[^byzantine-generals]
++The semi-honest setting assumes that participants claim only what they are entitled to in outputs, and cooperate until the transaction is successfully constructed and signed. While crash faults can be detected depending on the communication model, there are of course many other ways participants can be disruptive, especially if they have malicious goals like preventing the other parties from transacting.[^byzantine-generals] A Byzantine fault tolerant (BFT) protocol is one that is resilient to such disruption.
 +
-+Participation is voluntary, and no party can be compelled to sign. The protocol therefore operates in a non-cooperative game-theoretic setting: agreements to transact are not binding, and must be self-enforcing through incentives. We therefore define an honest participant as one which intends to complete the protocol and sign, regardless of which permitted actions the other honest participants choose to take. The agreed conditions must preserve that incentive throughout construction; the coalition formation protocol, discussed at the end of this overview, provides a mechanism for negotiating those conditions and aligning incentives for cooperation. For now we will simply assume that the honest users' incentives are already aligned when transaction construction commences.
++Participation is voluntary, and no party can be compelled to sign. The protocol therefore operates in the non-cooperative game-theoretic setting: any agreement to transact or sign cannot be binding, and must be self-enforcing through incentives in order to have any bearing. We therefore additionally define an honest participant as one which intends to complete the protocol and sign, regardless of which permitted actions the other honest participants choose to take. The agreed conditions must preserve that incentive throughout construction; the coalition formation protocol, discussed at the end of this overview, provides a mechanism for negotiating those conditions and aligning incentives for cooperation. For now we will simply assume that the honest users' incentives are already aligned when transaction construction commences.
 +
-+Under the rules of the semi-honest setting a malicious participant can add outputs exceeding its allocation. Because such outputs would be included as well, in general this may result in an invalid transaction even if it is fully signed. A malicious peer might also equivocate: give conflicting accounts of its actions to different peers. Or it might simply withhold a signature, causing delays. In the Byzantine setting the honest peers must be able to tolerate any such malicious behavior.
++Under the rules of the semi-honest setting a malicious participant might attempt to overspend, causing the combined transaction to be invalid even if if signatures are given for all inputs. A malicious peer might also equivocate: give conflicting accounts of its actions to different peers. Or it might simply withhold a signature, causing delays. In the Byzantine setting the honest peers must be resilient to such disruption. This means ensuring flood protection and fairness.
 +
 +### Optimistic transaction construction
 +
@@ docs/overview.md (new)
 +
 +### Validity proofs
 +
-+Assuming the input set has been finalized, outputs and fee contributions reduce the remaining available funds. If their total cost exceeds the total input value the unsigned transaction will not be valid even if signed, and at least one party is attempting to overspend. Any participant can also anonymously force termination of the optimistic path by adding an oversized fee contribution.
-+
-+Once overspending has been detected, uncertified output and fee contributions are no longer allowed. Instead zero-knowledge proofs establish that outputs are covered by input funds. This includes payments between participants, and must not reveal the details of how each participant allocates its funds.
++The purpose of validity proofs is to restore the possibility of completion by preventing the same funds from being claimed more than once.The proofs establish that outputs and fee contributions are covered by input funds, including any funds that originate from payments between participants. They must accomplish this *without* sacrificing privacy, which is why they must be zero-knowledge proofs. They do not replace each participant's final approval, nor can they compel any participant into providing the remaining proofs or signatures. They ensure that honest, responsive participants can successfully add all of their intended inputs and outputs to the shared state without obstruction.
 +
-+The purpose of the proofs is to restore the possibility of completion *without* sacrificing privacy, which is why they are zero-knowledge proofs. They mainly prevent the same funds from being claimed more than once. They do not replace each participant's final approval, nor can they compel any participant into providing the remaining proofs or signatures. They ensure that honest, responsive participants can successfully add all of their intended inputs and outputs to the shared state without obstruction.
++On the optimistic path, no proofs are needed if every participant can verify that all of its funds are are accounted for in its outputs and fees contributions, and no overspending has occurred, and everyone acknowledges that exact state. Overspending triggers proving so that contentious outputs and fee contributions can be validated. An anonymous, oversized fee contribution permits any participant to abort the optimistic path and force validity proofs to be required.
 +
-+Invalid transactions cannot spend any coins. Only valid transactions have consequences for the owners of the inputs. The sense in which the fragments themselves must be valid according to the proofs is that when combined they would result in a valid transaction if fully signed. Taken together with the incentive compatibility assumption, the lack of obstruction removes any reason for honest participants to withhold their signatures: by following the protocol the correct destination for all of their funds will be secured. And if we also assume consistency of the shared state, validity proofs ensure there is no way to poison the state so the transaction will be invalid, so maximally disruptive manipulation of the shared state amounts to withholding a signature, the only way the malicious participant can ensure a transaction does not have consequences.
++Only valid transactions have consequences for the owners of the inputs, because invalid transaction cannot actually spend any coins, even if fully signed. The sense in which the fragments themselves must be valid according to the proofs is that when combined they would result in a valid transaction if it were fully signed. Taken together with the incentive compatibility assumption, the lack of obstruction removes any reason for honest participants to withhold their signatures: by following the protocol their funds will be sent to the destination they intended, and since this applies to all participants, this removes any valid reason for honest participants to withold their input signatures.
 +
-+A widely circulated misconception is that validity proofs with zero knowledge somehow provide privacy. This is false. All they can do is enforce validity, and if done correctly, they can enforce this without destroying privacy. They cannot contribute to privacy.
++A widely circulated misconception is that validity proofs in such protocols, due to the use of zero knowledge somehow themselves are a source of privacy. This is false. All they can do is enforce validity, and if done correctly, they can enforce this without requiring privacy to be destroyed.
 +
 +### Consistency, liveness and termination in the presence of Byzantine faults
 +
@@ docs/overview.md (new)
 +
 +If a majority of the honest users can agree on a set of inputs and outputs, but one of the honest participants not in this majority still hasn't submitted all of their outputs, then it would rightfully withhold its signatures even if it does come back online. When assuming the asynchronous communication model, this can delay termination indefinitely, and achieving a majority is not sufficient for termination.
 +
-+The validity proofs added in the previous section make it possible to interpret signatures on the inputs as an honest signal, pun intended: signatures are an honest signal because they aren't costless, but may have consequences such as the mining fees if the other parties also sign, and secondly, signatures signal honest participation in the protocol, because the protocol makes it safe for honest participants to broadcast them regardless of the actions of other users.
++Contributing signatures to a transaction that may become valid when fully signed is both an honest signal and a signal of honesty. In the signalling-theory sense, it is not costless, since the transaction may have consequences such as mining fees if the other parties also sign. Contributing signatures *also* signals honesty in the sense defined above: validity proofs make it safe for honest participants to sign regardless of the actions of other users, so they have no reason to withhold their signatures. A which deviates or defects from transaction construction can veto the transaction but at the cost of witholding a signature on at least one of their inputs.
 +
-+What such a majority can provide, therefore, is a mechanism for agreeing on which inputs belong to peers that have failed to complete the protocol. Depending on the communication model, some kind of timeout or recovery condition will be reached, and any inputs for which signatures have not yet been provided can be defined as out of compliance with the protocol. A new transaction construction session can then be attempted, excluding those inputs.
++In lieu of agreement about a transaction, agreement on the available evidence can still support liveness by allowing recovery from a fault. This boils down identifying inputs for which signatures have not yet been received. A missing signature may still eventually arrive, completing the transaction, but to avoid waiting indefinitely, participants can negotiate another transaction construction attempt while continuing to listen for progress in the original one.
 +
-+Under synchrony or partial synchrony (specifically the eventual synchrony variant), if a sufficient threshold of peers can all agree it has been too long, then they can initiate such a recovery session. A threshold of peers agreeing implies a majority of honest peers agreeing. Note that agreement by a majority of honest participants requires a supermajority threshold. A quorum is a set of peers meeting the required agreement threshold. Given $n = 3f+1$ where at most $f$ are faulty, a quorum of $2f+1$ peers will have at least $f+1$ honest peers in it agreeing.
++Under synchrony or partial synchrony (specifically the eventual synchrony variant), if a sufficient threshold of peers can all agree it has been too long, then they can initiate such a recovery session. A threshold of peers agreeing implies a majority of honest peers agreeing. Note that agreement by a majority of honest participants requires a supermajority threshold. A quorum is a set of peers meeting the required agreement threshold. Given $n = 3f+1$ where at most $f$ are faulty, a quorum of $2f+1$ peers will include at least $f+1$ honest peers, a majority within any such quorum.
 +
-+So long as the notion of "too long" is well defined (consistent with the communication model) and agreed by a quorum, if there are $f$ inputs owned by misbehaving peers honest parties should be able to successfully complete a run of the protocol after $O(f)$ attemptsby simply excluding those inputs as it becomes apparent that they are unresponsive.
++So long as the notion of "too long" is well defined (consistent with the communication model) and agreed to by such a quorum, whenever there are up to $f$ inputs owned by faulty peers honest parties should be able to successfully complete a run of the protocol after $O(f)$ attempts by simply excluding those inputs as it becomes apparent that they are disruptive or unresponsive. Even in the worst case this process ensures at least one input can always be excluded.
 +
-+## Synchronization protocol
++If there are more than $f$ faults recovery is still possible but coordinating recovery attempts by identifying the subset of inputs elligible to participate in recovery requires additional assumptions.
 +
-+The abstract synchronization requirements of the previous sections can be realized by a family of related constructions.
++Note that synchronization has consequences for privacy as well, when operating outside of the design parameters. A majority of malicious validators, for example, could disrupt gossip and inclusion of certain messages in order to deanonymize them. In this scenario, the participant which unsuccessfully attempted to anonymously broadcast that message but failed can choose to include it, which would potentially implicate it as the author, or defect from validation in order to avoid acknowledging a state which does not include the message. However, in such a circumstance it would be better to allow outputs to be omitted and to withold signing with one of the inputs in order to reveal as little as possible.
++
++## Synchronizing protocol state
++
++The abstract state sharing requirements of the previous sections can be realized by a family of related constructions.
 +
 +### Byzantine eventual consistency
 +
-+The simplest of these is Byzantine Eventual Consistency by Martin Kleppmann and Heidi Howard.[^bec] In this model, messages, or transaction fragments as in our case, are committed to a [Merklized](https://en.wikipedia.org/wiki/Merkle_tree) causal log. For example, if Alice is adding an output, the output itself would be the payload of her message, and the envelope would contain references to Alice's last message, as well as the messages of other peers, referenced by hash.
++The general starting point is Byzantine Eventual Consistency (BEC) by Martin Kleppmann and Heidi Howard.[^bec] In this model, messages, or transaction fragments as in our case, are committed to a [Merklized](https://en.wikipedia.org/wiki/Merkle_tree) causal log. For example, if Alice is adding an output, the output itself would be the payload of her message, and the envelope would contain references to Alice's last message, as well as the messages of other peers, referenced by hash.
 +
-+In the naive version of their protocol (they describe a more optimized version), whenever a message is received, if the receiving peer does not know what a hash in its references commits to, it will request the preimage from the peer which sent this message, and after a finite number of such recursive queries and round trips it will eventually reach a message it has already seen. Signatures on the messages authenticate their authorship, allowing messages to be relayed via intermediate peers, and for any equivocations to be detectable. If the payloads are subject to validity constraints and merging independently accepting updates preserves these constraints, as Kleppmann and Howard show, this is sufficient for *Byzantine* eventual consistency: loosely speaking, even in the presence of Byzantine nodes, honest peers will eventually converge on the same set of messages.
++In the naive version of their protocol (they describe a more optimized version), whenever a message is received, if the receiving peer does not know what a hash in its references commits to, it will request the preimage from the peer which sent this message, and after a finite number of such recursive queries and round trips it will eventually reach a message it has already seen. Signatures on the messages authenticate their authorship, allowing messages to be relayed via intermediate peers, and for any equivocations to be detectable. If the payloads are subject to validity constraints and merging independently accepted updates preserves these constraints, as Kleppmann and Howard show, this is sufficient for *Byzantine* eventual consistency: loosely speaking, even in the presence of Byzantine nodes, honest peers will eventually converge on the same set of messages.
 +
-+For privacy-preserving transaction construction, the payload should be a list of transaction fragments delivered anonymously to the peer which constructs the message. In BEC, these messages form an unstructured directed acyclic graph (DAG), with each honest peer's messages forming a linked list which also links into the linked lists of other peers. The depths of these lists are not synchronized or bounded.
++For privacy-preserving transaction construction, the payload should be a list of transaction fragments delivered anonymously to the peer which constructs the message. In the general BEC construction, these messages form a directed acyclic graph (DAG), with each honest peer's messages forming a linked list which also links into the linked lists of other peers. BEC itself does not require the depths of these lists to be synchronized or bounded; the block DAG specializations below impose additional structure.
 +
 +Because in our setting they collect several state-related messages submitted by other participants, we'll call these messages blocks, in line with conventions in similar protocols.
 +
 +### Cordial miners inspired invariants
 +
-+Cordial Miners[^cordial-miners] is one of a family of so-called block DAG protocols, which also includes DAG-Rider.[^dag-rider] In these protocols, a fixed set of participants, usually called validators, produce blocks that, similarly to BEC, refer to other validators' blocks, and the consensus protocol involves defining a deterministic function that produces a consistent priority order when blocks conflict, that all honest validators will agree on. The cordiality requirement is that for $n = 3f + 1$ validators, every block at height $h$ will have $t = n - f$ parent blocks with height $h - 1$. In addition to setting up the required thresholds for Byzantine fault-tolerant consistency, this also serves as a flood protection mechanism.
++Cordial miners[^cordial-miners] is one of a family of so-called block DAG consensus protocols.[^dag-rider] In these protocols, a fixed set of participants, usually called validators, produce blocks that, similarly to BEC, refer to other validators' blocks, and the consensus protocol involves defining a deterministic function that produces a consistent priority order when blocks conflict, that all honest validators will agree on. The cordiality requirement is that for $n = 3f + 1$ validators, every block at height $h$ will have $t = n - f$ parent blocks with height $h - 1$. In addition to setting up the required thresholds for Byzantine fault-tolerant consistency, this also serves as a flood protection mechanism.
 +
 +By waiting to reconcile the set of fragments with neighboring peers before building a block, peers can adhere to the cordiality while minimizing the number of blocks sent overall, which is more appropriate for the goal of coming to consensus over a finite sequence of sets with minimal end-to-end latency, as opposed to maximizing throughput and minimizing confirmation latency, which is the more typical design goal for DAG consensus algorithms.
 +
 +Note that these restrictions on the structure still consist of a special case of Kleppmann and Howard's [hash-consed](https://en.wikipedia.org/wiki/Hash_consing) DAG; every block DAG structure is also a valid Byzantine eventual consistency causal log structure. Because of the validity proofs on transaction fragments, and the concurrent PSBT semantics we do not need an ordering but only a set union.
 +
-+Whether or not eventual consistency will suffice for synchronizing a set union depends on the communication model. When it is not sufficient, the blocks which do arrive and their parent blocks can be used to coordinate failure recovery, identifying responsive peers. In any case we do not need to ensure the stronger notion of safety that cordial miners and other such protocols provide, because of the unanimity requirement, and the consensus machinery is only needed for coordinating failure recovery.
++In the optimistic track, borrowing the cordial structure and setting $t = n$ to fulfill the unanimity requirement means that under asynchrony eventual consistency is the best guarantee we could make. Under synchrony or partial synchrony, the more standard $t = 2f + 1$ lets responsive peers coordinate the recovery track. Note that in principle $t$ could be lowered further, for partition tolerance or recovery in the presence of a dishonest majority, but this is a substantial qualitative difference in guarantees and so it has not yet been explored.
 +
-+### Fault tolerance as branched execution
++### Fault tolerance via branched execution
 +
-+Under asynchrony and in the presence of (Byzantine) faults, due to the unanimity requirement the best consistency guarantee that can be made is eventual consistency. No liveness guarantee can be made in the presence of faults for a particular run of the transaction construction protocol because liveness relies on starting a new protocol, and that requires some kind of synchronization between the honest peers.
++Somewhat surprisingly, the optimistic track and the recovery track can both proceed more or less independently.
++
++Under asynchrony and in the presence of (Byzantine) faults, due to the unanimity requirement the best consistency guarantee that can be made for the optimistic track is eventual consistency. No liveness guarantee is possible in the presence of faults for a particular run of the transaction construction protocol.
 +
 +Recall that when multiple transactions attempt to spend some of the same coins, it is up to miners to determine which one (if any) will be confirmed in a block. Miners are assumed to follow their incentives, maximizing fee revenues. Even if transaction replacement wasn't useful or desirable, there is no mechanism that can enforce that unspent outputs are exclusively bound to one transaction construction session over another without *global* consensus.
 +
@@ docs/overview.md (new)
 +
 +Since input exclusivity is neither desirable nor enforceable, we can embrace its absence and reframe liveness in a simpler way by treating all failure recovery as branching off another instance of the protocol with a subset of the participants precisely when that subset of the participants can agree among themselves that a failure condition has been detected. Such agreement inherently requires synchrony or partial synchrony, and so explains why this is needed for fault tolerance. In this case the blocks at some height $h$ with $t < n$ parent blocks will be produced as part of the recovery synchronization protocol on top of which a new transaction construction session will commence. If messages are delivered allowing a block at height $h$ to be produced with $t = n$ messages, the asynchronous base protocol can resume progress resulting in the diverging protocol states at height $h$. This special case has the same structure as all-to-all broadcast.
 +
++Since recovery is just permissioned coalition formation, any participant may act as an aggregator and make a coalition formation proposal based on its local view; the proposed participants must all accept before it starts. Membership changes can alter anonymity or payment terms, so participants may renegotiate or decline.
++
 +The reason this framing is simpler is that recovery attempts do not need to terminate the run of the protocol that they are trying to recover. In the case that both branches eventually succeed, Bitcoin itself will adjudicate the conflicting transactions. We can treat failure recovery as a (more) synchronous layer building on a fundamentally asynchronous optimistic base protocol with BEC semantics.
 +
-+### Centralization spectrum and TEE-based liveness
++### Centralization spectrum and optional TEE-based liveness
 +
-+All participants can submit their transactions to a designated validator, with all other validators' blocks simply acknowledging the designated validator's blocks. 
++All participants can submit their transaction fragments to a designated validator, with all other validators' blocks simply acknowledging the designated validator's blocks. These acknowledgements can have empty payloads, concentrating collection and validation work on one peer. 
 +
-+In principle, it is possible to decouple the validator role from the participant role and setting $n = 1$, where blocks form a linked list. This instantiates a version of the protocol based on a trusted coordinator. Note that "trust" here is meant only with regard to liveness, not to privacy. If a coordinator is trusted with privacy, which is the norm for such services,[^trusted-coordinators] validity proofs and anonymous broadcast are little more than privacy theater. A centralized protocol where the server simply does not keep a permanent record would be strictly better because users would be informed and computational and bandwidth resources would not be pointlessly wasted, degrading reliabiliy (which itself a privacy concern).
++In principle, it is possible to decouple the validator role from the participant role, with one validator serving many transaction participants. That validator's blocks form a linked list. This instantiates a version of the protocol based on a trusted coordinator. Note that "trust" here is meant only with regard to liveness, not to privacy. If a coordinator is trusted with privacy, which is the norm for such services,[^trusted-coordinators] validity proofs and anonymous broadcast are little more than privacy theater. A centralized protocol where the server simply does not keep a permanent record would be strictly better because users would be informed and computational and bandwidth resources would not be pointlessly wasted, degrading reliability (which is itself a privacy concern).
 +
-+Note that this does not actually require $n = 1$ to shift the communication and coordination complexity onto a more powerful node; clients who choose to follow a particular attested state can still submit acknowledgements to it, and simply echo the parent block set commitments of the attested blocks when acknowledging the same height with minimal communication complexity. Therefore there is no need to actually decouple those roles, it is sufficient to just shift the workload to one validator, unless such a validator is not itself a participant in the transaction.
++Note that centralizing the bulk of this communication and coordination work on one node does not require decoupling the validator and participant roles, nor does it confer any special priviliges to this de-facto leader; on the DAG model participants which only acknowledge the blocks of a single peer, can make those acknwoledgement in the form of blocks that echo the content bearing blocks with minimal communication complexity. No protocol modifications so long as this validator is still a participant in the transaction, and only the introduction of a validator that is not a participant would require these roles to be decoupled.
 +
-+A trusted execution environment (TEE) can shift this trust assumption from the service operator to the hardware vendor and its attestation infrastructure. Attestation provides verifiable evidence that designated validation code executed in the claimed protected environment. Clients can therefore accept its validation of the protocol state without trusting the operator to execute that code faithfully, instead trusting the vendor’s hardware isolation and attestation guarantees. This additional trust assumption can improve liveness and consistency under weaker quorum assumptions, while reducing clients’ validation work. It does not relax the requirement for unanimous transaction signing; private allocations and spending authority remain with the participants.
++Going futher, a trusted execution environment (TEE) can shift trust assumptions from a participant to the the hardware vendor on which the participant is running the protocol. Such a participant can produce attestations about exactly what code is being exceuted in the TEE enclave, which the other participants can verify. Clients could therefore accept its validation of the protocol state without trusting the operator to execute that code faithfully, instead trusting the vendor’s hardware isolation and attestation guarantees.
 +
-+This has two primary advantages. The first is that bandwidth or compute restricted devices can participate asymmetrically in dissemination, validation, etc. If the trust assumption fails, that is still only a liveness violation, and doesn't compromise on safety or privacy. Presumably such clients are too constrained for scalable Byzantine fault tolerance. On the other hand, if the TEE assumption holds, liveness can tolerate a dishonest majority allowing successful termination after $O(f)$ attempts even if $f = n - 2$ (note that $f = n - 1$ holds trivially, that's just falling back to a unilateral transaction).
++The reason such an additional trust assumption may be desired in some circumstances is that it improve liveness and consistency under weaker quorum assumptions, while reducing clients’ validation work further. This does not relax the requirement for unanimous transaction signing, nor is the TEE trusted with protecting privacy; private allocations and spending authority remain with the participants and their messages must remain unlinkable. This provides an alternative path to linveness when clients are too constrained for scalable Byzantine fault tolerance, or when the conditions for Byzantine fault tolerance don't hold (for example a dishonest majority of validators).
 +
-+In other words, using essentially the same unmodified block DAG structure we can accommodate multiple communication models and trust assumptions, to accommodate a variety of client capabilities.
++In other words, using essentially the same unmodified block DAG structure we can accommodate multiple communication models and trust assumptions, to accommodate a variety of client capabilities and circumstances.
 +
 +## Coalition formation
 +
@@ docs/overview.md (new)
 +
 +The [coalition formation](./coalition_formation.md) protocol is designed to allow mutually distrusting strangers to bootstrap transaction construction using a market-based mechanism. Coalition formation games, in game theory, typically refer to the cooperative game theory setting, where agreements are binding and can be enforced by some kind of mechanism. While Bitcoin can provide such a construct, analogously to the function of the court system, the current consensus rules require some kind of contract to be anchored in a confirmed transaction, i.e. binding agreements require creating new transactions and waiting for them to confirm.[^coinswap] In order to build transactions without having already built transactions, we must therefore assume the non-cooperative setting. Coalition formation in the non-cooperative setting can only rely on incentives.
 +
-+When preferences over the coalition structure are in play (the cost function), in so-called hedonic games, it is often very hard (also in an algorithmic sense) to find stable coalition structures, as the preferences of the participants may conflict. In their most general form, such game descriptions are enormous as the preferences are defined over a large combinatorial object but even when many assumptions are made, like constraining the kinds of preferences the participants may have, it is still generally hard to find stable equilibria.[^hedonic] Complicating matters further, sharing the preferences would itself be a privacy leak, so we would prefer to limit that as much as possible, and certainly we cannot assume a mechanism that optimizes outcomes by just being able to read these preferneces.
++When preferences over the coalition structure are in play (the cost function), in so-called hedonic games, it is often very hard (also in an algorithmic sense) to find stable coalition structures, as the preferences of the participants may conflict. In their most general form, such game descriptions are enormous as the preferences are defined over a large combinatorial object. Even when many assumptions are made, like constraining the kinds of preferences the participants may have, it is still generally hard to find stable equilibria.[^hedonic] Complicating matters further, sharing the preferences would itself be a privacy leak, so we would prefer to limit that as much as possible, and certainly we cannot assume a mechanism that optimizes outcomes by just being able to read these preferences.
 +
-+Fortunately, some of these difficulties of hedonic games can be bypassed with the introduction of a transferable utility, and assigning the coalition itself a payoff, which can be redistributed. In our use case this payoff originates from any blockspace savings from net settlement, and the privacy benefits from collaboration. This surplus is not observable, it is the sum of subjective payoffs depending on individual participants' preferences (which in turn depend on their circumstances, privacy threat model, etc). While this does not guarantee stability, if a stable coalition structure exists, a transferable utility can make the process of finding one much easier by iterated bilateral negotiation. However much these benefits are worth it to participants, if this surplus exists, then it can be voluntarily redistributed as sats among the participants (i.e. via a fee mechanism) aligning incentives for collaborative transaction construction, so that all coalition members stand to gain from participating.
++Fortunately, some of these difficulties of hedonic games can be bypassed with the introduction of a transferable utility, and assigning the coalition itself a payoff, which can be redistributed. In our use case this payoff originates from any blockspace savings from net settlement, and the privacy benefits from collaboration. This surplus is not observable, it is the sum of subjective payoffs depending on individual participants' preferences (which in turn depend on their circumstances, privacy threat model, etc). While this does not guarantee stability, if a stable coalition structure exists, a transferable utility can make the process of finding one much easier by iterated bilateral negotiation. However much these benefits are worth to participants, if this surplus exists, then it can be voluntarily redistributed as sats among the participants (i.e. via a fee mechanism) aligning incentives for collaborative transaction construction, so that all coalition members stand to gain from participating.
 +
-+This is exactly the mechanism that the coalition formation protocol attempts to build: co-spend proposals are anonymous and confidential proposals, each of which is a bundle of bilateral agreements between the proposer and the owner of the other UTXOs listed in the proposal. The distinguishing feature of co-spend proposals is that they can be aggregated together, which generalizes a JoinMarket-like fee mechanism: it allows multiple "takers" to pay a single "maker" as a kind of group buy, as well as multiple independent "makers", all in the same transaction. This generality means that the distinction between taker and maker is removed; any participant can play both roles in a single transaction, depending on the co-spend proposals it makes or accepts.
++This is exactly the mechanism that the coalition formation protocol attempts to build: co-spend proposals are anonymous and confidential proposals, each of which is a bundle of bilateral agreements between the proposer and the owners of the other UTXOs listed in the proposal. The distinguishing feature of co-spend proposals is that they can be aggregated together, which generalizes a JoinMarket-like fee mechanism: it allows multiple "takers" to pay a single "maker" as a kind of group buy, as well as multiple independent "makers", all in the same transaction. This generality means that the distinction between taker and maker is removed; any participant can play both roles in a single transaction, depending on the co-spend proposals it makes or accepts.
 +
-+Coalition formation proposals bundle together a collection of co-spend proposals, each of which has been unanimously accepted. Unanimous acceptance of a coalition formation proposal by the owners of all inputs named in all proposals kicks off the permissioned transaction construction with an initial set of inputs, and the terms of the aggregated co-spend proposals in effect. The aggregator role is undertaken by peers which proposing coalition formation proposals.
++Coalition formation proposals bundle together a collection of co-spend proposals, each of which has been unanimously accepted. Unanimous acceptance of a coalition formation proposal by the owners of all inputs named in all proposals kicks off the permissioned transaction construction with an initial set of inputs, and the terms of the aggregated co-spend proposals in effect. The aggregator role is undertaken by peers proposing coalition formation proposals.
 +
 +[^safety-liveness]: B. Alpern and F. B. Schneider, [*Defining Liveness*](https://www.cs.cornell.edu/fbs/publications/85-650.pdf) (1985). Formal definitions of safety and liveness, and their decomposition of system properties.
 +

[yuval-block]

Since there were many unresolved comments i took the liberty of resolving the ones i felt were obvious but left the ones that i was less sure about unresolved, @arminsabouri @afsheenb @xstoicunicornx if you don't mind please take a look at your still unresolved comments and resolving if i've managed to address your feedback

[github-actions]

range-diff for force push c278fa2252 → e341018a9c October 19, 2026 19:51 UTC: 1 unchanged, 1 dropped

^{reproduce: git range-diff 32edbfe..c278fa2 344b072..e341018}

1:  d20289ee35 < -:  ---------- Generate SUMMARY.md from an OKF index.md
2:  c278fa2252 = 1:  e341018a9c Add an overview

[github-actions]

range-diff for force push e341018a9c → fd3cc4b9ad October 19, 2026 19:57 UTC: 1 modified

^{reproduce: git range-diff 344b072..e341018 344b072..fd3cc4b}

1:  e341018a9c ! 1:  fd3cc4b9ad Add an overview

1: e341018a9c ! 1: fd3cc4b9ad Add an overview

@@ docs/overview.md (new)
 +
 +## Interactive transaction construction in the honest setting
 +
-+All of the protocols described here, starting with this one, assume interactivity. The PSBT concurrency spec describes how to merge states without specifying how peers communicate, whereas the protocols perscribe specific messages to be exchanged between peers. Some of these messages correspond to unordered PSBT fragments, and can merged according the concurrent PSBT specification.
++All of the protocols described here, starting with this one, assume interactivity. The PSBT concurrency spec describes how to merge states without specifying how peers communicate, whereas the protocols prescribe specific messages to be exchanged between peers. Some of these messages correspond to unordered PSBT fragments, and can merged according the concurrent PSBT specification.
 +
 +An *honest* participant is one that complies with the protocol. Faulty peers may deviate from the protocol, by being unresponsive or potentially with arbitrary, possibly malicious behavior. In the honest setting we assume that the only kind of fault is being unresponsive. Not only that, peers are additionally expected to keep confidential all of the information pertaining to the protocol's execution.
 +
@@ docs/overview.md (new)
 +
 +On the optimistic path, no proofs are needed if every participant can verify that all of its funds are are accounted for in its outputs and fees contributions, and no overspending has occurred, and everyone acknowledges that exact state. Overspending triggers proving so that contentious outputs and fee contributions can be validated. An anonymous, oversized fee contribution permits any participant to abort the optimistic path and force validity proofs to be required.
 +
-+Only valid transactions have consequences for the owners of the inputs, because invalid transaction cannot actually spend any coins, even if fully signed. The sense in which the fragments themselves must be valid according to the proofs is that when combined they would result in a valid transaction if it were fully signed. Taken together with the incentive compatibility assumption, the lack of obstruction removes any reason for honest participants to withhold their signatures: by following the protocol their funds will be sent to the destination they intended, and since this applies to all participants, this removes any valid reason for honest participants to withold their input signatures.
++Only valid transactions have consequences for the owners of the inputs, because invalid transaction cannot actually spend any coins, even if fully signed. The sense in which the fragments themselves must be valid according to the proofs is that when combined they would result in a valid transaction if it were fully signed. Taken together with the incentive compatibility assumption, the lack of obstruction removes any reason for honest participants to withhold their signatures: by following the protocol their funds will be sent to the destination they intended, and since this applies to all participants, this removes any valid reason for honest participants to withhold their input signatures.
 +
 +A widely circulated misconception is that validity proofs in such protocols, due to the use of zero knowledge somehow themselves are a source of privacy. This is false. All they can do is enforce validity, and if done correctly, they can enforce this without requiring privacy to be destroyed.
 +
@@ docs/overview.md (new)
 +
 +If a majority of the honest users can agree on a set of inputs and outputs, but one of the honest participants not in this majority still hasn't submitted all of their outputs, then it would rightfully withhold its signatures even if it does come back online. When assuming the asynchronous communication model, this can delay termination indefinitely, and achieving a majority is not sufficient for termination.
 +
-+Contributing signatures to a transaction that may become valid when fully signed is both an honest signal and a signal of honesty. In the signalling-theory sense, it is not costless, since the transaction may have consequences such as mining fees if the other parties also sign. Contributing signatures *also* signals honesty in the sense defined above: validity proofs make it safe for honest participants to sign regardless of the actions of other users, so they have no reason to withhold their signatures. A which deviates or defects from transaction construction can veto the transaction but at the cost of witholding a signature on at least one of their inputs.
++Contributing signatures to a transaction that may become valid when fully signed is both an honest signal and a signal of honesty. In the signalling-theory sense, it is not costless, since the transaction may have consequences such as mining fees if the other parties also sign. Contributing signatures *also* signals honesty in the sense defined above: validity proofs make it safe for honest participants to sign regardless of the actions of other users, so they have no reason to withhold their signatures. A which deviates or defects from transaction construction can veto the transaction but at the cost of withholding a signature on at least one of their inputs.
 +
 +In lieu of agreement about a transaction, agreement on the available evidence can still support liveness by allowing recovery from a fault. This boils down identifying inputs for which signatures have not yet been received. A missing signature may still eventually arrive, completing the transaction, but to avoid waiting indefinitely, participants can negotiate another transaction construction attempt while continuing to listen for progress in the original one.
 +
@@ docs/overview.md (new)
 +
 +So long as the notion of "too long" is well defined (consistent with the communication model) and agreed to by such a quorum, whenever there are up to $f$ inputs owned by faulty peers honest parties should be able to successfully complete a run of the protocol after $O(f)$ attempts by simply excluding those inputs as it becomes apparent that they are disruptive or unresponsive. Even in the worst case this process ensures at least one input can always be excluded.
 +
-+If there are more than $f$ faults recovery is still possible but coordinating recovery attempts by identifying the subset of inputs elligible to participate in recovery requires additional assumptions.
++If there are more than $f$ faults recovery is still possible but coordinating recovery attempts by identifying the subset of inputs eligible to participate in recovery requires additional assumptions.
 +
-+Note that synchronization has consequences for privacy as well, when operating outside of the design parameters. A majority of malicious validators, for example, could disrupt gossip and inclusion of certain messages in order to deanonymize them. In this scenario, the participant which unsuccessfully attempted to anonymously broadcast that message but failed can choose to include it, which would potentially implicate it as the author, or defect from validation in order to avoid acknowledging a state which does not include the message. However, in such a circumstance it would be better to allow outputs to be omitted and to withold signing with one of the inputs in order to reveal as little as possible.
++Note that synchronization has consequences for privacy as well, when operating outside of the design parameters. A majority of malicious validators, for example, could disrupt gossip and inclusion of certain messages in order to deanonymize them. In this scenario, the participant which unsuccessfully attempted to anonymously broadcast that message but failed can choose to include it, which would potentially implicate it as the author, or defect from validation in order to avoid acknowledging a state which does not include the message. However, in such a circumstance it would be better to allow outputs to be omitted and to withhold signing with one of the inputs in order to reveal as little as possible.
 +
 +## Synchronizing protocol state
 +
@@ docs/overview.md (new)
 +
 +In principle, it is possible to decouple the validator role from the participant role, with one validator serving many transaction participants. That validator's blocks form a linked list. This instantiates a version of the protocol based on a trusted coordinator. Note that "trust" here is meant only with regard to liveness, not to privacy. If a coordinator is trusted with privacy, which is the norm for such services,[^trusted-coordinators] validity proofs and anonymous broadcast are little more than privacy theater. A centralized protocol where the server simply does not keep a permanent record would be strictly better because users would be informed and computational and bandwidth resources would not be pointlessly wasted, degrading reliability (which is itself a privacy concern).
 +
-+Note that centralizing the bulk of this communication and coordination work on one node does not require decoupling the validator and participant roles, nor does it confer any special priviliges to this de-facto leader; on the DAG model participants which only acknowledge the blocks of a single peer, can make those acknwoledgement in the form of blocks that echo the content bearing blocks with minimal communication complexity. No protocol modifications so long as this validator is still a participant in the transaction, and only the introduction of a validator that is not a participant would require these roles to be decoupled.
++Note that centralizing the bulk of this communication and coordination work on one node does not require decoupling the validator and participant roles, nor does it confer any special privileges to this de-facto leader; on the DAG model participants which only acknowledge the blocks of a single peer, can make those acknwoledgement in the form of blocks that echo the content bearing blocks with minimal communication complexity. No protocol modifications so long as this validator is still a participant in the transaction, and only the introduction of a validator that is not a participant would require these roles to be decoupled.
 +
-+Going futher, a trusted execution environment (TEE) can shift trust assumptions from a participant to the the hardware vendor on which the participant is running the protocol. Such a participant can produce attestations about exactly what code is being exceuted in the TEE enclave, which the other participants can verify. Clients could therefore accept its validation of the protocol state without trusting the operator to execute that code faithfully, instead trusting the vendor’s hardware isolation and attestation guarantees.
++Going further, a trusted execution environment (TEE) can shift trust assumptions from a participant to the the hardware vendor on which the participant is running the protocol. Such a participant can produce attestations about exactly what code is being executed in the TEE enclave, which the other participants can verify. Clients could therefore accept its validation of the protocol state without trusting the operator to execute that code faithfully, instead trusting the vendor’s hardware isolation and attestation guarantees.
 +
 +The reason such an additional trust assumption may be desired in some circumstances is that it improve liveness and consistency under weaker quorum assumptions, while reducing clients’ validation work further. This does not relax the requirement for unanimous transaction signing, nor is the TEE trusted with protecting privacy; private allocations and spending authority remain with the participants and their messages must remain unlinkable. This provides an alternative path to linveness when clients are too constrained for scalable Byzantine fault tolerance, or when the conditions for Byzantine fault tolerance don't hold (for example a dishonest majority of validators).
 +

[github-actions]

range-diff for force push fd3cc4b9ad → dc99513d04 October 19, 2026 21:43 UTC: 1 unchanged

^{reproduce: git range-diff 344b072..fd3cc4b b3e699e..dc99513}

1:  fd3cc4b9ad = 1:  dc99513d04 Add an overview

[xstoicunicornx]

Overall its ACK from me.

Highlighted the remaining feedback that I think was missed.

The one thing I feel strongly about is that the 3 settings have the same heading pattern (leading with the setting name) and should be grouped together to make it intuitive to the reader that these are the 3 different settings in which fungi operates under.

[xstoicunicornx]

I think old title of "The semi-honest setting: adding privacy-preserving communication" was better. Transaction construction is kinda a given for entire fungi protocol, and "adding privacy-preserving communication" does a good job highlighting the the main difference between honest and semi-honest setting.

If you'd rather not use the old title it should at least match format of "Byzantine fault tolerant transaction construction" (ie Semi-honest setting transaction construction).

[xstoicunicornx]

Suggested change

The purpose of validity proofs is to restore the possibility of completion by preventing the same funds from being claimed more than once.The proofs establish that outputs and fee contributions are covered by input funds, including any funds that originate from payments between participants. They must accomplish this *without* sacrificing privacy, which is why they must be zero-knowledge proofs. They do not replace each participant's final approval, nor can they compel any participant into providing the remaining proofs or signatures. They ensure that honest, responsive participants can successfully add all of their intended inputs and outputs to the shared state without obstruction.

The purpose of validity proofs is to restore the possibility of completion by preventing the same funds from being claimed more than once. The proofs establish that outputs and fee contributions are covered by input funds, including any funds that originate from payments between participants. They must accomplish this *without* sacrificing privacy, which is why they must be zero-knowledge proofs. They do not replace each participant's final approval, nor can they compel any participant into providing the remaining proofs or signatures. They ensure that honest, responsive participants can successfully add all of their intended inputs and outputs to the shared state without obstruction.

[xstoicunicornx]

Are you saying that the only path to forcing validity proofs to be required is overspending triggering validation, and then through validation an oversized fee contribution permits any participant to abort optimistic path? Or that either overspending or oversized fee contribution can abort optimistic path and force validity proofs?

From your response #51 (comment) it seems like the former. I think its worth being a bit more verbose here to incorporate some of the context you gave in this response.

[xstoicunicornx]

I still think my version reads better:

Suggested change

	A widely circulated misconception is that validity proofs in such protocols, due to the use of zero knowledge somehow themselves are a source of privacy. This is false. All they can do is enforce validity, and if done correctly, they can enforce this without requiring privacy to be destroyed.
	While validity proofs restore the possibility of completion without sacrificing privacy, they do not contribute to privacy themselves. All they do is enforce validity, and if done correctly, they can enforce validity without destroying privacy.

[xstoicunicornx]

"Honest setting transaction construction" is more consistent with BFT heading. I think putting the "transaction construction" in the front buries the lede (especially since thats the redundant-ish part that all settings relate too).

[xstoicunicornx]

Where are these equations pulled from?

[xstoicunicornx]

The cordiality requirement is that for $n = 3f + 1$ validators, every block at height $h$ will have $t = n - f$ parent blocks with height $h - 1$.

I guess I don't understand how height and parent blocks tie together? They seem to not have a relationship in the given equations?