mimblewimble team mailing list archive

[Tomas Juočepis <tomasjuocepis@xxxxxxxxx>]

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).