Use more consistent terms

- s/quorum/coalition/ - in distributed systems "quorum" usually means a
  subset of size f+1, not the entire set. Coalition proposals concern
  all parties, and therefore their name should indicate that and avoid
  being misleading.

- consistency: s/listen announcements/listen advertisements/

Author: nothingmuch

02_coalition_formation.md

@@ -12,7 +12,7 @@ This isn't a transaction construction protocol (e.g. WabiSabi), but a precursor
 
 ## Overview of proposed solution
 
-This document describes a permissionless, peer-to-peer protocol for negotiating collaborative transaction construction. This takes place over two primary phases: bilateral negotiation, followed by aggregation. Successful execution of the protocol results in a quorum of UTXO owners unanimously deciding to build a transaction together.
+This document describes a permissionless, peer-to-peer protocol for negotiating collaborative transaction construction. This takes place over two primary phases: bilateral negotiation, followed by aggregation. Successful execution of the protocol results in a coalition of UTXO owners unanimously deciding to build a transaction together.
 
 ### Bilateral negotiation
 
@@ -28,7 +28,7 @@ Co-spend proposals aren't exclusive. Many proposals can be aggregated together b
 
 Fully accepted proposals can be broadcast and then aggregated with other compatible proposals. Aggregation makes it possible for multiple participants to simultaneously optimize their outcome according to their individual preferences. When they value privacy, this is a positive sum interaction and aggregation optimizes the generated surplus.
 
-To aggregate, several proposals are bundled together with a *quorum proposal* that all parties must agree to. Unanimous acceptance of such a quorum proposal signals that everyone is ready to construct a transaction.
+To aggregate, several proposals are bundled together with a *coalition proposal* that all parties must agree to. Unanimous acceptance of such a coalition proposal signals that everyone is ready to construct a transaction.
 
 Because transactions are only valid if all inputs are signed, multiparty transactions require unanimous agreement. A precondition for denial of service protection in privacy preserving multiparty transaction construction protocols is incentive compatibility for the honest participants. No honest participant should have a reason to withold their signature.
 
@@ -46,7 +46,7 @@ Fortunately, the introduction of a transferrable utility greatly simplifies find
 
 ### Transaction construction liveness assumptions
 
-For a quorum of $n \leq N$ peers, $f$ of which are adversarial, liveness for transaction construction can be achieved (with privacy) by the honest subset of peers in $O(f)$ time. Any defection requires transaction construction to start over. Due to random network disruptions, necessarily some rate of (apparent) defection must be tolerated.
+For a coalition of $n \leq N$ peers, $f$ of which are adversarial, liveness for transaction construction can be achieved (with privacy) by the honest subset of peers in $O(f)$ time. Any defection requires transaction construction to start over. Due to random network disruptions, necessarily some rate of (apparent) defection must be tolerated.
 
 Because exclusivity of spending attempts by inputs can't be enforced without global consensus, and because transaction replacement is desirable for fee market efficiency, we assume inputs are allowed to participate in concurrent sessions, which will result in conflicting transactions. Opt-in signalling can be used and obeyed as a courtesy, but this ultimately reduces to the same liveness model as transaction construction, potentially requiring additional attempts to recreate the transaction.
 
@@ -72,7 +72,7 @@ For all Bob knows, either Carol or Alice made the proposal, and the same goes fo
 
 Carol also wishes to CoinJoin with Alice and Dave. She creates a co-spend proposal with UTXOs $\{ A, C, D \}$, and adjusts $C$ down by 50 sats, $A$ up by 20, and $D$ up by 30. This too is unanimously accepted and broadcast.
 
-Dave then notices both proposals are compatible, and chooses to aggregate them together. He produces a quorum proposal, which depends on these two proposals. The quorum proposal chooses a specific feerate, among other things, combining the constraints of both previous proposals. It names $\{ A, B, C, D \}$ as the UTXOs.
+Dave then notices both proposals are compatible, and chooses to aggregate them together. He produces a coalition proposal, which depends on these two proposals. The coalition proposal chooses a specific feerate, among other things, combining the constraints of both previous proposals. It names $\{ A, B, C, D \}$ as the UTXOs.
 
 Once all parties accept Dave's proposal, consensus has been bootstrapped. Everyone can derive the same total adjustments: $A - 80$, $B + 50$, $C + 0$, $D + 30$. In general, only the owner of each coin knows their final adjustment, but in this example, Carol knows that Dave obtained $+30$ because her proposal is the only one that applies to his coin, and likewise Alice knows Bob obtained $+50$.
 
@@ -110,9 +110,9 @@ If the online keys are generated by hash chain (similar to LN revocation keys),
 
 Similarly, rate limiting could be done by restricting the rate of broadcast on the basis of the committed block hash, but on its own, this wouldn't establish a precedence order, and in the absence of consensus on the set of ownership proofs, it may result in ambiguities about which online key to use.
 
-### Negotiation: Listen announcements and/or gossip of partially accepted proposals
+### Negotiation: Listen advertisements and/or gossip of partially accepted proposals
 
-Short-lived listen announcements may be signed by "makers" using their online keys to indicate that the owner of a UTXO is soliciting proposals pertaining to its spending over the named communication channel. Peers should only gossip listen announcements for currently active or soon-to-be-active online keys. The hash of the signature is used as a flood protection mechanism, similar to ownership proofs.
+Short-lived listen advertisements may be signed by "makers" using their online keys to indicate that the owner of a UTXO is soliciting proposals pertaining to its spending over the named communication channel. Peers should only gossip listen advertisements for currently active or soon-to-be-active online keys. The hash of the signature is used as a flood protection mechanism, similar to ownership proofs.
 
 "Takers" evaluate listening coins and can construct proposals (defined in the next section) over the specified communication channels.
 
@@ -134,11 +134,11 @@ Finally, for a proposal to be fully accepted, the $n$ linkable ring signatures a
 
 Fully accepted proposals can then be broadcast for aggregation. A fully accepted proposal indicates that all owners of the specified UTXOs have some interest in this proposal being in effect.
 
-Individual proposals commit to a specific set of BIP 322 ownership proofs so that the signatures on them are verifiable. Proposals that refer to expired ownership proofs are still considered valid, and more generally, proposals that commit to different ownership proofs are potentially valid as long there is a non-expired ownership proof associated with the UTXO, which is also used for input weight estimations. See the quorum proposal section below for details.
+Individual proposals commit to a specific set of BIP 322 ownership proofs so that the signatures on them are verifiable. Proposals that refer to expired ownership proofs are still considered valid, and more generally, proposals that commit to different ownership proofs are potentially valid as long there is a non-expired ownership proof associated with the UTXO, which is also used for input weight estimations. See the coalition proposal section below for details.
 
 Co-spend proposals aren't updatable or revocable once fully accepted, but they do have an expiry (specified in block height, MTU, or UTC time). More than one signature on the same proposal should be considered a flooding attack by all participants, and honest parties should only sign (MuSig2) a proposal once. Again, see below for discussion of flood protection with respect to partially accepted proposals.
 
-However, co-spend proposals are able to explicitly include conflict hints for other proposals, indicating that (at least) the proposer of the conflicting proposal wouldn't accept a quorum proposal that depends on the excluded proposals.
+However, co-spend proposals are able to explicitly include conflict hints for other proposals, indicating that (at least) the proposer of the conflicting proposal wouldn't accept a coalition proposal that depends on the excluded proposals.
 
 #### Effective value adjustments
 
@@ -156,23 +156,23 @@ Imposing a minimal range width size imposes a limit on how many proposals can be
 
 ### Proposal aggregation and condition details
 
-A quorum proposal is a special kind of co-spend proposal that aggregates together a bundle of non-conflicting, fully accepted co-spend proposals. The quorum proposal is made by one of the peers, the aggregator, to *all* other peers implicated in the aggregation. The aggregator must also set specific values for any constrained parameters (e.g. a concrete feerate and not just a range).
+A coalition proposal is a special kind of co-spend proposal that aggregates together a bundle of non-conflicting, fully accepted co-spend proposals. The coalition proposal is made by one of the peers, the aggregator, to *all* other peers implicated in the aggregation. The aggregator must also set specific values for any constrained parameters (e.g. a concrete feerate and not just a range).
 
-#### Making and ratifying quorum proposals
+#### Making and ratifying coalition proposals
 
-Any peer may attempt to construct a quorum proposal by aggregating unanimously accepted co-spend proposals together, so long as it controls at least one of the online keys implicated in the aggregation. For rate limiting, the aggregator's key is made explicit, and the hash of this signature is used for flood control when gossipping the partially signed quorum proposal, much like the hash of ownership proofs.
+Any peer may attempt to construct a coalition proposal by aggregating unanimously accepted co-spend proposals together, so long as it controls at least one of the online keys implicated in the aggregation. For rate limiting, the aggregator's key is made explicit, and the hash of this signature is used for flood control when gossipping the partially signed coalition proposal, much like the hash of ownership proofs.
 
-Unlike co-spend proposals, quorum proposals are accepted with a regular signature by the online key. This makes them tractable for aggregators to make quorum proposals that revise the payoff or omit peers who didn't accept. As discussed above, quorum proposals aren't mutually exclusive. If a peer rejects a quorum proposal due to the inclusion of a specific proposal, it may broadcast a counter final proposal of its own, so there's no mechanism for explicit rejection.
+Unlike co-spend proposals, coalition proposals are accepted with a regular signature by the online key. This makes them tractable for aggregators to make coalition proposals that revise the payoff or omit peers who didn't accept. As discussed above, coalition proposals aren't mutually exclusive. If a peer rejects a coalition proposal due to the inclusion of a specific proposal, it may broadcast a counter final proposal of its own, so there's no mechanism for explicit rejection.
 
 #### Bootstrapping consensus for transaction construction
 
-Once a quorum proposal is fully accepted, a coalition has been formed, complete with a payoff imputation. The online keys are then used to initiate a consensus protocol to construct the full transaction.
+Once a coalition proposal is fully accepted, a coalition has been formed, complete with a payoff imputation. The online keys are then used to initiate a consensus protocol to construct the full transaction.
 
-Since the quorum proposal addresses every UTXO, its ownership proof set commitment is authoritative. This determines the canonical online key set for the quorum, allowing a consensus protocol to be initialized. The aggregator should use precedence ordering for symmetry breaking to minimize additional gossip and improve the chances of the quorum proposal being unanimously accepted, but there's no consensus state for this data at the time the quorum proposal is being authored. The purpose of quorum proposals is to bootstrap both the consensus protocol and incentive compatibility to make use of it.
+Since the coalition proposal addresses every UTXO, its ownership proof set commitment is authoritative. This determines the canonical online key set for the coalition, allowing a consensus protocol to be initialized. The aggregator should use precedence ordering for symmetry breaking to minimize additional gossip and improve the chances of the coalition proposal being unanimously accepted, but there's no consensus state for this data at the time the coalition proposal is being authored. The purpose of coalition proposals is to bootstrap both the consensus protocol and incentive compatibility to make use of it.
 
-#### Quorum proposal structure
+#### Coalition proposal structure
 
-The surplus of all included co-spend proposals is added to the quorum proposal's adjustment vector, which covers all UTXOs. The quorum proposal's surplus must be positive and needs to cover the shared transaction fields at the set feerate, but otherwise, the aggregated surplus is at the discretion of the aggregator; it may be claimed as a coordination fee, redistributed among all parties arbitrarily, or included in the mining fees.
+The surplus of all included co-spend proposals is added to the coalition proposal's adjustment vector, which covers all UTXOs. The coalition proposal's surplus must be positive and needs to cover the shared transaction fields at the set feerate, but otherwise, the aggregated surplus is at the discretion of the aggregator; it may be claimed as a coordination fee, redistributed among all parties arbitrarily, or included in the mining fees.
 
 The logical conjunction of co-spend proposals implies the union of their adjusted UTXOs and the intersection of their conditions is in effect. The per-UTXO adjustments are collected for each outpoint. The total adjustment for each UTXO may not overflow its effective value, based on the range proof widths.
 
@@ -231,8 +231,8 @@ Finally, PQ privacy must of course also assume that metadata privacy at the tran
 
 A protocol similar to WabiSabi can provide liveness, although in this setting, WabiSabi's reliance on KVACs would require one of the peers to serve as the coordinator, and it would be trusted. With modification, this coordinator could prove all transcript messages it accepted are valid, but may still arbitrarily censor certain operations, causing a UTXO to be unfairly blamed for failing to sign.
 
-Technically the quorum proposal can implement a coordination fee mechanism — for example, by making all adjustments slightly negative, apart from that of the coordinator (which may or may not be the aggregator). This provides the coordinator with an incentive to coordinate honestly on average. Unfortunately, this does little for any targeted censorship risk, so long as the payoff from censorship (of e.g. a specific TxOut) dominates over the expected loss of revenue from sabotaging a single attempt at transaction construction. It's likely that the majority of the revenue is still recoverable in a subsequent blame round, as the other participants have no indication that censorship has occurred.
+Technically the coalition proposal can implement a coordination fee mechanism — for example, by making all adjustments slightly negative, apart from that of the coordinator (which may or may not be the aggregator). This provides the coordinator with an incentive to coordinate honestly on average. Unfortunately, this does little for any targeted censorship risk, so long as the payoff from censorship (of e.g. a specific TxOut) dominates over the expected loss of revenue from sabotaging a single attempt at transaction construction. It's likely that the majority of the revenue is still recoverable in a subsequent blame round, as the other participants have no indication that censorship has occurred.
 
-For a more robust mechanism, coalition formation outputs a set of online keys for a quorum, and among other things, these are intended to be used to implement byzantine fault tolerant state machine replication for transaction construction. The initial state, based on the quorum proposal, can be proven valid with respect to each UTXO's adjustment sum commitments, which enforces that the agreed to imputation is in effect.
+For a more robust mechanism, coalition formation outputs a set of online keys for a coalition, and among other things, these are intended to be used to implement byzantine fault tolerant state machine replication for transaction construction. The initial state, based on the coalition proposal, can be proven valid with respect to each UTXO's adjustment sum commitments, which enforces that the agreed to imputation is in effect.
 
 The state machine collects inputs and outputs of a transaction (or tree of transactions a la CoinJoinXT). Since state messages are self authenticating, authenticating using zero knowledge proofs (anonymous credentials or ring signatures), they can be posted anonymously, much like in a permissioned blockchain, where all peers act as validators.