Define the on-chain privacy problems being addressed

[nothingmuch]

Minor edits from https://gist.github.com/nothingmuch/d84ba390d89b5b08897af2d95009c2a1:

• soft wrapping
• remove paragraph that hedges against doomerism, as that makes sense outside of the context of the fungi repo

[bc1cindy]

I left a review comment https://gist.github.com/nothingmuch/d84ba390d89b5b08897af2d95009c2a1?permalink_comment_id=6295257#gistcomment-6295257

[nothingmuch]

thanks to for the reminder, i replied, will try work some of the suggestions in where i agree, and will fix the typos

[arminsabouri]

Still havent finished. Left off around provenance and robust connectivity. Wanted to leave the comments I already have. Apologies, some of them are just complaining that a certain section doesnt click for me without a suggestion (mainly the social graph stuff). I'll come back around to it.
I also have not rendered or reviewed the diagrams yet

[arminsabouri]

"Connecting" is doing alot of work here. Eitherway its a bit wordy but I dont have a great suggestion right now. Just leaving this as a note to come back to

[yuval-block]

agreed. i was trying not to front load too much nuance, just are these multiparty txs made of independent sub-txns or potentially dependent ones

[yuval-block]

Rephrased, please resolve if better

[arminsabouri]

Is this setup of tx graph or graph minor used in this section? Its a bit odd to me bc I read this expecting this to be used in the next paragraph.

[yuval-block]

it's meant to be an aid to understanding the relationship between the cluster/user graph and the transaction graph, emphasizing that just because vertices are contracted that doesn't mean edges are removed (clustering is often described as an equivalence relation on vertices), so it's not a new concept it's just trying to make the specific notion of cluster graph, and what about it s a graph (as opposed to just an equivalence relation on coins/addresses) namely that the edges still connect between the clusters are where the useful information is

[yuval-block]

please resolve if clearer now, used "graph minor analogue" two paragraphs down

[arminsabouri]

What are the points this paragraph is trying to make? As I am reading there are seemingly two:

1. How privacy can decay in two different regimes.
2. Why entropy as a metric may understate privacy

[yuval-block]

mainly 2, that auxiliary information, in general, will not be observable, so users need to threat model and decide what amount of headroom will suffice based on what kind of auxiliary information they believe their adversary may have access to

1 is more a presupposition, that there are two regimes that are qualitatively very different, and if you don't account for auxiliary information the on chain analysis may make you think you're in the linear decay regime when in fact the adversary already has enough to move to the exponential decay regime

[yuval-block]

i think this should be clearer now, please resolve if so

[yuval-block]

Apologies, some of them are just complaining that a certain section doesnt click for me without a suggestion (mainly the social graph stuff). I'll come back around to it.

that is useful feedback please don't apologize

I also have not rendered or reviewed the diagrams yet

i suggest previewing on github, no need to run your own local rendering (which for the mdbook is a bit costly, needs to run a whole instance of chromium in nix sandbox just to get DOM rendering into a usable image format)

[Sjors]

It would be useful to illustrate both the additive and exponential case. IIUC the example below only covers the exponential case?

[yuval-block]

yes, but i have struggled to do that, so i'm hoping for suggestions.

for small very small n, visually the differences are not very obvious (e.g. the difference between half of 4 and 4-1 is just one edge/path), so for it to be visually clear this needs larger n

but the challenge is that it's very hard to draw a planar coinjoin graph of that size, graphviz does a better job than mermaid but it still looks like a bird's nest, it's basically impossible to follow any edge

i haven't worked on it recently but i vibe coded an interactive visualization for this which is closer to being able to do that, but it's still very messy and i had to set it down for a little while, too many things going on at once

anyway, so this is a general request - if someone has ideas about how to convey this difference visually in a clear way, please share

[bc1cindy]

what about drawing the candidate set?

[yuval-block]

There are people (such as myself) who have let the problems of display
lead them to conclude that for them graph is not the way.
Every problem has an answer, but mine I could not find,
so I thought I should talk it over to Him
and he'll give me peace of mind

Then I felt my life's too hard,
so I just had a talk with Claude.

Well, he's the only paid psychiatrist
that's known throughout the world
for solving the problems of all men
... but not really for this problem lol.

He suggested using an adjacency matrix of the boundary vertices of the transitive closure... which doesn't make really make sense (each row is a terminal utxo, and each column represents a candidate origin.

i don't think that's coherent because it doesn't show why the graph is brittle. Forgetting all about the One who pretty often lets me down, displaying the adjacency matrix including the intermediate nodes, so both columns and rows are just all coins in that subgraph, would kinda represent that.... but i'm not convinced that even if highlighted, the visual distinction between a block matrix and an upper diagonal matrix would help a reader who isn't already versed in spectral graph terms, and also it's unclear how to order the columns/rows.

[bc1cindy]

inspiring lol

same psychiatrist, fed him All You Need is DAG, figure 1

source on the row and round on the column, with the same coin struck in both graphs

wdyt?

[Sjors]

@bc1cindy your first example just illustrates the nature of additive vs exponentnial, but I think most reader will get that. The second example is much better. I'd reverse the before and after. But isn't this still "nothing happens" vs "exponential", and not the linear scenario? I guess something did happen, since you went from 16 to 15.

[yuval-block]

lmao, i guess claude likes the beatles more than stevie

is this a mermaid diagram? the grid layout seems pretty readable so i think this will work, better than what i managed

[bc1cindy]

does it seem better now? did it at 16 and 32 wallets so you can see which reads better. the 32 one opens a much wider gap at the end (22 against 1, instead of 8 against 1) but it's a taller image (1120 px against 762)

is this a mermaid diagram?

not mermaid, it's a svg from a small script, bc mermaid hands positions to dagre, and that's what makes the nest. here position is the data, so the row is the wallet, column is the round

the svg is what goes in the doc, the script only generates it. it computes the sequences from the graph instead of me typing them, so if the graph changes the numbers follow, and the number of wallets (n) is a parameter, which is how the 32 one was made

happy to push the svg as a commit to cherry-pick, and send the script along if you want it

[yuval-block]

thanks this is much better than what i managed to come up with so far

github is a bit hostile to svgs (i complain a lot about github, but in this case it's kinda justified, they technically can contain js which would be a script injection vuln if allowed with no restriction, letting malicious images perform actions on behalf of the user that is viewing the rendering)

so this may only be viewable in the mdbook version of this doc and not when browsing the source

i guess that's fine because afaict mermaid is not really up to the task of such a busy layout, and it'd just be one specific diagram

[bc1cindy]

got it

checking this I found that the stripping only happens with inline svgs, which is what I did, so I tested with an external one, but an svg loaded through <img> is its own doc, so it can't see the mdbook theme class, falls back to the OS setting and book on dark with the OS on light gives dark text on a dark background

[bc1cindy]

this doc isn't listed in SUMMARY.md, so mdbook never renders it

if it makes sense feel free to use this commit:

git fetch https://github.com/bc1cindy/docs.git ctp-render-only
git cherry-pick 51a5289

[yuval-block]

this doc isn't listed in SUMMARY.md, so mdbook never renders it

if it makes sense feel free to use this commit:

git fetch https://github.com/bc1cindy/docs.git ctp-render-only git cherry-pick 51a5289

Thanks, I couldn't find it yesterday and meant to ask you today

Any suggestions for a title? "collaborative transaction privacy" is what i called the gist originally, in this PR i call this a problem definition, but both feel kinda weaksauce

[bc1cindy]

Any suggestions for a title?

• The limits of collaborative transaction privacy
• Structural requirements for on-chain privacy
• What collaborative transactions leak?
• Privacy in multiparty transactions

[yuval-block]

so to be a bit more precise i think the "collaborative transaction privacy" title is descriptive of the content, but it doesn't quite capture that in the context of this repo it defines the problem that we're trying to solve

and if we just emphasize problem definition for fungi, that sells short the applicability of this perspective to alternatives

so i think a good title would address both of these, whereas my current title and your proposed alternatives only focuses on the first function of this doc

[bc1cindy]

Any suggestions for a title?

• Privacy requirements for collaborative transactions
• What collaborative transaction privacy requires
• Success criteria for collaborative transaction privacy
• The bar for collaborative transaction privacy