Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 31957B66 for ; Fri, 22 Sep 2017 21:32:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E4E8421 for ; Fri, 22 Sep 2017 21:32:41 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id 199so299189oii.11 for ; Fri, 22 Sep 2017 14:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TMQ9vKaSWj34ynuVTLZvqZLoU5R1MtMhXFEhGzgIbNE=; b=UxUbsYYDVaQUYBKlGbEktm3YVvTG7CfYfznkbG2IO4loCvvOq6jDavWXs3F/Ylk5HP nZ8ZfJrLaRN8AAVqPDqnaJxg80Pe05OVqprxjblv+0e1oZqVJBRa9TmxQDlkAvgRWvZO qTV75bytQ2u66ayFMWgulkXYhXJ47+n87RsfRXqf/mi1NyqeiG+1rOA9xCurzC6Cf9dx VaYYOOgwlf1n2gZ8PKyvYtJ09uEhU/rawc89By/AoK1F/NJ6zfyeuWL7zDjAq2bWa+b8 4obZJ5AL6JT7ZRRhEwVlkshkQLYAwGLtcCVMVwaT/gDd3rxVH26Pmhnjd+1DyDiuU7a/ B1mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TMQ9vKaSWj34ynuVTLZvqZLoU5R1MtMhXFEhGzgIbNE=; b=mcold9ysGGUIhIjc2LHSTCTY1+ftYb0XQ+t4A7acPsn0gBdsPLQfxDCFdvNt8HN3WT ulSHywTSSsZys3CSHUdSfFXD/H8QNnVugI8wgnfONqYKa2vm/mp0ajU6PR12Xwm1clRV VbWCItfPmpvLuHV7tNvXszgv5eFZxHXbDylA02hypiyu3KWKd7bxKf1D0pCJ+XVn4ks7 YE1BI5vUe+U9qJu8D3+1Kqmxgeid7aEcU/4kLeJflN5hfSM8c+07hrm6YeY+Ls0KDO5b n13KY1vIPCx1MCWUwaJ2lNwkyxCMKStuUW/5GPZA3nb05cchbsMW7ad6uHaIVwkilISe aEOA== X-Gm-Message-State: AHPjjUgg1R+qKWnbQTZv8ewyN4tu9IOgW2KO76o8E7i0XQ6GFh4zphNf S270rMDY20GQ6aETi9HnMSsJKio6VzNj2phJz1U= X-Google-Smtp-Source: AOwi7QC+JsdxuK3FgxsU0k5J7bM55vTGkIE3fGqOv1oW8InzQdsQB1EvjorEyGaeOQTPS0TSv8NlNRQ9j5kiREWa5JU= X-Received: by 10.202.178.133 with SMTP id b127mr622500oif.319.1506115961005; Fri, 22 Sep 2017 14:32:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.85.72 with HTTP; Fri, 22 Sep 2017 14:32:00 -0700 (PDT) In-Reply-To: <3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org> References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> <201709190309.08669.luke@dashjr.org> <3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org> From: Sergio Demian Lerner Date: Fri, 22 Sep 2017 18:32:00 -0300 Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary="001a113b5e32d8b4f50559cdf24c" X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=disabled 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, 22 Sep 2017 21:37:15 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) 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: Fri, 22 Sep 2017 21:32:42 -0000 --001a113b5e32d8b4f50559cdf24c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But generally before one signs a transaction one does not know the signature size (which may be variable). One can only estimate the maximum size. On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach wrote: > > On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner < > sergio.d.lerner@gmail.com> wrote: > > >> >> There are other solutions to this problem that could have been taken >> instead, such as committing to the number of items or maximum size of >> the stack as part of the sighash data, but cleanstack was the approach >> taken. > > > The lack of signed maximum segwit stack size was one of the objections to > segwit I presented last year. This together with the unlimited segwit sta= ck > size. > > However, committing to the maximum stack size (in bytes) for an input is > tricky. The only place where this could be packed is in sequence_no, with= a > soft-fork. E.g. when transaction version is 2 and and only when lock_time > is zero. > > For transactions with locktime >0, we could soft-fork so transactions add > a last zero-satoshi output whose scriptPub contains OP_RETURN and followe= d > by N VarInts, containing the maximum stack size of each input. > Normally, for a 400 byte, 2-input transaction, this will add 11 bytes, or > a 2.5% overhead. > > > There=E2=80=99s no need to put it in the transaction itself. You put it i= n the > witness and it is either committed to as part of the witness (in which ca= se > it has to hold for all possible spend paths), or at spend time by includi= ng > it in the data signed by CHECKSIG. > > --001a113b5e32d8b4f50559cdf24c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But generally before one signs a transaction one does not = know the signature size (which may be variable). One can only estimate the = maximum size.=C2=A0

On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach <mark@frieden= bach.org> wrote:

On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <sergio.d.lerner@gmail.c= om> wrote:



There are other solutions to this problem that could have been take= n
instead, such as committing to the number of items or maximum size of<= br>the stack as part of the sighash data, but cleanstack was the approachtaken.=C2=A0<= /span>

The lack of signed=C2=A0maximum segwit stack s= ize was one of the objections to segwit I presented last year. This togethe= r with the unlimited segwit stack size.

However, committing = to the maximum stack size (in bytes) for an input is tricky. The only place= where this could be packed is in=C2=A0sequence_no, with a soft-fork. E.g. = when transaction version is 2 and and only when lock_time is zero.

For transac= tions with locktime >0, we could soft-fork so transactions add a last ze= ro-satoshi output whose scriptPub contains OP_RETURN and followed by N VarI= nts, containing the maximum stack size of each input.=C2=A0
Normally, for a 400 byte, 2-input transaction, this will= add 11 bytes, or a 2.5% overhead.

There=E2=80=99s no need to put it in the transaction itself. You put= it in the witness and it is either committed to as part of the witness (in= which case it has to hold for all possible spend paths), or at spend time = by including it in the data signed by CHECKSIG.


--001a113b5e32d8b4f50559cdf24c--