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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6F11C67
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 06:19:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 5C35390
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 06:19:56 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 2154C38A5382;
Wed, 21 Oct 2015 06:18:57 +0000 (UTC)
X-Hashcash: 1:25:151021:bitcoin-dev@lists.linuxfoundation.org::B8yZCx=5Mnsig5Tc:aAcnD
X-Hashcash: 1:25:151021:decker.christian@gmail.com::u+5Onv/S7Z/O0WXT:deM=9
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Christian Decker <decker.christian@gmail.com>
Date: Wed, 21 Oct 2015 06:18:54 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; )
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
In-Reply-To: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201510210618.56159.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham 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: Wed, 21 Oct 2015 06:19:57 -0000
On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote:
> The proposal is implemented (see below), by computing the normalized
> transaction ID when adding them to the UTXO and storing them along with the
> coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
> OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
> how to best refactor the common functionality into reusable blocks. And the
> annotating incoming transactions with their normalized inputs is a bit
> cumbersome, maye somebody has some pointers here as well?
This doesn't completely close malleability (which should be documented in the
BIP), so I'm not sure it's worth the cost, especially if closing malleability
later on would need more. How about specifying flags upfront in the UTXO-
creating transaction specifying which parts the signature will cover? This
would allow implementation of fully malleability-proof wallets.
Additionally, you have a flag to control whether the opcode behaves as VERIFY
or not. Non-VERIFY is not possible as a softfork (without doing a second/new
P2SH) since it can be negated.
Luke
|
