[bitcoin-dev] Adjusted difficulty depending on relative blocksize

Jakob Rönnbäck jakob.ronnback at me.com
Fri Aug 14 14:48:48 UTC 2015


> 14 aug 2015 kl. 16:20 skrev Anthony Towns <aj at erisian.com.au <mailto:aj at erisian.com.au>>:
> 
> On 14 August 2015 at 11:59, Jakob Rönnbäck <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> What if one were to adjust the difficulty (for individual blocks) depending on the relative size to the average block size of the previous difficulty period? (I apologize if i’m not using the correct terms, I’m not a real programmer, and I’ve only recently started to subscribe to the mailing list)
> 
> ​That would mean that as usage grew, blocksize could increase, but confirmation times would also increase (though presumably less than linearly). That seems like a loss?
> 

Would that really be the case though? If it takes 5% to find a block, but it contains 5% more transactions would that not mean it’s the same? That would argue against the change if not for the fact that the blocks will be bigger for the next difficulty period.

> If you also let the increase in confirmation time (due to miners finding harder blocks rather than a reduction in hashpower) then get reflected back as decreased difficulty, it'd probably be simpler to just dynamically adjust the max blocksize wouldn't it?
> 

I guess that could make the difficulty fluctuate a bit depending on the amount of transactions and the fees being paid. Would it really matter in the long run though? Since it’s the same amount of miners, doesn’t that just mean it’s just the number that is lower, not the actual investment needed to mine the blocks? Not sure if this would open up some forms of attacks on the system for someone willing to lose money though…


Very good feedback though, thanks a lot :)

/jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/855d7a2f/attachment.html>


More information about the bitcoin-dev mailing list