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 EF5D1B12 for ; Fri, 8 Jan 2016 15:59:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4254317A for ; Fri, 8 Jan 2016 15:59:23 +0000 (UTC) Received: by mail-lf0-f41.google.com with SMTP id i124so10005336lfe.3 for ; Fri, 08 Jan 2016 07:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=A8L55NaunIsTWrQKjW72EX7PH985jOGwsfxrwmJgL78=; b=WfIAVW2DHlrrAA1HJfUS3QFiueHUMUbZihIfAaiN8IBytldfVGCuFhJMCeglRCZgds t+fW8aigrNPEJkeJhOJPxfi2aMCiU1SzhXzY0jEAqhp2PzdXYVvvFxHeHKFwX9gg5rVQ f7amHm+NPpgGaULf+zXcP9br8rHWtIrMZ4T5aHaoi2GeczSv+f/IymVLPdYVW+tWe62p 57hoTETzHGCUc/Wtctnges3UqvZ3/SQTbTKT9Yk2bMjAgVPJw2EbwF5eTHYcmscR0ISC IQfnltB1Bmmtz5ENnNFairzFmt0V3qAcABsHTaK3woChDo8eFfTNAfKNX598BGowyo8k z0Ew== MIME-Version: 1.0 X-Received: by 10.25.213.134 with SMTP id m128mr37286860lfg.87.1452268761795; Fri, 08 Jan 2016 07:59:21 -0800 (PST) Received: by 10.25.25.78 with HTTP; Fri, 8 Jan 2016 07:59:21 -0800 (PST) In-Reply-To: References: <8760z4rbng.fsf@rustcorp.com.au> <8737u8qnye.fsf@rustcorp.com.au> <20160108153329.GA15731@sapphire.erisian.com.au> Date: Fri, 8 Jan 2016 10:59:21 -0500 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11420fbaaa59250528d4ab0f X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 X-Mailman-Approved-At: Fri, 08 Jan 2016 17:40:50 +0000 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 15:59:24 -0000 --001a11420fbaaa59250528d4ab0f Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 10:50 AM, Gavin Andresen wrote: > 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. I should be more explicit about code complexity: The big picture is "segwitness will help scale in the very short term." So the spec gives two ways of stuffing the segwitness hash into the scriptPubKey -- one way that uses a 32-bit hash, but if used would actually make scalability a bit worse as coins moved into segwitness-locked transactions (DUP HASH160 EQUALVERIFY pay-to-script-hash scriptpubkeys are just 24 bytes). And another way that add just one byte to the scriptpubkey. THAT is the code complexity I'm talking about. Better to always move the script into the witness data, in my opinion, on the keep the design as simple as possible principle. It could be a 32-byte hash... but then the short-term scalability goal is compromised. Maybe I'm being dense, but I still think it is a no-brainer.... -- -- Gavin Andresen --001a11420fbaaa59250528d4ab0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 8, 2016 at 10:50 AM, Gavin Andresen <gavinandresen@gmail.c= om> wrote:
But as I said ea= rlier in the thread, there is a tradeoff here between crypto strength and c= ode complexity, and "the strength of the crypto is all that matters&qu= ot; is NOT security first.

I should be more explicit = about code complexity:

The big picture is "segwitness will help scale in the= very short term."

So the spec gives two ways of stuffing the segwitness has= h into the scriptPubKey -- one way that uses a 32-bit hash, but if used wou= ld actually make scalability a bit worse as coins moved into segwitness-loc= ked transactions (DUP HASH160 EQUALVERIFY pay-to-script-hash scriptpubkeys = are just 24 bytes).

And another way that add just one byte to the scriptpubkey.

THAT is= the code complexity I'm talking about.=C2=A0 Better to always move the= script into the witness data, in my opinion, on the keep the design as sim= ple as possible principle.

It could be a 32-byte hash... but then the short-term = scalability goal is compromised.

Maybe I'm being dense, but I st= ill think it is a no-brainer....

--
--
Gavin Andresen
--001a11420fbaaa59250528d4ab0f--