Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-22 📝 Original message:> On Sep 22, 2017, at 1:32 ...

📅 Original date posted:2017-09-22
📝 Original message:> On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <sergio.d.lerner at 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’s 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/9800edc4/attachment.html>;