Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layer-2 Deposit Channels #8

Open
cmdruid opened this issue Feb 9, 2024 · 0 comments
Open

Layer-2 Deposit Channels #8

cmdruid opened this issue Feb 9, 2024 · 0 comments
Assignees
Labels
roadmap Discuss a topic from our Roadmap

Comments

@cmdruid
Copy link
Contributor

cmdruid commented Feb 9, 2024

This topic is for the discussion of layer-2 deposit channels.

Currently, a deposit account is a 2-of-2 contract that can only be settled once.

We can extend the use of this deposit off-chain using a setup similar to a lightning channel:

  • Alice negotiates a lightning channel with the server, then registers a deposit into the channel (channel open). The escrow server deposits collateral into the channel.

  • Bob also negotiates a lightning channel with the server, then registers a deposit into the channel (channel open).

  • Alice creates an escrow contract that conditionally sends funds to either Bob or herself.

  • Alice signs transaction templates for each condition, with a revocation path that can sweep the collateral if the escrow server double-spends in the future.

  • The server can choose to broadcast one of the templates and close the channel, or negotiate a new channel (and revoke the current state plus ALL templates).

  • If the server double-spends, Alice can use her revocation key to sweep the collateral.

The setup and flow would be similar to a normal lightning channel, the difference being that we would use escrow contracts for exchanging balances between parties, versus an HTLC.

The escrow server would then act as a clearing-house of sorts, negotiating the next state for each deposit channel involved (and splicing out on-chain settlements), or settle all payments on-chain.

The advantages to this setup versus an HTLC:

  • Far easier to negotiate (server acts as coordinator).
  • Hub-and-spoke topology. No need for complex routing.
  • Payment contracts can be much longer lived.
  • No exponential lockup of liquidity.
  • All conditional payments backed by a single stake.
  • You can still program contracts with conditional payments.

The current lightning network is still a far superior choice for sending payments peer-to-peer, so it would make sense for deposit channels to be inter-operable with lightning channels. A "Contract Service Provider" would also benefit from using the existing lightning network to source collateral for their deposits.

This is still a topic heavy in R&D. Feel free to discuss if you have any questions.

@cmdruid cmdruid added the roadmap Discuss a topic from our Roadmap label Feb 9, 2024
@cmdruid cmdruid self-assigned this Feb 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
roadmap Discuss a topic from our Roadmap
Projects
Status: Research
Development

No branches or pull requests

1 participant