search

get10101 / 10101-PoC

The world needs more Lightning!
MIT License
17 stars 3 forks source link

Open payment channel between taker and maker #10

Closed holzeis closed 1 year ago

holzeis commented 2 years ago

Before funding a cfd contract using a lightning transaction, the taker and the maker need to open a payment channel

bonomat commented 2 years ago

Note: we will need dual-funded channels when using this channel for trading/betting.

holzeis commented 2 years ago

@bonomat whats the status of dual-funded channels? last time you mentioned this is not yet supported by ldk? are we planning to build that?

Alternatively, would it work to open two payment one inbound and one outbound?

bonomat commented 2 years ago

Dual-funded channels are still in the works on rust-lightning. In the meantime (and for the time being) we can use one-sided funded channels. The user then sends us their funds and we open a channel with them. It's not optimal because there is some trust involved but it should be good enough for now.

Alternatively, would it work to open two payment one inbound and one outbound?

For that we would need to be able to split DLCs across multiple channels. Not an easy task but something we should do in the long run.

holzeis commented 2 years ago

Dependent on #82 and #89

bonomat commented 2 years ago

I want to point out a potential problem which up in https://github.com/itchysats/10101/issues/113#issuecomment-1302804794:

For trading CFDs we need a channel with balances on both sides. In an ideal world we would have dual-funded channels but this is not a thing yet.

Since we don't have this we came up with a solution where the maker will open the channel to the taker and the taker send all channel funds to the maker on-chain in a trusted way. However, we assume that the maker will run on a server and the taker will run on a phone. Afaik it is hard to connect to a phone because your mobile provider might block the ports. If this is true, than we cannot easily do the proposed solution.

The simplest alternative to this I could come up with so far is to turn things around:

  1. the taker tells the maker he wants to open a channel and provides him an address,
  2. the maker sends on-chain funds to the taker
  3. the taker opens the channel to the maker.

This obviously really really bad but could work for the time being.

An alternative solution: We could run 10101 on a custom Signet for the time being and simply give the taker alot of money. (as proposed by @luckysori). That way the taker could simply open the channel to the maker and give us money, no need to rebalance.

What do you guys think?

holzeis commented 2 years ago

Well if its just the issue of reaching the phone, couldn't we use services like firebase to tell the mobile wallet to sign something and send it to the maker for opening the channel? Alternatively we could also implement a mediator service (could be the maker in the beginning) which will keep an encrypted inbox for the mobile takers. (The mobile wallet could then poll for new messages).

bonomat commented 2 years ago

LDK seems to be quite flexible in regards to the network stack: either build your own or use what they have: They have a tokio-based tcp connection library which is ready to use. So unless we build our own I don't think this can be easily done.

da-kami commented 2 years ago

I think to come to a conclusion it would be good to define what we expect as outcome of the tournament more clearly, as in:

The simplest alternative to this I could come up with so far is to turn things around:

1. the `taker` tells the `maker` he wants to open a channel and provides him an address,

2. the `maker` sends on-chain funds to the `taker`

3. the `taker` opens the channel to the maker.

Obviously not a solution we should use in production, but for a demo I would not mind to turn it around and let the taker open the channel. If this is just for the purpose of a demo I'm fine with it.

This obviously really really bad but could work for the time being.

An alternative solution: We could run 10101 on a custom Signet for the time being and simply give the taker alot of money. (as proposed by @luckysori). That way the taker could simply open the channel to the maker and give us money, no need to rebalance.

What do you guys think?

If we decide that a signet demo is good enough this might be the better solution to go for, because this is more in line of what the flow would actually be. I think this would simplify things rather than making them more complicated.

As far as I understand signet is a testnetwork similar to testnet; but centrally controlled. What would be the advantage over using testnet? No block times?

holzeis commented 2 years ago

As discussed in the objective alignment, for this ticket and for the tournament of legends we are going with a channel created by the taker and fix later.

  1. the taker tells the maker he wants to open a channel and provides him an address,
  2. the maker sends on-chain funds to the taker
  3. the taker opens the channel to the maker.
bonomat commented 2 years ago

One question: Since the wireframes does not have an action/screen for this: how is a channel created? Is this done automatically or through user input?

holzeis commented 2 years ago

One question: Since the wireframes does not have an action/screen for this: how is a channel created? Is this done automatically or through user input?

* automatically might be hard, because we will need to figure out _when_. Once money arrives in the wallet might not be the best idea because the user might want to deposit money in 2+ transactions before opening a wallet

* through user input: we should potentially design a screen in figma for that

Since this is anyways a temporary feature, I wouldn't go into any UX improvements and go with the automated approach.

bonomat commented 2 years ago

The flow as outlined in your comment here is temporary but generally opening a channel is not. We haven't modeled how a channel is being created yet.

da-kami commented 2 years ago

For clarification:

This ticket (#10) is about opening the channel once the user has funds in a Bitcoin hot-wallet which is part of the application (captured in #113). Note that we did not model this dimension in our wireframes so far; the setup that was depicted in the wireframes does not involve the Bitcoin wallet. Given that we want to depict that (or need to given our process flow) I will see to extend the wireframes to capture this.

After a discussion with @bonomat we came to the conclusion that it relatively easy to introduce a view for the Bitcoin wallet next to the Lightning wallet. Note that it will add some complexity.

Ad. channel open:

I think automated would be best for now, I would not want to show this functionality too much.

Here is my summary of the steps once more:

  1. Requirement: The on-chain wallet of the taker already has funds (i.e. #113), only then the taker will get the option to open a channel.
  2. The taker contacts the maker to create initial channel, I imagine these messages
    1. Taker -> Maker: Hello
    2. Maker -> Taker: Maker Lightning Node address
    3. Taker -> Maker: Intended capacity for channel (?)
    4. Maker -> Taker: OK
    5. Taker -> Maker: Address for BTC to go
  3. The maker funds the address provided by the taker
  4. The taker opens the channel to the maker by locking up the funds

User interface:

The taker sees a screen Create Channel where the taker can select:

The rest is done in the background, but we could provide some status update that shows the taker the process.

I will add this screen in our Figma wireframe.

da-kami commented 2 years ago

OpenChannelJourney

Note: This also depends on #139 now!

da-kami commented 1 year ago

@holzeis I assigned you you to this ticket because I think you are the one working on it primarily now.

Note: The screens are implemented besides the payment history actually being wired in, I would keep that tracked in #165

da-kami commented 1 year ago

This ticket still has several sub-tasks related to "opening the channel" that were not fully addressed. In a effort to know what is yet to be done I captured these tickets separately:

https://github.com/itchysats/10101/issues/199 https://github.com/itchysats/10101/issues/198 (this is relevant because it defines the channel capacity for now)

da-kami commented 1 year ago

@holzeis I think we can close this ticket in favor for the more specific follow-up tickets.