ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-17 📝 Original message: Good morning Conner, >> I ...
📅 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>;
📝 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>;