Published on: 2015-08-19T11:03:07+00:00
In an email conversation between Rusty Russell and Btc Drak, the deployment of OP_CSV was discussed as a means of avoiding hacks. Btc Drak requested interested parties to review the OP_CSV BIP, pull request, and related BIP68 PR. Additionally, there was mention of a feature-pack softfork that includes CLTV+CSV+BIP68+median_past_timelock as a single softfork. The "median-past-locktime" pull requests were also made available for review and have direct relevance to Lightning as part of the locktime featureset referenced above.Rusty Russell sent an email expressing his hope that OP_CSV gets deployed soon to avoid future hacks. He requested those interested in the topic to review the OP_CSV BIP, pull request, and related BIP68 PR. He mentioned that a BIP proposal for median-past-timelock would be presented shortly and would need review. There is growing support for a feature-pack softfork which includes CLTV+CSV+BIP68+median_past_timelock as a single softfork. Drak encouraged thoughts about this deployment option to establish consensus on how to move forward.In a separate discussion, Mats Jerratsch and Joseph discussed implementing changes to the Thunder proposal. Joseph asked about the impact of OP_CLTV on the proposal. After analysis, Mats found that replacing CSV with CLTV is possible but has downsides such as longer waiting periods if something goes wrong during channel negotiation and problems with reopening channels regularly. Mats hopes that OP_CSV will be deployed soon to avoid complications, but acknowledges that there is still work to be done.Mats and Joseph also discuss the possibility of using OP_CLTV without OP_CSV as a mandatory minimum for a full Lightning Network. Joseph mentions previous discussions on the mailing list with caveats on the risks and effects of doing so. Mats works out how much is possible with only CLTV implemented and believes minor changes to the code would result in full lightning channels. Joseph agrees and believes there will be huge benefits to Bitcoin if bitcoinj has an implementation ready when OP_CLTV/OP_CSV is implemented.The author of the Thunder proposal discusses integrating OP_CLTV and CSV into the channel design to mitigate malleability problems. Refund transactions are no longer necessary as the refund can be part of the opening transaction, eliminating risk problems and allowing for large amounts of funds within the channel. A new version of the channel is agreed upon when both parties release their temporary signatures A2 and B2, with malleability no longer an issue. Sending and receiving payments now consists of three outputs, combining the mechanism for refunds and revocable transactions with the ability of the receiver to claim payments if they know the secret R. However, there are issues with HTLCs not being strictly revocable, which can be resolved using a simple reserve strategy. The implementation of these changes in the current Thunder implementations involves deleting many necessary methods and switching to new scripts. There is a problem with settlement transactions not being time-encumbered, which means one party can claim the payment under any circumstances. It is important to track the amounts the other party is receiving to ensure their balance does not drop below a certain amount, serving as an incentive to clear out receiving payments promptly.
Updated on: 2023-07-31T18:13:44.500674+00:00