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
150
151
152
153
154
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 95097486
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 22:29:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDE1F124
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 22:29:48 +0000 (UTC)
Received: from mail-io0-f173.google.com ([209.85.223.173]) by
mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
0LxdxF-1aUqVb08WR-017HrU for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 05 Nov 2015 23:29:48 +0100
Received: by iody8 with SMTP id y8so105817490iod.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 05 Nov 2015 14:29:46 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.15.31 with SMTP id x31mr12562494ioi.51.1446762586973;
Thu, 05 Nov 2015 14:29:46 -0800 (PST)
Received: by 10.50.180.199 with HTTP; Thu, 5 Nov 2015 14:29:46 -0800 (PST)
In-Reply-To: <201511051936.09500.luke@dashjr.org>
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201511032201.21047.luke@dashjr.org>
<CABm2gDpNXGZ7yevFoN9k5nx7wBZX86cH0vJs38DyL+PtEPLHxw@mail.gmail.com>
<201511051936.09500.luke@dashjr.org>
Date: Thu, 5 Nov 2015 23:29:46 +0100
X-Gmail-Original-Message-ID: <CALqxMTGA-SHOgmNDfwTSFS5kwh8wCwJwmGKDNWg3F191SWBBTw@mail.gmail.com>
Message-ID: <CALqxMTGA-SHOgmNDfwTSFS5kwh8wCwJwmGKDNWg3F191SWBBTw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:81Dlf8bKIFrZBYJl43vnMN/r5IlBxDdoAvFg5N8hq/hhkiYAh8y
tJcg2Exje5Qg1Uz7ONaIgcMqW3joJNJoRm4RsZ2R+vitRoap/u/eNv77TeKWPNFTJvxY9FQ
6a1rNUiG8UXBQ05VPsuPGkbvpLlFdxZrOxYtUrJOp11jLTzfR3am6OLIoWpdFE1bU67cwIL
ll81FGn6L/bvjsTVKIhyg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UgHz85KIkig=:LFJpRtWapYkYnDA8BkE5N8
bJW6v2V4TkwETbLVt063qo3ElXTlPCoDOjkwpaa0aL3t5cDpeVVOtrKlc0pvlz/1R660ryf2K
rkN8m0+qVX2yVjJbRSq2cvIGmARp9l2Eb6QterKYiprvI+xblb7pvJX/6AU38ZsF8AyBHDm1x
LH8mZv/E4+27n4J/cAU0E5mIJDiXPcZ69zMUEpAWSSDFfWbC0ICAZdETqtR8Flq5Y0VKUxK+/
8Ma7tNScDj6MzZ3OAt0ba6lBVtce2sJvkpA0TKTI4VQ4s+wGM6lswnwOaAQxu7RbRuBlS2wZn
AnlmFn63swfQecpUH68fLHQB7+G/7Hnur5kPzuUvVeBdwG7Ex+e2MTJaMSPBcbMkR9z2ZKHGa
ZMH1ofHztOuxfq0K2zb8XSix5DAtwj99jkvMvcq9JDWkeA7khxhM5TwVduoqx8Is4Syfh23Vn
s2voCVTq+//RGejhfndsXTit4ZMdNWS7PL8sSHbE0LfZuAIm46wvmuj5viZFZmSDKLJxB8A0Q
2ssuJdegKp2zc+B3gb2uRTjv71fzp9f5QA5q1oGhWy5V+1MM92pQOs8RrJjRiBJ0wZ4XJHOnG
ZzD8LC9j0f8NlVBdXBSJ5yVF5r4gVkYxSNgkQxOqHLTGOgyG7CPyYOM420mMkue83UFaFz9Io
za2v2s9dtL7BioryZVfcyB06UVtnTBr3avlHURiEQMAi+eJD2yS9dPizCbCLdqDAr/5OUgHAX
iOLqxjSNespsWYcr
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 05 Nov 2015 22:30:58 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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: Thu, 05 Nov 2015 22:29:49 -0000
About the conflicting spends by the private key holder (self signature
malleability) that is in principle kind of fixable.
You make a new pub key type which is r,Q (where r is the DSA signature
component but chosen at key gen time, Q=3DxG is the pub key, r is point
compressed R =3D (r,f(r)) =3D kG ), r is the pre-computable part of an
ECDSA signature (unrelated to the message which can be decided later).
You make a new address type which is a =3D H(r,Q).
Then you make a new signature type which requires that the r from
sig=3D(r,s) matches the r committed to in the address.
As the ECDSA signature is s=3D(H(m)+r*x)/k mod n, if they sign two
different messages with the same r value they reveal the private key
via simultaneous equation, as s=3D(H(m)+r*x)/k and s'=3D(H(m')+r*x)/k and
solving k=3D(H(m)-H(m'))/(s-s') and x=3D(sk-H(m))/r allowing anyone who
sees both double spends to spend as they can replace the signature
with their own one. That converts double signatures into miner can
spend.
It doesnt necessarily enforce no pubkey reuse (Q), as a=3DH(r,Q) and
a'=3DH(r',Q) are different addresses, though it does enforce no
extended-address reuse (H=3D(r,Q)).
Binary failure address reuse could be an issue. Puts pressure on
transactional storage on wallets.
Adam
On 5 November 2015 at 20:36, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, November 05, 2015 3:27:37 PM Jorge Tim=C3=B3n wrote:
>> On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev
>>
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:
>> >> So this is indeed a form of desired malleability we will likely not b=
e
>> >> able to fix. I'd argue that this goes more into the direction of
>> >> double-spending than a form of malleability, and is mostly out of sco=
pe
>> >> for this BIP. As the abstract mentions this BIP attempts to eliminate
>> >> damage incurred by malleability in the third party modification
>> >> scenario and in the multisig scenario, with the added benefit of
>> >> enabling transaction templating. If we can get the segregated witness=
es
>> >> approach working all the better, we don't even have the penalty of
>> >> increased UTXO size. The problem of singlesig users doublespending
>> >> their outputs to update transactions remains a problem even then.
>> >
>> > I don't know what you're trying to say here. Double spending to the sa=
me
>> > destination(s) and malleability are literally the same thing. Things
>> > affected by malleability are still just as broken even with this BIP -
>> > whether it is triggered by a third-party or not is not very relevant.
>>
>> I think this is just a terminology confusion.
>> There's conflicting spends of the same outputs (aka unconfirmed
>> double-spends), and there's signature malleability which Segregated
>> Witnesses solves.
>> If we want to define malleability as signature malleability +
>> conflicting spends, then that's fine.
>> But it seems Christian is mostly interested in signature malleability,
>> which is what SW can solve.
>> In fact, creating conflicting spends is sometimes useful for some
>> contracts (ie to cancel the contract when that's supposed to be
>> allowed).
>> Maybe it is "incorrect" that people use "malleability" when they're
>> specifically talking about "signature malleability", but I think that
>> in this case it's clear that we're talking about transactions having
>> an id that cannot be changed just by signing with a different nonce
>> (what SW provides).
>
> Ok, then my point is that "signature malleability" is not particularly
> problematic or interesting alone, and the only way to get a practically-u=
seful
> solution, is to address all kinds of malleability.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
