{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-07\n📝 Original message:\nOn 2022-10-03 06:55, jlspc via Lightning-dev wrote:\n\u003e The WF Protocol\n\u003e ===============\n\nHi John,\n\nI had difficulty understanding your proposal description here and in \nyour paper[1].  I wonder if others are having the same the same \ndifficulty, so I've tried to reduce it down to just the essential idea \nso you can tell me if I'm understanding correctly and others can \nevaluate it more quickly.  Here I go:\n\nIn a traditional HTLC, the agreement is essentially:\n\n- Setup: Alice has x BTC, an unpublished value y, and the hash digest z \nwhich is hash(y)\n- HTLC success: Alice offers Bob the x BTC, which he can claim at any \ntime if he publishes y satisfying the equation hash(y) == z\n- HTLC failure: Alice can spend the x BTC back to her wallet after some \ntime t has elapsed\n\nIf I understand your modified protocol correctly, the essential modified \nagreement is:\n\n- [Setup the same]\n- [HTLC success the same]\n- HTLC failure: Alice can spend the x BTC back to her wallet by first \ngetting a trigger[2] transaction confirmed onchain, waiting b blocks, \nthen getting the actual spend-back-to-wallet transaction confirmed\n\nBecause the trigger transaction needs to be confirmed for b blocks \nbefore Alice can can spend the money back to her wallet, Bob doesn't \nneed to take any action to lock-in an HTLC Success unless he sees the \ntrigger transaction appear onchain or he expects to be offline for more \nthan b blocks.  This allows Alice to stay offline for as long as Bob can \ntolerate (which goes towards your point of Alice prepaying Bob for that \ntolerance).\n\n[1] \nhttps://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf\n[2] \"Trigger\" transaction is the name given to that type of transaction \nin section 4.2 of the Eltoo paper: https://blockstream.com/eltoo.pdf\n\n\u003e One-Shot Receives\n\u003e =================\n\nI understand the essence of this idea to be simply encumbering dedicated \nuser Bob's commitment transaction with a timelock so that he can't \npublish it until near the time when any HTLCs in it would expire.  \nAlice's version of commitment would be unencumbered, so she could \npublish it any time.\n\n\u003e when a user receives a payment and\n\u003e their channel partner is unresponsive, the user must submit their\n\u003e Commitment and HTLC-success transactions to the blockchain. However, if\n\u003e their partner's conflicting Commitment transaction wins the race and is\n\u003e included in the blockchain, the user then has to submit a different\n\u003e transaction that reveals the HTLC's secret and spends the HTLC output \n\u003e in\n\u003e their partner's Commitment transaction. The requirement to wait and \n\u003e check\n\u003e the blockchain for the winning Commitment transaction (which might not \n\u003e be\n\u003e determined until multiple blocks have been added to the blockchain) is\n\u003e awkward for a casual user.\n\nAlthough your proposal may address this in the normal case, I think it \ndoesn't address the pathological case where honest casual user Alice \nbroadcasts the latest commitment transaction but her channel partner, \nmalicious dedicated user Mallory, broadcasts an older revoked commitment \ntransaction.  Because Mallory's revoked commitment transaction is older, \nits timelock has expired, so it can win the race against Alice's latest \ncommitment transaction.\n\nTo become aware of this situation and to broadcast a penalty transaction \nwithin the necessary time limit, Alice still needs to monitor the block \nchain.  If Alice still needs to monitor the block chain in any case, \nthis proposed change doesn't eliminate the underlying problem of onerous \nmonitoring as far as I can tell.\n\nThanks as always for the innovative thinking!,\n\n-Dave"}