Ugam Kamat [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-06-05 to 2020-01-27
💬 Posted a total of 9 messages
📚 Participated in the following categories: Lightning-dev, PROPOSAL
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:58:14

- reply

📅 Original date posted:2020-01-27
📝 Original message:
Hey Subhra – In order to have faith that the channel announced by the nodes is actually locked on the Bitcoin mainchain we need to have the outpoint (`txid` and `vout`) of the funding transaction. If we do not verify that the funding transaction has been confirmed, nodes can cheat us that a particular transaction is confirmed when it is not the case. As a result we require that nodes announce this information along with the public keys and the signatures of the public keys that was used to lock the funding transaction.
This information is broadcasted in the `channel_announcement` message in the `short_channel_id` field which includes the block number, transaction number and vout. Since Bitcoin does not allow confidential transactions, we can query the blockchain and find out the channel capacity even when the amounts are never explicitly mentioned.
Ugam
From: Lightning-dev <lightning-dev-bounces at lists.linuxfoundation.org> On Behalf Of Subhra Mazumdar
Sent: Monday, January 27, 2020 12:45 PM
To: lightning-dev at lists.linuxfoundation.org
Subject: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network
Dear All,
What can be the potential problem if a channel is opened whereby the channel capacity is not revealed publicly but just a range proof of the attribute (capacity >0 and capacity < value) is provided ? Will it pose a problem during routing of transaction ? What are the pros and cons ?
I think that revealing channel capacity make the channels susceptible to channel exhaustion attack or a particular node might be targeted for node isolation attack ?
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/cf9b0f81/attachment-0001.html>

2023-06-09 12:55:18

- reply

📅 Original date posted:2019-06-26
📝 Original message:
Hey ZmnSCPxj,
Really appreciate your efforts in going through the proposal in depth. The two choices you mentioned for the proposal are a really fair analysis of how an attack can be launched on such forked away payments. In the current scheme, it seems it will create problems rather than solve it. I'll try to do some more work and see if I can come up with a more solid way in order to achieve this. Thanks again.
Ugam
-----Original Message-----
From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Sent: Wednesday, June 26, 2019 4:35 AM
To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Cc: René Pickhardt <r.pickhardt at googlemail.com>; Ugam Kamat <ugamkamat1 at gmail.com>; lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions
Good morning Ugam,
> In any case, this is effectively simply creation of fork points and join points along a multipart path.
> That the payment does not later join is merely a detail, especially once we get to "high" AMP (which requires payment points / scalars).
> We decided at previous dev summit not to implement this due to complexity-of-implementation for payers, as well as how to resolve when one branch fails while the other branch claims the payment.
On reflection, that there is no later join means that this scheme allows attack.
We have two choices:
1. Both forked branches have to succeed in order for the fork node to claim its incoming payment.
2. Either forked branch can succeed and the fork node can claim its incoming payment.
If we go with 1:
* Fork nodes can be attacked by routing a self-payment through a fork node, with the other branch going nowhere (give it an unuseable preimage).
Claim the branch that goes to yourself, then wait for your outgoing payment to lapse.
The fork node is forced to pay one branch but is unable to claim its incoming payment.
Attacker earns free money.
If we go with 2:
* Fork nodes can attack opportunistically, by only paying out to the smaller-valued branch.
Once the smaller-valued branch succeeds, the fork node can claim its incoming payment and forget about the other branch of the payment.
* This is the choice made for multipart payments.
However, note that in multipart, there is always a later join (most likely at the ultimate, *single* destination).
The join will not succeed unless both incoming payments arrive, so fork nodes cannot perform this attack opportunistically.
A plausible fix for your scheme would be to take choice 2 (either branch succeeding lets fork node claim incoming payment).
Then Eric and Grace need to cooperate and only take incoming payment if both of them receive incoming payments.
This implies Eric and Grace must trust each other to coordinate.
Regards,
ZmnSCPxj

2023-06-09 12:55:18

- reply

📅 Original date posted:2019-06-29
📝 Original message:
Thanks Christian for the references! As ZmnSCPxj pointed out, there was a loophole in my proposal that could potentially lead to DoS and failure attacks in the channels. These references should help me in working my proposal to circumvent such attacks. Have a great weekend.
Ugam
From: Christian Decker <decker.christian at gmail.com>
Sent: Friday, June 28, 2019 11:09 PM
To: Ugam Kamat <ugamkamat1 at gmail.com>
Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions
Hi Ugam,
I just wanted to quickly note that the current proposal [1] (implemented here [2]) is to give up on the fixed 65 byte frames altogether and allow variable payloads (reclaiming what previously was padding in the hop payloads). Given the low diameter of the network, this gives us a lot of freedom to put additional payloads in the onion :-)
Cheers,
Christian
[1] https://github.com/lightningnetwork/lightning-rfc/pull/619
[2] https://github.com/ElementsProject/lightning/pull/2689
On Tue, Jun 25, 2019 at 1:07 PM Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> > wrote:
Hey guys,
I’m kind of new to this mailing list, so let me know if this has been proposed previously. While reading Olaoluwa Osuntokun’s Spontaneous Payment proposal, I came up with the idea of simultaneous payments to multiple parties using the same partial route. In other words, say Alice, Bob, Charlie, Dave and Eric have channel opened with one another, and say Dave also has channel with Frank who has channel with Grace. Now, Alice is at a restaurant and wants to pay the bill amount to Eric (the restaurant owner) and a tip to Grace (who was her waiter). In the current scenario, Alice would have to send two payments A->B->C->D->E and A->B->C->D->F->G. However, if we repurpose the onion blob <https://github.com/ElementsProject/lightning/pull/2363> in the same way as is needed for Spontaneous Payments, we can create a scenario where there is no path duplication. Dave would split the payments, one to Eric and other going to Grace through Frank. The preimage PM used in commitments A->B, B->C and C->D will be a function of pre-images P1 of D->E and P2 of D->F and F->G such that PM = f(P1, P2).
Proposal can be implemented by repurposing the onion in similar fashion as Spontaneous Payments with slight modification
This proposal works in similar fashion to Spontaneous Payment proposal, by packing in additional data in the unused hops. For B and C the onion blob will be identical to other lightning payments. When D parses the onion, the 4 MSB of the realm will tell D how much data can be extracted. This data will encode the hashes of the pre-images that would be used for commitment transaction towards Eric and other towards Frank. For simplicity and privacy, I propose using 2 onion blobs for the data. So the payload can be 64 + 33 bytes = 97 bytes. The first byte would indicate how many hashes are packed, so we have 96 bytes for the payload, meaning we can pack a maximum of 3 hashes for 3 route payments from D. Now D will split the onion (18 hops as it has used the first two for bifurcation data) into number of routes. In the above case it will be 9 hops each. Now these two onions are similar to other lightning payments. The first hop tells D the short-channel id, amount to forward, CLTV and the padding. Since, the preimage is 32 bytes, we can pack that in one single hop that is received by the final party. This leaves the remaining 7 hops can be used for routing. Below figure depicts the onion split in terms of how A will create it. D will add the filler to make each onion have 20 hops. Onion data is encoded in the same order in which the payment hashes are packed in the bifurcation data for D.
Calculating the preimages
Eric and Grace will parse the onion and use the pre-images for settlement. Let P1 represent the pre-images of D->E and P2 of D->F and F->G. When the pre-images arrive at node D, it will combine them such that PM = f(P1, P2). The easiest way for both A and D to calculate that will be PM = SHA256(P1 || P2 || ss_d). Where || represents concatenation and ss_d is the shared secret created using the ephemeral public key of sender (the one generated by Alice) and private key of Dave. The need for using shared secret is to prevent the vulnerability where one channel operator who has nodes across both branches can use them to calculate the PM. Using shared secret also ensures that it is in fact D that has parsed them together.
Advantages of this proposal:
* Commitment transactions between A & B, B & C, and C & D now carry only one HTLC instead of two
* This means lower fees in case of on-chain settlement
* Lower routing fees for Alice as Bob and Charlie would not get to charge for two routings
* Since 483 is the max limit of the htlcs nodes can accepts, preventing duplication will allow more number of htlcs in flight.
* If each payment of Eric and Grace is below the htlc min B or C accepts, but together if it is higher, this route is now usable
Some thoughts on if this proposal can be misused?
* The probability of transaction failures increases as now the transaction is dependent on 2/3 branches
Deployment
Not all nodes need to support this feature. For example, B, C, E, F, and G does not even know that the payment arrived through branching. The nodes that can handle branching of payments can signal that using global features.
Ugam
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190629/1e2bb26f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7836 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190629/1e2bb26f/attachment-0001.png>

2023-06-09 12:55:16

- reply

📅 Original date posted:2019-06-25
📝 Original message:
Hey Rene, thanks for your comments! Regarding, pathfinding I agree, that smaller payments will have higher success rates, but this kind of bundling of payments will make some routes accessible which might not have been previously either due to `htlc_minimum_msat` limit of those nodes. Also, this reduces the number of HTLCs that are added making 483 limit more harder to reach. I think the decision might be a balance that we need to strike and can be an optional feature that can be enabled.
Yes, this proposal can only work for spontaneous payments as I think it would be impossible to bundle the hashes generated by the invoices and extract the pre-image. Regarding, proof of payment, as far as I know, spontaneous payments in itself does not carry that as Alice already knows the pre-images. So, this situation would be similar to that or even AMP for that matter where the user generates the preimages by themselves.
Could one resolve this in the world of scriptless scripts or when changing to secret / curve point based preimages based on the discrete log? To be frank, I have not done any work on this and will have to read this up before I can comment. Really appreciate your feedback.
Ugam
From: René Pickhardt <r.pickhardt at googlemail.com>
Sent: Tuesday, June 25, 2019 5:03 PM
To: Ugam Kamat <ugamkamat1 at gmail.com>
Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions
Hey Ugam,
I like the very clearly communicated idea and the fact that we can do crazy stuff with the filler of the onions. I have two concerns / questions:
1.) In pathfinding we actually try to make payments smaller (like moving to AMP) instead of combining payments. I think it was shown several times that the probability of finding a path (successful route) decreases with larger amounts. So saving fees might actually not be the metric that we are trying to optimize.
2.) Am I correct that this proposal would only work with the spontaneous payment scenario as the payment hashes of Eric and Grace could not just be added up as easy as the preimages can to get the overall payment hash for Alice? So in that sense on the invoice based system your proposal is not working and we don't have a proof of payment as Alice already knows the preimages? Could one resolve this in the world of scriptless scripts or when changing to secret / curve point based preimages based on the discrete log?
best Rene
On Tue, Jun 25, 2019 at 7:07 AM Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> > wrote:
Hey guys,
I’m kind of new to this mailing list, so let me know if this has been proposed previously. While reading Olaoluwa Osuntokun’s Spontaneous Payment proposal, I came up with the idea of simultaneous payments to multiple parties using the same partial route. In other words, say Alice, Bob, Charlie, Dave and Eric have channel opened with one another, and say Dave also has channel with Frank who has channel with Grace. Now, Alice is at a restaurant and wants to pay the bill amount to Eric (the restaurant owner) and a tip to Grace (who was her waiter). In the current scenario, Alice would have to send two payments A->B->C->D->E and A->B->C->D->F->G. However, if we repurpose the onion blob <https://github.com/ElementsProject/lightning/pull/2363> in the same way as is needed for Spontaneous Payments, we can create a scenario where there is no path duplication. Dave would split the payments, one to Eric and other going to Grace through Frank. The preimage PM used in commitments A->B, B->C and C->D will be a function of pre-images P1 of D->E and P2 of D->F and F->G such that PM = f(P1, P2).
Proposal can be implemented by repurposing the onion in similar fashion as Spontaneous Payments with slight modification
This proposal works in similar fashion to Spontaneous Payment proposal, by packing in additional data in the unused hops. For B and C the onion blob will be identical to other lightning payments. When D parses the onion, the 4 MSB of the realm will tell D how much data can be extracted. This data will encode the hashes of the pre-images that would be used for commitment transaction towards Eric and other towards Frank. For simplicity and privacy, I propose using 2 onion blobs for the data. So the payload can be 64 + 33 bytes = 97 bytes. The first byte would indicate how many hashes are packed, so we have 96 bytes for the payload, meaning we can pack a maximum of 3 hashes for 3 route payments from D. Now D will split the onion (18 hops as it has used the first two for bifurcation data) into number of routes. In the above case it will be 9 hops each. Now these two onions are similar to other lightning payments. The first hop tells D the short-channel id, amount to forward, CLTV and the padding. Since, the preimage is 32 bytes, we can pack that in one single hop that is received by the final party. This leaves the remaining 7 hops can be used for routing. Below figure depicts the onion split in terms of how A will create it. D will add the filler to make each onion have 20 hops. Onion data is encoded in the same order in which the payment hashes are packed in the bifurcation data for D.
Calculating the preimages
Eric and Grace will parse the onion and use the pre-images for settlement. Let P1 represent the pre-images of D->E and P2 of D->F and F->G. When the pre-images arrive at node D, it will combine them such that PM = f(P1, P2). The easiest way for both A and D to calculate that will be PM = SHA256(P1 || P2 || ss_d). Where || represents concatenation and ss_d is the shared secret created using the ephemeral public key of sender (the one generated by Alice) and private key of Dave. The need for using shared secret is to prevent the vulnerability where one channel operator who has nodes across both branches can use them to calculate the PM. Using shared secret also ensures that it is in fact D that has parsed them together.
Advantages of this proposal:
* Commitment transactions between A & B, B & C, and C & D now carry only one HTLC instead of two
* This means lower fees in case of on-chain settlement
* Lower routing fees for Alice as Bob and Charlie would not get to charge for two routings
* Since 483 is the max limit of the htlcs nodes can accepts, preventing duplication will allow more number of htlcs in flight.
* If each payment of Eric and Grace is below the htlc min B or C accepts, but together if it is higher, this route is now usable
Some thoughts on if this proposal can be misused?
* The probability of transaction failures increases as now the transaction is dependent on 2/3 branches
Deployment
Not all nodes need to support this feature. For example, B, C, E, F, and G does not even know that the payment arrived through branching. The nodes that can handle branching of payments can signal that using global features.
Ugam
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
https://www.rene-pickhardt.de
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/edb91a2b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7836 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/edb91a2b/attachment-0001.png>

2023-06-09 12:55:15

- reply

📅 Original date posted:2019-06-25
📝 Original message:
Hey guys,
I'm kind of new to this mailing list, so let me know if this has been
proposed previously. While reading Olaoluwa Osuntokun's Spontaneous Payment
proposal, I came up with the idea of simultaneous payments to multiple
parties using the same partial route. In other words, say Alice, Bob,
Charlie, Dave and Eric have channel opened with one another, and say Dave
also has channel with Frank who has channel with Grace. Now, Alice is at a
restaurant and wants to pay the bill amount to Eric (the restaurant owner)
and a tip to Grace (who was her waiter). In the current scenario, Alice
would have to send two payments A->B->C->D->E and A->B->C->D->F->G. However,
if we repurpose the onion blob
<https://github.com/ElementsProject/lightning/pull/2363> in the same way as
is needed for Spontaneous Payments, we can create a scenario where there is
no path duplication. Dave would split the payments, one to Eric and other
going to Grace through Frank. The preimage PM used in commitments A->B, B->C
and C->D will be a function of pre-images P1 of D->E and P2 of D->F and F->G
such that PM = f(P1, P2).
Proposal can be implemented by repurposing the onion in similar fashion as
Spontaneous Payments with slight modification
This proposal works in similar fashion to Spontaneous Payment proposal, by
packing in additional data in the unused hops. For B and C the onion blob
will be identical to other lightning payments. When D parses the onion, the
4 MSB of the realm will tell D how much data can be extracted. This data
will encode the hashes of the pre-images that would be used for commitment
transaction towards Eric and other towards Frank. For simplicity and
privacy, I propose using 2 onion blobs for the data. So the payload can be
64 + 33 bytes = 97 bytes. The first byte would indicate how many hashes are
packed, so we have 96 bytes for the payload, meaning we can pack a maximum
of 3 hashes for 3 route payments from D. Now D will split the onion (18 hops
as it has used the first two for bifurcation data) into number of routes. In
the above case it will be 9 hops each. Now these two onions are similar to
other lightning payments. The first hop tells D the short-channel id, amount
to forward, CLTV and the padding. Since, the preimage is 32 bytes, we can
pack that in one single hop that is received by the final party. This leaves
the remaining 7 hops can be used for routing. Below figure depicts the onion
split in terms of how A will create it. D will add the filler to make each
onion have 20 hops. Onion data is encoded in the same order in which the
payment hashes are packed in the bifurcation data for D.
Calculating the preimages
Eric and Grace will parse the onion and use the pre-images for settlement.
Let P1 represent the pre-images of D->E and P2 of D->F and F->G. When the
pre-images arrive at node D, it will combine them such that PM = f(P1, P2).
The easiest way for both A and D to calculate that will be PM = SHA256(P1 ||
P2 || ss_d). Where || represents concatenation and ss_d is the shared secret
created using the ephemeral public key of sender (the one generated by
Alice) and private key of Dave. The need for using shared secret is to
prevent the vulnerability where one channel operator who has nodes across
both branches can use them to calculate the PM. Using shared secret also
ensures that it is in fact D that has parsed them together.
Advantages of this proposal:
* Commitment transactions between A & B, B & C, and C & D now carry
only one HTLC instead of two
* This means lower fees in case of on-chain settlement
* Lower routing fees for Alice as Bob and Charlie would not get to
charge for two routings
* Since 483 is the max limit of the htlcs nodes can accepts,
preventing duplication will allow more number of htlcs in flight.
* If each payment of Eric and Grace is below the htlc min B or C
accepts, but together if it is higher, this route is now usable
Some thoughts on if this proposal can be misused?
* The probability of transaction failures increases as now the
transaction is dependent on 2/3 branches
Deployment
Not all nodes need to support this feature. For example, B, C, E, F, and G
does not even know that the payment arrived through branching. The nodes
that can handle branching of payments can signal that using global features.
Ugam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/0934469a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7836 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/0934469a/attachment-0001.png>

2023-06-09 12:55:04

- reply

📅 Original date posted:2019-06-05
📝 Original message:
Hey Nadav, that’s a good call as it’s not particularly intuitive when you try to read it. I’ll try to add to it if I can. Thanks!
Ugam
From: Nadav Kohen <nadav at suredbits.com>
Sent: Wednesday, June 5, 2019 10:08 PM
To: Ugam Kamat <ugamkamat1 at gmail.com>
Cc: Pierre <pm+lists at acinq.fr>; lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
Hi Ugam,
I also ran into an issue understanding this a while back, here's a PR I opened to try and make things more clear: https://github.com/lightningnetwork/lightning-rfc/pull/601
Feel free to add to it or comment if you think things could be improved :)
Best,
Nadav
On Wed, Jun 5, 2019 at 11:33 AM Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> > wrote:
Ah, now I see what you mean, it is locked with absolute timelock and hence I cannot broadcast that transaction. My apologies and thanks for the help!
Ugam
From: Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> >
Sent: Wednesday, June 5, 2019 10:00 PM
To: 'Pierre' <pm+lists at acinq.fr <mailto:pm%2Blists at acinq.fr> >
Cc: 'lightning-dev' <lightning-dev at lists.linuxfoundation.org <mailto:lightning-dev at lists.linuxfoundation.org> >
Subject: RE: [Lightning-dev] BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
Hey Pierre,
That’s what I am having a hard time understanding. Although it is timelocked in the second stage HTLC-timeout, I can still spend the original commitment transaction although after some time. This is what my thought process is:
* Offer the Htlc output and sign the commitment transactions
* Broadcast the commitment transaction containing the offered HTLC outputs to the main chain. The outputs of commitment tx are: (1) to remote; (2) to local with to_self_delay and (3) to P2WSH (the script I pasted earlier)
* Commitment transaction gets mined
* Spend the third output using 0 <remotehtlcsig> <localhtlcsig> 0 in the witness stack which will send the outputs to <local_delayed_pubkey> using to_self_delay
Now I think when you say the HTLC time out transaction is timelocked, you are referring the to the to_self_delay when spending the htlc-timeout. But although there is that timeout, the commitment transaction is already broadcasted, and the P2WSH output is already sent to my public key (although with a delay I can still spend that without my counterparty’s assent). Now, my counterparty on the other hand when he gets the pre-image, does not have the P2WSH output to claim his bitcoins with the pre-image because it has been already locked with my <local_delayed_pubkey> which I can spend when the to_senf_delay` is over
Ugam
From: Pierre <pm+lists at acinq.fr <mailto:pm+lists at acinq.fr> >
Sent: Wednesday, June 5, 2019 9:35 PM
To: Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> >
Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org <mailto:lightning-dev at lists.linuxfoundation.org> >
Subject: Re: [Lightning-dev] BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
Hello Ugam,
The HTLC-Timeout transaction <https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions> is timelocked (with locktime=cltv_expiry).
Cheers,
Pierre
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190605/6aa78160/attachment-0001.html>

2023-06-09 12:55:04

- reply

📅 Original date posted:2019-06-05
📝 Original message:
Ah, now I see what you mean, it is locked with absolute timelock and hence I cannot broadcast that transaction. My apologies and thanks for the help!
Ugam
From: Ugam Kamat <ugamkamat1 at gmail.com>
Sent: Wednesday, June 5, 2019 10:00 PM
To: 'Pierre' <pm+lists at acinq.fr>
Cc: 'lightning-dev' <lightning-dev at lists.linuxfoundation.org>
Subject: RE: [Lightning-dev] BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
Hey Pierre,
That’s what I am having a hard time understanding. Although it is timelocked in the second stage HTLC-timeout, I can still spend the original commitment transaction although after some time. This is what my thought process is:
* Offer the Htlc output and sign the commitment transactions
* Broadcast the commitment transaction containing the offered HTLC outputs to the main chain. The outputs of commitment tx are: (1) to remote; (2) to local with to_self_delay and (3) to P2WSH (the script I pasted earlier)
* Commitment transaction gets mined
* Spend the third output using 0 <remotehtlcsig> <localhtlcsig> 0 in the witness stack which will send the outputs to <local_delayed_pubkey> using to_self_delay
Now I think when you say the HTLC time out transaction is timelocked, you are referring the to the to_self_delay when spending the htlc-timeout. But although there is that timeout, the commitment transaction is already broadcasted, and the P2WSH output is already sent to my public key (although with a delay I can still spend that without my counterparty’s assent). Now, my counterparty on the other hand when he gets the pre-image, does not have the P2WSH output to claim his bitcoins with the pre-image because it has been already locked with my <local_delayed_pubkey> which I can spend when the to_senf_delay` is over
Ugam
From: Pierre <pm+lists at acinq.fr <mailto:pm+lists at acinq.fr> >
Sent: Wednesday, June 5, 2019 9:35 PM
To: Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> >
Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org <mailto:lightning-dev at lists.linuxfoundation.org> >
Subject: Re: [Lightning-dev] BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
Hello Ugam,
The HTLC-Timeout transaction <https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions> is timelocked (with locktime=cltv_expiry).
Cheers,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190605/da8d2741/attachment-0001.html>

2023-06-09 12:55:03

- reply

📅 Original date posted:2019-06-05
📝 Original message:
Hey Pierre,
That’s what I am having a hard time understanding. Although it is timelocked in the second stage HTLC-timeout, I can still spend the original commitment transaction although after some time. This is what my thought process is:
* Offer the Htlc output and sign the commitment transactions
* Broadcast the commitment transaction containing the offered HTLC outputs to the main chain. The outputs of commitment tx are: (1) to remote; (2) to local with to_self_delay and (3) to P2WSH (the script I pasted earlier)
* Commitment transaction gets mined
* Spend the third output using 0 <remotehtlcsig> <localhtlcsig> 0 in the witness stack which will send the outputs to <local_delayed_pubkey> using to_self_delay
Now I think when you say the HTLC time out transaction is timelocked, you are referring the to the to_self_delay when spending the htlc-timeout. But although there is that timeout, the commitment transaction is already broadcasted, and the P2WSH output is already sent to my public key (although with a delay I can still spend that without my counterparty’s assent). Now, my counterparty on the other hand when he gets the pre-image, does not have the P2WSH output to claim his bitcoins with the pre-image because it has been already locked with my <local_delayed_pubkey> which I can spend when the to_senf_delay` is over
Ugam
From: Pierre <pm+lists at acinq.fr>
Sent: Wednesday, June 5, 2019 9:35 PM
To: Ugam Kamat <ugamkamat1 at gmail.com>
Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
Hello Ugam,
The HTLC-Timeout transaction <https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions> is timelocked (with locktime=cltv_expiry).
Cheers,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190605/70751958/attachment.html>

2023-06-09 12:55:03

- reply

📅 Original date posted:2019-06-05
📝 Original message:
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>