3 ms·
I said "intentional hard-fork" for a reason. For everybody's reference, the bdb to leveldb hard-fork happened in early 2013. Everybody acted swiftly to correct
by wraithm112 11y ago
I said "intentional hard-fork" for a reason. For everybody's reference, the bdb to leveldb hard-fork happened in early 2013. Everybody acted swiftly to correct the issue by downgrading to 0.7 if I recall correctly.
An accidental hard-fork is a completely different animal from an intentional contentious hard-fork where half of the network goes one way and the other half the other way for the foreseeable future.
- mike_hearn 11y agoSo did I. Please re-read my post. The same change that triggered the accidental fork was done smoothly later on, but the change was the same - it was a deliberate hard fork. You probably didn't notice because there was plenty of lead time and I don't think any miners got split off the chain, even though they could have.
- deleted 11y ago[deleted]
- jcansdale 11y agoWould it be fair to say it was a deliberate hard rule change that because it was rolled out in a controlled manner didn't manifest itself as a hard-fork? IMHO there are ways to mitigate the dangers of an hard rule change so that a hard-fork never actually happens. For example, a notification period followed by a version based soft-fork should be able to get an overwhelming majority of miners on board. If blocks on the minority chain are taking over a day to generate and there is a massive transaction backlog, the minority chain is unlikely to make it to 6 blocks. Does that make sense? A hard rule change without a hard-fork?