Silent payments

[witcher_sense]

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.

If, and only if, the recipient also obtains a single private key from your wallet, the recipient can obtain all your private keys and steal your funds, just as if they had your xprv key.

As far as I know, this only applies to non-hardened derivation schemes, where it is possible to calculate parent keys by combining chain code with the child's private keys. In the case where the derivation process is hardened, an attacker would need your master private keys to calculate child keys, or parent private key to calculate a child key. All backward derivation won't be possible when derivation is hardened. In the case of silent payments, however, you don't share your xpub at all, replacing it with a deterministically derived silent payment address, which is basically a hash of a public key (not a master public key) encoded in a special format. In the latest implementation, it was proposed that silent payment addresses should start with the "sp1" prefix.

[1714752585]

1714752585

[1714752585]

1714752585

[1714752585]

1714752585

[1714752585]

1714752585

[n0nce]

In the case of silent payments, however, you don't share your xpub at all, replacing it with a deterministically derived silent payment address, which is basically a hash of a public key (not a master public key) encoded in a special format. In the latest implementation, it was proposed that silent payment addresses should start with the "sp1" prefix.

I know; just wanted to point out that xpub sharing (as alternative to silent payments) is not only less private but also potentially insecure.
Where can I find more information about the latest implementation or proposal? I'm interested to see what the creators think / how they handle SPV wallets and the complexity / burden of scanning for transactions.

Your schema remember me what in Monero is called Stealth Addresses:

Maybe this can be useful to compare the ideas:
https://www.getmonero.org/library/MoneroAddressesCheatsheet20201206.pdf

Yes, this is exactly what sprung to mind when I read this proposal. In my opinion, the biggest disadvantage - just as in Monero - is the need for transaction scanning.

[witcher_sense]

Where can I find more information about the latest implementation or proposal? I'm interested to see what the creators think / how they handle SPV wallets and the complexity / burden of scanning for transactions.

https://gist.github.com/w0xlt/a7b498ac1ff14b8c292a22be789bd93f

[NotATether]

Where can I find more information about the latest implementation or proposal? I'm interested to see what the creators think / how they handle SPV wallets and the complexity / burden of scanning for transactions.

https://gist.github.com/w0xlt/a7b498ac1ff14b8c292a22be789bd93f

That's the same implementation as in the original spec. Hardly anything has changed since then.

It would be interesting to see a silent payment implementation outside of Bitcoin Core.

[witcher_sense]

A pull request has been opened for adding Silent Payments to Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/27827

This PR implements the basic silent payments scheme. In particular:

    Adds support for existing wallets to send to silent payment addresses
    Adds support to the Bitcoin Core wallet for receiving silent payments

The following items are not covered in this PR and are intended for follow-up PRs:

    Adding labels for the receiver wallet
    Creating multiple outputs for the same silent payment address when sending
    Full RPC coverage (only send is covered in this PR)
    Light client support (vending the tweak data per block, either in an index or to serve to an indexer, such as electrum server)
    Add benchmarks to validate that there are no DoS concerns for doing silent payment verification for transactions in the mempool
    More unit / functional test coverage