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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Time to worry about 80-bit collision attacks
	or	not?
Precedence: list

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.