jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-11 📝 Original message: Hi Dave, Thanks for ...
📅 Original date posted:2022-10-11
📝 Original message:
Hi Dave,
Thanks for reading and for doing a better job of explaining the ideas than I did!
Responses are in-line below:
> 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).
Yes, that's exactly right.
I'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.
I'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.
>
> [1]
> <a href="https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf">https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf</a>;
> [2] "Trigger" transaction is the name given to that type of transaction
> in section 4.2 of the Eltoo paper: <a href="https://blockstream.com/eltoo.pdf">https://blockstream.com/eltoo.pdf</a>;
>
> > 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.
Yes, that's correct.
In 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.
Is 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.
> 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.
You'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?
The 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.
Does that make sense?
Many thanks,
John
Sent with Proton Mail secure email.
📝 Original message:
Hi Dave,
Thanks for reading and for doing a better job of explaining the ideas than I did!
Responses are in-line below:
> 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).
Yes, that's exactly right.
I'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.
I'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.
>
> [1]
> <a href="https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf">https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf</a>;
> [2] "Trigger" transaction is the name given to that type of transaction
> in section 4.2 of the Eltoo paper: <a href="https://blockstream.com/eltoo.pdf">https://blockstream.com/eltoo.pdf</a>;
>
> > 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.
Yes, that's correct.
In 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.
Is 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.
> 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.
You'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?
The 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.
Does that make sense?
Many thanks,
John
Sent with Proton Mail secure email.