Article about the blockchain and Bitcoin scaling.

[TheWolf666]

https://medium.com/scalar-capital/bandwidth-and-the-blockchain-2ad35c57dbdf

This article about how Bitcoin and in general the blockchain is scaling is very interesting.

I am not the author but I though it was very educational, and should belong here.

[1714755545]

1714755545

[1714755545]

1714755545

[1714755545]

1714755545

[Wind_FURY]

That's a good blog. Real scaling, share it around the forum. I admit that I was expecting something stupid, like "bigger blocks". Haha.

[TheWolf666]

That's a good blog. Real scaling, share it around the forum. I admit that I was expecting something stupid, like "bigger blocks". Haha.

hahaha, the endless block size issue, still debated even after SEGWIT fixed it.. true

[aliashraf]

op,

Stupid Medium corporation expects me to sign up and pay for premium membershit, I won't do that unless they accept bitcoin, and forget about KYC. It is not the case for now, so, copy/paste the text here please.

[aliashraf]

Op.

Forget about my previous post, I used another device to fool Medium a bit more  

Now, back to the article:
I do agree it has some educational material but I can't see anything new or important mentioned in this article. The author, puts a little bit more than adequate emphasis on relay network optimization role in scaling. Although he is right about 2nd layer protocols (like LN) not being an ultimate solution for scaling, like most authors in the field, he has no clue about what an on-chain scaling solution would look like. He is absolutely wrong. as i said. when he reduces the problem to relay network and bandwidth optimization.

P.S.
@ETFbitcoin: The way I understand it, credit card payments are a form of KYC. I don't and won't use such a payment device, never ever.

[Wind_FURY]

That's a good blog. Real scaling, share it around the forum. I admit that I was expecting something stupid, like "bigger blocks". Haha.

hahaha, the endless block size issue, still debated even after SEGWIT fixed it.. true

It's still debatable if it was fixed by Segwit, or if even if it needed fixing in my opinion. Segwit wasn't a "scalability fix", it was a malleability fix.

Op.

Forget about my previous post, I used another device to fool Medium a bit more 

Now, back to the article:
I do agree it has some educational material but I can't see anything new or important mentioned in this article. The author, puts a little bit more than adequate emphasis on relay network optimization role in scaling. Although he is right about 2nd layer protocols (like LN) not being an ultimate solution for scaling, like most authors in the field, he has no clue about what an on-chain scaling solution would look like. He is absolutely wrong. as i said. when he reduces the problem to relay network and bandwidth optimization.

What would an on-chain scaling solution, that doesn't centralize the network, look like? Sharding? Where's the Github link, where's the testnet?

[Wind_FURY]

What would an on-chain scaling solution, that doesn't centralize the network, look like? Sharding? Where's the Github link, where's the testnet?

https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6

Maybe you should read what sharding really is.

As it separates the data among multiple machines, (1 pc does not store the entire database.)
and then ask yourself how many machines are you willing to donate to be a non-mining / non-fiat earning nodes.  

True Onchain Scaling can only occur onchain, anything else like LN is offloading not scaling.

The whole point is increased TPS, so onchain scaling has to increase TPS capacity onchain.
To increase this you must cram more Transactions Per Second into the available vehicle, which are called blocks.
So your only true options are
1.  Increase Block Size
2.  Faster Blockspeed, which means more blocks in given time
3.  Increased Compression of TPS , so more TPS fit inside a Block

You can do 1 or a combination , as each increase true onchain scaling by adding more TPS.

All of the rest offchain , only offloads TPS to another service, but does not actually increase the true onchain capacity.
Offloading only removes some needs for increased onchain scaling, but it is a temporary band-aid and won't fix anything in the long run.
Offloading itself will fail, once the onchain TPS is Maxed out or priced out of utility.

Then my question is, if it increases blockchain size, speed, and transactions per second, then wouldn't it still be bloated, scale the network ininstead of out, and centralize the network?

[Wind_FURY]

What would an on-chain scaling solution, that doesn't centralize the network, look like? Sharding? Where's the Github link, where's the testnet?

https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6

Maybe you should read what sharding really is.

As it separates the data among multiple machines, (1 pc does not store the entire database.)
and then ask yourself how many machines are you willing to donate to be a non-mining / non-fiat earning nodes.  

True Onchain Scaling can only occur onchain, anything else like LN is offloading not scaling.

The whole point is increased TPS, so onchain scaling has to increase TPS capacity onchain.
To increase this you must cram more Transactions Per Second into the available vehicle, which are called blocks.
So your only true options are
1.  Increase Block Size
2.  Faster Blockspeed, which means more blocks in given time
3.  Increased Compression of TPS , so more TPS fit inside a Block

You can do 1 or a combination , as each increase true onchain scaling by adding more TPS.

All of the rest offchain , only offloads TPS to another service, but does not actually increase the true onchain capacity.
Offloading only removes some needs for increased onchain scaling, but it is a temporary band-aid and won't fix anything in the long run.
Offloading itself will fail, once the onchain TPS is Maxed out or priced out of utility.

Then my question is, if it increases blockchain size, speed, and transactions per second, then wouldn't it still be bloated, scale the network ininstead of out, and centralize the network?

If you don't do anything to increase TPS, then you have done nothing.

There are other solutions, and it doesn't have to be on-chain. In Bitcoin that's better because there's no need for a hard fork, that would bring its own problems.

You can make all of the nonsense changes that you like, but if none increase the ONCHAIN TPS, none of them improve scaling.

I'm talking about scaling, but without giving up node-decentralization. Increasing on-chain TPS would be increasing the block size, that would centralizing. Then what's the use of sharding? It's only slowing down the problem, but still centralizing.

[Wind_FURY]

There are other solutions, and it doesn't have to be on-chain. In Bitcoin that's better because there's no need for a hard fork, that would bring its own problems.

I'm talking about scaling, but without giving up node-decentralization. Increasing on-chain TPS would be increasing the block size, that would centralizing. Then what's the use of sharding? It's only slowing down the problem, but still centralizing.

No , you don't even understand that scaling means increased onchain TPS,
offloading TPS to an alternative system , does not increase the Onchain TPS ,
it is still the same fixed amount of TPS with or without your LN offloading nonsense.

This is it.  There literally are no other ways to do it.

Scaling would be meaningless in Bitcoin if it gives up decentralization. Plus scaling Bitcoin is not exclusively about utility, it's about improving latency/data propagation of a DECENTRALIZED NETWORK. Actual improvements that would help grow the network, not constrict it. Real scaling.

If you believe bigger blocks is the solution, go ahead.

[TheWolf666]

Just a small stupid question but, since SEGWIT is enabling a variable size of blocks and so far it never happen that the Bitcoin transaction had to scale up over 2500 bytes, why people are still talking about the size of the blocks?
Isn't SEGWIT the solution of this problem?

"As of 2017, the average transaction make-up would lead to blocks with 4M weight units being about 2.3MB in size if all transactions were segwit transactions."
https://en.bitcoin.it/wiki/Weight_units

[Wind_FURY]

Scaling would be meaningless in Bitcoin if it gives up decentralization. Plus scaling Bitcoin is not exclusively about utility, it's about improving latency/data propagation of a DECENTRALIZED NETWORK. Actual improvements that would help grow the network, not constrict it. Real scaling.

If you believe bigger blocks is the solution, go ahead.

Listen Mr. Clueless,
Bitcoin lost decentraliztaion years ago when the ASICS took away the poor man's ability to mine bitcoin from his PC.
You talk out of your ass more than your mouth.

Before you talk, and call everyone names, understand how the network works Mr. Zeitcoin lover. Hahaha! Zeitcoin.

Mining is cartelized, I accept that. I was talking about node-centralization. Bitcoin is not decentralized? Let me remind you of the UASF. Go eat your crayons.

Onchain Scaling can be increased in only a few ways.
Yes
1. is a bigger block
however
2. is a faster block speed, this is why litecoin and dogecoin have more scalability than bitcoin,
(Bitcoin moves to 5 Minute blockspeed instead of 10 minutes it literally double it's onchain TPS , with no change in Block size.)
(Bitcoin moves to 2.5 Minute blockspeed (like litecoin), it literally quaddrouples it's onchain TPS , with no change in Block size.)  
Even your pathetic non-mining node would have no trouble keeping up.
or
3. Create a New Compression for the blocks that enables more TPS to be stored in a single block.

IF option 1 scares you because you're stupid, then option 2 and 3 are still available.  

Your post proves that you don't understand anything. Go back to your crayon eating.

Offloading is a temporary Patch , not a scaling solution.

All of these are bandaids, and at some point, the onchain TPS limits will still overload and what good is offloading to LN,
when it's is also stuck, because no coins can move on or off it.

That's why i said "To some extent", the community eventually will be forced to approve block size increase.

Then what? When will the block size increases stop? What bigger block size would be the best size to hard fork to?

That will be setting up a dangerous precedent.

[Wind_FURY]

Then what? When will the block size increases stop? What bigger block size would be the best size to hard fork to?

That will be setting up a dangerous precedent.

It's not like i prefer block size/weight increase, my point is while there are many on-chain & off-chain scaling (which i mentioned above), eventually block size will be needed.
I should emphasize block size/weight increase should only be used as last resort, not as first resort or not considered at all.

I believe that if a proposal requires a hard fork, and the network isn't in a life-or-death situation, then it will never gain enough support. It's not as easy as saying that "a hard fork will eventually be needed".

[DooMAD]

We basically know what all the existing options are for scaling (barring any new technological leaps or discoveries) and, for me at least, I'm comfortable in the knowledge there are people working on each option and that they're being implemented in order of preference with the aim of preserving decentralisation.  People can get fixated on the options they can easily understand, but it doesn't mean that's the best option right now.  There's a pretty clear order of priority in terms of where we can increase throughput without centralising the network, so it's only natural we're pursuing those ones first.  People just need to take a step back, look at the bigger picture and chill out a bit.  

You can say "but, but blocksize", "but, but faster block speed", etc, but it's not like we're hearing anything new.  We know those things exist.  The cost/benefit ratio has already been evaluated and wasn't deemed a priority.  Hence other options taking precedence and being actively developed first.  If we need to resort to those options with a higher cost, we can consider that later.

[UnruffledST]

What would an on-chain scaling solution, that doesn't centralize the network, look like? Sharding? Where's the Github link, where's the testnet?

Say YES to sub-second zero-confirmation transactions and say NO to instant transactions.

The Sub-Zero Protocol permits Scroda to achieve Sub-Second Zero-Confirmation Transactions all due to two chains coming together and becoming one, Yin and Yang.

https://medium.com/@scroda/scrodas-sub-zero-protocol-walkthrough-c1677f3d60fa

Take a look at our discussion https://bitcointalk.org/index.php?topic=5160269.msg51868770#msg51868770

We will be releasing testnet soon.

[cfbtcman]

LN will never be solution, Satoshi said that onchain transactions will support miners in the future, with LN there is no fees for the real miners that support blockchain, with time the fee of one ON-CHAIN transaction will be huge.

LN will have low fees but On-Chain will have a impossible fee to pay and who will rule the LN chanels will be the same as banks, we are not in control of our money!

We need to think about a scalling solution that splits the blocks in blockchain groups, like group A, B, C and so on, that number of groups will be bigger with the number of nodes running, that way the size of block will be always 1MB by node, node type A, node type B and so on, they could be splitted in many 1 MB parts of a block an tested online like SPV wallets.

If bitcoin was used by all the people of the world they will not to be all nodes, so, we can have one node for some % of people, the same way we dont need to have 100% full node information by each node, so, we can split like prunned nodes, some have some blocks, some have other blocks, that way we can scale blocksize and if we scale blocksize we can have some pruned nodes registering 1st 1 MB of the block and other nodes registering 2nd 1MB and others registering 3rd 1MB of the blocks, why not?

If we make this auto-scalling by the number of existing nodes and transactions we can do it without Lightning Network bullshit that its even worst as banks!

To solve the huge number o information in all network there is another solution, we start to delete 1st blocks of blockchain after some number of blocks, example GENESIS block can be deleted and the money still in that address can be reward for miners, this is the best solution for any database, all databases in the world cant grow up infinitely, that is fisically impossible and will waste a lot of resources, so we need to start do delete blocks sooner or later, why dont do the perfect machine now and dont let problems for future generations solve like Y2K in year 2000 ?

[squatter]

It's not like i prefer block size/weight increase, my point is while there are many on-chain & off-chain scaling (which i mentioned above), eventually block size will be needed.
I should emphasize block size/weight increase should only be used as last resort, not as first resort or not considered at all.

I believe that if a proposal requires a hard fork, and the network isn't in a life-or-death situation, then it will never gain enough support. It's not as easy as saying that "a hard fork will eventually be needed".

That's my contention too. Some people believe that as technological improvements mitigate the technical reasons not to increase block size, that it will become easier politically to accomplish a hard fork. However, I think the fee market will just become the central political issue at that point. The question of whether fees alone can sustain adequate mining incentives (at 4MB block weight limit) could keep everyone debating for another decade.

[mda]

https://bitcointalk.org/index.php?topic=5109561

Just don't erase the genesis block please.

[DooMAD]

LN will never be solution

That's why it's not the only avenue being explored.  No one is saying that Lightning is going to magically solve all our problems and we don't need to look at anything else.

To solve the huge number o information in all network there is another solution, we start to delete 1st blocks of blockchain after some number of blocks, example GENESIS block can be deleted and the money still in that address can be reward for miners

If you can find support for it, go right ahead.  Count me out, though.  I've seen enough iterations of "hey, let's steal old coins and put them back into circulation" threads to know that only a few well-intentioned-but-ultimately-misinformed fools want that.

[ABCbits]

LN will never be solution, Satoshi said that onchain transactions will support miners in the future, with LN there is no fees for the real miners that support blockchain, with time the fee of one ON-CHAIN transaction will be huge.

Only fools who say LN will solve all scaling problem, besides LN still need on-chain transaction to open & close channel.

IMO LN only useful for those who often make micro-transaction.

LN will have low fees but On-Chain will have a impossible fee to pay and who will rule the LN chanels will be the same as banks, we are not in control of our money!

LN basically bunch of un-broadcasted transaction with timelock, we have control over our money. The real problem is when other party is unresponsive or non-cooperative where we're forced until timelock expired.

We need to think about a scalling solution that splits the blocks in blockchain groups, like group A, B, C and so on, that number of groups will be bigger with the number of nodes running, that way the size of block will be always 1MB by node, node type A, node type B and so on, they could be splitted in many 1 MB parts of a block an tested online like SPV wallets.

It's called Sharding & already exist for years. The hard part is convincing the community to use sharding.

If bitcoin was used by all the people of the world they will not to be all nodes, so, we can have one node for some % of people, the same way we dont need to have 100% full node information by each node, so, we can split like prunned nodes, some have some blocks, some have other blocks, that way we can scale blocksize and if we scale blocksize we can have some pruned nodes registering 1st 1 MB of the block and other nodes registering 2nd 1MB and others registering 3rd 1MB of the blocks, why not?

Irrelevant, regular people don't bother run full nodes, they will always rely on SPV or custodial wallet.

If we make this auto-scalling by the number of existing nodes and transactions we can do it without Lightning Network bullshit that its even worst as banks!

To verify total of full nodes, a node must connect to all full nodes where :
1. Most device can't connect to thousand nodes at once
2. De-anonymization because all nodes who broadcast a transaction/block
3. Full nodes have low default incoming connection limit (AFAIK it's 125)

To solve the huge number o information in all network there is another solution, we start to delete 1st blocks of blockchain after some number of blocks, example GENESIS block can be deleted and the money still in that address can be reward for miners, this is the best solution for any database, all databases in the world cant grow up infinitely, that is fisically impossible and will waste a lot of resources, so we need to start do delete blocks sooner or later, why dont do the perfect machine now and dont let problems for future generations solve like Y2K in year 2000 ?

Pruned mode already realize your idea, user just need to store set of UTXO, recent blocks & all blocks header (which is only 80 bytes/block).

[UnruffledST]

@Wind_FURY did you have a chance to read the article I posted?