Skip to content

Instantly share code, notes, and snippets.

@antiochp antiochp/elder_channels_3.md Secret
Last active Sep 12, 2019

Embed
What would you like to do?

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.

  • Outchannel
  • Outclose_A
  • Outclose_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.

Txclose_A_0 (Inchannel -> Outclose_A, Kernclose_A_0)

Txsettle_A_0 (Inclose_A -> [OutA', OutB'], Kernsettle_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.

Txfund ([InA, InB] -> Outchannel, Kernfund)

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.

Txmut (Inchannel -> [OutA', OutB'], Kernmut)

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.

Txclose_A_1 (Inchannel -> Outclose_A, Kernclose_A_1)

Txsettle_A_1 (Inclose_A -> [OutA', OutB'], Kernsettle_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.

Txrevoke_B_0 (Inclose_A -> Outchannel, Kernrevoke_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.

Txclose_A_0 (Inchannel -> Outclose_A, Kernclose_A_0)

Txrevoke_B_0 (Inclose_A -> Outchannel, Kernrevoke_B_0,close_A_0,0) Txclose_B_1 (Inchannel -> Outclose_B, Kernclose_B_1) => Txrevoke_close_B (Inclose_A -> Outclose_B, [Kernrevoke_B_0,close_A_0,0, Kernclose_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 OutA' 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
@tromp

This comment has been minimized.

Copy link

commented May 23, 2019

The latest "settle" output has a relative lock against against the latest "close" output. This constrains each "settle" to the corresponding "close".

Replace the two "output"s here by "kernel".
Also note that the settle transactions assume the possibility of duplicate outputs,
so that Alice cannot prevent Bob settling by creating an on-chain out_A herself.

@antiochp

This comment has been minimized.

Copy link
Owner Author

commented May 23, 2019

Replace the two "output"s here by "kernel".

Done. Thanks for spotting that.

Also note that the settle transactions assume the possibility of duplicate outputs

Done. Added a section explaining this assumption.

@kargakis

This comment has been minimized.

Copy link

commented May 27, 2019

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.

Fees are based on tx weight - don't remember the exact formula off the top of my head but a "close" or "settle" tx would involve a unique output, independent of the other output(s) created by the other transaction with which the "close"/"settle" transaction is aggregated. So since the "close"/"settle" transaction contributes to more outputs in an aggregated transaction, doesn't the fee need to increase as well?

@tromp

This comment has been minimized.

Copy link

commented May 27, 2019

Yes, the zero-output fee paying transaction that the close or settle is to be aggregated with would set the fee large enough to cover both...

@kargakis

This comment has been minimized.

Copy link

commented May 27, 2019

Another question that is not clear by reading the proposal: I assume there is no need for a separate node implementation for Grin LN to happen and all the logic can be handled by wallets, does that sound right?

@tromp

This comment has been minimized.

Copy link

commented May 27, 2019

Just as with Bitcoin's lightning hubs running the "lnd" Lightning Network Daemon, people will need to run Grin lightning hubs, that wallets can then connect to.

@tromp

This comment has been minimized.

Copy link

commented Sep 8, 2019

Compare to "Laser Beam" at https://github.com/BeamMW/beam/wiki/Lightning-Network, which is closer to the first iteration of Elder Channels.

@antiochp

This comment has been minimized.

Copy link
Owner Author

commented Sep 12, 2019

The outputs OutA and OutB in each "settle" tx define who gets what when the channel is closed so by definition each settle tx can only be built after deciding how the funds are to be distributed on each channel update.

The "close" and "revert" txs in comparison simply move funds in their entirety between the various multisig outputs.
For example from Outchannel to Outclose_A.
These "close" and "revert" txs could potentially be pre-built during initial channel construction as long as something was missing from them and they were not yet full valid txs.

I think we can do this with "adaptor signatures".

Alice and Bob construct Txclose_A_2 such that the kernel requires a secret s to complete the signature.
The corresponding previous state revocation Txrevoke_A_1 is built requiring the same secret s to complete the signature.

Multiple instances of these "close" and "revoke" txs can be built during the initial channel negotiation between Alice and Bob.
Wallet key management would need to be robust and reliable here.

This way we increase local storage requirements as we would now store many partially built "close" and "revoke" txs (one for each possible channel update).
But per-round communication would be minimized.

Per Round Requirements (Assuming pre-built close and revoke txs)

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

We would also need some mechanism to reveal s each round to allow parties to complete their respective txs locally.


I think we can take this a step further if we pre-build the "settle" tx kernels themselves.
These tx kernels can be built without the specific outputs themselves. Alice and Bob just need to pre-select private keys to use for these "settle" txs.

Then each round reduces to simply building and sharing the final outputs OutA and OutB and their associated rangeproofs. And then revealing s to allow both parties to complete the "close", "revoke" and "settle" txs locally.

Per Round Requirements (Assuming pre-built close, revoke, settle txs)

  • 2 individual "settle" outputs + rangeproofs

Initial Channel Negotiation

Alice and Bob can initiate a payment channel by -

  • funding the multisig output Outchannel
  • deciding on an initial limit on the number of channel updates
  • pre-building the necessary adaptor signature constrained txs for these channel updates

Alice and Bob can always agree to extend the channel by building txs to support additional channel updates so this initial limit can be increased at any time.


I'm not sure if the trade-off between initial setup requirements vs. per-round requirements are worth it but its something to think about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.