<div dir="ltr">
<p class="inbox-inbox-p1"><span class="inbox-inbox-s1">Good evening </span><span class="inbox-inbox-s2">ZmnSCPxj</span><span class="inbox-inbox-s1">,<br></span><br>> Also, thank you for the link.<br><br>Definitely! I had to do some digging myself to recover these hidden gems.<br><br>> I understand. It would be good to know what you have, and perhaps consider<br><span class="inbox-inbox-s1">> planning a new BOLT document for </span><span class="inbox-inbox-s2">such.<br></span><br>Yes, that is the ultimate goal. I think it might be a little to soon to have a<br>full-on BOLT spec. There are still some implementation details that we would<br>like to address before formalizing everything. I am working to have something<br>written up in the short-term documenting the approach[es] that ends up being<br>solidified. Hopefully that can get some eyes during development, and perhaps<br>serve as working document/rough draft.<br><br>> Sorry, I seem confused this idea.<span class="inbox-inbox-Apple-converted-space"> </span>Can you give example for commitment with 2x<br><span class="inbox-inbox-s1">> </span><span class="inbox-inbox-s2">HTLC</span><span class="inbox-inbox-s1">?<br></span><span class="inbox-inbox-s1"><br>Sure thing! The confirmation of second level </span><span class="inbox-inbox-s2">HTLC</span><span class="inbox-inbox-s1"> </span><span class="inbox-inbox-s2">txns</span><span class="inbox-inbox-s1"> can be separated by<br></span><span class="inbox-inbox-s1">arbitrary delays. This is particularly true if the </span><span class="inbox-inbox-s2">CLTVs</span><span class="inbox-inbox-s1"> have already expired,<br></span><span class="inbox-inbox-s1">offering an attacker total control over when the </span><span class="inbox-inbox-s2">txns</span><span class="inbox-inbox-s1"> appear on the network. One<span class="inbox-inbox-Apple-converted-space"> <br></span></span><span class="inbox-inbox-s1">way this can happen is if the attacker </span><span class="inbox-inbox-s2">iteratively</span><span class="inbox-inbox-s1"> broadcasts a single<br></span><span class="inbox-inbox-s1">second-level </span><span class="inbox-inbox-s2">txn</span><span class="inbox-inbox-s1">, waits for confirmation and </span><span class="inbox-inbox-s2">CSV</span><span class="inbox-inbox-s1"> to expire, then repeat with<br></span><span class="inbox-inbox-s1">another second-level </span><span class="inbox-inbox-s2">txn</span><span class="inbox-inbox-s1">.<br></span><span class="inbox-inbox-s1"><br>Since the </span><span class="inbox-inbox-s2">CSVs</span><span class="inbox-inbox-s1"> begin ticking as soon as they are included in the chain, the<span class="inbox-inbox-Apple-converted-space"> <br></span></span><span class="inbox-inbox-s1">attacker could try to sweep each one immediately after its </span><span class="inbox-inbox-s2">CSV</span><span class="inbox-inbox-s1"> expires. If the<span class="inbox-inbox-Apple-converted-space"> <br></span></span>watchtower doesn't have the ability to sweep outputs independently, it would<br><span class="inbox-inbox-s1">have no way to intercept this behavior, and prevent the </span><span class="inbox-inbox-s2">breacher</span><span class="inbox-inbox-s1"> from sweeping<br></span><span class="inbox-inbox-s1">individual </span><span class="inbox-inbox-s2">HTLCs</span><span class="inbox-inbox-s1"> sequentially.<br></span><span class="inbox-inbox-s1"><br>> When the commitment </span><span class="inbox-inbox-s2">txid</span><span class="inbox-inbox-s1"> is found </span><span class="inbox-inbox-s2">onchain</span><span class="inbox-inbox-s1">, the </span><span class="inbox-inbox-s2">WatchTower</span><span class="inbox-inbox-s1"> creates a single<br></span>> main output claim transaction using the 1 or 2 signatures for the main<br><span class="inbox-inbox-s1">> outputs.<span class="inbox-inbox-Apple-converted-space"> </span>And for each </span><span class="inbox-inbox-s2">HTLC</span><span class="inbox-inbox-s1"> outpoint on the commitment transaction, if it gets<br></span><span class="inbox-inbox-s1">> spent, the </span><span class="inbox-inbox-s2">WatchTower</span><span class="inbox-inbox-s1"> creates one </span><span class="inbox-inbox-s2">HTLC</span><span class="inbox-inbox-s1"> justice transaction from the<span class="inbox-inbox-Apple-converted-space"> <br></span></span><span class="inbox-inbox-s1">> second-stage </span><span class="inbox-inbox-s2">HTLC</span><span class="inbox-inbox-s1"> transaction.<br></span><br>Yes, this is how it would work in context of what I was suggesting. Certainly,<br>there are other ways to accomplish the same thing. I don't wish to claim that<br><span class="inbox-inbox-s1">this is the best solution available, there are a lot of </span><span class="inbox-inbox-s2">tradeoffs</span><span class="inbox-inbox-s1"> that need<br></span>to be evaluated. I'm hoping that you and others can bring any shortcomings to<br>light and help us sift through them.<br><br>> 5.<span class="inbox-inbox-Apple-converted-space"> </span>0 or 1 or 2 signatures for the main outputs. These sign a single<br>> transaction that claims only the main outputs.<br><span class="inbox-inbox-s1"><br>Yes, it seems necessary to separate the commitment outpoints from the </span><span class="inbox-inbox-s2">HTLC<br></span><span class="inbox-inbox-s1">outpoints in case the commitment </span><span class="inbox-inbox-s2">txn</span><span class="inbox-inbox-s1"> is </span><span class="inbox-inbox-s2">broadcasted</span><span class="inbox-inbox-s1"> before the </span><span class="inbox-inbox-s2">CLTVs</span><span class="inbox-inbox-s1"> expire.<br></span><span class="inbox-inbox-s1">You could try to batch these with the </span><span class="inbox-inbox-s2">HTLCs</span><span class="inbox-inbox-s1">, but then we get back into<br></span>exponential territory.<br><br>> Is that approximately what is needed?<span class="inbox-inbox-Apple-converted-space"> </span>Have I missed anything?<br><br>Nope, I think your understanding is on point. IMO this seems to be a reasonable<br><span class="inbox-inbox-s1">compromise of the </span><span class="inbox-inbox-s2">tradeoffs</span><span class="inbox-inbox-s1"> at hand, and definitely something that could serve<br></span>as an initial iteration due to its simplicity. In the future, there are<span class="inbox-inbox-Apple-converted-space"> </span>definitely ways<br>to improve on this on make it even more efficient! Though having <span class="inbox-inbox-s1">a <br></span><span class="inbox-inbox-s1">solid/workable </span><span class="inbox-inbox-s2">v0</span><span class="inbox-inbox-s1"> is important if it is to be deployed. I enjoy hearing your<br></span>thoughts on this, thank you for your responses!<br><br>Best,<br>Conner</p></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 17, 2018 at 6:14 AM ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning Conner,<br></div><div><br></div><div class="m_5975885928002876892protonmail_signature_block"><div class="m_5975885928002876892protonmail_signature_block-user m_5975885928002876892protonmail_signature_block-empty"><br></div></div><div> <br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><span class="m_5975885928002876892inbox-inbox-s1">Hi </span><span class="m_5975885928002876892inbox-inbox-s2">ZmnSCPxj,</span><span class="m_5975885928002876892inbox-inbox-s1"><br></span></div><div>> Can you describe the "encrypted blob" approach to me? Or point me to<br></div><div>> materials?<br></div><div><br></div><div>There's an awesome watchtower thread on the mailing list from 2016 that starts<br></div><div>here [1]. It covers a broader range of possibilities than just the encrypted<br></div><div><span class="m_5975885928002876892inbox-inbox-s1">blob approach, and also considers other revocation schemes, e.g. </span><span class="m_5975885928002876892inbox-inbox-s2">elkrem</span><span class="m_5975885928002876892inbox-inbox-s1">.<br><br>Similar to what you described, one encrypted blob approached discussed in<br>that thread is:<br></span><span class="m_5975885928002876892inbox-inbox-s1">1. </span><span class="m_5975885928002876892inbox-inbox-s2">hint</span><span class="m_5975885928002876892inbox-inbox-s1"> = </span><span class="m_5975885928002876892inbox-inbox-s2">tixd</span><span class="m_5975885928002876892inbox-inbox-s1">[:16]<br></span><span class="m_5975885928002876892inbox-inbox-s1">2. </span><span class="m_5975885928002876892inbox-inbox-s2">blob</span><span class="m_5975885928002876892inbox-inbox-s1"> = Enc(data, </span><span class="m_5975885928002876892inbox-inbox-s2">txid</span><span class="m_5975885928002876892inbox-inbox-s1">[16:])<br></span>3. Send (hint, blob) to watchtower.</div><div><br></div><div>Whenever a new block is mined, the watchtower checks if it has an entry for each<br></div><div><span class="m_5975885928002876892inbox-inbox-s2">txid</span><span class="m_5975885928002876892inbox-inbox-s1">[:16]. If so, it </span><span class="m_5975885928002876892inbox-inbox-s2">decrypts</span><span class="m_5975885928002876892inbox-inbox-s1"> using </span><span class="m_5975885928002876892inbox-inbox-s2">txid</span><span class="m_5975885928002876892inbox-inbox-s1">[16:], assembles the justice </span><span class="m_5975885928002876892inbox-inbox-s2">txn</span><span class="m_5975885928002876892inbox-inbox-s1">, and<br></span>broadcasts (assuming the reward output matches what was negotiated).</div><div><br></div><p><br></p></div></blockquote><div>Thank you, that is indeed similar to what I was thinking given the name "encrypted blob".<br></div><div><br></div><div>Also, thank you for the link. I have not had much time to back-read anything older than 2017 in the archives. I observe that neither Poon nor Dryja seem to strongly participate in this list from 2017 onwards.<br></div><div><br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><span class="m_5975885928002876892inbox-inbox-s1"><br>> Do you have a description of the </span><span class="m_5975885928002876892inbox-inbox-s2">WatchTower</span><span class="m_5975885928002876892inbox-inbox-s1"> protocol used in </span><span class="m_5975885928002876892inbox-inbox-s2">lnd</span><span class="m_5975885928002876892inbox-inbox-s1">? It may be<br></span><span class="m_5975885928002876892inbox-inbox-s1">> useful to be </span><span class="m_5975885928002876892inbox-inbox-s2">intercompatible</span><span class="m_5975885928002876892inbox-inbox-s1">.<br></span></div><div>We don't have anything written up formally, though what we have currently<br></div><div>operates on the design above.<br></div><p><br></p></div></blockquote><div>I understand. It would be good to know what you have, and perhaps consider planning a new BOLT document for such.<br></div><div><br></div><div>Nicolas Dorier mentioned plans for BTCPay to somehow host "merchant support networks" where merchants may expose WatchTower endpoints, which other merchants may post revocation information for their channels to.<br></div><div><br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><br></div><div>I'll also take this time to brain dump some recent investigations I've been doing on<br></div><p><br></p><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div>watchtowers. TL;DR @ fin.<br></div><p><br></p><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div>FWIW, I've been thinking about this in the context of the simple encrypted<br></div><div>blob approach, though the observations can generalize to other schemes.<br></div><p><br></p><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><span class="m_5975885928002876892inbox-inbox-s1">As </span><span class="m_5975885928002876892inbox-inbox-s2">Laolu</span><span class="m_5975885928002876892inbox-inbox-s1"> mentioned, the storage requirement for the watchtower is dominated by<br></span><span class="m_5975885928002876892inbox-inbox-s1">the number of </span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1"> signatures included in the encrypted blob. Due to<br></span><span class="m_5975885928002876892inbox-inbox-s1">independence of the second stage transactions, there is a </span><span class="m_5975885928002876892inbox-inbox-s2">combinatoric</span><span class="m_5975885928002876892inbox-inbox-s1"> blowup in<br></span><span class="m_5975885928002876892inbox-inbox-s1">the number of signatures that would need to be </span><span class="m_5975885928002876892inbox-inbox-s2">pre</span><span class="m_5975885928002876892inbox-inbox-s1">-signed under the revocation<br></span>private key _if sweeping of HTLC outputs is batched_.</div><div><br></div><div>If we want to batch sweep without more liberal sighash flags, I think we'd need to<br></div><div>pre-sign n*2^n signatures. There are 2^n <span class="m_5975885928002876892inbox-inbox-s1">possible ways that n HTLCs can straddle<br>the first and second stages, and each permutation would require n distinct signatures<br>since the set of inputs is unique to each permutation. Needless to say, this isn't feasible<br>with the maximum number of </span><span class="m_5975885928002876892inbox-inbox-s2">HTLCs </span>allowed in the protocol.<br></div></div></blockquote><div><br></div><div>Yes, I thought this too.<br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><br></div><div>However, I have some observations that might inform an efficient set of<br></div><div>signatures we can choose to include in the encrypted blobs.<br></div><p><br></p><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><span class="m_5975885928002876892inbox-inbox-s1">The first is that the </span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1"> timeout or </span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1"> success transaction _must_ be<br></span>broadcast before the attacker can move funds back into their wallet. If</div><div>these transactions are never mined, it is actually fine to do nothing and leave<br></div><div>those outputs in the breached state.<br></div><div><br></div><div>If/when the victim comes back online, they themselves can sign and broadcast<br></div><div>a justice transaction that executes the revocation clause of either the offered or<br></div><div><span class="m_5975885928002876892inbox-inbox-s1">received </span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1"> scripts, based on the observed </span><span class="m_5975885928002876892inbox-inbox-s2">spentness</span><span class="m_5975885928002876892inbox-inbox-s1"> of the various commitment<br></span><span class="m_5975885928002876892inbox-inbox-s2">HLTC</span><span class="m_5975885928002876892inbox-inbox-s1"> outputs at that time. So, we can save on signature data by only requiring the<br></span>watchtower to act if second stage transactions are confirmed.</div></div></blockquote><div><br></div><div>This is a good observation! I initially thought that we would have to provide both the first-stage and second-stage revocation signatures.<br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><span class="m_5975885928002876892inbox-inbox-s1"><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1">One </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2"><span class="m_5975885928002876892colour" style="color:inherit"><span class="m_5975885928002876892size" style="font-size:inherit">reallyyy</span></span></span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"> nice thing about not having the watchtower sweep the </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"> outputs<br></span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1">on the commitment </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2"><span class="m_5975885928002876892colour" style="color:inherit"><span class="m_5975885928002876892size" style="font-size:inherit">txn</span></span></span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"> directly is that it doesn't need to know how to<br></span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1">reconstruct the more complex </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"> redeem scripts. It only needs to reconstruct<br></span>commitment <span style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat" class="m_5975885928002876892inbox-inbox-gr_ m_5975885928002876892inbox-inbox-gr_1315 m_5975885928002876892inbox-inbox-gr-alert m_5975885928002876892inbox-inbox-gr_spell m_5975885928002876892inbox-inbox-gr_inline_cards m_5975885928002876892inbox-inbox-gr_run_anim m_5975885928002876892inbox-inbox-ContextualSpelling m_5975885928002876892inbox-inbox-ins-del">to-local</span> and second-stage to-local scripts and witnesses. This means<br>the blob primarily contains:<br><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"><span class="m_5975885928002876892inbox-inbox-inbox-inbox-Apple-converted-space"> </span>- 1 revocation </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2"><span class="m_5975885928002876892colour" style="color:inherit"><span class="m_5975885928002876892size" style="font-size:inherit">pubkey</span></span><br></span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"><span class="m_5975885928002876892inbox-inbox-inbox-inbox-Apple-converted-space"> </span>- 1 local delay </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2"><span class="m_5975885928002876892colour" style="color:inherit"><span class="m_5975885928002876892size" style="font-size:inherit">pubkey</span></span><br></span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"><span class="m_5975885928002876892inbox-inbox-inbox-inbox-Apple-converted-space"> </span>- 1 </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2">CSV</span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"> delay<br> - 2 commitment signatures<br></span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-Apple-converted-space"> </span>- n HTLC signatures<br><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1">and we don't have to bother sending </span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s2">CLTVs, local/remote htlc pubkeys,</span><span class="m_5975885928002876892inbox-inbox-inbox-inbox-s1"> or <br></span></span>payment hashes at all.</div><div><br></div><div>The storage for this ends up being something like ~100 + 64*(2+nhtlcs) when you<br></div><div>include other things like the sweep address.<br></div></div></blockquote><div><br></div><div>Thank you, that seems like a start at something that can be implemented.<br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div>The second observation is that the second stage transactions could be broadcast<br></div><div><span class="m_5975885928002876892inbox-inbox-s1">sequentially such that the </span><span class="m_5975885928002876892inbox-inbox-s2">CSV</span><span class="m_5975885928002876892inbox-inbox-s1"> delays don't overlap at all. In this event, the<br></span>watchtower needs to sweep the HTLCs iteratively to prevent the attacker from</div><div>sweeping any of the outputs as the relative timelocks expire.<br></div></div></blockquote><div><br></div><div>Sorry, I seem confused this idea. Can you give example for commitment with 2x HTLC?<br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><span class="m_5975885928002876892inbox-inbox-s1">One minimal </span>solution could be to send signatures for independent sweep<br></div><div>transactions, allowing <span class="m_5975885928002876892inbox-inbox-s1">the watchtower to sweep each </span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1"> output individually.<br>This is nice because it </span><span class="m_5975885928002876892inbox-inbox-s1">permits the watchtower to sweep exactly the subset of<br></span><span class="m_5975885928002876892inbox-inbox-s2">HTLCs</span><span class="m_5975885928002876892inbox-inbox-s1"> that ever transition </span><span class="m_5975885928002876892inbox-inbox-s1">into the second stage, and under any permutation<br></span><span class="m_5975885928002876892inbox-inbox-s2">wrt</span><span class="m_5975885928002876892inbox-inbox-s1">. </span><span class="m_5975885928002876892inbox-inbox-s2">ordering </span>of confirmed second stage transactions.</div></div></blockquote><div><br></div><div>Yes, this seems like a good general idea.<br></div><blockquote class="m_5975885928002876892protonmail_quote" type="cite"><div dir="ltr"><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div><span class="m_5975885928002876892inbox-inbox-s1">With the single transaction per </span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1"> approach, the total number of signatures that<br></span><span class="m_5975885928002876892inbox-inbox-s1">are sent to the watchtower remains linear in the number </span><span class="m_5975885928002876892inbox-inbox-s2">HTLCs</span><span class="m_5975885928002876892inbox-inbox-s1"> on the commitment<br></span>transaction. This approach does have the downside of consuming slightly more</div><div>fees, since each output is swept with a distinct transaction.<br></div><p><br></p><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div>However, this approach is fairly efficient in preventing the attacker entirely from<br></div><div>moving funds from the channel into their wallet wrt. to the amount of data stored.<br></div><div>Considering that the majority of the<span class="m_5975885928002876892inbox-inbox-Apple-converted-space"> </span>channel balance is expected to be in<br></div><div>the commitment outputs and that hypothetically on-chains fees are offset by the<br></div><div>remote balance, this could be an <span class="m_5975885928002876892inbox-inbox-s1">acceptable </span><span class="m_5975885928002876892inbox-inbox-s2">tradeoff</span><span class="m_5975885928002876892inbox-inbox-s1">.</span><br></div><p><br></p><p class="m_5975885928002876892inbox-inbox-p1"><br></p><div>I suspect that in practice, most second stage transactions will be valid by the<span class="m_5975885928002876892inbox-inbox-Apple-converted-space"> <br></span>time an attacker would drop to chain. Because of this, it's possible that they</div><div>could be mined in the same block as the breach transaction.<br></div><div><br></div><div>If everything is mined in the same block or in quick succession, it might be<br></div><div><span class="m_5975885928002876892inbox-inbox-s1">worthwhile to also </span><span class="m_5975885928002876892inbox-inbox-s2">pre</span><span class="m_5975885928002876892inbox-inbox-s1">-sign a justice </span><span class="m_5975885928002876892inbox-inbox-s2">txn</span><span class="m_5975885928002876892inbox-inbox-s1"> that batch sweeps all </span><span class="m_5975885928002876892inbox-inbox-s2">HTLCs</span><span class="m_5975885928002876892inbox-inbox-s1"> directly<br></span><span class="m_5975885928002876892inbox-inbox-s1">from the second layer, requiring one additional signature/</span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1">.<span class="m_5975885928002876892inbox-inbox-Apple-converted-space"> <br></span></span></div><div>This could be a plausible scenario if the offender breached unintentionally, and<span class="m_5975885928002876892inbox-inbox-Apple-converted-space"> <br></span>their implementation tries to proceed normally. However it does require all of the<span class="m_5975885928002876892inbox-inbox-Apple-converted-space"><br></span><span class="m_5975885928002876892inbox-inbox-s2">CSV</span><span class="m_5975885928002876892inbox-inbox-s1"> delays to conincide. If that doesn't happen, the watchtower can always<br></span>resort to sweeping the outputs individually.</div><div><span class="m_5975885928002876892inbox-inbox-s1"><br>All in all, I think the ability to sweep each </span><span class="m_5975885928002876892inbox-inbox-s2">HTLC</span><span class="m_5975885928002876892inbox-inbox-s1"> independently is more-or-less<br></span>a requirement just given the complexity of how the on-chain state-space can<span class="m_5975885928002876892inbox-inbox-Apple-converted-space"> <br></span>manifest, especially if CLTVs have already expired. Other scenarios may</div><div>be worth including on a case by case basis or if we feel they are justified. This<br></div><div>could be handled dynamically by including some <span class="m_5975885928002876892inbox-inbox-s2">bitvector</span><span class="m_5975885928002876892inbox-inbox-s1"> or some compact<br>representation of how to reconstruct the transactions </span>for any additional, included</div><div>signatures.<br></div></div></blockquote><div><br></div><div>Okay. So it seems, the blob contains:<br></div><div><br></div><div>1. Revocation pubkey (from our revocation basepoint and per-commitment basepoint)<br></div><div>2. Their delayed payment pubkey (needed in scripts)<br></div><div>3. Our imposed to_self_delay (the setting we indicate, that we impose on the remote side)<br></div><div>4. Our payment pubkey<br></div><div>5. 0 or 1 or 2 signatures for the main outputs. These sign a single transaction that claims only the main outputs.<br></div><div>6. 0 or more second-stage HTLC revocation signatures. These sign individual transactions (one per HTLC) that claims only the second-stage HTLC output.<br></div><div>7. scriptpubkey to put all the funds in.<br></div><div><br></div><div>When the commitment txid is found onchain, the WatchTower creates a single main output claim transaction using the 1 or 2 signatures for the main outputs. And for each HTLC outpoint on the commitment transaction, if it gets spent, the WatchTower creates one HTLC justice transaction from the second-stage HTLC transaction.<br></div><div><br></div><div>Is that approximately what is needed? Have I missed anything?<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div>