1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1XjzEd-0004P6-Pe
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Oct 2014 23:34:31 +0000
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;
Received: from mail-ig0-f172.google.com ([209.85.213.172])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XjzEc-0003SC-PN
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Oct 2014 23:34:31 +0000
Received: by mail-ig0-f172.google.com with SMTP id a13so4326845igq.11
for <bitcoin-development@lists.sourceforge.net>;
Thu, 30 Oct 2014 16:34:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.31.201 with SMTP id f192mr24260428iof.41.1414712065352;
Thu, 30 Oct 2014 16:34:25 -0700 (PDT)
Received: by 10.107.159.3 with HTTP; Thu, 30 Oct 2014 16:34:25 -0700 (PDT)
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
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XjzEc-0003SC-PN
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing regularity of block times?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 30 Oct 2014 23:34:31 -0000
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.
|
