Strawman ladder - #17
Conversation
arminsabouri
left a comment
There was a problem hiding this comment.
I'm pretty sure I have read and reviewed this document in its current form. I will re-review after state-chain things have been updated
| [^sudoku]: K. Atlas, [*CoinJoin Sudoku*](https://www.coinjoinsudoku.com/) | ||
| [^boltzmann]: LaurentMT, [*Boltzmann*](https://gist.github.com/LaurentMT/d361bca6dc52868573a2), specifically the link-probability matrix. | ||
| [^maurer]: F. K. Maurer, T. Neudecker, M. Florian, [*Anonymous CoinJoin Transactions with Arbitrary Values*](https://www.researchgate.net/publication/318128387_Anonymous_CoinJoin_Transactions_with_Arbitrary_Values) | ||
| [^sudoku]: K. Atlas, [*CoinJoin Sudoku*](https://www.coinjoinsudoku.com/) |
There was a problem hiding this comment.
Double citation w/ L156
|
|
||
| Constructing transactions that provide privacy this way inherently requires the participation of multiple parties, or there is no crowd for individuals to blend in. The purpose of these protocols is to allow the honest parties to agree on the inputs they intend to spend and the outputs they intend to create, with no arbitrary restrictions and without linking any one input or output to any other. This requires that all outputs are paid for by the inputs being spent, any uncovered output is by definition malicious. | ||
|
|
||
| Beyond that this protocol suite does not perscribe ay specific strategy for optimizing privacy. Although specific recommendations to improve privacy are provided in this repository, following those recommendations is a matter of incentives and client policy, not protocol rules. |
There was a problem hiding this comment.
| Beyond that this protocol suite does not perscribe ay specific strategy for optimizing privacy. Although specific recommendations to improve privacy are provided in this repository, following those recommendations is a matter of incentives and client policy, not protocol rules. | |
| Beyond that this protocol suite does not perscribe any specific strategy for optimizing privacy. Although specific recommendations to improve privacy are provided in this repository, following those recommendations is a matter of incentives and client policy, not protocol rules. |
This sentence is a bit confusing. Are you just referring to the fact that this is a document is strawmans and not a protocol spec?
There was a problem hiding this comment.
more that the cost function is client policy
|
|
||
| # Multi sender, single receiver payjoin | ||
|
|
||
| At the cost of one more round trip, where the senders submit signatures for their inputs, BIP 77 can be [modified](https://github.com/payjoin/rust-payjoin/pull/923) to support multiplexing of several senders' payments to one shared receiver. |
There was a problem hiding this comment.
The PR that adds ns1r might be more informative. Or even the gh discussion
There was a problem hiding this comment.
what would be your preferred link? there's also a citation for ns1r in #7 that links to the removal issue, but i dunno if that's the best discussion entry point
This document was previously called "overview" but it's not an overview since it describes many strawmen that are not in the protocol, it is a strawman ladder for didactic purposes
TODO