You are viewing a single comment's thread from:

RE: Witness Update: 15 Hours In Front of a Computer in Puerto Rico

Yeah the almost five hour replays were extra difficult as well. It seems some had to replay and others didn’t. That added a lot of drama. I was ready to go with my v19 node but vanderberg asked me to hold off since he didn’t want to risk anymore replays and we wanted to keep v19 nodes ready to restart with enable stale production if needed. Eventually we mostly had to replay anyway. By the time I tried, my v20 node already downloaded, decompressed, and replayed as well.

Sort:  

Yes, by the time you realized your replay, when synced was no good, you had to replay again. Tough times this replay stuff.

Replaying should never be necessary "EVER"... because replaying from genesis is a terrible idea. Archiving the first 2 years of steem... and keeping it in a separate archive database should be sufficient.

If the code changes, and can't read the archived format anymore.. there should be a separate utility tool created to port the old archive database to the new format, that runs independently of steemd.

Going forward, as the blockchain gets huge... these designs need to happen sooner than later.

The challenge with that idea is that it would no longer be a blockchain. If the data isn’t immutably stored in a way that any node could sync with, things might get weird.

Loading...

It's important that one is able to replay and verify the full blockchain, and it's also important that people actually do this exercise every now and then (and particularly after the network has been bootstrapped like this), but in situations like this one really want to be able to bootstrap things without having to do a full replay from the genesis block - at least, one should be able to bootstrap things only from a known recent checkpoint.

It's rare to see a social media platform have outages lasting for hours, it's rare to see banking solutions having outages lasting for many hours, and it's even rarer to see major blockchain solutions having long-lasting outages.

Bitcoin had a similar chain fork in March 2013, it took six hours to resolve the situation. Lots of trust were lost as double-spends were possible during those six hours - Steem has obviously learned from this, as the network was shut down to avoid such problems. Anyway, given that the chain actually forked, and invalid blocks got produced by the 0.20-nodes, did any transactions get rolled back?

No, a checksum value was implemented, so we were all on the same fork.

Since witness nodes were not producing properly, there was no conensus for any of the chain forks.

Any transactions that were attempted to be sent, weren't written into any particular chain.

So exchanges and the like, wouldn't have had transfers completed while it was in that state.

So that is the long way of answering "did any transactions get rolled back" (I assume you mean, did double spends occur?) --- no.

So that is the long way of answering "did any transactions get rolled back" (I assume you mean, did double spends occur?) --- no.

"Double spend" is one thing, posting something to the blockchain, seeing that it got posted, and then having it deleted the next day is another. I guess there is no such concept as "unconfirmed transaction" in Steem, a transaction that isn't written to the blockchain in due time is probably lost?

I noticed one of the emergency patches was like "ignore all blocks produced while the blockchain was down", that's part of why I'm asking.

Coin Marketplace

STEEM 0.26
TRX 0.11
JST 0.033
BTC 63851.10
ETH 3059.36
USDT 1.00
SBD 3.85