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"

oakagent · 2026-10-18T05:10:00Z

+
+Fees paid by consenting users, and understood to be in the service of privacy, have unfortunately not gone towards fixing these flaws. Instead, among other things, were awarded to DoS attackers (through successful extortion) as well as funded misleading marketing efforts, which arguably includes a years long twitter feud that has alienated users and fostered a cult like mentality with regards to Bitcoin privacy technology among the remaining proponents.
+
+The evidence for centralized CoinJoins being flawed and predatory is overwhelming, despite not being inherent it appears inevitable. It is not just harmful to directly exploited users, but to privacy and fungibility as a whole. Weak privacy is antithetical to censorship resistance, the chilling effects of surveillance lead to self-censrship, and it is antithetical to self sovereign custody due to the lack of informed consent and perhaps more importantly because such misinformation exposes users to unnecessary risk with real safety concerns, as indicated by the alarming rise of $5 wrench attacks.


The unpaired $ before 5 wrench opens inline math that mdbook-katex closes at the next $ on line 226, so the intervening prose is treated as a LaTeX expression and KaTeX rejects it, leaving the affected content unrendered. Escape it as \$5.

oakagent · 2026-10-25T04:56:26Z

+
+While even poorly implemented centrally coordinated coinjoins have demonstrated that $n$ on the order of hundreds is achievable, in the decentralized setting this is more costly for peers who can't rely on communicating with just one trusted coordinator. If one of the peers is selected as a leader, the additional communication overhead. Coordinating such a transaction also requires sharing information about the previous outputs, the message validity proofs, etc, and the leader must broadcast all of this information to all parties, which for large transaction any be too taxing on the chosen leader, necessitating failover and incurring significant communication overhead.
+
+Since traditional leader based consensus imposes asymmetric resource utilization, placing more of burden on the leader, another useful probability to think about is that of the leader being able to communicate successfully during one run of the underlying consensus protocol. Naively the probability of consensus succeeding under this leader is $q^n$, if the probability of error was independent, but network congestion is likely to cause correlated transmission failures for a leader that lacking sufficient resources in reality things will fare worse. Although such leader faults do not break the unanimity requirement, they delay progress of the overall protocol and consume more resources from all peers, which in turn negatively $p$.


Undefined q leaves leader success probability unevaluable

q is never defined anywhere in the document, so the stated leader success probability q^n cannot be evaluated.

_{oak · automated · e2b8cec}

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

bc1cindy mentioned this pull request Oct 15, 2026

check links #57

Merged

oakagent reviewed Oct 18, 2026

View reviewed changes

oakagent reviewed Oct 25, 2026

View reviewed changes


		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.


		Fees paid by consenting users, and understood to be in the service of privacy, have unfortunately not gone towards fixing these flaws. Instead, among other things, were awarded to DoS attackers (through successful extortion) as well as funded misleading marketing efforts, which arguably includes a years long twitter feud that has alienated users and fostered a cult like mentality with regards to Bitcoin privacy technology among the remaining proponents.

		The evidence for centralized CoinJoins being flawed and predatory is overwhelming, despite not being inherent it appears inevitable. It is not just harmful to directly exploited users, but to privacy and fungibility as a whole. Weak privacy is antithetical to censorship resistance, the chilling effects of surveillance lead to self-censrship, and it is antithetical to self sovereign custody due to the lack of informed consent and perhaps more importantly because such misinformation exposes users to unnecessary risk with real safety concerns, as indicated by the alarming rise of $5 wrench attacks.


		While even poorly implemented centrally coordinated coinjoins have demonstrated that $n$ on the order of hundreds is achievable, in the decentralized setting this is more costly for peers who can't rely on communicating with just one trusted coordinator. If one of the peers is selected as a leader, the additional communication overhead. Coordinating such a transaction also requires sharing information about the previous outputs, the message validity proofs, etc, and the leader must broadcast all of this information to all parties, which for large transaction any be too taxing on the chosen leader, necessitating failover and incurring significant communication overhead.

		Since traditional leader based consensus imposes asymmetric resource utilization, placing more of burden on the leader, another useful probability to think about is that of the leader being able to communicate successfully during one run of the underlying consensus protocol. Naively the probability of consensus succeeding under this leader is $q^n$, if the probability of error was independent, but network congestion is likely to cause correlated transmission failures for a leader that lacking sufficient resources in reality things will fare worse. Although such leader faults do not break the unanimity requirement, they delay progress of the overall protocol and consume more resources from all peers, which in turn negatively $p$.

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

yuval-block commented Aug 5, 2026 •

edited

Loading