Feed for tag: opcodes
Claiming an OP_RETURN prefix

OP_RETURN code has some interesting, but highly controversial, applications. It’s used to mark a transaction output as invalid, allowing users to burn bitcoin, its also used to add some data to a transaction or store data on the blockchain, which you shouldn’t do.

Some use OP_RETURN prefixes as a way of confirming that they are behind this transaction, using colored coins or storing data.

Recently there were discussions on how to claim these OP prefixes but some members of the community thought it was a bad idea as it would allow censorship and reduce anonymity.

This relates to an old BIP from 2016, but work on this BIP is still in progress.

Lightning Network Fees and Operation Codes

Rusty Russel via bitcoin-dev:

The largest problem we are having today with the lightning protocol is trying to predict future fees. Eltoo solves this elegantly, but meanwhile we would like to include a 546 satoshi OP_TRUE output in commitment transactions so that we use minimal fees and then use CPFP (which can’t be done at the moment due to CSV delays on outputs). Unfortunately, we’d have to P2SH it at the moment as a raw ‘OP_TRUE’ is non-standard. Are there any reasons not to suggest such a policy change?

OP_TRUE is an operation code used in Bitcoin Script. Its function is to push “1” onto the stack, which will later be popped and evaluated in conjunction with standard lightning commitment transactions. Every operation code yields a computational weight because they are all components of a smart contract. Fundamentally, the commitment transactions for Lightning are “hacky”, meaning they take advantage of unusual protocols and combinations of operation codes. The impact of this on the user is an inability to consistently calculate transaction fees.

The last thing lightning users would want would be to close a channel only to see their funds suspended in the memory pool or to close a channel and overpay. While transaction fees can be adjusted following transactions, lightning transactions ought to occur with a degree of precision that circumnavigates a scenario where a user would ever have to adjust an on-chain transaction fees.