[Lightning-dev] Trustless WatchTowers?
conner at lightning.engineering
Tue Apr 17 09:07:22 UTC 2018
The ability for a watchtower to spend them independently seems to resolve
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
> > developers: this seems to require a bit of surgery on our code I think
> > (currently construction of justice transactions is done in a separate
> > and we always generate a justice transaction that claims all claimable
> > of the revoked commitment transaction), and we might decide to defer this
> > feature for later (leaking revocation basepoint secret is easy and
> > 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
> in which the second-level txns have already been spent, and then forgo
> them entirely (on the assumption that it has already been done by a
> > 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
> outputs when batched, they can choose other sets that the watchtower can't
> on. Spending them independently seems to resolve this.
> 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
>> > 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
>> like to address before formalizing everything. I am working to have
>> written up in the short-term documenting the approach[es] that ends up
>> solidified. Hopefully that can get some eyes during development, and
>> 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
>> > 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
>> arbitrary delays. This is particularly true if the CLTVs have already
>> 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
>> another second-level txn.
>> Since the CSVs begin ticking as soon as they are included in the chain,
>> 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
>> have no way to intercept this behavior, and prevent the breacher from
>> 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
>> outpoints in case the commitment txn is broadcasted before the CLTVs
>> You could try to batch these with the HTLCs, but then we get back into
>> exponential territory.
>> > Is that approximately what is needed? Have I missed anything?
>> Nope, I think your understanding is on point. IMO this seems to be a
>> compromise of the tradeoffs at hand, and definitely something that could
>> as an initial iteration due to its simplicity. In the future, there are definitely
>> 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
>> thoughts on this, thank you for your responses!
>> Thank you for this confirmation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lightning-dev