[Lightning-dev] eltoo Trustless WatchTowers

Olaoluwa Osuntokun laolu32 at gmail.com
Wed May 9 22:51:55 UTC 2018


> However, this has the drawback that each update of a single channel will
> generate a `(txid[:16], blob)` pair that has the same `txid[:16]` key,
> letting the WatchTower correlate the timing and number of updates of each
of
> your channels.

On the other hand, going with the "swap this blob" approach is much, much
more scalable as each client of the watchtower only consumes a bounded
(could say constant) amount of space. If you pad out the blob to the max
size accounting for HTLC limits (which further obfuscates the details of the
update), then watchtowers can easily plan out the storage requirements as a
function of the number of open clients.

In order to mitigate the timing leaks, clients don't need to _immediately_
update their blob. Instead, they can add a level of randomization via a
timer drawn from a particular distribution. The downside of this is that
there's a window of opportunity wherein a new state is at play, yet the
watch tower hasn't yet been updated. Even with asymmetric commitments, one
would still want to introduce such randomization in order to de-correlate
their updates (and also batch several updates into a single message).

> It seems desirable to at least retain the property that the WatchTower
> cannot correlate our updates to our channels.

Is the scalability tradeoff worth it though?

> since only the latest update transaction is valid

All update transactions are valid, just some are more valid than others ;)

> Under Poon-Dryja, if I have watching service contracts from several
> WatchTowers, when I get another revocation, I can distribute the
revocation
> data to a subset of all my serving WatchTowers; under
> Decker-Russell-Osuntokun I would have to contact all of them to give the
> latest update transaction.

Not necessarily. Due to the nature of the update transactions, several
watchtowers could even progressively advance the update transaction towards
the final most up to date state. Your constraint of "i need to update them
all each time" seems arbitrary and isn't inherent to either of the schemes.

--Laolu


On Wed, May 2, 2018 at 3:43 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning list,
>
> I started considering, what a trustless, blinded WatchTower for eltoo
> channels would look like.  Unfortunately, I cannot derive a good one yet,
> sorry.
>
> My basis, is the same "encrypted blob" we use for Poon-Dryja channels.
>
> Now an issue is that update transactions in Decker-Russell-Osuntokun
> channels have no txid that can be used as key for the encrypted blob.
>
> One thing we can use is the trigger transaction, which has a stable txid
> since its sole input is an ordinary 2-of-2 that is signed with normal
> `SIGHASH_ALL`.
>
> However, this has the drawback that each update of a single channel will
> generate a `(txid[:16], blob)` pair that has the same `txid[:16]` key,
> letting the WatchTower correlate the timing and number of updates of each
> of your channels.  Compare to the case where a Poon-Dryja uses the same
> encoding: the WatchTower knows each `(txid[:16], blob)` pair is *some*
> update to *one* of your channels, but cannot know if any two pairs you
> submit are for the same channel or two different channels.  Indeed even if
> a theft attempt occurs the WatchTower can only know that some `txid[:16]`
> belongs to a particular channel, but not whether the other `txid[:16]` you
> published to it are to the same channel, or another channel you happen to
> be interested in.
>
> It seems desirable to at least retain the property that the WatchTower
> cannot correlate our updates to our channels.
>
> Another property that the Poon-Dryja encrypted-blob has is that we can
> distribute our updates for a single channel to two or more WatchTowers, to
> improve our privacy slightly (if we can somehow identify that two different
> WatchTowers are not somehow comparing notes; but simple use of Tor and
> similar can obscure that the same node is the source of communications).
> It also seems desirable to retain this property, but under
> Decker-Russell-Osuntokun channels, when a new update is made, every
> WatchTower who is watching should be informed of that update (since only
> the latest update transaction is valid).  Under Poon-Dryja, if I have
> watching service contracts from several WatchTowers, when I get another
> revocation, I can distribute the revocation data to a subset of all my
> serving WatchTowers; under Decker-Russell-Osuntokun I would have to contact
> all of them to give the latest update transaction.
>
> ---
>
> So let me propose my half-baked idea for encrypted-blob, slightly-blinded
> Decker-Russell-Osuntokun WatchTowers:
>
> 1.  We observe that for each update transaction, the signatures are
> malleable (sign malleability, also one signature is from the attacker and
> the attacker can pick a new R), but the message they are signing (a copy of
> the transaction that has been modified in particular ways) is not.
> 2.  We observe that under SegWit the txid is simply an unusual form of the
> hash of the message (transaction) that is getting signed under a
> `SIGHASH_ALL` signature.  Thus if `txid[:16]` is acceptable as a key, then
> `hash[:16]` of the message signed in the update transactions should also be
> acceptable.
> 3.  Thus we generalize our WatchTowers pairs to `(hash[:16], blob)`, where
> `hash` is the message that is signed in the witness program, not just the
> `txid`.
> 4.  The same framework can be used for Poon-Dryja and
> Decker-Russell-Osuntokun WatchTowers.  Under Poon-Dryja the `hash` is the
> reverse of the `txid` (or rather, the `txid` is properly the reverse of the
> hash) being watched for.
> 5.  The main loop of the WatchTower (which can watch either Poon-Dryja or
> Decker-Russell-Osuntokun channels) is now something like: When a block
> comes in, verify each transaction.  If during signature validation, we
> match the hash of the message being signed to a watched blob `hash[:16]`,
> we decrypt the blob and proceed to justice depending on the type of the
> decrypted blob.
> 6.  Notice an important point: the same WatchTower, if it supported both
> Poon-Dryja and Decker-Russell-Osuntokun channels, would not know if a
> `(hash[:16], blob)` pair even belongs to a Poon-Dryja or a
> Decker-Russell-Osuntokun channel, unless a theft attempt was made! This is
> important as it lets us retain high anonymity sets while transitioning the
> network from Poon-Dryja to Decker-Russell-Osuntokun.
> 7.  We handle Poon-Dryja channel blobs as with current Poon-Dryja
> techniques that I ahd Connor described last month.
> 8.  For Decker-Russell-Osuntokun channels, the blob would contain: state
> number (`nLockTime`), `Au` and `Bu` pubkeys, the basepoints for `As,i` and
> `Bs,i`, and the corresponding signatures for the update transaction, the
> corresponding settlement transaction, and the settlement details (how much
> value each side, HTLCs in flight, CSV-delta, etc) as well as how the
> WatchTower bounty gets paid out.
> 9.  The blob does not contain the latest channel update!  Instead, the
> WatchTower would iterate the state number repeatedly, and generate each
> possible future update transaction (without signatures).  This is because
> the message commits to constant data, an `nLockTime` we are iterating, a
> satoshi amount that is the same since update transactions pay no fees from
> the funding transaction, and a P2WSH that is derivable completely from
> `Au`, `Bu`, `As,i` and `Bs,i` basepoints, the current `nLockTime`, and the
> CSV-delta setting.  This yields new messages that are hashed and compared
> to other `hash[:16]` the WatchTower has.  If it matches another one, the
> WatchTower knows that at least one future update transaction exists: the
> WatchTower simply iterates until it finds the last channel update or
> reaches the maximum state number.
> 10.  When the WatchTower finds the last channel update for the channel,
> and it is different from the message that triggered us, then it knows that
> the current published update transaction is not the latest, it knows the
> latest update, and it can now publish the latest update transaction and
> eventually its corresponding settlement transaction, in order to provide
> justice.
>
> The above retains the decorrelation property (the WatchTower, given two
> `(hash[:16], blob)` pairs, cannot know if the two pairs refer to the same
> channel, or different channels), but only up to a theft attempt.  If a
> theft attempt occurs, then the WatchTower can now correlate the blobs (it
> might have kept records of when the blobs were given to it, and the
> decrypted blobs certainly give it history of how much money was allocated
> to both sides of the channel at that time) to a specific channel; hopefully
> theft attempts are rare enough that this is an acceptable amount of lost
> privacy.  If a node is served by many WatchTowers, it might elect to not
> give all updates to a single WatchTower (to reduce the privacy leakage in
> case of a theft attempt), so the WatchTower should also be prepared in that
> its latest known update might not actually be the latest.
>
> it also requires quite a bit of grinding on the WatchTower, as it has to
> generate a large number (possibly up to a billion) of possible future
> update transactions.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180509/8d8029a6/attachment.html>


More information about the Lightning-dev mailing list