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
|
Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 051C09C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 22:34:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
[209.85.218.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 603BEE2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 22:34:44 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id r126so150566131oib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 15:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=/yFBLj38VL9b77ibRrmybNZBpgvWDkGXPwo234nej0c=;
b=ljN8iAPGT7vt1u+Yz5eOX9TQTczKMkFI6FwiKDjVBUcJifkJN7zOQqSmUyslSMePQm
vH+D//xh7kN8YEa8Z0LqlEw35HABf+e65/Qyi4So30MyhWkzyhwuoigU3OgpR4X1BcKt
PQDYSfyag7bIQupjOskiF1MDEbE16U6aMse2qb82MyRxgZaiEZLAhrsFAHxvEHrEXhTk
Wfw7Xbv1Qhu9F3shfGhqHAwPxWNuVHpNmlBlMZnY62kL45/Rzsm7cYg2p+F6Y5Fadedj
VqT7iBi2gGeOvNYYjAnEAvdr9FRKZ+ni3IsGVKBtOFMGdcW/Bp+7gGARisEYsCLAWQZv
wlig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=/yFBLj38VL9b77ibRrmybNZBpgvWDkGXPwo234nej0c=;
b=dl2pJ3OEDSrpu2pXxRk7+awg6YvGwHjlReHEqRnXhPrF7CzsZL+pAAYFF55BwAr5fc
aPxZJuSIEKULK2OmwzpsEXXZVWDOMWjFOH2phuU1+wSw/hOUW93TjZR/+9enZjJlayzi
46676u++p8+PeG4IDfNjgkUN1FoHsp0qHaxt7BHUxP4eTcV2RUOFFs0RaRw1XMJQwcKY
KBzN7IF1Jdp527CBPp/jFDtB7bEyXCLX64Aa2xfBp08Gyb1DQOl6s7Gh9H2JMGMEep54
ARDJjAoYQP9QY/i1qh2p1CUh5AbeuK7hj3G9gZPJcp2C3ByaIpxK3zQLIGuvG2e5/0La
QpTA==
X-Gm-Message-State: AE9vXwOxB69esN37Y7VlHq4ywZT3Ko/wioePVLpFAzmZed0VhrUNWq9FXn9kmbs4SI28NokN0iIwJKc51BUI7g==
X-Received: by 10.202.228.69 with SMTP id b66mr19745940oih.168.1474151683750;
Sat, 17 Sep 2016 15:34:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.52.39 with HTTP; Sat, 17 Sep 2016 15:34:43 -0700 (PDT)
In-Reply-To: <CAH2=CKzcNu-jWPr3AKhpTN_cyGVO67oPCMQx2hUrp=Ax_+wvCw@mail.gmail.com>
References: <CAH2=CKzsHROCXQHRS25i5O8XUPkbwFMDAFC_CO9MD6RuJajA4g@mail.gmail.com>
<715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
<CAH2=CKzcNu-jWPr3AKhpTN_cyGVO67oPCMQx2hUrp=Ax_+wvCw@mail.gmail.com>
From: Nick ODell <nickodell@gmail.com>
Date: Sat, 17 Sep 2016 16:34:43 -0600
Message-ID: <CANN4kmd2N_iguM1KKWO8dgV_ZhO-qkk4bON6vfNySLdYQQjwGg@mail.gmail.com>
To: "Rune K. Svendsen" <runesvend@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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] Simple tx ID malleability fix,
opcode proposal: OP_TXHASHVERIFY
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sat, 17 Sep 2016 22:34:45 -0000
Then you have a new problem. Hash1 must contain Hash2 and the
transaction, but Hash2 must contain Hash1 and the transaction. A
circular dependency.
--Nick
On Sat, Sep 17, 2016 at 3:14 PM, Rune K. Svendsen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I hadn't thought of that... There is a solution, I think, but it makes the
> operation less simple.
>
> If a transaction contains at least two OP_TXHASHVERIFY-protected inputs,
> signed without ANYONECANPAY, their signatures would cover the other input's
> OP_TXHASHVERIFY hash, right?
>
>
> /Rune
>
>
> On Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>>
>> (removing the list)
>>
>> Because the tx hash in your construction is not signed, someone wishing to
>> maleate a transaction may do so by also updating the hash in the scriptSig.
>>
>> Matt
>>
>> On September 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev"
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> I would really like to be able to create transactions that are immune to
>>> transaction ID malleability now, so I have been thinking of the simplest
>>> solution possible, in order to get a BIP through without too much trouble.
>>>
>>> An opcode we could call OP_TXHASHVERIFY could be introduced. It would be
>>> defined to work only if added to a scriptSig as the very first operation,
>>> and would abort if the hash of the transaction **with all OP_TXHASHVERIFY
>>> operations (including stack push) removed** does not match what has been
>>> pushed on the stack.
>>>
>>> So, in order to produce a transaction with one or more inputs protected
>>> against tx ID malleability, one would:
>>>
>>> 1. Calculate tx ID of the tx: TX_HASH
>>> 2. For each input you wish to protect, add "0x32 $TX_HASH
>>> OP_TXHASHVERIFY" to the beginning of the scriptSig
>>>
>>> When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question,
>>> and remove the "0x32 <32 bytes> OP_TXHASHVERIFY" sequence from the beginning
>>> of all scriptSigs (if present), and abort if the tx copy hash does not match
>>> the top stack item.
>>>
>>> This is a very simple solution that only adds 34 bytes per input, and
>>> when something better becomes available (eg. Segwit), we will stop using
>>> this. But in the meantime it's very valuable to be able to not worry about
>>> tx ID malleability.
>>>
>>> Please let me know what you think.
>>>
>>>
>>>
>>> /Rune
>>>
>>> ________________________________
>>>
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
