pull down to refresh

I recently started hearing about silent payments and it's lead me to reading BIPs

what I have come to understand

Silent Payents is BIP-352. Which describes the protocol explanation of how to look for silent payments in transactions.
I guess BIPs are descriptions of the protocol additions from the original whitepaper? The data is in the chain, and it's interpreted block-by-block to determine if it's valid for whatever BIPs are enforced by the validator.
Silent Payments requires wallets to provide support for the tweaked data (for the sender) and extra indexing (for the receiver).
This extra processing trades up to provide excellent privacy.

socializing an sp1 address for potential profit

In a supporting wallet, a reciever (Bob) generates a silent payment address. optionally a Label & Change Label for all the inputs a sender (Alice) might find.

the address looks like this

sp1qqweplq6ylpfrzuq6hfznzmv28djsraupudz0s0dclyt8erh70pgwxqkz2ydatksrdzf770umsntsmcjp4kcz7jqu03jeszh0gdmpjzmrf5u4zh0c
A sender (Alice) would put that address into her supporting wallet which would follow the protocol to derrive the on-chain, regular taproot address for the payment:
bc1pftjlgdq0ufhq7qwd0atxhrjhlnpmc8v4x50tgytygzk5rz339u6qngunq4
In a supporting wallet, Bob has a big list of transactions to scan for based on all the silent payment addresses he's generated. Bob also has the ability to restore these addresses deterministically (including their labels!!)

How it's working

In order for Alice to know where to send Bob money to buy whatever Bob was selling, and for Bob to be able to register payment of his money, the wallets they use need to calculate public Taproot address bc1... & corresponding Taproot signatures (in Bob's case) from the Silent Payment addresses sp1...
In order to accomplish this cool trick, Bob used two keys to generate the Silent Address. Scan Key allows Bob to know where to look. Spend Key allows him to know how to sign a given UTXO.
     scan_private_key: m / purpose' / coin_type' / account' / 1' / 0
    spend_private_key: m / purpose' / coin_type' / account' / 0' / 0

Implementations already available as of early August, 2024

Cake Wallet APKs available, also iOS Silentium PWA available

The future??

What do you think:
  1. Would you use a silent payment address?
  2. What are the outcomes of something like this that's widely used?
  3. Do you think these could these be used for privacy enhancing transactions that have inputs of KYC'd UTXOs? it seems like it to me.
"Do you think these could these be used for privacy enhancing transactions that have inputs of KYC'd UTXOs? it seems like it to me."
Are you saying that if you have a kyc utxo and you send it to a silent payment address it breaks the link between the utxos? If so could you explain in more detail?
My understanding is that this is a good tool to replace HD wallets with a few tradeoffs like the need to constantly scan new taproot transactions for incoming payments. I'm not convinced it does what you describe in point 3. It would be interesting if it did.
reply
tool to replace HD wallets
I think it depends on HD wallets (BIP32)
Key Derivation

Two keys are needed to create a silent payments address: the spend key and the scan key. To ensure compatibility, wallets MAY use BIP32 derivation with the following derivation paths for the spend and scan key. When using BIP32 derivation, wallet software MUST use hardened derivation[19] for both the spend and scan key.

A scan and spend key pair using BIP32 derivation are defined (taking inspiration from BIP44) in the following manner:

     scan_private_key: m / purpose' / coin_type' / account' / 1' / 0
    spend_private_key: m / purpose' / coin_type' / account' / 0' / 0
purpose is a constant set to 352 following the BIP43 recommendation. Refer to BIP43 and BIP44 for more details.
reply