You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: