[Lightning-dev] eltoo Trustless WatchTowers

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed May 2 10:43:22 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180502/6347b578/attachment-0001.html>


More information about the Lightning-dev mailing list