150 sats \ 3 replies \ @nout 1 Jun 2022
Great summary on important topic :) I hope to see more posts like this... and that's why I boosted some sats your way ;)
- There's this ring signature proposal for Bitcoin, but not sure if anything ever came out of that: https://sci-hub.se/10.1109/CIS.2017.00075
- And here seems to be some update for Stealth Addresses: https://sci-hub.se/10.1109/ICCCWorkshops49972.2020.9209929 (again I have no idea about quality of this paper)
Seth, are you planning on keeping this article up to date?
reply
131 sats \ 1 reply \ @0260378aef 1 Jun 2022
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
21 sats \ 0 replies \ @0260378aef 1 Jun 2022
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
21 sats \ 0 replies \ @sethforprivacy OP 1 Jun 2022
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:
https://github.com/sethforprivacy/sethforprivacy.com/blob/master/content/posts/proposed-bitcoin-privacy-improvements.md
Will give it a read and add if it makes sense, thanks!
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
21 sats \ 2 replies \ @sethforprivacy OP 31 May 2022
Since posting I've:
- Added FediMint/minimint
- https://sethforprivacy.com/posts/proposed-bitcoin-privacy-improvements/#fedimint
- Updated the PayJoin section extensively thanks to feedback from Samourai Wallet and Adam Gibson (waxwing), the author of the PayJoin BIP
- https://sethforprivacy.com/posts/proposed-bitcoin-privacy-improvements/#payjoin---bip-78
Please let me know if there are other proposals I should add, any issues, or any details I missed on existing sections!
reply
21 sats \ 1 reply \ @sethforprivacy OP 1 Jun 2022
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:
https://sethforprivacy.com/posts/proposed-bitcoin-privacy-improvements/#payjoin---bip-78
reply
0 sats \ 0 replies \ @sethforprivacy OP 2 Jun 2022
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
10 sats \ 4 replies \ @saunter 1 Jun 2022
People are sleeping on Fedimint.
This is fantastic solution
reply
10 sats \ 3 replies \ @sethforprivacy OP 1 Jun 2022
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
0 sats \ 2 replies \ @zuspotirko 1 Jun 2022
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
1 sat \ 1 reply \ @sethforprivacy OP 1 Jun 2022
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
11 sats \ 0 replies \ @0260378aef 2 Jun 2022
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
10 sats \ 1 reply \ @cryptocoin 11 Jun 2022
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
10 sats \ 0 replies \ @cryptocoin 11 Jun 2022
And that was article published at about the same time as this call for privacy enhancements:
Bitcoin Needs To Be More Private For Adoption
#35719
https://bitcoinmagazine.com/technical/bitcoin-needs-better-privacy-for-fungibility
reply
1 sat \ 1 reply \ @moel 1 Jun 2022
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
0 sats \ 0 replies \ @sethforprivacy OP 1 Jun 2022
I've been told that Blue Wallet also supports PayJoin, which is available on iOS but haven't tried it yet myself!
reply