David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-07 📝 Original message: On 2022-10-03 06:55, ...

📅 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