Great summary on important topic :) I hope to see more posts like this... and that's why I boosted some sats your way ;)
Seth, are you planning on keeping this article up to date?
reply
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.
reply
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
Seth, are you planning on keeping this article up to date?
Absolutely, it's not easy to keep things like this up to date but I will try my best. All of the source for the site/posts is on Github as well, so pull requests to correct/keep things up to date are always welcome! The specific source for this post is here:
There's this ring signature proposal for Bitcoin
Will give it a read and add if it makes sense, thanks!
And here seems to be some update for Stealth Addresses
Will give it a read as well and share with Monero researchers to see how relevant it may be, thanks! Had definitely not seen this before, though.
reply
Since posting I've:
Please let me know if there are other proposals I should add, any issues, or any details I missed on existing sections!
reply
Pushed a bunch of new updates to the PayJoin entry as I got more good context from Max Tannahill on the background and adoption issues there:
reply
Added a simple pros/cons section to each proposal, but please note those are somewhat subjective and based on my own understanding of each! Take with a grain of salt, but helpful simplifications and as true/accurate as I can make them :)
Always welcome corrections or further insight!
reply
People are sleeping on Fedimint.
This is fantastic solution
reply
It certainly has a much more interesting set of pros/cons than Liquid, but I just can't really get behind any type of custodial model myself.
I also have deep concerns about how it will open up the federation members to regulatory or legal risk for easy money transmission prosecution, something that is obviously garbage but could be leveraged to harm Bitcoin/Bitcoiners if Fedimint got enough usage.
reply
I think many Bitcoiners are deeply sceptical towards everything that reduces Bitcoins elegance of simplicity. Buzzwords like "side chain" or "federation" just scream shitoinery.
reply
Most Bitcoiners are not skeptical of Lightning which is far more complex than most side-chain proposals.
It's less skepticism and more "what do thought leaders push for". The key difference here is people need to very clearly understand the custodianship implications of federations like Fedimint.
reply
Yes, LN is far more complex. But it is not custodial, so it's not somehow irrational to treat it entirely differently to fedimint or federated sidechains.
There's relevant history that I think people are overlooking. Do people remember OT (Open Transactions) or even earlier pre-bitcoin implementations like Truledger, Loom? When I asked elsirion at the El Salvador conference he hadn't heard of OT.
Honestly I don't bring that up as a dig against people, it's more to me important to try to learn: what is it about these constructions that somehow hasn't gained traction in past iterations, even if on paper the properties they offered are very attractive? The natural conclusion is: ruthless removal of central points of failure is the key thing, and federation generally doesn't cut it, unless we can find some new twist.
reply
This blog post made it into Bitcoin Magazine!
Reviewing Privacy-Enhancing Proposals For Bitcoin | Bitcoin Magazine #35582 https://bitcoinmagazine.com/technical/list-of-bitcoin-privacy-proposals
reply
And that was article published at about the same time as this call for privacy enhancements:
reply
I have a question about PayJoin - BIP 78... Currently both Samourai and BTCPayServer support PayJoin.
But which iOS wallet can I use to send PayJoin transactions ?
reply
I've been told that Blue Wallet also supports PayJoin, which is available on iOS but haven't tried it yet myself!
reply