[Bitcoin-ml] Block size credit and supporting "burst" block sizes

Jeff Garzik jeff at bloq.com
Sun Nov 19 13:51:55 UTC 2017


This "burst" behavior aligns with the original idea behind the block size
limit:

On ordinary days, the block size limit would not be apparent; it becomes
apparent only in high traffic scenario when traffic bursts high, preventing
a [then inexpensive] DoS.

The long run behavior would, by implication, have a dynamic adjustment
which allows for growth, but at the same time prevents "uncharacteristic"
block sizes.  This can be molded into a block size credit system like you
describe.  Other suggestions from the distant past include exponentially
higher fees for upper bands of block size - "buying up"



On Sun, Nov 19, 2017 at 9:46 PM, Tier Nolan via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> wrote:

> Sometimes the demand for block size temporarily increases.  For example,
> during Christmas shopping, the demand for transactions could increase.  It
> can also spike for other reasons.
>
> In the long run, the block size limit should be set to the size required
> so that fees stay stable (and low).  This means that the block size limit
> is increased at the same rate as transaction demand increases, but is is a
> coarse adjustment.
>
> Each chain has to decide what that balance is.  Maybe $20 fees are ok for
> a settlement chain.  Even Bitcoin Cash is probably not aiming to be a
> "micro-payment" chain.  It has fees of a few cents.
>
> It looks like Bitcoin Cash fees are around 5 cents and the blocks aren't
> actually hitting the size limit anyway.  Is there a fee target for Bitcoin
> Cash?
>
> The easiest solution is to just set the block limit above the peak rate,
> but that leads to low fees during normal demand.  This gives a larger block
> chain than is necessary.
>
> The best outcome is that the fees are stable all the time.  When demand is
> low, the block size is smaller and it can increase during peak load to keep
> supply and demand in balance.  This gives most bang for blocksize buck (no
> matter what size you think the blockchain should be).
>
> A feature that would help is to give miners a way to gain block size
> credit.  If a miner produces a block that is below the blocksize limit,
> they get credit for the portion of the block that they didn't use.
>
> During peak demand periods, they could use that credit to make blocks that
> would otherwise be above the block size limit.
>
> The limit might be 8MB (standard) and 32MB (absolute).  A miner who
> produces a 6MB block gets 2MB credit.  A miner could produce a 16MB block
> but would have to spend 8MB of size credit.  No matter what the 32MB
> absolute would apply.
>
> The standard size target could be tweaked every few months to keep fees in
> the target range.
>
> This would be an additional block reward.  They would get minting fees and
> also block size credit.  The block size credits would never run out too, so
> that helps as minting fees fall to zero.
>
> If users can own block credit too, then this helps with Lightning.  They
> require a low fee main chain and it would allow them to pre-pay for their
> channel close transactions.  If the Lightning network was attacked, it
> could cause a massive demand for channel clock transactions as a burst.
> This would cause a series of 32MB blocks with everyone spending their block
> credit to cause the limit to be hit.
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>


-- 
Jeff Garzik
CEO and Co Founder
Bloq, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171119/afc6b469/attachment.html>


More information about the bitcoin-ml mailing list