Re: [Lightning-dev] Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo)
ZmnSCPxj writes: > I am almost certain that a Smart Contract Unchained Escrowed > Decker-Russell-Osuntokun channel factory can merge the watchtower and > escrow functionality as well, using the above basic sketch, with > additional overlay network to allow for federated escrows. The issue > is really the increased complexity of the `(halftxid, encrypted_blob)` > scheme with Decker-Russell-Osuntokun. > > (To my knowledge, Decker-Russell-Osuntokun only simplifies watchtowers > if the watchtower knows the funding outpoint, which is information we > should really prefer the watchtower to not know unless an attack > occurs; with an unknown-funding-outpoint, `(halftxid, encrypted_blob)` > scheme, Decker-Russell-Osuntokun is actually more complicated, since > hiding the funding outpoint prevents having a simple key for the > watchtower to replace.) Just a minor comment on this: for eltoo the watchtower does not need to know the funding outpoint, instead any information that'd allow a watchtower to collate (encrypted) updates would be sufficient for it to be able to discard earlier ones. I'm thinking in particular about the session-based collation that the lnd watchtower protocol uses can be one such collation key. Alternatively we can still use the Poon-Dryja style encryption with the trigger transaction hash (which admittedly isn't very prominently described in the eltoo paper) as the encryption key. That transaction being the first step towards closing a channel unilaterally forces any cheating party to reveal the decryption key for the update txs that'll override its actions. Furthermore, while encrypting all the reactions with the same encryption key may appear to leak information, it is only the update transaction that is passed to the watchtower, not the actual state (direct outputs and HTLCs) which is attached to the settlement transaction, kept by the endpoint. So all the watchtower gets from decrypting all prior update transactions is a set of semantically identical 1-input-1-output update transactions from which it can at most learn how many updates were performed. This last leak can also be addressed by simply randomizing the increment step for state numbers and not passing every state update to the watchtower (since the watchtower will only ever need the last one we can coalesce multiple updates and flush them to the watchtower after some time). Cheers, Christian [1]: https://github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo)
Good morning Christian, Nadav, and all, > > Escrow collusion > > - > > While not particularly familiar with SCU, I think the escrow might need > to be ultimately trusted, since giving it the ability to act as > co-signer in lieu of a subset of participants, or even sole signature > authority could lead to collusion between the escrow and the remainder > of the contract participants, but I'm happy to be corrected here. This is correct. It should be noted that Smart Contracts Unchained is simply the logical extension of the buyer-seller-escrow 2-of-3 setup. When locking up its funds, the buyer trusts that the escrow does not collude with the seller to steal the funds without sending product. And when sending its product, the seller trusts that the escrow does not collude with the buyer to clawback the funds without returning the product. As such, even if the number of participants increases, trust that the escrow does not perform collusion with any of the participants, must still exist. This can be mitigated by having the escrow be a k-of-n federation. If you have `t` trusted escrow entities, you must ensure `n - k < t`. For example, if you trust only 3 escrows, then you would accept a 5-of-7 setup where 3 of the escrows are among the trusted set, and you would ensure that at most 2 of them are not involved in the signing. But you would not accept 4-of-7, as all three of your trusted escrows could potentially be removed from the signing federation. > > We had similar considerations while working on the original channel > factories paper, where we tried to come up with a scheme that'd allow a > subset of participants to split out an inactive participant in order to > recover from what would otherwise be a deadlock. We decided to drop that > possibility due to the complexity involved and the potential for serious > damage if participants collude. Indeed. I would like to point out, that channel factories, as they host channels, "degrade gracefully". If you have an ABC channel factory, that hosts AB, BC, and AC channels, even if C is offline, the AB channel continues to work "seamlessly", without any care that C is offline. Thus, I contend that channel factories hosting channels is sufficient, and there is no need for a "split out" function as described. Subsets *already work*, at reduced capability (in the above example, the BC and AC channels no longer work, because C is offline, but AB can continue to work perfectly fine), as long as you use channel factories (where the n >= 3 mechanism holds only channels, never direct HTLCs or HODLings) instead of CoinPools/multiparticipant channels. --- Given that most of the activity will be in "standard" 2-of-2 Poon-Dryja channels, and the factory is just a host for channels, you do not really need a fully-featured channel factory layer. For example, it might be acceptable to use the Decker-Wattenhofer decrementing-`nSequence` mechanism for the channel factory layer. This is trustless (no need for an Smart Contracts Unchained escrow federation or a Somsen Statechains blinded federation), at the cost of having a bad locktime-to-updates-limit tradeoff. The above is acceptable since you can update the channels independently of the factory that hosts them (that is the entire point of channels, and why they take activity offchain, they can be updated without having to update whatever hosts them, whether a blockchain or another offchain mechanism) (Indeed, one can take the point-of-view that the blockchain "goes offline" for stretches of time of around 10 minutes (i.e., the inter-block time), during which no updates to the blockchain layer are possible, and if you want to keep operating while the blockchain "goes offline" (i.e. miners are still solving the next block) then you can use payment channels.) The general use of updating the factory layer would be to rebalance the channels inside it. But we already *can* rebalance today, without factories, and without any activity on the layer that hosts the channels, by self-paying. Thus, having a limit on the number of updates on the factory layer may be an acceptable tradeoff, since you can always prioritize rebalancing at the channels layer (i.e. Lightning already currently works with just that), and only fall back to rebalancing at the factory layer if it would not be lucrative to do the rebalancing at the channels layer, and enough of the factory participants think it is a good idea to simultaneously rebalance on the factory layer at that point. I think channel factories (which **only** host channels, and never HTLCs or HODLings, so I think "multiparticipant channels" is either a misnomer, or the wrong thing entirely) have the major advantage of greatly reducing the onchain footprint, and simultaneously having a decent "graceful degradation" (i.e. the individual channels in it continue to operate even if one of the factory participants is offline).
Re: [Lightning-dev] Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo)
Hi Nadav, thanks for writing up this proposal. I think I can add a bit of details, which might simplify the proposal. ## Ordering of updates The way we ensure that an update tx (as the commitment txs are called in the paper) can be attached only to prior updates is done by comparing the state-number committed to in the prevout script with the current timelock through CLTV. This functionality exists today already, and does not have to be implemented by the Escrow at all: it can just sign off on any update transaction and the monotonicity of the sequence of updates is guaranteed through the script. This should simplify the escrow considerably and allow us to disclose less to it. ## Emulating `sighash_anyprevout` We can emulate `sighash_anyprevout` and variants today already, if we know all the transactions we'd eventually want to bind to at the time we create the transaction that'd use `anyprevout`: simply iterate through all the transactions it might bind to, update the transaction we're signing with the prevout details of that potential binding, and sign it. There are two downsides to this, namely processing overhead to generate `n` signatures for `n` potential bindings, and communication overhead, since we're now exchanging `n` signatures, instead of a single `anyprevout` signature, but it can work. I think with the escrow we can defer the creation of the signature to the time we need it, and externalize the anyprevout logic: at each update all parties sign a statement that they are ok with state `k`. Should one party become unresponsive, or broadcast an intermediate TX k' writes: > Hi all, > > # Simulating Eltoo / ANYPREVOUT Factories Using SCU Escrows > > In this write-up I hope to convince you that it is possible to create some > weak version of Eltoo channels and channel factories today without > SIGHASH_ANYPREVOUT (although the version using this sighash is clearly > superior) using ZmnSCPxj's proposal Smart Contracts Unchained (SCU) which > Ben Carman has cleverly given the name SCUE'd Eltoo. > > ## Introduction > > ### Eltoo / ANYPREVOUT > > Eltoo is a proposal for a new (and generally improved) way of doing > Lightning channels which also allows for multi-party channels (and channel > factories). I am by no means fluent in the going's on of eltoo and > anyprevout so I will link https://blockstream.com/eltoo.pdf and > https://bitcoinops.org/en/topics/sighash_noinput/. My understanding is that > at a high level, rather than using a penalty mechanism to update channel > states, sighash_anyprevout is used to make any old commitment transaction > spendable by any newer commitment transaction so that old revoked states > can be updated on-chain instead of relying on a punishment mechanism. > Benefits of this scheme include but are not limited to easier watchtower > implementations, static partial backups, and multi-party channels. > > ### Smart Contracts Unchained (SCU) > > I strongly recommend the reader read this write up by ZmnSCPxj before > continuing https://zmnscpxj.github.io/bitcoin/unchained.html > > At a high level the idea is to use a participant-chosen "federation" of > "escrows" which can be thought of as virtual machines which understand > contracts written in some language and which enforce said contracts by > giving users signatures of transactions that are produced by these > contracts. A general goal of SCU is to be trust-minimizing and as private > as possible. For example, escrows should not be able to see that they are > being used if there are no disputes, among other considerations that can be > made to make SCU Escrows as oblivious as possible (discussed further below). > > ## Proposal (Un-Optimized) > > At a high level, this proposal is to replace the use of ANYPREVOUT with a > federation of SCU Escrows which will enforce state updates by only > generating signatures to spend older states with newer ones. > > I will work in the general context of multi-party channels but all of this > works just as well in two-party (Lightning) channels. > > Say that we have N parties who wish to enter into a multi-party channel > (aka channel factory). Each participant has a public key P_i and together > they do a distributed key generation (DKG) of some kind to reach some > shared secret x (for example, each party contributes a commitment to a > random number and then that random number, MuSig style, and the sum of > these random numbers constitutes the shared secret). This x will be used to > derive a sequence of (shared) key pairs (x_k, X_k) (for example this can be > done by having x_k = PRNG(x, k)). > > Let State(k) be some agreed upon commitment of the channel state at update > k (for example, HMAC(k, kth State Tx outputs)). State(0) is a commitment to > 0 and the initial channel balances. > > Let Delta be some CSV timelock. > > For the sake of simplicity, let us consider the case where only a single > SCU escrow is used which has public key E, but note that all of the > following
