Edits to coalition_formation #2
Conversation
|
|
||
| ### Setup: BIP 322 gossip, online key enrollment | ||
|
|
||
| Every spendable coin could potentially be spent in a multiparty transaction (although not all coins can be co-spent). To facilitate this, we require a gossip mechanism for BIP-322 ownership proofs, with a replacement and expiration mechanism for flood protection, committing to a public key referred to as the *online key* for the coin. |
There was a problem hiding this comment.
In this sentence, who is "we"?
Also, what is committing to a public key? The ownership proofs, the gossip mechanism, the flood protection? This sentence isn't entirely clear and could be reworded.
"To facilitate this, we require a gossip mechanism for BIP-322 ownership proofs, with a replacement and expiration mechanism for flood protection, committing to a public key referred to as the online key for the coin."
There was a problem hiding this comment.
In this sentence, who is "we"?
I guess the reader or any hypothetical intended implementor of this protocol
Also, what is committing to a public key?
the ownership proofs
This sentence isn't entirely clear and could be reworded.
Similarly to TLS/SSL certificates, the ownership proof contains a digital signature, and the data that is signed can include the hash of that public key...
"To facilitate this, we require a gossip mechanism for BIP-322 ownership proofs, with a replacement and expiration mechanism for flood protection, committing to a public key referred to as the online key for the coin."
so to break this down:
- there are BIP-322 ownership proofs
- which certify a public key
- have a definite expiry
- there needs to be a way to update them (by replacement)
- there needs to be to rate limit this
- there is a gossip mecahnism, over which the ownership proofs are exchanged, and each peer can keep a local view of the up to date ownership proofs for all known coins
This attempt is still a bit clumsy but better:
To facilitate this, we require a gossip mechanism for BIP-322 ownership proofs. This needs to have support expiration and replacement, and have flood protection. The proofs commit to a public key referred to as the online key for the coin.
|
|
||
| Every spendable coin could potentially be spent in a multiparty transaction (although not all coins can be co-spent). To facilitate this, we require a gossip mechanism for BIP-322 ownership proofs, with a replacement and expiration mechanism for flood protection, committing to a public key referred to as the *online key* for the coin. | ||
|
|
||
| The purpose of this online key is to authenticate the owner of the UTXO without requiring them to access the spending keys for communication. Anonymous authentication requires the use of ring signatures (and are therefore less likely to be supported by a HWW than BIP-322 proofs), and also simplify the mapping to just a single public key per UTXO, regardless of the complexity the `scriptPubKey` might have (complex multisig or ambiguity from multiple spend paths). |
There was a problem hiding this comment.
What is less likely to be supported? Ring signatures or something else?
"Anonymous authentication requires the use of ring signatures (and are therefore less likely to be supported by a HWW than BIP-322 proofs), and also simplify the mapping to just a single public key per UTXO, regardless of the complexity the scriptPubKey might have (complex multisig or ambiguity from multiple spend paths)."
There was a problem hiding this comment.
yep, ring signatures
i suspect it originally said "therefore is" referring to anonymous authentication and then i realized concretely ring signatures is the actual thing that is less likely to be supported and i just didn't remove the "therefore", if it was "which are less likely..." i think that's much clearer
|
|
||
| #### Flood protection | ||
|
|
||
| Online keys may need to be rotated. Since ownership proofs are tied to UTXOs that provides some degree of Sybil protection (identities aren't costless because UTXOs aren't costless), but that is insufficient for flood protection with regards to gossipped messages, since unlike Bitcoin transaction gossip, such messages don't consume any of the scarce resource. |
There was a problem hiding this comment.
This sentence has a lot of ideas in it and it's not totally clear.
"Since ownership proofs are tied to UTXOs that provides some degree of Sybil protection (identities aren't costless because UTXOs aren't costless), but that is insufficient for flood protection with regards to gossipped messages, since unlike Bitcoin transaction gossip, such messages don't consume any of the scarce resource."
Does a rewrite like this make sense?
"Ownership proofs are tied to UTXOs, which provides some Sybil resistance, since creating UTXOs has a cost. However, this is insufficient for flood protection of gossipped messages. Unlike Bitcoin transactions, which consume UTXOs when included in blocks, ownership proof messages can be broadcast repeatedly without consuming the underlying UTXO."
There was a problem hiding this comment.
yes.
the logic is as follows:
- key rotation requires multiple proofs
- the total number of utxos that can publish ownership proofs is limtied because utxos themselves are costly
- therefore rate limiting can be done for each utxo independently, without worrying about UTXOs getting churned to skirt rate limits
- so we need to rate limit the number of updates per utxo
Here's another attempt sort of based on your rephrasing:
Ownership proofs are tied to UTXOs. This provides some Sybil resistance, since creating new UTXOs isn't free. The online keys may need to be rotated, which requires publishing replacement ownership proofs before existing ones expire. Unlike Bitcoin transactions, broadcasting ownership proofs is essentially free so this gossip layer needs an additional flood protection mechanism.
|
|
||
| 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.
Just a thought, do you think items like
There was a problem hiding this comment.
no, on github this renders as shitty latex, on some web forum systems the mathjax output is usually a bit nicer and with pandoc converted to say pdf it renders as nice latex typesetting...
this could be floor(v/log2(v)) if optimizing for plaintext readability but i prefer the latex display
|
|
||
| If $m=n$ linkable ring signatures with distinct key images have been collected, then a proposal has been unanimously accepted. | ||
|
|
||
| Finally, for a proposal to be fully accepted, the $n$ linkable ring signatures are replaced with a single Schnorr signature made by the MuSig2 aggregate key formed from the set of associated online keys of the UTXOs. This reduces the size, as well as the computational cost of verifying proposals. Because all parties have accepted, no single party can deny having signed making a joint multisignature is semantically equivalent to the $n$ individual linkable ring signatures, the distinction is only meaningful during negotiations before all parties have accepted. |
There was a problem hiding this comment.
This line is unclear — a lot of ideas packed into it:
"Because all parties have accepted, no single party can deny having signed making a joint multisignature is semantically equivalent to a the
Does this make sense as a rewrite?
"Because all parties have accepted, no single party can deny having signed. This makes a joint multisignature semantically equivalent to the
|
|
||
| #### Making and ratifying quorum 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. |
There was a problem hiding this comment.
Who or what is "it" in this line? The peer? The proposal?
"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 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. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
In this line
"...potentially requiring additional attempts to recreate the transaction"
In the case of additional attempts, what does that entail? Do you reuse accepted proposals or start over with bilateral negotiation?
There was a problem hiding this comment.
accepted proposals can be reused freely, or not, at the discretion of the aggregator
|
|
||
| A precondition for liveness is that any such cost function is monotonically decreasing in new information revealed during transaction construction. | ||
|
|
||
| Concretely, whenever the action of some peer is revealed (i.e. when an input or output is added), at worst, other peers should be indifferent to this, but they may also obtain positive utility. If this isn't the case, parties may rationally choose to defect. The purpose of the constraints in proposals is to allow the honest subset peers to avoid such non-malicious conflicts a priori, since monotonicity is required for liveness, a peer that engages in the protocol without adhering to this restriction and refuses to sign is deviating from the protocol, and therefore by definition not a member of the honest subset. |
There was a problem hiding this comment.
This line is confusing. Should it be split into two, with a period are "priori"?
"The purpose of the constraints in proposals is to allow the honest subset peers to avoid such non-malicious conflicts a priori, since monotonicity is required for liveness, a peer that engages in the protocol without adhering to this restriction and refuses to sign is deviating from the protocol, and therefore by definition not a member of the honest subset."
What is the connection between monotonicity and protocol membership?
There was a problem hiding this comment.
so what it's trying to say is:
- a priori all parties need to agree to sign, before they know all the details of what they will be signing
- since this is in the non cooperative setting this agreement must be self enforcing
- therefore by definition only peers whose cost function is monotonically decreasing given more details about the transaction structure are honest
any peer that has an rational reason not to sign at the end is deviating from the protocol, because they should have taken that into account ahead of time, and therefore when they deviate from the protocol and fail to sign at the end they need to be kicked out of future attempts
if the cost function is not monotonically decreasing (e.g. this tx costs me 10 sats in objective fees, but if i learn that there are some nice inputs joining maybe subjectively it only costs me 5 sats, because that's how i price the privacy benefit, but then when the outputs are revealed if i see a JPEG in there and i perceive a "cost" of 15 sats overall because i feel that +10 sats quantifies my injury, and that makes me want to want to do an authoritarianism or call my lawyer and sue people, and because of this i refuse to sign the transaction, then technically i'm the one breaking the rules because the protocol says i should have declared this restriction or rejected the coalition proposal if it failed to say JPEGs are forbidden
|
|
||
| Note that this example omits many details discussed below. | ||
|
|
||
| Alice, Bob, Carol, and Dave are owners of UTXOs $A$, $B$, $C$, and $D$, respectively. Alice wants to CoinJoin with Bob and Carol. She creates a co-spend proposal with UTXOs $\{ A, B, C \}$. In this proposal, she adjusts her UTXO $A$ down by 100 sats, and adjusts $B$ and $C$ up by 50 sats each, providing an incentive for Bob and Carol to accept. She sends this to Bob and Carol, who accept, after which the proposal is fully accepted and broadcast. |
There was a problem hiding this comment.
Is there any specific reason as to why Alice makes this adjustment? Or is it just a random number for the purpose of this example?
"In this proposal, she adjusts her UTXO
There was a problem hiding this comment.
these are just arbitrary numbers yeah
something the document as a whole should make clearer is that it's generic over the cost function, but also it tries not to leak more than is necessary about this cost function... but basically Alice's preferences are described by such a cost function and it says that her utility is maximized if she pays Bob and Carol those values in this case but it's meant to be general, the only protocol requirement on the cost function is that monotonicity requirement (from the point of view of the agents it also needs to be actually tractable to compute but that's outside of the scope of this document)
2 participants
No description provided.