Re: [Lightning-dev] Trustless Watchtowers
Good morning Conner, > > > > > From my bare knowledge of go, it seems data structures and messages so > > > far, > > > without actual logic, but please inform me if I am incorrect. > > > > Much of the server side has been implemented, which accepts encrypted blobs > > from > > watchtower clients and stores them. The functionality related to scanning > > blocks > > and publishing justice txns has also been implemented, but has not been > > merged > > yet. The big remaining task is to integrate the client such that it properly > > backs up states after receiving revocations from the remote peer. Is the server in a different repo from lnd? I suppose I should look at non-c-lightning repos more often. > > > > > Note however that watchtowers would require to keep all encrypted blobs > > > that > > > are keyed to the same partial txid. I.e. watchtowers need to store the > > > pair > > > in a set with the set looking at the entire txid+blob as the identity of > > > the > > > object. Otherwise it would be possible, if your watchtower is identified > > > by > > > your counterparty, for the counterparty to give the commitment > > > transaction's > > > txid with a randomly-generated blob to your watchtower before it gives the > > > revocation key to you. > > > I have described the above problem before here: > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html > > > with an unsatisfactory solution. > > > > Indeed, this was great observation! The tower can't be sure which client is > > uploading the "real" blob either. In light of that, the chosen design uses a > > two level bucketing structure that maps: > > -> client_pubkey1 : encrypted_blob1 > > -> client_pubkey2 : encrypted_blob2 > > ensuring that different client's can't overwrite each other. Further, the > > tower > > will only store one blob for a given txid per client. Upon decryption, the > > tower > > would learn that only one of this a valid update (and possibly delete state > > for > > the offender). > > > > > However, this remains your counterparty best avenue of attack, is to > > > simply > > > spam your watchtower until it runs out of resources and crashes. > > > > The client pubkeys described above are tied to what we've been referring to > > as a > > session. In order for a client to facilitate the attack described above, > > they > > would have to pay the tower for multiple sessions tied to different > > ephemeral > > session keys. > > A session grants the client the ability to store up to N blobs, where N > > would be > > several thousand. Thus, the cost to perform the attack would be many orders > > of > > magnitude greater than the cost to back up one channel. In the private tower > > case, there isn't necessarily payment, though it's more or less assumed > > that one > > wouldn't DOS their own tower. > > In practice, the tower should only ever accept sessions if it can be > > certain it > > has the appropriate disk-space to facilitate them, so I don't think > > there is much > > risk in the node crashing due to this. Someone could still pay to fill > > up my tower, > > but the tower would be compensated appropriately. The tower could also raise > > it's price point if it detects such behavior. I understand. It seems similar to "ticket" system I proposed in that post also. Somebody (not in summit, it was some paper whose author I forgot, and whose title I also forgot...) gave a good idea of combining paying the watchtower with checking if the watchtower is actually working. Basically, we simulate a breach, which releases some money to the watchtower. If the watchtower correctly fixes the breach, then it gets paid. If not, we retain our money and can find another watchtower. However, it seems not so compatible with session system...? You have to pay to get a session key first, and this cannot be recovered if the watchtower turns out to not actually monitor breaches. (I suppose the session keys could be low cost, since they are effectively just spam prevention, and watchtowers could charge larger for breach recovery, in which case it may be sensible to have both.) > > > > > And if the watchtower identifies the user, then this leaks the privacy of > > > the > > > user to the watchtower, and what would then be the point of encrypted > > > blob? > > > > I believe the same session-based, encrypted-blob approach would work eltoo > > towers as well, if the concern is primarily about the channel partner > > presuming > > the valid blob. The general design should be readily able to serve > > eltoo clients, > > with some slight modifications to breach detection and justice txn > > construction. > > My greater concern with the update-and-replace model is that it leaks timing > > information about a particular channel to the tower, since the tower must > > know > > which prior state needs replacing. So even though it is possible to make > > eltoo > > towers constant-space per channel, IMO
Re: [Lightning-dev] Trustless Watchtowers
Quick correction: > Thus, the cost to perform the attack would be many orders of > magnitude greater than the cost to back up one channel. This was written assuming the attacker was trying to upload multiple encrypted blobs for the same txid, which seems like an unlikely attack vector if the tower inherently defends against it. If instead they are just trying to fill up the tower, the cost is linear in the amount of blobs they send. --Conner On Tue, Nov 13, 2018 at 4:12 PM Conner Fromknecht wrote: > > Hi ZmnSCPxj, > > I haven't yet gotten around to writing up everything documenting in the > working > watchtower design. However, I think we are nearing that phase where things > seem > mostly solidified and would welcome feedback before attempting to formalize > it. > Expect some follow up posts on the ML :) > > > From my bare knowledge of go, it seems data structures and messages so far, > > without actual logic, but please inform me if I am incorrect. > > Much of the server side has been implemented, which accepts encrypted blobs > from > watchtower clients and stores them. The functionality related to scanning > blocks > and publishing justice txns has also been implemented, but has not been merged > yet. The big remaining task is to integrate the client such that it properly > backs up states after receiving revocations from the remote peer. > > > Note however that watchtowers would require to keep all encrypted blobs that > > are keyed to the same partial txid. I.e. watchtowers need to store the pair > > in a set with the set looking at the entire txid+blob as the identity of the > > object. Otherwise it would be possible, if your watchtower is identified by > > your counterparty, for the counterparty to give the commitment transaction's > > txid with a randomly-generated blob to your watchtower before it gives the > > revocation key to you. > > > > I have described the above problem before here: > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html > > with an unsatisfactory solution. > > Indeed, this was great observation! The tower can't be sure which client is > uploading the "real" blob either. In light of that, the chosen design uses a > two level bucketing structure that maps: > >-> client_pubkey1 : encrypted_blob1 > -> client_pubkey2 : encrypted_blob2 > > ensuring that different client's can't overwrite each other. Further, the > tower > will only store one blob for a given txid per client. Upon decryption, the > tower > would learn that only one of this a valid update (and possibly delete state > for > the offender). > > > However, this remains your counterparty best avenue of attack, is to simply > > spam your watchtower until it runs out of resources and crashes. > > The client pubkeys described above are tied to what we've been referring to > as a > session. In order for a client to facilitate the attack described above, they > would have to pay the tower for multiple sessions tied to different ephemeral > session keys. > > A session grants the client the ability to store up to N blobs, where N would > be > several thousand. Thus, the cost to perform the attack would be many orders of > magnitude greater than the cost to back up one channel. In the private tower > case, there isn't necessarily payment, though it's more or less assumed that > one > wouldn't DOS their own tower. > > In practice, the tower should only ever accept sessions if it can be certain > it > has the appropriate disk-space to facilitate them, so I don't think > there is much > risk in the node crashing due to this. Someone could still pay to fill > up my tower, > but the tower would be compensated appropriately. The tower could also raise > it's price point if it detects such behavior. > > > And if the watchtower identifies the user, then this leaks the privacy of > > the > > user to the watchtower, and what would then be the point of encrypted blob? > > I believe the same session-based, encrypted-blob approach would work eltoo > towers as well, if the concern is primarily about the channel partner > presuming > the valid blob. The general design should be readily able to serve > eltoo clients, > with some slight modifications to breach detection and justice txn > construction. > > My greater concern with the update-and-replace model is that it leaks timing > information about a particular channel to the tower, since the tower must know > which prior state needs replacing. So even though it is possible to make eltoo > towers constant-space per channel, IMO we're better off storing all prior > encrypted blobs to maintain adequate privacy. On private towers, perhaps this > privacy/space tradeoff may acceptable, but not sure if the tradeoff makes > sense > on public towers. > > Cheers, > Conner > > On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev > wrote: > > > > Good morning list, > > > > We were not able to discuss this topic much at
Re: [Lightning-dev] Trustless Watchtowers
Hi ZmnSCPxj, I haven't yet gotten around to writing up everything documenting in the working watchtower design. However, I think we are nearing that phase where things seem mostly solidified and would welcome feedback before attempting to formalize it. Expect some follow up posts on the ML :) > From my bare knowledge of go, it seems data structures and messages so far, > without actual logic, but please inform me if I am incorrect. Much of the server side has been implemented, which accepts encrypted blobs from watchtower clients and stores them. The functionality related to scanning blocks and publishing justice txns has also been implemented, but has not been merged yet. The big remaining task is to integrate the client such that it properly backs up states after receiving revocations from the remote peer. > Note however that watchtowers would require to keep all encrypted blobs that > are keyed to the same partial txid. I.e. watchtowers need to store the pair > in a set with the set looking at the entire txid+blob as the identity of the > object. Otherwise it would be possible, if your watchtower is identified by > your counterparty, for the counterparty to give the commitment transaction's > txid with a randomly-generated blob to your watchtower before it gives the > revocation key to you. > > I have described the above problem before here: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html > with an unsatisfactory solution. Indeed, this was great observation! The tower can't be sure which client is uploading the "real" blob either. In light of that, the chosen design uses a two level bucketing structure that maps: -> client_pubkey1 : encrypted_blob1 -> client_pubkey2 : encrypted_blob2 ensuring that different client's can't overwrite each other. Further, the tower will only store one blob for a given txid per client. Upon decryption, the tower would learn that only one of this a valid update (and possibly delete state for the offender). > However, this remains your counterparty best avenue of attack, is to simply > spam your watchtower until it runs out of resources and crashes. The client pubkeys described above are tied to what we've been referring to as a session. In order for a client to facilitate the attack described above, they would have to pay the tower for multiple sessions tied to different ephemeral session keys. A session grants the client the ability to store up to N blobs, where N would be several thousand. Thus, the cost to perform the attack would be many orders of magnitude greater than the cost to back up one channel. In the private tower case, there isn't necessarily payment, though it's more or less assumed that one wouldn't DOS their own tower. In practice, the tower should only ever accept sessions if it can be certain it has the appropriate disk-space to facilitate them, so I don't think there is much risk in the node crashing due to this. Someone could still pay to fill up my tower, but the tower would be compensated appropriately. The tower could also raise it's price point if it detects such behavior. > And if the watchtower identifies the user, then this leaks the privacy of the > user to the watchtower, and what would then be the point of encrypted blob? I believe the same session-based, encrypted-blob approach would work eltoo towers as well, if the concern is primarily about the channel partner presuming the valid blob. The general design should be readily able to serve eltoo clients, with some slight modifications to breach detection and justice txn construction. My greater concern with the update-and-replace model is that it leaks timing information about a particular channel to the tower, since the tower must know which prior state needs replacing. So even though it is possible to make eltoo towers constant-space per channel, IMO we're better off storing all prior encrypted blobs to maintain adequate privacy. On private towers, perhaps this privacy/space tradeoff may acceptable, but not sure if the tradeoff makes sense on public towers. Cheers, Conner On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev wrote: > > Good morning list, > > We were not able to discuss this topic much at recent summit, but I noticed > that lnd has some code related to watchtowers already. From my bare > knowledge of go, it seems data structures and messages so far, without actual > logic, but please inform me if I am incorrect. > > I assume much of the watchtowers code and design in lnd is by Conner, simply > because, he discussed this on this list earlier this year. > > I have seen recently, some paper about paying watchtowers by actually > simulating breaches. You would give a watchtower some txid+blob pair, then > send that txid and see if the watchtower claims it. If it does, then you > have evidence of liveness and correct behavior, and have also paid for and > incentivized the watchtower to
Re: [Lightning-dev] Trustless WatchTowers?
The ability for a watchtower to spend them independently seems to resolve this* On Tue, Apr 17, 2018 at 01:30 Conner Fromknechtwrote: > 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
Re: [Lightning-dev] Trustless WatchTowers?
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 ZmnSCPxjwrote: > 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 >
Re: [Lightning-dev] Trustless WatchTowers?
Good evening ZmnSCPxj, > Also, thank you for the link. Definitely! I had to do some digging myself to recover these hidden gems. > 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. > 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. > 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. Yes, this is how it would work in context of what I was suggesting. Certainly, there are other ways to accomplish the same thing. I don't wish to claim that this is the best solution available, there are a lot of tradeoffs that need to be evaluated. I'm hoping that you and others can bring any shortcomings to light and help us sift through them. > 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. > 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! Best, Conner On Tue, Apr 17, 2018 at 6:14 AM ZmnSCPxjwrote: > Good morning Conner, > > > > > 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). > > > Thank you, that is indeed similar to what I was thinking given the name > "encrypted blob". > > 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. > > > > > 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. > > > I understand. It would be good to know what you have, and perhaps consider > planning a new BOLT document for such. > > 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. > > > > I'll also take this time to brain dump some recent investigations I've > been doing on > > > > watchtowers. TL;DR @ fin. > > > >
Re: [Lightning-dev] Trustless WatchTowers?
Good morning Conner, > 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, > andbroadcasts (assuming the reward output matches what was negotiated). Thank you, that is indeed similar to what I was thinking given the name "encrypted blob". 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. >> 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. I understand. It would be good to know what you have, and perhaps consider planning a new BOLT document for such. 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. > 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 > bythe number of HTLC signatures included in the encrypted blob. Due > toindependence of the second stage transactions, there is a combinatoric > blowup inthe number of signatures that would need to be pre-signed under the > revocationprivate 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. Yes, I thought this too. > 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_ > bebroadcast 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 > commitmentHLTC outputs at that time. So, we can save on signature data by > only requiring thewatchtower to act if second stage transactions are > confirmed. This is a good observation! I initially thought that we would have to provide both the first-stage and second-stage revocation signatures. > One reallyyy nice thing about not having the watchtower sweep the HTLC > outputson the commitment txn directly is that it doesn't need to know how > toreconstruct the more complex HTLC redeem scripts. It only needs to > reconstructcommitment 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. Thank you, that seems like a start at something that can be implemented. > 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, > thewatchtower needs to sweep the HTLCs iteratively to prevent the attacker > from > sweeping any of the outputs as the relative timelocks expire. Sorry, I seem confused this idea. Can you give example for commitment with 2x HTLC? > One minimal solution could be to send signatures for independent sweep > transactions, allowing the watchtower to sweep
Re: [Lightning-dev] Trustless WatchTowers?
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
Re: [Lightning-dev] Trustless WatchTowers?
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Trustless WatchTowers?
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. > The WatchTower would have to store each and every justice transaction it > received, and would not be able to compress it or use various techniques to > store data efficiently. In our current implementation, we've abandoned the "savings" from compressing the shachain/elkrem tree. When one factors in the space complexity due the *just* the commitment signatures, the savings from compression become less attractive. Going a step father, once you factor in the space complexity of the 2-stage HTLC claims, then the savings from compressing the revocation tree become insignificant. It's also worth pointing out that if the server is able to compress the revocation tree, then their necessarily linking new breach payloads with a particular channel. Another downside, is that if you go to revocation tree compression, then all updates *must* be sent in order, and updates cannot be *skipped*. 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. -- Laolu On Sun, Apr 15, 2018 at 8:32 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Hi all, > > Nicolas Dorier was requesting additional hooks in c-lightning for a simple > WatchTower system: > https://github.com/ElementsProject/lightning/issues/1353 > > Unfortunately I was only able to provide an interface which requires a > *trusted* WatchTower. Trust is of course a five-letter word and should not > be used in polite company. > > My key problem is that I provide enough information to the WatchTower for > the WatchTower to be able to create the justice transaction by itself. If > so, the WatchTower could just make the justice transaction output to itself > and the counterparty, so that the WatchTower and the counterparty can > cooperate to steal the channel funds: the counterparty publishes a revoked > transaction, the WatchTower writes a justice transaction on it that splits > the earnings between itself and the counterparty. > > 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. The WatchTower would have to store each and every > justice transaction it received, and would not be able to compress it or > use various techniques to store data efficiently. The WatchTower would not > have enough information to regenerate justice transactions (and in > particular would not be able to create a travesty-of-justice transaction > that pays out to itself rather than the protected party). In practice this > would require that node software also keep around those transactions until > some process has ensured that the WatchTower has received the justice > transactions. > > Is there a good way to make trustless WatchTowers currently or did this > simply not reach BOLT v1.0? > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Trustless WatchTowers?
Hi all, Nicolas Dorier was requesting additional hooks in c-lightning for a simple WatchTower system: https://github.com/ElementsProject/lightning/issues/1353 Unfortunately I was only able to provide an interface which requires a *trusted* WatchTower. Trust is of course a five-letter word and should not be used in polite company. My key problem is that I provide enough information to the WatchTower for the WatchTower to be able to create the justice transaction by itself. If so, the WatchTower could just make the justice transaction output to itself and the counterparty, so that the WatchTower and the counterparty can cooperate to steal the channel funds: the counterparty publishes a revoked transaction, the WatchTower writes a justice transaction on it that splits the earnings between itself and the counterparty. 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. The WatchTower would have to store each and every justice transaction it received, and would not be able to compress it or use various techniques to store data efficiently. The WatchTower would not have enough information to regenerate justice transactions (and in particular would not be able to create a travesty-of-justice transaction that pays out to itself rather than the protected party). In practice this would require that node software also keep around those transactions until some process has ensured that the WatchTower has received the justice transactions. Is there a good way to make trustless WatchTowers currently or did this simply not reach BOLT v1.0? Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev