📅 Original date posted:2018-04-17
📝 Original message:
Good morning Conner,
>> I understand. It would be good to know what you have, and perhaps consider
>> planning a new BOLT document for such.
> Yes, that is the ultimate goal. I think it might be a little to soon to have a
> full-on BOLT spec. There are still some implementation details that we would
> like to address before formalizing everything. I am working to have something
> written up in the short-term documenting the approach[es] that ends up being
> solidified. Hopefully that can get some eyes during development, and perhaps
> serve as working document/rough draft.
I understand. For myself, I will also wait for comment from other c-lightning developers: this seems to require a bit of surgery on our code I think (currently construction of justice transactions is done in a separate process, and we always generate a justice transaction that claims all claimable outputs of the revoked commitment transaction), and we might decide to defer this feature for later (leaking revocation basepoint secret is easy and requires maybe a few dozen sloc, but that requires a trusted WatchTower).
>> Sorry, I seem confused this idea. Can you give example for commitment with 2x
>> HTLC?
> Sure thing! The confirmation of second level HTLCtxns can be separated byarbitrary delays. This is particularly true if the CLTVs have already expired,offering an attacker total control over when the txns appear on the network. One way this can happen is if the attacker iteratively broadcasts a singlesecond-level txn, waits for confirmation and CSV to expire, then repeat withanother second-level txn.
> Since the CSVs begin ticking as soon as they are included in the chain, the attacker could try to sweep each one immediately after its CSV expires. If the watchtower doesn't have the ability to sweep outputs independently, it would
> have no way to intercept this behavior, and prevent the breacher from sweepingindividual HTLCs sequentially.
Ah, I thought you wanted to impose some kind of contract on HTLC-timeout/HTLC-success to enforce this behavior, you are referring to a technique that the attacker might attempt to use if we use only a single justice transaction that claims all HTLC outputs.
>> 5. 0 or 1 or 2 signatures for the main outputs. These sign a single
>> transaction that claims only the main outputs.
>
> Yes, it seems necessary to separate the commitment outpoints from the HTLCoutpoints in case the commitment txn is broadcasted before the CLTVs expire.You could try to batch these with the HTLCs, but then we get back intoexponential territory.
Agreed.
>> Is that approximately what is needed? Have I missed anything?
>
> Nope, I think your understanding is on point. IMO this seems to be a reasonable
> compromise of the tradeoffs at hand, and definitely something that could serveas an initial iteration due to its simplicity. In the future, there are definitely ways
> to improve on this on make it even more efficient! Though having a solid/workable v0 is important if it is to be deployed. I enjoy hearing yourthoughts on this, thank you for your responses!
Thank you for this confirmation.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/d82214af/attachment.html>;
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:50:10
in reply to nevent1q…nv6x
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:50:10Event JSON
{
"id": "73b70afb1429a1a3f7afe5b12536c833ee76e8245aa6b91521b17e0da36e06f7",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315010,
"kind": 1,
"tags": [
[
"e",
"6dd96ef1f5459831b29122e2c31121736b8e8107366862ff1c3ad1cf0ba80839",
"",
"root"
],
[
"e",
"2725076771c60a26fe0700bf3ff167fef626585deda5c2f76deefc6e797b14df",
"",
"reply"
],
[
"p",
"175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246"
]
],
"content": "📅 Original date posted:2018-04-17\n📝 Original message:\nGood morning Conner,\n\n\u003e\u003e I understand. It would be good to know what you have, and perhaps consider\n\u003e\u003e planning a new BOLT document for such.\n\u003e Yes, that is the ultimate goal. I think it might be a little to soon to have a\n\u003e full-on BOLT spec. There are still some implementation details that we would\n\u003e like to address before formalizing everything. I am working to have something\n\u003e written up in the short-term documenting the approach[es] that ends up being\n\u003e solidified. Hopefully that can get some eyes during development, and perhaps\n\u003e serve as working document/rough draft.\n\nI understand. For myself, I will also wait for comment from other c-lightning developers: this seems to require a bit of surgery on our code I think (currently construction of justice transactions is done in a separate process, and we always generate a justice transaction that claims all claimable outputs of the revoked commitment transaction), and we might decide to defer this feature for later (leaking revocation basepoint secret is easy and requires maybe a few dozen sloc, but that requires a trusted WatchTower).\n\n\u003e\u003e Sorry, I seem confused this idea. Can you give example for commitment with 2x\n\u003e\u003e HTLC?\n\u003e Sure thing! The confirmation of second level HTLCtxns can be separated byarbitrary delays. This is particularly true if the CLTVs have already expired,offering an attacker total control over when the txns appear on the network. One way this can happen is if the attacker iteratively broadcasts a singlesecond-level txn, waits for confirmation and CSV to expire, then repeat withanother second-level txn.\n\u003e Since the CSVs begin ticking as soon as they are included in the chain, the attacker could try to sweep each one immediately after its CSV expires. If the watchtower doesn't have the ability to sweep outputs independently, it would\n\u003e have no way to intercept this behavior, and prevent the breacher from sweepingindividual HTLCs sequentially.\n\nAh, I thought you wanted to impose some kind of contract on HTLC-timeout/HTLC-success to enforce this behavior, you are referring to a technique that the attacker might attempt to use if we use only a single justice transaction that claims all HTLC outputs.\n\n\u003e\u003e 5. 0 or 1 or 2 signatures for the main outputs. These sign a single\n\u003e\u003e transaction that claims only the main outputs.\n\u003e\n\u003e Yes, it seems necessary to separate the commitment outpoints from the HTLCoutpoints in case the commitment txn is broadcasted before the CLTVs expire.You could try to batch these with the HTLCs, but then we get back intoexponential territory.\n\nAgreed.\n\n\u003e\u003e Is that approximately what is needed? Have I missed anything?\n\u003e\n\u003e Nope, I think your understanding is on point. IMO this seems to be a reasonable\n\u003e compromise of the tradeoffs at hand, and definitely something that could serveas an initial iteration due to its simplicity. In the future, there are definitely ways\n\u003e to improve on this on make it even more efficient! Though having a solid/workable v0 is important if it is to be deployed. I enjoy hearing yourthoughts on this, thank you for your responses!\n\nThank you for this confirmation.\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/d82214af/attachment.html\u003e",
"sig": "fedd542ac717de1632cad8ebbbe248cdb5b390eb92ba3768cfb5f5b50cb063bd02c4fcee70ea2406c2a71b6ba7622d1fc5193c5cb0d147195655c89582c2f7c0"
}