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 <m...@friedenbach.org> wrote: > > On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner < > sergio.d.ler...@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. > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
