Nostr notes by Benjamin Weintraub [ARCHIVE]

📅 Original date posted:2023-05-02 🗒️ Summary of this ...

2023-06-19T17:42:14Z

In reply to nevent1q…dw7y
_________________________

📅 Original date posted:2023-05-02
🗒️ Summary of this message: A user is seeking help on generating a transaction that spends the to_local and HTLC output after force closing a channel in LND.
📝 Original message:
Thank you, Ken. I have a follow up question as well.

Context: I’m playing around with some failure scenarios in LND. Say Alice is paying Bob, before Bob is able to send the fulfillment (which includes the HTLC preimage), Alice’s node dies and becomes unreachable.

Bob has already received the commitment for the updated balance and already has the preimage, so he force closes the channel.

My understanding is that he will submit the updated commitment to the blockchain as well as the channel closing transaction (after the CSV timeout) which spends his to_local and the HTLC output.

Here is my problem. After using `lncli closechannel --force ...` , I only see the commitment transaction in the mempool, not the subsequent HTLC/to_local spend. How can I generate the transaction that spends the to_local and HTLC output? If there's a way to generate it with lnd, that would be ideal.

Thanks in advance!

Ben
________________________________
From: Ken Sedgwick <ksedgwic at bonsai.com>
Sent: Sunday, April 30, 2023 14:30
To: Benjamin Weintraub <weintraub.b at northeastern.edu>
Cc: Lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Spending `to_local` output of commitment

Ben,

The necessary witness is described here:
https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local-output

Regards,

Ken

On Sat, Apr 29, 2023 at 7:57 PM Benjamin Weintraub via Lightning-dev <lightning-dev at lists.linuxfoundation.org<mailto:lightning-dev at lists.linuxfoundation.org>> wrote:
Hi all,

I have a question about commitments. If a peer force closes a channel by sending a commitment to the blockchain, what kind of witness script is needed to redeem the `to_local` funds? (assuming the `to_self_delay` has elapsed.) It seems that the transaction described here is for cooperative closures: https://github.com/lightning/bolts/blob/c74a3bbcf890799d343c62cb05fcbcdc952a1cf3/03-transactions.md#closing-transaction. But for force closures, I would think that the txin would need to be the `to_local` txout of the commitment.

Concretely, I have commited the following transaction on a local simnet bitcoin blockchain and mined 500 blocks on top of it. I want to spend vout[2], how can I generate such a transaction?

{
"hash": "47d15337bb3c29c7c2881dd7cd912604b401ed221c66ea6f781b456d4983d451",
"size": 444,
"vsize": 279,
"weight": 1113,
"version": 2,
"locktime": 551351761,
"vin": [
{
"txid": "0248025b9447df8267d02d14c34ab9b269f52cd827132c70159a55cbf27ab3c1",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"",
"3045022100d3f52ca04d6a71587c29592931e542b16a47f3e9e577f1869b416547d00c62dd0220485da35ad31ff71b4263b1a25f0ba9f35990e1c8d5ac848365bbd588c3ce83d701",
"3044022057fc3878e17a865c12d57b7885ed48f0d6122bd9e00511c8eac150180d1508d502205fd1d0674a41b3c0118d0b6c19b1c77d35fc95bb89f929da6478f22e94dbf5ce01",
"5221038acdafe305edd06e91706ee687a091be306f0f29bcbda52dadde084bbaa36c902103d8fd53b9b43638c2255e1abd6f134a0232d2fba65527252c4eb81f926ddf50ad52ae"
],
"sequence": 2161061453
}
],
"vout": [
{
"value": 0.0000033,
"n": 0,
"scriptPubKey": {
"asm": "0 45ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"hex": "002045ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qghkgvfzrwm28qqx2vkf8swazda4j4ese5fxg7hadyjdccutf2htqysq3qz"
]
}
},
{
"value": 0.0000033,
"n": 1,
"scriptPubKey": {
"asm": "0 502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"hex": "0020502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q2q4pweztxdzg959r7kyanps67m3pqk5m0t7n7hp93m7f3wm2amksa0fysc"
]
}
},
{
"value": 0.0002,
"n": 2,
"scriptPubKey": {
"asm": "0 045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"hex": "0020045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qq3248lrcjj20zmhlfnazy8gzjns5p7mewuh0ad7c897s4swye7zsyrm5pc"
]
}
},
{
"value": 0.009761,
"n": 3,
"scriptPubKey": {
"asm": "0 2d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"hex": "00202d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q94gu5ssdpd4t2myhegnrr4esfjddjqjj2t48rua037tnv9neqshqm4z7yr"
]
}
}
],
"blockhash": "0fa78bc7e9f6e0a60be71bb5fb2eaaf42a97895bb057f09d7cbb2c49120fa61d",
"confirmations": 500,
"time": 1682451410,
"blocktime": 1682451410
}

Thanks in advance,

Ben
_______________________________________________
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

--
Ken Sedgwick
Bonsai Software, Inc.
http://www.bonsai.com/ken/
(510) 269-7334
ken at bonsai.com<mailto:ken at bonsai.com>
Public Key: http://www.bonsai.com/ken/ken.asc
GPG Fingerprint: 4695 E5B8 F781 BF85 4326 9639 BBFC E515 8602 5550

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

📅 Original date posted:2023-05-02 🗒️ Summary of this ...

2023-06-09T13:13:13Z

In reply to nevent1q…wmp4
_________________________

📅 Original date posted:2023-05-02
🗒️ Summary of this message: A user is seeking help on generating a transaction that spends the to_local and HTLC output after a force close of a channel in LND.
📝 Original message:
Thank you, Ken. I have a follow up question as well.

Context: I’m playing around with some failure scenarios in LND. Say Alice is paying Bob, before Bob is able to send the fulfillment (which includes the HTLC preimage), Alice’s node dies and becomes unreachable.

Bob has already received the commitment for the updated balance and already has the preimage, so he force closes the channel.

My understanding is that he will submit the updated commitment to the blockchain as well as the channel closing transaction (after the CSV timeout) which spends his to_local and the HTLC output.

Here is my problem. After using `lncli closechannel --force ...` , I only see the commitment transaction in the mempool, not the subsequent HTLC/to_local spend. How can I generate the transaction that spends the to_local and HTLC output? If there's a way to generate it with lnd, that would be ideal.

Thanks in advance!

Ben
________________________________
From: Ken Sedgwick <ksedgwic at bonsai.com>
Sent: Sunday, April 30, 2023 14:30
To: Benjamin Weintraub <weintraub.b at northeastern.edu>
Cc: Lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Spending `to_local` output of commitment

Ben,

The necessary witness is described here:
https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local-output

Regards,

Ken

On Sat, Apr 29, 2023 at 7:57 PM Benjamin Weintraub via Lightning-dev <lightning-dev at lists.linuxfoundation.org<mailto:lightning-dev at lists.linuxfoundation.org>> wrote:
Hi all,

I have a question about commitments. If a peer force closes a channel by sending a commitment to the blockchain, what kind of witness script is needed to redeem the `to_local` funds? (assuming the `to_self_delay` has elapsed.) It seems that the transaction described here is for cooperative closures: https://github.com/lightning/bolts/blob/c74a3bbcf890799d343c62cb05fcbcdc952a1cf3/03-transactions.md#closing-transaction. But for force closures, I would think that the txin would need to be the `to_local` txout of the commitment.

Concretely, I have commited the following transaction on a local simnet bitcoin blockchain and mined 500 blocks on top of it. I want to spend vout[2], how can I generate such a transaction?

{
"hash": "47d15337bb3c29c7c2881dd7cd912604b401ed221c66ea6f781b456d4983d451",
"size": 444,
"vsize": 279,
"weight": 1113,
"version": 2,
"locktime": 551351761,
"vin": [
{
"txid": "0248025b9447df8267d02d14c34ab9b269f52cd827132c70159a55cbf27ab3c1",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"",
"3045022100d3f52ca04d6a71587c29592931e542b16a47f3e9e577f1869b416547d00c62dd0220485da35ad31ff71b4263b1a25f0ba9f35990e1c8d5ac848365bbd588c3ce83d701",
"3044022057fc3878e17a865c12d57b7885ed48f0d6122bd9e00511c8eac150180d1508d502205fd1d0674a41b3c0118d0b6c19b1c77d35fc95bb89f929da6478f22e94dbf5ce01",
"5221038acdafe305edd06e91706ee687a091be306f0f29bcbda52dadde084bbaa36c902103d8fd53b9b43638c2255e1abd6f134a0232d2fba65527252c4eb81f926ddf50ad52ae"
],
"sequence": 2161061453
}
],
"vout": [
{
"value": 0.0000033,
"n": 0,
"scriptPubKey": {
"asm": "0 45ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"hex": "002045ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qghkgvfzrwm28qqx2vkf8swazda4j4ese5fxg7hadyjdccutf2htqysq3qz"
]
}
},
{
"value": 0.0000033,
"n": 1,
"scriptPubKey": {
"asm": "0 502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"hex": "0020502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q2q4pweztxdzg959r7kyanps67m3pqk5m0t7n7hp93m7f3wm2amksa0fysc"
]
}
},
{
"value": 0.0002,
"n": 2,
"scriptPubKey": {
"asm": "0 045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"hex": "0020045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qq3248lrcjj20zmhlfnazy8gzjns5p7mewuh0ad7c897s4swye7zsyrm5pc"
]
}
},
{
"value": 0.009761,
"n": 3,
"scriptPubKey": {
"asm": "0 2d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"hex": "00202d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q94gu5ssdpd4t2myhegnrr4esfjddjqjj2t48rua037tnv9neqshqm4z7yr"
]
}
}
],
"blockhash": "0fa78bc7e9f6e0a60be71bb5fb2eaaf42a97895bb057f09d7cbb2c49120fa61d",
"confirmations": 500,
"time": 1682451410,
"blocktime": 1682451410
}

Thanks in advance,

Ben
_______________________________________________
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

--
Ken Sedgwick
Bonsai Software, Inc.
http://www.bonsai.com/ken/
(510) 269-7334
ken at bonsai.com<mailto:ken at bonsai.com>
Public Key: http://www.bonsai.com/ken/ken.asc
GPG Fingerprint: 4695 E5B8 F781 BF85 4326 9639 BBFC E515 8602 5550

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

📅 Original date posted:2023-04-27 🗒️ Summary of this ...

2023-06-09T13:13:06Z

In reply to nevent1q…5cpq
_________________________

📅 Original date posted:2023-04-27
🗒️ Summary of this message: The author is seeking advice on witness scripts needed to redeem `to_local` funds after a peer force closes a channel. Includes a sample transaction.
📝 Original message:
Hi all,

I have a question about commitments. If a peer force closes a channel by sending a commitment to the blockchain, what kind of witness script is needed to redeem the `to_local` funds? (assuming the `to_self_delay` has elapsed.) It seems that the transaction described here is for cooperative closures: https://github.com/lightning/bolts/blob/c74a3bbcf890799d343c62cb05fcbcdc952a1cf3/03-transactions.md#closing-transaction. But for force closures, I would think that the txin would need to be the `to_local` txout of the commitment.

Concretely, I have commited the following transaction on a local simnet bitcoin blockchain and mined 500 blocks on top of it. I want to spend vout[2], how can I generate such a transaction?

{
"hash": "47d15337bb3c29c7c2881dd7cd912604b401ed221c66ea6f781b456d4983d451",
"size": 444,
"vsize": 279,
"weight": 1113,
"version": 2,
"locktime": 551351761,
"vin": [
{
"txid": "0248025b9447df8267d02d14c34ab9b269f52cd827132c70159a55cbf27ab3c1",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"",
"3045022100d3f52ca04d6a71587c29592931e542b16a47f3e9e577f1869b416547d00c62dd0220485da35ad31ff71b4263b1a25f0ba9f35990e1c8d5ac848365bbd588c3ce83d701",
"3044022057fc3878e17a865c12d57b7885ed48f0d6122bd9e00511c8eac150180d1508d502205fd1d0674a41b3c0118d0b6c19b1c77d35fc95bb89f929da6478f22e94dbf5ce01",
"5221038acdafe305edd06e91706ee687a091be306f0f29bcbda52dadde084bbaa36c902103d8fd53b9b43638c2255e1abd6f134a0232d2fba65527252c4eb81f926ddf50ad52ae"
],
"sequence": 2161061453
}
],
"vout": [
{
"value": 0.0000033,
"n": 0,
"scriptPubKey": {
"asm": "0 45ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"hex": "002045ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qghkgvfzrwm28qqx2vkf8swazda4j4ese5fxg7hadyjdccutf2htqysq3qz"
]
}
},
{
"value": 0.0000033,
"n": 1,
"scriptPubKey": {
"asm": "0 502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"hex": "0020502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q2q4pweztxdzg959r7kyanps67m3pqk5m0t7n7hp93m7f3wm2amksa0fysc"
]
}
},
{
"value": 0.0002,
"n": 2,
"scriptPubKey": {
"asm": "0 045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"hex": "0020045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qq3248lrcjj20zmhlfnazy8gzjns5p7mewuh0ad7c897s4swye7zsyrm5pc"
]
}
},
{
"value": 0.009761,
"n": 3,
"scriptPubKey": {
"asm": "0 2d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"hex": "00202d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q94gu5ssdpd4t2myhegnrr4esfjddjqjj2t48rua037tnv9neqshqm4z7yr"
]
}
}
],
"blockhash": "0fa78bc7e9f6e0a60be71bb5fb2eaaf42a97895bb057f09d7cbb2c49120fa61d",
"confirmations": 500,
"time": 1682451410,
"blocktime": 1682451410
}

Thanks in advance,

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

📅 Original date posted:2023-05-02 📝 Original message: Thank ...

2023-06-09T13:08:43Z

In reply to nevent1q…k02x
_________________________

📅 Original date posted:2023-05-02
📝 Original message:
Thank you, Ken. I have a follow up question as well.

Context: I’m playing around with some failure scenarios in LND. Say Alice is paying Bob, before Bob is able to send the fulfillment (which includes the HTLC preimage), Alice’s node dies and becomes unreachable.

Bob has already received the commitment for the updated balance and already has the preimage, so he force closes the channel.

My understanding is that he will submit the updated commitment to the blockchain as well as the channel closing transaction (after the CSV timeout) which spends his to_local and the HTLC output.

Here is my problem. After using `lncli closechannel --force ...` , I only see the commitment transaction in the mempool, not the subsequent HTLC/to_local spend. How can I generate the transaction that spends the to_local and HTLC output? If there's a way to generate it with lnd, that would be ideal.

Thanks in advance!

Ben
________________________________
From: Ken Sedgwick <ksedgwic at bonsai.com>
Sent: Sunday, April 30, 2023 14:30
To: Benjamin Weintraub <weintraub.b at northeastern.edu>
Cc: Lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Spending `to_local` output of commitment

Ben,

The necessary witness is described here:
https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local-output

Regards,

Ken

On Sat, Apr 29, 2023 at 7:57 PM Benjamin Weintraub via Lightning-dev <lightning-dev at lists.linuxfoundation.org<mailto:lightning-dev at lists.linuxfoundation.org>> wrote:
Hi all,

I have a question about commitments. If a peer force closes a channel by sending a commitment to the blockchain, what kind of witness script is needed to redeem the `to_local` funds? (assuming the `to_self_delay` has elapsed.) It seems that the transaction described here is for cooperative closures: https://github.com/lightning/bolts/blob/c74a3bbcf890799d343c62cb05fcbcdc952a1cf3/03-transactions.md#closing-transaction. But for force closures, I would think that the txin would need to be the `to_local` txout of the commitment.

Concretely, I have commited the following transaction on a local simnet bitcoin blockchain and mined 500 blocks on top of it. I want to spend vout[2], how can I generate such a transaction?

{
"hash": "47d15337bb3c29c7c2881dd7cd912604b401ed221c66ea6f781b456d4983d451",
"size": 444,
"vsize": 279,
"weight": 1113,
"version": 2,
"locktime": 551351761,
"vin": [
{
"txid": "0248025b9447df8267d02d14c34ab9b269f52cd827132c70159a55cbf27ab3c1",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"",
"3045022100d3f52ca04d6a71587c29592931e542b16a47f3e9e577f1869b416547d00c62dd0220485da35ad31ff71b4263b1a25f0ba9f35990e1c8d5ac848365bbd588c3ce83d701",
"3044022057fc3878e17a865c12d57b7885ed48f0d6122bd9e00511c8eac150180d1508d502205fd1d0674a41b3c0118d0b6c19b1c77d35fc95bb89f929da6478f22e94dbf5ce01",
"5221038acdafe305edd06e91706ee687a091be306f0f29bcbda52dadde084bbaa36c902103d8fd53b9b43638c2255e1abd6f134a0232d2fba65527252c4eb81f926ddf50ad52ae"
],
"sequence": 2161061453
}
],
"vout": [
{
"value": 0.0000033,
"n": 0,
"scriptPubKey": {
"asm": "0 45ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"hex": "002045ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qghkgvfzrwm28qqx2vkf8swazda4j4ese5fxg7hadyjdccutf2htqysq3qz"
]
}
},
{
"value": 0.0000033,
"n": 1,
"scriptPubKey": {
"asm": "0 502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"hex": "0020502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q2q4pweztxdzg959r7kyanps67m3pqk5m0t7n7hp93m7f3wm2amksa0fysc"
]
}
},
{
"value": 0.0002,
"n": 2,
"scriptPubKey": {
"asm": "0 045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"hex": "0020045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qq3248lrcjj20zmhlfnazy8gzjns5p7mewuh0ad7c897s4swye7zsyrm5pc"
]
}
},
{
"value": 0.009761,
"n": 3,
"scriptPubKey": {
"asm": "0 2d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"hex": "00202d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q94gu5ssdpd4t2myhegnrr4esfjddjqjj2t48rua037tnv9neqshqm4z7yr"
]
}
}
],
"blockhash": "0fa78bc7e9f6e0a60be71bb5fb2eaaf42a97895bb057f09d7cbb2c49120fa61d",
"confirmations": 500,
"time": 1682451410,
"blocktime": 1682451410
}

Thanks in advance,

Ben
_______________________________________________
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

--
Ken Sedgwick
Bonsai Software, Inc.
http://www.bonsai.com/ken/
(510) 269-7334
ken at bonsai.com<mailto:ken at bonsai.com>
Public Key: http://www.bonsai.com/ken/ken.asc
GPG Fingerprint: 4695 E5B8 F781 BF85 4326 9639 BBFC E515 8602 5550

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

📅 Original date posted:2023-04-27 📝 Original message: Hi ...

2023-06-09T13:08:36Z

In reply to nevent1q…chgl
_________________________

📅 Original date posted:2023-04-27
📝 Original message:
Hi all,

I have a question about commitments. If a peer force closes a channel by sending a commitment to the blockchain, what kind of witness script is needed to redeem the `to_local` funds? (assuming the `to_self_delay` has elapsed.) It seems that the transaction described here is for cooperative closures: https://github.com/lightning/bolts/blob/c74a3bbcf890799d343c62cb05fcbcdc952a1cf3/03-transactions.md#closing-transaction. But for force closures, I would think that the txin would need to be the `to_local` txout of the commitment.

Concretely, I have commited the following transaction on a local simnet bitcoin blockchain and mined 500 blocks on top of it. I want to spend vout[2], how can I generate such a transaction?

{
"hash": "47d15337bb3c29c7c2881dd7cd912604b401ed221c66ea6f781b456d4983d451",
"size": 444,
"vsize": 279,
"weight": 1113,
"version": 2,
"locktime": 551351761,
"vin": [
{
"txid": "0248025b9447df8267d02d14c34ab9b269f52cd827132c70159a55cbf27ab3c1",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"",
"3045022100d3f52ca04d6a71587c29592931e542b16a47f3e9e577f1869b416547d00c62dd0220485da35ad31ff71b4263b1a25f0ba9f35990e1c8d5ac848365bbd588c3ce83d701",
"3044022057fc3878e17a865c12d57b7885ed48f0d6122bd9e00511c8eac150180d1508d502205fd1d0674a41b3c0118d0b6c19b1c77d35fc95bb89f929da6478f22e94dbf5ce01",
"5221038acdafe305edd06e91706ee687a091be306f0f29bcbda52dadde084bbaa36c902103d8fd53b9b43638c2255e1abd6f134a0232d2fba65527252c4eb81f926ddf50ad52ae"
],
"sequence": 2161061453
}
],
"vout": [
{
"value": 0.0000033,
"n": 0,
"scriptPubKey": {
"asm": "0 45ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"hex": "002045ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qghkgvfzrwm28qqx2vkf8swazda4j4ese5fxg7hadyjdccutf2htqysq3qz"
]
}
},
{
"value": 0.0000033,
"n": 1,
"scriptPubKey": {
"asm": "0 502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"hex": "0020502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q2q4pweztxdzg959r7kyanps67m3pqk5m0t7n7hp93m7f3wm2amksa0fysc"
]
}
},
{
"value": 0.0002,
"n": 2,
"scriptPubKey": {
"asm": "0 045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"hex": "0020045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1qq3248lrcjj20zmhlfnazy8gzjns5p7mewuh0ad7c897s4swye7zsyrm5pc"
]
}
},
{
"value": 0.009761,
"n": 3,
"scriptPubKey": {
"asm": "0 2d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"hex": "00202d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"sb1q94gu5ssdpd4t2myhegnrr4esfjddjqjj2t48rua037tnv9neqshqm4z7yr"
]
}
}
],
"blockhash": "0fa78bc7e9f6e0a60be71bb5fb2eaaf42a97895bb057f09d7cbb2c49120fa61d",
"confirmations": 500,
"time": 1682451410,
"blocktime": 1682451410
}

Thanks in advance,

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

📅 Original date posted:2022-12-13 📝 Original message: Very ...

2023-06-09T13:07:46Z

In reply to nevent1q…p3th
_________________________

📅 Original date posted:2022-12-13
📝 Original message:
Very helpful, thank you for the quick reply!

Ben
________________________________
From: SomberNight <somber.night at protonmail.com>
Sent: Tuesday, December 13, 2022 10:53
To: Benjamin Weintraub <weintraub.b at northeastern.edu>
Cc: Lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Unclear HTLC scenario

Hi Ben,

This is handled earlier than update_fail_htlc: when the recipient sees the update_add_htlc, some sanity checks will fail and it won't commit it to the commitment tx.

See here:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flightning%2Fbolts%2Fblame%2Fa0bbe47b0278b4f152dbaa4f5fab2562413a217c%2F02-peer-protocol.md%23L1036&data=05%7C01%7Cweintraub.b%40northeastern.edu%7C5e9d13700f58406b671208dadd223e31%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C638065437441102846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6GUyG4x9dxZnhGZpIJY6SQBmA%2FH4%2Bcw8kkD3aQaNZ%2Bk%3D&reserved=0

> 1. type: 128 (`update_add_htlc`)
> [...]
> A receiving node:
> [...]
> - receiving an `amount_msat` that the sending node cannot afford at the current `feerate_per_kw` (while maintaining its channel reserve and any `to_local_anchor` and `to_remote_anchor` costs):
> - SHOULD send a `warning` and close the connection, or send an
`error` and fail the channel.

If the recipient decides to simply close the transport connection, the update_add_htlc message is forgotten (due to the rules of how channel_reestablish works), and the channel is back to a usable state.

ghost43

------- Original Message -------
On Tuesday, December 13th, 2022 at 2:51 PM, Benjamin Weintraub via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

> Hi list,
>
>
>
> I have a question about how update_fail_htlcs are handled. Consider this scenario: a node, potentially adversarial, forwards an HTLC along a channel that does not have the funds to support a payment of that size. How does the recipient of the HTLC respond?
>
>
>
> I see this line in BOLT #2:
>
> “until the corresponding HTLC is irrevocably committed in both sides' commitment transactions: MUST NOT send an `update_fulfill_htlc`, `update_fail_htlc`, or `update_fail_malformed_htlc`"
>
>
>
> But this seems confusing to me in the context of the scenario I suggested. Is it saying that even though the channel cannot support the payment, the nodes still need to commit to it?
>
>
>
> I assume that this interpretation is not correct, but then when is it okay for a node to send an update_fail_htlc? Immediately upon receiving an invalid transaction?
>
>
>
> Any insight you could provide would be great.
>
>
>
> Thanks in advance,
>
> Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221213/aba37c8b/attachment.html>;

📅 Original date posted:2022-12-13 📝 Original message: Hi ...

2023-06-09T13:07:45Z

In reply to nevent1q…0fmj
_________________________

📅 Original date posted:2022-12-13
📝 Original message:
Hi list,

I have a question about how update_fail_htlcs are handled. Consider this scenario: a node, potentially adversarial, forwards an HTLC along a channel that does not have the funds to support a payment of that size. How does the recipient of the HTLC respond?

I see this line in BOLT #2:

“until the corresponding HTLC is irrevocably committed in both sides' commitment transactions: MUST NOT send an update_fulfill_htlc, update_fail_htlc, or update_fail_malformed_htlc"

But this seems confusing to me in the context of the scenario I suggested. Is it saying that even though the channel cannot support the payment, the nodes still need to commit to it?

I assume that this interpretation is not correct, but then when is it okay for a node to send an update_fail_htlc? Immediately upon receiving an invalid transaction?

Any insight you could provide would be great.

Thanks in advance,

Ben

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

📅 Original date posted:2022-02-16 📝 Original message: Hi ...

2023-06-09T13:05:20Z

In reply to nevent1q…9vx7
_________________________

📅 Original date posted:2022-02-16
📝 Original message:
Hi Laolu!

Thanks for the helpful reply. A couple follow up questions:

1) Why would concurrent signatures generate additional messages? My understanding is that by the time the signatures are sent, the HTLCs are already locked in.

2) Perhaps I didn't just understand your explanation, but I still don't get why the additional `commitment_signed` and `revoke_and_ack` messages are necessary. The initial pair of `commitment_signed` and `revoke_and_ack` messages establish a new state _conditioned_ on possessing the pre-image, right? So after the pre-image is shared, then all parties have assurance of the new state and therefore _could_ go to the chain (even if they don't want to, because they want to keep the channel open). Since the new state is already guaranteed by the previous commitments and revocations, what purpose do the additional commitments and revocations provide?

Thanks again!
Ben

--
Ben Weintraub
PhD Student
Khoury College of Computer Sciences
Northeastern University
https://ben-weintraub.com/

________________________________
From: Olaoluwa Osuntokun <laolu32 at gmail.com>
Sent: Tuesday, February 15, 2022 18:13
To: Benjamin Weintraub <weintraub.b at northeastern.edu>
Cc: Lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Normal operation questions

Hi Benjamin,

> 1) Multiple sources indicate that after Alice sends the `update_add_htlc`,
> she should then send the `commitment_signed`, but why is it important that
> she sends it first (before Bob)? As far as I understand, as long as she
> doesn't revoke the old state before Bob commits to the new state, there
> shouldn't be a problem. In that case, the order wouldn't matter---they could
> even send their commitments concurrently. So does the order matter?

You're correct that it isn't absolutely necessary that she sends a new
signature after adding a new HTLC to the pending set of HTLCs. Alice may
want to delay her signature if she has other HTLCs she wants to add to the
commitment transaction, which allows her to batch/pipeline updates to the
channel.

If Alice is forwarding that HTLC, and Bob's side of the channel has been
dormant (not making many updates), then it's her best interest to propose a
new state immediately as she may generate some routing fees from a
successful forward.

Concurrent signatures aren't an issue, but will end up generating additional
state transitions for both sides to have the exact same set of locked in
HTLCs.

> 2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange
> `commitment_signed` and `revoke_and_ack` messages again. Why is this
> necessary? After Alice receives the preimage, doesn't she have enough
> information to claim her funds (with the new state)?

If Bob is sending the pre-image, then _he_ is the one that is claiming the
funds. Once Bob learns of the pre-image, he can go to chain if he wants to
in order to claim the HTLC. However that'll be a lot slower and also cost
more in chain fees than doing an update off-chain to settle the HTLC from
the PoV of the commitment transaction of both parties. Both sides exchange
those messages in order to update their commitment state _off chain_.

Once Alice receives the pre-image (assuming a multi-hop scenario), she can
opt to not wait for the full exchange, and instead _pipeline_ the pre-image
back upstream in the route. In practice, this can reduce perceived user
latency for payments, as you can side step the 1.5 RTTs at each hop in the
route, and simply sling the pre-image all the way back to the original
sender.

-- Laolu

On Tue, Feb 15, 2022 at 7:32 AM Benjamin Weintraub <weintraub.b at northeastern.edu<mailto:weintraub.b at northeastern.edu>> wrote:
Hi all,

I have a couple questions about the Normal Operation protocol. For the following, consider a single-hop payment between Alice and Bob over a single channel.

1) Multiple sources indicate that after Alice sends the `update_add_htlc`, she should then send the `commitment_signed`, but why is it important that she sends it first (before Bob)? As far as I understand, as long as she doesn't revoke the old state before Bob commits to the new state, there shouldn't be a problem. In that case, the order wouldn't matter---they could even send their commitments concurrently. So does the order matter?

2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange `commitment_signed` and `revoke_and_ack` messages again. Why is this necessary? After Alice receives the preimage, doesn't she have enough information to claim her funds (with the new state)?

Thanks!
Ben

--
Ben Weintraub
PhD Student
Khoury College of Computer Sciences
Northeastern University
https://ben-weintraub.com/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben-weintraub.com%2F&data=04%7C01%7Cweintraub.b%40northeastern.edu%7Cd033116731cd4050291708d9f0d8d9bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637805637505660537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ip73Qo2E1UUud0LxEuMVCpYJQNxYQYLB3YtW0xIrtUA%3D&reserved=0>;

_______________________________________________
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev&data=04%7C01%7Cweintraub.b%40northeastern.edu%7Cd033116731cd4050291708d9f0d8d9bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637805637505660537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=V1m2qqncyahnT7crpeYhCmgGcBjep%2Ft%2FIBnjzuDbRJk%3D&reserved=0>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220216/16cb3180/attachment.html>;

📅 Original date posted:2022-02-15 📝 Original message: Hi ...

2023-06-09T13:05:19Z

In reply to nevent1q…zw95
_________________________

📅 Original date posted:2022-02-15
📝 Original message:
Hi all,

I have a couple questions about the Normal Operation protocol. For the following, consider a single-hop payment between Alice and Bob over a single channel.

1) Multiple sources indicate that after Alice sends the `update_add_htlc`, she should then send the `commitment_signed`, but why is it important that she sends it first (before Bob)? As far as I understand, as long as she doesn't revoke the old state before Bob commits to the new state, there shouldn't be a problem. In that case, the order wouldn't matter---they could even send their commitments concurrently. So does the order matter?

2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange `commitment_signed` and `revoke_and_ack` messages again. Why is this necessary? After Alice receives the preimage, doesn't she have enough information to claim her funds (with the new state)?

Thanks!
Ben

--
Ben Weintraub
PhD Student
Khoury College of Computer Sciences
Northeastern University
https://ben-weintraub.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220215/ea3c951b/attachment.html>;

📅 Original date posted:2021-12-09 📝 Original message: Hi ...

2023-06-09T13:04:45Z

In reply to nevent1q…nvj0
_________________________

📅 Original date posted:2021-12-09
📝 Original message:
Hi all,

I have a question about BOLT #2. What exactly does it mean to "fail the channel"? In the section for "update_add_htlc," the follwing text is written:

* receiving an amount_msat equal to 0, OR less than its own htlc_minimum_msat:
* SHOULD fail the channel.
* receiving an amount_msat that the sending node cannot afford at the current feerate_per_kw (while maintaining its channel reserve and any to_local_anchor and to_remote_anchor costs):
* SHOULD fail the channel.
* if a sending node adds more than receiver max_accepted_htlcs HTLCs to its local commitment transaction, OR adds more than receiver max_htlc_value_in_flight_msat worth of offered HTLCs to its local commitment transaction:
* SHOULD fail the channel.
* if sending node sets cltv_expiry to greater or equal to 500000000:
* SHOULD fail the channel.

Does it mean closing the channel (unilaterally or mutually)? Or ending the TCP connection? Something else?

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/b7241bfc/attachment-0001.html>;