Did you know bolt12 only lets you have a static qr code if you reuse the same pubkey again and again? This is bad for your privacy and allows companies like Chainalysis to offer a transaction monitoring tool for lightning. Bolt12 considered harmful.
Login to reply
Replies (35)
Good post. This should also be an issue with bolt11 though, right?
#siamstr
View quoted note →
wen bolt13
Didn't know. That's a show stopper right there.
This is relevant information for privacy folks and cypherpunks.
#Monero #Lihtning
Did you know bolt12 only lets you have a static qr code if you reuse the same pubkey again and again? This is bad for your privacy and allows companies like Chainalysis to offer a transaction monitoring tool for lightning. Bolt12 considered harmful.
View quoted note →
What is the contrast here? Static QR codes for invoices can't be done at all with BOLT11. And how is this related to privacy? Blinded paths is often the feature associated with increased (receiver) privacy - and those can be done with BOLT11 as well.
Where can i find out about this? Just skimmed through bolt12 and couldn't find anything pointing me in the direction of understanding it.
probably, thanks to hop hints
bolt12 specifies, for Offers, a TLV of type: 22, value: 32 byte offer_issuer_id (i.e. a pubkey)
GitHub
bolts/12-offer-encoding.md at master · lightning/bolts
BOLT: Basis of Lightning Technology (Lightning Network Specifications) - lightning/bolts
Good thing I just made a CLN LNURL server that fetches Bolt11 invoices then...
Did you know bolt12 only lets you have a static qr code if you reuse the same pubkey again and again? This is bad for your privacy and allows companies like Chainalysis to offer a transaction monitoring tool for lightning. Bolt12 considered harmful.
View quoted note →
This is very much a misread of the spec. View quoted note →
Indeed
You’re misreading the spec. Maybe ask someone who knows how things are implemented before running to nostr to post next time?
View quoted note →
What is the point of bolt12 then?
Does it just hide your actual pubkey? I don't get it
Now that you mention it I think I remember you mentioning something about this on Vlads podcast recently
Nuance
View quoted note →
The point is that this is FUD and not true.
Nuance all you want, the same applies: you should make a new payment string for every service
wallets like phoenix encourage bolt12 reuse across different services (by only letting you have one bolt12) and this is bad for privacy
I appreciate the correction you offer in the post I reply to below, and I think this is a good recommendation: for good privacy, don't reuse a bolt12 or any other payment string across multiple services. Instead, make a new payment string for each service you use.
View quoted note →
I appreciate the correction you offer in the post I reply to below, and I think this is a good recommendation: for good privacy, don't reuse a bolt12 or any other payment string across multiple services. Instead, make a new payment string for each service you use.
View quoted note →
I appreciate the correction you offer in the post I reply to below, and I think this is a good recommendation: for good privacy, don't reuse a bolt12 or any other payment string across multiple services. Instead, make a new payment string for each service you use.
View quoted note →
Well… don’t do that.
Tell Phoenix, “Hey! Don’t do that!”
I also cross-posted your correction on twitter so that it gets more visibility:
https://x.com/super_testnet/status/1894009493068906633
Even your response seems like you understand that nuance matters in this topic
View quoted note →
> What is the contrast here?
I don't think I'm making a contrast. I originally said that bolt12 is bad for privacy if you reuse it, because it involves reusing a pubkey over and over again. After a correction from Matt, I slightly revise my point: it's still true that bolt12 is bad for privacy if you reuse it, but that's not because it involves reusing a pubkey over and over (though it does), it's because you're reusing *anything.* For good privacy, never reuse any data across two different services.
nuance does matter
Reusing BOLT12 offer per inflow = Good
Reusing BOLT12 offer for multiple inflows = Bad
Just create an offer PER each usecase.
yes, but phoenix wallet makes that hard. To make a new bolt12 in phoenix wallet, you must create a new wallet and pay for more inbound capacity. This disincentive encourages payment string reuse and is bad.
Yes, using embedded node wallets that use backends that aren't yours ARE hard to control. I use my own CLN node to create any offers I want. Maybe direct this criticism to Phoenix and not the BOLT12 spec.
Amen
Agreed, the problem is Phoenix's implementation, not the bolt12 spec
I was also under the impression that phoenix's implementation was "the way it worked". Thanks for clarifying this!
Yo, I hear ya! But for real, what’s the best way to get clued up on the specs before I dive in next time? 🤔💭 #LearningCurve
Tried bolt12 between two separate phoenix wallets ... Sent more sats than I should have been able to (according to inbound liquidity available)... Maybe I misunderstand, but if so, that seems like a killer feature/tradeoff?!