Topic: Silent payments - page 4. (Read 2764 times)

Sharing an xpub is also a security risk, due to being able to derive all private keys from an xpub and a single private key.

How Silent Payments Are Bringing New Privacy Protections To Bitcoin

I think we've got it:
1) "b" is private, but can be non-unique if an address is reused
2) "SHA-256("txid:vout")" is public, but also unique
3) "b*SHA-256("txid:vout")" is private and unique at the same time
And when in the third case we will reach the same value, that would mean double spending of any kind, for example RBF (and it is a nice feature to preserve the same output addresses in case of any transaction replacements).

Nice idea. To make it computationally simple, all that is needed, is using "txid:vout" from the sender's input. That will be always unique, because each coin can be spent only once, so for the same recipient's public key, it will be tweaked in a different way each time.

It can be better than that. We could use z-value instead. Processing transactions is needed anyway, so by using z-value as an offset, it is guaranteed to be unique. And for Taproot addresses, we no longer have SIGHASH_SINGLE bug, so it will always be a hash of some transaction.

Edit: Also, to avoid circular dependencies, the output of the recipient should be cleared during calculating this z-value, so it will be some altered z-value anyway. Or we could put the real recipient key here, then reach this z-value, and then use that to do the tweak in the real transaction.

This can be solved by using R-value of the signature, instead of B-value public key. Then, address reuse would be automatically avoided, because it would mean that two inputs share the same k-value, so if d-values are also identical, this would leak the private key. Each safe wallet will use random k-value, that will be different each time.

The problem is not to have something that cannot be reused.  The problem is to have a means for people to publish information that can be reused to send money to them money, without any other communication between sender and recipient—without the horrific privacy wreckage of Bitcoin address reuse as it now stands.

We already have things that cannot be reused: transactions. It is technically possible to create a signed transaction, where some output is bigger than some input, sign it with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, and then, people can donate just by adding more coins, without invalidating signatures. Actually, this sounds like invoice, and is great when it comes to accumulating dust. The only missing part with such donations is that the creator have to specify the amount upfront, unless it is a donation to some miner, then it can be handled as a transaction fee.

For cryptocurrencies, privacy and fungibility are practically synonymous:  You can’t have either one without the other, and providing either one provides the other.

In practice, a lack of privacy literally means that 1 BTC ≠ 1 BTC.


The most important use case for Silent Payments is tip addresses, donation addresses, etc.  It is a very common and important use case.  This use case has never been solved in Bitcoin; I think that the lack of a solution is a flaw in Bitcoin.  Look around this forum at all the tip addresses in people’s signatures—observe all the donation addresses you see in static webpages.  These all incur the problems of address reuse.  The problem must be solved.

---

Zcash has strictly superior privacy technology, compared to Monero.  In the context of discussing strong privacy for Bitcoin (much stronger than Silent Payments), I addressed similar concerns accordingly:


See Tyler Winklevoss’ above-linked Tweet.  Do you suppose that he would renounce Bitcoin, if Bitcoin were to attain better privacy?

---

My exchange never did that.  (I use DEX.)

For those interested in learning more about silent payments and other similar proposals aimed at improving privacy of on-chain users, you should listen to this podcast:

https://bitcoinmagazine.com/technical/silent-payments-improve-privacy-without-bitcoin-data

"In this episode of “Bitcoin, Explained,” hosts Aaron van Wirdum and Sjors Provoost welcome Ruben Somsen back on the show to talk about his recent proposal for “silent payments.”

Silent payments resemble earlier ideas like “stealth addresses” and “reusable payment codes,” in that they allow users to publish a static address. While this is not the actual bitcoin address where they will be paid, senders of a transaction can use this static address to generate new bitcoin addresses for the recipient, for which the recipient — and only the recipient — can, in turn, generate the corresponding private keys.

Like stealth addresses and reusable payment codes, the benefit of silent payments is that addresses can be posted publicly without harming users’ privacy; snoops cannot link the publicly posted address to the actual bitcoin addresses where the recipient is paid. Meanwhile, unlike stealth addresses and reusable payment codes, silent payments do not require any additional blockchain data — though this does come at a computational cost for the recipient.

The podcast episode details this in roughly two parts. In the first half of the episode, Somsen, van Wirdum and Provoost break down how silent payments work, and in the second half of the episode, they discuss how silent payments compare to stealth addresses and reusable payment codes, as well as some potential implementation issues.

Provoost made a successful silent payment on the Signet Bitcoin testnet, but silent payments are not ready for mainnet use at this time."

I think you are right. Generally to track all incoming payments, you need a master public key from which all other public addresses are deterministically derived. To (re)calculate a particular address, you need two pieces of information, namely your xpub (ypub, zpub) and derivation path to the address. Anyone who has both can reconstruct the address and see all associated transactions. In some cases, one even doesn't need to know a derivation path. In silent payments, you also need only two pieces of information to calculate the address, one of which is a public key of the sender and the other is a private key of either sender or receiver. This requirement (having to have a private key) makes watch-only wallets impossible, let alone the fact that each particular sender creates unique private-public keypair for the receiver, which has no connection with other keypairs.

Hmm. You're not obligated to do a continual real-time scanning to make use of silent payments. Just scan the blockchain once a month, unlocking your wallet for a short time.

Alternatively, we can separate the silent public key into the "scanning key" and "spending key" to mitigate the security risk.

Xpub sharing is a way less efficient way of sharing a series of addresses than silent payments.
In the video, starting at around 33:23 those differences are analysed.

But the summary is: you should share your xpub only with those you are confident sharing your privacy with, as they would be able to track all your received payments scanning the addresses generated from such xpub.
Silent payments instead break this allowing you the total privacy (with the “scanning costs”).

I realized another drawback: the receiver needs their private key to check if they've received a payment. That makes a watch-only wallet impossible, and even if you use Bitcoin Core, private keys are stored encrypted until you enter your password. Keeping the wallet unlocked adds a security risk.

Thanks for the link to a video presentation. When I was writing about silent payments, I couldn't find any visual aids that would help me to understand this technology better. Could you briefly tell us about the advantages of silent payments over the common xpub sharing technique?

I would call silent payments a steganographic method of hiding information because it allows you to get lost in the crowd merely by making completely normal payments with no specific fingerprint. With silent payments you are hiding in plain sight.


It is true, unlike very controversial proposals like covenants, which I personally deem extremely undesirable for bitcoin because they make it less fungible and censorship-resistant, the silent payments technique doesn't require making any changes on a protocol level.

That is possible, but the whole point is that the address is mangled and used just once. That means it wouldn't matter that a specific amount is sent to an addresses - that's the only receive it makes anyway.

I see this as a feature mainly for wallets, not really for websites accepting BTC donations as you can't really make the address update on each load without some PHP or JS running in the backend, and most people won't see a reason to make their addresses that cumbersome.

I am popping in to share an article that was published by Bitcoin Magazine, that can help the less technical of us to grasp the basics of the topic discussed here.

IMPROVING BITCOIN PRIVACY WITH SILENT PAYMENTS

The article is very basic and originates from Marty Bent's newsletter, but they claim they will update it when more details emerge.

Another "not too technical" resource is the following one:



Where I got a very clear overview of this technique. And solved my first thought about this (why it is superior to "xpub-sharing")


Just a couple of things that caught my attention:

The irony is strong with this one:


The second reflection revolves also around the BIP119 drama. Silent Payments are techniques which don't require any new functions in the bitcoin protocol. It's a very elegant and effective technique to gain privacy from transactions and solve a real problem. What I mean, so much remains to be "discovered" using the current bitcoin protocol, we cannot risk anything implementing a new feature which is secure and scrutinised beyond any reasonable doubt.

That's a good point. Especially since you need to run a full node anyway when using a current implementation of what's described here (such as BTCPay Server). In this case, it's required to scan all derivation paths - up until the 'last generated address' - forever, since someone could get a new generated address from your site, save it and donate money to it a few months or years later. It can be 'attacked' by making the software generate thousands or millions of addresses, so you'll need to continuously scan for m/84'/0'/0'/0/1 to m/84'/0'/0'/0/918231812 from that point on, for example.
Though that's exactly what you're doing with silent payments as well, right. Check a few transactions per second (a few thousand per 10-minute interval) and match against all possible derivation paths based on your seed / public key, pretty much.

Besides the sender knowing the real address, since that's where they send their money; in Monero, the sent amount is encrypted and you can only observe from the outside that input and output amounts match. I'm not sure if the silent payments proposal includes something like this, but I'm pretty sure it doesn't.

---

All in all, it seems to me like this silent payment proposal is basically just going to move this 'feature' from application level (BTCPay) down directly into the protocol level. Since it doesn't change the requirements or effects compared to the current application level implementations (full node, always on, scanning basically just as much), I currently don't really see the need of it. Without need of blockchain scanning, it would be a nice addition for people who want to receive donations and don't (want to / can) run a node.

Generally, I believe it's universally accepted that keeping the 'base layer' compact and simple is better, unless it's absolutely needed. For instance, SegWit allowed to build Lightning and had many more new advantages, but it was a relatively compact change and it didn't change more than what was absolutely needed. Or also Taproot, which allows to do new things that weren't possible before (opposed to moving existing functionality to the base layer).

Yes! That was it.

You can't track her donations, because the address you will generate won't be shown to anyone else. Once an address is shown, it's never used again. You can of course attack her by generating billions of addresses, but that will only increase her children, and, therefore, make her monitoring more difficult. It's a similar problem to DDoS.

No need for that: the sender already knows the real address. It's not possible to send Bitcoins any other way.

https://bitcoinprivacy.me/coinswap-donations

I am not familiar with how BTCPay server works but can't I just attack Alice by pre-generating billions of addresses using her server and tracking all incoming donations? I definitely can't do that with silent payments since I have no private keys of other donations.