Lightning Network Fees and Operation Codes
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.
Support us and the authors of this article by donating to the following address:35jeGBHweQTbT5c1s2iRKSw1WCre2GPuaX