On 14 August 2015 at 16:48, Jakob Rönnbäck < bitcoin-dev@lists.linuxfoundation.org> wrote:
> 14 aug 2015 kl. 16:20 skrev Anthony Towns <a...@erisian.com.au>: > > On 14 August 2015 at 11:59, Jakob Rönnbäck < > bitcoin-dev@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're waiting for one confirmation, something like that works -- you might from 95% chance of 10 minutes 5% chance of 20 minutes to 100% chance of 10m30s. But if you want 144 confirmations (eg) you go from 95% chance of 1 day, 5% chance of 1 day 10 minutes; to 100% chance of 1 day 72 minutes. > 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… > Once blocksizes had normalised as much larger than 1MB with a corresponding higher average hashrate, a bad actor could easily mine a raft of valid empty/small blocks at the minimum hash rate and force a reorg (and do doublespends, etc). Cheers, aj -- Anthony Towns <a...@erisian.com.au>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
