Topic: Bitcoin works as intended, price confirms (Read 1600 times)

@dinofelis
Are 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.

As a softfork LTCP would use extension blocks on bitcoin to provide an account based system layer
https://www.docdroid.net/QHJX8Ml/luminotransactioncompressionprotocolltcp.pdf.html#page=8

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.

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.

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)

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.

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.

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

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.

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.

Anyone any comments if I'm wrong ?

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.

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.

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

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 ?

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.

Care to explain ?  Suppose Alice and Bob set up a channel.  Alice puts in 1 BTC, and Bob puts in 1 BTC too.
The channel derives its security from the fact that the balance of the channel will always be between (2 BTC for Alice / 0 BTC for Bob) and (0 BTC for Alice, 2 BTC for Bob), right ?  It is a stack of non-published transactions from Alice or from Bob towards the "actual state", with "guard transactions" that allow the duped party to get everything (here, 2 BTC) if ever the counter party publishes a previous transaction that is not the last balance.  At least, that's my understanding of it.

Now, suppose that the network is such, that 5 times in a row, LN channels go through the Alice/Bob link in the same direction, from Alice to Bob, with 0.2 BTC to transact.  Now, Alice is at 0 BTC in the channel, and Bob is at 2 BTC in the channel.  There is no channelling possible any more from Alice to Bob.  Note that this probably means, that Alice had another channel open, say, to Joe.   If that channel was 1 BTC/1BTC initially, it is now also 0 BTC / 2 BTC, in the favour of Alice.

Alice still has her 2 BTC from the start (of which she locked in 1 BTC to Bob, and 1 BTC to Joe).  But it is now totally in her Joe channel, and nothing any more in her Bob channel.

You are saying that Alice doesn't have to settle.  She can wait for a payment in the other direction.  Sure.  But if her node is principally on a flux "from Joe to Bob" (say, Joe is closer to a big spender, and Bob is closer to a bitcoin accepting shop), her node is essentially "dead", and our 3 people have bitcoins locked up in channels that will wait for a long time before acting again.

The only thing to do, is essentially, to settle the channels, free up the 2 BTC that Alice had locked up in the channels, and start over again (after a day or so, when the time lock expires).

Did I get something wrong ?

No, you're wrong

If you run out of BTC in a Lightning channel, the channel remains. All you have to do is get something paid into it, it's called commerce.

Stability wont happen even though its being slowly accepted by some countries as of now.System of bitcoin would remain as it is and investors and traders would really remain on the field since price wont really be go stable no matter what and that's the beauty of bitcoin on my part not only to myself but on most people for sure.

I totally agree with it and that bitcoins blocksize is of no issue but just an issue being hyped by the miners so that they can have control over bitcoin and they can increase the miner fee. Bitcoin is good as it is and it doesnt need upgrading at the moment. Bitcoin is growing up and will continue to increase when Australia starts to adopts bitcoin on July.

What these very vocal people on the internet don't realize is that the sooner the system reaches 'stability', the sooner fund managers will move in.

This is the big problem, and why the LN has a HUGE centralization pressure.  Only hubs that can link to *a lot of customers* and hence lock in a lot of coins, and have *big amounts* locked in with other big hubs, can hope to average out a lot of payments so as to avoid channels to get exhausted.  If you only have, say, 4 BTC, and you lock them up in 8 channels, each of them 0.5 BTC, it will be hard for you, as a small node, not to "run out of BTC" in one of the channels after even just a few transactions.  If you have 10 000 BTC, and lock up 500 BTC in 20 channels to some other dolphins of the same kind, you will have a network that can handle a lot more transactions before having to settle, which puts you at a big advantage over smaller fish.  These lots of transactions will smooth out much more and keep your channel actually quadratically long alive with its content.  (if you put 10 times more coins in a channel, it will live 100 times longer, because the fluctuations go as square root of the amount).