rich1.0npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdhttps://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdnjumphttps://nostr.ae📅 Original date posted:2022-10-07 📝 Original message: On 2022-10-03 06:55, jlspc via Lightning-dev wrote: > The WF Protocol > =============== Hi John, I had difficulty understanding your proposal description here and in your paper[1]. I wonder if others are having the same the same difficulty, so I've tried to reduce it down to just the essential idea so you can tell me if I'm understanding correctly and others can evaluate it more quickly. Here I go: In a traditional HTLC, the agreement is essentially: - Setup: Alice has x BTC, an unpublished value y, and the hash digest z which is hash(y) - HTLC success: Alice offers Bob the x BTC, which he can claim at any time if he publishes y satisfying the equation hash(y) == z - HTLC failure: Alice can spend the x BTC back to her wallet after some time t has elapsed If I understand your modified protocol correctly, the essential modified agreement is: - [Setup the same] - [HTLC success the same] - HTLC failure: Alice can spend the x BTC back to her wallet by first getting a trigger[2] transaction confirmed onchain, waiting b blocks, then getting the actual spend-back-to-wallet transaction confirmed Because the trigger transaction needs to be confirmed for b blocks before Alice can can spend the money back to her wallet, Bob doesn't need to take any action to lock-in an HTLC Success unless he sees the trigger transaction appear onchain or he expects to be offline for more than b blocks. This allows Alice to stay offline for as long as Bob can tolerate (which goes towards your point of Alice prepaying Bob for that tolerance). [1] https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf [2] "Trigger" transaction is the name given to that type of transaction in section 4.2 of the Eltoo paper: https://blockstream.com/eltoo.pdf > One-Shot Receives > ================= I understand the essence of this idea to be simply encumbering dedicated user Bob's commitment transaction with a timelock so that he can't publish it until near the time when any HTLCs in it would expire. Alice's version of commitment would be unencumbered, so she could publish it any time. > when a user receives a payment and > their channel partner is unresponsive, the user must submit their > Commitment and HTLC-success transactions to the blockchain. However, if > their partner's conflicting Commitment transaction wins the race and is > included in the blockchain, the user then has to submit a different > transaction that reveals the HTLC's secret and spends the HTLC output > in > their partner's Commitment transaction. The requirement to wait and > check > the blockchain for the winning Commitment transaction (which might not > be > determined until multiple blocks have been added to the blockchain) is > awkward for a casual user. Although your proposal may address this in the normal case, I think it doesn't address the pathological case where honest casual user Alice broadcasts the latest commitment transaction but her channel partner, malicious dedicated user Mallory, broadcasts an older revoked commitment transaction. Because Mallory's revoked commitment transaction is older, its timelock has expired, so it can win the race against Alice's latest commitment transaction. To become aware of this situation and to broadcast a penalty transaction within the necessary time limit, Alice still needs to monitor the block chain. If Alice still needs to monitor the block chain in any case, this proposed change doesn't eliminate the underlying problem of onerous monitoring as far as I can tell. Thanks as always for the innovative thinking!, -Dave