this is a sorta placeholder and request-for-comment on the subject of transaction privacy triggered by some comments on Twitter by @RagnarLif . The questions it triggered for me we could discuss:
- How possible is it to implement transaction privacy (stealth addresses) on the Stacks blockchain?
- What are the pros/cons and risks of implementing this feature on Stacks - eg, politically, etc?
- How much user desire, importance is there for this feature?
- If it’s possible, would it be better to implement on a “privacy Subnet” versus on the Stacks base chain?
- Would creating an easy way for Dev’s to swap STX and BTC in/out of the XMR (Monero) privacy coin be better than implementing on Stacks?
This page I found useful for understanding at least the basics of how stealth addresses can work, particularly the images showing how the addresses/keys are used and combined.
cc: @jude is this even possible to implement on Stacks say with a Clarity contract?
2 Likes
This is very interesting and I agree with it in principle.
I think a Monero bridge feels like low hanging fruit.
I wonder what the legal implications are having something like this at the application layer vs the blockchain level.
1 Like
I agree that doing it on Stacks L1 could increase the risk of unwanted legal and gov actions.
My first thought was ideally, if possible, to implement this in a Clarity contract and/or a Subnet that app devs can use or not.
Is this feature and the possible use-cases it could bring worth the risks and effort at this point in time?
What problems do blockchains try to solve?
Wasn’t the intransparency of classic banking a big motivation for Bitcoin?
Probably coinjoins are possible as well on stacks.
1 Like
Yes, Stacks needs to improve privacy.
I’m not technical, so my contributions to the effort will be minimal. However, in September, I submitted a Foundation wishlist grant for privacy on Stacks:
This could be a data point or avenue for development?
2 Likes
In the above doc describing how stealth-addresses work there is mention of an “address scanner”, a kind of third pary sitting between tx sender and receiver, that’s needed to implement it. Given my crude understanding of how it works it looks like perhaps a Clarity contract could perform the Scanner role/functions. A core blockchain+Clarity guru would have to chime in here.
You can have transparency of a blockchain to validate and verify transactions while having privacy for users. Monero is the best example. Obviously, Bitcoin has the transparency of transactions with pseudonymous users. Unfortunately, Bitcoin isn’t very fungible, and protocol privacy is poor. To combat these, Whirlpool is a coinjoin tool that works OK.
1 Like
Privacy is extremely important.
2 Likes
I could see why in some cases you’d want to be able to see what’s going on at the base-chain layer so you know the token, esp Bitcoin, is not being inflated/corrupted. At the same time, this transparency is NOT good for individuals. So is this an argument for not having it on L1 while it’d be nice to have on L2 or just at the smart-contract or app layer where it can be optionally used by devs and users.
Coinjoins work OK, arguably, for some users but are there any with good API so devs can easily build it into their apps? A standardized way of doing this via contract calls and defined stealth-address format, functioning, would be helpful I think.
At a minimum, wallets should automatically generate a new address every time the user clicks “receive.” See the
screenshot of the Bitcoin white paper:
1 Like
sounds like a reasonable feature to open bug or enhancement issues on the Hiro web and desktop wallets on Github.