Re: Ring signatures (monero-style) in Bitcoin: is it possible?
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
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