Topic: Could the lightning network solve the block size problem? (Read 3869 times)

Lightning transactions are going to be cheaper & more private than regular blockchain transactions.

Then you say it is not true that most of the developers are heavily invested into the network and others too? Can you explain where they expect the return of investment from if not by fees? Or do you say that they did not invest at all?

After skimming over LN whitepaper I noticed that it doesn't analyze conditions in which necessity to update channels will become a bottleneck. Have I just missed them because skipped some too technical parts?

Underrated post. This is one of the most succinct descriptions of the LN I've read. Thank you, da2ce7.

Lowers fees?  That's great to hear. But new worries are : need of third party intervention makes us slightly go away from bitcoins prime motto. But scaling the block size would be great solution we can enjoy from this lightning network. So, we need to compromise a little thing.

I do not understand why people think that the lightning network is going to have high fees? Luke-jr even said somewhere that it would have lower fees than using the blockchain. Yes, you can create payment channels with anyone that you want. You can find many simple explanations by clicking on this link.

How is the anonymity of the users compared to bitcoin with the lightning network? Or is it that the lightning network would work with a website, service or exchange only anyway so that those know their customers?

If this really would happen and leading to higher fees fees because of too small blocks then what about personal transactions? Can payment channels be established for private person to private person and without high fees?

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)

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.

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

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)

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).

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.

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.

 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

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?

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.

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

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.

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?