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
|
Return-Path: <s7r@sky-ip.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5164C409
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2015 22:22:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com
[162.222.225.14])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 99742137
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2015 22:22:50 +0000 (UTC)
Received: from [0.0.0.0] (exit-tor.tykva.info [209.133.66.214])
(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 13F6B1A1B3A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2015 22:22:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
s=20110108; t=1445293369;
bh=a5F4vs6XiDxBx7RYzxCg5PmCZdSxcIwKToi//xHXAL0=;
h=Reply-To:Subject:References:To:From:Date:In-Reply-To;
b=c0Pm42MLK2apmQlGa804Nrgjd7vxldDa930qAV4eVHANHw+Y5FO5R6UYYyHBv9Y/V
Nxg/IiiAIAwQ2kzA2SjRoJVIqGcDKnEUO6a+lBoCZRhOhPze7n1kpiQjulF9QXfpSY
dyvOc6RWtdIisqyYCDs5Tc6yrRYXt3hyXq95Hx+Q=
Reply-To: s7r@sky-ip.org
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<CAE-z3OUrM=0XsdfdU2d9h6uhCh9vP83X-OZR8NyAYsvYuE1vtg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
From: s7r <s7r@sky-ip.org>
X-Enigmail-Draft-Status: N1010
Message-ID: <56256D36.5050801@sky-ip.org>
Date: Tue, 20 Oct 2015 01:22:46 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAE-z3OUrM=0XsdfdU2d9h6uhCh9vP83X-OZR8NyAYsvYuE1vtg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=IPz/cVbG c=1 sm=1 tr=0
a=QVMj3kqrJ5NkcnqZZZ66eQ==:117 a=QVMj3kqrJ5NkcnqZZZ66eQ==:17
a=N659UExz7-8A:10 a=QPuc3nO-0ARW_2InZ1EA:9 a=pILNOxqGKmIA:10
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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: Mon, 19 Oct 2015 22:22:58 -0000
So what exactly is used to create the normalized txid (sha256 hash of
what data)? I've read in the linked BIP draft that it will strip the
'malleable parts' but didn't understand what exactly will be used to
calculate the normalized transactions ids and how will the change apply
retro-active for the transactions so deep buried in the blockchain?
Pubkeys (addresses) can be reused infinitely so what guarantees us
unique normalized txids all the time and protection against replay
attacks? The question is not if this issue is covered or not, I know it
is, I am just asking how, in simpler terms.
SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document.
Will it also fix > third level malleability (a tx which spends from
another unconfirmed tx which spends from yet another unconfirmed tx)?
On 10/19/2015 6:23 PM, Tier Nolan via bitcoin-dev wrote:
> On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> As with the previous version, which was using a hard-fork, the
> normalized transaction ID is computed only considering the
> non-malleable parts of a transaction, i.e., stripping the signatures
> before computing the hash of the transaction.
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> Is this proposal recursive?
>
> *Coinbase transaction
> *
>
> * n-txid = txid
>
> *Non-coinbase transactions
> *
> * replace sigScripts with empty strings
> * replace txids in TxIns with n-txid for parents
>
> The 2nd step is recursive starting from the coinbases.
>
> In effect, the rule is that txids are what they would have been if
> n-txids had been used right from the start.
>
>
|
