Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-09 📝 Original message:> 2) In order to prevent ...
📅 Original date posted:2016-02-09
📝 Original message:> 2) In order to prevent significant blowups in the cost to validate
> [...] and transactions are only allowed to contain
> up to 20 non-segwit inputs. [...]
There is two kind of hard fork, the one who breaks things, and the one who
does not.
Restricting the non-segwit inputs would disrupt lots of services, and
potentially invalidating
hash time locked transactions, which is a very bad precedent.
So I'm strongly against this particular point.
> scriptPubKeys are now limited to 100 bytes in
> size and may not contain OP_CODESEPARATOR, scriptSigs must be push-only
> (ie no non-push opcodes)
Same problem for native multisig, however potentially less important than
the previous point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160209/a04a4478/attachment.html>;
📝 Original message:> 2) In order to prevent significant blowups in the cost to validate
> [...] and transactions are only allowed to contain
> up to 20 non-segwit inputs. [...]
There is two kind of hard fork, the one who breaks things, and the one who
does not.
Restricting the non-segwit inputs would disrupt lots of services, and
potentially invalidating
hash time locked transactions, which is a very bad precedent.
So I'm strongly against this particular point.
> scriptPubKeys are now limited to 100 bytes in
> size and may not contain OP_CODESEPARATOR, scriptSigs must be push-only
> (ie no non-push opcodes)
Same problem for native multisig, however potentially less important than
the previous point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160209/a04a4478/attachment.html>;