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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F94D8A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Nov 2015 04:00:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149101.authsmtp.com (outmail149101.authsmtp.com
[62.13.149.101])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 88F7690
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Nov 2015 04:00:46 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA440efJ096526;
Wed, 4 Nov 2015 04:00:40 GMT
Received: from muck ([50.58.157.74]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA440Yl0026578
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 4 Nov 2015 04:00:37 GMT
Date: Tue, 3 Nov 2015 23:00:33 -0500
From: Peter Todd <pete@petertodd.org>
To: Christian Decker <decker.christian@gmail.com>
Message-ID: <20151104040033.GA26961@muck>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
X-Server-Quench: 9ba2cf8e-82a8-11e5-bcde-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUFloCAgsB AmMbW1BeUF17Wms7 bgpPaA1DY09JQQJu
T01BRU1TWkEZBRgB b0IeUht0cgJONn9w YkVmEHkJDUYpI04o
X0ZWRGUbZGY1bX1N AxQNagNUcQZLeRkW O1F2XD1vNG8XDSg5
AwQ0PjZ0MThBHWxm aCA1GBo0RlwOFzo9 VR0OVSk1FEseTi4v LhsgYn8wBy4A
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 50.58.157.74/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Wed, 04 Nov 2015 04:00:47 -0000
--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 t=
he
> 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 scrip=
ts
> 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.
>=20
> 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.
--=20
'peter'[:-1]@petertodd.org
00000000000000000247b0e7436a5169ac6f9087be0295d10b07bf0bcbd4c0cc
--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWOYLcXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZDhkMTNhMDM5M2JlZTIwNjhkZGUxZjI3MzJiNjc4NmUx
MGQzODM4NDcxMzA4NDUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyzFQf/dAaIRXA2rTnHnUCB4VztI+Yy
mE0oX81wtUsnei/JtxzTr5Z92zxSMLvxgrDAscywDCapHicdbNUj4UDeXJ7CyeL3
/cZOcxlsQYYqfe8pJqFtwZKtfNUqlni4xYH5fjyQBjMjdFAGB/ICbSVSnmKkiV62
nldkUx1jg5jdMNXntuWC9zu7alnfcp4crfyy3hEM6m0WBTAjOPn7uhPTMK2B0uBS
AdAOI07LG++ztys3SiUBluDnkzXhufOlocyeSOqhfJGEZMFVihst/lFM22NveNzl
wWf7j0b4MGPze9udgmtkM8ZsiyI/ZpFUqjN3AWJOQv2KvOON5wHk8Rtou4283g==
=ul4p
-----END PGP SIGNATURE-----
--HcAYCG3uE/tztfnV--
|
