[bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

Natanael natanael.l at gmail.com
Thu Mar 30 10:19:33 UTC 2017


Den 30 mars 2017 12:04 skrev "Luke Dashjr" <luke at dashjr.org>:


I don't see a purpose to this proposal. Miners always mine as if it's their
*only* chance to get the fee, because if they don't, another miner will. Ie,
after 1 block, the fee effectively drops to 0 already.


I believe that with correctly configured incentives, you can make it more
profitable to delay some transactions with lower fees but still include
them in the next block then to include them all at once. This would smooth
out the inclusion of transactions.

This may require changing the difficulty scaling from using a simple
logarithm to a function that first behaves like a logarithm up to some
multiple of the standard block size, after which difficulty starts
increasing faster and reaches a greater-than-linear ratio in expected
required hash per mined bit. Perhaps tipping over at around a blocksize 3x
the standard blocksize. Since the standard blocksize increases with
continous load after retargeting, the blocksize at which this happens also
increases.

Also, together with the above the fee pool does slightly counteract what
you say, as they'll get a share via the pool when there's less transactions
available the next time they create a block (like insurance).

For a user, what's the incentive to pay an individual miner the fee
directly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/ccbd4893/attachment.html>


More information about the bitcoin-dev mailing list