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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 742AA8DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 09:38:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DF74112
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 09:38:14 +0000 (UTC)
Received: by wicll6 with SMTP id ll6so5716483wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 05 Nov 2015 01:38:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=84vB4QvPjMOVNxjT3gFILXGHS2FR8iHK1stWVMi6J0s=;
b=1C5VbqBrnAxLP1Wft9KoQ5bqVuKcpgUhxcOU2sAw0zKmwTK7u2rXjGB/K2fysf0Umt
1zHmEyxzn7kS7M/u8o8ZviakX8J0JRdtEd97claNMDauMUkZmFCIag5fk7ImBH38yGQ7
lXoWNe6phdhoYlvdV0MOstiPGJDG2ih3KT+9sIDERcdKtdoEp2HeSa6oboJPEpk2YVt2
8GQUu6Bc7Rl1iNnYySzY+n80XTh24AlWpb2HaRICA6OPTVHhoLY1jrvZoKIqMW20btFE
enEVw7kCtBNjS6Yfo1ahWyq09uKGjXmVY3nYOs8szhH0lPMjNqcywVO6RTj5XutnLo9g
4Fug==
X-Received: by 10.194.243.227 with SMTP id xb3mr7994607wjc.96.1446716292698;
Thu, 05 Nov 2015 01:38:12 -0800 (PST)
MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201510220905.27124.luke@dashjr.org>
<CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com>
<201511032048.18680.luke@dashjr.org>
<CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
<20151104040033.GA26961@muck>
In-Reply-To: <20151104040033.GA26961@muck>
From: Christian Decker <decker.christian@gmail.com>
Date: Thu, 05 Nov 2015 09:38:03 +0000
Message-ID: <CALxbBHV=ge4fZ9Rma+UmOKs8amDc+yxzb+eUxcCEPmcOb4tsxQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0141a162b7a12f0523c7e2a1
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 05 Nov 2015 09:38:15 -0000
--089e0141a162b7a12f0523c7e2a1
Content-Type: text/plain; charset=UTF-8
This does indeed sound reasonable. The chances of having a cut in the
network consisting of non-upgraded nodes partitioning the network and not
forwarding the segregated witnesses should be minimal, given a long rollout
phase before the activation.
If everybody agrees that this is a better way to approach the normalization
issue we should probably start writing it up and see if we can get critical
mass behind it :-)
On Wed, Nov 4, 2015 at 5:00 AM Peter Todd <pete@petertodd.org> wrote:
> On Tue, Nov 03, 2015 at 09:44:02PM +0000, Christian Decker via bitcoin-dev
> wrote:
> > Ok, so assuming we can get a connected component of upgraded nodes that
> > relay both the transaction and the associated external scripts then we
> > could just piggyback the external scripts on top of the normal messages.
> > Non-upgraded nodes will read the entire two-part message but only parse
> the
> > classical transaction, dropping the external script. Validation rules for
> > upgraded nodes are the same as before: if the attached signatures are
> > invalid the entire TX is dropped. We have to commit to the external
> scripts
> > used during the creation of a block. I think the easiest way to add this
> > commitment is the coinbase input I guess, and following the transaction
> > list a new list of signature lists is shipped with the rest of the block.
> > Non-upgraded will ignore it as before.
> >
> > Would that work? It all hinges on having upgraded miners in a connected
> > component otherwise non-upgraded nodes will drop the external scripts on
> > the way (since they parse and then reconstruct the messages along the
> > path). But if it works this could be a much nicer solution.
>
> FWIW my replace-by-fee fork does preferential peering with other RBF
> nodes to ensure that you'll always be connected to at least some
> full-RBF peers. In practice this works very well, and I'm sure a similar
> scheme could be used in this situation as well.
>
> Basically, conceptually unless you're connected to peers that advertise
> that they relay the new data, you treat the situation as though you're
> not connected to any peers at all. No different than if for some reason
> none of your peers were advertising NODE_NETWORK.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000247b0e7436a5169ac6f9087be0295d10b07bf0bcbd4c0cc
>
--089e0141a162b7a12f0523c7e2a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This does indeed sound reasonable. The chances of having a=
cut in the network consisting of non-upgraded nodes partitioning the netwo=
rk and not forwarding the segregated witnesses should be minimal, given a l=
ong rollout phase before the activation.<div><br></div><div>If everybody ag=
rees that this is a better way to approach the normalization issue we shoul=
d probably start writing it up and see if we can get critical mass behind i=
t :-)</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, No=
v 4, 2015 at 5:00 AM Peter Todd <<a href=3D"mailto:pete@petertodd.org">p=
ete@petertodd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On=
Tue, Nov 03, 2015 at 09:44:02PM +0000, Christian Decker via bitcoin-dev wr=
ote:<br>
> Ok, so assuming we can get a connected component of upgraded nodes tha=
t<br>
> relay both the transaction and the associated external scripts then we=
<br>
> could just piggyback the external scripts on top of the normal message=
s.<br>
> Non-upgraded nodes will read the entire two-part message but only pars=
e the<br>
> classical transaction, dropping the external script. Validation rules =
for<br>
> upgraded nodes are the same as before: if the attached signatures are<=
br>
> invalid the entire TX is dropped. We have to commit to the external sc=
ripts<br>
> used during the creation of a block. I think the easiest way to add th=
is<br>
> commitment is the coinbase input I guess, and following the transactio=
n<br>
> list a new list of signature lists is shipped with the rest of the blo=
ck.<br>
> Non-upgraded will ignore it as before.<br>
><br>
> Would that work? It all hinges on having upgraded miners in a connecte=
d<br>
> component otherwise non-upgraded nodes will drop the external scripts =
on<br>
> the way (since they parse and then reconstruct the messages along the<=
br>
> path). But if it works this could be a much nicer solution.<br>
<br>
FWIW my replace-by-fee fork does preferential peering with other RBF<br>
nodes to ensure that you'll always be connected to at least some<br>
full-RBF peers. In practice this works very well, and I'm sure a simila=
r<br>
scheme could be used in this situation as well.<br>
<br>
Basically, conceptually unless you're connected to peers that advertise=
<br>
that they relay the new data, you treat the situation as though you're<=
br>
not connected to any peers at all. No different than if for some reason<br>
none of your peers were advertising NODE_NETWORK.<br>
<br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
00000000000000000247b0e7436a5169ac6f9087be0295d10b07bf0bcbd4c0cc<br>
</blockquote></div>
--089e0141a162b7a12f0523c7e2a1--
|
