Replies (53)
Well, this will increase the traffic in the blockchain with small amounts of value / small utxos, and such increase tx fees in the future, won't it?
Nope. This is for big value transfer.
Can I use this to post a Silent Payment QR on my roadside produce stand?
Yep. That’s the idea.
Even better, you could just advertise your nip05 address and the payment app could independently generate the sp address. This would prevent QR code spoofing.
Great to hear. This is the future I want to live in.
Thx. But why shouldn't then a 'classical' silent payment be used in stead of a NSW? Sure one needs to present their silent payment address, but has a save wallet (e. g. Multisig), instead of a 'hot wallet' in nostr? Only because you instantly know someone's nostr silent payment address after proved npub?
*safe
This is a horrible idea. If it happens, it will cause a disaster worse than Anigma.
Use Payment Targets.
Excellent. semisol stamp of appoval! ✅
This is a payment target.
It’s not. Unlike a separately managed wallet, this is the same nonsense as onchain.
Silent payments via an external wallet work fine. Use them!
It's one payment target. It isn't payment targets. Implement kind 10133 payment targets and whoever wants Silent Payments can add them to there.
Yup, it's a payment target.
Silent Payments afaik don't support multi sig, right?
Now you just need a stable currency to pay with.
Is there a way to use Nostr as a coordinator for payjoin or coinjoin? Do these silent payment addresses help with developing these coordinators? I don't really know much but I get a feeling, There's a way to do some decentalized coordination via Nostr and the fact the identity is also the payment address. I think
@Super Testnet made or mentioned something called void wallet a few years ago which coordinates coin joins with Nostr.
GitHub
GitHub - brilliancebitcoin/void: A work-in-progress bitcoin wallet that only sends and receives coinjoins
A work-in-progress bitcoin wallet that only sends and receives coinjoins - brilliancebitcoin/void
This is VERY bad. The way that you have derived the spend and scan private keys can lead to total loss of funds and identity.
Gist
Nostr Silent Payments
Nostr Silent Payments. GitHub Gist: instantly share code, notes, and snippets.
NSFW? 😃
Not safe for anything.
You created secure messaging on Nostr?
Noooo!! Not the precious scan key. 😭 Check mate, silent payment supporters
Hey Jeff how come I can't message my friend on White Noise? It just spins forever
Don't take tbouma seriously. They've been spamming AI slop for a while; and they themselves are either a bot or have succumbed to AI psychosis
Just a few minutes ago, I was thinking about how - while LLMs are great for so much coding - they are simply unable to come up with new, safe, protocols. You've pointed out a good example of that
(I have an idea to fix this particular problem, but I don't want to help them 😀)
AI Slop
Derivation of sub keys is often overlooked. And people have tendency to even overlook password kdfs. Please use at least a single round of a currently approved hash like sha256 when deriving from a good entropy source. If the entropy is weak, a whole hell opens, but at least use a very strong kdf then.
The derivations give two more public keys that give the silent payment address. That doesn’t reveal anything. If you do the scanning yourself, you’re fine. If you use a service such as frigate, you have to trust the service because the non-hardened derivations can be used to derive the nsec. So you have to trust as any other service you are providing your nsec (unless you are using a signer).
But the main benefit of this approach still stands - it does provide additional protection to the donor.
Why would a Bitcoin SP user (normally with hardened derivations, not derived from nostr) voluntarily give their scan private key to a third-party server to scan for convenience? Wouldn't that defeat the whole point of Bitcoin SP as that third-party now has full view of what I'm receiving forever?
If anyone can derive the SP address from your npub, then anyone can derive your scan key from your npub? Am I missing something?
Nope. They can derive your spend public key and scan public key - that’s the sp address- not the corresponding private keys. Those need to be protected, same as the nsec.
But even sp address being derived from the npub; isn't it still deterministic and computable from the npub by anyone, which is the whole part of doxxcoin we are trying to avoid in the first place?
Yes, but the resulting addresses in the bitcoin transaction are computed by using the sender’s private key, that only the receiver, with their private key, can detect using Diffie-Hellman agreement- that’s the magic.
So the privacy is still only downstream? It reads ironic to me, but this whole thing may be going over my head so apologies if it is.
The address tying inputs to you is public. The outputs being private only changes the payment graph after the point.
100%.
Unacceptable bullying behavior. I've met Tim IRL.
The issue is that there is no way to derive a distinct key from an npub.
All tweaks are reversible by the server and so they can derive your nsec easily, so the electrum server would know your nsec (and that is why I compared it to Anigma). A list of candidate npubs’ tweaks can be subtracted and checked.
Even asking an LLM would have found this issue. Cryptography is hard to get right and so unless you have a good reason, don’t roll your own schemes.
If you do, do some research.
Just make a new keypair.
@grok is this true? 😂
> All tweaks are reversible by the server and so they can derive your nsec easily
You could *multiply* by the tweak 't', instead of adding +t*G, and that might be safer, because dividing by 't' is much harder than reversing the addition -t*G
I don't claim to like this proposal, nor that my idea is valid in this case; just throwing this out as something to think about. Cryptography is interesting and fun
Any integer x over GF(p) have a modular inverse x^-1 so that x * x^-1 = 1.
So the view private key v = H(S || “magic number”) * s (where s is your nsec, and S = sG = npub) can be reversed, by testing each possible S’, and if it holds, then it is the view key for S’:
S’ = H(S’ || “magic number)^-1 * v * G = H^-1 * H * s * G = sG = S
Then you can trivially reverse the key
s = H(S || “magic number”)^-1 * v
I address this issue in the security caveats. If you keep scanning local, no problem. If you use a scanning server, every key is like a root equivalent. BIP 352, because you have hardened derivation from the nsec, this is not a problem. With this approach, you do.
Gist
Nostr Silent Payments
Nostr Silent Payments. GitHub Gist: instantly share code, notes, and snippets.
I have never liked the approach of “fixing” security issues by just marking them out of scope.
Cryptography needs to be resistant to footguns. You should NOT be able to misuse without going out of your way.
This trivially allows that with a simple oversight
That looks like tonight’s homework. Thanks! I know there is a constraint with disclosing the tweaked private keys, but there should be no issue with deriving a sp address from a npub.
The better use case for this approach might be for machine identities (npubs) that are immediately ready to receive payments, the moment they are generated. I was trying to do something similar with Cashu/Lightning but this is way simpler and with no infrastructure.
Is a massive footgun worth it just to not publish 1 event or add it to an existing one
We’ll see. We can debate or we can experiment. I don’t know the final answer.
This is the machine-payments unlock. An npub that can receive privately at birth turns agents from API keys with opinions into actual economic actors. Dangerous amount of future in that sentence.
Already mutelisted after
Sad to see this might be their whole online personality.
Thanks for the write-up of that, semisol. Makes sense
I was thinking of multiplication in a different context, where it is sometimes a bit better than addition, but you're right that it doesn't help here
Multiplication is used in ECDH.
You have private keys a and b, and public keys aG and bG. An outside observer can't compute a*b*G (you can't multiply two points, and you would need to break ECDLP)
But, a can compute abG with a * (bG), and b can with b * (aG).
I know thanks. I was thinking about other contexts where they tweak by multiplying the public key by the tweak instead of adding it
If I remember correctly, multiplication is used instead of addition is used somewhere in Lightning
A' = t A
instead of
A' = A + tG
