Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: Mark Friedenbach <mark@friedenbach•org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)
Date: Fri, 22 Sep 2017 17:32:56 -0300	[thread overview]
Message-ID: <CAKzdR-phAarTY16BOnC95BPN0qMNEE_XZ9H-XmFeeaBc2V1U5w@mail.gmail.com> (raw)
In-Reply-To: <CAA2B000-6C54-4AD7-B931-43C99D615A61@friedenbach.org>

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

>
> 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.

> Arguably for a future script version upgrade one of these other
> approaches should be taken to allow for shorter tail-call scripts.
>
> Mark
>
> * Well, almost any. You could end the script with DEPTH EQUAL and that
>   is a compact way of ensuring the stack is clean (assuming the script
>   finished with just "true" on the stack). Nobody does this however
>   and burning two witness bytes of every redeem script going forward
>   as a protective measure seems like an unnecessary ask.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2667 bytes --]