From conner at lightning.engineering Tue Apr 17 08:30:42 2018 From: conner at lightning.engineering (Conner Fromknecht) Date: Tue, 17 Apr 2018 08:30:42 +0000 Subject: [Lightning-dev] Trustless WatchTowers? In-Reply-To: References: Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: