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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D05ADF01
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 03:30:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [103.22.144.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22A78F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 03:30:28 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 427ED1402DE; Fri, 8 Jan 2016 14:30:25 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Gavin Andresen <gavinandresen@gmail.com>
In-Reply-To: <CAPg+sBhH0MODjjp8Avx+Fy_UGqzMjUq_jn3vT3oH=u3711tsSA@mail.gmail.com>
References: <CABsx9T3aTme2EQATamGGzeqNqJkUcPGa=0LVidJSRYNznM-myQ@mail.gmail.com>
<CAPg+sBhH0MODjjp8Avx+Fy_UGqzMjUq_jn3vT3oH=u3711tsSA@mail.gmail.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1
(x86_64-pc-linux-gnu)
Date: Fri, 08 Jan 2016 14:00:11 +1030
Message-ID: <8760z4rbng.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
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
X-Mailman-Approved-At: Fri, 08 Jan 2016 03:31:24 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Time to worry about 80-bit collision attacks
or not?
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: Fri, 08 Jan 2016 03:30:28 -0000
Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> Yes, this is what I worry about. We're constructing a 2-of-2 multisig
> escrow in a contract. I reveal my public key A, you do a 80-bit search for
> B and C such that H(A and B) = H(B and C). You tell me your keys B, and I
> happily send to H(A and B), which you steal with H(B and C).
FWIW, this attack would effect the current lightning-network "deployable
lightning" design at channel establishment; we reveal our pubkey in the
opening packet (which is used to redeem a P2SH using normal 2of2).
At least you need to grind before replying (which will presumably time
out), rather than being able to do it once the channel is open.
We could pre-commit by exchanging hashes of pubkeys first, but contracts
on bitcoin are hard enough to get right that I'm reluctant to add more
hoops.
Cheers,
Rusty.
|
