Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AC75C9C for ; Sun, 12 Jun 2016 14:40:20 +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 CBFD81C6 for ; Sun, 12 Jun 2016 14:40:19 +0000 (UTC) Received: by mail-lf0-f41.google.com with SMTP id f6so50022819lfg.0 for ; Sun, 12 Jun 2016 07:40:19 -0700 (PDT) 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 :cc; bh=3RFSHgoQCQ1uWMD7QspZY/ODOPDKoS3ItGG1YM4vLrU=; b=tMCaZ3xIywVp+58IYYKLf3jx/RRjhxTKui+xpafKVdTFPQ0XDbeI+kAv31LW3iF45r vM1eCGEUSfSpiFkTfN7aPyGb5icz1W33RgvDkdlYoH8msuIwrDYZ4/gcp8ss7l73asYy BS2L9FAmf++EukSydaAVEvoax3TzjoliA44K8jyLvCbwVtKExn5hyRsMT2Q2YA4U7PhZ zFUtu4+xb0yQWXL6sGXY6WGVRGiszSnTp4Q1i89K/kxpjmQ/1cAVL4X+ga93az9pQ2VV dngNETbV1TEhB0g0H7kKrFhofOePAEq/DcXX9ubgZ4/nDBZu5StEVMhlfnu7hZ9YwAkZ TZGQ== 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; bh=3RFSHgoQCQ1uWMD7QspZY/ODOPDKoS3ItGG1YM4vLrU=; b=JCnkljaeJTxfNLgEHXR2BVtWzSZB8agCRuZ/oMTEkNrSR4t+dGvMpUtm7rzSZTbuua sj9Z/4hWLhYK7dEFuSiyK0ibSffzLxBUHv884MZWFWCwvabwmTB2zAr7vYgDhZM739hV 1oOrNCzK14jnWYwVuDWuMfTvh/SHZrgc0ejzEb5BEBlJvduLTK7Hzju6BifmZFqSCQKS ML/HaxXU3zNlAf6dTngYXI4Pzv2pwOmO/2TaKXNZ1zKPFwZnG/I/kKEg7hXopkUXSjcn Mrl9BJOV2mrQeC+Udu+LLwnz8bWnBjrt2baba1i44KrKQVOuLYtB23EXJlZJVgyGTsd+ xwhg== X-Gm-Message-State: ALyK8tLlaJ2Q8a30Lzp051D1lKHLhRQcC2E1Dm12Bsn08li1i42VJZB0fC4nRY8xbiqJv1EAIfE3cqEdfsgazA== MIME-Version: 1.0 X-Received: by 10.46.0.16 with SMTP id 16mr2748911lja.48.1465742417779; Sun, 12 Jun 2016 07:40:17 -0700 (PDT) Received: by 10.114.172.115 with HTTP; Sun, 12 Jun 2016 07:40:17 -0700 (PDT) Received: by 10.114.172.115 with HTTP; Sun, 12 Jun 2016 07:40:17 -0700 (PDT) In-Reply-To: <201606081645.12598.luke@dashjr.org> References: <201606080729.24789.luke@dashjr.org> <201606081645.12598.luke@dashjr.org> Date: Sun, 12 Jun 2016 16:40:17 +0200 Message-ID: From: Pieter Wuille To: Luke Dash-Jr , Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1142c0aa24e348053515c0db 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 Subject: Re: [bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 14:40:20 -0000 --001a1142c0aa24e348053515c0db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jun 8, 2016 18:46, "Luke Dashjr via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Wednesday, June 08, 2016 8:23:51 AM Johnson Lau wrote: > > If someday 32 bytes hash is deemed to be unsafe, the txid would also be > > unsafe and a hard fork might be needed. Therefore, I don=E2=80=99t see = how a > > witness program larger than 40 bytes would be useful in any case (as it is > > more expensive and takes more UTXO space). I think Pieter doesn=E2=80= =99t want to > > make it unnecessarily lenient. > > There is no harm in being lenient, but it limits the ability to do softfork > upgrades in the future. I appreciate Pieter's concern that we'd need to d= o > more development and testing to go to this extreme, which is why I am onl= y > asking the limit raised to 75 bytes. No strong opinion, but I'd rather not change it anymore, as I don't see the point. Any data you would want to encode there can be moved to the witness at 1/4 the cost and replaced by a 256-bit hash. If the data is 43 bytes or higher, that is even cheaper. The only thing that cannot be in the hash is metadata to indicate what hashing/rule scheme itself is used. I think 68 bits (OP_n + 8 bytes) for that is plenty. --=20 Pieter --001a1142c0aa24e348053515c0db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jun 8, 2016 18:46, "Luke Dashjr via bitcoin-dev"= ; <bitcoin-dev@= lists.linuxfoundation.org> wrote:
>
> On Wednesday, June 08, 2016 8:23:51 AM Johnson Lau wrote:
> > If someday 32 bytes hash is deemed to be unsafe, the txid would a= lso be
> > unsafe and a hard fork might be needed. Therefore, I don=E2=80=99= t see how a
> > witness program larger than 40 bytes would be useful in any case = (as it is
> > more expensive and takes more UTXO space). I think Pieter doesn= =E2=80=99t want to
> > make it unnecessarily lenient.
>
> There is no harm in being lenient, but it limits the ability to do sof= tfork
> upgrades in the future. I appreciate Pieter's concern that we'= d need to do
> more development and testing to go to this extreme, which is why I am = only
> asking the limit raised to 75 bytes.

No strong opinion, but I'd rather not change it anymore,= as I don't see the point. Any data you would want to encode there can = be moved to the witness at 1/4 the cost and replaced by a 256-bit hash. If = the data is 43 bytes or higher, that is even cheaper. The only thing that c= annot be in the hash is metadata to indicate what hashing/rule scheme itsel= f is used. I think 68 bits (OP_n + 8 bytes) for that is plenty.

--
Pieter

--001a1142c0aa24e348053515c0db--