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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1UFt1J-0001vt-T8
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 21:15:33 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.51 as permitted sender)
client-ip=209.85.215.51; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f51.google.com;
Received: from mail-la0-f51.google.com ([209.85.215.51])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFt1E-0001bg-Ta
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 21:15:33 +0000
Received: by mail-la0-f51.google.com with SMTP id fo13so1651148lab.24
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 14:15:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.148.133 with SMTP id ts5mr19156432lab.2.1363209322170;
Wed, 13 Mar 2013 14:15:22 -0700 (PDT)
Received: by 10.112.96.164 with HTTP; Wed, 13 Mar 2013 14:15:22 -0700 (PDT)
Date: Wed, 13 Mar 2013 14:15:22 -0700
Message-ID: <CAAS2fgSxZw56TNzGEBeTpykJcc=4WKixG2LEd3EnY46z7wy1VA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: 1UFt1E-0001bg-Ta
Cc: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] On fork awareness Was: 0.8.1 ideas
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: Wed, 13 Mar 2013 21:15:34 -0000
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins <andyparkins@gmail.com> wrote=
:
> On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
>> Here's a simple proposal to start discussion from...
>
> It seems to me that the biggest failure was not the development of two
> chains, but the assurance to users (by the client) that their transaction=
s
The development of two chains was maximally bad because the state was
irreconcilable without the manual intervention. The only reason you're
saying that it was only the false confirms that were bad is because
manual intervention resolved the worse badness. :) A whole bunch of
people spending coins that can only exist in the different exclusive
chains would have been very bad indeed.
> Is it possible to change the definition of "6 confirmations" so that it's
> something like: "six confirmations clear of any other chain". While ther=
e
> are two competing chains, it's possible that one will go pop at any momen=
t.
> That makes the confirmation count of any transaction on one of those chai=
ns,
> zero.
Not reliably, you will only hear of a competing chain if some of your
peers have accepted it. If your peers were all pre-0.8 or all 0.8 you
only would have heard of one chain.
Relaying non-primary chains has some obvious and subtle challenges=E2=80=94
Obviously you need some way of preventing it from being a DOS vector,
but thats not a fundamental issue=E2=80=94 you could rate limit by only
relaying chains which are close to the current best in sum difficulty=E2=80=
=94
just a software engineering one.
A more subtle issue is it that it's not in a node's self-interest to
tell peers about a chain it thinks is invalid: it wants its peers on
_its_ view of the consensus, not some other one. Though perhaps this
could be addressed by only relaying headers for non-primary chains.
|
