10 sats \ 0 replies \ @jeff 30 Nov \ parent \ on: Bitcoin Uses Water? These are the same outlets that lie about everything else bitcoin
I observed the same pattern after I deployed my own solar panels on my roof. The reporting in MSM was complete bullocks.
I wasnt familiar with nodeless.
What was the illegal part? Were you converting + moving fiat too? Or was simply routing BTC enough to count as "money transmitter"?
Custodial BTC > Custodial-Anything-Else
Boom, Bust & Echo by Dr. K Foot.
It's a book about demographics.
If you buy a domain, you can have this repo/list hosted by github pretty easily.
Couldn't a blockchain replace a centralized certificate authority?
Bad take. Freedom of choice.
"Do you accept Bitcoin, YET?"
Not ironically, not sarcastically, just emphatically adding "yet", like its inevitable and strange that they dont.
That subtle "yet", makes them think for a split second.
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!
If time is money, how are they moving in different directions?
🤯
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?
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.
Microsoft Excel 2010
Everything after that, is just brutal unnecessary re-writes and designed-for-SaaS-features.