Quote from: nc50lc on September 21, 2019, 09:52:38 AM

Isn't this the same as number 3's input(s) re-spending to make another TX to extend the n_locktime target?
If Alice needs to withdraw from the accidentally broadcasted tx, then there's an on-chain transaction and fees involved
thus, basically the same as #3.

I found 3 the most convenient option, but it's possible to create a client that utilizes the concept for ease of use.

That is different, although I'm not sure if I explained it clear enough.
The point here is that Alice does not need to re-spend transaction to extend to new CSV target. She creates transaction where inputs are any UTXOs belonging to Alice but outputs have CSV target for Bob's public key (in ELSE clause). Bob gets this transaction from Alice directly and keeps it on his side (inside wallet storage, e.g). No broadcasting, no keeping in peer mempool, etc.
That's it until accident, assuming Alice does not spend inputs that transaction targets. No more actions like re-spending are needed from Alice unlike in type 3 option. The relative lock clock will start ticking only when there is an accident and Bob broadcasts.

Quote from: ETFbitcoin on September 21, 2019, 06:54:09 PM

I know LN time lock generally far shorter. But what if Alice forget to re-new the transaction and Bob spend the coin as soon as time lock duration expired? With high transaction fees, Alice only have about 10 minutes attempting to cancel / double-spend Bob's transaction.

The same answer is here.