Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0E7E3AA6 for ; Fri, 22 Sep 2017 21:11:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com [74.125.83.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AE000203 for ; Fri, 22 Sep 2017 21:11:05 +0000 (UTC) Received: by mail-pg0-f52.google.com with SMTP id k193so1198824pgc.8 for ; Fri, 22 Sep 2017 14:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OLnG16h4ScdhK7S0kv2OhgBnyU2sx3lqvjyp7P91GoQ=; b=BtJGhtbvQUzHGFtBNacIixhJDgj363Cv2j7nhPoQPhk4fmkDeU0EilJmiRPVf/T2Nv MWRrYGURj0DeXqRyITcW3DKKV6l92QJ3k5YRy011P9ZzP2T3aw46OmWNRN6cI2GnhKtp WDpyTQ1rEojYRbYdejQdtUT1ewbxNGhekl0KO4Z6Ny5hAPDf+bXTVE9bP8IOBRS7bqtE GUPtn1q5pHnTvlJDJU8lmWaLhQvlLQvt/lYECkW8npiJREPID0fKHsPNRjTHGeRy23XG pUdxDT4AQL4bk9x6E1DbuUqxdEtLvL/+3E5CbF6UfAwuggCY0vNOffAQHpq8osb5CJqm JQsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OLnG16h4ScdhK7S0kv2OhgBnyU2sx3lqvjyp7P91GoQ=; b=OUyKRcg/s3FtOH/R5clLVl4waTttz7+ecEJP7N4pqwygi/OGzxgWTn5V5HrSeaFVPT rgVAR/Vi/NfAfDYtMB3wuAEpfvFep1Li9ZySqWUuZDh7FaFHAGvj10NvB5CG5mnPiJ+x kJftTbiTJRHvmjX/IN/f7h6O6iZy3JJs0wljOrTx/ajGfMhPRQP5adUmH40qY+8dgjl3 sWv9cM1MtMmlyyL1PO9IWa+nU5YxHfUm6FemHZ9AHlZ8mElJHK5RlKzmYOobH/XoDEkO nfQsecWP7mu3xKuzzW5Pw3wCKAdGpWy2CsP+DlL0SO2TSfHKoS4/A2THFLVSR2kmBagd xxAQ== X-Gm-Message-State: AHPjjUim6TvioxFjTQZrTJ8j8zPGMb+eBbd97J4SIJmiZKIU56j3VQ8W WDjjvdzXgk3fTRn9qEkfpPi8nw== X-Google-Smtp-Source: AOwi7QDImEyXHYBTGB+9KncxPDMV4ZCLPwtjofUc/wnJM1L8wREvb437ejTaZt5Uwk5dz2NuyQoWJw== X-Received: by 10.98.236.150 with SMTP id e22mr352782pfm.203.1506114665332; Fri, 22 Sep 2017 14:11:05 -0700 (PDT) Received: from ?IPv6:2601:640:102:9b01:b813:d9f9:2ea:bb39? ([2601:640:102:9b01:b813:d9f9:2ea:bb39]) by smtp.gmail.com with ESMTPSA id f74sm844050pfa.36.2017.09.22.14.11.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 14:11:04 -0700 (PDT) From: Mark Friedenbach Message-Id: <3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_B15E0862-A6D4-4BA1-9E1A-F403AB94707E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 22 Sep 2017 14:11:03 -0700 In-Reply-To: To: Sergio Demian Lerner References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> <201709190309.08669.luke@dashjr.org> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM 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:13:27 +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:11:07 -0000 --Apple-Mail=_B15E0862-A6D4-4BA1-9E1A-F403AB94707E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner = wrote: >=20 >=20 >=20 > 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.=20 >=20 > 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 = stack size. >=20 > 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. >=20 > For transactions with locktime >0, we could soft-fork so transactions = add a last zero-satoshi output whose scriptPub contains OP_RETURN and = followed by N VarInts, containing the maximum stack size of each input.=20= > 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. --Apple-Mail=_B15E0862-A6D4-4BA1-9E1A-F403AB94707E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 = 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 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 followed 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 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.

= --Apple-Mail=_B15E0862-A6D4-4BA1-9E1A-F403AB94707E--