This has happened at least 1573 times.. therefore it is not news. It becomes news if block time were to go to 1 hour average for a few days. However, when this scenario has occurred in the past transactions fees went so high that it made sense for miners to turn their miners back on to harvest the high fees.
If only there were a crypto-literate news outlet capable of putting this sort of thing in context like that. Say, a news-desk specializing in crypto-coin topics. They could call it coin-news, or crypto-desk, or something like that!
If only there was a technical news aggregator full of experts in software hacking, whose users would be able to sort out newsworthy updates from background noise. They could call it software-news or hacker-aggregator or something like that.
If you're at a cash register and there's a slight chance that when you use your credit card that it won't accept a payment for an hour, wouldn't you not want to use that credit card?
You understand that credit card payments don't usually get settled immediately, right?
If you want a comparable experience to regular credit cards, simply accept unsettled bitcoin transactions, and get some insurance for the events where the unsettled transactions got double spent.
You'll get the exact same experience as a bank, with a much faster settlement time, and significantly lower fees.
Bitcoin was never intended for instantaneous transactions. Remember when credit cards were offline and bulk data was processed at the end of the day with one roll-up transaction phoned in? That's basically the solution.
Assuming it's a problem in the first place. The consumer EFT system in my country routinely has a 30 - 60 minute delay before the transaction can be processed, and that doesn't stop everyone from using it routinely to pay their rent. And actual wire transfers still take days. That would seem to be the competition. (Comparing to credit cards is flawed, as the funds don't transfer custody with a credit card for some time, as anyone who has dealt with a chargeback knows.)
It was originally intended for exactly that - instantaneous transactions. It was only a huge rift in the community in ~2014 that saw it turn away from the original mission.
The original paper that defined Bitcoin "supposed" mining would take 10 minutes per block, which is what the implementation has in fact always targeted... how was it ever "originally intended" to run instantaneously?
It also suggested waiting for multiple "confirmations", i.e. further mined blocks on top, to reduce the risk of a blockchain history reorganization. 6 confirmations is generally regarded as full confirmation.
The only time this is interesting is if we get an inversion or whatever they call it where the difficulty goes up just before a bunch of miners stop mining (because the price dropped or whatever) and we get to a point where there's not enough miners to make blocks to get to the next difficulty adjustment.
This gets at one of the things I've never quite understood about Bitcoin. Over time the effort to mine a coin goes up - there's a ultimately a set limit on the number of coins that will be produced. Mining coins is where the effort for all operations comes from.
What if the impetus for mining - an increasing worth for a rarer coin - doesn't scale? Couldn't you have a situation where fewer miners reduces the speed of operations so there's less demand which is a feedback on itself.
Mining is solving some kind of puzzle. If not a lot of blocks get mined, the difficulty the puzzle is reduced. This way the system automatically balances so mining a block costs about as much as you gain when you solve the puzzle first.
I do wish people would not use the term "puzzle" when talking about bitcoin and proof-of-work. The word "puzzle" conveys some sort of strategy and approach beyond trial-and-error. Instead of a puzzle, it is a brute-force search.
Would you say that other proof of work puzzles such as Cuckoo Cycle [1], which asks for a fixed length cycle in a large random bipartite graph, is a brute force search as well? Because that one is certainly not solved by trying all possible cycles.
I think of it more like a raffle. But yeah, I share your frustration. Writers fixate on finding the right analogy instead of focusing on the actual problem being solved: randomly choosing a block decider out of an open set of candidates, with no central selection infrastructure.
Internal state of sha256 is 512 bits, though the inputs the user can control are limited to about 300 bits. In any case, it's larger than the believed number of atoms in the observable universe.
The important point is that there is no progress, each attempt has an independent probability of success. Imagining it as an infinite haystack with a difficulty controlled density of needles still yields the right understanding.
Other sources report the only 'days' delay was between block 0 and block 1 – and thus likely an idiosyncratic effect of the launch. Apparently, also, there were a few more >20hr blocks in the 1st half of 2009, when interest was very, very low.
So while technically true, without further details, your comment implies something that's not really reflective of the system today.
Of course, as a stochastic process, it's possible that the delay reaches any length whatsover. But it becomes vanishingly unlikely, under the rough assumption that hash power stays at the level observed at the last difficulty-adjustment.
Anyone arguing a delay between block 0 and block 1 is not arguing from a rational standpoint. It is akin to arguing that an airline had days of no flights where they didn't fly any routes at all, because the company was obviously founded and incorporated at least a few weeks before their first commercial service was introduced.
How can negative times happen? Each block contains a hash of the previous block so in order to mine the next block you would need to know the hash of the previous block which more or less means that you need to know the previous block which means it existed first.
Is this some play going on with embedded timestamps or something that are not necessarily monotonic?
The internal timestamps are not necessarily monotone because if they were forced to be then if the single clown in front of you set the timestamp incorrectly into the future you'd be forced to do so too.
If you want monotone stamps from the block header timestamps you can post process them to make them monotone. ... if that kind of error would be superior for your purposes. For this discussion probably the best thing to do is ignore any non-monotone timestamps (and maybe the block before them too).
Because the protocol rules don't have any strong incentives for setting the timestamps precisely they're best taken as approximate.
timestamps are submitted by the miner solving the block, so a misconfigured clock could be the culprit, but most often these are attacks against a difficulty adjustment algorithm or re-org scheme where a lot of hashrate is used to overwhelm consensus and assert that their tampered chain is the correct chain.
This is typically used for forcing a block history in smaller networks where it is easier to dominate the hashrate. Zawy12 is a researcher who has put a considerable amount of work into different rolling window hashrate adjustment algorithms to combat this, like LWMA etc.
It's a fun fact that not a lot of people know: These same algorithms are used in heating elements and thermocouples so that the heat level does not 'overshoot' the objective and is able to maintain heat in windy environments or variable temp environments while staying in a certain window.
If you've ever used an e-nail or soldering iron, chances are you've used something that employs this same tech.
Less than 20 irreversible transactions per second. Regular financial infrastructure requires maybe a few weeks or months or years for a reasonably irreversible transaction.
Layer 2/Lightning can process far greater number of transactions for a far lower fee with a cryptographic guarantee of submission to the underlying blockchain. There are some kinks of course, as there always are.
> today you learn that wire transfers are not irreversible
Nope. Reversing wires on bank error requires both sides’ consent. (Some wire agreements have you authorise the bank to do this on your behalf.) Less a reversal than sending a counterbalancing wire. Even this is only possible for minutes to a day.
Beyond that, e.g. in cases of fraud, law enforcement must freeze and seize.
