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). --- In any case, if you still want to continue to use Smart Contracts Unchained, I suggest merging the escrow functionality with watchtower functionality. This does not improve security (escrows can still collude with other channel participants) but does improve privacy and increases your anonymity set when you are not colluding with your escrows. With this, your setup to enter into a Smart Contracts Unchained contract would be: * Agree on the contract. * Create a funding transaction that pays to an n-of-n of the participants. * Create a contract transaction that pays to a k-of-n of the escrow federation, spending the above funding transaction output. * This is signed with a sign-to-contract, where the `R` commits to a hash of the contract. * Broadcast and sign the funding transaction. * Send a `(halftxid, encrypted_blob)` pair to the escrow federation. * The `halftxid` is half of the `txid` of the contract transaction. * The `encrypted_blob`, when decrypted, shows that it is actually a Smart Contracts Unchained contract (and not a normal Lightning watchtower blob) and contains the contract and the decommitment in the sign-to-contract. When the contract transaction is confirmed onchain, the escrow federation performs the normal watchtower operation of taking the full txid of the encrypted blob, and if it decodes successfully, can now open the enrypted blob and read the contract. It checks that the contract matches the signature on the contract transaction, then if that matches, enforces the contract. (It seems to me a good idea to make watchtowers general enough that they can support not just Lightning, but also CoinSwap and Smart Contracts Unchained, if only for the improved anonymity set.) 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.) Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
