> nothing in Bitcoin prevents someone from generating the wallet of someone else
Maybe nothing in Bitcoin does, but among many other things the heat death of the universe does. The probability of finding a key of a secure cryptography scheme by brute force is purely of mathematical nature. It is low enough that we can for all practical intends just state as a fact that it will never happen. Not just to me, but to absolutely no one on the planet. All security works like this in the end. There is no 100% guaranteed security in the sense of guaranteeing that an adverse event will not happen. Most concepts in security have much lower guarantees than cryptography.
LLMs are not cryptography and unlike with many other concepts where we have found ways to make strong enough security guarantees for exposing them to adversarial inputs we absolutely have not achieved that with LLMs. Prompt injection is an unsolved problem. Not just in the theoretical sense, but in every practical sense.
> The timestamp is expressed as UTC seconds since 1970-01-01
That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those shift with leap seconds unlike TAI which is actually just the number of seconds that have passed since 1970001Z)?
It says: CAs MUST properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.
Do leap seconds even matter here? Doing anything involving DNS or certificates in a way that requires clock synchronization down to the second would seem to be asking for trouble.
Abolition of the Leap Second is basically a done deal. So, the differences caused by leap seconds will become frozen as arbitrary offsets, GPS time versus UTC for example.
Basically when it was invented leap seconds seemed like a good idea because we assumed the inconvenience versus value was a good trade, but in practice we've discovered the value is negligible and the inconvenience more than we expected, so, bye bye leap seconds.
The body responsible has formal treaty promises to make UTC track the Earth's spin and replacing those treaties is a huge pain, so, the "hack" proposed is to imagine into existence a leap minute or even a leap hour that could correct for the spin, and then in practice those will never be used either because it's even less convenient than a leap second - but by the time they're asked to set a date for these hypothetical changes likely the signatory countries won't exist and their successors can just sign a revised treaty, countries only tend to last a few hundred years, look at the poor US which is preparing 250th anniversary celebrations while also approaching civil war.
I tried to think about and leap seconds on their own don't seem to be a real problem. The problem is that leap seconds, minutes, hours, days, years, etc are a human interface concept and therefore only make sense to humans, but we've decided to force machines to deal with these human interface concepts as the primary way of dealing with time, when only the presentation layer should even know what a leap second is.
Leap seconds are not a human interface concept. Humans don't care. People who haven't thought very hard about this tend to believe humans care but they don't.
If humans cared the existing systems couldn't exist. For more than a century we've all lived with time "zones" which are thousands of seconds wide and we're not bothered by that. Many of us have civil time systems which shift twice per year by 3600 seconds for really no good reason, and while that's annoying it's barely worth a brief mention on TV news or in small talk. Leap seconds are 3600 times smaller and happen way less often, they're entirely negligible.
They existed because we thought we cared, and we actually don't care, and we thought it was pretty easy to do, and it actually wasn't very easy after all.
The October Revolution being in November is because of a different drift problem. The Calendar drifts because the Earth's orbit isn't a whole number of days, so any attempt to have fixed length years drifts noticeably over just a few decades, the initial fix ("Julian" calendars) had the compensation factor wrong, and countries adopted an improved calendar ("Gregorian" calendars) at different points leading to that offset between Old and New dates.
The leap second is because the Earth's spin varies. The orbit isn't varying significantly, it's just not a whole number of day-night cycles which is inconvenient for us, but the spin actually varies. To "fix" this variation we have leap seconds. But unlike the very noticeable October versus November difference, a century of missed leap seconds adds up to much less than a minute of difference between solar time and civil time, and that's not something you'll actually notice.
I'm aware of the different periods involved (I have a degree in astronomy), my point is that because the Russian Empire put off the switch for so long the difference became a historical joke. Similarly, I would suggest that it is generally best practice to make small changes quickly rather than large changes slowly. So why is it in the case of leap seconds (given we can and do perform measurements below the second scale to take account in variations in local and global gravity) are we seemingly unable to handle something so trivial?
Probably yeah, seconds don't really matter here. You would have to work hard for the 27 second difference to be material. But precision is nice.
unixtime is almost certainly what is meant by the standard, but it is not the count of UTC seconds since 1970; unix time is the number of seconds since 1970 as if all days had 86400 seconds. UTC, TAI, and GPS seconds are all the same length, and the same number have happened since 1970, but TAI appears 37 seconds ahead of UTC because TAI has days with 86400 seconds, while UTC has some days with 86401 seconds and was 10 seconds ahead of UTC in 1970. unixtime and UTC are in sync because unixtime allows some days to encompass 86401 UTC seconds while unixtime only counts 86400 seconds.
> Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.
I like that they are integrated into the terminal and stay in the terminal. For most things my terminal multiplexer is essentially my tiling window manager and everything that breaks out of that via its own window is very unergonomic and breaks the structured logic of my workflow. Technically just having a full GUI inside the boundaries of a terminal would be fine for a lot of things. But it's also one of these things where constraints make a lot of things better. Many GUIs are just really bloated and bad. TUIs just do not allow a lot of the sins of modern GUIs.
I agree that they can get very clunky for non text based tasks or anything where you actually need custom text formating.
If you have something to add to the conversation then just do that. Don't make bad faith interpretations and unsubstantiated accusations against people.
>If you have something to add to the conversation then just do that. Don't make bad faith interpretations and unsubstantiated accusations against people.
You mean like you just did?
Tipping culture in the US is absolutely rooted in bigotry[0][1][2][3][4][5][6][7]. That's not a "bad faith interpretation," it's well-documented history.
The bad faith interpretation is claiming that tipping is racist, not providing any evidence for it, claiming that OP knows that it is racist and supports it for that reason.
>The bad faith interpretation is claiming that tipping is racist,
That's not a bad faith interpretation, the origins of tipping in the US are absolutely based in bigotry.
>claiming that OP knows that it is racist and supports it for that reason.
A fair point. GP certainly did not assume good faith or give the comment to which they responded the most charitable reading.
My apologies for being somewhat knee-jerk about it, but I have a really big problem with bigotry (I am absolutely not claiming that you or the poster to whom GP replied are bigoted) and believe that decent people should call attention to bigotry, especially when it's embedded in society as the tipping culture is in the US.
Bigotry is ethically wrong and harms the societies which it infests. As I mentioned, I feel strongly about that.
If I was less than charitable with your response to calling out bigotry (GP's attempt to do so was rather ham-handed), my apologies.
> Waiters also explicitly aren't allowed to be paid less. They must make at LEAST minimum wage. If they don't make minimum after tips, their hourly rate is raised each paycheck to equal minimum wage.
That means they are allowed to be paid less than minimum wage. Wage is paid by the employer, not the employer's customer. If the employer can deduct the tips from the minimum wage, that explicitly means that they are allowed to pay tipped workers less and that tipping does not provide any additional income but instead only shifts the responsibility of paying people for their work to the customer. Tips are are nothing but gifts to the employer.
> and it's an easy way to show appreciation.
If something is socially expected simply as part of protocol and people only do it out of the social pressure not to deviate from the norm and be seen as assholes, then that is not appreciation.
As someone very engaged in reading HackerNews comments I observed that your comment and the comment you are replying to have that exact same format of three short paragraphs.
The people behind these bots most certainly found that many engaging, authentic comments follow this clever pattern. It is also worth noting that such comments are remarkably digestible – due to their brevity and decomposition into even smaller logical and lexical parts – and swiftly read, requiring only a very short attention span and little intellectual investment from the reader.
This makes me very curious about the statistics on how HackerNews comments are structured and how well different formats of comments perform in the community. I would be thrilled to dive into the data and might write a neat program to analyze this sharing the results with the community.
The data you'd need for that is all available through both the HN Firebase API (which is a bit antiquated) and Algolia's HN Search API. If you find anything interesting, definitely let us know!
Incidentally, both comments were edited after the fact. Neither my nor Dang's comment were originally of this length but we both made edits that ended up there. I did notice the irony :)
You could tell them that you are very happy to pay them the price they printed on the menu and that they can present you with a payment terminal charging exactly that price, but that you will not do that job for them. Basically make the waiter select the 0% option.
But in the end you'll only annoy the waiter and not the owner of the restaurant who is actually running the tipping scam.
Unless you are running a more complex setup SPF, DKIM and DMARC really aren't that complicated. They are annoying and additional checkboxes you have to go trough that are hard to fully automate because they require access to DNS, but they are more busywork than difficult.
Domain and IP reputation and all the other quirks of deliverability are much more of a headache. DMARC is setup, test and done. But deliverability in praxis is something you cannot just test and can break at any time. The second worst are email providers that do whitelisting for email and require you to go through their process to even be allowed to send emails to their customers. The worst are providers that randomly decide to drop your emails without informing you or giving you a proper way to appeal as a small sender. If you're not a large email provider they have no problem just dropping you and the fault is on you because your service is the only one that is not working.
And then there are so many more intricacies of the ancient email protocol. Compatibility with horrendously outdated and misconfigured mail infrastructure is particular frustrating to me. I'm running a modern, properly configured, state of the art email server, but get ghosted by large email providers, yet have to deal with the broken mess, much bigger providers than myself are, which of course have no trouble delivering their broken spoofable email just because they are large enough.
Maybe nothing in Bitcoin does, but among many other things the heat death of the universe does. The probability of finding a key of a secure cryptography scheme by brute force is purely of mathematical nature. It is low enough that we can for all practical intends just state as a fact that it will never happen. Not just to me, but to absolutely no one on the planet. All security works like this in the end. There is no 100% guaranteed security in the sense of guaranteeing that an adverse event will not happen. Most concepts in security have much lower guarantees than cryptography.
LLMs are not cryptography and unlike with many other concepts where we have found ways to make strong enough security guarantees for exposing them to adversarial inputs we absolutely have not achieved that with LLMs. Prompt injection is an unsolved problem. Not just in the theoretical sense, but in every practical sense.
reply