elder_channels_3.md

Elder Channels (3)

A payment channel can be opened between two endpoints Alice and Bob.

3 multisig outputs are created to maintain channel funds. One "channel" output holding funds while the channel is active and two "close" outputs used to hold funds when closing the channel, one for each endpoint.

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

Channel Setup

A pair of multisig "close" and "settle" transactions are built. These are specific to Alice and a matching pair are built for Bob. The "close" tx for Alice will spend funds from the shared "channel" output to Alice's "close" output. The "settle" tx will spend funds from the "close" output and release them out to Alice and Bob.

The "settle" kernel has a relative lock height on the "close" kernel. After closing the channel there is a delay before the funds can settle and be released to Alice and Bob.

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

Tx_{settle_A_0} (In_{close_A} -> [Out_A', Out_B'], Kern_{settle_A_0,close_A_0,1440})

Alice gets their "close" tx. Bob gets his matching "close" tx. Both Alice and Bob get both "settle" txs, to prevent funds getting locked up in either "close" output.

Once these "close" and "settle" txs have been negotiated a tx can be built to fund the multisig "channel" output.

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

The channel is open once the funding tx has been broadcast and confirmed.

Closing the Channel

Alice and Bob can negotiate a mutual channel close by building a tx that release the funds from the channel.

Tx_mut (In_channel -> [Out_A', Out_B'], Kern_mut)

Alternatively they can decide to unilaterally close the channel by broadcasting their multsig "close" tx built earlier.

Updating Channel State

The original multisig "channel" output and two multisig "close" multisig outputs exist for the duration of the channel.

To update the state of the channel a new pair of "close" and "settle" txs are negotiated, with the new "settle" tx distributing funds to Alice and Bob as necessary.

The initial channel state may release funds 50/50 to Alice and Bob with the updated state releasing funds 60/40 for example.

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

Tx_{settle_A_1} (In_{close_A} -> [Out_A', Out_B'], Kern_{settle_A_1,close_A_1,1440})

These txs are for Alice and a matching pair of txs are built for Bob.

Note we reuse the existing "channel" and "close" outputs. Each "settle" kernel has a relative lock height against against the "close" kernel. This constrains each "settle" to the corresponding "close".

At this point Alice can close the latest state (1) as before. There is a problem here though as they can also attempt to close a previous (revoked) state to claim an incorrect split of funds.

To prevent this a "revoke" tx is also built that spends funds from a multisig "close" output back to the multisig "channel" output. These are negotiated such that Bob can revoke an attempt to close a previous state by Alice.

Tx_{revoke_B_0} (In_{close_A} -> Out_channel, Kern_{revoke_B_0,close_A_0,0})

This tx kernel has a relative lock height of 0 against the corresponding "close" kernel. Every "close" has a corresponding "settle" and every previous close has a corresponding "revoke".

The most recent "close" is the only state that cannot be revoked.

A "revoke" can always be broadcast before the corresponding "settle" due to the different relative lock heights.

For every previous "close" tx attributable to Alice, Bob possesses the corrresponding "revoke" tx.

If Alice were to attempt to close a previous state, Bob would immediately revoke this attempt and close the channel at the latest state themselves. Bob can aggregate and cut-through the "revoke" and "close" txs.

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

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} (In_{close_A} -> Out_{close_B}, [Kern_{revoke_B_0,close_A_0,0}, Kern_{close_B_1}])

This aggregate tx spends from the previous close state attributable to Alice into the latest close state attributable to Bob.

This latest close state cannot be revoked and after the delay, Bob (or Alice) can settle the channel and release funds according to the latest channel state.

Note it is unsafe for Bob to leave the channel open if Alice ever attempts to close a previous state. The delay between the "close" and "settle" starts on first entry to the state and does not reset. Alice could attempt a second close on that previous state and settle immediately.

Bob would be unwise to attempt closing at a different old state for the same reasons.

Bob must immediately "revoke and close" if Alice ever attempts to close on an old channel state.

Bob must broadcast only the aggregate cut-through "revoke and close" tx. If the individual "revoke" tx was ever revealed, Alice could use it to lock funds up by repeatedly closing and revoking until the delay expired. The kernel offset in the "revoke and close" tx prevents Alice from recovering the individual "revoke" tx.

Assumptions

The "settle" tx assumes support for duplicate UTXOs in Grin/MW. This is not currently the case and Alice could lock funds up by creating a duplicate Out_A' and preventing the settle tx from confirming. This can be resolved by building separate settle txs for Alice and Bob with each producing a single output. Support for duplicate UTXOs would permit the single settle tx described here to work.

Fees

Fees have been ignored. Any tx can have fees "added" through aggregation with another tx carrying the appropriate combined fees. Any "close" tx or "settle" tx involved in the channel design can simply be aggregated with a fee paying tx provided by Alice or Bob. This simplifes the channel design significantly.

Local Storage Requirements

Both Alice and Bob must maintain the following -

• 2 latest "settle" txs (1 each for Alice and Bob)
• 1 latest "close" kernel + offset
• all previous "revoke" kernels + offsets

Per Round Requirements

Each state update for the channel requires the following -

• 2 multisig "revoke" kernels + offsets
• 2 multisig "close" kernels + offsets
• 2 multisig "settle" kernels + offsets
• 2 individual "settle" outputs + rangeproofs

Are the state_i outputs?
Can you elaborate what you are proposing to change from the above Per Round Requirements:
2 multisig "revoke" kernels + offsets
2 multisig "close" kernels + offsets
2 multisig "settle" kernels + offsets
2 individual "settle" outputs + rangeproofs
?

Yes each state is now a new output + rangeproof.

I don't think we need the per-party txs with the folding approach.
But each state update now involves a new output + rangeproof.

So I think the per round requirements are something like -

1 multisig state output + rangeproof
1 foldable "update" tx (offset adjustment)
1 "close" kernel + offset
1 "settle" tx (2 outputs + 2 rangeproofs + kernel + offset)
1 "revoke" kernel + offset

3 outputs + 3 rangeproofs + 3 kernels + 3 offsets + 1 offset adjustment

vs. what is proposed in the gist -

2 outputs + 2 rangeproofs + 6 kernels + 6 offsets

But we gain simplicity because we no longer need to maintain per-party close and settle state.
We do not need to identify which party closed and which party can therefore revoke etc.

---

Edit: Maybe the state update outputs do not need corresponding rangeproofs. If they are always folded (and cut-through) then they never appear on chain. So maybe its actually -

3 outputs + 2 rangeproofs + 3 kernels + 3 offsets + 1 offset adjustment

vs.

2 outputs + 2 rangeproofs + 6 kernels + 6 offsets

i.e. We replace 3 kernels and 3 offsets with a single output and an offset adjustment.

---

Edit: Need to think about this a bit more but I suspect the "revoke" tx will always be foldable as well and does not require its own kernel.
The only txs that do require a kernel and will appear on chain are the "close" and "settle" txs.

So (assuming this is actually true and works) per round requirements are -

1 multisig state output
1 foldable "update" tx (just an offset adjustment)
1 "close" kernel + offset
1 "settle" kernel + offset
2 "settle" outputs + rangeproofs
1 foldable "revoke" tx (just an offset adjustment)

3 outputs + 2 rangeproofs + 2 kernels + 2 offsets + 2 offset adjustments

vs.

2 outputs + 2 rangeproofs + 6 kernels + 6 offsets

So this is an outline for the next iteration, Elder Channels (4), where each channel payment gets a new Close output, with a single close tx for both Alice and Bob, where the previous close tx is revoked by the paying party revealing their previous excess?
I think that's a nice proposal, worthy of its own page (maybe linking back to all previous versions)...

Yes - planning on putting (another) one together. 👍

I think that rough proposal for Elder Channels (4) is fundamentally flawed.
Any excess revealed for say state1 -> state2 can simply be used to "reverse" the tx, state2 -> state1 in this case.
So I suspect it is possible to transition back to old invalid states even after attempting to close the latest state - either locking funds up indefinitely or potentially settling the channel at old invalid state.

If a channel payment from Alice to Bob takes the channel from initial state1 to state2, then Alice reveals her excess from Out_channel to Out_close1.
Bob can use this to revert Alice's obsolete close tx, with a new tx that spends Out_close1 to (Out_channel to) Out_close2, which Alice cannot undo, as she doesn't know Bob's excess from Out_channel to Out_close2.

which Alice cannot undo, as she doesn't know Bob's excess from Out_channel to Out_close2.

Yes thanks - that's the bit I was missing 👍. The excess necessary to revoke has not yet been revealed for the latest closed state.

Linking here as I had not recognized quite how similar this is to the earlier concept of triggers described here -https://lists.launchpad.net/mimblewimble/msg00025.html