pull down to refresh
284 sats \ 6 replies \ @jeff 25 Oct 2023 \ on: Solving subscriptions on Bitcoin, one zap at a time bitcoin
Oh, no way! I was designing something super similar, completely independently! Didn't even know NIP-47 existed, let alone was getting traction!
I was working on a less resource intensive, more private-by-default, technique in my design philosophy.
Not sure if it's competing or complimentary to the approach you have here. Maybe the world needs both.
If I understand NWC, and the "billing address" analogy, then the billing address would then need to be "managed" by the user (and to maximize privacy, one would need to make one per vendor?) and then track it all by the merchant. Then, there would always be a risk that the list of these "billing addresses" would be leaked, and joined, exposing the users buying patterns.
If the NIP-47 design is a "one-to-one-to-one" solution (where merchants map invoices map to user's payments), then my philosophy was a many-to-one solution. Where users would pay a specific amount to the merchant, along with a DM containing proof that they paid that specific numbered invoice.
So, a merchant would have say a weekly subscription service, that users have to pay every week. The merchant would announce to the world "Hey, everybody that wants my service, send me a DM that proves you send a payment to pay for this invoice".
The user would basically create their own receipt, proving that they paid for this week's service.
Admittedly, this only works for fixed-price re-occuring bills. And, the merchant would have basically a sku-like idea to their billing. There would be a cron job running for each billing cycle, for each subscription-sku.
NWC is more of a way to deliver invoices to a user's wallet, rather than prove you paid a merchant. It works great for subscriptions because you can send directly to the user without the user having to remember to pay the merchant.
reply
Right! And I love it. I understand that it would work great. But I'm just saying there are privacy trade-offs. With NWC, a relay is incentivized to figure out all the billing addresses for one user, and then sell that list. The relay will basically have a honey-pot of a user's spending patterns. Assuming I understand the protocol correctly. Which, tbh, I haven't read it fully yet.
To simplify, NWC, has address-re-use privacy concerns, that could be reverse-engineered by a slightly ambitious relay. Have I got this part correct?
reply
No, relays can't interfere. These are encrypted requests.
reply
So the relays don't see a public key for the "billing address"?
reply
They just see encrypted DM's, that could be for any reason. But also, NWC dictates that a specific private/public keypair is used to communicate with the recipient. So even if they know a DM is meant for NWC (they wouldn't know), they couldn't do anything with it.
reply
Gotcha. I guess the relay would have to make more assumptions than I presumed, to get even crumbs of intelligence. Thanks for the taking her with me, Tony. Keep up the great work you guys are doing!
reply