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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7BC9B71F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 18:08:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
[74.201.84.163])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E540B296
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 18:08:19 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
mx.zohomail.com with SMTPS id 1479406092316156.7201289152149;
Thu, 17 Nov 2016 10:08:12 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <59D27CC6-120C-4673-9F20-6B5E95EA60C6@voskuil.org>
Date: Fri, 18 Nov 2016 02:08:09 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F2B3EA2-4245-4A0E-8E19-12D02A871815@xbt.hk>
References: <CABm2gDr2-MCiaFFjgUFP5Xc0fQfuqJ3=ZkrzjHqmOiwRZ50CBw@mail.gmail.com>
<d58ee114-00fd-23c8-9ca7-9a4b28c26f27@voskuil.org>
<CAE-z3OX5vak25UWcmBSe63OmoOVoGB394WmwyWwUcSxWeDOLhw@mail.gmail.com>
<e0e6679f-aec6-a579-667d-b5b58ea2360b@voskuil.org>
<CAE-z3OXfJa3Lewtrafm25bdfPa=eiarOAXBNbgc3ccTi7Qoe6A@mail.gmail.com>
<5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org>
<CAPWm=eW9X77+qQZGHkAOjN-k7KFwq06gKS6HOVOTE1+SmYBhWA@mail.gmail.com>
<34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org>
<FA128F93-7E79-47FE-8270-225D07DD6FEF@xbt.hk>
<8d92ae05-ac6a-30b7-5ef3-f7aa1298e46d@voskuil.org>
<632B36D5-74AF-41E2-8E21-359F02645066@xbt.hk>
<59D27CC6-120C-4673-9F20-6B5E95EA60C6@voskuil.org>
To: Eric Voskuil <eric@voskuil.org>
X-Mailer: Apple Mail (2.3124)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP
Proposal] Buried Deployments)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 18:08:20 -0000
The fact that some implementations ban an invalid block hash and some do =
not, suggests that it=E2=80=99s not a pure p2p protocol issue. A pure =
p2p split should be unified by a bridge node. However, a bridge node is =
not helpful in this case. Banning an invalid block hash is an implicit =
=E2=80=9Cfirst seen=E2=80=9D consensus rule.
jl2012
> On 18 Nov 2016, at 01:49, Eric Voskuil <eric@voskuil.org> wrote:
>=20
> Actually both possibilities were specifically covered in my =
description. Sorry if it wasn't clear.
>=20
> If you create a new valid block out of an old one it's has potential =
to cause a reorg. The blocks that previously built on the original are =
still able to do so but presumably cannot build forever on the *new* =
block as it has a different tx. But other new blocks can. There is no =
chain split due to a different interpretation of valid, there are simply =
two valid competing chains.
>=20
> Note that this scenario requires not only block and tx validity with a =
tx hash collision, but also that the tx be valid within the block. =
Pretty far to reach to not even get a chain split, but it could produce =
a deep reorg with a very low chance of success. As I keep telling =
people, deep reorgs can happen, they are just unlikely, as is this =
scenario.
>=20
> If you create a new invalid block it is discarded by everyone. That =
does not invalidate the hash of that block. Permanent blocking as you =
describe it would be a p2p protocol design choice, having nothing to do =
with consensus. Libbitcoin for example does not ban invalidated hashes =
at all. It just discards the block and drops the peer.
>=20
> e
|
