Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-16 📝 Original message: Hi Jonathan, This is ...
📅 Original date posted:2018-01-16
📝 Original message:
Hi Jonathan,
This is definitely a problem! I have a mainnet channel I force closed 2 weeks ago that is still not mined :(
With current spec I guess it is not much that can be done other than crossing fingers. For future specs maybe someone could come up with some SIGHASH flag magic to either (1) allow adding an extra input that could go to fees, or (2) add both a new input and output, where the difference goes to fees. I believe this would change the TXID of the commitment transaction, but not sure if that’s a problem? (Watchtowers comes to mind).
If keeping the TXID intact is important, one solution would be to always add a small (1 satoshi?) output to every commitment transaction, that anyone can spend. So if the commitment transaction has a fee too low, you could do CPFP on this small output, making it confirm. You could even make a batch sweep of many such outputs, and they would be (un)fairly cheap since they don’t need a signature. Do you think this would work?
- Johan
On Sun, Jan 14, 2018 at 2:30, Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
Hey everybody.
Say that the last time we updated channel state, we assumed 40 satoshi/byte was enough to get confirmed, then I leave the channel for a few weeks, come back to find my partner fell off the face of the internet.
I perform unilateral close with my output on CSV timelock... but it turns out there’s 500 MB of txes at around 100 satoshi/byte and lets say my transaction will never get confirmed at 40 sat/byte.
What course of action can I take?
1. to_local output can't be redeemed until the commitment transaction (which will "never confirm") is confirmed + the CSV timeout.
2. to_remote output probably won't be redeemed as the other person is offline.
The only remedy I can think of is hope that the other person comes back online and CPFPs your to_remote output for you... but at that point it would be better for them to just amicably close with normal outputs... so basically your only hope is wait for other person to come online.
Since CSV will cause script verification to fail, a CPFP transaction will not be propagated.
If we can't CPFP, the CSV timer won't start (it starts once the CSV containing output is confirmed).
Seems like a problem.
Anyone have any solutions?
Thanks, Jon
--
-----------------
Jonathan Underwood ビットバンク社 チーフビットコインオフィサー -----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180117/1a4ee0f6/attachment.html>;
📝 Original message:
Hi Jonathan,
This is definitely a problem! I have a mainnet channel I force closed 2 weeks ago that is still not mined :(
With current spec I guess it is not much that can be done other than crossing fingers. For future specs maybe someone could come up with some SIGHASH flag magic to either (1) allow adding an extra input that could go to fees, or (2) add both a new input and output, where the difference goes to fees. I believe this would change the TXID of the commitment transaction, but not sure if that’s a problem? (Watchtowers comes to mind).
If keeping the TXID intact is important, one solution would be to always add a small (1 satoshi?) output to every commitment transaction, that anyone can spend. So if the commitment transaction has a fee too low, you could do CPFP on this small output, making it confirm. You could even make a batch sweep of many such outputs, and they would be (un)fairly cheap since they don’t need a signature. Do you think this would work?
- Johan
On Sun, Jan 14, 2018 at 2:30, Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
Hey everybody.
Say that the last time we updated channel state, we assumed 40 satoshi/byte was enough to get confirmed, then I leave the channel for a few weeks, come back to find my partner fell off the face of the internet.
I perform unilateral close with my output on CSV timelock... but it turns out there’s 500 MB of txes at around 100 satoshi/byte and lets say my transaction will never get confirmed at 40 sat/byte.
What course of action can I take?
1. to_local output can't be redeemed until the commitment transaction (which will "never confirm") is confirmed + the CSV timeout.
2. to_remote output probably won't be redeemed as the other person is offline.
The only remedy I can think of is hope that the other person comes back online and CPFPs your to_remote output for you... but at that point it would be better for them to just amicably close with normal outputs... so basically your only hope is wait for other person to come online.
Since CSV will cause script verification to fail, a CPFP transaction will not be propagated.
If we can't CPFP, the CSV timer won't start (it starts once the CSV containing output is confirmed).
Seems like a problem.
Anyone have any solutions?
Thanks, Jon
--
-----------------
Jonathan Underwood ビットバンク社 チーフビットコインオフィサー -----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180117/1a4ee0f6/attachment.html>;