From: Gregory Maxwell <gmaxwell@gmail•com>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing regularity of block times?
Date: Thu, 30 Oct 2014 23:34:25 +0000 [thread overview]
Message-ID: <CAAS2fgRLoDLzzD3v9qizzhH_PM9Q_a7Dq6-8mrAYbKc1-P6aTg@mail.gmail.com> (raw)
In-Reply-To: <874mul9met.fsf@rustcorp.com.au>
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.
next prev parent reply other threads:[~2014-10-30 23:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 23:18 Rusty Russell
2014-10-30 23:34 ` Jeff Garzik
2014-10-30 23:34 ` Gregory Maxwell [this message]
2014-10-31 3:31 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgRLoDLzzD3v9qizzhH_PM9Q_a7Dq6-8mrAYbKc1-P6aTg@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=rusty@rustcorp$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox