Published on: 2015-07-28T04:22:21+00:00
The soft fork process is experiencing significant changes, leading to a backlog in the system. Prior to these changes, there were already concerns surrounding the process. The version bits BIP, which allows for multiple concurrent soft forks, is still in progress. The BIP66 fork has also highlighted additional issues with the process. Meanwhile, the block size hard fork remains a contentious topic.In an email exchange between Rusty Russell and Joseph Poon, it was mentioned that assuming BIP62 for OP_CSV was satisfactory, but lacked strong motivation. Poon proposed an alternative model without BIP62.Poon further elaborated on the matter in a post, stating that OP_CSV still requires BIP62. However, he suggested that a model could be constructed using OP_CLTV without BIP62. This model would utilize a single-funder approach with an OP_CLTV'd output, which returns the full balance to the original funder at a much later date after all commitments and dependent outputs have expired. Assuming BIP62 does not currently face objections, but having a backup plan in case it proves overly optimistic is considered beneficial.On the Lightning Network mailing list, Russell and Poon discussed the dual-anchor proposal for the network. Russell noted that asymmetric risk should not be a problem with this proposal, as either party could abort the transaction without penalty. Poon agreed, stating that non-cooperation risks are not significant since the channel will be closed out if parties are uncooperative. Russell acknowledged that there may be some unusual economic incentives involved in channel creation, but if both channels are established with the same person, it should be straightforward. They also explored the use of OP_CSV or OP_CLTV for time-locked transactions, highlighting the requirement of BIP62 for OP_CSV. Poon suggested constructing a model using OP_CLTV without BIP62.A statement made by Rusty Russell regarding the time required for a full two-way channel was corrected by go1111111 on a thread found on bitcointalk.org. The correction pointed out that the atomic swap tx could hit the bitcoin blockchain around the same time as the anchor tx.A recent discussion on #lightning-dev highlighted that a single-funder anchor could be accomplished without the need for new sighash ops or outsourcability loss. The other end of the anchor can transfer funds either through the lightning network or via the atomic cross-blockchain idea. The dual-anchor proposal introduces an asymmetric risk, where either side could abort the transaction without penalty and force the other side to wait for the escape timeout. Although incentives for channel creation have not been thoroughly addressed yet, they are connected to routing and currently not entirely clear. When connecting to a hub, it is reasonable to expect the funder to provide the funds.
Updated on: 2023-07-31T18:10:22.268579+00:00