mimblewimble team mailing list archive
Mailing list archive
Re: Elapsed-Time-Scaled Block Size
I was directed to this thread by Jeremy Wohl
<https://twitter.com/jeremiahcode> after posting a related thought
<https://twitter.com/JaEsf/status/933718447414038530> on Twitter.
Interesting topic! My thoughts:
1. There are several parameters that one could consider making
proportional to block time: max block size is one (this thread), but others
include block reward (my suggestion), or 1/difficulty, so that finding a
block gets easier as time passes. All of these (esp difficulty) would
require some plumbing, but seem doable.
2. All of these offer benefits related to stability/predictability:
- less volatile block times (meaning spends require fewer confirms - so,
good for security)
- more stable behavior under hashrate fluctuations, including sudden
drops after a chain split
- predictable coin issuance rate
- predictable block height-to-time mapping
- predictable blockchain size growth over time
3. The recurring concern is that verifying block times is hard and
therefore they could be gamed. Obviously no one wants to just "trust
miners". But Bitcoin already requires (very slow) consensus on block times
for, eg, the biweekly difficulty adjustment, so arguably the question is
just how much more quickly and accurately consensus on block times/network
time (range) could be achieved. I'm not as pessimistic about this as some
of you - I'm sure it's been discussed before...
4. There are probably folks on bitcoin-dev interested in this thread,
and guaranteed to be people there who've already thought about some of
this, so maybe worth posting a recap there once this thread settles down?
On Thu, Nov 23, 2017 at 11:52 AM, Tomas Juočepis <tomasjuocepis@xxxxxxxxx>
> Given that nodes would not propagate future-dated blocks, what's a scenario
> where gaming timestamps would be plausible?
> On Nov 23, 2017 7:05 AM, "John Tromp" <john.tromp@xxxxxxxxx> wrote:
> > Wouldn't this create an incentive for a miner to include all transactions
> > with fees attached from the mempool and publish the block with a time
> > enough in the future to allow that size of block?
> Yes, it clearly provides incentives to lie about timestamps,
> which I think is enough to make it a bad idea.