This has also been posted at steem, r/btc and r/bitcoin_unlimited. While I haven't received much feedback at all, at least I haven't received any negative feedback - except from people arguing that the chain split risk is insignificant.
----
The more I consider it, the more I agree that the accidental chain split risk is indeed a weakness with BU as it is today. It's not even needed with malice - the Bitcoin.com mining pool accidentally mined a block being some few bytes too big the other day, and it seems entirely reasonable to assume other nodes mining with the BU software and being configured to already accept big blocks would be wasting CPU-power mining at top of that doomed block. It's also quite clear from the ViaBTC block size increase roadmap that increasing the de-facto blocksize with BU is a non-trivial operation that requires coordination efforts and manual tuning of the EB configuration parameter.
The intended usage of the EB-parameter (Excessive Blocksize) is most of all to publicly flag what kind of max block size limit one deem appropriate. Miners are generally incentivized to keep their block sizes so low a minimum number of nodes and miners would eventually deem the blocks excessively big. In a perfect world this probably would work out pretty well - however, if miners have different settings in their EB, the chain risk split will always be there, either due to incompetence, bugs or malicious miners (and I would expect some grumphy small-blockers to do what they can to sabotage the network after a BU "takeover").
My proposal is to modify the BU software so that one can lie a bit about the effective EB setting. (This should be configurable, nodes and miners should still be free to force their configured EB-setting to be efficient).
So the EB-settings over the last 1000 mined blocks should be monitored, and the median EB is found (actually, something like 45-percentile would probably be more correct, due to the asymmetric situation; the bigblock-chain would be immediately orphaned by all miners if the smallblock-chain grows longer, but the reverse isn't true). Two special cases are monitored for:
In those two special cases one may end up being at the "wrong" side of a harmful chain split.
In any of those two cases, the local efficient EB setting should be temporary set to the median EB value. The new efficient EB-limit should be valid for AD number of blocks (AD is by default configured to 4) - after that it may drop back to the configured setting (if one has set EB too small, and all blocks are bigger than the local EB, then the median EB will be permanently followed). The new EB-limit should also be flagged - it would be pretty bad to mine a block directly at the top of a 3MB-block and still claim EB2/AD4 in the block header.
This is an "internal" implementation change, it does not really change the consensus rules or the flagging protocol - thought it does change the meaning of EB a bit, one can no longer trust nodes and miners to stubbornly stick to the EB-settings they are flagging.
----
The more I consider it, the more I agree that the accidental chain split risk is indeed a weakness with BU as it is today. It's not even needed with malice - the Bitcoin.com mining pool accidentally mined a block being some few bytes too big the other day, and it seems entirely reasonable to assume other nodes mining with the BU software and being configured to already accept big blocks would be wasting CPU-power mining at top of that doomed block. It's also quite clear from the ViaBTC block size increase roadmap that increasing the de-facto blocksize with BU is a non-trivial operation that requires coordination efforts and manual tuning of the EB configuration parameter.
The intended usage of the EB-parameter (Excessive Blocksize) is most of all to publicly flag what kind of max block size limit one deem appropriate. Miners are generally incentivized to keep their block sizes so low a minimum number of nodes and miners would eventually deem the blocks excessively big. In a perfect world this probably would work out pretty well - however, if miners have different settings in their EB, the chain risk split will always be there, either due to incompetence, bugs or malicious miners (and I would expect some grumphy small-blockers to do what they can to sabotage the network after a BU "takeover").
My proposal is to modify the BU software so that one can lie a bit about the effective EB setting. (This should be configurable, nodes and miners should still be free to force their configured EB-setting to be efficient).
So the EB-settings over the last 1000 mined blocks should be monitored, and the median EB is found (actually, something like 45-percentile would probably be more correct, due to the asymmetric situation; the bigblock-chain would be immediately orphaned by all miners if the smallblock-chain grows longer, but the reverse isn't true). Two special cases are monitored for:
- A block is observed that is larger than our EB, but smaller or equal the median EB
- A block is observed that exceeds the median EB, but is lower than our EB
In those two special cases one may end up being at the "wrong" side of a harmful chain split.
In any of those two cases, the local efficient EB setting should be temporary set to the median EB value. The new efficient EB-limit should be valid for AD number of blocks (AD is by default configured to 4) - after that it may drop back to the configured setting (if one has set EB too small, and all blocks are bigger than the local EB, then the median EB will be permanently followed). The new EB-limit should also be flagged - it would be pretty bad to mine a block directly at the top of a 3MB-block and still claim EB2/AD4 in the block header.
This is an "internal" implementation change, it does not really change the consensus rules or the flagging protocol - thought it does change the meaning of EB a bit, one can no longer trust nodes and miners to stubbornly stick to the EB-settings they are flagging.
