summaryrefslogtreecommitdiff
path: root/34/77a6c4ffc30998a2b7347f18ee6aed844c93f1
blob: 101c62862972cffc496990cc8c3bb5c31d1216fe (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tier.nolan@gmail.com>) id 1YsWSv-00034Z-Dq
	for bitcoin-development@lists.sourceforge.net;
	Wed, 13 May 2015 13:12:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.181 as permitted sender)
	client-ip=209.85.216.181; envelope-from=tier.nolan@gmail.com;
	helo=mail-qc0-f181.google.com; 
Received: from mail-qc0-f181.google.com ([209.85.216.181])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YsWSu-0006z8-K4
	for bitcoin-development@lists.sourceforge.net;
	Wed, 13 May 2015 13:12:49 +0000
Received: by qcbgy10 with SMTP id gy10so21742546qcb.3
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 May 2015 06:12:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.217.17 with SMTP id n17mr27779586qhb.69.1431522763227;
	Wed, 13 May 2015 06:12:43 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Wed, 13 May 2015 06:12:43 -0700 (PDT)
In-Reply-To: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
Date: Wed, 13 May 2015 14:12:43 +0100
Message-ID: <CAE-z3OWUGPqruBkuXggzdNkOn+L-SSg84Qd1_JZYBunmY+j=HQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1139b816ca68150515f65dd8
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(tier.nolan[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.2 MISSING_HEADERS        Missing To: header
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	1.9 MALFORMED_FREEMAIL Bad headers on message from free email service
	-0.3 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YsWSu-0006z8-K4
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 13 May 2015 13:12:49 -0000

--001a1139b816ca68150515f65dd8
Content-Type: text/plain; charset=UTF-8

I think this is a good way to handle things, but as you say, it is a hard
fork.

CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
fix malleability once and for all.

This has the effect of doubling the size of the UTXO database.  At minimum,
there needs to be a legacy txid to normalized txid map in the database.

An addition to the BIP would eliminate the need for the 2nd index.  You
could require a SPV proof of the spending transaction to be included with
legacy transactions.  This would allow clients to verify that the
normalized txid matched the legacy id.

The OutPoint would be {LegacyId | SPV Proof to spending tx  | spending tx |
index}.  This allows a legacy transaction to be upgraded.  OutPoints which
use a normalized txid don't need the SPV proof.

The hard fork would be followed by a transitional period, in which both
txids could be used.  Afterwards, legacy transactions have to have the SPV
proof added.  This means that old transactions with locktimes years in the
future can be upgraded for spending, without nodes needing to maintain two
indexes.

--001a1139b816ca68150515f65dd8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think this is a good way to handle things, but as y=
ou say, it is a hard fork.<br><br></div>CHECKLOCKTIMEVERIFY covers many of =
the use cases, but it would be nice to fix malleability once and for all.<b=
r><div><div><br>This has the effect of doubling the size of the UTXO databa=
se.=C2=A0 At minimum, there needs to be a legacy txid to normalized txid ma=
p in the database.<br><br></div><div>An addition to the BIP would eliminate=
 the need for the 2nd index.=C2=A0 You could require a SPV proof of the spe=
nding transaction to be included with legacy transactions.=C2=A0 This would=
 allow clients to verify that the normalized txid matched the legacy id.<br=
><br></div><div>The OutPoint would be {LegacyId | SPV Proof to spending tx=
=C2=A0 | spending tx | index}.=C2=A0 This allows a legacy transaction to be=
 upgraded.=C2=A0 OutPoints which use a normalized txid don&#39;t need the S=
PV proof.<br><br></div><div>The hard fork would be followed by a transition=
al period, in which both txids could be used.=C2=A0 Afterwards, legacy tran=
sactions have to have the SPV proof added.=C2=A0 This means that old transa=
ctions with locktimes years in the future can be upgraded for spending, wit=
hout nodes needing to maintain two indexes.<br></div></div></div>

--001a1139b816ca68150515f65dd8--