Bitcoin Forum

As I wrote some time ago:

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.

Well it doesn't work as intended, because it was intended to be a currency and is now impractical for everyday transactions until SegWit/LN are implemented.  SegWit doesn't affect the stability of the Bitcoin network, it's just a way of making Bitcoin transactions easier to send which is even good for bigger investors.

It works great for everyday transactions. It was never intended for microtransactions.

Segwit is a huge change of the protocol, it will undermine investors confidence and send the price plummeting. Unlimited blocks is also not safe. Investors are cautious. Upgrade Bitcoin to Segwit or to BU and it will lose relevance very quickly.

it DOES work as intended, and the increasing volume in transactions, increased number of merchants, increase in the amount of money that payment processors for merchants such as BitPay are processing each month (which is millions of dollars) is supporting this.

the fact that there is a spam attack and during that period of attack people still pay low fees such as 20 satoshi per bytes and then get a late confirmation doesn't mean "bitcoin as a currency is impractical"

at the same time price rising, and all these things that are said doesn't mean we don't need some solution for scaling.

Segwit is yet to be tested on real life bitcoin transactions and we may see what segwit can do when ltc will have segwit after tomorrow. If it works as intended than that may help bitcoin to get more support for segwit activation. Yes doing micro transactions on bitcoin is quite costlier right now but price is in steady rise which is good thing for anyone to hold bitcoin for both short term and long term. Look at other alts all are red right now.

I cannot go against your statement. Both bitcoin unlimited and segwit wanted to be on the top of the blockchain as the primary code to be used in mining. The two groups would imply that if the blocksize of bitcoin will not increase it will become unstable. But looking at the situation at the moment bitcoin doesnt need higher blocks and even without increasing the blocksize bitcoin continues to move on.

No, it doesn't work as intended.  The average transactions per block (https://blockchain.info/charts/n-transactions-per-block?timespan=all) have been steadily increasing since the beginning.  The miners' revenues (https://blockchain.info/charts/miners-revenue) have also been rising and there's absolutely no reason why people should be paying anything other than tiny transaction fees with the mining revenues as they are.  And by "tiny transaction fees" I mean <20 satoshi per byte.  Transaction fees are meaningless and they only make up 10% or so of mining revenues anyway - they should only matter for priority transactions until the block reward is so small relative to the price that transaction fees are 100% necessary to secure the network.

Bitcoin objectively needs scaling.  It's not just a case of paying higher fees because that means that these pointless fees will be a competition to get into a block and many people never get their transactions confirmed at all.

The solution is SegWit + LN.  That's the only way which results in infinite scaling instead of just handling an increase in transaction volume until it gets too big and ordinary people can't use nodes.

i am disagreeing with you on things you just mentioned here. i agree that at this point with $21000+ block reward we shouldn't be paying high fees.

i am disagreeing with you on saying "bitcoin is not working as intended". bitcoin was intended to be used as a decentralized digital cash and it is still doing that. the intention was never about the amount of fees we are supposed to pay.

fees being higher, blocks being full, mempool being spammed to death (https://bitcointalk.org/index.php?topic=1776143.msg17715431#msg17715431), miners not making up their mind about scaling, and all the topics about scaling and some users calling it as store of value, only to transfer money oversees, only to transfer millions of dollars, .... does not change the fact that bitcoin is a p2p digital cash and it still is working as such.

Even with LN, we can't talk of "infinite scaling". We need to open a LN channel for every user with an on-chain transaction, and there must also be space on the blockchain to close it. Doing a little bit of kindergarden math: If we'd 2 MB blocks (~the effective estimated Segwit block size) and a value of 180 byte per transaction, then ~11000 users could open a payment channel per block, or 1,5 million per day. That's a lot, but it's not enough for the whole world's population, and it doesn't take into account channel closing transactions and other on-chain transactions.

Sidechains and extension blocks are a way to get closer to "infinity". I prefer a three-layer system: 1) Main chain 2) Sidechains or "extension" blockchains 3) LN.

Do you have something against the core developers?
I assume that you are one of the Segwit haters,but i don`t see any reason why you hate Segwit.
By the way,most of the core devs are playing with altcoins.

I see your point here.  Maybe I was hyperbolic, but here's something that the whitepaper says:


He's right, but mediation only results in higher transaction costs if the alternative can handle the transactions at all.  A decentralised peer-to-peer cash (which I admit is working in the most basic sense, as you pointed out) is seldom appealing if it seems like principle over practicality.  Whether people like it or not, any altcoin could provide these scaled solutions from the start (admittedly none have done it very well yet bar litecoin), so Bitcoin's immutability should only apply when it's something worth keeping.

Note:  Mempool spam are still transactions.  Sometimes they will be inevitable which is why it's important to have a system that works (d5000 knows what he's talking about when referring to a combination of extension chains and LN), instead of just having transaction capacity in the most basic sense.

Read one more time.
As a sane and cautious investor I am against any change of the Bitcoin protocol. Bitcoin is too big to change.

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.

So your "kindergarten math" is not very insightful, because it paints the absolute worst case scenario for Lightning's capacity.



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.

And so extension blocks simply give miners all the power to turn the mining network into servers that control the client software that the users use, Bitcoin would cease to be decentralised or peer to peer. Miners could create extension chains so huge that it would be no longer practical for regular users to download all the extension chains that their transactions are placed in, or to donwload the chains that contain BTC they receive from others. It's basically an even worse idea than Bitcoin Unlimited, as the miners don't even need Bitcoin nodes voting for the blocksize, they can change the blocksize to anything they like at whim.

Bitcoin is fine, nothing should be changed in its protocol. Investors have confidence it will not be changed and buy, confirmed by price action. Dare to make changes and they will flee.

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

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.

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.

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.

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.

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 ?

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.

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.

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.

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 ?

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.

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.

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.

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.

@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