131 sats \ 1 reply \ @0260378aef 1 Jun 2022 \ parent \ on: A List of Proposed Bitcoin Privacy Improvements | sethforprivacy.com bitcoin
The ring signature proposal:
The idea is by no means dumb but from my somewhat brief reading (then again, it's a somewhat brief paper, to say the least!), I don't see a materially important difference to the Chaumian blinding construction.
In both cases, you start by submitting your inputs (the paper unhelpfully uses the term 'transactions' for input utxos). In this new idea you also submit an ephemeral public key and then once the server sends back a list of all participant public keys, and it's this set of keys you form ring sigs over, that is, you ring-sign each of your destination addresses.
To do that without trivially linking inputs to outputs (which is the desirable property with a server-based mix, for privacy from central coordinator), you're going to need to break the network linkage between the first and second phase. This is exactly the same as when using Chaum blind signatures.
It is also a shame that the paper does not discuss ring signature properties in any detail. Its definition of the term does not discuss the crucial property of spontaneity, nor linkability (which is important in Monero but I guess not, here), nor culpability, which could well be relevant in potential DOS attacks against this construction.
So TLDR it's interesting but probably not revolutionary, and the paper is really lacking in detail.
On second thoughts I guess you do need the 'linkability' property as in Monero, because you don't want someone double-signing, that is, for input A, you don't want them to be able to submit an output set of address and amounts twice. But ...
this is where the lack of detail matters. Is it intended for construction equal-amount coinjoins? It seems like that's tacitly implied, and that the output address set that each participant sends is supposed to add up to some fixed amount. That's a whole can of worms already (see Wabisabi). And/or: what about change outputs? Depending on the model those could be sent along with the inputs, or over separate network identities.
TLDR this is just a vague idea, not a proposal, I think.
reply