To the Math wiz out there, the ideal solution would be an SP address that can be derived from the pubkey directly in such a way that nobody needs to "set it up" with a supporting client.
The goal is...
From what I looked, i think yea it's possible to derive a Bitcoin SP address from a nostr key, though i think an agreed upon rule needs to be used so that the public can generate that BSP address (so whatever the NIP will it'll need to define it)
With that said though, I'd go ahead and not utilize Bitcoin SP for what I'm aiming for, but rather go with a simple tweak added in the current way a bitcoin address is generated from a nostr address, and from it a normal (random) bitcoin address is genreated (controlled by the receiver) to send btc to, and it's a normal address (so no need to worry about a wallet having SP support or not), and this can be applied to the other chains/shitcoins as well.
Now we're talking how a client does things: either automatically detect a transaction coming to this, and with an ephemeral key sends an encrypted message to the receiver, to their prefered relays, to inform them of the transaction + tweak, or the user clicks a button 'Tell Vitor you sent them money' (extra user info: Otherwise its as if you hadn't sent them anything and the money is lost).
Regarding zaps, for me I'd just go with private zaps on a post or profile that the receiver only sees and can confirm, but if we want a solution for 'public' zaps on-chain with silent type transactions, i'd imagine the only way to do so without revealing any info (even amount) would be for the receiver to send a confirmation event of receiving it, referencing the zap, and trusting that this happened, and not sharing the amount.
Regarding a ZK solution... I'm not sure what that'd be, but I'd imagine we'd need to add something to the transaction for this type of solution to work... perhaps. ZK in a lot of use-cases/situations is very hard (for me at least).
With that said though, I'd go ahead and not utilize Bitcoin SP for what I'm aiming for, but rather go with a simple tweak added in the current way a bitcoin address is generated from a nostr address, and from it a normal (random) bitcoin address is genreated (controlled by the receiver) to send btc to, and it's a normal address (so no need to worry about a wallet having SP support or not), and this can be applied to the other chains/shitcoins as well.
Now we're talking how a client does things: either automatically detect a transaction coming to this, and with an ephemeral key sends an encrypted message to the receiver, to their prefered relays, to inform them of the transaction + tweak, or the user clicks a button 'Tell Vitor you sent them money' (extra user info: Otherwise its as if you hadn't sent them anything and the money is lost).
Regarding zaps, for me I'd just go with private zaps on a post or profile that the receiver only sees and can confirm, but if we want a solution for 'public' zaps on-chain with silent type transactions, i'd imagine the only way to do so without revealing any info (even amount) would be for the receiver to send a confirmation event of receiving it, referencing the zap, and trusting that this happened, and not sharing the amount.
Regarding a ZK solution... I'm not sure what that'd be, but I'd imagine we'd need to add something to the transaction for this type of solution to work... perhaps. ZK in a lot of use-cases/situations is very hard (for me at least).