Strawman ladder by yuval-block · Pull Request #17 · fungi-protocol/docs

yuval-block · 2026-08-05T18:53:12Z

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 )

arminsabouri

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

arminsabouri · 2026-08-05T19:10:40Z

+[^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/)


Double citation w/ L156

arminsabouri · 2026-08-07T14:25:29Z

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


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?

more that the cost function is client policy

arminsabouri · 2026-08-07T14:29:13Z

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


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

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

Probably this one payjoin/rust-payjoin#434

bc1cindy · 2026-08-25T21:59:10Z

+
+# generalized coinjoin with randomization mechanism
+
+[verifiable randomization mechanism](https://gist.github.com/nothingmuch/f5b9a559958c6116606d9da0d4d884f2) provides sybil resistance and improved graph properties, as well as useful symmetry breaking properties for the protocol in both the low volume (up to one tx per block) and high volume (more than one tx per block) regimes


Suggested change

[verifiable randomization mechanism](https://gist.github.com/nothingmuch/f5b9a559958c6116606d9da0d4d884f2) provides sybil resistance and improved graph properties, as well as useful symmetry breaking properties for the protocol in both the low volume (up to one tx per block) and high volume (more than one tx per block) regimes

[verifiable randomization mechanism](https://gist.github.com/nothingmuch/f5b9a559958c6116606d9da0d4d884f2) provides sybil resistance and improved graph properties, as well as useful symmetry breaking properties for the protocol in both the low volume (up to one tx per block) and high volume (more than one tx per block) regimes. the randomization promotes disjoint paths probabilistically; the [max flow / path count metric](https://github.com/nothingmuch/tx-graph-anonymity-sets/blob/main/07_path_like_anonymity_set.md) is what verifies they actually materialized, telling a client whether another round is needed.

i think it would make this rung self contained

oakagent · 2026-09-23T14:59:33Z

+
+## Informal Problem Definition
+
+Transacting privately means that the funding or spending of a specific transaction output must be plausibly attributable to a sufficiently large number of [wallet clusters](https://spiralbtc.substack.com/p/the-scroll-2-wallet-clustering-basics) under reasonable assumptions. For a more comprehensive and nuanced discussion of the problems these protocols aim to solve, see [./collaborative_txn_privacy.md] which, similarly to this one, builds up from PayJoin.


./collaborative_txn_privacy.md is not part of this commit's tree (git ls-files lists only README.md and strawman_ladder.md), so the pointer cannot be resolved.
It is also written as [...] without (), so it renders as literal text instead of a clickable link.

known issue, depends on #7

oakagent · 2026-10-08T13:48:07Z

Typos in what this pull request adds (automated):

strawman_ladder.md

l.12 - "perscribe ay" → "prescribe any"
l.16 - "is 3 half-round" → "is a 3 half-round"
l.34 - "can still tolerated" → "can still be tolerated"
l.76 - "avoid disrupt or abuse the protocol" → "avoid disrupting or abusing the protocol"
l.80 - "also kown as" → "also known as"
l.82 - "imagine peer to peer protocol" → "imagine a peer to peer protocol"
l.91 - "outputs not be included" → "outputs not being included"
l.93 - "due the total" → "due to the total"
l.97 - "one or more the inputs" → "one or more of the inputs"
l.99 - "sigma protocols are sufficient for instantiating" → "sigma protocols sufficient for instantiating"
l.103 - "Any any protocol" → "Any protocol"
l.105 - "the opening one (or more) of the commitments" → "the opening of one (or more) of the commitments"
l.107 - "the commitment id one of" → "the commitment id is one of"
l.109 - "the nullifiers reveals" → "the nullifiers reveal"
l.109 - "byzantine peers peers" → "byzantine peers"
l.111 - "Such a private key an efficient" → "Such a private key is an efficient"
l.115 - "since that preclude" → "since that precludes"
l.143 - "wagner attack attack" → "wagner attack"
l.173 - ""anti sybil" are misleading" → ""anti sybil" is misleading"
l.173 - "claim is technically accurate" → "the claim is technically accurate"
l.175 - "among other things, were awarded" → "among other things, they were awarded"
l.175 - "as well as funded misleading" → "as well as funding misleading"
l.177 - "self-censrship" → "self-censorship"
l.185 - "progress and eventually convergence" → "progress and eventually converge"
l.185 - "in the presence of an byzantine peers" → "in the presence of byzantine peers"
l.187 - "modeled either as" → "modeled as"
l.189 - "processes the these" → "processes these"
l.191 - "set reconcilation" → "set reconciliation"
l.193 - "most severe setting" → "most severe settings"
l.195 - "how long this can takes" → "how long this can take"
l.195 - "the honest peer to actually communicate" → "the honest peers to actually communicate"
l.195 - "it can eventually comes back" → "it can eventually come back"
l.196 - "since for transaction construction can enforce" → "since transaction construction can enforce"
l.202 - "For a economic transactions" → "For economic transactions"
l.202 - "impose a choice is between" → "impose a choice between"
l.214 - "turn out focus" → "turn our focus"
l.218 - "relying on consensus this can impede" → "relying on consensus can impede"
l.222 - "proceed at rate limited" → "proceed at a rate limited"
l.244 - "per transactions" → "per transaction"
l.252 - "there is sweet spot" → "there is a sweet spot"
l.254 - "for large transaction any be too taxing" → "for large transactions may be too taxing"
l.256 - "placing more of burden" → "placing more of the burden"
l.256 - "a leader that lacking sufficient resources" → "a leader that lacks sufficient resources"
l.256 - "which in turn negatively $p$" → "which in turn negatively affects $p$"
l.266 - "maintaining threshold clock based CRDT" → "maintaining a threshold clock based CRDT"
l.281 - "least resillient" → "least resilient"
l.291 - "protocols have that rely" → "protocols that rely"
l.296 - "rateless set reconcilation" → "rateless set reconciliation"
l.303 - "set reconcilation" → "set reconciliation"
l.332 - "for precompution" → "for precomputation"
l.355 - "Bitcoin transaction transaction outputs" → "Bitcoin transaction outputs"
l.361 - "the CIOH is be accurate" → "the CIOH is accurate"
l.369 - "and which Carol" → "and which to Carol"
l.371 - "linking inputs a PayJoin transaction" → "linking inputs in a PayJoin transaction"
l.375 - "for more additional blockspace savings" → "for additional blockspace savings"
l.377 - "custer mempool" → "cluster mempool"
l.387 - "fully signedThis transaction" → "fully signed transaction"
l.393 - "requires couinterparty trust" → "requires counterparty trust"
l.429 - "set reconcilation" → "set reconciliation"

overview

e2b8cec

yuval-block mentioned this pull request Aug 5, 2026

Add honest overview #11

Closed

arminsabouri reviewed Aug 7, 2026

View reviewed changes

bc1cindy mentioned this pull request Aug 25, 2026

transport strawman ladder outline #27

Open

bc1cindy reviewed Aug 25, 2026

View reviewed changes

oakagent reviewed Sep 23, 2026

View reviewed changes

Navigation Menu

Repository navigation

Strawman ladder - #17

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

yuval-block commented Aug 5, 2026 •

edited

Loading

Uh oh!

arminsabouri left a comment

Uh oh!

arminsabouri Aug 5, 2026

Uh oh!

arminsabouri Aug 7, 2026

Uh oh!

yuval-block Aug 7, 2026

Uh oh!

arminsabouri Aug 7, 2026

Uh oh!

yuval-block Aug 7, 2026

Uh oh!

arminsabouri Aug 7, 2026

Uh oh!

bc1cindy Aug 25, 2026

Uh oh!

oakagent Sep 23, 2026

Uh oh!

nothingmuch Sep 23, 2026

Uh oh!

oakagent commented Oct 8, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants


		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.


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


		# generalized coinjoin with randomization mechanism

		[verifiable randomization mechanism](https://gist.github.com/nothingmuch/f5b9a559958c6116606d9da0d4d884f2) provides sybil resistance and improved graph properties, as well as useful symmetry breaking properties for the protocol in both the low volume (up to one tx per block) and high volume (more than one tx per block) regimes


		## Informal Problem Definition

		Transacting privately means that the funding or spending of a specific transaction output must be plausibly attributable to a sufficiently large number of [wallet clusters](https://spiralbtc.substack.com/p/the-scroll-2-wallet-clustering-basics) under reasonable assumptions. For a more comprehensive and nuanced discussion of the problems these protocols aim to solve, see [./collaborative_txn_privacy.md] which, similarly to this one, builds up from PayJoin.

Conversation

yuval-block commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arminsabouri left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oakagent commented Oct 8, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

yuval-block commented Aug 5, 2026 •

edited

Loading