Coalition formation - #18
Open
yuval-block wants to merge 1 commit into
Open
Conversation
bc1cindy
reviewed
Aug 17, 2026
Contributor
There was a problem hiding this comment.
typos:
- L15: "bootstraps a compatible transaction a protocol … on initial set" → "bootstraps a compatible transaction construction protocol … on an initial set"
- L33: "withold" → "withhold"
- L59: "are assumed quantify" → "assumed to quantify"; "Maurer et al's the sub-transaction model" → "Maurer et al's sub-transaction model"; "an estimate the cost to an adversary an n−1 deanonymization attack" → "an estimate of the cost to an adversary of an n−1 …"; "that liquidity is must be" → "must be"
- L63: "the honest subset peers" → "the honest subset of peers"
- L97: "tied to UTXOs that provides" → "which provides"
- L99: "encoded of the cost function" → "encoded in the cost function"
- L119: "unaddressible" → "unaddressable"
- L123: "demanding to be a one" → "demanding to be one"; "has an incentive be a validator" → "an incentive to be"
- L133: "While $m <
$n$ " → "$m < n$" (broken LaTeX?) - L141: "as long there is" → "as long as there is"
- L169: "counter final proposal" → "counter coalition proposal"?
- L209: "is just be a hash to curve" → "is just a hash to curve"
- L211: unbalanced closing parenthesis at the end of the paragraph
- L219: "Payments requests" → "Payment requests"
- L223: "BIPs 79-7" → missing digit?
- L245: "self authenticating, authenticating using" → "self-authenticating using"
|
|
||
| ### Transaction construction liveness assumptions | ||
|
|
||
| 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. |
Contributor
There was a problem hiding this comment.
Suggested change
| 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. | |
| 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, assuming $f < n/3$ for decentralized agreement, or $f \leq n - 2$ when an attested coordination service (TEE) is used. Any defection requires transaction construction to start over. Due to random network disruptions, necessarily some rate of (apparent) defection must be tolerated. |
|
|
||
| Ownership proofs are also used to estimate input weights. For P2TR outputs, this indicates the spend path intended to be used in any collaborative transactions. Note, however, that this isn't enforceable. | ||
|
|
||
| Each proof's endorsement of the online key has a validity interval specified in terms of Bitcoin block height or MTU (valid-after and valid-until). When multiple proofs by the same UTXO are nominally in effect, the one with the latest expiry time takes precedence. Ownership proofs commit to a block hash whose height or MTU is within some set interval of the valid-after field. |
Contributor
There was a problem hiding this comment.
should "MTU" be "MTP" (median time past, BIP 113)?
https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
MTU usually reads as maximum transmission unit
same on l143 ("block height, MTU, or UTC time")
wall-clock time is already covered by UTC there, so by elimination i assume MTU means chain time, i.e. MTP
|
|
||
| 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. | ||
|
|
||
| A coalition proposal also specifies a concrete transaction construction protocol version, and commits to a specific set of listen advertisements associated with the specified UTXOs, which have either demanded or opted into serving as validators. These peers agree to allow other peers to connect to them and facilitate in gossip. Depending on the liveness requirements of byzantine agreement for the subsequent transaction construction protocol, the aggregator may specify validators at their discretion and named parties may accept or decline. |
Contributor
There was a problem hiding this comment.
how is the session keyed? or is that out of scope here?
|
|
||
| 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. | ||
|
|
||
| Co-spend proposals therefore form a commutative semi-group, unioning the sets of UTXOs and summing the adjustments component wise. It's only a semi-group because proposals can't always be aggregated together. One reason for this is that the conditions might be mutually exclusive. Another is consensus rules (e.g. `OP_CLTV` making conflicting assertions). |
Contributor
There was a problem hiding this comment.
summing adjustments isn't idempotent, worth stating the bundle is a set (dedup by proposal id)?
double-inclusion via gossip would double payoffs
|
|
||
| When communicating a partial proposal, the proposer shares with each recipient the opening of the commitment associated with their UTXO. This payoff is denominated in sats, and it can be positive or negative. | ||
|
|
||
| Each adjustment value commitment is also covered by a range proof certifying that the adjustment is a small positive or negative integer. Small means at least $\lfloor\frac{v}{log_2(v)}\rfloor$, where $v$ is the minimal effective value among all specified UTXOs. This minimum value is computed by taking the highest acceptable feerate in the proposal conditions and multiplying that by the input weights estimated from the ownership proofs. |
Contributor
There was a problem hiding this comment.
"Small means at least X" seems inverted... "small" should be an upper bound, but "at least" sets a lower one
should this be "the range width is at least X", with the adjustment bounded in magnitude by the width?
Suggested change
| Each adjustment value commitment is also covered by a range proof certifying that the adjustment is a small positive or negative integer. Small means at least $\lfloor\frac{v}{log_2(v)}\rfloor$, where $v$ is the minimal effective value among all specified UTXOs. This minimum value is computed by taking the highest acceptable feerate in the proposal conditions and multiplying that by the input weights estimated from the ownership proofs. | |
| Each adjustment value commitment is also covered by a range proof certifying that the adjustment is a small positive or negative integer, bounded in magnitude by the proof's range width. The minimum range width is $\lfloor\frac{v}{log_2(v)}\rfloor$, where $v$ is the minimal effective value among all specified UTXOs. This minimum value is computed by taking the highest acceptable feerate in the proposal conditions and multiplying that by the input weights estimated from the ownership proofs. |
|
|
||
| To be accepted (and propagated through gossip) by a peer, any newly made proof associated with a coin must have a hash value (e.g. wtxid of the BIP 322 `to_sign` virtual transaction) numerically smaller than all the other proofs already associated with that output which are known to the peer. | ||
|
|
||
| Because ownership proofs may be valid at disjoint time intervals, a peer should store up to $k$ proofs (in total, not per validity time interval) in its gossip set for each candidate UTXO, so long as the hashes of *all* of these are numerically smaller than $c_1 + 2^{(c_2 d k)}$, where $d$ is the total duration of all proofs, and $c_i$ are dynamically set policy values (similar to `minrelayfee`, based on local resource limits). |
Contributor
There was a problem hiding this comment.
how should this formula behave? as written, the threshold gets looser as d grows, so longer-lived proofs are easier to store, which seems backwards (shouldn't occupying the gossip set for longer require a luckier hash?)
maybe c₂ is meant to be negative?
it would also help to say what scale the hashes are compared against
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This document describes the BFT coalition formation protocol that is a precursor to BFT transaction construction.