Replying to Avatar lontivero

IMO it is because BIP352 is in reality an alternative to BIP32 (HD) and that meansthat you have to compatibilize two key management strategies, scriptPubKey detection, labeling systems, indexing/indexers. Backups are also different from HD wallets. Also, other concepts like read-only wallets are not compatible/possible.

This introduces a lot of friction. Moreover, many libraries don't support what it is needed to implement it. For example, NBitcoin doesn't know how to sign a non-tweaked key. So, it is not sooo simple.

Anyway, I think it worths the effort.
Avatar
dangershony 10mo ago

How can you build a public Indexer for silent payments? unless you mean self hosted Indexers?

Reply to this note

Please Login to reply.

Discussion

Avatar
lontivero 10mo ago

The BIP352 has a section for Light Client Support.

Basically what a light client needs to detect an incomming Silent Payment is to calculate the sum of the inputs' pubkeys, that's all. So, if all the spending inputs were segwit or taproot client would be able to detect payments independently without the help of any indexer. However, for legacy scripts like P2PKH extracting the pubkey requires access to the prevout's scriptPubKey, something that unfortunately light clients don't have. That's basically why we need an indexer that provides the tweakData (in short, the sum of the pubkeys)

Avatar
dangershony 10mo ago

Ok but the receiver will still need the private key to identify an incoming 📨 payment.

Avatar
lontivero 10mo ago

Yes. Because the key generation involves a DH shared secret.