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

Reply via email to