Michael Gronager [ARCHIVE] on Nostr: š Original date posted:2013-03-13 š Original message:Please note that it was ...
š
Original date posted:2013-03-13
š Original message:Please note that it was not 0.8 that had issues, but 0.7(and downwards).
I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for a similar situations in the future.
Instead I would like to propose a setup for "considerate mining":
* Run pools either on newest or second newest version (up to you depending on which features you like as a pool admin) - say e.g. 0.8
* Connect to the rest of the bitcoin network _only_ through a node of the other version - say e.g. 0.7
This guarantees that no blocks will get into the network that will not be accepted by both 0.8 and 0.7. Those two versions together should add up to say >90%.
Once everyone else (90%) have upgraded to the newest, (0.8), drop the 0.7 and start to introduce 0.9 instead.
/M
š Original message:Please note that it was not 0.8 that had issues, but 0.7(and downwards).
I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for a similar situations in the future.
Instead I would like to propose a setup for "considerate mining":
* Run pools either on newest or second newest version (up to you depending on which features you like as a pool admin) - say e.g. 0.8
* Connect to the rest of the bitcoin network _only_ through a node of the other version - say e.g. 0.7
This guarantees that no blocks will get into the network that will not be accepted by both 0.8 and 0.7. Those two versions together should add up to say >90%.
Once everyone else (90%) have upgraded to the newest, (0.8), drop the 0.7 and start to introduce 0.9 instead.
/M