← Back to team overview

mimblewimble team mailing list archive

Re: Elapsed-Time-Scaled Block Size

 

I wouldn't put so much trust in miners timestamps. I'm much more of a fan
of building systems where we don't have to trust them.

On Tue, Nov 21, 2017 at 12:53 AM Tomas Juočepis <tomasjuocepis@xxxxxxxxx>
wrote:

> Hello, grinners,
>
> what if block size limit of each newly found block would be linearly
> proportional to time elapsed since last block? Stated another way, nodes
> would consider a new block valid only if timestamp delta (new block
> timestamp - last block timestamp) multiplied by some parameter of size/time
> ratio is greater than the size of the new block. It seems that something
> like this could produce a more constant transaction throughput in cases of
> quickly varying applied pow rate ("hash rate") without affecting difficulty
> adjustment.
>
> For example, consider the following block timestamp deltas (in minutes):
> 10, 20, 30, 3, 5, 7, 5, 5, 5, 10 (total 100, average 10 (nominal))
> With block sizes being constant, we get 10 blocks worth of size.
> With block sizes linearly proportional to time delta, with slope
> coefficient set so that nominal (target) time produces nominal block size,
> we'd get same cumulative size (and therefore same cumulative consumed
> network bandwidth), but transaction rate would be more even/consistent.
>
> Let's say we can fit 1000 txs in a block designed to be mined every 10
> minutes. With the previous example, with constant size we'd have the
> following:
> t=10, 1000 txs confirmed
> t=30, 2000 txs confirmed
> t=60, 3000 txs confirmed
> t=63, 4000
> t=68, 5000
> t=75, 6000
> t=80, 7000
> t=85, 8000
> t=90, 9000
> t=100, 10000
> With time-delta-scaled size, we'd have:
> t=10, 1000 txs
> t=30, 3000 txs
> t=60, 6000 txs
> t=63, 6300 txs
> t=68, 6800 txs
> t=75, 7500 txs
> t=80, 8000 txs
> t=90, 9000 txs
> t=100, 10000 txs
>
> Any thoughts? The main issue I see is gaming timestamps, but can't that be
> solved by nodes not propagating blocks until timestamps are no longer dated
> in the future? Miners could still risk and add a timestamp few minutes into
> the future, but they would risk their block being orphaned if another miner
> finds another block with a valid timestamp, thus propagating through the
> network (before the future dated block can propagate).
> --
> Mailing list: https://launchpad.net/~mimblewimble
> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References