how will lightning users find compatible payment channels?

Mashuri

full member

Activity: 135

Merit: 107

Quote from: cbeast on April 17, 2015, 04:36:40 AM

Exactly. Fees will be the reward in this case, not an altcoin that so many others are convinced are needed. Fees are something everyone understands.

Agreed. Fees within the same system are far more transparent. An altcoin involves other hard-to-calculate transactions costs, such as slippage, variable security risks, etc.

cbeast

donator

Activity: 1736

Merit: 1014

Let's talk governance, lipstick, and pigs.

Quote from: Mashuri on April 15, 2015, 08:23:03 PM

Looks like I schooled myself with that scenario. I see what problem you're pointing out now. AB's funding transaction and BC's funding transaction cannot interact with each other directly. It doesn't matter what B's output on AB is. If B's output on BC is 0 then he/she cannot send any more BTC on that channel without transacting on the block chain.

I think the solution to this will be multifaceted. As the network grows, BGP-like routing systems can emerge to find working paths for transactions. Also, I see a market incentive for hub-and-spoke 2-of-3 payment channels emerging, with well-funded, well-connected hubs charging higher fees.

Exactly. Fees will be the reward in this case, not an altcoin that so many others are convinced are needed. Fees are something everyone understands.

Mashuri

full member

Activity: 135

Merit: 107

Looks like I schooled myself with that scenario. I see what problem you're pointing out now. AB's funding transaction and BC's funding transaction cannot interact with each other directly. It doesn't matter what B's output on AB is. If B's output on BC is 0 then he/she cannot send any more BTC on that channel without transacting on the block chain.

I think the solution to this will be multifaceted. As the network grows, BGP-like routing systems can emerge to find working paths for transactions. Also, I see a market incentive for hub-and-spoke 2-of-3 payment channels emerging, with well-funded, well-connected hubs charging higher fees.

Mashuri

full member

Activity: 135

Merit: 107

Quote from: cbeast on April 15, 2015, 06:58:00 PM

Quote from: Mashuri on April 15, 2015, 06:22:31 PM

Quote from: cbeast on April 15, 2015, 05:54:31 PM

Quote from: Mashuri on April 15, 2015, 05:30:08 PM

Couldn't it just be broken up into a bunch of small transactions instead? In the lightning network it would still get through pretty fast, and with arguably less risk (only the currently "active" small transaction is at risk of failing). When faced with a narrow data bus, up the frequency.

That would require closing the contract and paying mining fees. If mining fees go up substantially, then you end up paying a lot more. The point of Lightning is to rarely pay mining fees.

No it wouldn't. The whole point of a payment channel is that multiple payments can be made on it without submitting to the block chain. The only reason to do so would be if a party is uncooperative.

I was under the impression that payments could be made with credit already nLockTimed into the system so you wouldn't need to commit more money into it than is owed to you.

I get the feeling we're not on the same page here. Let me know if this scenario helps to answer your original question:

A has a channel with B and B has a channel with C, but A and C do not have a channel with each other. A wants to send 10 BTC to C through B but B only has a 1 BTC balance in his/her channel with C (his balance with A doesn't matter, since he will be pulling funds from him/her). For simplicity, we'll assume there are no fees between any of these parties. A creates a 1 BTC Hashed Timelock Contract (HTLC1) and passes it to B. B then creates a HTLC for 1 BTC (HTLC2) and passes it to C. C unlocks HTLC2 and pulls 1 BTC from B. This allows B to unlock HTLC1 and pull 1 BTC from A. The transfer of 1 BTC is now complete. Notice that B never has to commit more funds from outside his channels. His balance fluctuates between 0 and 1 BTC, finalizing back to its original 1 BTC. A, B and C now repeat the same procedure 9 more times. In the lightning network this can all happen in a matter of milliseconds.

Edited for clarity.

cbeast

donator

Activity: 1736

Merit: 1014

Let's talk governance, lipstick, and pigs.

Quote from: Mashuri on April 15, 2015, 06:22:31 PM

Quote from: cbeast on April 15, 2015, 05:54:31 PM

Quote from: Mashuri on April 15, 2015, 05:30:08 PM

Couldn't it just be broken up into a bunch of small transactions instead? In the lightning network it would still get through pretty fast, and with arguably less risk (only the currently "active" small transaction is at risk of failing). When faced with a narrow data bus, up the frequency.

That would require closing the contract and paying mining fees. If mining fees go up substantially, then you end up paying a lot more. The point of Lightning is to rarely pay mining fees.

No it wouldn't. The whole point of a payment channel is that multiple payments can be made on it without submitting to the block chain. The only reason to do so would be if a party is uncooperative.

I was under the impression that payments could be made with credit already nLockTimed into the system so you wouldn't need to commit more money into it than is owed to you.

Mashuri

full member

Activity: 135

Merit: 107

Quote from: cbeast on April 15, 2015, 05:54:31 PM

Quote from: Mashuri on April 15, 2015, 05:30:08 PM

Couldn't it just be broken up into a bunch of small transactions instead? In the lightning network it would still get through pretty fast, and with arguably less risk (only the currently "active" small transaction is at risk of failing). When faced with a narrow data bus, up the frequency.

That would require closing the contract and paying mining fees. If mining fees go up substantially, then you end up paying a lot more. The point of Lightning is to rarely pay mining fees.

No it wouldn't. The whole point of a payment channel is that multiple payments can be made on it without submitting to the block chain. The only reason to do so would be if a party is uncooperative.

cbeast

donator

Activity: 1736

Merit: 1014

Let's talk governance, lipstick, and pigs.

Quote from: Mashuri on April 15, 2015, 05:30:08 PM

Couldn't it just be broken up into a bunch of small transactions instead? In the lightning network it would still get through pretty fast, and with arguably less risk (only the currently "active" small transaction is at risk of failing). When faced with a narrow data bus, up the frequency.

That would require closing the contract and paying mining fees. If mining fees go up substantially, then you end up paying a lot more. The point of Lightning is to rarely pay mining fees.

Mashuri

full member

Activity: 135

Merit: 107

Couldn't it just be broken up into a bunch of small transactions instead? In the lightning network it would still get through pretty fast, and with arguably less risk (only the currently "active" small transaction is at risk of failing). When faced with a narrow data bus, up the frequency.

cbeast

donator

Activity: 1736

Merit: 1014

Let's talk governance, lipstick, and pigs.

If larger amounts are transmitted and they want to use payment channels, but the other party doesn't have enough to credit in another channel because they already have large channels open, then how will they find channels capable of linking them? It seems like a 6 Degrees of Cheryl's Birthday problem.

Topic: how will lightning users find compatible payment channels? (Read 1013 times)