[Question] Unilateral closing during fee increase. [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2018-01-16T23:47:04+00:00


Summary:

In a mailing list post, Johan discusses the problem of a mainnet channel force closed two weeks ago that has not been mined yet. While there may not be a current solution, he suggests that future specifications could include a SIGHASH flag magic to allow for an extra input that could go towards fees or add both a new input and output where the difference goes to fees. To maintain the TXID, one potential solution would be to always add a small (1 satoshi?) output to every commitment transaction that anyone can spend.Meanwhile, Jonathan raises another issue related to unilateral close with his output on CSV timelock. He discovers that there are 500 MB of transactions at around 100 satoshi/byte, making it unlikely that his transaction will get confirmed at 40 sat/byte. His only hope is for the other person to come back online and use CPFPs to redeem the to_remote output. However, since the CSV will cause script verification to fail, a CPFP transaction will not be propagated. Without CPFP, the CSV timer won't start. Jonathan asks if anyone has any solutions to this problem.Richard and ZmnSCPxj engage in an email exchange discussing the possibility of one side of a channel having complete control over it. The only way to transfer control back to both parties in a trustless manner would be through an on-chain transaction, which essentially involves closing the channel and reopening it when the other party returns online. However, this approach requires trust in the system and assumes that the other party will communicate any pending shutdown and cooperate in closing the channel. There is also a question about changing the fee size when one party wants to close the channel, but this would require trust in the other party as well. The discussion emphasizes the importance of trust in the Lightning Network.The discussion revolves around potential issues with channel closure and possible solutions to overcome them. One scenario involves one side gaining complete control over the channel, allowing for unilateral closure without input from the other party. Another scenario arises when a user's partner goes offline, leaving their transaction unconfirmed due to insufficient fees. Suggestions are made to use out-of-band fee payment mechanisms like Confirmtx.com or Pushtx.btc.com to get the transaction mined without an on-blockchain payment. Alternatively, using a Lightning transaction to pay for the service could be more cost-effective than on-chain payments. Overall, the discussion highlights the challenges faced in closing channels and explores various strategies to address these challenges.In summary, a user faces a problem where their partner has gone offline, leaving 500 MB of transactions at around 100 satoshi/byte. The user had previously assumed that 40 satoshi/byte was enough to get confirmed but since the other person is offline, their transaction may never get confirmed at this rate. The user's only hope is for the other person to come back online and use CPFPs to redeem the to_remote output, as the CSV timer won't start until the CSV containing output is confirmed. However, if they can't CPFP, the script verification will fail and the CSV timer won't start. Thus, there seems to be no solution except waiting for the other person to come online.


Updated on: 2023-07-31T19:39:21.790404+00:00