0 sats \ 0 replies \ @kandycoder 17 Oct 2023 \ parent \ on: Accept Bitcoin via Lightning for a merchant with a read-only solution? bitcoin
Yeah, being able to configure it with the invoice key instead of the admin key is ideal in this case. Just use something like BlueWallet with it. Or, OP's friend can get LNbits API integrated into his existing app, and then configure each cashier's instance with the invoice-only key. And if he wants to self-host LNbits or switch LNbits providers later, piece of cake.
Code can be brutal law sometimes. It gets gray when there is a mistake and the wrong person is in possession of data (i.e. funds) that do not "rightfully" belong to them. (Granted this hinges on the definition of "rightful".) In such a case you have no other recourse than to appeal to a real-life court or appeal to the honesty and goodwill of the adversary. The recent mishap with F2Pool is an example that I think showed the Golden Way. I don't agree with those who said F2Pool should have kept the incorrect fee; when the tech enforces brutal justice, it devolves upon human beings to show mercy. As this brings out the best in people, it obviates the need for courts, and I think that is a beautiful thing. But a dog-eat-dog world without courts where code is law could be extremely harsh. The moral of the story is: let us all strive to live in a way that makes courts unnecessary.
Undecided for two competing reasons:
-
On the one hand, socializing the cost of storing one's assets feels like a very un-ethical and antithetical thing to Bitcoin.
-
On the other hand, the freedom to "speak" on the blockchain began with the Genesis block and is part of the Bitcoin ethos.
Would like to see a compromise implemented that addresses both of those points.
EDIT: Just saw this and I think maybe it's going in the right direction: https://thebitcoinmanual.com/articles/what-is-ordisrespector/
It seems anonymous posting would enable something similar to MLK's dream, where a post is judged not by the reputation (color) but by the character of its content. I just wonder if such a world could successfully mix with a reputation-based world or not.
Please, how can I look up those notehashes (pardon my ignorance)?
Perfectly written and excellent excerpt. I am curious about something related to this topic: has anyone done a study on how increasing difficulty might have (or might in the future have) an effect on block regularity? Intuitively, it seems to me that as difficulty continues to increase, eventually the time between blocks will become more irregular due to the corresponding scarcity of hash solutions for higher difficulty levels. Hopefully that day would be in a galaxy far far away, but it would be nice if we have insight on that, and to know where we currently are on the scale of block regularity.
Well said. I first thought it was a bad idea, but now I think the worst thing that can happen is that fees go up to the point that Bitcoin becomes prohibitively expensive for those who are not already established in the space. I believe the door of opportunity is closing fast, and soon there will be a wall of separation between the wise who value freedom of speech and the fools who will HFSP.
Agree. Wish a lawyer would comment on how this might work together with the current legal systems of the world.
Interesting, thanks for sharing.
The UX challenge in my version is definitely real, but let's explore it a bit. I originally had the idea of "pinning" so that any UX pain due to disambiguation could be minimized to the first visit, but perhaps even that could be significantly improved. In a Nostr setting, the popularity rank could be scoped to the relay. Community-centric popularity rankings (i.e. having your client sample from its favorite relays) could have nice advantages, and at the same time mitigate that centralization danger. Clients could automate disambiguation in many cases to minimize UX pain (and should lock-in so users don't get unsuspectingly surprised by a different same-named domain on a future visit). UX/UI would definitely have to be in focus.
Such a radically new paradigm as non-unique names would have costs / trade-offs. Perhaps the best middle ground would be for clients to forever support both ends of the spectrum (traditional DNS and non-unique naming). The advantages of trad DNS would remain, while a non-unique naming system would provide an escape valve to discourage from and protect against power structures abusing the more authoritative DNS system. Relays could even inform their own ranking based on the existing DNS system for seamless transition. That is to say, if I control a mysite.com registration in both trad DNS and on the Bitcoin blockchain, then I would keep both up-to-date. If a divergence happens, the hybrid system would seamlessly failover to the non-unique naming system, still pointing clients to my intended site. This would also facilitate a painless transition from trad DNS to non-unique naming without any ugly UX disambiguation for text-book cases. In cases where no such authoritative link exists (such as brand-new Bitcoin-only registrations), your "first come, first served" approach could be applied as policy, not requirement. This would relegate manual disambiguation to an available option / feature, rather than making it an obstacle to acceptance.
In that sense, the "non-unique" part (of this newly coined term "non-unique naming") would serve mainly as the relief valve, but would not get in anybody's way. Spoofs of google.com would never bother anyone because they would have to be sought out. First-time registrations would have priority, but squatters could still be circumvented with community support through manual disambiguation until relays quickly get the hint and switch over to the more popular site.
Totally agree on UX issue. I originally had the idea of "pinning" so that this UX pain only needs to happen on first visit. Still not ideal, though.
I also totally agree that permanent exclusivity suffers from an opposite problem.
I've been toying with an idea that changes the paradigm with respect to the two critical problems mentioned above: Just allow multiple registrations of the same name, and let the user disambiguate, and allow the user to "pin" the one that is relevant.
-
Squatting would probably be solved, because common names that are over-registered would intrinsically lose value.
-
Scamming might be solved, if people could distinguish by popularity rating.
-
Relay records could be kept truthful by requiring updates to be signed by the owner as determined by the Bitcoin blockchain.
-
This solves the problem of lost keys, because a new registration could simply replace an old one, and eventually the old one would become stale and drop out of relevance. (Of course such things as the popularity rating would restart, but that's probably a good punishment for losing one's keys.)