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.
Discussion
wen bolt13
Didn't know. That's a show stopper right there.
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
Well… don’t do that.
Tell Phoenix, “Hey! Don’t do that!”
Even your response seems like you understand that nuance matters in this topic
nuance does matter
This is relevant information for privacy folks and cypherpunks.
#Monero #Lihtning
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.
> 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.
Where can i find out about this? Just skimmed through bolt12 and couldn't find anything pointing me in the direction of understanding it.
bolt12 specifies, for Offers, a TLV of type: 22, value: 32 byte offer_issuer_id (i.e. a pubkey)
https://github.com/lightning/bolts/blob/master/12-offer-encoding.md
This is very much a misread of the spec. nostr:note1ehvw9rucz7jclm6r2pfn93wacuerqrl8l6e7yy7968upws5tr27qpryfwp
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.
Good thing I just made a CLN LNURL server that fetches Bolt11 invoices then...
You’re misreading the spec. Maybe ask someone who knows how things are implemented before running to nostr to post next time?
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.
I also cross-posted your correction on twitter so that it gets more visibility:
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
The point is that this is FUD and not true.
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.
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!