Post
Topic
Board Bitcoin Discussion
Merits 2 from 1 user
Re: SegWit + Variable and Adaptive (but highly conservative) Blocksize Proposal
by
d5000
on 11/05/2017, 22:56:42 UTC
⭐ Merited by DooMAD (2)
An attacker like the PBOC itself has trillions of dollars to dump and bloat the network and keep it at the maximum, so even if you set a limit, you would end up with a blocksize that's too big for most people and then the nodes start dropping like soliders in the d-day.

If these "money making machines" want to destroy Bitcoin, they can do so now. An 51% attack costs about 600-700 million dollars at this moment. The PBOC would have no problem with that. So why go the hard way and spam the Bitcoin network during 10 years to achieve ~3,5 MB base size if you can destroy it instantly?

As the blocksize growth - as already said - is linear, I think the importance of this attack vector is negligible.

@DooMAD: I have, however, a slight update proposal:

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.

Regarding an upper blocksize cap (@Carlton Banks): In the previous proposals we discussed it made sense for me because the proposed block size growth was exponential (+5% is the last one I remember) and that could have lead to an uncontrollable situation in the future. I think this proposal is conservative enough that such an upper cap isn't important. I also wouldn't totally oppose it.