I mean, I could be wrong! Its been awhile since I studied the LN standards in depth.
Yes, there's probably a perfectly good way to do that. I'm not a front end dev though, so I haven't spent the time to figure it out.
Re: usage, people are likely making something like 1 to 10 timestamps per second average with OpenTimestamps. I can't tell for sure though, as people making large numbers of timestamps per second can (and should!) aggregate their timestamps with merkle trees on their end.
As far as I can tell timestamps have pretty much never come up officially in the US federal court system. But that doesn't mean they're worthless. Quite the contrary! It probably means they're so strong that no-one has been foolish enough to contest one in court rather than just settling.
Maybe you need to have a chat with your wife about what kinda of relays she's frequenting.
(A positive chat I mean; obviously you might want to use those relays too)
I thought we fixed that issue? Or am I thinking of a different issue?
I would expect invoice creation to result in a disk IO, as I'd expect it to write the invoice data synchronously to disk as a power outage at the wrong time could otherwise cause issues. But maybe it delays that until payment happens. Maybe.
Yes, it's particularly bad for OTS calendars I do want the invoice to be right there to make it easy to donate. But I don't want to enable third parties to trigger disk IO as they run on cheap VPS's with relatively bad disk performance.
I got Lightning donations working as again on the https://alice.btc.calendar.opentimestamps.org/ and https://bob.btc.calendar.opentimestamps.org/ OpenTimestamps calendars.
If you'd like to donate, go to either of those URLs and use the Lightning invoice on the page. That's much appreciated, as tx fees and VPS servers all cost me money.
...the only catch is the way those invoices are implemented is hilariously shoddy: I have a watch job that makes a new LN invoice every few seconds. And I turned on garbage collection of expired invoices¹ in my lnd configuration. So there is a small chance that you'll get an invoice that was shown to someone else already.
I didn't want to generate a new invoice on every visit, as I'd need to figure out how to properly rate limit it so as to not open up a DoS attack. In practice people don't donate anywhere near frequently enough for this to matter. So good enough for now.
1) gc-cancelled-invoices-on-the-fly=true
The only problem with that policy is you can't pay for your verification anonymously using Bitcoin. Or at least dogecoin...
Amethyst for the win.
Now I'm curious why you are seeing porn and I'm not.
Currently eSIMs kinda suck. If they fixed them so you could have an unlimited number of eSIMs, that might be different. But for now they're terrible.
This is why I travel with a little pill container full of sim cards...
In th future, chatgpt will be used to reject your shitty code.
If you are a sufficiently good stalker, you should be able to figure out where I went today. 😂
Reading English sucks even more for consensus critical protocols. It's extremely difficult to be sure you've interpreted an English specification correctly; code specifications can at least be executed to check if your understanding is correct.
Bitcoin has "official" specs: the C++ source code of Bitcoin Core.
That's the thing you need to match in reality. And getting that bug-for-bug compatible is a nightmare that no one has ever perfectly achieved.
We don't know what the dealers paid for it; prices of illegal drugs aren't uniform.