The ability for a watchtower to spend them independently seems to resolve this*<br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht <conner@lightning.engineering> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<p class="m_4866601949400619855inbox-inbox-p1"><span class="m_4866601949400619855inbox-inbox-s1">Hi </span><span class="m_4866601949400619855inbox-inbox-s2">ZmnSCPxj</span><span class="m_4866601949400619855inbox-inbox-s1">,<br></span></p></div><div dir="ltr"><p class="m_4866601949400619855inbox-inbox-p1"><br>> I understand.<span class="m_4866601949400619855inbox-inbox-Apple-converted-space"> </span>For myself, I will also wait for comment from other c-lightning<br>> developers: this seems to require a bit of surgery on our code I think<br>> (currently construction of justice transactions is done in a separate process,<br>> and we always generate a justice transaction that claims all claimable outputs<br>> of the revoked commitment transaction), and we might decide to defer this<br><span class="m_4866601949400619855inbox-inbox-s1">> feature for later (leaking revocation </span><span class="m_4866601949400619855inbox-inbox-s2">basepoint</span><span class="m_4866601949400619855inbox-inbox-s1"> secret is easy and requires<br></span><span class="m_4866601949400619855inbox-inbox-s1">> maybe a few dozen </span><span class="m_4866601949400619855inbox-inbox-s2">sloc</span><span class="m_4866601949400619855inbox-inbox-s1">, but that requires a trusted </span><span class="m_4866601949400619855inbox-inbox-s2">WatchTower</span><span class="m_4866601949400619855inbox-inbox-s1">).<br></span><br></p></div><div dir="ltr"><p class="m_4866601949400619855inbox-inbox-p1">Certainly, it will require changes to ours as well. Would also love to hear what the<br>other implementations think of such a proposal. As of now, we detect if the<span class="m_4866601949400619855inbox-inbox-Apple-converted-space"> <br></span>commitment outputs have been spent, and if so, attempt to spend an aggregate of<br>the commitment outputs and second-level outputs conditioned on which are<span class="m_4866601949400619855inbox-inbox-Apple-converted-space"> <br></span>reported as spent. To realize this fully, we would need to also detect the case<br><span class="m_4866601949400619855inbox-inbox-s1">in which the second-level </span><span class="m_4866601949400619855inbox-inbox-s2">txns</span><span class="m_4866601949400619855inbox-inbox-s1"> have already been spent, and then forgo sweeping<br></span>them entirely (on the assumption that it has already been done by a watchtower).</p></div><div dir="ltr"><p class="m_4866601949400619855inbox-inbox-p1"><br><br>> Ah, I thought you wanted to impose some kind of contract on<br><span class="m_4866601949400619855inbox-inbox-s1">> </span><span class="m_4866601949400619855inbox-inbox-s2">HTLC</span><span class="m_4866601949400619855inbox-inbox-s1">-timeout/</span><span class="m_4866601949400619855inbox-inbox-s2">HTLC</span><span class="m_4866601949400619855inbox-inbox-s1">-success to enforce this behavior, you are referring to a<br></span>> technique that the attacker might attempt to use if we use only a single<br><span class="m_4866601949400619855inbox-inbox-s1">> justice transaction that claims all </span><span class="m_4866601949400619855inbox-inbox-s2">HTLC</span><span class="m_4866601949400619855inbox-inbox-s1"> outputs.<br></span><br></p></div><div dir="ltr"><p class="m_4866601949400619855inbox-inbox-p1">Precisely, if the attacker knows that we can only sweep a particular sets of<br>outputs when batched, they can choose other sets that the watchtower can't act<span class="m_4866601949400619855inbox-inbox-Apple-converted-space"><br></span>on. Spending them independently seems to resolve this.</p></div><div dir="ltr"><p class="m_4866601949400619855inbox-inbox-p1"><br><br>-Conner</p></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 17, 2018 at 8:02 AM ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com" target="_blank">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><blockquote class="m_4866601949400619855m_-3191206843123868525protonmail_quote" type="cite"><div dir="ltr"><p class="m_4866601949400619855m_-3191206843123868525inbox-inbox-p1"></p><div>> I understand. It would be good to know what you have, and perhaps consider<br></div><div><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">> planning a new BOLT document for </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">such.<br></span></div><div>Yes, that is the ultimate goal. I think it might be a little to soon to have a<br></div><div>full-on BOLT spec. There are still some implementation details that we would<br></div><div>like to address before formalizing everything. I am working to have something<br></div><div>written up in the short-term documenting the approach[es] that ends up being<br></div><div>solidified. Hopefully that can get some eyes during development, and perhaps<br></div><div>serve as working document/rough draft.<br></div><p></p></div></blockquote><div><br></div><div>I understand. For myself, I will also wait for comment from other c-lightning developers: this seems to require a bit of surgery on our code I think (currently construction of justice transactions is done in a separate process, and we always generate a justice transaction that claims all claimable outputs of the revoked commitment transaction), and we might decide to defer this feature for later (leaking revocation basepoint secret is easy and requires maybe a few dozen sloc, but that requires a trusted WatchTower).<br></div><div><br></div><blockquote class="m_4866601949400619855m_-3191206843123868525protonmail_quote" type="cite"><div dir="ltr"><p class="m_4866601949400619855m_-3191206843123868525inbox-inbox-p1"></p><div>> Sorry, I seem confused this idea.<span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-Apple-converted-space"> </span>Can you give example for commitment with 2x<br></div><div><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">> </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">HTLC</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">?<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"><br>Sure thing! The confirmation of second level </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">HTLC</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">txns</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> can be separated by<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">arbitrary delays. This is particularly true if the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">CLTVs</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> have already expired,<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">offering an attacker total control over when the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">txns</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> appear on the network. One<span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-Apple-converted-space"> <br></span></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">way this can happen is if the attacker </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">iteratively</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> broadcasts a single<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">second-level </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">txn</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">, waits for confirmation and </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">CSV</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> to expire, then repeat with<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">another second-level </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">txn</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">.<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"><br>Since the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">CSVs</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> begin ticking as soon as they are included in the chain, the<span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-Apple-converted-space"> <br></span></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">attacker could try to sweep each one immediately after its </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">CSV</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> expires. If the<span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-Apple-converted-space"> <br></span></span>watchtower doesn't have the ability to sweep outputs independently, it would</div><div><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">have no way to intercept this behavior, and prevent the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">breacher</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> from sweeping<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">individual </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">HTLCs</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> sequentially.<br></span></div><div><br></div><p></p></div></blockquote><div>Ah, I thought you wanted to impose some kind of contract on HTLC-timeout/HTLC-success to enforce this behavior, you are referring to a technique that the attacker might attempt to use if we use only a single justice transaction that claims all HTLC outputs.<br></div><blockquote class="m_4866601949400619855m_-3191206843123868525protonmail_quote" type="cite"><div dir="ltr"><p class="m_4866601949400619855m_-3191206843123868525inbox-inbox-p1"></p><div><br></div><div>> 5.<span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-Apple-converted-space"> </span>0 or 1 or 2 signatures for the main outputs. These sign a single<br></div><div>> transaction that claims only the main outputs.<br></div><div><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"><br>Yes, it seems necessary to separate the commitment outpoints from the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">HTLC<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">outpoints in case the commitment </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">txn</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> is </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">broadcasted</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> before the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">CLTVs</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> expire.<br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">You could try to batch these with the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">HTLCs</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">, but then we get back into<br></span>exponential territory.</div><p></p></div></blockquote><div>Agreed.<br></div><blockquote class="m_4866601949400619855m_-3191206843123868525protonmail_quote" type="cite"><div dir="ltr"><p class="m_4866601949400619855m_-3191206843123868525inbox-inbox-p1"></p><div>> Is that approximately what is needed?<span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-Apple-converted-space"> </span>Have I missed anything?<br></div><div><br></div><div>Nope, I think your understanding is on point. IMO this seems to be a reasonable<br></div><div><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">compromise of the </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">tradeoffs</span><span class="m_4866601949400619855m_-3191206843123868525inbox-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="m_4866601949400619855m_-3191206843123868525inbox-inbox-Apple-converted-space"> </span>definitely ways</div><div>to improve on this on make it even more efficient! Though having <span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">a <br></span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1">solid/workable </span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s2">v0</span><span class="m_4866601949400619855m_-3191206843123868525inbox-inbox-s1"> is important if it is to be deployed. I enjoy hearing your<br></span>thoughts on this, thank you for your responses!</div><p></p></div></blockquote><div>Thank you for this confirmation.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div></blockquote></div>