rich1.0npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fhttps://nostr.ae/npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fnjumphttps://nostr.ae📅 Original date posted:2017-09-22 📝 Original message: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 <mark at friedenbach.org> wrote: > > 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/87c83dee/attachment.html>