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
96
97
98
99
100
101
102
103
104
105
106
|
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 <rusty@ozlabs.org>) id 1Xk3DX-0004vl-02
for bitcoin-development@lists.sourceforge.net;
Fri, 31 Oct 2014 03:49:39 +0000
X-ACL-Warn:
Received: from ozlabs.org ([103.22.144.67])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Xk3DV-0002aP-8y
for bitcoin-development@lists.sourceforge.net;
Fri, 31 Oct 2014 03:49:38 +0000
Received: by ozlabs.org (Postfix, from userid 1011)
id 6961514009E; Fri, 31 Oct 2014 14:49:29 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Gregory Maxwell <gmaxwell@gmail.com>
In-Reply-To: <CAAS2fgRLoDLzzD3v9qizzhH_PM9Q_a7Dq6-8mrAYbKc1-P6aTg@mail.gmail.com>
References: <874mul9met.fsf@rustcorp.com.au>
<CAAS2fgRLoDLzzD3v9qizzhH_PM9Q_a7Dq6-8mrAYbKc1-P6aTg@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1
(x86_64-pc-linux-gnu)
Date: Fri, 31 Oct 2014 14:01:12 +1030
Message-ID: <87h9yk9apr.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Xk3DV-0002aP-8y
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: Fri, 31 Oct 2014 03:49:39 -0000
Gregory Maxwell <gmaxwell@gmail.com> writes:
> 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.
Your point is well made.
If everyone published their easy blocks at the 20 minute mark,
divergence would be a problem (though with 6/7 blocks being normal, the
network would probably recover). I was proposing to relay them as
normal, they're just not accepted until 20 minutes.
(Though with the suggested variant of accepting the most-compatible
rather than first-seen block, this isn't so critical).
> It is precisely the variance being some huge multiple of the network
> radius which allows the network to converge at all.
I hadn't thought about it that way, but I assumed GHOST mitigate this
down to some lower limit. Or?
> 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.
Agreed, that would be foolish. Note that in my proposal, block
timestamps wouldn't reflect the delay (removing incentive to push
timestamps forward, but making judging historical blockchain's validity
harder).
> 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.
Nice idea. Publishing WIP blocks like this could provide evidence, but
you'd have to incentivize miners to publish them. Can you think of a
way to do that (which beats simply reducing the block time)?
> I'll dig up some citations for you later. Cheers.
Thanks for your time,
Rusty.
|
