Re: [Lightning-dev] Trustless WatchTowers?

[Conner Fromknecht]

The ability for a watchtower to spend them independently seems to resolve
this*
On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht
 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  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 

Re: [Lightning-dev] Trustless WatchTowers?

[Conner Fromknecht]

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  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
>

Re: [Lightning-dev] Trustless WatchTowers?

[Conner Fromknecht]

Good evening ZmnSCPxj,

> Also, thank you for the link.

Definitely! I had to do some digging myself to recover these hidden gems.

> 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.

> 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.

> When the commitment txid is found onchain, the WatchTower creates a single
> main output claim transaction using the 1 or 2 signatures for the main
> outputs.  And for each HTLC outpoint on the commitment transaction, if it
gets
> spent, the WatchTower creates one HTLC justice transaction from the
> second-stage HTLC transaction.

Yes, this is how it would work in context of what I was suggesting.
Certainly,
there are other ways to accomplish the same thing. I don't wish to claim
that
this is the best solution available, there are a lot of tradeoffs that need
to be evaluated. I'm hoping that you and others can bring any shortcomings
to
light and help us sift through them.

> 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.

> 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!

Best,
Conner

On Tue, Apr 17, 2018 at 6:14 AM ZmnSCPxj  wrote:

> Good morning Conner,
>
>
>
>
> Hi ZmnSCPxj,
> > Can you describe the "encrypted blob" approach to me? Or point me to
> > materials?
>
> There's an awesome watchtower thread on the mailing list from 2016 that
> starts
> here [1]. It covers a broader range of possibilities than just the
> encrypted
> blob approach, and also considers other revocation schemes, e.g. elkrem.
>
> Similar to what you described, one encrypted blob approached discussed in
> that thread is:
> 1. hint = tixd[:16]
> 2. blob = Enc(data, txid[16:])
> 3. Send (hint, blob) to watchtower.
>
> Whenever a new block is mined, the watchtower checks if it has an entry
> for each
> txid[:16]. If so, it decrypts using txid[16:], assembles the justice txn,
> and
> broadcasts (assuming the reward output matches what was negotiated).
>
>
> Thank you, that is indeed similar to what I was thinking given the name
> "encrypted blob".
>
> Also, thank you for the link. I have not had much time to back-read
> anything older than 2017 in the archives. I observe that neither Poon nor
> Dryja seem to strongly participate in this list from 2017 onwards.
>
>
>
> > Do you have a description of the WatchTower protocol used in lnd? It
> may be
> > useful to be intercompatible.
> We don't have anything written up formally, though what we have currently
> operates on the design above.
>
>
> I understand. It would be good to know what you have, and perhaps consider
> planning a new BOLT document for such.
>
> Nicolas Dorier mentioned plans for BTCPay to somehow host "merchant
> support networks" where merchants may expose WatchTower endpoints, which
> other merchants may post revocation information for their channels to.
>
>
>
> I'll also take this time to brain dump some recent investigations I've
> been doing on
>
>
>
> watchtowers. TL;DR @ fin.
>
>
>
> 

Re: [Lightning-dev] Trustless WatchTowers?

[ZmnSCPxj via Lightning-dev]

Good morning Conner,

> Hi ZmnSCPxj,
>
>> Can you describe the "encrypted blob" approach to me? Or point me to
>> materials?
>
> There's an awesome watchtower thread on the mailing list from 2016 that starts
> here [1]. It covers a broader range of possibilities than just the encrypted
> blob approach, and also considers other revocation schemes, e.g. elkrem.
>
> Similar to what you described, one encrypted blob approached discussed in
> that thread is:1. hint = tixd[:16]2. blob = Enc(data, txid[16:])3. Send 
> (hint, blob) to watchtower.
>
> Whenever a new block is mined, the watchtower checks if it has an entry for 
> each
> txid[:16]. If so, it decrypts using txid[16:], assembles the justice txn, 
> andbroadcasts (assuming the reward output matches what was negotiated).

Thank you, that is indeed similar to what I was thinking given the name 
"encrypted blob".

Also, thank you for the link. I have not had much time to back-read anything 
older than 2017 in the archives. I observe that neither Poon nor Dryja seem to 
strongly participate in this list from 2017 onwards.

>> Do you have a description of the WatchTower protocol used in lnd? It may be> 
>> useful to be intercompatible.
> We don't have anything written up formally, though what we have currently
> operates on the design above.

I understand. It would be good to know what you have, and perhaps consider 
planning a new BOLT document for such.

Nicolas Dorier mentioned plans for BTCPay to somehow host "merchant support 
networks" where merchants may expose WatchTower endpoints, which other 
merchants may post revocation information for their channels to.

> I'll also take this time to brain dump some recent investigations I've been 
> doing on
>
> watchtowers. TL;DR @ fin.
>
> FWIW, I've been thinking about this in the context of the simple encrypted
> blob approach, though the observations can generalize to other schemes.
>
> As Laolu mentioned, the storage requirement for the watchtower is dominated 
> bythe number of HTLC signatures included in the encrypted blob. Due 
> toindependence of the second stage transactions, there is a combinatoric 
> blowup inthe number of signatures that would need to be pre-signed under the 
> revocationprivate key _if sweeping of HTLC outputs is batched_.
>
> If we want to batch sweep without more liberal sighash flags, I think we'd 
> need to
> pre-sign n*2^n signatures. There are 2^n possible ways that n HTLCs can 
> straddle
> the first and second stages, and each permutation would require n distinct 
> signatures
> since the set of inputs is unique to each permutation. Needless to say, this 
> isn't feasible
> with the maximum number of HTLCs allowed in the protocol.

Yes, I thought this too.

> However, I have some observations that might inform an efficient set of
> signatures we can choose to include in the encrypted blobs.
>
> The first is that the HTLC timeout or HTLC success transaction _must_ 
> bebroadcast before the attacker can move funds back into their wallet. If
> these transactions are never mined, it is actually fine to do nothing and 
> leave
> those outputs in the breached state.
>
> If/when the victim comes back online, they themselves can sign and broadcast
> a justice transaction that executes the revocation clause of either the 
> offered or
> received HTLC scripts, based on the observed spentness of the various 
> commitmentHLTC outputs at that time. So, we can save on signature data by 
> only requiring thewatchtower to act if second stage transactions are 
> confirmed.

This is a good observation!  I initially thought that we would have to provide 
both the first-stage and second-stage revocation signatures.

> One reallyyy nice thing about not having the watchtower sweep the HTLC 
> outputson the commitment txn directly is that it doesn't need to know how 
> toreconstruct the more complex HTLC redeem scripts. It only needs to 
> reconstructcommitment to-local and second-stage to-local scripts and 
> witnesses. This means
> the blob primarily contains:
>  - 1 revocation pubkey
>  - 1 local delay pubkey
>  - 1 CSV delay
>  - 2 commitment signatures - n HTLC signatures
> and we don't have to bother sending CLTVs, local/remote htlc pubkeys, or 
> payment hashes at all.
>
> The storage for this ends up being something like ~100 + 64*(2+nhtlcs) when 
> you
> include other things like the sweep address.

Thank you, that seems like a start at something that can be implemented.

> The second observation is that the second stage transactions could be 
> broadcast
> sequentially such that the CSV delays don't overlap at all. In this event, 
> thewatchtower needs to sweep the HTLCs iteratively to prevent the attacker 
> from
> sweeping any of the outputs as the relative timelocks expire.

Sorry, I seem confused this idea.  Can you give example for commitment with 2x 
HTLC?

> One minimal solution could be to send signatures for independent sweep
> transactions, allowing the watchtower to sweep