Well this is interesting!
13/ Come party with the big boys and their heavy, heavy bags. Try using JoinMarket, where you can coinjoin and earn. I take you through the JoinMarket basics, but be sure to read the docs before you try anything for yourself! https://www.youtube.com/watch?v=zTCC86IUzWo
is anyone still using the #bitcoin binaries for 32-bit x86 linux?
if you do, please let us know—the current idea is to phase them out in the not-so-distant future
Seems even more relevant now, PSBTs would make this a lot simpler to implement.
Finally found a decent, simple solution for syncing GitHub issues for offline usage:
Some detailed analysis on knapsack mixing from nopara. Busy adding maker to JM gui, so i won't be reading right now but looks interesting.
We have computed the very first chosen-prefix collision for SHA-1. To put it in another way: all attacks that are practical on MD5 are now also practical on SHA-1.
We have reduced the cost of a collision attack from 2^64.7 to 2^61.2, and the cost of a chosen-prefix collision attack from 2^67.1 to 2^63.4.
Demo: The legacy branch of GnuPG (version 1.4) is vulnerable. We have created two PGP keys with different UserIDs and colliding certificates.
New blog post from ajtowns on priorities in btc development:
Just to note, this can be done today, using -P to pick parties for the second round (the actual payment). Although it will be a bit flaky in that you can't guarantee that those entities will use the desired utxo (hence 10 might work and 2 might not).
Will have a think about whether you can make it work "for sure".
(5/5 i guess)
This gives rise to a natural thought - since this effect is *from the specific viewpoint of gaining privacy from your payee* so powerful, why not focus on creating it?
One approach: in joinmarket you do a normal coinjoin with say 10 parties, then take the equal sized output of that as your input for your actual payment, and re-join with the same 10 parties - either likely or definitely(? needs work), you will have multiple equal sized inputs, thus the paid coins are not identifiable. (4/n)
Now there's an exception to that identifiability: if you coinjoin with 1 other maker, and one of the maker's inputs happens to be the same size exactly as one of your inputs, then it isn't possible to distinguish between the two input subsets.
This has been noted in the past as one of the main reason disentangling joinmarket joins is hard.
Also note, that idea of equal inputs was termed 'reverse coinjoin' by nopara in some recent writing (https://pastebin.com/ADu7kQFk).
Caveat: lightning and coinswap (and swaps in and out of lightning) are all natural solutions to this problem; but limited in size and require interactivity. Focusing here on coinjoin which addresses a different scenario.
So joinmarket already by default solves the first half of this problem: it allows you to pay an arbitrary (including large) amount, with a coinjoin. That's the main idea of it.
But with fees on inputs, the taker inputs are identifiable (generally).
Another joinmarket showerthought; it needs a little background:
Consider that one aspect of on-chain privacy is specifically hiding your own coins from the payee. This one is a seriously difficult problem; no existing coinjoin does it except in certain special cases (more on that in a moment). Even Payjoin, difficult to coordinate but powerful technique - but doesn't address this problem at all.
For myself I suspect this hasn't got as much attention as you might expect, not because of a lack of cool crypto tech, but because of a lack of well conceived use cases.
We don't generally pay for computation of things directly. It happens, but rarely.
I found myself idly wondering whether paying for proof of work might ever be a viable idea (aside from the indirect: just using bitcoin itself, often can get same effect).
I'd imagine they would apply some relative ordering of in/out ownership within a transaction... which is idiotic, but fits perfectly well with the rest of the paper.
A little bit of discussion on this paper, from ~ a year ago: https://bitcoinhackers.org/@htimsxela/101453730742128063
The "swap a coin for a secret" idea slowly developed over time, and Maxwell took a nice step forward in summarizing the more sophisticated idea with "ZKCP" or zero knowledge contingent payments (anyone remember darkleaks? lower tech version of same idea). There's a whole story here but it's one that continues to fascinate me as likely very important in future. This paper is ditching the ZKP heavy machinery but is still an interesting take.