Ring signatures (monero-style) in Bitcoin: is it possible?

[apogio]

We 've been discussing something in another thread and since I am not, by any means, a bitcoin contributor, I 'd like to ask the more technically savvy users about it.

What would it need to add Ring Signatures to Bitcoin?

Here is my approach, but of course, I guess it will be invalid.

Adding Ring Signatures to Bitcoin would require changes both in the Protocol and Consensus layers.

1. New opcodes will be needed to support ring signatures. I guess this needs a soft fork.
2. Any input will need to reference multiple UTXOs, because in ring signatures only one of the UTXOs is truly spent. I guess this needs a change in the consensus layer.
3. Changes in wallets to support this new update.

I don't have any other thoughts. What makes me sceptical though is:

a) what about the efficiency in terms of fees and speed?
b) could it be vulnerable to double-spending?
c) what about the transactions that have already been added to the blockchain?
 

[Trêvoid]

c) what about the transactions that have already been added to the blockchain?
 

it would be a major step for privacy, if we accept all approach as a valid, to answer c) it wouldn’t hide old transactions only new ones using the feature you mentioned.

also it takes a lot of work and careful planning.

[bias]

it would be a major step for privacy, if we accept all approach as a valid, to answer c) it wouldn’t hide old transactions only new ones using the feature you mentioned.

also it takes a lot of work and careful planning.

I'm not a tech guy, nor do I have the proper skills but I'm certain that it will need time and big effort. However, that doesn't mean that it can't be done, unless some of our community gurus say otherwise.
As I said in the other thread, if something like that happened, I wonder how all the CEX's and the KYC/ AML checkers will work out and name "dirty" coins and addresses. They will find a way, or will it be a dead end for their methods?

[Mia Chloe]

~snip..

Okay, so adding those fancy "ring signatures" to Bitcoin I guess would be a massive deal. We may even need to change how Bitcoin even works at its core, like how transactions point to your money. Wallets would also need a total makeover too.

But honestly, it could make things way slower and more expensive to use. Plus, figuring out how to stop people from cheating (double-spending) with this new system would be a real headache. And of course, all the Bitcoin we have now would just stay the same, this would only affect new stuff. Big changes with some serious downsides to think about.

[tromp]

a) what about the efficiency in terms of fees and speed?

Basic ring signatures take up space proportional to ring size which makes them rather inefficient.
Newer designs [1] get by with logarithmic size which support large ring sizes much more efficiently.

But in either case the real efficiency problem is the impact on UTXO size. Since one can never tell which is the real input and which are the decoys, no output can be known to be definitely spent. So the UTXO set balloons to the entire TXO set, with very detrimental impact on node efficiency. It's not so noticeable on Monero yet because daily tx volumes are about 15x smaller than Bitcoin.
Zcash suffers from the same problem, but with only 10% of Monero's tx volume, it's even less noticeable there.

[1] https://eprint.iacr.org/2024/921

[d5000]

I'm wondering if this would not be a hard-forking change. Can you really achieve this only "tightening" some rules?

One crucial question is: How would old nodes process these transactions? If they see a transaction with several inputs, they may automatically deduce that all of them are spent.  So I guess there would need to be a completely new input format, like Segwit did. But it would be a much more drastic change than Segwit imo.

Googling the concept I found this - they claim to have "implemented ring signatures in Bitcoin". They however don't provide much details, only a JavaScript (!) file. So either I'm not knowledgeable enough to understand what they were doing, or it's not really a "ring signature implementation" on Bitcoin but perhaps a Proof of Concept (which could be implemented in an altcoin).

What should work however is to create a 1:1 pegged token (via Proof of burn) on the Bitcoin chain using OP_RETURN or another "data storage" format (Bitcoin Stamps, Ordinals Inscriptions ...) to code in the necessary data for ring signatures (OP_RETURN may be actually to limited currently). I think I wouldn't make many friends here if I'd implemented that

[apogio]

Basic ring signatures take up space proportional to ring size which makes them rather inefficient.
Newer designs [1] get by with logarithmic size which support large ring sizes much more efficiently.

But in either case the real efficiency problem is the impact on UTXO size. Since one can never tell which is the real input and which are the decoys, no output can be known to be definitely spent. So the UTXO set balloons to the entire TXO set, with very detrimental impact on node efficiency. It's not so noticeable on Monero yet because daily tx volumes are about 15x smaller than Bitcoin.
Zcash suffers from the same problem, but with only 10% of Monero's tx volume, it's even less noticeable there.

[1] https://eprint.iacr.org/2024/921

So you 're basically saying that, by design, the implementation of ring signatures isn't space-efficient.  Am I getting it correctly?
In Monero, the ring size is set to 16, which means that there are 15 decoys and 1 true UTXO.^[1]

I'm wondering if this would not be a hard-forking change. Can you really achieve this only "tightening" some rules?

The pull request ^[1] I posted below, says "this PR follows a double fork...". I am not sure what this double fork is, I guess I need to find the time to read it more carefully.

One crucial question is: How would old nodes process these transactions? If they see a transaction with several inputs, they may automatically deduce that all of them are spent.  So I guess there would need to be a completely new input format, like Segwit did. But it would be a much more drastic change than Segwit imo.

It should be incredibly difficult to work with older nodes, that's why I asked for the pipeline. This is actually a good idea. A new address format, where there's no obligation to choose this instead of the older ones.

Googling the concept I found this - they claim to have "implemented ring signatures in Bitcoin". They however don't provide much details, only a JavaScript (!) file. So either I'm not knowledgeable enough to understand what they were doing, or it's not really a "ring signature implementation" on Bitcoin but perhaps a Proof of Concept (which could be implemented in an altcoin).

Yeah yeah, I 've tried googling myself and then I tried to find relevant scientific papers, but none of them made sense (I don't remember finding any papers, only google stuff).

What should work however is to create a 1:1 pegged token (via Proof of burn) on the Bitcoin chain using OP_RETURN or another "data storage" format (Bitcoin Stamps, Ordinals Inscriptions ...) to code in the necessary data for ring signatures (OP_RETURN may be actually to limited currently). I think I wouldn't make many friends here if I'd implemented that

I am sure you wouldn't, but th


References:
[1] Github Pull Request: https://github.com/monero-project/monero/pull/8178

[stwenhao]

What would it need to add Ring Signatures to Bitcoin?

It can be done on top of Taproot. You can have a single Taproot address, which would handle N users at the same time.

if something like that happened, I wonder how all the CEX's and the KYC/ AML checkers will work out and name "dirty" coins and addresses

In the same way, as they do that on other coins, which introduced similar rules. If you use some privacy-based coin, like Monero, and you send it between exchanges, then these exchanges comply with some regulations, and the more users they have, the more traffic they can deanonymize.

But honestly, it could make things way slower and more expensive to use.

It depends, how things will be connected. Because if it will be optional, and the cost of computing things will be only on users of Ring Signatures, then it wouldn't affect the rest of the network. For example: if you have Lightning Network or sidechains, then only these users have to process, what happens inside these networks. Everyone else can just see things, as they are today, so they don't pay any additional costs.

But in either case the real efficiency problem is the impact on UTXO size. Since one can never tell which is the real input and which are the decoys, no output can be known to be definitely spent. So the UTXO set balloons to the entire TXO set, with very detrimental impact on node efficiency. It's not so noticeable on Monero yet because daily tx volumes are about 15x smaller than Bitcoin.

In the most extreme case, you need only a single UTXO per subnetwork. Which means, that if you want to peg Monero into Bitcoin, then you can have a single UTXO, with all Monero's supply, denominated in BTC, and then, from the Bitcoin's perspective, you have a single moving UTXO. But if you want to really know, what is spent, and what is unspent, then you have to connect with that subnetwork, and download their database.

Which means, that making N additional UTXOs wouldn't hurt the main network in that case, but only some subnetwork. And then, switching from one bloated network to some fresh one, is just a matter of moving your coins from one UTXO to another UTXO. And in that case, you can always leave some subnetwork, if it will be more bloated, than it should be (and also, subnetworks have a nice property, that they commit to a stronger chain, which allows pruning historical data in a way, where new nodes don't have to download that kind of data, to check, if the network is honest or not; just like you don't have to download all historical LN transactions, if they are all settled on-chain).

I'm wondering if this would not be a hard-forking change. Can you really achieve this only "tightening" some rules?

A lot of things can be made through soft-forks: https://petertodd.org/2016/forced-soft-forks

One crucial question is: How would old nodes process these transactions?

In the same way as today. And how would old nodes process Schnorr signatures they know nothing about? How would pre-Segwit nodes process Segwit transactions? If Ring Signatures would be enabled as a feature, only for those, who will explicitly want to use it, then the rest of the users will be unaffected.

[NotATether]

What would it need to add Ring Signatures to Bitcoin?

It can be done on top of Taproot. You can have a single Taproot address, which would handle N users at the same time.

This will open the gateway to smart contract-type mixers among other things, which are already present on Ethereum. I am very excited to see any developments in that space.

if something like that happened, I wonder how all the CEX's and the KYC/ AML checkers will work out and name "dirty" coins and addresses

In the same way, as they do that on other coins, which introduced similar rules. If you use some privacy-based coin, like Monero, and you send it between exchanges, then these exchanges comply with some regulations, and the more users they have, the more traffic they can deanonymize.

They will continue to blacklist addresses that send or receive coins to other blacklisted addresses and then do that recursively.

Coinjoins break this all up, but then all bitcoins eventually fall into the category of "clean" coins or mixed coins, with the mixed coins percentage growing larger and larger as the block reward shrinks. Well it would, if it weren't for investors. But I generally believe that most people who have mixed bitcoins don't bother sending them back to exchanges, meaning the mixed bitcoins stay "underground", and only a few of it transitions to "clean coins" (through being confiscated, held endlessly by exchanges and then turning them over to some government).