Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-22 📝 Original message:Rather than re-enable ...
📅 Original date posted:2015-07-22
📝 Original message:Rather than re-enable OP_LEFT, a NOP could be re-purposed in a soft fork.
OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]] [LEN_PARAM] OP_LEFTEQUALVERIFY
OP_DROP OP_CHECKSIG
A B L OP_LEFTEQUALVERIFY checks if the leftmost L bytes of A and B match.
If not, then the script immediately fails. If either array is less than L
bytes or if there are fewer than 3 values on the stack, then it also fails.
The OP_DROP is needed as the new opcode must count as a NOP for legacy
nodes.
A change like this would only cause a once-off improvement in efficiency,
so it is less likely to be worth the effort.
It also requires most clients to be updated to support the new address
system.
A different BIP could be added for that.
An alternative way to add new opcodes is to use a different script engine
like with P2SH.
On Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> While we're all debating the block size, please review this proposal to
> modestly increase the number of transactions per block.
>
> https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63
>
> Best,
>
> Jeremy
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/f9295b82/attachment.html>
📝 Original message:Rather than re-enable OP_LEFT, a NOP could be re-purposed in a soft fork.
OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]] [LEN_PARAM] OP_LEFTEQUALVERIFY
OP_DROP OP_CHECKSIG
A B L OP_LEFTEQUALVERIFY checks if the leftmost L bytes of A and B match.
If not, then the script immediately fails. If either array is less than L
bytes or if there are fewer than 3 values on the stack, then it also fails.
The OP_DROP is needed as the new opcode must count as a NOP for legacy
nodes.
A change like this would only cause a once-off improvement in efficiency,
so it is less likely to be worth the effort.
It also requires most clients to be updated to support the new address
system.
A different BIP could be added for that.
An alternative way to add new opcodes is to use a different script engine
like with P2SH.
On Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> While we're all debating the block size, please review this proposal to
> modestly increase the number of transactions per block.
>
> https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63
>
> Best,
>
> Jeremy
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/f9295b82/attachment.html>