Why do we need a "routing" process in Lightning Network?

Why do we need a "routing" process in Lightning Network?

If I am wrong, please correct me.

If we simplify Lightning Network, it seems to work similar to this simple unidirectional payment channel between two parties (although, Lightning Network is a bidirectional).

So we may simplify the process of a payment between two parties in Lightning Network as follows:

(1) the sender and recipient just need to create a channel and deploy the contract and then the sender puts the recipient's address in the contract as recipient.

(2) Then any agreed number of off-chain transactions will be done between sender and recipient such that the sender's address for each mico-payment will be verified by recipient.

(3) Eventually, a settlement will be done via an on-chain transaction, by which the recipient will receive the total amount the contract.

In a first view, it seems no need for "routing" process.

So, can we now ask that why do we need a routing process for performing a payment in Lightning Network?

P.S. I refer you to the Lightning Network website, where it's mentioned that:

"By creating a network of these two-party ledger entries, it is possible to find a path across the network similar to routing packets on the internet."

Note: The payment channels are composable, meaning that If A and B have a payment channel, and B and C have another, then A can pay C through B. But the matter is that there is a fee incentive for intermediaries. Now the question is which one is more affordable?

(1) Doing like above approach?

Or

(2) A and C create another channel between themselves without paying to B and without need for routing ?

So, the answer of necessity of need for a routing process in Lightning Network is dependent on affordability of paying to one or multiple intermediaries instead of paying for a new direct channel without intermediary?

https://ift.tt/2r7DRnm

Comments

Popular posts from this blog

Bitcoin Core errors with database block

sendrawtransaction and txn-mempool-conflict