Skip to content

Strawman ladder - #17

Draft
yuval-block wants to merge 1 commit into
mainfrom
strawman-ladder
Draft

Strawman ladder#17
yuval-block wants to merge 1 commit into
mainfrom
strawman-ladder

Conversation

@yuval-block

@yuval-block yuval-block commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

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

  • update DAG section with information about set-chain consensus, which seems to be a better contender than a bespoke DAG based CRDT approach
  • describe TEE based weak coordinator approach for dishonest majority
  • clean up (e.g. make links to primary sources into footnotes for consistency with Define the on-chain privacy problems being addressed #7 )

@yuval-block yuval-block mentioned this pull request Aug 5, 2026

@arminsabouri arminsabouri left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread strawman_ladder.md
[^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/)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double citation w/ L156

Comment thread strawman_ladder.md

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more that the cost function is client policy

Comment thread strawman_ladder.md

# 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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR that adds ns1r might be more informative. Or even the gh discussion

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably this one payjoin/rust-payjoin#434

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants