Nostr Web Client

This isn’t specific to BOLT 12 and is really stretching the line on accuracy.

Yes, if you reuse a BOLT 12 across two companies they can compare notes and see that you used the same one (duh!), but it’s not “because you reuse the same public key”, it’s because it’s the same thing!

But, of course, you don’t *have * to do this. Wallets, by default, should generate a fresh BOLT 12 every time they display the receive key (and LDK will every time the wallet asks for a BOLT 12), including fetching a different “offer_issuer_id”.

Ultimately, don’t assume things just based on the name of a field in a spec - the “offer_issuer_id” is a misnomer, LDK actually has a different name for it because of this, and IIRC the spec even says don’t reuse it if you’re a regular end-user wallet! nostr:note197dwq5alqrxcyjvjk9yds63pzj07a2t83tjacxzdp53uux73t5hsdtuk8f

Reply to this note

Please Login to reply.

Discussion

Super Testnet 10mo ago

It's good to hear that ldk gives you a new bolt12 every time, I think that's what all wallets should do

> it’s not “because you reuse the same public key”, it’s because it’s the same thing!

True, I agree, the problem is reusing the same payment string across multiple accounts, regardless of whether that payment string unwraps to a bolt12 or an lnurl or anything else

For every new account at any service, you should make a new payment string

Peter Todd 10mo ago

It the service knows who you are it's not very important to give them a new bolt12 invoice. That's doubly true when they have a personal relationship with you, eg my consulting clients.

Super Testnet 10mo ago

> It the service knows who you are

Good clarifying words

I was particularly thinking of robosats, which is a service that (1) doesn't know who I am (2) they recommend (and facilitate through their UI) creating a new account for every transaction

On a service like that, I think it is also wise to create a new bolt12 for every transaction (and thus every account), because otherwise they can correlate two different payments and build a profile on you that way

vnprc 10mo ago

Mining pools should not know who you are. 👀

Matt Corallo 10mo ago

Sadly in lightning if you’re doing repeated payments, even with a fresh BOLT 12 each time with blinded paths, in practice you can probably group most outbound payments :/

vnprc 10mo ago

Dang, ok

Super Testnet 10mo ago

how? what info lets you group them?

Matt Corallo 10mo ago

Not thinking of one single thing, but there’s plenty of ways fingerprinting different users is likely possible. If you have 10K withdraws per user you can probably cluster the blinded paths many of them are using, add on top features which may identify specific clients and you can probably do pretty well. Obv you can’t tell the difference been any two invoices for different Phoenix (or other wallet with a fixed LSP (set)) wallets, but across wallets I’m skeptical it’s robustly private.

Super Testnet 10mo ago

sounds like a fun thing to test for a hackathon project

Matt Corallo 10mo ago

Sounds more like a six month academic research project, but 🤷‍♂️

vnprc 10mo ago

Thanks for clarifying this, Matt. I was under the same impression as Super.

Matt Corallo 10mo ago

It’s a bad name for the field in the spec!

e5bab168... 10mo ago

Somewhat related user question. Hoping when a channel is closed that all associated BOLT 12's cease to function, ie, they return an error if used as opposed to any loss of funds. Is there also a standard way to disable individual BOLT 12's while still maintaining the channel?

Matt Corallo 10mo ago

If a sender cannot reach a recipient (which shouldn’t happen just because a channel is closed) the payment will simply not complete and the sender will keep their money. If you want to mark an offer as unpayable you’d have to check with your specific lightning implementation to see if they support that feature.

e5bab168... 10mo ago

Thank you for this information! 🙏