Conner Fromknecht [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-17 📝 Original message: The ability for a ...
📅 Original date posted:2018-04-17
📝 Original message:
The ability for a watchtower to spend them independently seems to resolve
this*
On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht
<conner at lightning.engineering> wrote:
> 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/ba5d4ec3/attachment.html>;
📝 Original message:
The ability for a watchtower to spend them independently seems to resolve
this*
On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht
<conner at lightning.engineering> wrote:
> 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/ba5d4ec3/attachment.html>;