[Megathread] Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion

[n0nce]

~ BTC Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion BTC ~

Preamble / Motivation:
Motivated by discussions on various threads, I started looking more thoroughly into L1 blockchain privacy - covering what is available in terms of academic research, implementation in various altcoins and upsides & drawbacks of different methods.

This thread is dedicated for sharing ideas and research, as well as discussing and educating, about privacy solutions that could be implemented in Bitcoin in the future. Hopefully, it could even become the starting ground for development of concrete BIPs.
What I am specifically looking for in existing implementations is that they do have to work with UTXO-based cryptocurrency, they do need to work with PoW, they do need to work without a centralized, trusted setup ceremony and generally have to work on Bitcoin.

This is not an altcoin discussion; its sole goal is trying to find one or more L1 privacy solution candidates for Bitcoin.

As I'm still learning a lot on this subject, I appreciate suggestions for changes and additions to whatever I write next..
I will also add more sections / lists in place of reserved posts over time.

The set of lists and the lists themselves are by no means definitive or authoritative; merely a starting point, and will be maintained. Yes, I even leave question marks wherever I'm sure more information has to be added since I'm not educated enough on these topics. We're all going to learn something together here...

Selected privacy-focused altcoin projects, techniques employed and limitations:

• Monero
  
  • Ring signatures: obfuscate UTXOs
    
  • Ring confidential transactions: hide amounts (range proof)
    
  • Bulletproofs: much more efficient NIZK range proofs
    
  • Stealth addresses: sender generates unlinkable one-time address from given public key
    
  • Drawbacks: larger transaction size, ... ?
• Zcash
  
  • Zerocoin: basically in-protocol mixing for existing coin e.g. Bitcoin, precursor of Zerocash
    
  • Zerocash: successor of Zerocoin: smaller, faster verifiable transactions, variable amounts, spendable directly to receiver
    
  • Drawbacks: centralized 'key creation ceremony' required, larger transaction size, ... ?
    
• Grin
  
  • MimbleWimble: complete new protocol for confidential transactions and smaller transactions (but interactive!)
    
  • Drawbacks: interactive - both parties need to be online at the same time, ... ?
• Litecoin
  
  • MimbleWimble Extension Blocks: optional MW, but non-interactive and with stealth addresses
    
  • Extension Blocks: kind of like little side chains with extra features (in this case MW)
    
  • Drawbacks: it's only optional, ... ?

Layer 1 privacy concepts that could / do work in Bitcoin:

• CoinJoin (Greg Maxwell): combine transactions to hide who pays whom - usable today
  
• CoinSwap (Greg Maxwell): swap coins with someone else to get new transaction history - usable today
  
• Confidential Transactions (Greg Maxwell): hide transaction value - sidechain / softfork needed
  
• MimbleWimble: complete new protocol for confidential transactions and smaller transactions - big fork needed (? To-do: look into how it was done on LTC)
  

[n0nce]

Reserved

[n0nce]

Reserved

[Hueristic]

This is not an altcoin discussion; its sole goal is trying to find one or more L1 privacy solution candidates for Bitcoin.

Pretty tough not to mention alts in this discussion as they are usually the best place to test out ideas.

Considering Monero has used just about every form of privacy tech that was originally suggested for Bitcoin I think discusing how those techs are working out and which can be successfully imported.

And of course alternative techs like ZK-Snarks and ZK-Starks are good candidates for discussion and a discussion about Z-crap (w00ps slipped) would not be out of order when trying to gauge whether Zk-Snarks is mature and understood enough to trust.

Layer 1 privacy concepts that could / do work in Bitcoin:

    CoinJoin (https://en.bitcoin.it/wiki/CoinJoin) (Greg Maxwell): combine transactions to hide who pays whom - usable today
    CoinSwap (https://bitcointalk.org/index.php?topic=321228.0) (Greg Maxwell): swap coins with someone else to get new transaction history - usable today
    Confidential Transactions (https://web.archive.org/web/20200502151159/https://people.xiph.org/~greg/confidential_values.txt) (Greg Maxwell): hide transaction value - sidechain / softfork needed
    MimbleWimble (https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt): complete new protocol for confidential transactions and smaller transactions - big fork needed (? To-do: look into how it was done on LTC)

You need to add bulletproofs to this list, not sure why its not there.[/s] NVM I see why, considering it a subset.

I'd really like to hear GMaxwells current thoughts on this subject.

[dkbit98]

MimbleWimble: complete new protocol for confidential transactions and smaller transactions

You could also add Litecoin to the list (I see you mentioned it above), it has code that is very similar to Bitcoin and was used before as testing ground for Bitcoin.
Few months ago they also added MimbleWimble, and I think there are more coins that use this privacy method, but it never got more attention for some reason.
There is one Elliptic blog article explaining MimbleWimble privacy upgrade for Litecoin, and I am sure it wouldn't be hard to do the same thing for Bitcoin.
https://www.elliptic.co/blog/explaining-mimblewimble-the-privacy-upgrade-to-litecoin

I would always vote for adding any privacy based protocol change in Bitcoin but I am more than certain that would create huge conflicts of interest and probably hard fork.
Just look what is happening with shitereum now, exchange owners are saying they will support shitereumPoW, and they say they would shut down staking or censor transactions if threatened by regulators.
Imagine what would happen with Bitcoin privacy fork in similar scenario if someone got threatened by regulators again... than again, I think that Bitcoin is mature enough for changes like this.

[jackg]

• Grin
  
  • MimbleWimble: complete new protocol for confidential transactions and smaller transactions
    
  • Drawbacks: ... ?

I was looking at a chart comparing grin and monero on the stackexchange yesterday. Link provided: https://monero.stackexchange.com/questions/11107/what-is-the-difference-between-monero-xmr-and-grin-grin

From the top comment:
The main difference I noticed was grin being considered fairly weak for privacy as it hides historic information and transaction amounts but those can be gathered before a transaction is confirmed (when it's broadcast and in the mempool - as I understand it - perhaps there's a way they'll come up with to obscure this further).

I THINK I'd add an con of the grin community being new and grin coin being fairly new too - I think that's their biggest drawback so far (just the newness, nothing to do with the people).

[NotATether]

Feel free to add MuSig (and MuSig2 and Musig-DN), and the BIP341/342 recommended way to create multisignatures on Taproot - that is a link to my BIP, which uses only BIP341 and BIP342 guidelines for constructing and spending from Multisig outputs.

[tromp]

The biggest downsides of privacy tech like ZCash and Monero is that they hugely hurt scalability, not just by having much larger transactions, but also by making it impossible to identify the UTXO set. Because you never know when outputs are spent, you have to maintain the entire TXO set (i.e. not only store but be able to efficiently index it) all the time. (When Monero fans claim that it improves scalability over Bitcoin, they conveniently ignore these properties and instead refer to Monero's ability to increase the maximum block size under conditions of congestion.)
Mimblewimble is the opposite, allowing you to completely forget about spent outputs, even in the Initial Block Download, greatly improving scalability and privacy at the same time.

I was looking at a chart comparing grin and monero on the stackexchange yesterday. Link provided: https://monero.stackexchange.com/questions/11107/what-is-the-difference-between-monero-xmr-and-grin-grin

A much more objective comparison can be found at
https://phyro.github.io/grinvestigation/why_grin.html
The one downside to Mimblewimble compared to bitcoin, is that it no longer allows full auditability.
But at least in Grin, auditability reduces to one simple equation. Quoting from https://np.reddit.com/r/CryptoTechnology/comments/kyhgcv/are_there_any_public_cryptocurrencyblockchain

Σ utxo = Σ kernel + offset * G + height * 60e9 * H

Another feature, that can be considered both an advantage in some cases, and a disadvantage in others, is that MW transactions are multisig by sender AND receiver, and thus require them to interact to build the tx, just as is already the case for Lightning. The advantage being that you cannot receive unwanted coins (like tainted ones), and don't need to scan the blockchain for new outputs unless you just transacted. The disadvantage is that you need to be in communication with the recipient.

Note that Litecoin's MWEB implementation is not pure MW, but a more complicated hybrid that no longer requires receiver interaction.

The main difference I noticed was grin being considered fairly weak for privacy as it hides historic information and transaction amounts but those can be gathered before a transaction is confirmed

This is quite wrong. An accurate overview of what various blockchains hide (and how scalable they are) can be found at https://forum.grin.mw/t/scalability-vs-privacy-chart

I THINK I'd add an con of the grin community being new and grin coin being fairly new too - I think that's their biggest drawback so far (just the newness, nothing to do with the people).

Grin has had a running testnet since 2017. It's hardly new by now.

[jackg]

The main difference I noticed was grin being considered fairly weak for privacy as it hides historic information and transaction amounts but those can be gathered before a transaction is confirmed

This is quite wrong. An accurate overview of what Grin and Monero hide can be found at
https://forum.grin.mw/t/scalability-vs-privacy-chart
which also shows how scalable various blockchains are.

Is coinswaps available on grin now then (I just realised how old that link was too but it was the first result I got).

Without MWCS you can see addresses that get paid in the mempool, with MWCS (if it's implemented) you wouldn't be able to trace anything from what I can tell as long as mixing is done frequently enough which it would if it scaled to bitcoin's size.

[tromp]

Without MWCS you can see addresses that get paid in the mempool

That makes no sense. Pure MW has no addresses.

The only thing you can see in the mempool that you cannot see in blocks are the original
transaction boundaries (except for txs that got aggregated in the Dandelion phase, but that is rare).

Mimblewimble Coinswap for Grin is still in development.

[ABCbits]

Layer 1 privacy concepts that could / do work in Bitcoin:

• CoinJoin (Greg Maxwell): combine transactions to hide who pays whom - usable today
  
• CoinSwap (Greg Maxwell): swap coins with someone else to get new transaction history - usable today
  

Do these two can be classified as part of layer 1 privacy since it doesn't require change on layer 1 protocol?

The biggest downsides of privacy tech like ZCash and Monero is that they hugely hurt scalability, not just by having much larger transactions, but also by making it impossible to identify the UTXO set.

Also due to longer block/transaction verification time.

[DaveF]

One of the major drawbacks I see in a lot of the privacy coins is actually the privacy. I have no idea how / if it could be done but we would need a way for Alice to pay Bob that is 100% private BUT at the same time provide them with a way that if needed Alice could prove to the world that she did in fact pay Bob to this address and this amount and here it is to be seen on a public block explorer. BUT and this is a big but, they both have to agree to release that info. Alice says she paid and here is her 1/2 of the info. Bob now has to put up his 1/2 to show there was no transaction if he said he was not paid. This way in event that either Alice or Bob are compromised you still can't get the information because you need the other 1/2.

If you can't do that then there will be a lot of people who are going to start popping up saying that they didn't get their money.

Which brings up the next question, which probably needs it's own thread. Do we need L1 privacy or would an integrated into the protocol but on an L2 privacy be better?

-Dave

[tromp]

we would need a way for Alice to pay Bob that is 100% private BUT at the same time provide them with a way that if needed Alice could prove to the world that she did in fact pay Bob to this address and this amount and here it is to be seen on a public block explorer. BUT and this is a big but, they both have to agree to release that info.

Mimblewimble supports payment proofs. For a payment from Alice to Bob, this is a statement signed by Bob's public key (associated with his wallet) that appearance of certain data on-chain (sufficiently confirmed), proves that he was paid by Alice. The statement can include amount, time, and purpose of payment.
BUT Bob's agreement is not needed to release this info. In fact, payment proofs are useful in cases where Bob promises to provide some goods or service in exchange for Alice's payment, but then fails to do so. Now Alice can submit the payment proof to some 3rd party (e.g. a court) as evidence for Bob's fraud.

Which brings up the next question, which probably needs it's own thread. Do we need L1 privacy or would an integrated into the protocol but on an L2 privacy be better?

I think amount and address privacy is best built into the base consensus layer, as these improve scalability as well in case of MW.
But hiding input-output links (obfuscating the tx graph) on the base layer comes at a large cost in either scalability or (in case of recursive snarks/starks) in trustworthiness, so perhaps that is better added on as separate service  (such as the Mimblewimble CoinSwap protocol).

[DaveF]

we would need a way for Alice to pay Bob that is 100% private BUT at the same time provide them with a way that if needed Alice could prove to the world that she did in fact pay Bob to this address and this amount and here it is to be seen on a public block explorer. BUT and this is a big but, they both have to agree to release that info.

Mimblewimble supports payment proofs. For a payment from Alice to Bob, this is a statement signed by Bob's public key (associated with his wallet) that appearance of certain data on-chain (sufficiently confirmed), proves that he was paid by Alice. The statement can include amount, time, and purpose of payment.
BUT Bob's agreement is not needed to release this info. In fact, payment proofs are useful in cases where Bob promises to provide some goods or service in exchange for Alice's payment, but then fails to do so. Now Alice can submit the payment proof to some 3rd party (e.g. a court) as evidence for Bob's fraud.

Yes, with MW either person can reveal the transaction. For true privacy you need to be sure it can only be released when BOTH people agree to release it.
If for whatever reason Bob does not want it known that Alice paid him if Alice can release in unilaterally then it's not really that private. Because it does not have to be Alice, just someone with access to Alice's computer / phone / whatever.

-Dave

[tromp]

For true privacy you need to be sure it can only be released when BOTH people agree to release it.
If for whatever reason Bob does not want it known that Alice paid him if Alice can release in unilaterally then it's not really that private.

It's also not that useful, as payments can trivially be denied by a fraudulent receiver, with no recourse for the buyer.

Payment proofs are a critical component to a functioning digital payment economy.

[oryhp]

For true privacy you need to be sure it can only be released when BOTH people agree to release it.

Requirement that both agree to release it is what enables fraud. If I pay you X in exchange for some good Y and you refuse to give me Y after you were paid X, then I should be able to prove (regardless of how you feel about it) that I paid X to get Y. Otherwise you can only ever transact with the people you trust which makes it unusable as a payment system. You have to protect the payer from a fraudulent payee.

[DaveF]

It's also not that useful, as payments can trivially be denied by a fraudulent receiver, with no recourse for the buyer.

Payment proofs are a critical component to a functioning digital payment economy.

Requirement that both agree to release it is what enables fraud. If I pay you X in exchange for some good Y and you refuse to give me Y after you were paid X, then I should be able to prove (regardless of how you feel about it) that I paid X to get Y. Otherwise you can only ever transact with the people you trust which makes it unusable as a payment system. You have to protect the payer from a fraudulent payee.

Why, if I said I paid and you say I didn't and I release my side and you don't release yours then although there is not 100% proof you did not get paid it looks shady as hell.

You can either have privacy or you can have proof. You can't really have both. Which was why I also pointed out privacy might be better on L2.
If you don't trust me or I don't trust you then here you go it's all in public, if we do then it's the same transaction but on L2
Or a simple private / not private switch on L1. Whatever.

But if either side can disclose without permission of the other don't think it's private. It's just more limited visibility.

-Dave

[Hueristic]

Why, if I said I paid and you say I didn't and I release my side and you don't release yours then although there is not 100% proof you did not get paid it looks shady as hell.

You can either have privacy or you can have proof. You can't really have both. Which was why I also pointed out privacy might be better on L2.
If you don't trust me or I don't trust you then here you go it's all in public, if we do then it's the same transaction but on L2
Or a simple private / not private switch on L1. Whatever.

But if either side can disclose without permission of the other don't think it's private. It's just more limited visibility.

-Dave

If there was no transaction then there would be no key to release then by extension would you have the person saying they never received having to give up their private keys to prove the transaction never existed?

I guess a checksum could be incorporated into the chain to prove wallets that store all transactions as being kosher but otherwise then you could just get into wallet hacking and fraudsters would be all over that.

The main difference I noticed was grin being considered fairly weak for privacy as it hides historic information and transaction amounts but those can be gathered before a transaction is confirmed

This is quite wrong. An accurate overview of what Grin and Monero hide can be found at
https://forum.grin.mw/t/scalability-vs-privacy-chart
which also shows how scalable various blockchains are.

I have not kept up on grin, with that being said are you stating that a listener can no longer store transactions for chain analysis?

[tromp]

Why, if I said I paid and you say I didn't and I release my side and you don't release yours then although there is not 100% proof you did not get paid it looks shady as hell.

So I can make you look shady by claiming I paid you and releasing my fake side and by definition you couldn't release yours?

It seems you want to transact with people whom you trust and don't trust at the same time.
You trust them to provide the goods/services you pay for, but
you don't trust them not to disclose tx info without your consent.

I have not kept up on grin, with that being said are you stating that a listener can no longer store transactions for chain analysis?

Any mempool observer can reconstruct (nearly all of) the transaction graph.
But chain analysis on this graph is hard without any visible amounts or addresses.
It's even harder if most transactions are payjoins (i.e. receiver also provides an input), so that you cannot distinguish between payer and payee. Thanks to the interactivity required by MW, payjoins are just as easy as non-payjoins.

[DaveF]

Why, if I said I paid and you say I didn't and I release my side and you don't release yours then although there is not 100% proof you did not get paid it looks shady as hell.

So I can make you look shady by claiming I paid you and releasing my fake side and by definition you couldn't release yours?

It seems you want to transact with people whom you trust and don't trust at the same time.
You trust them to provide the goods/services you pay for, but
you don't trust them not to disclose tx info without your consent.

You could only get away with it once possibly twice before people assume it's you doing the scamming.
Perhaps 3 flags.
1) open and public transactions
2) closed either side can release the transaction information
3) closed both sides have to agree to release the transaction

You would also have to have a way of forcing that. i.e. addresses that begin with 1 are option 1, addresses that begin with 2 are option 2, addresses that begin with a 3 are option 3.

That way when you pay you know what you are getting into. If we really don't trust each other 1 or 2. One is fully public 2 is private but can be released without my consent or knowledge so there is proof for the sender. 3 is private and secure.

-Dave