BitShares Forum

Main => General Discussion => Topic started by: bytemaster on October 27, 2015, 10:42:31 pm

Title: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: bytemaster on October 27, 2015, 10:42:31 pm
Ben and I have discovered the root cause for the loss of consensus and have a temporary fix that can be used by all witnesses.

The problem was a single field which we failed to serialize when saving chain state to disk.  Any node that didn't replay the chain on startup would have this field reset to 0.

We will be releasing a fix for this along with several other fixes by the end of the week.   In the meantime, all full nodes should always replay the blockchain on startup by using the --replay-chain argument.

Title: Re: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: abit on October 28, 2015, 08:32:00 am
Restarted.
A node with Debug build took 461 seconds to re-index.
Another node running with Release build took 126 seconds to re-index.

Do we still need to restart if it's already started with --replay-blockchain? Do we need to restart with --replay-blockchain every day or somewhat interval?

Here are some new info while restarting.
Code: [Select]
   82.551%   346000 of 419135
1401613ms th_a       db_update.cpp:244             check_for_blackswan  ] Black Swan detected:
   Least collateralized call: 75.71602860647396938  0.01320724314791250
   Settle Price:              0.00025496653564220  3922.08333333333348492
   Max:                       0.00025496653564220   3922.08333333333348492

1401614ms th_a       db_update.cpp:244             check_for_blackswan  ] Black Swan detected:
   Least collateralized call: 759.92759999999998399  0.00131591483188662
   Settle Price:              0.00003505287141438  28528.33333333333212067
   Max:                       0.00003505287141438   28528.33333333333212067
Title: Re: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: xeroc on October 28, 2015, 09:07:00 am
Those are supposedly RUB and SEK .. It may have been caused by a malious price from yahoo but I can't tell for sure ..
Title: Re: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: bytemaster on October 28, 2015, 12:51:15 pm
Those are supposedly RUB and SEK .. It may have been caused by a malious price from yahoo but I can't tell for sure ..

Total amount of value involved in those swans is less than $10.   
Title: Re: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: xeroc on October 28, 2015, 01:28:30 pm
Those are supposedly RUB and SEK .. It may have been caused by a malious price from yahoo but I can't tell for sure ..

Total amount of value involved in those swans is less than $10.   
How can we restart the markets then?
Title: Re: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: maqifrnswa on October 28, 2015, 02:13:46 pm
Are the tags correct?
2.0.151027 is a lower version number than the previous release 2.15.294

that causes problems for people with automated version checking, and is different than the previously announced versioning system
Title: Re: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: abit on October 28, 2015, 02:20:27 pm
Are the tags correct?
2.0.151027 is a lower version number than the previous release 2.15.294

that causes problems for people with automated version checking, and is different than the previously announced versioning system
Apparently 294 which is day-of-year is harder to read. 151027 is a date but easier to read.
I wonder why not use 2.15.1027 for better compatibility.
Title: Re: Fix for Loss of Consensus with Withdraw Vesting Balance
Post by: bytemaster on October 28, 2015, 06:43:57 pm
Are the tags correct?
2.0.151027 is a lower version number than the previous release 2.15.294

that causes problems for people with automated version checking, and is different than the previously announced versioning system
Apparently 294 which is day-of-year is harder to read. 151027 is a date but easier to read.
I wonder why not use 2.15.1027 for better compatibility.

We would like to reserve the 2.X  as the hard fork number.