lightning-dev
Combined summary - Anchor transaction for no expiration channels without segwit
The email conversation between Christopher Jämthagen, Nicolas Dorier, and Tier Nolan discusses the possibility of creating anchor transactions for indefinite channel lifetimes without segwit.
The proposed solution involves two transactions to be confirmed but with indefinite channel lifetime or one transaction to be confirmed with a definite channel lifetime. There is still uncertainty about which option would be best from the user perspective as channel renewal can be done in the background.Two-layer HTLCs need malleability fixes or workarounds to avoid excessive timeouts. Additionally, symmetrically funded channels require four 1BTC outputs and are slightly smaller than two single-funded channels. The proposal includes TX1 for initialization of the channel and TX2 to be nTimelocked after the bounty's expiration. The two should be signed by Alice and Bob before broadcasting TX1. If TX1 is mutated, both parties should abort and spend their timeouts to recover their funds.Nicolas Dorier suggests that using nLocktime for TX2 is almost costless and prevents fast initial channel close. Once an unchanged version of TX1 is in the blockchain, all further updates of the channel can exclude the nLocktime. The bounty is set up so that Alice can unlock it once the channel is established as a courtesy.In a recent email exchange, Nicolas Dorier proposed an alternative method for transaction locking to create symmetrically funded channels. The proposed method involves using nTimelock after the bounty's expiration, which would keep the transaction smaller. A symmetrically funded channel requires four 1BTC outputs, making it essentially two single funded channels.The discussion revolves around a proposed solution that utilizes Segwit to establish a symmetrically funded channel between Alice and Bob, without the need for third-party channel monitoring. Tier Nolan suggests a simpler way to implement this, through nTimelock after the bounty's expiration.The proposed symmetrically funded channel requires four 1BTC outputs, which are essentially two single-funded channels. The transaction creates an output paying Alice and Bob 1BTC each. Alice and Bob create TX1, sign it, and share the results. They also create TX2, sign it, and share the results. If one signs the transactions, and the other doesn't, then the signer should spend their inputs to be safe. If TX1 is broadcast, then they can both spend their timeouts to recover their funds, making it safe. Once they both have signed versions of TX1 and TX2, they will broadcast TX1 to initialize the channel.The discussion revolves around a proposal to create a time-locked transaction. The proposed solution is for TX2 to be nTimelocked after the bounty's expiration. If Alice sees Bob not signing it, she can reclaim the bounty fast. If Bob signs it, Alice cannot broadcast it immediately.According to the given context, it seems that someone is suggesting that there is no need for a second timeout. The reason behind this statement is that TX2 can only be signed by Bob once he receives the second output of TX1. Therefore, Bob does not have to worry about Alice closing the channel with TX2.In a recent email exchange, Nicolas Dorier suggested an alternative method for transaction locking to create symmetrically funded channels. The proposed method involves using nTimelock after the bounty's expiration, which would keep the transaction smaller. A symmetrically funded channel requires four 1BTC outputs, making it essentially two single funded channels.Alice and Bob are opening a channel with 1BTC each. The output would be either 1BTC from Alice and Bob, or 1BTC from Bob with a timeout. If Bob is unresponsive, Alice can claim the entire bounty. Similarly, if Alice is unresponsive, Bob can claim the bounty after the timeout. However, if Alice claims the bounty, Bob can take over the escrow.Overall, the discussion revolves around finding solutions for creating anchor transactions and symmetrically funded channels with indefinite channel lifetimes without segwit. The proposed methods involve using nLocktime or nTimelock after the bounty's expiration to prevent fast initial channel close. The conversations also touch upon the need for signed versions of TX1 and TX2, as well as safe aborts and recovery of funds in case of mutations or unresponsiveness.