Could the lightning network solve the block size problem?

[Carlton Banks]

I watched the presentation on the lightning network and if it allows regular payments along with the option for this side enhancement then it could help a lot with the block size problem.

The lightning network basically allows people to set up payment nodes to run transactions which can be as many transactions as you want in a certain amount of time without touching the blockchain. At the end of the time period the final balance of the transaction is posted to the blockchain. The people running the nodes have no way to interfere with the transactions and it allows for more anonymity.

I am cautiously optimistic about it.

https://www.youtube.com/watch?v=-aI4inWxBwk

HMM

1. Increase the blocksize by a "decent" amount to accommodate transaction volume by changing ONE LINE OF CODE.

OR

2. Create "the lightning network" to accommodate transaction volume by creating an entirely new system to piggy back on top of bitcoin by adding THOUSANDS OF LINES OF CODE.




Answer = 1  

You got it in 1 (well, two really).


BIP101 is the most crude way of "solving" the issue, other than just deleting that one line of code completely, of course.



Sadly, you will also "solve" the decentralisation "problem" at the same time. Please spare us these armchair software engineering decisions, you are either incapable of understanding the issue, or willfully ignorant of the consequences.

The (technical) debate has long since moved on; no one except a bunch of shills and ignorants are trying to offer Hearn and Andresen either as the new team or their hijack-as-a-technical-proposal as the new software.


Give it up, the Bitcoin userbase doesn't want to be constantly harassed by mindless acolytes and sociopathic pushers. XT and BIP101 threads are nearly gone, mostly people are having more productive discussions about totally different topics, scaling or not.

And if you've got a better idea than the lightning network to scale transaction rates, let's hear it (no, not BIP101....)

[johoe]

1. Increase the blocksize by a "decent" amount to accommodate transaction volume by changing ONE LINE OF CODE.

OR

2. Create "the lightning network" to accommodate transaction volume by creating an entirely new system to piggy back on top of bitcoin by adding THOUSANDS OF LINES OF CODE.

I'd say both

The lightning network is a great invention.  It supports low-overhead nano-payments with near instant confirmation times that are fully backed by bitcoins.  It has also a few disadvantages:

• If your hub is down, you can't send or receive payments.  You either need to wait until your hub is up again or receive the bitcoins by the pre-signed transactions, which takes several days.
• Hubs may censor your transactions.  Sure, you can always choose another hub or use bitcoin directly.
• You need to establish a payment channel on the blockchain beforehand.  This is a locked coin on the blockchain that contains enough funds to cover your funds that you have at the hub.  The hub must fund it with his own coins to guarantee for the maximum balance that you may receive.  So it is quite capital intensive to run a big hub.  Not only does the hub not get the funds that the customer put there (which is a good thing) but the hub also has to cover for the maximum that its customers may put in their accounts without requiring a new on-chain transaction.
• The security of the lightning network relies on the fact that nobody can spam the blockchain to prevent the confirmation of a fixed fee transaction for a few days.  Do you think this is possible with the current block size?
• If you don't constantly watch the blockchain, your hub may cheat you and steal your coins after a few days.
• There is no implementation, yet.

We need a larger block size anyway.  The lightning network may help to reduce the current growth, but the size of the blocks have to grow.  Also we should at least kick the can to ensure that the current growth can continue short term until we know the lightning network works and is accepted by the community.   And if we keep the block size small to get fees of 20 $ per on-chain transaction (like some small block proponents want), we would basically prevent that people can avoid LN because of censoring or other reasons.

[RoadTrain]

Then the question arises: If institutions still need to use the traditional way of clearing, then why do they use LN at all? They can just open an account at each other like how it is done between banks today

Because LN provides the way of doing so trustlessly -- one cannot steal funds, and in case of uncooperative behavior the channel is resolved on the blockchain.

[RoadTrain]

1. Increase the blocksize by a "decent" amount to accommodate transaction volume by changing ONE LINE OF CODE.

OR

2. Create "the lightning network" to accommodate transaction volume by creating an entirely new system to piggy back on top of bitcoin by adding THOUSANDS OF LINES OF CODE.

I'd say both

The lightning network is a great invention.  It supports low-overhead nano-payments with near instant confirmation times that are fully backed by bitcoins.  It has also a few disadvantages:

• If your hub is down, you can't send or receive payments.  You either need to wait until your hub is up again or receive the bitcoins by the pre-signed transactions, which takes several days.
• Hubs may censor your transactions.  Sure, you can always choose another hub or use bitcoin directly.
• You need to establish a payment channel on the blockchain beforehand.  This is a locked coin on the blockchain that contains enough funds to cover your funds that you have at the hub.  The hub must fund it with his own coins to guarantee for the maximum balance that you may receive.  So it is quite capital intensive to run a big hub.  Not only does the hub not get the funds that the customer put there (which is a good thing) but the hub also has to cover for the maximum that its customers may put in their accounts without requiring a new on-chain transaction.
• The security of the lightning network relies on the fact that nobody can spam the blockchain to prevent the confirmation of a fixed fee transaction for a few days.  Do you think this is possible with the current block size?
• If you don't constantly watch the blockchain, your hub may cheat you and steal your coins after a few days.
• There is no implementation, yet.

We need a larger block size anyway.  The lightning network may help to reduce the current growth, but the size of the blocks have to grow.  Also we should at least kick the can to ensure that the current growth can continue short term until we know the lightning network works and is accepted by the community.   And if we keep the block size small to get fees of 20 $ per on-chain transaction (like some small block proponents want), we would basically prevent that people can avoid LN because of censoring or other reasons.

Fair points, I like it. To be honest, I doubt Bitcoin can bear $20 fees even with LN, as LN still depends on the blockchain. I'm also not sure why $20? E.g. if we remove subsidy now, it will require only ( ) $2.5 fee per tx in order to keep the dollar reward per block steady. Of course, assuming other things being equal

IMO the most realistic scenario is that we raise the limit in 2016, and it buys is time to explore all options (be it LN or some kind of fliexible blocksize limit et cetera).

[johnyj]

Then the question arises: If institutions still need to use the traditional way of clearing, then why do they use LN at all? They can just open an account at each other like how it is done between banks today

Because LN provides the way of doing so trustlessly -- one cannot steal funds, and in case of uncooperative behavior the channel is resolved on the blockchain.

I still don't really understand how a channel works under dispute, e.g. both party claim different truth. I think that is not possible without a judge-like third party involved

And the traditional approach is also trustless: Bitpay have a 1000 btc account at Coinbase, Coinbase have a 1000 btc account at Bitpay, if Bitpay run away, his account at Coinbase will belong to Coinbase, vice versa

[da2ce7]

I still don't really understand how a channel works under dispute, e.g. both party claim different truth. I think that is not possible without a judge-like third party involved

And the traditional approach is also trustless: Bitpay have a 1000 btc account at Coinbase, Coinbase have a 1000 btc account at Bitpay, if Bitpay run away, his account at Coinbase will belong to Coinbase, vice versa

LN are no more of a learning curve than what Bitcoin was 4 years ago.

In the case of a dispute, then the most resent tx is sent (with a big fee) to the Bitcoin network. LN work by constantly trading would-be-valid Bitcoin transactions, these transactions never need to go on the Bitcoin network unless one of the parties doesn't respond.

In the case that one of the parties doesn't respond, then after a timeout, the latest Bitcoin tx is released on the network, spending both the anchors, and thus closing the channel. -  Everything was agreed upon up-to that point, so very little to Bitcoin was lost (maybe a few cents in fees).

Think about it: it works in the opposite way to how things work atm:

1. You go to the cafe, and buy a coffee with Bitcoin.
2. The cafe gets a Bitcoin TX, and has to wait for a block for it to be confimed.
3. Everything is settled after the tx is in the block chain. (about 10 min or more).

(with lightning):
1. You go to the cafe, and buy a coffee with LN.
2. You update the anchor TX to the cafe, and send the updated TX to the cafe. (instant).
3. No need for settlement since you come in every day.

- See in the general case, nothing ever touches the blockchain. - there is no 'confirmation times'

- Only in the case where there is disagreement dose the 'confirmation time' matter - only to resolve things back to the 'last known good state'.

- It isn't possible to double-spend a LN transaction, since the lock time is longer than the time for the Cafe to release the last know tx.

- if the Cafe goes out of business, then you can get your Bitcoin back, maybe after 6 weeks.  But you only put 20$ at a time, so this doesn't bother you so much.

[RoadTrain]

Then the question arises: If institutions still need to use the traditional way of clearing, then why do they use LN at all? They can just open an account at each other like how it is done between banks today

Because LN provides the way of doing so trustlessly -- one cannot steal funds, and in case of uncooperative behavior the channel is resolved on the blockchain.

I still don't really understand how a channel works under dispute, e.g. both party claim different truth. I think that is not possible without a judge-like third party involved

And the traditional approach is also trustless: Bitpay have a 1000 btc account at Coinbase, Coinbase have a 1000 btc account at Bitpay, if Bitpay run away, his account at Coinbase will belong to Coinbase, vice versa

As far as I'm aware, OP_CHECKLOCKTIMEVERIFY is used to ensure that only the most recent tx is valid.

In case of traditional approach, it's not trustless. Imagine that Alice on BitPay transacts 100 BTC to Bob on Coinbase. BitPay deducts Alice's balance by 100 BTC and deducts 100 BTC from Coinbase's account with it. Now Coinbase credits Bob by 100 BTC. Effectively, it means that Coinbase is being owed 100 BTC by BitPay, which is supposed to clear at the end of the day. But if BitPay runs away with money, Coinbase is short 100 BTC!

[johnyj]

Then the question arises: If institutions still need to use the traditional way of clearing, then why do they use LN at all? They can just open an account at each other like how it is done between banks today

Because LN provides the way of doing so trustlessly -- one cannot steal funds, and in case of uncooperative behavior the channel is resolved on the blockchain.

I still don't really understand how a channel works under dispute, e.g. both party claim different truth. I think that is not possible without a judge-like third party involved

And the traditional approach is also trustless: Bitpay have a 1000 btc account at Coinbase, Coinbase have a 1000 btc account at Bitpay, if Bitpay run away, his account at Coinbase will belong to Coinbase, vice versa

As far as I'm aware, OP_CHECKLOCKTIMEVERIFY is used to ensure that only the most recent tx is valid.

In case of traditional approach, it's not trustless. Imagine that Alice on BitPay transacts 100 BTC to Bob on Coinbase. BitPay deducts Alice's balance by 100 BTC and deducts 100 BTC from Coinbase's account with it. Now Coinbase credits Bob by 100 BTC. Effectively, it means that Coinbase is being owed 100 BTC by BitPay, which is supposed to clear at the end of the day. But if BitPay runs away with money, Coinbase is short 100 BTC!

Yes, that is a risk, banks must constantly watch the net exposure. I guess 1000 BTC is 1% of their funds, and 100 BTC is 0.1% of their funds, so the loss is still controllable

And can you explain how such a situation will be solved in LN?

[RoadTrain]

Then the question arises: If institutions still need to use the traditional way of clearing, then why do they use LN at all? They can just open an account at each other like how it is done between banks today

Because LN provides the way of doing so trustlessly -- one cannot steal funds, and in case of uncooperative behavior the channel is resolved on the blockchain.

I still don't really understand how a channel works under dispute, e.g. both party claim different truth. I think that is not possible without a judge-like third party involved

And the traditional approach is also trustless: Bitpay have a 1000 btc account at Coinbase, Coinbase have a 1000 btc account at Bitpay, if Bitpay run away, his account at Coinbase will belong to Coinbase, vice versa

As far as I'm aware, OP_CHECKLOCKTIMEVERIFY is used to ensure that only the most recent tx is valid.

In case of traditional approach, it's not trustless. Imagine that Alice on BitPay transacts 100 BTC to Bob on Coinbase. BitPay deducts Alice's balance by 100 BTC and deducts 100 BTC from Coinbase's account with it. Now Coinbase credits Bob by 100 BTC. Effectively, it means that Coinbase is being owed 100 BTC by BitPay, which is supposed to clear at the end of the day. But if BitPay runs away with money, Coinbase is short 100 BTC!

Yes, that is a risk, banks must constantly watch the net exposure. I guess 1000 BTC is 1% of their funds, and 100 BTC is 0.1% of their funds, so the loss is still controllable

And can you explain how such a situation will be solved in LN?

To be honest, I'm still not good enough with LN understanding, so I don't want to make errors with explanations. So don't take this for granted.

When a channel is created, a corresponding refund transaction is created as well, that gives back the coins. Let's say it's locked for 30 days.
Now, when a intra-channel transaction is made, it's locked for 29 days. And with every subsequent transaction the locktime is decreasing. It means that the most recent transaction has the lowest locktime, and thus will be the only one confirmed when channel is closed.

[johnyj]

When a channel is created, a corresponding refund transaction is created as well, that gives back the coins. Let's say it's locked for 30 days.
Now, when a intra-channel transaction is made, it's locked for 29 days. And with every subsequent transaction the locktime is decreasing. It means that the most recent transaction has the lowest locktime, and thus will be the only one confirmed when channel is closed.

I can imagine that both Coinbase and Bitpay creating a 24 hour time locked transaction, where each party pay 1000 coins to the counterpart (The transaction have two input and two output)

Then, when Alice is paying Bob 100 bitcoin, a corresponding transaction of 100 bitcoin will be reflected into this balance, thus a new transaction of Coinbase paying Bitpay 1000 bitcoin and Bitpay paying Coinbase 900 bitcoin are generated and pushed into payment channel, replacing the previous one

Then if Coinbase went down following this transaction, this last transaction will make sure at the end of the day, Bitpay would still receive 100 bitcoin

In order to do this, both funding address of the time locked payment must be locked and prohibit further spending from that address until the channel is closed (What if a malicious user created an extremely short time locked transaction, refuse to pay anything and close the channel immediately?)

Still, someone has to push the new transaction into payment channel, and how to make sure this new transaction correctly reflect the reality is the key. Since the payment channel does not know anything about Alice or Bob's trading activity, it is the responsibility of Coinbase to push in the correct transaction, and at the same time it must inform the Bitpay to credit Bob's account with 100 bitcoin. It seems the transactions in payment channel must have some other spaces to specify the address of initial sender and final beneficiary

[Elwar]

One benefit of locking bitcoins is lower trade velocity of those coins which would result in higher bitcoin prices.

If bitcoins become a commodity which you can create a hub and make more bitcoins then holding your bitcoins will become a feature that makes you money to facilitate more spending.

It's like instead of buying an expensive miner, you buy expensive bitcoins.

[Carlton Banks]

One benefit of locking bitcoins is lower trade velocity of those coins which would result in higher bitcoin prices.

If bitcoins become a commodity which you can create a hub and make more bitcoins then holding your bitcoins will become a feature that makes you money to facilitate more spending.

It's like instead of buying an expensive miner, you buy expensive bitcoins.

Perhaps I'm missing something, but surely the money in lightning payment channels will move around within the channel/s no differently to how/when it moves in any other system? (i.e. if/when the owner chooses to move money, it goes). If someone wanted to use money from 1 channel to pay on another, the experience would have to be pretty seamless from the users perspective ( and no doubt channel operators would pre-empt this by using/creating inter-channel settlement channels...)

If the money is no more immobilized than usual, how will that boost the price? Just because it's off-chain, or something I'm not appreciating? Come to think of it, low money velocity depresses the exchange rate of that money, so I'm totally not sure what you mean by this, Elwar?

[Searing]

 kinda as an aside we can't get the current devs to agree to a block size increase....it seems doubtful the lightning network or any other major
code will be coming any time soon w/o a major shake up...but being open source....this could just go along in 'slug movement' mode for a long long time yet imho

 too much posturing and egos involved...hope I'm wrong but with all the power/egos and money at stake a major win will be just these guys getting 'some' kind
of block size increase protocol going.....it is my view...they are 'never' gone move fast on anything and the more complicated the less likely it will be to be added

again hope I'm wrong but past actions and tantrums are not encouraging

[RoadTrain]

When a channel is created, a corresponding refund transaction is created as well, that gives back the coins. Let's say it's locked for 30 days.
Now, when a intra-channel transaction is made, it's locked for 29 days. And with every subsequent transaction the locktime is decreasing. It means that the most recent transaction has the lowest locktime, and thus will be the only one confirmed when channel is closed.

I can imagine that both Coinbase and Bitpay creating a 24 hour time locked transaction, where each party pay 1000 coins to the counterpart (The transaction have two input and two output)

Then, when Alice is paying Bob 100 bitcoin, a corresponding transaction of 100 bitcoin will be reflected into this balance, thus a new transaction of Coinbase paying Bitpay 1000 bitcoin and Bitpay paying Coinbase 900 bitcoin are generated and pushed into payment channel, replacing the previous one

Then if Coinbase went down following this transaction, this last transaction will make sure at the end of the day, Bitpay would still receive 100 bitcoin

In order to do this, both funding address of the time locked payment must be locked and prohibit further spending from that address until the channel is closed (What if a malicious user created an extremely short time locked transaction, refuse to pay anything and close the channel immediately?)

Still, someone has to push the new transaction into payment channel, and how to make sure this new transaction correctly reflect the reality is the key. Since the payment channel does not know anything about Alice or Bob's trading activity, it is the responsibility of Coinbase to push in the correct transaction, and at the same time it must inform the Bitpay to credit Bob's account with 100 bitcoin. It seems the transactions in payment channel must have some other spaces to specify the address of initial sender and final beneficiary

From what I understand, an intra-channel transaction is valid only when both parties agree on it (sign it?). This includes checking balances, locktime and such.

LN is relatively low-level protocol, so the parties will still have to communicate somehow. BitPay and Coinbase will need a separate communication protocol to update user balances. But it's only because they are centralized services serving many users. That's not the only use case for LN. In every use case, there must be a communication protocol between parties, be it Skype, email or some automated stuff.

[Elwar]

One benefit of locking bitcoins is lower trade velocity of those coins which would result in higher bitcoin prices.

If bitcoins become a commodity which you can create a hub and make more bitcoins then holding your bitcoins will become a feature that makes you money to facilitate more spending.

It's like instead of buying an expensive miner, you buy expensive bitcoins.

Perhaps I'm missing something, but surely the money in lightning payment channels will move around within the channel/s no differently to how/when it moves in any other system? (i.e. if/when the owner chooses to move money, it goes). If someone wanted to use money from 1 channel to pay on another, the experience would have to be pretty seamless from the users perspective ( and no doubt channel operators would pre-empt this by using/creating inter-channel settlement channels...)

If the money is no more immobilized than usual, how will that boost the price? Just because it's off-chain, or something I'm not appreciating? Come to think of it, low money velocity depresses the exchange rate of that money, so I'm totally not sure what you mean by this, Elwar?

From what I gather and was mentioned in the video, each "hub" needs a significant amount of bitcoins in order to operate.

Imagine there is a new wireless Internet service (BitCast) in town that uses the Lightning Network via the BitPay payment hub. As a user you put .5 bitcoins toward the BitPay payment service for a month time lock. You lock .5 bitcoins and BitPay locks .5 bitcoins to match. Then BitCast locks in .5 with BitPay and BitPay locks in .5 bitcoins with BitCast (I may be way off on how many people need to lock bitcoins, but for sure the hub locks bitcoins). That is 2 bitcoins that will not be on the exchanges for a month.

In the meantime you're paying .0001 bitcoins per minute for your web service, paying by the minute. By the end of the month you spent 1000 minutes on BitCast's wireless connection, 1000 transactions through BitPay to BitCast. The Bitcoin blockchain receives one transaction of .1 bitcoins on the blockchain and everyone gets their locked coins back (.4 for you and .6 for BitCast). Additionally, BitPay might charge a fee for their service as a hub. So their 2 bitcoin investment might garner them .02 bitcoins for that transaction (a 12% yearly return on their bitcoin holdings).

If BitCast has 10,000 customers, that's 5000 bitcoins that are not available to be traded that month.

When I speak of money velocity I refer to the amount of time bitcoins are kept off of the exchange. If a remittance company can transfer $10 billion worth of bitcoins in 1 hour (fiat to bitcoin -> bitcoin back to fiat) then the bitcoin price will not be affected. If that same remittance company transferred that same amount and it took a week for the bitcoin to bitcoin transfer to go through, then that's $10 billion worth of wealth in the Bitcoin economy for that week. That would certainly push the price up.

If 10 million bitcoins are being used as LN hubs, that leaves only 4 million bitcoins available for the rest of the economy.

[RoadTrain]

Exchanges can participate as well. If you have a channel with BitPay, and BitPay has a channel with Bitstamp, then you can transact your locked coins to Bitstamp and sell them (if they allow it, though).

[Carlton Banks]

Imagine there is a new wireless Internet service (BitCast) in town that uses the Lightning Network via the BitPay payment hub. As a user you put .5 bitcoins toward the BitPay payment service for a month time lock. You lock .5 bitcoins and BitPay locks .5 bitcoins to match. Then BitCast locks in .5 with BitPay and BitPay locks in .5 bitcoins with BitCast (I may be way off on how many people need to lock bitcoins, but for sure the hub locks bitcoins). That is 2 bitcoins that will not be on the exchanges for a month.

Now I do see what you mean. So there are other attractions from that perspective also; the money locked in channels is by definition locked into commercial activity, which I think can be quantified as a metric that feeds into that array of information that determines the exchange rate (payment channel transactions would I think be distinct on the blockchain, so it's not a case of relying on self-published figures).

This only affects the supply side at the exchanges, demand for currencies is difficult to affect so directly. But it's still a powerful effect, particularly because of that extra information it creates (that distinguishes between types of activity on the network)

[johnyj]

I don't think high frequency regular payments will be handled that way. Mobile operators used to operate on minute based charging, and then they found out that added transaction/billing management did not worth the effort, so they switched to another model, offering limitless call time with a fixed monthly rate, achieving even higher profit and user satisfaction

Similarly, it will be a huge pain if you need to have both party to sign the transaction in payment channel for each of millions of transactions during a day. They might come up with a better model to reduce the management overhead

[Blawpaw]

I watched the presentation on the lightning network and if it allows regular payments along with the option for this side enhancement then it could help a lot with the block size problem.

The lightning network basically allows people to set up payment nodes to run transactions which can be as many transactions as you want in a certain amount of time without touching the blockchain. At the end of the time period the final balance of the transaction is posted to the blockchain. The people running the nodes have no way to interfere with the transactions and it allows for more anonymity.

I am cautiously optimistic about it.

https://www.youtube.com/watch?v=-aI4inWxBwk

I guess that the bitcoin lightning network is one of the best proposal's that can really solve the block size issue. apart from the Bitcoin Lightning network you have the Sidechains project and the colored coins.

[Carlton Banks]

I watched the presentation on the lightning network and if it allows regular payments along with the option for this side enhancement then it could help a lot with the block size problem.

The lightning network basically allows people to set up payment nodes to run transactions which can be as many transactions as you want in a certain amount of time without touching the blockchain. At the end of the time period the final balance of the transaction is posted to the blockchain. The people running the nodes have no way to interfere with the transactions and it allows for more anonymity.

I am cautiously optimistic about it.

https://www.youtube.com/watch?v=-aI4inWxBwk

I guess that the bitcoin lightning network is one of the best proposal's that can really solve the block size issue

It only resolves that issue indirectly, and not comprehensively either (as payment channels are not necessarily designed to be suitable for every type of transaction). Lightning specifically addresses transaction scaling, not the blocksize limit (remember that the transaction rate is the actual point of this whole debate, NOT the blocksize)