Luke Dashjr

Need some way to avoid users trying to send a silent payment to a wallet that doesn't support it... am I missing something?

>When the recipient publishes their silent payment address, it needs to be clear that it is not a regular taproot address. The address format should be distinct. But I don't...

>Another approach could be that a silent_payment wallet only ever generates 1 key, perhaps with a new silent(pk) descriptor type. That might also make it easier for getnewaddress to spit...

>Not sure if I understand your question, but this scheme doesn't change anything regarding the sender/recipient relationship. The sender will know the tweaked address and the recipient will know where...

>You can label the tweaked address. It is part of the wallet. That seems like a bad design... it should show the silent address. But more importantly, for the recipient...

Many people don't receive only donations. If you have multiple clients, you need a different address for each so you know who is paying you.

> client could share txid in which he sent the payment Anyone could claim to have sent it. There is still no proof-of-sender in Bitcoin, and it doesn't look like...

Concept NACK. I think we're trying to eliminate file-based RPC methods? At the very least, we shouldn't make RPC methods that do *both* file-based and non-file-based access...

For that use case, I would suggest a RPC method that makes a watch-only copy of a loaded wallet.

What do we gain from this?