From conner at lightning.engineering Tue Apr 17 04:28:35 2018 From: conner at lightning.engineering (Conner Fromknecht) Date: Tue, 17 Apr 2018 04:28:35 +0000 Subject: [Lightning-dev] Trustless WatchTowers? In-Reply-To: References: Message-ID: 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). > 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. There are more complex proposals discussed allowing an encrypted blob to reference data stored in a prior encrypted blob. Primary advantage would be reducing the storage costs of HTLCs present on multiple successive commitment transactions; primary disadvantage is that it's significantly more complex, in addition to the other points brought up by Laolu. I'm not positive as to the extent this approach was implemented/fleshed out, or if any other pros/cons may have been realized in the process. I haven't done nearly as much research as Tadge on that front, he's probably got some extensive thoughts on the tradeoffs. ======= 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 by the number of HTLC signatures included in the encrypted blob. Due to independence of the second stage transactions, there is a combinatoric blowup in the number of signatures that would need to be pre-signed under the revocation private 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. 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_ be broadcast 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 commitment HLTC outputs at that time. So, we can save on signature data by only requiring the watchtower to act if second stage transactions are confirmed. One reallyyy nice thing about not having the watchtower sweep the HTLC outputs on the commitment txn directly is that it doesn't need to know how to reconstruct the more complex HTLC redeem scripts. It only needs to reconstruct commitment 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. 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, the watchtower needs to sweep the HTLCs iteratively to prevent the attacker from sweeping any of the outputs as the relative timelocks expire. One minimal solution could be to send signatures for independent sweep transactions, allowing the watchtower to sweep each HTLC output individually. This is nice because it permits the watchtower to sweep exactly the subset of HTLCs that ever transition into the second stage, and under any permutation wrt. ordering of confirmed second stage transactions. With the single transaction per HTLC approach, the total number of signatures that are sent to the watchtower remains linear in the number HTLCs on the commitment transaction. This approach does have the downside of consuming slightly more fees, since each output is swept with a distinct transaction. However, this approach is fairly efficient in preventing the attacker entirely from moving funds from the channel into their wallet wrt. to the amount of data stored. Considering that the majority of the channel balance is expected to be in the commitment outputs and that hypothetically on-chains fees are offset by the remote balance, this could be an acceptable tradeoff. I suspect that in practice, most second stage transactions will be valid by the time an attacker would drop to chain. Because of this, it's possible that they could be mined in the same block as the breach transaction. If everything is mined in the same block or in quick succession, it might be worthwhile to also pre-sign a justice txn that batch sweeps all HTLCs directly from the second layer, requiring one additional signature/HTLC. This could be a plausible scenario if the offender breached unintentionally, and their implementation tries to proceed normally. However it does require all of the CSV delays to conincide. If that doesn't happen, the watchtower can always resort to sweeping the outputs individually. All in all, I think the ability to sweep each HTLC independently is more-or-less a requirement just given the complexity of how the on-chain state-space can manifest, especially if CLTVs have already expired. Other scenarios may be worth including on a case by case basis or if we feel they are justified. This could be handled dynamically by including some bitvector or some compact representation of how to reconstruct the transactions for any additional, included signatures. TL;DR: We can get away with just sweeping the second stage outputs. Sweeping each in a distinct txn avoids combinatoric blowup of trying to batch the sweeps. The storage is linear in the number of HTLC outputs, and also reduces the data required to reconstruct the individual redeem scripts. Any feedback or additional insights would be greatly appreciated! Let me know if I've overlooked anything critical :) Cheers, Conner [1] https://lists.linuxfoundation.org/pipermail/lightning-dev /2016-August/000565.html On Mon, Apr 16, 2018 at 11:30 PM ZmnSCPxj via Lightning-dev < lightning-dev at lists.linuxfoundation.org> wrote: > Good morning Laolu, > > > Hi ZmnSCPxj, > > > It seems to me, that the only safe way to implement a trustless > WatchTower, > > is for the node to generate a fully-signed justice transaction, > IMMEDIATELY > > after every commitment transaction is revoked, and transmit it to the > > WatchTower. > > No, one doesn't need to transmit the entire justice transaction. Instead, > the client simply sends out the latest items in the script template, and a > series of _signatures_ for the various breach outputs. The pre-generated > signature means that the server is *forced* to reproduce the justice > transaction that satisfies the latest template and signature. Upfront, free > parameters such as breach bonus (or w/e else) can be negotiated. > > > Thank you, I understand. > > As a result of these downside, our current implementation goes back to the > ol' "encrypted blob" approach. One immediate benefit with this approach is > that the outsourcing protocol isn't so coupled with the current _commitment > protocol_. Instead, the internal payload can be typed, allowing the server > to dispatch the proper breach protocol based on the commitment type. The > blob approach can also support a "swap" protocol which is required for > commitment designs that allow for O(1) outsourcer state per-client, like > the > scheme I presented at the last Scaling Bitcoin. > > > Can you describe the "encrypted blob" approach to me? Or point me to > materials? > > I imagine that in this case, the protected node hands a (txid, blob) pair > to the WatchTower. If the WatchTower sees a transaction that matches the > given txid, it gets some information from the actual transaction to decrypt > the blob (e.g. use the encrypted commitment index in `nLockTime` and > `nSequence` as a decryption key); the blob is the justice transaction (or > just a template type and its signatures as you describe above). > > Do you have a description of the WatchTower protocol used in lnd? It may > be useful to be intercompatible. > > 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: