Topic: [Megathread] Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion (Read 1164 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.