Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.172 as permitted sender)
	client-ip=209.85.213.172; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f172.google.com; 
MIME-Version: 1.0
In-Reply-To: <874mul9met.fsf@rustcorp.com.au>
References: <874mul9met.fsf@rustcorp.com.au>
Date: Thu, 30 Oct 2014 23:34:25 +0000
Message-ID: <CAAS2fgRLoDLzzD3v9qizzhH_PM9Q_a7Dq6-8mrAYbKc1-P6aTg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing regularity of block times?
Precedence: list

On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> Hi all,
>
>         I've been toying with an algorithm to place a ceiling on
> confirmation latency by allowing weaker blocks after a certain time.
> Hope this isn't noise, but thought someone must have considered this
> before, or know of flaws in the scheme?
>
> Gory details:
> http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html

Irregularity is a required property for convergence. Imagine what
would happen in a network where a blocks were produced at an exact
interval: Almost everyone would produce one the exact same time, and
the network would fragment and because the process would continue it
would not converge. It is precisely the variance  being some huge
multiple of the network radius which allows the network to converge at
all.

When lower variance is tolerable for convergence it can be achieved by
reducing the expectation. Maybe some other distribution can be proven
to be convergent to, it's difficult to reason about.

Bitcoin testnet implements a rule that allows lower difficulty blocks
after a delay (20 minutes, in fact), but it's a testing-toy... not
secure or intended to be so. At least one altcoin has copied that
behavior and been exploited on account of it.

If you're simply looking for faster evidence that the network is
working on a particular transaction set, at some lower timescale:,
then thats already possible.  e.g. look into how the p2pool sharechain
builds a consensus around mining work used for pooling. The same
mechanism can be used to give faster transaction selection evidence.

I'll dig up some citations for you later. Cheers.