Coalition formation - #18
yuval-block wants to merge 1 commit into
Conversation
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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
not quite, this paragraph tacitly assumes a perfect agreement mechanism, and talks just about the unanimous signing requirement which is inherent for SIGHASH_ALL signing
|
|
||
| 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. |
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
There was a problem hiding this comment.
yes.
btw MTP goes back to satoshi's code, bip 113 just uses it to enforce time based nLocktime which is nice because it's monotonically increasing
|
|
||
| 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. |
There was a problem hiding this comment.
how is the session keyed? or is that out of scope here?
There was a problem hiding this comment.
group secret key?
the aggregator can generate a PSK and share it with all parties by encrypting it to them same as the opening of the adjustment commitments, i haven't bothered designing this detail yet it's not very consequential
|
|
||
| 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). |
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
There was a problem hiding this comment.
yes, it's deduped, a coalition formation proposal can only list a co-spend proposal once.
the component wise sum of the adjustment vectors is not idempotent just commutative (fwiw it does say commutative semi-group, not join semi lattice for this reason, but perhaps that should mention that the "effects" or terms of co-spend proposals can be aggregated non-idempotently)
this doesn't really matter because aggregation is only done by one entity, not as a distributed computation
|
|
||
| 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. |
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?
| 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. |
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
that was intended
should this be "the range width is at least X", with the adjustment bounded in magnitude by the width?
but yes this is clearer, "small is no smaller than ..."
the rationale here is that this limits the number of co-spend proposals that can be aggregated per UTXO in a coalition formation proposal
|
|
||
| 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). |
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
There was a problem hiding this comment.
storage is not so costly, this is a few hundred bytes per UTXO, and those are costly, the main concern is the bandwidth amplification of churn
committing to longer durations prevents churn - it forces the broadcaster to work hard to grind hashes
There was a problem hiding this comment.
sorry that was a bit vague, by having a longer window of time during which a certain replacement threshold is set, each replacement during this window costs more, and the work per replacement increases at an exponential rate so longer durations basically enforce an exponential backoff on the writer
This document describes the BFT coalition formation protocol that is a precursor to BFT transaction construction.