Peter Todd [ARCHIVE] on Nostr: π Original date posted:2018-01-14 π Original message: On Sun, Jan 14, 2018 at ...
π
Original date posted:2018-01-14
π Original message:
On Sun, Jan 14, 2018 at 10:30:28AM +0900, Jonathan Underwood 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?
While not ideal, you can use out-of-band fee payment mechanisms such as
https://confirmtx.com and https://pushtx.btc.com to get the transaction mined
without an on-blockchain payment. For that matter, you could use a Lightning
transaction to pay for that service more cheaply than on-chain payments those
existing accelerators currently use.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180114/98c78dd1/attachment.sig>
π Original message:
On Sun, Jan 14, 2018 at 10:30:28AM +0900, Jonathan Underwood 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?
While not ideal, you can use out-of-band fee payment mechanisms such as
https://confirmtx.com and https://pushtx.btc.com to get the transaction mined
without an on-blockchain payment. For that matter, you could use a Lightning
transaction to pay for that service more cheaply than on-chain payments those
existing accelerators currently use.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180114/98c78dd1/attachment.sig>