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
178
179
180
181
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <s7r@sky-ip.org>) id 1YtCL1-0006Ui-FH
for bitcoin-development@lists.sourceforge.net;
Fri, 15 May 2015 09:55:29 +0000
Received-SPF: neutral (sog-mx-1.v43.ch3.sourceforge.com: 162.222.225.20 is
neither permitted nor denied by domain of sky-ip.org)
client-ip=162.222.225.20; envelope-from=s7r@sky-ip.org;
helo=outbound.mailhostbox.com;
Received: from outbound.mailhostbox.com ([162.222.225.20])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YtCKm-0000WE-93 for bitcoin-development@lists.sourceforge.net;
Fri, 15 May 2015 09:55:27 +0000
Received: from [0.0.0.0] (manning1.torservers.net [96.44.189.100])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id 9A92F78184C;
Fri, 15 May 2015 09:54:59 +0000 (GMT)
Message-ID: <5555C26F.7080706@sky-ip.org>
Date: Fri, 15 May 2015 12:54:55 +0300
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Christian Decker <decker.christian@gmail.com>,
Bitcoin Development <bitcoin-development@lists.sourceforge.net>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
In-Reply-To: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=Ou6ysHLt c=1 sm=1 tr=0
a=s8xZHfdCR1WDCFMteBX5PQ==:117 a=s8xZHfdCR1WDCFMteBX5PQ==:17
a=ZDnEzkWgAAAA:8 a=-NIMs_s3AAAA:8 a=SY9aFQKHIdAA:10 a=N659UExz7-8A:10
a=bvjBBkZ6AAAA:8 a=NEAV23lmAAAA:8 a=JcT1meiOAAAA:8 a=FP58Ms26AAAA:8
a=R31bUt4ix5t8YeTpn7cA:9 a=1VWO3H-3S_Oj3jQk:21 a=z4g78kI1aK7fx81u:21
a=pILNOxqGKmIA:10
X-CTCH-RefID: str=0001.0A020203.5555C274.0101, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: s7r@sky-ip.org
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.8 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [162.222.225.20 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1YtCKm-0000WE-93
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: s7r@sky-ip.org
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: Fri, 15 May 2015 09:55:29 -0000
Hello,
How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
b) replays
If you strip just the scriptSig of the input(s), the txid(s) can still
be mutated (with higher probability before it gets confirmed).
If you strip both the scriptSig of the parent and the txid, nothing can
any longer be mutated but this is not safe against replays. This could
work if we were using only one scriptPubKey per tx. But this is not
enforced, and I don't think it's the proper way to do it.
Something similar can be achieved if you would use a combination of
flags from here:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
But this has some issues too.
I've read your draft but didn't understand how exactly will this prevent
normal malleability as we know it, second level malleability and replays
as well as how will we do the transition into mapping the txes in the
blockchain to normalized txids. Looking forward to read more on this
topic. Thanks for the brainstorming ;)
On 5/13/2015 3:48 PM, Christian Decker wrote:
> Hi All,
>=20
> I'd like to propose a BIP to normalize transaction IDs in order to
> address transaction malleability and facilitate higher level protocols.
>=20
> The normalized transaction ID is an alias used in parallel to the
> current (legacy) transaction IDs to address outputs in transactions. It
> is calculated by removing (zeroing) the scriptSig before computing the
> hash, which ensures that only data whose integrity is also guaranteed b=
y
> the signatures influences the hash. Thus if anything causes the
> normalized ID to change it automatically invalidates the signature. Whe=
n
> validating a client supporting this BIP would use both the normalized t=
x
> ID as well as the legacy tx ID when validating transactions.
>=20
> The detailed writeup can be found
> here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.med=
iawiki.
>=20
> @gmaxwell: I'd like to request a BIP number, unless there is something
> really wrong with the proposal.
>=20
> In addition to being a simple alternative that solves transaction
> malleability it also hugely simplifies higher level protocols. We can
> now use template transactions upon which sequences of transactions can
> be built before signing them.
>=20
> I hesitated quite a while to propose it since it does require a hardfor=
k
> (old clients would not find the prevTx identified by the normalized
> transaction ID and deem the spending transaction invalid), but it seems
> that hardforks are no longer the dreaded boogeyman nobody talks about.
> I left out the details of how the hardfork is to be done, as it does no=
t
> really matter and we may have a good mechanism to apply a bunch of
> hardforks concurrently in the future.
>=20
> I'm sure it'll take time to implement and upgrade, but I think it would
> be a nice addition to the functionality and would solve a long standing
> problem :-)
>=20
> Please let me know what you think, the proposal is definitely not set i=
n
> stone at this point and I'm sure we can improve it further.
>=20
> Regards,
> Christian
>=20
>=20
> -----------------------------------------------------------------------=
-------
> One dashboard for servers and applications across Physical-Virtual-Clou=
d=20
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insight=
s
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>=20
>=20
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
|
