Re: [Lightning-dev] Witness asymmetric payment channels
Hi Z, Thanks as usual for your thoughtful comments I agree with you that there is no improvement in complexity in the formal sense. I do believe it is an improvement in conceptual complexity. At least, I am able to keep all the moving parts in my head at the same time whereas I struggle sometimes with the current BOLT spec. Unfortunately, while thinking about the above statement I realised there is worse storage complexity. In order to punish a revoked commitment transaction efficiently you need to extract the publication secret. But in order to do that you need to keep around the encrypted signature (a.k.a adaptor signature) **for that particular commitment transaction**. This means you have O(n) storage, unlike the present spec which has O(1) by deriving the previously revealed revocation secret from the present one (this can't be done with adaptor signatures). This doesn't seem to be addressed in the original work. Yikes! This might be a fatal flaw to this proposal unless it can be addressed. > When we have "the same" transaction on both sides, however, we need to > synchronize between the two sides. Can you elaborate on this? I think you can carry on using the same BOLT 2 update protocol within this channel system. The txids being the same for both parties sometimes seems to be incidental. It may be advantageous to use an alternative protocol that forces a synchronization of the commitment transactions but I don't *think* it is a requirement. I guess you would need to sync in Decker-Russell-Osuntokun because it needs an objective ordering of commitment transactions. That is seemingly not the case here though LL On Tue, Aug 25, 2020 at 10:45 PM ZmnSCPxj wrote: > > Good morning Lloyd, > > I think this is excellent work overall. > > With that said... > > > > - It is more elegant as there are half the number of possible > > transactions. I > > expect this will follow through to reduced implementation complexity > > and maybe > > make it easier to explain as well. > > I am not sure the complexity will be reduced all that much. > > Currently: > > * We provide a partial signature for the other side for their commitment > transaction. > * We keep our own commitment transaction and the partial signature we receive > from the other side. > > The node never has to retain the commitment transaction of the other side. > > With this setup: > > * We provide a partial signature for the other side for their asymmetric > signature. > * We keep a copy of the shared commitment transaction and the partial > signature we received for our own asymmetric signature from the other side. > > So storage complexity is still the same. > > An issue is that with asymmetric transactions, it is fairly easy to use TCP > to communicate changes to the commitment txes. > We send a bunch of HTLC changes we want to apply to the other side commitment > tx, then send a signature for those changes. > Since what we send applies to *their* transaction only, we do not have to > consider what they sent to us, we just have to consider what we sent to them. > Conversely, when keeping track of what our commitment transaction is, we only > have to consider what they sent to us, in order, and then when we receive a > signature we know it is for the commitment transaction with all the updates > the other side sent. > > (This arguably just moves the complexity higher, however: we cannot forward > an HTLC until both us and the other side have revoked the transactions that > do not contain it i.e. the "irrevocably committed" state.) > > When we have "the same" transaction on both sides, however, we need to > synchronize between the two sides. > Suppose both participants want to forward HTLCs to one another. > Without any kind of locking, both participants could send network packets > containing the HTLCs they want to add to each other, and it becomes ambiguous > whether the signature they *should* send contains one, or both. > > Basically, TCP only assures a global order for *one* direction of the > communications, once we have two network nodes talking simultaneously, the > order in which one writes and then reads is a lot more ambiguous. > > This issue also exists for Decker-Russell-Osuntokun, incidentally. > > One way to solve this would be to have a "token" that is passed alternately > between the participants. > At initial connection, they run a secure multiparty coinflip that indicates > which one gets the token. > Then, the one that holds the token can add more HTLCs, then tell the other > "okay, now we sign" and they exchange signatures for a new version that > involves only the HTLCs from the token-holder. > Then the token-holder passes the token to the other side. > > If the current token-holder does not have any HTLCs it wants to send, it can > wait for some time (in case it receives a request to forward), then if there > are still no HTLCs, it can pass the token to the other side by sending a > toke
[Lightning-dev] Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo)
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 can be extended to a threshold scheme of escrows. E_k will be used to denote some tweak of E by State(k) similar to the tweak described in SCU. ### Transactions Funding Transaction Like all such schemes, the funding transaction is some transaction containing an N-of-N multi-signature output with keys P_1, ..., P_N called the funding output. Commitment Transaction The commitment transaction spends the funding output and has a single output which has two spending conditions: Either E_k and X_k sign OR all N parties sign cooperatively after Delta. State Transaction The state transaction spends the commitment transaction via the cooperative branch and has (potentially many) outputs representing the current channel state. For example there will be an output for each solvent participant in this channel, as well as an output for ever contract living on this channel (for instance, other smaller channels). Commitment Update Transaction Let k2 be some state where k2 > k. The commitment update transaction spends either a commitment transaction's non-cooperative branch (E_k and X_k) or another commitment update transaction's non-time-locked branch, and has a single output which has two spending conditions: Either E_k2 and X_k2 sign OR E_k2' and X_k2' sign after Delta where those are tweaked keys in some way (to avoid signatures generated for one case being used in the other). State Update Transaction The state update transaction spends the commitment update transaction via the time-locked branch and has outputs equal to those on the (k2)th state transaction. ### Update Mechanism The update mechanism here is the same as would be expected for a multi-party payment channel but with t
