That's not taking something very important about the transaction capacity of Lightning Network into account; once the channel is open, you can use the BTC in the channel infinitely (well, unless you run out of BTC of course). There is no need to close the channel, unless you need it for an on-chain transaction, or if someone you exchange BTC on Lightning with tries to start replaying old transactions.

Yep, I knew that you can "reload" the channel infinite times. The point is that in LN there must be space for a closing transaction because it's a core component of its trust model. If someone wants to scam you (returning to an older state) you would need to close the channel.

Edit: Regarding extension blocks, they would be opt-in, so even if it was true that miner could force you to use several chains (I am investigating that so I can confirm) you would never be forced to use extension blocks at all - you can stay with the "oldskool" main chain.

Yep, I knew that you can "reload" the channel infinite times. The point is that in LN there must be space for a closing transaction because it's a core component of its trust model. If someone wants to scam you (returning to an older state) you would need to close the channel.

Can you reload it with new bitcoins without on-chain locking in of those bitcoins in the channel ??I understand you can move them back and forth as many times as you want, but the contents of the channel is fixed once and for all (until settlement), no ?

Can you reload it with new bitcoins without on-chain locking in of those bitcoins in the channel ??I understand you can move them back and forth as many times as you want, but the contents of the channel is fixed once and for all (until settlement), no ?

If I have understood it the right way: You cannot use your on-chain Bitcoins to reload a LN channel without locking them. But you can receive LN Bitcoins from other LN users and "reload" the channel with them. That's what makes LN actually a "network" and an improvement over previous payment channel ideas.

The "LNCoins" would be routed to the node with whom you have opened the channel, and then paid to you. So if you observe only your channel, it would be this node who is seemingly sending them back to you, but he's compensed by other LNcoins from the origin of the "LN node chain".

Uhh, if we leave bitcoin as is with its current state, I don't think it will scale in the future and we'll have more problems in terms of fees and the speed of the transactions as well. The thing is investors and people are just contributing to the price rise because of FOMO and hopes that they will profit as well. Sooner or later, we need to develop the protocol--be it a hard fork or a soft fork.

The only thing that makes Bitcoin preferred over other cryptocurrencies is stability and safety, it is the longest running network and for fans of POW, Bitcoin is the most difficult blockchain to attack. Activating Segwit is such a huge change that it will remove this stability and safety - the competitive advantage of Bitcoin. If Segwit is activated and Bitcoin loses this stability safe haven status, why not go for coins that are technologically much more superior, the so-called generation 2 and 3 coins? Bitcoin with Segwit will offer the same level of safety as these other coins but Bitcoin will be much more backward technologically, so it makes no sense to stay invested in Bitcoin with Segwit activated.

Bitcoin should be left alone as a crypto reserve and crypto settlement network, as is, only bugfixes should be done on it.

Price action confirms that investors are fine with leaving Bitcoin as is. It does NOT need big blocks, it does NOT need Segwit. Developers, with your itchy fingers, go play with altcoins. Bitcoin is now investors safe haven, untouchable.

Your judgment is not really accurate, it does not work well in day-to-day transactions, there are too many unconfirmed transactions, this makes the system paralyzed, and the market is not okay. nail. It is possible that bitcoin does not need large blocks, but if it does, it can improve the transaction.

Can you reload it with new bitcoins without on-chain locking in of those bitcoins in the channel ??I understand you can move them back and forth as many times as you want, but the contents of the channel is fixed once and for all (until settlement), no ?

If I have understood it the right way: You cannot use your on-chain Bitcoins to reload a LN channel without locking them. But you can receive LN Bitcoins from other LN users and "reload" the channel with them. That's what makes LN actually a "network" and an improvement over previous payment channel ideas.

Ah, that's NOT how I thought it was working.

I thought that you had essentially "independent" channels in 2-2 links, but that the lightning network allowed "combined" instructions, namely if you *accept* a payment on one channel, you are *obliged* to send a payment on your other channel along the path, or the payment on the first channel was not valid.

However, bitcoins locked in one channel remained in that channel, and bitcoins locked in another channel remained locked in that channel.

At least, that's how I understood it.

In other words:

If Joe has a 1/1 channel with Alice (each one BTC) and Alice has another 1/1 channel with Bob, then:

Joe can send 0.5 BTC to Bob through Alice, in such a way, that the channel between Joe and Alice now shifts to 0.5/1.5 and the channel between Alice and Bob now shifts to 0.5/1.5.

So net, Joe lost 0.5 BTC and Bob won 0.5 BTC.

Alice won 0.5 BTC in her channel with Joe, and lost 0.5 BTC in her channel with Bob.

I thought that was the basic idea of LN.

But there's no way for Alice to take out 0.5 BTC from her channel with Joe, and put it in the channel with Bob, without settling on chain.

Uhh, if we leave bitcoin as is with its current state, I don't think it will scale in the future and we'll have more problems in terms of fees and the speed of the transactions as well. The thing is investors and people are just contributing to the price rise because of FOMO and hopes that they will profit as well. Sooner or later, we need to develop the protocol--be it a hard fork or a soft fork.

Your judgment is not really accurate, it does not work well in day-to-day transactions, there are too many unconfirmed transactions, this makes the system paralyzed, and the market is not okay. nail. It is possible that bitcoin does not need large blocks, but if it does, it can improve the transaction.

It's a fallacy and a fantasy to think that Bitcoin's purpose is to buy coffee with. It has worked great as a store of value. If there is a fork, investors will flee to alts where forks also happen but those alts offer so much more functionality. Bitcoin's value is safety, a fork of any kind will degrade Bitcoin to an alt, it will stop being a safe haven.

@dinofelis: Yes, you're right - I have clarified it in an edit of my post but you were faster

The point is that, as you say, you can only receive Bitcoins from the node with whom you have a open channel (let's call it Alice). But another user (let's call him Bob) that has a channel open with Alice can do payments to you using Alice's node. What really happens is that Bob moves coins to Alice and Alice to you. That would be the way to "reload" a channel.

@dinofelis: Yes, you're right - I have clarified it in an edit of my post but you were faster

The point is that, as you say, you can only receive Bitcoins from the node with whom you have a open channel (let's call it Alice). But another user (let's call him Bob) that has a channel open with Alice can do payments to you using Alice's node. What really happens is that Bob moves coins to Alice and Alice to you. That would be the way to "reload" a channel.

Ok, that's more or less how I understood it. But the tricky part is that, with relatively small amounts in channels, you have to be at "average wind still places" for them to be able to function a certain time before being "pushed against a wall". None of your channels can be on a "systematic flow" from one place to another. If you are, your channels will quickly be "exhausted" in the meaningful direction, at which point you have to settle and reload them (ok, you can wait for the occasional transaction in the other direction, true).

Suppose, in our example, that Joe regularly receives payments in bitcoin, and has his favorite bitcoin store at Bob's, who is a bitcoin-accepting merchant. This means that Alice will regularly see payments that go from Joe to Bob. Very rarely, Bob pays Joe in bitcoin, which would be the way to relieve Alice's exhausted channels (in one direction).

In fact, in the given situation, when Joe has done 2 payments, Alice's channels are exhausted: Joe/Alice is at 0 / 2 and Alice/Bob is at 0 / 2.

Now, Alice can wait for the occasional transaction that Bob does to Joe. But most of the time, where she is, these payments go in the other direction. So the best Alice can do, is to settle, and start again a channel with 1 / 1 with Joe, and 1 / 1 with Bob. To be exhausted again after 2 payments.

In this particular case, it makes absolutely no sense for Alice to use the LN: she does more on-chain settlements than transmitting LN transactions !

Suppose now, that Joe is rich. He has 100 BTC which he might spend at Bob's. But Alice isn't rich. She's just operating her LN node.Joe could open an asymmetric channel to Alice: 100/1. But Alice cannot open an asymmetric channel to Bob. She has only one BTC left.So she opens a 1 / 1 channel with Bob.

Joe pays two times 0.5 BTC to Bob through Alice. Joe/Alice is now at 99 / 2 ; but Alice/Bob is at 0/2. And Joe cannot send another transaction to Bob through Alice without Alice settling first with both guys, take the 2 BTC from the Joe/Alice channel, and start over:

99/1 and 1/1 respectively.

Suppose on the other hand that Alice is also rich. No problem this time:

Joe opens an 100/5 channel with Alice, and Alice opens an 100/1 channel with Bob (she knows that Bob only receives coins, and rarely spends them, but she wants some engagement from him).

This time, Joe can do 200 LN transactions through Alice towards Bob, before they are in 0/105 and 0 / 101, and need to settle.

200 transactions for 2 settlements, that's fine.

This example is, I admit, extreme. But it shows how "being a rich node" increases dramatically the efficiency of using an LN node.

I think you are right - I hadn't read your previous answer to Carlton Banks, that's why I missed your point.

The way like LN could deal with this problem is to let users set a minimum balance in every channel. So if someone like the Joe in your example abuses from a node with a pretty low balance like Alice, Alice would block Joe's node and other nodes from routing in the direction where the channel is "exhausted" - and Joe would have to search another node as "hub" or directly open a channel to Bob (what would be perhaps the best solution if he buys frequently there).

For example, if Alice has both channels with 2/2 BTC each, she could decide she doesn't want to fall below 1,5/3,5 in neither direction, and if a payment leads to her node to reach this limit, she wouldn't accept more payments in the "wrong direction".

But I admin I'm speculating here, as I haven't tested the alpha client.

Extension blocks simply produce the same outcome as Bitcoin Unlimited with a different method. The miners control which extension block they put a regular user's transaction into, and so they can create new chains at will, and force users to download the extension chains they create against the user's will.

No, sorry this is false.A miner cannot choose a random extension block, as he also cannot put a bitcoin transaction on the litecoin blockchain.Technically he can try, but the Block/Tx would be invalid or junk data.

Look at the bcoin ToTheMoon Spec and BIP141.

A user can choose to use the extension block, if he uses the witness version specified by that extension block proposal and witness programs.

A user has to transfer his bitcoins from the main blockchain to a specific extension blockchain with an "enter transaction".Then he can transfer the bitcoins within the extension blockchain, without touching the main blocks.If he needs the bitcoins back in the main blocks, he sends the bitcoins with an "exit transaction" back to the main blocks. This is a bit more complicated and will be done by miners through a resolution transaction and needs a cooldown period of 100 blocks, before the bitcoins can be spent again.

Of course the user does not need to do this manually - this is done for the user by your wallet Software. The wallet software will use a payment protocol or you'll provide a specific extension block bitcoin address or an main block address (1 and 3 adresses). For sending to an extension block from the main blockchain your wallet only has to understand the extension block addresses. It does not need process the extension block data.

To send and receive in the extension blocks your wallet has to support the specific extension block and you have to enable support for the specific opt-in extension block in your wallet.

And you don't even need to process the extension blocks, if you receive from an extension block to your main block address.Receiving from an extension block address to a main block address with a software, which is not aware of (or has not opted-in to) extension blocks is similar to how unupgraded wallets handle segwit transactions.You cannot tell if the unlock script was correct, because you don't see it, but you can tell, that you have received real bitcoins which are now under your control, and that all bitcoins in the main block are valid, which is an important reason to run a full node in the first place.

Some miner may put this to an additional extension block, but it would be invalid or just junk data without meaning, where no one ever could be forced to process that junk data. Meaning no miner would do that, because he would just waste his resources.

The important fact remains:The user is totally in control, where the transaction will end up and has meaning or in which utxo set his bitcoins are stored.There will be separate (different kind of) bitcoin addresses for extension blocks. Think different than 1 and 3 adresses for main blocks, which in fact are a recipe how to create the "lock script" for the outputs in a bitcoin transaction. In fact the recipe from 1 (P2PKH) addresses are completely incompatible with extension blocks.3 (P2SH) Addresses are invalid, because the recipe tells to store the output in the canonical block utxo and not in the extension block utxo (segwit can use nested P2SH, because it uses the main block utxo)

Thank you for your informed answer, MoinCoin! I'm still by no means an extension block expert but I still consider it one of the best "intermediate-level" scaling proposals (as a 2nd layer between the main chain and LN).

I thought a little bit more about the LN problem described by dinofelis, and I think it could be possible for Alice to reload her "exhausted" channel finding a route from her "full" channel to it.

So if the exhausted channel is the channel between Alice and Bob (0/2), while her channel to Joe is full (2/0), then she may try to find a forth party (let's call her Carol) who has connections with Joe and Bob and can route a 1 BTC payment to her first channel. Alice pays Joe 1 BTC, Joe pays Carol 1 BTC and Carol Bob 1 BTC who pays it to Alice getting the channel again to 1/1.

Obviously this is only possible if Bob has no problem routing a payment to Alice via this channel.

Thank you for your informed answer, MoinCoin! I'm still by no means an extension block expert but I still consider it one of the best "intermediate-level" scaling proposals (as a 2nd layer between the main chain and LN).

I thought a little bit more about the LN problem described by dinofelis, and I think it could be possible for Alice to reload her "exhausted" channel finding a route from her "full" channel to it.

So if the exhausted channel is the channel between Alice and Bob (0/2), while her channel to Joe is full (2/0), then she may try to find a forth party (let's call her Carol) who has connections with Joe and Bob and can route a 1 BTC payment to her first channel. Alice pays Joe 1 BTC, Joe pays Carol 1 BTC and Carol Bob 1 BTC who pays it to Alice getting the channel again to 1/1.

Obviously this is only possible if Bob has no problem routing a payment to Alice via this channel.

This isn't the first time I've seen this idea discussed and if I'm not mistaking the lightning development is already looking at this sort of solution.

@dinofelisAre you familiar with the LTCP from Sergio Demian Lerner (RSK Labs)?AFAIK it is especially suitable for refilling payment channels, but however the Bitcoin architecture makes it harder, than an account based system like Rootstock or Ethereum, but nonetheless it could provide immense blockspace savings for bitcoin.