You are viewing a single comment's thread from:

RE: Steem recovered from the hf20 fork thanks to abit and its emergency patches

in #witness7 years ago (edited)

It was fixed without the help of steemit inc, so it's kind of decentralised.

The main problem is price manipulation, because of this, it is not a bad idea to hide this chat.

Checkout 0.19.12 and apply the patches from abit, then replay. I pasted my changes to the config.ini.

Sort:  

replay will take me 36 hours or so. after that if it doesn't work, maybe there is a better routine already in place...
a real hotfix, maybe even a patch

There is a branch, which apply the 2048 fix: https://github.com/steemit/steem/commits/20180917-increase-fork-buffer

but no official release yet.

Replaying 3 nodes took me 3-4 hours each.

What is your
cat /proc/cpuinfo
?
I would guess you have an i7 processor?
Those seem to run the replay way faster.

model : 79 model name : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz stepping : 1 microcode : 0x1 cpu MHz : 2199.998 cache size : 16384 KB

so it's kind of decentralised

There is no decentralisation if Steem is completely down because of few witnesses wanted to run new software.

The witness are elected by the steem user and have the power to vote for a new hardfork. So when HF20 was announced, every witness has to decide to install it or not. When a defined percentage of witnesses did go to HF 20, it was activated. Normally, this should not be a problem and the new features are then activated on the scheduled date.

This time, there were two undiscovered bugs, one in HF 19 and one in HF 20.

After the crash, the elected witnesses have the duty and the power to recover and to start the steem chain again.

I do not see, why this is not decentralized?

why this is not decentralized

Because whole community have to decide who are those 20 centered witnesses. Those twenty are centralised power and decide what to run for whole network.
We should rearrange votes on them if they fail like yesterday.
Vote for @abit!

That's b.s. Steem was frozen since it's how the blockchain works if there is a critical error.

Freezing the block production is the safest thing to do when nodes disagree on block validity, but it should be possible to freeze the block production without halting all the nodes and hence stopping all the user interfaces from working. Ideally it should still be possible to read old posts even if the blockchain is frozen.

It's also a setback that it took so long time to resolve the issue.