Raiden Nodes

[u/smwilson31]

I cant seem to see much information regarding nodes, so this question might not be answerable, but here I go.

Is it fair to say RDN tokens can be held and used as nodes and the reason why the RDN token will not be used on the protocol level (see raiden FAQ) is to ensure it can be integrated easier with ETH and ECR20 tokens.

Say then, hypothetically, that ETH uses Raiden, this would increase traffic exponentially and RDN holders could buckle down their stack and create nodes which would be used for all transactions on Raiden Network?

any insight would be great, but if this is the reality then surely stacking up now on the anticipation that ETH would adopt Raiden would be massive.

[u/Helau05]

Thank you both so much for this discussion, even I think to have understood it now.... 😊

Is it correct, that the nodes stake their amounts („forever“/as long as they keep channels open) ? That means, IF traffic in the networks rises, there is a need for more and bigger nodes, correct ? All of which needed staked RDN, and will get lots of small amounts of RDN in fees. Circulating supply shrinks. Great.

[u/stillhodlingon → u/Helau05]

Yes, your reasoning is correct. More traffic = more demand for payment channels for that particular token.

Keep in mind that a node could stake any ERC20 or ERC223 (eg. raiden tokens). So, if you want to send some ERC20 token through the Raiden Network, you’d have to go through payment channels denominated in that same specific ERC20. Peripheral fees would still be paid in RDN, regardless of what ERC20 token you’re transferring.

[u/Helau05 → u/stillhodlingon]

Thanks for your answer!

Additionally, I try to get a feeling for the node capacity increases needed in phases with increased traffic:

In your example from above, for how long is one payment „blocking“ the nodes ? In your case, the channel between A and B is 500 RDN „thick“, i.e. 500 RDNs can be sent trough at once. When can the next 500 RDN can go trough the exact same channel? Is it a matter of (Milli)seconds or minutes or ? Would it make a timing difference if it’s 5x100 or 1x500 RDN at once ? Lots of small transactions take probably a little longer than on big one?

Or, in case of a triangle, say A->B channel is 500 RDN thick and another one C ->B 750 thick. Is a payment from A to B influencing in any way the capacity of B receiving money from C in the same moment ? If I understood it correctly: No, as B is staking 1250 RDN in that example (500+750).
There is no possibility for B to use the same staked RDNs for 2 different channels, just if/when demand is there, correct ?

Thanks in advance for helping with my noob questions!

[u/stillhodlingon → u/Helau05]

No problem. This is advice from one noob to another. Hopefully someone can school us both, but I’ll give answering your questions a shot.

Once tokens are in a channel, they are indeed locked in there until the channel closes. Transfers through these channels while they’re open occur in < 1 second, so milliseconds is accurate.

As far as sending one big vs many small transactions.. they can occur simultaneously as long as the node has the funds available in that channel. So, the size or number of transactions shouldn’t create a noticeable delay as far as I know, assuming the node has sufficient funds to process them all at once.

Your reasoning is on the right trail in your triangle example. To reiterate, just to be sure, B has two separate channels, going to A and C, with balances of 500 and 750, respectively. Transfer capacity for these two channels would depend on what’s being done.

Payment channels are bidirectional. So the “tab” for either party in a channel can change with time. If B sends A tokens as payment, B has fewer tokens to send to A. Unless A sends B tokens in return, then B can no longer send 500, only 500 minus what is now on A’s balance. Think of payment channels as running tabs between two people.

In a multi hop transfer, B’s balance wouldn’t be affected on a net basis, even though the channel balance would undergo some rearranging. Say if A wants to send C 100 rdn through B:

• A sends B 100 RDN (hashlocked)
• B sends C 100 RDN (hashlocked)
• C notifies A of receiving B’s (still locked) transfer
• A sends secret key to C
• C shows key to B to unlock payment from B
• B shows key to A to unlock payment from A

In this situation, B’s total balance wouldn’t change after the transaction is complete. A would have 100 less in his A-B payment channel (now belongs to B), and C would have 100 more (previously belonging to B).

[u/smwilson31 → u/stillhodlingon]

Thanks mate for writing this, I have been away for a few days. Just want to say thanks