Bitcoin Forum
May 21, 2024, 10:41:22 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: What is the technical reason why bitcoin can't scale?  (Read 492 times)
franky1
Legendary
*
Offline Offline

Activity: 4228
Merit: 4490



View Profile
July 15, 2021, 09:04:58 AM
Last edit: July 15, 2021, 10:05:19 AM by franky1
 #21

the main problem with not increasing the blocksize*. is that the limited transactions allowed end up covering all the mining costs

EG if it cost $200k to mine a block. and there are only allowed 2500 transactions.
then each transaction ends up costing $80
where as letting say 10,000 transactions by removing the cludgy math of the /4 wall.. means transactions could be diluted to $20. while still allowing the new dev sought data limit of 4mb acceptance

keeping the capacity(the real politics) at ~2500 just makes for the argument of "onchain fees are high, so use an altnet"
yet
users would not want to pay $80 to be able to lock an asset.. release an asset for/from another network

thus.. those proposing the onchain stifling end up shooting themselves in the foot

after all. if paypal offered payments for microcents of all dollarfiat payments..  but said it will charge $80 per deposit and $80 per withdrawal if people use the dollar with them.
people will just use vinmo measured in euro. and convert to dollar elsewhere
or
would convert dollar to euro and then deposit with paypal who charge a $1 deposit $1 withdrawal through paypal
thus no one uses dollar in paypal

the other silly economic politics is:
"reduce onchain utility 'coz average joe needs to store blockchain''
which is countered by
"offer custodial channels offchain 'coz average joe wont use fullnodes 24/7 for their once a year unlock'"
meaning average joe still are not adopting bitcoin full nodes. and all that are running full nodes become central custodians.. again self defeating the pretend purpose of their game

*for transaction count stagnation, not for silly political bloat of data excuses

The most bizarre step in the long, slow, drawn out attempts to scale bitcoin is segwit.
Segwit itself increased the limit on the size of a block by roughly 4 times, which, oddly enough, is exactly that ... a block size increase ...
the cludgy math to increase the data bloat.. did not result in an increase the transaction capacity. thus its "we increased the block size" missed the whole point of the real reason why the community wanted a blocksize increase

its like a woman asking for bigger pants so that when she gets pregnant she has room to comfortably incubate kids..
the husband gave her bigger pants but got a vasectomy to refuse to give her the kids she actually wants the pants for. oh and now he just wants to make her fat to fit into the pants. to then have an excuse to leave the wife for another woman

Actually the scaling issue is, in my opinion, a case of ignoring the fact that networks get better and storage gets larger.

While many like to say that increasing the block size or decreasing the time between blocks isn't a long term solution, it is indeed obvious that with increased world bandwidth and increased average storage, block size increases and time reductions can be handled incrementally.

well you will now hear the conversative stagnators say
analogy
"cant do livestream on internet because 1999 floppy disks"


I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
ndalliard
Full Member
***
Offline Offline

Activity: 154
Merit: 177



View Profile
July 15, 2021, 09:09:50 AM
 #22

after all. if paypal offered payments for micropennies but said it will charge $80 per deposit and $80 per withdrawal.
people will just use vinmo
are you comparing bitcoin with paypal and venmo?
franky1
Legendary
*
Offline Offline

Activity: 4228
Merit: 4490



View Profile
July 15, 2021, 09:14:00 AM
Last edit: July 15, 2021, 09:56:58 AM by franky1
 #23

after all. if paypal offered payments for micropennies but said it will charge $80 per deposit and $80 per withdrawal.
people will just use vinmo
are you comparing bitcoin with paypal and venmo?

i edited it to clear up any misunderstanding

im comparing bitcoin to dollars.. and paypal to sidechains/altnets like LN
im comparing altcoin to euro.. and venmo to an altcoin sidechain/altnet

after all.. would you use paypal if it cost you $80 to deposit/withdraw
would you even still favour the dollar if every bank transfer cost you $80
or would you move to another altcoin/service that only charges €1($1.2)
proclaiming the dollar is a dead currency due to fees

..
back to my point
at the moment pools are considering fee's asn an acceptable 0.5 bonus to their 6.25 income
meaning that the 0.5 fee total ($15k split over the average 2500tx stifled limit) means average cost per transaction is $6.

but when that $15k acceptable bonus for pools is a required $200k main subsidy.
then its $80

however. allowing 10k transactions without the math cludge of the /4 wall
today thats $1.50 and in future thats $20

in short..
more transactions per block = less people pay individually

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
fresheneesz
Jr. Member
*
Offline Offline

Activity: 33
Merit: 73


View Profile
July 15, 2021, 07:18:25 PM
Merited by Welsh (6), ABCbits (3), d5000 (1)
 #24

> What is the technical reason why bitcoin transactions can't scale?

Bitcoin can and has improved its scalability. But there are technical bottlenecks that present tradeoffs between achieving bitcoin's goals and increasing the block size (or shortenting the block time).

I wrote a paper a while back that goes through the exhaustive list of bottlenecks: https://github.com/fresheneesz/bitcoinThroughputAnalysis

> Is it technically infeasible to have a secure network while at the same time having faster transactions, without second layer solutions?

Its absolutely technically feasible to increase the transaction throughput of bitcoin. With technical innovations and hardware improvements, bitcoin's onchain throughput will increase over time. However, its a slow process.

> Can someone help me understand why we are not seeing many changes to bitcoin

Bitcoin's philosophy is slow and steady wins the race basically. The Bitcoin community has been committed to widespread buy in from people around the world before making changes. Proposals are discussed by tons of people, code changes are reviewed by tons of people, and deployments are done in a way that requires both overwhelming support from developers, reviewers, users, and miners. All this is done in as decentralized a way as possible. This process makes it substantially less likely that bugs and mistakes are introduced into the software. It makes the system more solid, secure, and reliable. It builds world trust that the Bitcoin system will continue to be solid and predictable. The trade off is that this process is slow. But its a worthy trade off I think.

> why the 10min transaction times is something which "must" occur in order to maintain security.

The paper I linked above also goes over this. Other people have mentioned it in comments too. Lower block times increase the advantage the last miner to mine a block gets, which increases pressure for miners to centralize. Decentralization of miners is key to bitcoin's blockchain security, and so we want to make sure we're designing the system to be well away from any significant miner centralization pressure.

You can think of this as related to the speed of light. Information can only travel so fast, and this puts a constraint on how quickly distantly separated entities can come to a consensus. In a decentralized network, very few entities are connected directly, and so information musts travel in many hops. This is exascerbated by the fact that your connections aren't chosen at all based on their physically proximity to you. So you have signals that can travel halfway around the world and back a number of times before consensus can be reached. 10 minutes isn't the time it takes to come to a consensus tho. The standard in bitcoin is 6 blocks - so about an hour. Even if block times were 10 seconds, however, the time to come to a consensus in the network (aka the "finalization time" - the time after your transaction has been confirmed after which you can consider it non-reversible) wouldn't be much different.

However, the time relevant to miners that matters is the time it takes for them to get the last mined block so they can start mining on it. If it took 1 minute for blocks to get to miners, that would be 10% of the time available to mine - so miners close to whoever last mined the block would have a 10% advantage. That would be bad centralization pressure. But that would be the same centralization pressure if the blocktime were 1 minute and it took 6 seconds to get to propagate the block to other miners. 6 seconds is not a lot of time for a decentralized network.

> If miners were 100x more powerful (or 100x less powerful) than they are currently, would that change the transaction time?

It would not by the way that the protocol is designed. It targets 10 minutes by adjusting the "difficulty" every two weeks. But if you're asking could we reduce the block time if miners were more powerful? The answer is also no, the block time is related to network propagation, not miner hashpower.
franky1
Legendary
*
Offline Offline

Activity: 4228
Merit: 4490



View Profile
July 15, 2021, 08:05:02 PM
Last edit: July 15, 2021, 09:17:34 PM by franky1
 #25

In a decentralized network, very few entities are connected directly, and so information musts travel in many hops. This is exascerbated by the fact that your connections aren't chosen at all based on their physically proximity to you. So you have signals that can travel halfway around the world and back a number of times before consensus can be reached.

that like saying
oh no. livestreaming cant work because earth is not flat
oh no live streaming gameplay of live action game cant work because earth is round

sorry but. we are not in 2010 with slow internet.
its 2020. people can livestream HD content to millions of viewers instantly

but if you are playing a game where you sniping someone in a game can only be consensus as a kill by 10 other players.. in 1 hours time..
then i feel sorry for your internet

heck i was playing Call of Duty with people from australia, china and US.. in 2009 and i was not waiting an hour for a kill confirm. nor was it taking an hour to send a 4mb mp3 song

i still find it funny how people are making floppy disk excuses.. in a live streaming era

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
kano
Legendary
*
Offline Offline

Activity: 4508
Merit: 1819


Linux since 1997 RedHat 4


View Profile
July 16, 2021, 12:57:19 AM
 #26

In a decentralized network, very few entities are connected directly, and so information musts travel in many hops. This is exascerbated by the fact that your connections aren't chosen at all based on their physically proximity to you. So you have signals that can travel halfway around the world and back a number of times before consensus can be reached.
...
i still find it funny how people are making floppy disk excuses.. in a live streaming era
Indeed, that's the point of my previous post.

People claiming that some "12 years ago" decisions about disk storage and internet performance will decide Bitcoin forever is simply ridiculous.

Though I could also point out that the original decision was 32MB per block, not 1MB or 4MB.

As for orphan rates, there will always be orphans, and trying to make Bitcoin avoid orphans for some guy CPU mining with an RPi that will never find a block in 1000 years running his blockchain on crappy internet is just ridiculous when you have to pay $5000 for a reasonable performance miner ...

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
garlonicon
Hero Member
*****
Offline Offline

Activity: 806
Merit: 1940


View Profile
July 16, 2021, 04:29:06 AM
 #27

Quote
Though I could also point out that the original decision was 32MB per block, not 1MB or 4MB.
Yes, but 1 MB is what most of the nodes accepted. It is mainly about backward-compatibility. If you would create such a soft-fork where blocks would have 1 GB, then it could be activated. Previous block sizes could be changed in a hard-fork way, because the network was small enough to do it easily. But as the network grows, it is harder and harder to do some hard-fork, because if developers can change things in a backward-incompatible way, then they can potentially change everything. On the other hand, soft-forks are unstoppable: https://www.truthcoin.info/blog/against-the-hard-fork/
kxwhalexk
Member
**
Offline Offline

Activity: 98
Merit: 173


View Profile
July 16, 2021, 08:59:27 AM
 #28

I want to make two statements:
1)The relationship between network speed and fork rate
Bitcoin's security requirements cannot have too many forks. The way to reduce forks is to make the block generation time much longer than the block transmission time. Therefore, increasing the block size may increase the possibility of forks, thereby reducing security . However, Satoshi Nakamoto invented the blockchain in 2009, and it has been 10 years now. The network transmission rate has been greatly improved. Is it possible to increase it?

As early as October 2010,  Developer Jeff Garzik considered that the 1M block would not be able to accommodate all transactions, proposed to modify the code and expand the capacity to 7.1M according to the target of 1,400 transactions per minute (ie 23 tps). Opponents believe that this requires all software to be upgraded, which is likely to cause confusion. Satoshi Nakamoto agreed not to upgrade for the time being, but suggested that preparations should be made in advance. For example, when the software is updated, the block limit should be increased after a certain block height (that is, a certain time) is written in the code. After that, Satoshi Nakamoto retired, and the development work was handed over to Gavin Andresen to take the lead.

2)If you reduce the size of each transaction, is it another expansion?
The signature part of the transaction occupies a large part. If it is moved out of the block, and the legality of the transaction will be verified later, you can reduce the size of each transaction, so as to put more transactions in a block, and increase TPS.
kano
Legendary
*
Offline Offline

Activity: 4508
Merit: 1819


Linux since 1997 RedHat 4


View Profile
July 16, 2021, 09:33:48 AM
 #29

Quote
Though I could also point out that the original decision was 32MB per block, not 1MB or 4MB.
Yes, but 1 MB is what most of the nodes accepted. It is mainly about backward-compatibility.
...
No, it is simply that core is completely against it, they prefer to use the fake excuse of never doing a hard fork.
Heck I've asked such questions of them back in 2011 - and got nowhere with it.
e.g. one of a number I've done:
https://bitcointalk.org/index.php?topic=51504.0

When core wanted to force miners to use Segwit, there was also BIP100 that got greater than 70% block coinbase approval with the mining community.
Alas core didn't want it and that was the end of it.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
ndalliard
Full Member
***
Offline Offline

Activity: 154
Merit: 177



View Profile
July 16, 2021, 09:45:40 AM
 #30

Quote
Though I could also point out that the original decision was 32MB per block, not 1MB or 4MB.
Yes, but 1 MB is what most of the nodes accepted. It is mainly about backward-compatibility.
...
No, it is simply that core is completely against it, they prefer to use the fake excuse of never doing a hard fork.
Heck I've asked such questions of them back in 2011 - and got nowhere with it.
e.g. one of a number I've done:
https://bitcointalk.org/index.php?topic=51504.0

When core wanted to force miners to use Segwit, there was also BIP100 that got greater than 70% block coinbase approval with the mining community.
Alas core didn't want it and that was the end of it.
core has no power - the users have - don't spread lies!
AverageGlabella
Legendary
*
Offline Offline

Activity: 1232
Merit: 1080


View Profile
July 16, 2021, 11:21:14 AM
 #31

While many like to say that increasing the block size or decreasing the time between blocks isn't a long term solution, it is indeed obvious that with increased world bandwidth and increased average storage, block size increases and time reductions can be handled incrementally.
They are not long term solutions that much is clear and Bitcoin relying on the progression of other technology which may or may not be suitable is not the best way to develop a currency which we want to be used for mainstream transactions. Bitcoin has to come up with a solution without relying on other technology because its not guaranteed that it will forever scale. Anyway Bitcoin should be looking to be as efficient and accessible as possible currently that is not the case.
ndalliard
Full Member
***
Offline Offline

Activity: 154
Merit: 177



View Profile
July 16, 2021, 11:34:24 AM
 #32

While many like to say that increasing the block size or decreasing the time between blocks isn't a long term solution, it is indeed obvious that with increased world bandwidth and increased average storage, block size increases and time reductions can be handled incrementally.
They are not long term solutions that much is clear and Bitcoin relying on the progression of other technology which may or may not be suitable is not the best way to develop a currency which we want to be used for mainstream transactions. Bitcoin has to come up with a solution without relying on other technology because its not guaranteed that it will forever scale. Anyway Bitcoin should be looking to be as efficient and accessible as possible currently that is not the case.

i agree with you that increasing the blocksize or decreasing the time blocks are found is not a solution. would you elaborate why you think that bitcoin is not efficient or not accessible?
kano
Legendary
*
Offline Offline

Activity: 4508
Merit: 1819


Linux since 1997 RedHat 4


View Profile
July 17, 2021, 04:43:32 AM
 #33

Quote
Though I could also point out that the original decision was 32MB per block, not 1MB or 4MB.
Yes, but 1 MB is what most of the nodes accepted. It is mainly about backward-compatibility.
...
No, it is simply that core is completely against it, they prefer to use the fake excuse of never doing a hard fork.
Heck I've asked such questions of them back in 2011 - and got nowhere with it.
e.g. one of a number I've done:
https://bitcointalk.org/index.php?topic=51504.0

When core wanted to force miners to use Segwit, there was also BIP100 that got greater than 70% block coinbase approval with the mining community.
Alas core didn't want it and that was the end of it.
core has no power - the users have - don't spread lies!
Users had nothing to do with segwit being implemented at all.
The pools agreed to it on the basis of also adding more changes later.
Alas core didn't do the later changes.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
ndalliard
Full Member
***
Offline Offline

Activity: 154
Merit: 177



View Profile
July 17, 2021, 06:42:55 AM
 #34

Quote
Though I could also point out that the original decision was 32MB per block, not 1MB or 4MB.
Yes, but 1 MB is what most of the nodes accepted. It is mainly about backward-compatibility.
...
No, it is simply that core is completely against it, they prefer to use the fake excuse of never doing a hard fork.
Heck I've asked such questions of them back in 2011 - and got nowhere with it.
e.g. one of a number I've done:
https://bitcointalk.org/index.php?topic=51504.0

When core wanted to force miners to use Segwit, there was also BIP100 that got greater than 70% block coinbase approval with the mining community.
Alas core didn't want it and that was the end of it.
core has no power - the users have - don't spread lies!
Users had nothing to do with segwit being implemented at all.
The pools agreed to it on the basis of also adding more changes later.
Alas core didn't do the later changes.
again: core has no power. same goes for the pools. users run the software, if you don't agree with the software/rules, don't run it. btw. core developers are also users of the software they are developing. but i guess we are getting off topic here
TangentC
Member
**
Offline Offline

Activity: 266
Merit: 20


View Profile
July 17, 2021, 08:02:00 AM
Last edit: July 17, 2021, 08:31:51 AM by TangentC
 #35

core has no power.

Hmm, you must have been sleeping
when Core threaten the miners that they would brick all of their millions of asics by changing the PoW algo, costing the miners billion$.
https://news.bitcoin.com/bitcoin-developers-changing-proof-work-algorithm/
Quote
Bitcoin Community Members and Developers Propose Changing Bitcoin’s Proof-of-Work

https://www.nasdaq.com/articles/why-viabtc-rejects-segwit-soft-fork-in-favor-of-block-size-hard-fork%3A-interview-with-haipo
Quote
Do you think that the Bitcoin Core development team should be fired?

I believe that the Bitcoin Core developers currently have too much power; there's no system of checks and balances for them.
They can decide to make massive changes to Bitcoin based on their own personal preferences, and then force those changes on to the users.


The btc users would have loved being able to mine btc on their home PCs again, but as it was just a blackmail threat to get their way on segwit,
Once Core got segwit enabled, all talk of new algo died.

So if someone can destroy your means of earning money almost overnight, you don't consider that they have power.  Cheesy Cheesy Cheesy
garlonicon
Hero Member
*****
Offline Offline

Activity: 806
Merit: 1940


View Profile
July 17, 2021, 08:47:32 AM
 #36

Quote
they would brick all of their millions of asics by changing the PoW algo
Not really, BTC is going to change things in a soft-fork way. That means changing PoW algo is possible, but limited. For example, it is possible to change it to sha256d plus sha3, but it is not possible to completely abandon sha256d. The only possible change in a soft-fork way is making previously valid blocks invalid, while also making new blocks valid under old rules. And that can be done for example by checking both sha256d difficulty and sha3 difficulty, in this way it would be backward-compatible.

Quote
The btc users would have loved being able to mine btc on their home PCs again
I think that it will be possible in the future. I can imagine a system where people will mine blocks on their CPU's and will receive a fractions of satoshi in the Lightning Network. Also, maybe some other kind of computations will allow CPU mining again, for example making signatures smaller, batching transactions, or maybe some other things where CPU's fits better than ASIC's.
Wind_FURY
Legendary
*
Offline Offline

Activity: 2926
Merit: 1830



View Profile
July 17, 2021, 09:10:19 AM
Merited by ndalliard (1)
 #37

after all. if paypal offered payments for micropennies but said it will charge $80 per deposit and $80 per withdrawal.
people will just use vinmo
are you comparing bitcoin with paypal and venmo?

i edited it to clear up any misunderstanding

im comparing bitcoin to dollars.. and paypal to sidechains/[bb]altnets like LN[/b]
im comparing altcoin to euro.. and venmo to an altcoin sidechain/altnet


Did you just call the Lightning Network an “altcoin network”? Because that’s a misinformed way to describe it. It needs an onchain transaction to open, and fund a channel in Lightning. In actuality those transactions in Lightning are Bitcoin transactions that have not been broadcasted in the Bitcoin network yet.

██████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
██████████████████████
.SHUFFLE.COM..███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
█████████████████████
████████████████████
██████████████████████
████████████████████
██████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
██████████████████████
██████████████████████
██████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
.
...Next Generation Crypto Casino...
ndalliard
Full Member
***
Offline Offline

Activity: 154
Merit: 177



View Profile
July 17, 2021, 08:33:29 PM
 #38

core has no power.
Hmm, you must have been sleeping
sure attack me personally but don't provide anything with substance...  Roll Eyes

when Core threaten the miners that they would brick all of their millions of asics by changing the PoW algo, costing the miners billion$.
https://news.bitcoin.com/bitcoin-developers-changing-proof-work-algorithm/
Quote
Bitcoin Community Members and Developers Propose Changing Bitcoin’s Proof-of-Work
a threat and a proposition is nothing real (i wouldn't take anything from bitcoin[dot]com seriously)

https://www.nasdaq.com/articles/why-viabtc-rejects-segwit-soft-fork-in-favor-of-block-size-hard-fork%3A-interview-with-haipo
Quote
Do you think that the Bitcoin Core development team should be fired?

I believe that the Bitcoin Core developers currently have too much power; there's no system of checks and balances for them.
They can decide to make massive changes to Bitcoin based on their own personal preferences, and then force those changes on to the users.
do you think, i believe.... again - no substance. and no, core can't force changes on to the users!!

The btc users would have loved being able to mine btc on their home PCs again, but as it was just a blackmail threat to get their way on segwit,
do they? who are "the btc users"? i don't want to mine on my home pc again, but i guess i don't count as "a btc user" then...  Roll Eyes

after all. if paypal offered payments for micropennies but said it will charge $80 per deposit and $80 per withdrawal.
people will just use vinmo
are you comparing bitcoin with paypal and venmo?

i edited it to clear up any misunderstanding

im comparing bitcoin to dollars.. and paypal to sidechains/[bb]altnets like LN[/b]
im comparing altcoin to euro.. and venmo to an altcoin sidechain/altnet


Did you just call the Lightning Network an “altcoin network”? Because that’s a misinformed way to describe it. It needs an onchain transaction to open, and fund a channel in Lightning. In actuality those transactions in Lightning are Bitcoin transactions that have not been broadcasted in the Bitcoin network yet.
i think it is a good idea to ignore franky1 on anything he says about the lightning network
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!