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
