[Bitcoin-ml] Block size credit and supporting "burst" block sizes
tier.nolan at gmail.com
Tue Nov 21 13:00:56 UTC 2017
On Tue, Nov 21, 2017 at 12:34 AM, Steve via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> wrote:
> But if miners are setting the block size they would be doing do by soft
> limits. Nothing stops another miner mining larger blocks except possibly
> the fear of all other miners rejecting their block. I don't think we have
> any historical information to help guess how this would play out.
The miners could easily implement a formal soft fork to give them direct
control of the block size. A simple rule would be that they assign a
version bit to vote for an increase or decrease in the size. Every so
often, the votes are counted and if more than 2/3 agree to a rise/fall,
then the limit is increased/decreased by 10%.
If the soft fork was accepted, then miners would have an incentive to
update their software to reject oversized blocks in that case. If most
miners update, then all miners have to update.
Limiting the block size is a soft fork. There is even a risk that the
miners could reduce the hard cap via a soft fork.
If you want to go down the road of artificial limits I'm not sure what we
> gain by creating this secondary market in block space credits. Why does
> the unused space credit need to be tied to a miner?
It doesn't have to be miners who own the extra block space.
It could be linked to individual UTXO outputs. Someone could create a 250
byte transaction and then assign an additional 500 bytes to a particular
output (maybe similar to how the sequence field was updated). That
transaction would count as 750 bytes of (soft) block size when included in
a block. The block including the transaction that spends the output would
get the extra 500 bytes. In theory, some transactions could have a
Why not a simple global pool that any miner can use?
That would work too. The disadvantage is that it creates an incentive for
it not to be conserved. During non-peak time, miners would still get extra
fees by consuming the extra space.
> These facts are symptomatic of that fact that miners have not yet
explored the levels of sophistication available to them. Nothing other
than technical barriers to entry currently stops a miner from modifying
node code themselves and setting their own limits or policies.
I agree. I think it is likely that miner initiated soft-forks will occur
in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-ml