The ability for a watchtower to spend them independently seems to resolve this* On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht <conner@lightning.engineering> wrote:
> Hi ZmnSCPxj, > > > > 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). > > Certainly, it will require changes to ours as well. Would also love to > hear what the > other implementations think of such a proposal. As of now, we detect if the > > commitment outputs have been spent, and if so, attempt to spend an > aggregate of > the commitment outputs and second-level outputs conditioned on which are > reported as spent. To realize this fully, we would need to also detect the > case > in which the second-level txns have already been spent, and then forgo > sweeping > them entirely (on the assumption that it has already been done by a > watchtower). > > > > > 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. > > Precisely, if the attacker knows that we can only sweep a particular sets > of > outputs when batched, they can choose other sets that the watchtower can't > act > on. Spending them independently seems to resolve this. > > > > -Conner > > On Tue, Apr 17, 2018 at 8:02 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > >> Good morning Conner, >> >> > I understand. It would be good to know what you have, and perhaps >> consider >> > planning a new BOLT document for such. >> Yes, that is the ultimate goal. I think it might be a little to soon to >> have a >> full-on BOLT spec. There are still some implementation details that we >> would >> like to address before formalizing everything. I am working to have >> something >> written up in the short-term documenting the approach[es] that ends up >> being >> solidified. Hopefully that can get some eyes during development, and >> perhaps >> serve as working document/rough draft. >> >> >> 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). >> >> > Sorry, I seem confused this idea. Can you give example for commitment >> with 2x >> > HTLC? >> >> Sure thing! The confirmation of second level HTLC txns can be separated >> by >> arbitrary delays. This is particularly true if the CLTVs have already >> expired, >> offering an attacker total control over when the txns appear on the >> network. One >> way this can happen is if the attacker iteratively broadcasts a single >> second-level txn, waits for confirmation and CSV to expire, then repeat >> with >> another second-level txn. >> >> Since the CSVs begin ticking as soon as they are included in the chain, >> the >> attacker could try to sweep each one immediately after its CSV expires. >> If the >> watchtower doesn't have the ability to sweep outputs independently, it >> would >> have no way to intercept this behavior, and prevent the breacher from >> sweeping >> individual HTLCs sequentially. >> >> 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. >> >> >> > 5. 0 or 1 or 2 signatures for the main outputs. These sign a single >> > transaction that claims only the main outputs. >> >> Yes, it seems necessary to separate the commitment outpoints from the >> HTLC >> outpoints in case the commitment txn is broadcasted before the CLTVs >> expire. >> You could try to batch these with the HTLCs, but then we get back into >> exponential territory. >> >> Agreed. >> >> > Is that approximately what is needed? Have I missed anything? >> >> Nope, I think your understanding is on point. IMO this seems to be a >> reasonable >> compromise of the tradeoffs at hand, and definitely something that could >> serve >> as an initial iteration due to its simplicity. In the future, there are >> definitely >> ways >> to improve on this on make it even more efficient! Though having a >> solid/workable v0 is important if it is to be deployed. I enjoy hearing >> your >> thoughts on this, thank you for your responses! >> >> Thank you for this confirmation. >> >> Regards, >> ZmnSCPxj >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev