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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <runesvend@gmail.com>) id 1WDbUa-0005sC-C2
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Feb 2014 15:12:52 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.180 as permitted sender)
client-ip=74.125.82.180; envelope-from=runesvend@gmail.com;
helo=mail-we0-f180.google.com;
Received: from mail-we0-f180.google.com ([74.125.82.180])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WDbUZ-0008Ae-8z
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Feb 2014 15:12:52 +0000
Received: by mail-we0-f180.google.com with SMTP id u57so6157106wes.11
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Feb 2014 07:12:45 -0800 (PST)
X-Received: by 10.194.78.16 with SMTP id x16mr1155463wjw.86.1392217965153;
Wed, 12 Feb 2014 07:12:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.24.170 with HTTP; Wed, 12 Feb 2014 07:12:25 -0800 (PST)
In-Reply-To: <20140210030048.GB31925@savin>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
<20140210030048.GB31925@savin>
From: =?ISO-8859-1?Q?Rune_Kj=E6r_Svendsen?= <runesvend@gmail.com>
Date: Wed, 12 Feb 2014 16:12:25 +0100
Message-ID: <CAH2=CKzNGN7mpe1NLtsLRNSszSD2ZNwjoAsaH40EvGtA5ezDeQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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
(runesvend[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
X-Headers-End: 1WDbUZ-0008Ae-8z
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
malleability
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, 12 Feb 2014 15:12:52 -0000
Instead of trying to remove the possibility of transaction
malleability, would it make sense to define a new, "canonical
transaction hash/ID" (cTxID), which would be a hash of the part of the
transaction data which we know is not malleable, and have clients use
this cTxID internally, thus making the traditional transaction hash
irrelevant for a client to function correctly?
We already have a non-malleable transaction hash: the hash that is
signed, ie. the transaction with each scriptSig replaced by the
scriptPubKey it redeems. This could be the cTxID.
Or is this simply a too fundamental change to the way bitcoin-qt (and
all other clients) work in order to be feasible?
As far as I can see, it completely solves the issue of not having a
canonical ID for a transaction, but it also increases the
computational requirements for a node. For one, as far as I can see,
it requires the node to index all transactions, because in order to
calculate a cTxID, it would be necessary to fetch all transactions
referred to by the transaction in question, in order to pull in the
scriptPubKeys that are redeemed.
On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
>> Hello all,
>>
>> it was something I planned to do since a long time, but with the
>> recent related issues popping up, I finally got around to writing a
>> BIP about how we can get rid of transaction malleability over time.
>>
>> The proposed document is here: https://gist.github.com/sipa/8907691
>>
>> I expect most rules to not be controversial. Maybe rules 1 and 3, as
>> they require modifications to wallet software (Bitcoin Core 0.9 and
>> BitcoinJ already implement it, though) and potentially invalidate some
>> script functionality. However, these new rules remain optional and
>> controlled by an nVersion increase.
>>
>> Comments please!
>
> You should probably add making CHECKMULTISIG require the dummy value to
> be exactly equal to OP_FALSE; verifying that in the transaction itself is
> laborious. A more subtle example is we may want both CHECKSIG and
> CHECKMULTISIG to fail the transaction if the signature is invalid but
> not exactly equal to OP_FALSE; some transaction forms are significantly
> more compact if you can have failed signatures, but that's a source of
> malleability. (are there counter examples people can think of?)
>
>
> But as I said on IRC, I'm a bit hesitant to bake in assumptions about
> malleability when we have no solid idea if ECC signatures are or are not
> malleable on a fundemental level; if "whack-a-mole" anti-malleability is
> all we've got it could be ugly if a break is found. Similarly, we may
> find we missed something, or some needed change makes the malleability
> rules difficult to work with for some new script type that is required.
>
> I'd rather see a new CHECKSIG mode for the case where malleability
> absolutely must be eliminated - certain multi-party protocols - and fix
> wallet software instead. (the malleability problems people see are
> closely related to inability to handle double-spends and reorgs) But I
> can easily see that being an impossible goal engineering wise...
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
