Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AF9C4F95 for ; Fri, 8 Jan 2016 03:41:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 59B4D11A for ; Fri, 8 Jan 2016 03:41:39 +0000 (UTC) Received: from [IPv6:2607:fb90:424:b1a8:da3e:79f4:c5b9:ded6] (unknown [172.56.39.98]) by mail.bluematt.me (Postfix) with ESMTPSA id 560925AF08; Fri, 8 Jan 2016 03:41:37 +0000 (UTC) In-Reply-To: <8760z4rbng.fsf@rustcorp.com.au> References: <8760z4rbng.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Matt Corallo Date: Fri, 08 Jan 2016 03:41:34 +0000 To: Rusty Russell , Rusty Russell via bitcoin-dev , Pieter Wuille , Gavin Andresen Message-ID: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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 05:54:09 +0000 Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 03:41:39 -0000 Indeed, anything which uses P2SH is obviously vulnerable if there is an attack on RIPEMD160 which reduces it's security only marginally. While no one thought hard about these attacks when P2SH was designed, we realized later this was not such a good idea to reuse the structure from P2PKH. Hence why this discussion came up. On January 7, 2016 7:30:11 PM PST, Rusty Russell via bitcoin-dev wrote: >Pieter Wuille via bitcoin-dev >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. >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev