{"type":"rich","version":"1.0","author_name":"npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exr","author_url":"https://nostr.ae/npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exr","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-11\n📝 Original message:\nHi Dave,\n\nThanks for reading and for doing a better job of explaining the ideas than I did!\n\nResponses are in-line below:\n\n\u003e Hi John,\n\u003e \n\u003e I had difficulty understanding your proposal description here and in \n\u003e your paper[1].  I wonder if others are having the same the same \n\u003e difficulty, so I've tried to reduce it down to just the essential idea \n\u003e so you can tell me if I'm understanding correctly and others can \n\u003e evaluate it more quickly.  Here I go:\n\u003e \n\u003e In a traditional HTLC, the agreement is essentially:\n\u003e \n\u003e - Setup: Alice has x BTC, an unpublished value y, and the hash digest z \n\u003e which is hash(y)\n\u003e - HTLC success: Alice offers Bob the x BTC, which he can claim at any \n\u003e time if he publishes y satisfying the equation hash(y) == z\n\u003e - HTLC failure: Alice can spend the x BTC back to her wallet after some \n\u003e time t has elapsed\n\u003e \n\u003e If I understand your modified protocol correctly, the essential modified \n\u003e agreement is:\n\u003e \n\u003e - [Setup the same]\n\u003e - [HTLC success the same]\n\u003e - HTLC failure: Alice can spend the x BTC back to her wallet by first \n\u003e getting a trigger[2] transaction confirmed onchain, waiting b blocks, \n\u003e then getting the actual spend-back-to-wallet transaction confirmed\n\u003e \n\u003e Because the trigger transaction needs to be confirmed for b blocks \n\u003e before Alice can can spend the money back to her wallet, Bob doesn't \n\u003e need to take any action to lock-in an HTLC Success unless he sees the \n\u003e trigger transaction appear onchain or he expects to be offline for more \n\u003e than b blocks.  This allows Alice to stay offline for as long as Bob can \n\u003e tolerate (which goes towards your point of Alice prepaying Bob for that \n\u003e tolerance).\n\nYes, that's exactly right.\n\nI'd note that the transaction that plays the role of the \"trigger\" transaction is actually just Alice's Commitment transaction, so no new transaction is required.\n\nI'd also note that the parameter \"b\" is exactly Bob's to_self_delay parameter and he has already committed himself to being able to respond to Alice's on-chain transactions within a window of b blocks, so the protocol doesn't put any additional requirements on his monitoring of the blockchain.\n\n\u003e \n\u003e [1] \n\u003e \u003ca href=\"https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf\"\u003ehttps://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf\u003c/a\u003e\n\u003e [2] \"Trigger\" transaction is the name given to that type of transaction \n\u003e in section 4.2 of the Eltoo paper: \u003ca href=\"https://blockstream.com/eltoo.pdf\"\u003ehttps://blockstream.com/eltoo.pdf\u003c/a\u003e\n\u003e \n\u003e \u003e One-Shot Receives\n\u003e \u003e =================\n\u003e \u003e\n\u003e I understand the essence of this idea to be simply encumbering dedicated \n\u003e user Bob's commitment transaction with a timelock so that he can't \n\u003e publish it until near the time when any HTLCs in it would expire.  \n\u003e Alice's version of commitment would be unencumbered, so she could \n\u003e publish it any time.\n\nYes, that's correct.\n\nIn particular, dedicated user Bob can't publish his current Commitment transaction until Alice has put her conflicting current Commitment transaction on-chain (assuming she follows the protocol) or both parties have updated the state off-chain. As a result, Alice doesn't have to worry about the case where she submits her current Commitment and HTLC-success transactions only to later discover that Bob's current Commitment transaction has won the race, thus forcing Alice to then submit her transaction (which is like an HTLC-success transaction but isn't actually called that in the protocol) which reveals the hash preimage and takes payment of the HTLC. Forcing Alice to wait around to see who's current Commitment transaction has won the race seems like an inconvenient requirement for a casual user.\n\nIs my understanding of this issue correct, or can Alice submit her transaction spending the HTLC output of Bob's current Commitment transaction even before he has submitted his current Commitment transaction? I realize this part of the protocol depends on node relay behavior, so it's harder to nail down and reason about than the consensus portion of the protocol. I may not have the correct understanding here, and if my understanding isn't correct, I'd really like to fix it.\n\n\u003e Although your proposal may address this in the normal case, I think it \n\u003e doesn't address the pathological case where honest casual user Alice \n\u003e broadcasts the latest commitment transaction but her channel partner, \n\u003e malicious dedicated user Mallory, broadcasts an older revoked commitment \n\u003e transaction.  Because Mallory's revoked commitment transaction is older, \n\u003e its timelock has expired, so it can win the race against Alice's latest \n\u003e commitment transaction.\n\u003e \n\u003e To become aware of this situation and to broadcast a penalty transaction \n\u003e within the necessary time limit, Alice still needs to monitor the block \n\u003e chain.  If Alice still needs to monitor the block chain in any case, \n\u003e this proposed change doesn't eliminate the underlying problem of onerous \n\u003e monitoring as far as I can tell.\n\nYou're right that Bob (or Mallory) could still broadcast an older revoked transaction, and if that happens, Alice needs to broadcast a penalty transaction within her long interval (I_L) safety parameter which I was suggesting she could set to something like 1-3 months. I felt that being able to shut off her phone and not worry about the Lightning app for all but a short time (say 10 minutes) every few months wasn't overly onerous. Do you feel that casual users wouldn't see it that way?\n\nThe issue of how often Alice needs to monitor the blockchain is based on her setting of her I_L parameter and is really independent of her ability to perform one-shot receives. My understanding is that in the current Lightning protocol, if Alice is receiving a payment and she gives the payment's secret to her partner Bob, and if Bob fails to update the channel state to reflect the payment, Alice has to 1) submit her Commitment and HTLC-success transactions, 2) wait to see if her current Commitment transaction or Bob's current Commitment transaction won the race, and if Bob's current Commitment transaction won, 3) submit her transaction spending Bob's current Commitment transaction's HTLC output. The protocol that supports one-shot receives eliminates steps 2) and 3) above, which seems like a better user interface.\n\nDoes that make sense?\n\nMany thanks,\nJohn\n\n\n\nSent with Proton Mail secure email."}