Published on: 2018-10-13T11:40:30+00:00
On October 13, 2018, Christian Decker proposed an adaptive scheme for update transactions in the Lightning specification. The scheme starts with a single transaction and adds a second at around 90% of the available range. This method creates a larger overall counter, providing a single counter with 10^18 possible updates.In contrast, ZmnSCPxj suggested always having two update transactions, which would create a single counter with 10^18 possible updates. Anthony Towns proposed that if you have more than 1 billion updates to your channel, you could reset the locktime by rolling over to use new update keys. This method would save a transaction if you did a cooperative close.The Lightning Network specification uses a penalty-based invalidation mechanism, but eltoo is a drop-in replacement for this. One issue with eltoo's locktime-based sequencing is that it limits the number of updates to 1 billion. However, ZmnSCPxj suggests an adaptive scheme in which a second update transaction is added at around 90% of the available range; this effectively creates a larger overall counter with 10^18 possible updates.Alternatively, Anthony Towns suggests always having two update transactions, creating a single counter with 10^18 possible updates, and rolling over to new update keys after using more than 1 billion updates on a channel. This would make unilateral closes more painful, but keep cooperative closes cheap. Christian Decker notes that he did not think 1 billion updates would be used anytime soon since splice-in/splice-out operations would lead to regular on-chain re-anchoring.In a discussion about the Lightning specification, it was suggested to use a larger overall counter for updates by always having two update transactions and incrementing highbits when lobits saturates. This creates a single counter with 10^18 possible updates. This method is useful for channels that require more than 1 billion updates as resetting the locktime by rolling over to new update keys can be done. This would save a transaction if a cooperative close is done rather than an unilaterally close. Rolling over to new update keys requires an extra transaction on-chain. The suggestion for this method came from Anthony Towns.In a discussion about the eltoo Lightning Network specification, Anthony Towns suggests using new update keys to reset the locktime and state numbers when there are more than 1 billion updates to a channel. Christian Decker had originally believed that this number of updates was unlikely, but Towns explains that it could be possible with regular on-chain operations. To implement this, one would need to use an extra transaction on-chain to roll-over to the new update keys when unilaterally closing, but cooperative closes would remain cheap. This process could be repeated every time another 1 billion updates occur. The eltoo specification is a drop-in replacement for the penalty-based invalidation mechanism currently used in the Lightning Network.Christian Decker proposed a drop-in replacement called 'eltoo' for the penalty-based invalidation mechanism currently used in the Lightning specification. The locktime-based sequencing in eltoo interprets any number above 0.500 billion as a UNIX timestamp, leaving about 1 billion numbers that are interpreted as being in the past with the current timestamp of ~1.5 billion. In response to this, AJ suggested that if there were more than 1B updates to a channel, one could reset the locktime by rolling over to use new update keys. Unilateral closes will need an extra on-chain transaction to roll-over, but cooperative closes can save a transaction. Repeat the process after another 1B updates making unilateral closes more painful while keeping cooperative closes cheap.In a recent discussion on bitcoin-dev mailing list, Bitcoin Core developer AJ Towns proposed eltoo as a drop-in replacement for the penalty-based invalidation mechanism used in the Lightning Network specification. He suggested that the eltoo protocol could be further simplified to have a simpler ratchet mechanism and proposed a new transaction scheme that would replace "funding transaction spending to address 'X', and a set of ratcheting states that spend from-and-to the same address 'X'". This transaction scheme has several features such as txes at (3a) and (3b) can both pay current market fees with minimal risk and can be CPFPed by a tx spending your own channel balance, both parties can claim their funds as soon as the other can, no matter who initiates the close, and more. However, the scheme isn't great for untrusted outsourcing and requires NOINPUT to function properly. Despite these limitations, AJ thinks that eltoo works nicely.In a post to the lightning-dev mailing list, David A. Harding shared his thoughts on several potential denial-of-service (DoS) attacks against Lightning Network settlements with regards to issues with relative locktime and SIGHASH_NOINPUT.
Updated on: 2023-07-31T20:05:29.778894+00:00