Re: SegWit + Variable and Adaptive (but highly conservative) Blocksize Proposal
@DooMAD: I have, however, a slight update proposal:
Change
to
with X = 4 or more, I would propose X = 8.
The reason is that totaltxfee can have fluctuations. So a malicious person/group that wanted to increase the block size could produce a "full block spam attack" in a difficulty period just after a period with relatively low TotalTxFee.
Change
Code:
(TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty)
to
Code:
(TotalTxFeeInLastDifficulty > average(TotalTxFee in last X difficulty periods))
with X = 4 or more, I would propose X = 8.
The reason is that totaltxfee can have fluctuations. So a malicious person/group that wanted to increase the block size could produce a "full block spam attack" in a difficulty period just after a period with relatively low TotalTxFee.
Exceptional reasoning, I'm totally on board with that. I was hoping we could find improvements that help raise disincentives to spam and this absolutely qualifies. OP updated. Thanks.
It's not about precedents. Or about how many people say it (seriously?)
It's about design. It's about logic. Don't talk to us about what everyone already thinks or has said, talk about what makes sense. Satoshi wouldn't have made Bitcoin if he'd listened to all the preceding people who said that decentralised cryptocurrency was an unsolvable problem, you don't solve design problems by pretending the problem doesn't exist.
It's about design. It's about logic. Don't talk to us about what everyone already thinks or has said, talk about what makes sense. Satoshi wouldn't have made Bitcoin if he'd listened to all the preceding people who said that decentralised cryptocurrency was an unsolvable problem, you don't solve design problems by pretending the problem doesn't exist.
Maybe it's just me, but I honestly don't see what's logical about taking a stab in the dark now with no way to accurately forecast future requirements. Particularly if that stab in the dark could easily result in another contentious debate later. If someone can convince me why a potential hard fork later is somehow better than an equally potential soft fork later, I'll reconsider my stance.
also
this would cause orphan risks of when nodes rescan the block chain
if 2016 blocks were X then the next time 2016 blocks were y(=x-0.01) with the rules being Y.. all the X blocks would get orphaned because the 2016 blocks that are X are above the current Y rule.
Code:
THEN BaseMaxBlockSize = BaseMaxBlockSize -0.01MB
WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB
WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB
this would cause orphan risks of when nodes rescan the block chain
if 2016 blocks were X then the next time 2016 blocks were y(=x-0.01) with the rules being Y.. all the X blocks would get orphaned because the 2016 blocks that are X are above the current Y rule.
Is there some kind of workaround or fix that would still enable us to reduce dynamically while limiting the potential for orphans? I have doubts a sufficient supermajority could be reached for the proposal if max sizes could only increase. It needs to be possible to reduce if there's a lack of demand.