Channel opening and transaction forwarding

Althea L1 Development
1

One of the more difficult problems with paying for bandwidth in cryptocurrency is that cryptocurrency transactions themselves require internet access resulting in a bootstrapping problem.

This thread is for the discussion of handling the light client and bootstrapping issues. There are a few primary questions here.

  1. Do we forward transactions we receive over cleartext and not open tunnels until the channel is opened? I’ll deem this the cooperative light client method.
  2. Do we open channels immediately and allow some amount of debt to be run up without an open channel? Allowing the light client to send it’s own transaction. I call this the free trial method.

The next major set of questions are

  1. During channel opening how do we make sure the costs of opening the channel are split equally? This might just be a property of the smart contract. In the event that they are not equal bad actors could game the system to save a few pennies at the expense of peers.
  2. How do we handle channel transition? The situation where there is a active channel waiting to be closed and a new channel waiting in the wings needs to be handled well.
2

In previous discussions @Jehan has been a fan of the free trial method. He believes it is simpler to handle.

After a discussion today with @kindiana we’ve come up with a method that I think is simple enough that the free trial method will be strictly more complicated to secure form abuse than to implement cooperate light clients.

If a client is connected to the internet it will forward transactions it’s party to to the internet over an endpoint exposed on the physical interfaces. If it’s not connected to the internet transactions to that endpoint will return an error.

When a new node comes online it will send a signed channel opening transaction to it’s counterparty who will forward it, once the channel is opened the tunnel will open and bootstrapping will be complete.

3

The question of how to get transactions to a full node and who pays for channel opening are two completely different questions.

I think the special tx endpoint is an acceptable solution for now, although it will grow unwieldy if any internet access other than blockchain tx submission is required. For example, are we sure we don’t want to have the ability for a node to check that their tx was correctly submitted? Without some way for the node to check this, they are kind of lost out in space in the event of smart contract issues or retries.

On the question of who pays for channel opening, in the case that node A wants to pay node B for internet access, I think that node A should pay for the channel. With Connext’s channel design, this is possible. Node A can open a channel, and pay node B on it for as long as it wants, with the channel functioning as a unidirectional channel. The only time that node B will need to pay for a transaction is if node B wants to get its money out, or node B wants to pay node A. From my discussion with @kindiana, I believe that this is supported by guac.

The only time that we care about who opens the channel is when both nodes are attempting to pay each other at once. This is an interesting scenario, because it would be cheaper for them to just settle up without a channel (i believe this is how rita works already). If one owed the other more, then the one that owed more could pay to open it.

Also, if both nodes owe each other similar amounts, the channel will not be closed, since it will even out. In the case that a channel needs to be closed and reopened, one node by definition owes the other one. In this scenario, the node that will receive the money is incentivized to close the old channel, while the node that is paying the money is incentivized to open the new one. If we condensed closing and reopening into one “refereshing” tx, then this might be a harder question.

In any case, lets stick with the dumb solution for now. We will see how the real world scenarios evolve. Additionally, our whole design of having every pair of neighbors open a new channel is not practical without a cheap blockchain, which makes all of these questions a lot less important.

4

After discussing with @Jehan and @kindiana we’ve decided on adding a ultra low bandwidth (1kbps capped) ‘bootstrapping tier’.

Instead of being cut off nodes will instead cap non-paying or have-not-paid peers. A router in bootstrapping mode will not allow user traffic over this highly throttled connection and will instead just use it to contact the full node and bootstrap. Since this operation should not take more than a few kilobytes at most bootstraping should be quick.

Edgecases require this bootstrapping network to be unconditional to ease the process too many complicated rules get involved otherwise. But even at maximum abuse this is 80mb of free data per network member per day. An amount that should be trivial even for large scale nodes. This also solves all bootstrapping connectivity issues forever instead of requiring a mess of endpoints to fully solve every edgecase.

5

http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm @kindiana these are the commands we need to be looking at.

6

image
image996×1604 124 KB

7

What is “When we run out of money in channel (and haven’t joined yet)”?

8

“Open” is the state where the other party is paying us and but we are not paying them?

9

I assume that’s the state where the other party opened the channel and we haven’t deposited yet. I guess you could roll that into the same state as if one party runs out of money? @kindiana

10

like ttk2 said, “When we run out of money in channel (and haven’t joined yet)” is the state where the other party opened the channel and we haven’t deposited yet. We can’t roll that into any other state because there is no “redeposit” or “reload” method on the contract, so we have to close the channel if one party has joined and runs out of money

also correct on the open state, its used so we don’t join channels if we don’t need to pay the other person

11

So, it’s more like “When they run out of money in channel (and we haven’t joined yet)”?

12

Not really, more like A opens channel with B (deposit 1k), pays B 10, and then B wants to pay A 100, what needs to happen is that B needs to join the channel (because it’s run out of credit) and then send another update

13

I guess what I’m confused about is the term “run out of money” which indicates there was money in the channel to start with. In your example, how does B pay 10 if he never deposited in the first place?

14

maybe this will make it clearer lol
A deposit 1k (in state joined)
B is in state open
A 1000 B 0
A -> B 10
A 9990 B 10
B -> A 100
(B is in state open, and doesn’t have enough money to pay A, thus deposits some and moves to state Pending join)

15

why allow an open state with no funds? I guess there’s the question of what to define as the funds threshold for open.

16

Open just means you can transfer money back and forth, when you have not deposited. We don’t want everyone to blindly join channels others have made because that would be a waste of gas if they never transfered enough to us to make it worthwhile

1 Like
17

Got it! (writing extra characters to meet limit)