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
Re: [Lightning-dev] Commitment delay asymmetry
Good morning Jim, >> It seems to me that adding an entire new attack vector in order to only >> *mitigate* (not eliminate!) another attack vector is not a good enough >> trade-off. In particular the new attack seems *easier* to perform. The >> current attack where I annoy the other side until it closes has the risk >> that the other side may have a high tolerance for annoyance, and decide not >> to close the channel unilaterally anyway. But in a symmetric-delay world, I >> do not have to wait for the other side to get annoyed: I just trigger the >> lockup period immediately in the active attack. > > I don't see the two attacks in the symmetric case as any different from one > another. In 1.1, you force a unilateral close by becoming unresponsive and > forcing the other side to eventually broadcast the commitment. In this case > you waste the other party's channel balance for the full time of the delay > PLUS the additional time they wait around to determine if you are ever going > to come online. In 1.2, you force a unilateral close by broadcasting > yourself. This is actually a weaker attack because the other party only has > to wait for the delay period and there is no uncertainty about when they will > get access to funds. So basically, I see no reason for an attacker to ever > choose 1.2 over 1.1. You make a good point there, I understand. >>> For example, in the case where the side unilaterally closing the channel >>> has zero balance, the other side gets no delay and symmetry as measured by >>> (coins locked) * (duration of lock) equals zero on both sides. When the >>> side closing the channel has at least 50% of the balance, both sides must >>> wait the full delay. Thoughts? >> >> So on channel setup where I am the funder to a 1BTC channel I make to >> Daniel: >> >> * Daniel holds a commitment transaction with: ZmnSCPxj=1BTC+no delay, >> Daniel=0BTC+no delay >> * I hold a commitment transaction with: ZmnSCPxj=1BTC+no delay, >> Daniel=0BTC+no delay > > I rather like Daniel's suggestion to scale the delay in proportion to the > time-money lost by the broadcasting party. Essentially, the delay just serves > as punishment, so we should ensure that the punishment delivered is no > greater than the time-value lost by the initiator of the unilateral close. > > This example is not quite right: the commitment delays do not need to be the > same in both commitment transaction with this scaling strategy. So the delay > for the local output is ALWAYS the to_local_delay, as it is in the BOLT 3 > spec today. When assigning the delay on the remote output, however, instead > of using 0 as BOLT specifies now or to_remote_delay as I originally proposed, > a better rule might be min(to_remote_delay, to_local_delay * to_local_value / > to_remote_value). So the delay is never worse than what the opposite side > would get by broadcasting themself, but is the punishment duration is reduced > if the attacker broadcasts a commitment transaction in which the balance of > funds is skewed towards the victim's end of the channel. However, I'm not > sure how much this matters because as I argued above, an attacker should > always prefer to become unresponsive rather than broadcast the commitment > themself. This seems complicated, so perhaps just make delays equal as in the original proposal. Of course, each side has its own `to_self_delay` that currently is applied to the other side. It seems best the rule: If I impose a specific `to_self_delay`, that applies to your commitment transaction, but for both branches of that. My commitment transaction will have delays from your `to_self_delay` setting. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.
Op 10-04-18 om 20:34 schreef Tyler H: > > I will continue to approach the problem of securely advertising > human-understandable node names, and I hope someday soon I will have a > solution Lightning can use that retains the open, decentralized > properties of the technology and the underlying blockchains. > Two of my favorite approaches: * Namecoin-style: Register your name first-come-first-serve on a block chain. -> Provides no protection against name squatting and attackers registering similarly-looking names. * Web of Trust: I tell you I believe this pubkey really corresponds to this name; someone else might tell you something else. DNS is essentially a special case of this, where the WoT has a centralized star shape. TLS is another case, where there is dozens of signing parties (CAs), and everyone typically gets their keys signed by only one of them, so anyone verifying keys has to trust all these CAs. More generally, a WoT can have any shape though. -> Provides little to no protection against trusted parties lying to you. CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
