Topic: [Megathread] Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion (Read 1298 times)

It must be resistant to 50%+1 POW attacks. As Private Proof of Stake is used, Pandora Cash is protected from 50%+1 POW attacks but not from 50%+1 POS attacks.

I come back to this topic every once in a while for reference.
Maybe you @n0nce want to add some examples for working CoinJoin implementations (wallets or similar concepts ) to the OP for advanced accessibility for anyone stumbling accross this thread? Also DEX solutions such as Bisq wallet could be added to OP. Just a thought.


Yes, LN is a step in the right direction and over time I hope to see more "tiny" improvements that add up to create more privacy for Bitcoin.

Happy New Privacy Year 2023.

Me too, even though the lightning network (that is designed to work on a large scale) comes incidentally with strong privacy. So, hard fork or not, bitcoin is going to get more private over time, and even if most users don't care about privacy, they do care about the instant confirmation. So, there may be a resistance.

It says it's immune to 50%+1 attacks. Smells fishy to me.

This great discussion / summary of privacy solutions deserves a bump.

One of the main concerns regarding privacy solutions I see (for Bitcoin): There is just a lack of interest and understanding for probably 90%+ of people using Bitcoin.
It's the same for simple security and privacy concerns when browsing the web. Still a majority of people never pays any attention to this, ever - at least until they become victim of a successful scam / fishing or similar attempt. And even those who are a little worried in most cases don't really bother to actively change their behaviour and security-practices.
Since it's a mega-complex topic you can't even blame them (unless their work directly involves sensitive data they ought to protect).

So, to sum up my point, unless there is greater awareness of how important fungibility and privacy are for "sound money", I believe it's still a LONG way to get any of the possible solutions implemented for Bitcoin. Question is: will it ever happen without a huge fork that will result in one government-approved transparency chain and one black-listed privacy chain.
I'd love to be convinced otherwise, but for now I remain quite sceptical.

I'm always open for ideas on how to spread privacy awareness... But I believe it's not easy.

I just looked it up; MimbleWimble, PoW, ASICs (planned?), temporary wallet IDs.. Cool, but nothing really new for this discussion.
Except if they maybe solved the MimbleWimble interactivity problem! I don't think so, though.

I think for a 'privacy upgrade' to be widely accepted in the Bitcoin community, it should be possible to do confidential transactions just like regular SegWit transactions. Without extra requirements like running your own full node or anything else.

Any thoughts about BEAM?

This sounds very similar to a static LN invoice. But yes, as you noted, BOLT12 doesn't eliminate the need to run an always-online full node with Lightning on top. The interactive element is just automated.
It is obvious how the number of Bitcoin users in relation to the number of full nodes is huge.
And a lot of full nodes may not even hold personal balances as they may be a business node or an Electrum server node serving lots of users (like family members).

I guess it may be worth considering a 'delegation of trust' similar to using a single full node to serve a whole family's SPV wallets; it would require some sort of accounting on the node if this scheme were to be considered for Lightning and / or an interactive privacy coin such as Grin / equivalent Bitcoin upgrade.

I can answer about Grin. Please correct me if I'm wrong about BOLT12 as I've only skimmed over it. The main concept of BOLT12 seems to be to share information from A to B directly through some hops, in this case by routing over the lightning network.
The first thing to note in a lightning environment is that you must have something online to sign the transfer which I guess in this case is the lightning node. In Grin, we have a Slatepack standard (https://docs.grin.mw/grin-rfcs/text/0015-slatepack/) which does something similar.
When someone wants to send some coins from address A to B (address is an offchain information) it derives an onion service address from the address and attempts to share the information by trying to communicate with the onion url.
The other party needs to run the listener on the other end by running that onion service so it has a similar online requirement to the lightning network and it hops over Tor rather than the lightning network. This functionality is supported by the wallet.
If it succeeds in finding the service, the two parties exchange the messages over this communication channel, otherwise you receive an encrypted message for that recipient address to copy/paste to them on whatever communication channel you want (yes, manually copy pasting).

I think both LN and Grin are in the process of figuring out which transport methods work best and iterating on these. There will be something better than BOLT12 and there will be something better than Slatepacks, but both are a great start in the right direction.

Thanks for your insights! Regarding this point, honestly no matter how much I love Lightning, it's one of my biggest issues with it.
I've been looking for solutions (like BOLT12: https://bitcointalksearch.org/topic/testing-c-lightning-v0102-offers-bolt12-5383567) for a while now. The interactive element is eliminated (automated) once you run your own full node, but that is really a non-insignificant hurdle, especially for new users.
It's definitely easier setting a friend of family member up with a pure on-chain wallet, pointed to my private Electrum server instance, at least for the start.

But I've yet to fully look through the solutions Grin, Litecoin and others came up with and judge what looks acceptable and what doesn't.

Same as with any cryptocurrency. Not all have this "overtime supply fee" of Z-cash, but all have a hidden "first-to-acquire" tax. Or differently put: A capital appreciation advantage. That's why most developers prefer to create a brand new currency, and not focus on one that is already made, which is ironic if you think of it; open-source software means you don't have to give a solution to the same problem twice.

Monetary policy is what takes the cake. That's why the developers of Ethereum corp haven't defined one yet. Decisions that affect it are made accordingly to the stakeholders' benefits:

TL;DR, Ethereum (like most cryptos) is fiat.

This is what I am saying, if privacy technology was so good (and it changed drastically in last few years), than more people would mine and actually use zcash for privacy.
It just proves that same stuff would probably never be accepted or adopted in bitcoin blockchain.
I know Bitcoiners who want more privacy in Bitcoin but none of them want it the zcash-way.

PS
I mentioned 10% tax just to show zcash shady history, and when you have so much shady stuff, you can't expect their privacy implementations to be very good.
I'll at least give them credits for trying and testing stuff.

There you go. Once you introduce dev fees, it is extremely difficult to get rid of them from the protocol, due to founder's greed. Another reason why self-respecting decentralized currencies should not implement it.

The devtax was originally advertised as 10% of total supply, by 20% tax on first the 4 years which generates half of total supply.

But before those 4 years were up, they voted to extend it another 4 years, and now with the planned switch to PoS it becomes effectively 20% of total supply. So much for immutable monetary policy...

The most inline with Bitcoin design would be the Mimblewimble chain format because, unlike other designs discussed in this thread, it achieves better privacy by making the protocol simpler. It also comes with the simplest mixer which, as far as I know, is much more efficient than any mixer on Bitcoin.
I don't think Monero's ring sigs are worth considering at this point. The idea was very interesting years ago, but at least to me, it seems like a relatively bad tradeoff to make today. You're much better off adopting ZCash's newest z2z variant or something like a variant of Lelantus.

Btw, regarding drawbacks listed in Grin. Interactivity is a tradeoff rather than a drawback. Let me list some benefits of interactivity that are overlooked:

1. It allows one transaction flow to create all possible transactions (you can't build a payjoin or other multiparty tx with a noninteractive transaction)
2. Payjoins could in theory become the default behaviour (read more about payjoins here https://en.bitcoin.it/wiki/PayJoin)
3. Any transaction party can decide to bump fees if they want to speed up transaction inclusion in a block
4. Any transaction can provably commit to a document (with a multisig)
5. No more need for a test transaction before sending the money
6. In MW, the receiver proves the ability to spend the output when they receive it. It becomes impossible to send to an address whose private key was lost
7. Parties can pay for their own onchain objects e.g. if the receiver wants to create 7 outputs, they can do so, but they pay 7*output_fee + 1/num_participants*sig_fee

Benefits of interactive-only transactions (Mimblewimble design):

1. Every transaction comes with a cross-input-output-signature-aggregation
2. You get full wallet control - unlike in Bitcoin and other cryptocurrencies where you control only what you spend, you can actually control what you receive
3. No more taint/dust/ads output injection attacks
4. Potential for the unification of onchain and lightning transaction flows (or at least making these very similar)
5. You know which outputs you own can exist since you've created them. This means there's no need to scan the blocks for your outputs if you don't reuse the seed on multiple wallets e.g. a hot wallet on the mobile phone.
6. Since you create the outputs, it becomes possible to label the outputs at creation. Whether that's some kind of graph coloring, note keeping or something else

Drawbacks:

1. Cold storage becomes tedious
2. Exchange integration becomes more painful
3. Interactive experience (not necessary to be online at the same time)

Note that if drawback 3. is so bad that it can't be widely adopted, this means that neither can the lightning network because it also requires interactivity.
Point 1. and 2. are of such nature that a solution needs to be built once so it's really a O(1) cost and after this, you're good to go.

That's what I've been trying to say like 5 times so far already!
Bitcoin is not Zcash; exchanges need Bitcoin. If Bitcoin becomes private, they will 100% do their best to be allowed continuing to buy and sell Bitcoin.

This is not about the coin, it's about the technology.
I don't think them having rather centralized mining has anything to do with the privacy tech being bad, right?

Also that 10% 'tax' is not an inherent flaw that is tied to their privacy tech in any way, right?
I'm not interested in any of these coins to be fully honest; I just want to see which privacy concepts exist, what are the upsides / downsides, and which are best suited for Bitcoin.

Zcash is just a failed experiment, and I don't think any of their privacy solutions would ever be accepted in Bitcoin.
I don't want to turn this topic into shitcointalk, but I had to notice that zcash, despite all it's privacy tech, is heavily centralized coin.
Currently ViaPool has over 44% of total hashrate, so it's not very hard to perform attack on this network, and all this theater privacy would mean nothing.
Oh and what about 10% foundation reward shady tax, I forgot to say that before... 

There is no decentralized or peer-to-peer trading using shielded addresses? Then what's the point of Zcash?

No, the attacker couldn't because there's no exchange or trading platform that supports Sapling -> Sapling transactions. In fact most exchanges only allow trading the transparent pool.

Yeah, fair point. I've mentioned before about implementing script-path only taproot addresses. In that linked thread it was in relation to concerns that P2TR addresses were more vulnerable to quantum attacks then P2WPKH addresses. But at some point in the future we will probably have to phase out all addresses which reveal the public key, if not all addresses based on ECDSA altogether.

Sure, but there is still a risk that someone generates unlimited ZEC within the Sapling pool and simply keeps it all within the Sapling pool. Turnstiles only prevent that ZEC from leaving the Sapling pool. With unlimited ZEC inside the Sapling pool, the attacker could still use it to trade, sell for other cryptocurrencies or for fiat, to buy goods and services, etc., and it could be an arbitrarily long period of time before such an attack was discovered.

I disagree with this. If it became clear that the attack I outlined above had happened, and that there were millions more ZEC in the Sapling pool than expected, then the value of ZCash would tank, regardless of what pool your money is in. The coins of the users in the new Orchard pools would be protected from the rampant inflation by the turnstile, sure, but they wouldn't be protected from the general loss of confidence in the asset as a whole.

There's only a risk of unlimited ZEC *within the old Sprout/Sapling pools*. There is no risk of that unlimited ZEC getting out to either the transparent or the Orchard pool due to turnstiles.

So the only risk is to people who keep ZEC in the old shielded pools in case the turnstile prevents them from getting their funds out due to someone else having inflated funds moved out.


Disagree. The upgrade clearly means something with the turnstile protection and with the new address format defaulting payments to the Orchard pool.

That depends on whether wallets use Taproot correctly. Most will probably just set a public key and completely ignore the script path, because privacy gains only begin when you have at least two TapScripts.

Taproot is a brick and mortar, but by no means the finished building.

Only for people creating and using the new Halo 2 Orchard addresses though, unless I'm mistaken? Since the old Groth16 addresses are still in use and can still be created, funded, etc., then the risk of someone compromising the entire set up and printing unlimited ZEC in secret remains. Doesn't really make a difference if the addresses I am using are trustless, when the majority of the network are still using addresses based on the old system.

Zcash need to phase out all old addresses before this upgrade means anything.

---

On a slight tangent, how feasible do people think it would be to do something like this for bitcoin? If we phased out all addresses except taproot (for example), then there is a privacy increase there not just from the inherent properties of taproot but also by putting everyone in to the same anonymity set and breaking some forms of blockchain analysis, such as change address identification based on matching input/output script types.

As of their NU5 upgrade on May 31, Zcash no longer relies on a trusted setup [1] [2].

[1] https://www.coindesk.com/tech/2022/05/31/zcashs-nu5-upgrade-goes-live-boosting-privacy-and-removing-trusted-setups/
[2] https://zips.z.cash/zip-0224

But exchanges can afford to do that because Zcash and all its pairs make up a tiny amount of their volume. If all bitcoin transactions suddenly became 100% private tomorrow, the vast majority of centralized exchanges would either have to accept that or shut down since they would not be able to survive without the volume of bitcoin and its trading pairs.

Not to get too off topic here, but I agree. There is no doubt that Monero (or BitMonero as it was called at the time) had shady beginnings, but the fact remains that Monero as it exists today is open source, verifiable, and importantly trustless, which cannot be said for Zcash. To use Zcash, you must trust completely in the set up process and the six individuals involved in that process. This is a complete non-starter as far as I am concerned for any currency, least of all a currency which styles itself as a privacy currency.

Not unusual for shitcoin shenanigans  
It's just a company with workers and all other crap.
If I start to name all the shady stuff in zcash I would probably need days to finish exposing everything.

If you look my previous posts you will see that I said the same thing for monero, but they are still better than zcash in almost everything.
Some people even say that one country secret service (I won't name the country) is actually the one who is behind everything done in zcash.
Now if you look at nationality of some  scientists who worked on zcash and place they worked, you will understand better, it's not some anonymous guys like in case with Bitcoin.

Let's face it, nobody is using that crap for privacy, and you can easily confirm this onchain comparing number of transactions with everything else.
You can also look in Bisq exchange markets and you will see zec having zero volume there 

Seraphis explanation for those interested.

https://www.youtube.com/watch?v=fEJpE7LumG8

Which is exactly why enforced improvement in privacy doesn't necessarily translate to improvement in utility or improvement in fungibility. Banning Zcash from exchanges due to it being a "privacy coin", means that all ZEC are essentially tainted.

That's actually what Australia did, according to my employer (who is incorporated there).

See, lawmakers do not care about "normal address" and "private address" - they are both random strings of text to them, without a name and postal address.

Nothing unusual there.
Todd went on a long road trip [1], staying at an unpredictable motel, buying a disposable computer and thoroughly destroying it afterwards, generally making lots of expenses for which Zcash reimbursed him.
Snowden probably chose to make negligible expenses and declined to be paid.


If you want to talk about shady history, look at Monero's Cryptonote origins with the Bytecoin scam [2] and the purposely obfuscated inefficient miner software [3]...

[1] https://www.coindesk.com/markets/2016/11/14/zcash-and-the-art-of-security-theater/

[2] https://bitcointalksearch.org/topic/the-bytecoin-scam-a-continuation-4508322

[3] https://da-data.blogspot.com/2014/08/minting-money-with-monero-and-cpu.html

Yeah, I believe he was one of the six people, with pseudonym John Dobbertin, that participated in zcash ''trusted setup'' ceremony.
He said nobody paid him to be a part of this ceremony, but they did pay other people to participate.... all this is a shitshow because they had to make one more ceremony two years later to upgrade, and they will probably have more ''upgrades'' in future
Now even if zcash is to become without this trusted setup they will always have this suspicious shady history and it's never going to be widely accepted.
Bitcoin on the other hand never did such shenanigans, so privacy changes would be easier for people to accept.

I'm against blocksize increase, too, but I find it interesting to use extension blocks for MimbleWimble transactions.
Though on the other hand, it also feels a bit like Lightning or sidechains, where you add functionality (Lightning: speed and lower fees; extension blocks: privacy) 'on top' instead of 'Layer 1'.
It should be possible to prevent blocksize changes and only use these blocks for privacy, but I've got to read up on extension blocks further to understand whether that's an option.
As far as I know, in Litecoin hasn't increased their block size, either.

At least for Edward Snowden, it could be because he involved on Zcash creation. And when it happened, Monero still at rough start.


You're right. Here are few past discussion that i could remember,
Superspace: Scaling Bitcoin Beyond SegWit
Auxiliary block: Increasing max block size with softfork

While it's interesting approach, it's crude way to increase blocksize and add another technical complexity. IMO it'll never happen when increasing blocksize is the only goal.

Sure; because it's a low-volume altcoin. But good luck delisting Bitcoin..

Oh noes!  It's hard to build privacy, and easy to break it.. That's why a built-in mechanism would be so great.

I am really interested in reading more about silent payments and stealth addresses.
Stealth addresses have a lot of downsides though, and I don't really see a way to fix that. There must be another way.

For now, Litecoin's MimbleWimble implementation sounds the most interesting to me, but I believe extension blocks were extremely unpopular in Bitcoin in the past, weren't they?

Not as sad it is to load up your wallet on a public Electrum server by mistake, which unquestionably didn't happen to me today.

Or they would just delist Zcash from this exchanges, and they don't have to explain why.
I don't like Zcash for several reasons, and it has even worse history than monero, but some security experts like Edward Snowden thinks it's good for privacy.
Lightning Network is fine and more people is using it, but I am nor sure it's the best option for for transacting large amounts of money, and we don't know what tech Chainalysis and others are using from tracking.
Sad thing is that most people don't care at all about privacy until it's to late. 

I guess if you disable z2t by default, like tromp just said, they would kind of be forced to do allow depositing / withdrawing 'private coins'. With Zcash, they kind of have the power of choice as it's a lower marketcap and it's technically possible to go from shielded to transparent. But if we disable this on the by far biggest market cap asset by default, they kind of have to follow suit.

Even though Lightning Network privacy can be attacked, it's way more hidden than an on-chain withdrawal and history has shown that if the market wants e.g. Lightning withdrawals, exchanges will implement that. Even though it could make some regulator go all whiney-whiney.

Sure; big Bisq fan here, too - just trying to say I wouldn't be too worried on centralized exchanges' opinion on things when it comes to advancing Bitcoin to the next level if I may say so.

Because most exchanges I know only accept depositing and withdrawing coins to and from transparent Zcash t-addresses... there is nothing private about that.
If privacy for Bitcoin would be optional I suspect that not many exchanges would enable private deposits/withdrawals, but it certainly have much better chances than for ztrash.
Bitcoin is big enough for anyone to attack it directly, maybe that is why they started dealing with privacy stuff for ethereum and other shitcoins.

Most reported trading volume on centralized exchanges is fake and washtrading, even on Binance, so I don't trust what they are saying.
On the other hand, one of the the biggest volume in Bisq exchange is for XMR and you can't fake that so easy, or you can't disable and halt withdrawals.

Zcash currently allows all 4 directions between transparent t addresses and shielded z addresses: t2t, t2z, z2t, and z2z. I'm not sure how these qualifiers work if you have different types of inputs, or different types of outputs in one tx.
A first step to phasing out transparent addresses is to disable z2t, so once shielded you stay shielded. A second step is to disable t2t, so you cannot create new transparent outputs. I don't think you want to take either step in Bitcoin.


IMO a coin that values full auditability should keep private amounts optional, although one could argue that with ElGamal commitments, at least unconditional soundness is preserved.

Interesting. To be fair, layer 1 privacy upgrades for Bitcoin would always be optional or partial, too - since old UTXOs couldn't be magically 'made private' until they move, right?
But I guess depending on how it's implemented, every new UTXO after the upgrade could be private by default, without an option to disable that.

What do you think about that?
Are there existing concepts / ideas about the very question how to best 'add' privacy to an existing coin (in terms of what to do with pre-upgrade UTXOs and whether privacy can or should be optional afterwards)?

It's also possible they give up because many wallet don't support privacy feature or found out it took some time to create transaction. Even after few major performance improvement, it took 19 seconds to create transaction with 1 input/2 output on Raspberry Pi 3[1].

[1] https://garethtdavies.com/crypto/zcash-shielded-transactions-on-the-raspberry-pi.html

Obviously, because privacy is optional in Zcash.
Only a small minority (0.8M of 15M ZEC) of coins lives in shielded pools, and only a small fraction of transactions is z2z.

It seems most Zcash users are not interested in its privacy features, but hope to profit from other people's interest in its privacy features.

Why is Zcash not really a privacy coin?

According to CoinGecko, Monero is traded most on Binance - an exchange with 14 Billion US dollars in total trading volume over the last 24h.
I'm not an expert on centralized exchanges, but HitBTC with almost 2 Billion USD and Kraken with 500 Million US dollars total daily volume are also some pretty big names who list Monero. The latter I remember, recently introduced Lightning withdrawals; so it seems adding privacy to Bitcoin is certainly not something exchanges are completely shying away from.

As for Grin, indeed there's little volume and according to CoinGecko, over the last 24h, we see most volume on Bitforex and Gate.io (these names are new to me); KuCoin and HitBTC also list it but have barely any trades going on.
Anyhow, I am not convinced that exchanges even really care about privacy in Bitcoin or not; they just care about people buying and selling as much as possible.

I know that you didn't say that, but I'm pretty certain they can and probably already do engage in a lot of lobbying.

Zcash listed on exchanges is not really privacy coin, Monero is often not available for withdrawal from exchanges or it is delisted, and Grin has very low volume to have much bigger influence.
I didn't say that exchanges have the power to influence regulators, but they have power to support or not support new potential Bitcoin fork especially if they control bitcoin miners.
Remember what happened with Bcash and all other BTC forks, this would be like a small disturbance compared to adding privacy to Bitcoin, that is my opinion.

I doubt that; they sell and buy Zcash, Monero and Grin amongst other privacy cryptos, so why would a privacy upgrade to Bitcoin Layer 1 influence regulators any more than adding another privacy coin to their offer book?

If anything, large exchanges may (or already do?) even have the power to influence regulators and authorities through their lobby work.

Keep in mind that exchanges don't really have a say in what softfork is activated or not.

Just think how many Bitcoins are owned by Binance, Coinbase and other centralized exchanges and services, some of them even have their own mining pools.
I am sure they would be all be against adding privacy protocol changes for Bitcoin, because of the fear from regulators could hurt their business.
If they don't like mixers and coinjoin I could only imagine reaction to Bitcoin becoming privacy coin.

Apologies if I'm missing something, but I don't see how that solves the problem at all.

Whether or not Alice signs a message before making the transaction is irrelevant. Before the payment is made and the scam has taken place, then there is nothing to be gained by Alice signing a message saying she is intending to make the payment. After she has made the payment, the payment will be verified by a third party viewing the transaction, not by any signed message. And as you point out, with or without a signed message, Bob can still deny the receiving address is his.

Privacy coin or not, hidden addresses or not, without a signed message from the recipient confirming their payment address, there is always the possibility that they deny the address is theirs.

You can pre-sign incoming transactions of predetermined denominations from a hot wallet to a cold wallet,
and keep them stored in the hot wallet to be used at any later time. So it can be made to work with a few limitations.

I think if you look at my post and topic history, it's obvious that I love Lightning.
But I just don't think interaction is going to be accepted / acceptable on layer 1. Even on Lightning, where it's technically impossible to do away with interaction, mechanisms have been developed to 'hide' it - LNURL, BOLT12 are just two examples. People just don't like this..

Honestly, being able to have things like static invoices (BOLT12) is a huge creature comfort. Or being able to receive payments directly into a cold storage wallet.
By the way; does interactivity in pure MimbleWimble / Grin mean that basically cold wallets don't exist? Or has someone come up with a smart solution?

This is going to sound cliche, but BIP322 signed messages solve half of this problem.

- Alice signs a BIP322 message from the UTXO she's about to spend. This proves that she is able to spend it.
- Alice sends the payment to Bob.
- Bob denies receiving payment.
- Everybody who reads the BIP322 signed message knows that Alice sent the money to some address. But still nobody can verify that this is Bob's address without cryptographic proof, which Bob refuses to supply so he can feign non-payment.

(Now somebody might say why doesn't Alice simply put Bob's address in the BIP322 message, and show it to Bob so he can confirm, but that isn't going to work; Bob can still feign non-payment to everyone else.)

Strange to hear you denounce Lightning just like that...

If Bitcoin is to achieve any sort of mainstream adoption, and actual use as a currency, then most users will eventually be far more familiar with the interactive nature of L2 transactions than the non-interactive nature of L1.

Btw, another advantage I haven't mentioned is that multisig greatly reduces worries about mistyping addresses or sending to the wrong address, since the receiver must actually prove being able to spend received funds before being able to receive them. That gives much more peace of mind and mostly avoids the need for an extra "test" transaction of negligible value before a big value transaction.

Wow, we're already at 2 pages of discussion. Thanks everyone who chimed in so far - I'm catching up right now!

I opted to just add Grin since it implemented MimbleWimble first, from what I can tell. But if the implementation is different and these changes make its implementation more interesting for Bitcoin, I'll have a closer look there.

You think so? I believe some privacy upgrades could be implemented as soft fork.

What do you guys think about this, though? A hard fork would mean from then on, every UTXO would be private, on the other hand, old UTXOs would still remain 'open' - so might as well go for softfork (if technically possible)? I think that's an interesting question to discuss.


Great insight, thanks! I will add these points as drawbacks of ZCash and Monero. I personally think scalability should always be maintained and / or improved in Bitcoin to maintain maximum decentralization.

Interaction sounds pretty much like a no-go to me, to be honest. It's great to hear that Litecoin was able to solve this limitation - will definitely dig up and link some information about this.

I guess it's closer to L1 than L2.. but I get where you're coming from. Some aspects do happen off-chain (coordination of inputs / outputs), but in the end, you swap an on-chain UTXO for another on-chain UTXO. You never really 'leave' layer 1 for extended period of time compared to actually moving coins into a Lightning channel or a sidechain.

Interesting point that you brought up. I've thought about it a bit and there are certainly points for / against either point. Honestly, even with Bitcoin, I wouldn't know where to go complain / sue / ... if I went 'first' on a purchase and wouldn't get the goods - even though technically I could prove the payment. On the other hand, I don't think that a cryptocurrency that allows to prove payment would incur a big hit on privacy. Most privacy features would remain intact, like unlinkability of funds and payment history.

True, any UTXO before the soft- or hardfork would of course still be in the open. But the moment you spend it to a new 'privacy address' (or whatever) it would be 'gone' from the transparent pool basically.
Whether spending using a new, privacy-oriented technique can be enforced probably depends on the type of fork. But traditionally, I think we've all preferred softforks.. Most people happily switch to the new system, like SegWit, due to the obvious benefits it offers.

Realistically, nobody is doing that today, though (as I alluded to earlier) and they still send and receive Bitcoin for goods.

None, because I don't need to. I trust the merchants I transact with. But, even there was a need, a PGP message is not going to save a junkie. Alright, so Bob signs Alice his invoice, Alice sends him the bitcoin and gets no product in return. Now what? Why should I believe Alice for telling me she never got her product and not Bob yelling in craze that he gave it and that she's a liar?

Minimum trust is required. Probably that's why PGP isn't used in invoices.

Edit: No zero. I just looked into my emails and when I used CoinPayments they did send me one signed message of their invoice, and another of their receipt later.

Absolutely. And how many merchants, both online or in person that you have spent bitcoin with, use PGP? For me, the answer is zero. Even getting peer to peer traders to use PGP is a challenge.

And regardless, even if everyone did use PGP all the time, that's entirely separate to bitcoin itself. If you want to use PGP as a solution, then there is nothing stopping me from also applying the same solution to Monero, for example. You give me your Monero address via PGP, and I can release your address along with the other necessary information to prove I paid you: https://www.getmonero.org/resources/user-guides/prove-payment.html

Solution: PGP. Bob can't deny he asked for money if he signed it.

I'm not convinced that this is a drastically different scenario to what we already have in Bitcoin.

Alice pays Bob.
Bob denies receiving payment.
Alice publishes a transaction hash which anyone can look up.
Bob denies the receiving address in that transaction belongs to him.

If Alice is really lucky, she has some correspondence from Bob with the address in it which can be independently verified and which Bob cannot deny. On the other hand, there is a good chance the address was a one time address generated by a payment processor plugin on a website and she therefore has no independently verifiable record of the address.

What weed? I don't know what you're talking about, pal. Now pull over so we can get back on-topic.

No. Privacy isn't that, or similar to that. When I say I want privacy, I mean I want the ability to selectively reveal my activity to the rest of the world. That applies to the other party too. I can't forbid from the merchant to not reveal this activity since he's part of it. However, if both of us want to remain private, we must not leave some surveillance companies effectively tracing that activity and revealing it to the world without our consent.

Part of the discussion here should also be what privacy is and what it means to other people.
I think that if you are saying something is private the only way that it should be able to be revealed is if all people involved agree to it. Otherwise it's just hidden but can be shown. The old spy adage "Any 2 people can keep a secret so long as one of them is dead" comes into play here.

To others privacy just means it can't be found out by outsiders but anyone involved can reveal it.

To others it means that it can never be shown. It's done it happened but you can't prove it.
https://www.youtube.com/watch?v=WTbgsoHDc24



I'm stealing that line from you for future use.

-Dave

One thing that is deserved to be said is that no matter what privacy-oriented concepts, ideas, techniques are implemented in bitcoin, you can never achieve the same levels of privacy in comparison with privacy-oriented cryptocurrencies. The reason is simple: Their privacy model is enforced by default*, whereas in bitcoin, privacy enhancement is optional. Stones are set from genesis, and even though Monero (which is what takes the cake) experienced leaks on privacy, it still forms the best black-box-like electronic money out there, in sum.

*Z-cash excluded?

If you give me cash, and I don't give you weed, you can't prove you gave me cash. Yet, it's working fine centuries now.

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

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.


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.

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.



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?

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

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.

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.

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

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.


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).

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

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


Also due to longer block/transaction verification time.

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.

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.

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.


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.


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


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

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.

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).

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.

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.



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.

Reserved

Reserved

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)