pull down to refresh

Do we need protocol level Coinjoin?
40 sats \ 18 comments \ @kilianbuhn 14 Apr 2022 bitcoin
I am not a big fan of using tech for the sake of using tech.
But coinjoins barely have any disadvantages at all. If all Miners are required by protocol organize or only accept transactions with a minimum number of inputs and outputs.
Another Idea to implement this would be that transactions older than e.g. 20 minutes are allowed to go on chain without conjoin - which would allow to process transactions from people who cannot wait until the transaction is submitted with limited time in internet left. This time would also be a soft incentivation for coinjoins that is not monetary.
What do you think?
write
preview
related posts
16 sats \ 0 replies \ @nullcount 14 Apr 2022 freebie
There's a shitcoin that tried this. Decred forked BTC with an incentive to participate in collaborative transactions.
As a result, the majority of transactions are part of a large-enough anonymity set that most of the Decred chain has gone dark.
It's as if JoinMarket was actually easy to use.
A quote from Decred developer:
"To do a coinjoin you need some type of coordinating server for multiple parties to create the shared coinjoin transaction. Prior to joining Decred, I wrote code for the joinmarket project which was the leading bitcoin coinjoin creation software. It tried to increase mix volume to build a large enough anonymity set by using a market to incentivize others with profit to offer their coins for joining. This model worked but never really picked up enough steam to build a large enough anonymity set with many participants to make the privacy resistant to chain analysis. Less then 1% of coins were participating. This became known as the problem of coincidence... needing people to be sending transactions at the same time for the same amount. While writing code for Decred's ticket buying system in 2016, I came to see the ticket purchasing architecture was the key piece that was missing. Decred's ticket buying system uses transactions of the same denomination that occur frequently at the same time, and with a large percentage (50%) of the total coins existing participating. It was from this insight that the initial prototypes were created."
I'm holding out for JAM to make JM sexy. Perhaps cross-input signature aggregation makes coinjoin cheaper?
reply
14 sats \ 0 replies \ @thrown 14 Apr 2022
tbh i’d rather see privacy punted to layer 2. focus on improving privacy in lightning so that when you exit lightning to layer 1 (like a savings account) nobody knows where you came from.
reply
10 sats \ 6 replies \ @notgeld 14 Apr 2022
No.
reply
4 sats \ 5 replies \ @kilianbuhn OP 14 Apr 2022
Why not? What would be the disadvantage?
reply
10 sats \ 4 replies \ @notgeld 14 Apr 2022
Lean protocol (without CJ) is more decentralized and allows to build CJ on top, even variations of CJ (Samourai Wallet, Wasabi, JoinMarket).
Protocol level CJ will make blockchain heavier and less decentralized while simultaneously makes harder to build some other things on top. Imagine how much longer it will be channel opening in LN if there protocol CJ would take place.
reply
21 sats \ 1 reply \ @kilianbuhn OP 14 Apr 2022
Have you read my post? Or only get angry after reading the headline?
I only want to require multi input/output transactions for transactions younger than 20 min. This wouldn't sabotage second layer solutions, nor any coinjoins wallets.
Only incentive for coinjoins. No hard fork.
reply
0 sats \ 0 replies \ @notgeld 14 Apr 2022
I am not angry.
Those who use CJ already incentivized to so something for privacy. You actually propose to tax everybody else. And another thing, less obvious, CJ needs coordination of participants so it is supposed to be overlay protocol, always. This is what I said about, it would be better for everybody to keep base layer lean.
reply
0 sats \ 1 reply \ @IanMalcolmPhd 21 Apr 2022
What about a privacy slider, where 1 is "fastest and the least private" and 10 is "it clears in a week"
reply
0 sats \ 0 replies \ @notgeld 22 Apr 2022
It might be non-private. Least priority transaction may mean that you know counterparty or do self-transfer.
Privacy is hard and IMO it should be a by-product of scalability like in Lightning Network.
reply
32 sats \ 3 replies \ @k00b 14 Apr 2022
We don't need it certainly. It might be nice to have, but coinjoins as an optional higher layer protocol are good enough imo. Besides, keeping the base layer simple and transparent is a worthy tradeoff especially if it allows - as Bitcoin does - for privacy to be built in higher layers. We are early, coinjoin tools are improving, and coinjoin markets are becoming more liquid.
What would you be willing to give up for the base layer to have coinjoin on it? Everything has tradeoffs.
reply
4 sats \ 2 replies \ @kilianbuhn OP 14 Apr 2022
I'd argue that bigger coinjoins transactions are simpler and more elegant for a base layer?
What would be the tradeoff?
reply
1 sat \ 1 reply \ @k00b 14 Apr 2022
I don't know the tradeoffs but I'm also not advocating for a hard fork. Other than requiring consensus changes (which is a massive downside on its own), there are undoubtably huge tradeoffs - in UX, security, etc. e.g. Mimble Wimble Coin had a huge DoS vulnerability in its implementation.
reply
0 sats \ 0 replies \ @zuspotirko 14 Apr 2022
Which transactions get into which blocks when doesn't require a hard fork. Coinjoins are already a thing on Bitcoin.
Actually there already is a precedent for this: Miners include transactions with the highest fee before they include the oldest transactions.
reply
21 sats \ 0 replies \ @cozy 14 Apr 2022
I think practically speaking, as far as fungibility and privacy goes, things like OP_CTV and AnyPrevOut being used for sidechains have effectively the same power as Coinjoin. For most people who aren't trying to launder hundreds of millions of dollars, for which there is no liquidity, there is already a path of fungibility, too. It can get better, of course, but I don't think protocol level coinjoin is a good idea. Just my 2 sats though.
reply
2 sats \ 0 replies \ @BlueSlime 15 Apr 2022
I believe the auditable nature of the blockchain is part of Bitcoin's success. The transparency is useful and ideally organizations will adopt bitcoin as a counter to internal corruption.
It also makes the protocol simpler and easier to work with. Transactions do not require negotiating view keys or any other additional steps in order to coordinate with others.
I think it's easier to add a layer of privacy than take it away. Imagine if the world ran on tor by default. I love Tor, but 90% of my traffic does not need to negotiate complicated circuits and rendezvous points, I just want it to get from a > b as fast as possible.
reply
0 sats \ 0 replies \ @IanMalcolmPhd 21 Apr 2022
What about a privacy slider, where 1 is "fastest and the least private" and 10 is "it clears in a week"
reply
0 sats \ 1 reply \ @moel 15 Apr 2022
We could ask minders to economically "incentivize" coin-joins.
It is very simple: large transactions with multiple inputs and multiple outputs simple pay a LOWER fee than one-input-one-output-one-change kind of transactions.
This way, all wallet makers have an incentive to make their wallet auto-batch transactions.
On-chain a multiple-in-multiple-out "batch-transaction" and a "coin-join" transaction look the same. With Taproot they look identical.*
  • Do not quote me on this. Where is @jimmySong when you need him?
reply
0 sats \ 0 replies \ @jimmysong 15 Apr 2022
This is the idea behind CISA, because the savings would be larger. Instead of a signature per input, you get one signature for all the inputs, adding more savings.
The problem is the coordination and can't be done just by the miners. SIGHASH_SINGLE could do it, but that would defeat the purpose of the CoinJoin.
reply