elder_channels_redux.md

Elder Channels (Redux)

Superseded by revised description here - https://gist.github.com/antiochp/e54fece52dc408d738bf434a14680988

---

A channel consists of a single multisig output. Alice and Bob agree to fund the channel.

Tx_fund ([In_A, In_B] -> Out_channel, Kern_fund)

A pair of endpoint specific "close" and "settle" txs are negotiated for both Alice and Bob. Each "settle" tx has a relative lock height from the corresponding "close" tx kernel, introducing a delay between "close" and "settle" (24 hours for example).

The "close" and "settle" txs are negotiated between Alice and Bob before the channel is funded to prevent funds being locked up by either party.

Close and settle txs for Alice -

Tx_{close_0_A} (In_channel -> Out_{close_0_A}, Kern_{close_0_A})

Tx_{settle_0_A} (In_{close_0_A} -> [Out_A0, Out_B0], Kern_{settle_0_A,close_0_A,1440})

A matching pair of txs are created for Bob.

The channel can be closed cooperatively at any time by building a tx to spend from the multisig "channel" output, distributing funds back to Alice and Bob.

Alternatively either party can non-cooperatively close the channel by broadcasting their version of the current "close" tx (Tx_{close_0_A} for Alice or Tx_{close_0_B} for Bob).

To update the channel state a new "close" and "settle" pair of txs is negotiated, along with a "revoke" tx that revokes the previous state. The "revoke" tx simply spends the "close" funds back to the main "channel" output.

Tx_{close_1_A} (In_channel -> Out_{close_1_A}, Kern_{close_1_A})

Tx_{settle_1_A} (In_{close_1_A} -> [Out_A1, Out_B1], Kern_{settle_1_A,close_1_A,1440})

Tx_{revoke_0_B} (In_{close_0_A} -> Out_channel, Kern_{revoke_0_B})

Note: Alice possesses the "close" and "settle" txs. Bob possesses the tx to revoke the previous state attributed to Alice. Bob can revoke any previous close broadcast by Alice.

Note: Alice cannot lock funds by repeatedly closing and revoking old states. Only Bob can revoke if Alice closes.

At this point Alice can non-cooperatively close the latest state by broadcasting Tx_{close_1_A}, waiting for the delay and then broadcasting Tx_{settle_1_A}.

Alternatively Alice could attempt to close a previous state by broadcasting Tx_{close_1_A}.

Bob can "revoke and close" to immediately close the channel for the latest state as follows -

Tx_{revoke_0_B} (In_{close_0_A} -> Out_channel, Kern_{revoke_0_B})

Tx_{close_1_B} (In_channel -> Out_{close_1_B}, Kern_{close_1_B})

=> Tx_{revoke_close_B} (In_{close_0_A} -> Out_{close_1_B}, [Kern_{revoke_0_B}, Kern_{close_1_B}])

A "revoke and close" cut-through tx can be built for any previous "close" to the latest state with a single "revoke" kernel and the latest "close" kernel.

The example above used states 0 and 1 but the same thing applies for any arbitrary states. There is still only a single "revoke" tx with a single kernel and a single close tx for the latest state. An aggregate cut-through tx with 2 kernels is required to "revoke and close" any previous state.

On-Chain Activity

In the cooperative case there will be a single funding tx and a single close tx.

Tx_fund ([In_A, In_A] -> Out_channel, Kern_fund)

Tx_close (In_channel -> [Out_A', Out_B'], Kern_close)

In the non-cooperative case there will be a close and settle pair. The relative lock height between close and settle will be visible.

Tx_fund ([In_A, In_A] -> Out_channel, Kern_fund)

Tx_close (In_channel -> Out_close, Kern_close)

Tx_settle (In_close -> [Out_A', Out_B'], Kern_{settle,close,1440})

In the revocation case we will see a close followed by a revoke and close and a final settle tx.

Tx_fund ([In_A, In_A] -> Out_channel, Kern_fund)

Tx_close (In_channel -> Out_close, Kern_close)

Tx_{revoke_close} (In_close -> Out_close', [Kern_revoke, Kern_close'])

Tx_settle (In_close' -> [Out_A', Out_B'], Kern_{settle,close',1440})

Local Storage Requirements

Each party must maintain a single "close" and "settle" tx pair for the latest channel state.

To allow revocation of any previous state they must also store the revocation kernel for each previous channel state.

If you don't punish publication of old states, then you need not assign blame either.

I think you do need to assign blame here, otherwise A can potentially lock funds up.
A can "close" and then "revoke and close" on the next block and continue to do this repeatedly. If they can do this for long enough they get to expire the delay and close an old state.
The blame ensures only B can "close and revoke" after A "closes".

How do you pay the required fees?

I was ignoring fees for simplicity. One option may be to take fees out of the channel design entirely.
To "close" you could simply aggregate the channel close tx with another tx carrying sufficient fees for both.
Same for "revoke and close" and "settle" as necessary.

Thanks for elaborating.

You make a good point about fees being possibly provided by separate aggregate-able transactions.
Those could even be single-input, zero-output transactions paying all of the input as fee.
Or more likely, single-input, single(change)-output transactions when no input of the right fee size is available.
That certainly simplifies the payment channel design.
And allays any fears that one wouldn't be able to settle due a sharp rise in fees.

This scheme has exactly the same number of required outputs (6) and transactions (6) per round as the punishing one.
We can call them the "punishing" and the "forgiving" scheme.

The blame ensures only B can "close and revoke" after A "closes".

The only remaining worry is that A watches out for B's revoke kernel appearing in a mempool,
and reusing it to close out to yet another old state (assuming miners resolve aggregation conflicts in favor of higher fees).
I suppose the kernel offsets would guard against this as well?!

The only remaining worry is that A watches out for B's revoke kernel appearing in a mempool,
and reusing it to close out to yet another old state (assuming miners resolve aggregation conflicts in favor of higher fees).
I suppose the kernel offsets would guard against this as well?!

Let me think about this a bit.

The kernel offset would prevent A from de-aggregating B's "revoke and close".
Each "revoke" may spend back to the reused channel output but each "revoke" tx must have a unique kernel offset (and both parties would need to verify this is the case). If a kernel offset was ever chosen that violated this then one party could potentially be in a position to lock the channel up and eventually close out an old invalid state.

B can build the aggregate [Tx_{revoke_B_0}, Tx_{close_B_3}].
Neither A nor any colluding miner can de-aggregate this and cannot retrieve Tx_{revoke_B_0} from the pool (assuming both "revoke" and "close" are endpoint specific).
B must never broadcast either of these individual "revoke" or "close" txs in this scenario.

There are several scenarios that come into play once a channel is closed (current or otherwise) and the channel must be closed ASAP by the other party in all these scenarios. I do not think it is ever safe to leave the channel open (or reopen it via a "revoke")
once any close has been attempted.

The reuse of the channel multisig output means its a one way process one a close has begun or "bad things" will happen.

I think we can make the "settle" tx symmetric if we make both A and B close txs spend to the same "close" output.
Rather than using distinct "close" outputs for A and B we can use a "relative lock height of 0" to constrain the "close" and "revoke" txs.

Tx_{close_0_A} (In_channel -> Out_{close_0}, Kern_{close_0_A})

Tx_{revoke_0_B} (In_{close_0} -> Out_channel, Kern_{revoke_0_B,close_0_A,0})

Need to think this through a bit more but I think it works (again with the caveat that channels must be closed ASAP once any close is attempted).
This way we save an additional tx (settle still needs know if A or B closed it for the relative lock height) and an additional output for each channel state.

That certainly simplifies the payment channel design.

Definitely. I think it will be a lot easier to reason about the channels if we can safely assume fees are "out-sourced" to other txs and play no active role in the channel itself.

make both A and B close txs spend to the same "close" output.

We can take this further by making all of close1, close2, ... spend from the unique channel output to a unique close output.
Then all spends from the latter are still distinguished by the earlier kernel that they are relative to.
So the per round requirements reduce to

2 outputs, for the Alice and Bob payouts
2 closing kernels
2 kernel relative settling tx
2 kernel relative revoke kernels for the previous round

Two states

• Out_channel
• Out_close

Alice can close the channel moving funds from Out_channel to Out_close -

Tx_{close_A_0} (In_channel -> Out_close, Kern_{close_A_0})

If this is an old state then Bob can "revoke and close" with -

Tx_{revoke_B_0} (In_close -> Out_channel, Kern_{revoke_B_0,close_A_0,0})
Tx_{close_B_n} (In_channel -> Out_close, Kern_{close_B_n})
=> Tx_{revoke_close_B_n} (In_close -> Out_close, [Kern_{revoke_B_0,close_A_0,0}, Kern_{close_A_n}])

This "revoke and close" aggregate tx spends from Out_close back to Out_close ...

This doesn't work as the delay is still counting down from the first "close" (one kernel relative lock height does not supersede another).

We need a new "close" output per channel update to ensure it is only spent by the associated settle tx and not any previous one.

This "revoke and close" aggregate tx spends from Outclose back to Outclose ...

Yes; in fact it would be a transaction with 0 inputs and 0 outputs after cut-through; just 2 kernels.

This doesn't work as the delay is still counting down from the first "close"

Yes, I should've realized it doesn't invalidate the earlier settle, and thus fails to work...

So the per round requirements are

2 kernel-relative 0-delay revoke kernels for the previous round
2 closing kernels
1 musig close output
1 kernel-relative k-day-delay settling tx
2 outputs, for the Alice and Bob payouts

In the above case we have the problem because A can start a timer (the relative lock height before "settle") and it will run down before B can settle the latest state.

But maybe we can solve this with 2 close states (one per endpoint) - each represented by a multisig output.

• Out_channel
• Out_{close_A}
• Out_{close_B}

Alice can attempt to close an old state with -

Tx_{close_A_0} (In_channel -> Out_{close_A}, Kern_{close_A_0})

Bob can "revoke and close" with -

Tx_{revoke_B_0} (In_{close_A} -> Out_channel, Kern_{revoke_B_0,close_A_0,0})
Tx_{close_B_1} (In_channel -> Out_{close_B}, Kern_{close_B_1})
=> Tx_{revoke_close_B_1} (In_{close_A} -> Out_{close_B}, [Kern_{revoke_B_0,close_A_0,0}, Kern_{close_B_1}])

This way we have two delay timers. One for Alice delaying Out_{close_A} from being settled and one for Bob delaying Out_{close_B}. Alice just got her (old) closed state revoked so the timer is no longer applicable. The timer is running for Bob to settle his closed state and this cannot be revoked as it is the latest state.
After the delay Bob can safely settle the channel and distribute funds back to Alice and Bob as per latest state.

Either party can attempt to close old state but this will be immediately revoked and the latest state will be closed by the other party.

So maybe we don't need a unique close output per channel state update, maybe we just need a unique close state per channel participant.

Per round requirements here would be -
2 revoke kernels + offsets
2 close kernels + offsets
2 settle kernels + offsets
2 settle outputs (shared across both variations of the settle tx)

Both parties would need to maintain latest state (close kernel + single settle tx) and all previous revoke kernels.

we just need a unique close state per channel participant.

A yes, that would do the trick.
The revoke + latest close aggregates into a transfer from one close output to the other.

So in this final (famous last words:-) form, we need for each additional round

2 kernel-relative 0-delay revoke kernels for the previous round
2 "closing" kernels
2 kernel-relative k-day-delay "settling" tx
2 outputs, for the Alice and Bob payouts

Compared to the last one, we have one less output and one more kernel.
Which is a good trade-off, as outputs require expensive rangeproofs...

If the channel is likely to reuse previous balances, e.g. because Alice and Bob are playing a random game with 50-50-odds,
then they can decide to reuse the outputs (and corresponding rangeproofs) created earlier, for greater efficiency.

Revised proposal based on this discussion - https://gist.github.com/antiochp/e54fece52dc408d738bf434a14680988

So, does this mean that the Lightning Network could finally be implemented on top of Grin? That would be huge.