From ugamkamat1 at gmail.com  Wed Jun  5 15:51:51 2019
From: ugamkamat1 at gmail.com (Ugam Kamat)
Date: Wed, 5 Jun 2019 21:21:51 +0530
Subject: [Lightning-dev] BOLT #3: Shouldn't timeout be included in the
	script of "Offered HTLC Outputs" for the local node?
Message-ID: <033501d51bb6$9871cb90$c95562b0$@gmail.com>

Hey guys,

 

I know this question is not right for this mailing list, but I have tried
asking it on Stackexchange
<https://bitcoin.stackexchange.com/questions/88100/bolt-3-shouldnt-timeout-b
e-included-in-the-script-of-offered-htlc-outputs-f>  (even offered a bounty)
and didn't get a response as of yet.  So here's the question: According to
the BOLT #3 documentation,
<https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactio
ns.md#offered-htlc-outputs> the offered HTLC output has the following script
that allows the remote node to claim the funds with the payment pre-image
and the local node to claim it after a HTLC timeout.

 

1.  # To remote node with revocation key
2.  OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
3.  OP_IF
4.      OP_CHECKSIG
5.  OP_ELSE
6.      <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
7.      OP_NOTIF
8.          # To local node via HTLC-timeout transaction (timelocked).
9.          OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
10.      OP_ELSE
11.         # To remote node with preimage.
12.         OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
13.         OP_CHECKSIG
14.      OP_ENDIF
15. OP_ENDIF

 

If you see the output that sends the funds to the local node (line 7-9), it
is not timelocked in the script. What is said is that that part is delayed
in the second stage using to_self_delay. However, a local node after signing
this commitment transaction, which includes the HTLC he offered, can
broadcast it to claim the bitcoins from the HTLC-timeout (he already has the
signatures) and pays to an address although with to_self_delay.

 

Although the delay exists in the 2nd stage (CSV locked with to_self_delay),
nothing stops me from offering a htlc to my peer node, sign the updated
commitment transaction and a second later broadcast the commitment
transaction on mainchain and spend the HTLC to an address locked with CSV.
The remote node will still forward the htlc because from its viewpoint it is
still within the bounds of the cltv_expiry as specified by BOLTs. Now, when
the remote node gets the pre-image it doesn't have any transaction to settle
with. Where is the shortcoming in my though process and isn't timelock
expiry something that should be included in the script itself?

 

 

Ugam

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190605/b45f4506/attachment-0001.html>