Conner Fromknecht [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-17 📝 Original message: Hi ZmnSCPxj, > I ...
📅 Original date posted:2018-04-17
📝 Original message:
Hi ZmnSCPxj,
> 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).
Certainly, it will require changes to ours as well. Would also love to hear
what the
other implementations think of such a proposal. As of now, we detect if the
commitment outputs have been spent, and if so, attempt to spend an
aggregate of
the commitment outputs and second-level outputs conditioned on which are
reported as spent. To realize this fully, we would need to also detect the
case
in which the second-level txns have already been spent, and then forgo
sweeping
them entirely (on the assumption that it has already been done by a
watchtower).
> 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.
Precisely, if the attacker knows that we can only sweep a particular sets of
outputs when batched, they can choose other sets that the watchtower can't
act
on. Spending them independently seems to resolve this.
-Conner
On Tue, Apr 17, 2018 at 8:02 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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 HTLC txns can be separated by
> arbitrary 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 single
> second-level txn, waits for confirmation and CSV to expire, then repeat
> with
> another 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
> sweeping
> individual 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 HTLC
> outpoints 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 into
> exponential 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
> serve
> as 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
> your
> thoughts 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/466f490f/attachment-0001.html>;
📝 Original message:
Hi ZmnSCPxj,
> 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).
Certainly, it will require changes to ours as well. Would also love to hear
what the
other implementations think of such a proposal. As of now, we detect if the
commitment outputs have been spent, and if so, attempt to spend an
aggregate of
the commitment outputs and second-level outputs conditioned on which are
reported as spent. To realize this fully, we would need to also detect the
case
in which the second-level txns have already been spent, and then forgo
sweeping
them entirely (on the assumption that it has already been done by a
watchtower).
> 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.
Precisely, if the attacker knows that we can only sweep a particular sets of
outputs when batched, they can choose other sets that the watchtower can't
act
on. Spending them independently seems to resolve this.
-Conner
On Tue, Apr 17, 2018 at 8:02 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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 HTLC txns can be separated by
> arbitrary 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 single
> second-level txn, waits for confirmation and CSV to expire, then repeat
> with
> another 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
> sweeping
> individual 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 HTLC
> outpoints 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 into
> exponential 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
> serve
> as 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
> your
> thoughts 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/466f490f/attachment-0001.html>;