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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
