From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 70919A3F for ; Mon, 11 Jan 2016 20:32:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8FEF11D for ; Mon, 11 Jan 2016 20:32:16 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id a123so200508257vkh.1 for ; Mon, 11 Jan 2016 12:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KwGz82R+5VulomWKHvYmZthYgbPlh+H7hwG1ktvkbBY=; b=p1pFmg23dwHnCHhGLc20gj1pLxw1hw3Eg2TblkSV6+GEzEdbIV1f4Z2rRQaRdDkwZM yW2bLAyrQZ7sLgk1S/uGs+UAB03IjQ9JWXv1GhiWB/qcRalYe6xrExgWHe9cxtb3morM S5VMHNgsegjG1Yf+57I9xaPjil5UL/rITm6VZXVoZpkDvJpsBL/26XCzbuEP3uGm8Js9 6U5K81qcy/qVeZd2l/ZoE2KfbWKNhFiyrmeVLpFvUWGoQK1WhVCefmn+FFnZbL13M2Ao Ew5oP/+MEmIZJvWgFWeOGQReIMiPHfRauTljmHwSwzi2KhVSuCn2y8nLqmzcjgp7HZ1k v7aA== 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:date :message-id:subject:from:to:cc:content-type; bh=KwGz82R+5VulomWKHvYmZthYgbPlh+H7hwG1ktvkbBY=; b=ghc/YzJZCdoyb0NLs8VHEWICusKIPsvsW0Bq9N74/qF6vNvc7RnI5F7oc24FIBqlcH tFZYb2x6G+ruVDQobt2NTbZx1xoUW/dRpHNFisW7xFCfBCftljF/NgTd4Kkeiudyd+Ja bfM/QoazRnCyWLfVyijY9VTvqskyMwNzLc85HXED0LhFxe7llhF5s6+s8w9NyRhuSHcG cVvWNyKaMa88Ugzx/kvelvJq3UCqISOIIhd7et5SA1fKXsIf16gPds6IUYE/dMgN0ixJ Nim72eID0o00jHzynoRHgk7n61nLNZsQf+B4FbnCtC4VaJ5yUo5L/i3wEBYn7Z8bkN64 bR1g== X-Gm-Message-State: ALoCoQlHp13gztQWxCKbGOlurGualfB4btpLga62Gj6JwaIy5OrI/AWzG9R2lCtKv61ZlcvOvETI5A54j+i5Q6YVvA+UtpN0dQ== MIME-Version: 1.0 X-Received: by 10.31.154.213 with SMTP id c204mr91035348vke.38.1452544335926; Mon, 11 Jan 2016 12:32:15 -0800 (PST) Received: by 10.31.141.73 with HTTP; Mon, 11 Jan 2016 12:32:15 -0800 (PST) In-Reply-To: References: <8760z4rbng.fsf@rustcorp.com.au> <8737u8qnye.fsf@rustcorp.com.au> <20160108153329.GA15731@sapphire.erisian.com.au> Date: Mon, 11 Jan 2016 21:32:15 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 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: Mon, 11 Jan 2016 20:32:17 -0000 On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev wrote: > And to fend off the messag that I bet somebody is composing right now: > > Yes, I know about a "security first" mindset. But as I said earlier in the > thread, there is a tradeoff here between crypto strength and code > complexity, and "the strength of the crypto is all that matters" is NOT > security first. If the crypto code is properly encapsulated, the code complexity costs of choosing one hashing function over another should be non-existent. You made the space argument which is valid, but in my opinion code complexity shouldn't be a valid concern in this discussion. As a maybe uninteresting anecdote, I proposed the asset IDs in https://github.com/ElementsProject/elements/tree/alpha-0.10-multi-asset to do the same ```ripemd160 . sha256``` choice that Mark Friedenbach had proposed and I had approved for https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#asset-tags . More humble than me, he admitted he had made a design mistake much earlier than me, who (maybe paradoxically) probably had less knowledge for making crypto choices at the low level. In the end I was convinced with examples I failed to write down for documentation and can't remember. That's not to say I have anything to say in this debate other than code complexity (which I do feel qualified to talk about) shouldn't be a concern in this debate. Just want to focus the discussion on what it should be: security vs space tradeoff. Since I am admittedly in doubt, I tend to prefer to play safe, but neither my feelings nor my anecdote are logical arguments and should, therefore, be ignored for any conclusions in the ```ripemd160 . sha256``` vs sha256d debate. Just like you non-sequitor "sha256d will lead to more code complexity", if anything, sha256d should be simpler than ```ripemd160 . sha256``` (but not simpler enough that it matters much).