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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6DCBA360
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 21:02:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D550F128
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 21:02:47 +0000 (UTC)
Received: by mail-pg0-f51.google.com with SMTP id 81so36993256pgh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 14:02:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=0HN/snQv6chHUr36dTgjqHLDjWh16uXk2UNKnH9/llw=;
b=2Coq0hn1VkEgH+L9jvr3u9Dq9HEA/r+aTYTgWrr027b4vBBBRTvvhX2Oa/g5pS92XN
0UuF+PZO/J777NUZi/b5Mrb3c2oac8vS4SEtUd6Oilt6dT0gT18kwNsFAqxmiI6sC2Ko
XYmZb3ZsUS7sb6bQqorqkndCOxSOWhbqllT42kqu3Ej9JITfnW3WTzDPqvCe5qM9MsWm
UZTEyQNNftL0TLd6keutslUwSjSFv00gS2FHdvxswvA/dhuFAwC6BFWX8V9g80mmSjy5
456HLodW9N2jlhPYI3I1LTLHd/iZq99qXgTrTCvp4pFPpG6FlAvYge3tx/A2K4H15Gj2
Gfmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=0HN/snQv6chHUr36dTgjqHLDjWh16uXk2UNKnH9/llw=;
b=YDuTjvaANI9qsIa8Oy/Adcnk8hjBiJ2pzMIWIMI3w73g+1qpvYxjx5NDpYqkHWjfxp
C1iHhScDIdKA27diRuzyyMt77cjvQWCwDXtpZbMJrcJJYiFUvlA/c0TpAFN3kn/fSs5Z
ZN96T263ZVQs2tS4bueC8Ix3gHfwLjcVUbdPZ8NSKO+JQaCgtAhcyo4N7hMEHD3Ug3YS
A1hwg0XGJSaxuFAVIl1hzcEP3zG8yGRWvELVQj2iIJMglAJDbGMyCY4dpoyPa8VsuonW
sU2Ff8GAGBvd5Yljhd9E464peTxgkL4RCBl/WooJeVX+iNdXxU65nAiDngJYVtkqN7Xi
+M/Q==
X-Gm-Message-State: AFeK/H0bmXI/R2oQ+f+Z4f7p6XDVMrnquwIseAirMrJ7ibOLLHn1ilS3peo0EvFU91tKoQ==
X-Received: by 10.99.47.68 with SMTP id v65mr26473534pgv.23.1490648567236;
Mon, 27 Mar 2017 14:02:47 -0700 (PDT)
Received: from ?IPv6:2601:600:9000:d69e:8c11:8163:4024:ef42?
([2601:600:9000:d69e:8c11:8163:4024:ef42])
by smtp.gmail.com with ESMTPSA id
t12sm2932768pfg.14.2017.03.27.14.02.46
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 27 Mar 2017 14:02:46 -0700 (PDT)
To: Suhas Daftuar <sdaftuar@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAFp6fsHhqdL=MNyAAyfwA7qw5-MhW19Whky+kY3n3=+u61bXBg@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <cacb32cd-387b-2189-141f-3f5f60c38d49@voskuil.org>
Date: Mon, 27 Mar 2017 14:03:08 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAFp6fsHhqdL=MNyAAyfwA7qw5-MhW19Whky+kY3n3=+u61bXBg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Mon, 27 Mar 2017 21:17:48 +0000
Subject: Re: [bitcoin-dev] Segregated witness p2p layer compatibility
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: Mon, 27 Mar 2017 21:02:48 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/27/2017 12:22 PM, Suhas Daftuar via bitcoin-dev wrote:
> Eric Voskuil wrote:
>
>> Given the protocol requirements of the segwit proposal this is
>> not the case. A miner running pre-segwit code will produce
>> blocks that no segwit node will ever receive.
>
> The phrase "protocol requirements of segwit" is confusing here,
> because there are two different layers that need consideration:
> the consensus protocol layer and the peer-to-peer protocol layer.
> But in neither layer is the behavior of not downloading blocks
> from non-NODE WITNESS peers a "requirement". This is an
> implementation detail in the Bitcoin Core code that alternate
> implementations compliant with BIP 144 could implement
> differently.
I agree, and thanks for the detailed clarification. Clearly it is
possible for segwit blocks to be relayed. It is the implementation of
Bitcoin Core (at least), in the absence of sufficient relay, that
produces this outcome.
> This is an implementation detail in the Bitcoin Core code that
> alternate implementations compliant with BIP 144 could implement
> differently.
>
> At the consensus layer, non-segwit blocks (described above) that
> are valid to older nodes are also valid to segwit nodes. That
> means that if a miner was using an older, pre-segwit version of
> Bitcoin Core to produce blocks after segwit activates, that blocks
> they find will be valid to all nodes.
IOW Bitcoin Core has been implemented so that it will not see valid
blocks announced by certain of its peers. Forcing it to see such
blocks requires the p2p network work around its implementation. I
agree that this is not inherent in the specifications for segwit, but
it reads more like a bug than an "implementation detail" to me.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY2X3/AAoJEDzYwH8LXOFOez8H+wcmUkQnzqMlmBTQ/OqMO6q4
enLOX3H4UDa6gZdUxEDpszUvuca2ayukVYwIVo28BcjsTmQgxaxdrFTNTDYTRfe1
S2aX3Ftism0zuEIw8/KM2wcnNaHe9C5Q8TRmW7u6ZoLTJFwCkKWK1VEM9GFDePpT
+HjtdviKt3s6NwiYhG+U+JawF+YDJvxyxcEj28bMFB1EW1kIAPA709oz2scZCPrc
VroEUoFXFgMXBJaosKSVTUN3JE9pU9R1Mn7xVWwMEdU1IjeOeygHjdE/NfP7BJuU
05dWsH0be/xyNO76oFGhmwIyDogloQ9a5klEe7NetTDs1ieMD5j5oyr/qB79spw=
=xkiV
-----END PGP SIGNATURE-----
|
