What is Nostr?
Tier Nolan [ARCHIVE] /
npub1g6v…l5wd
2023-06-07 15:43:14
in reply to nevent1q…npuw

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>;
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd