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

[brainactive]

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

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

With the internet, connection speeds increased from 56kbps dialup to adsl to cable to adsl2 to now 500mbps. We could see progress being made and changes to the technology.

Can someone help me understand why we are not seeing many changes to bitcoin and why the 10min transaction times is something which "must" occur in order to maintain security.

[Charles-Tim]

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

There has been improvement with the adoption of Segwit and Taproot in which the transaction fees are reduced up to 50% while the Taproot transactions will be more efficient with also 2.5x faster block validation and 30% to 75% savings on multisig.

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

No, but the Bitcoin community are always looking for more way to improve scaling. Lightning network is still part of the process because it will actually help which can reduced on-chain transactions if adopted by people.

Can someone help me understand why we are not seeing many changes to bitcoin and why the 10min transaction times is something which "must" occur in order to maintain security.

Not necessarily 10 minutes, it is 10 minutes on average, it can take 1 minute, it can take 2 minutes, it can even take 30 minutes.

[BlackHatCoiner]

It's not the infeasibility, but the practicality I'd rather say. Every altcoin that tried to solve the scaling problem by increasing the block size brought others afterwards. And that's obvious; they're two opposite terms.

• The scaling issue requires increasing the size of the chain.
• The decentralization occurs when it's not increasing.

Generally, peer-to-peer networks are by their nature inefficient compared with the centralized ones. The whole world can't fit in a chain and retain its decentralization. One of them has to go. The lightning network is indeed a very practical solution. Each user keeps their own balance, just like how it should be at first.

Can someone help me understand why we are not seeing many changes to bitcoin and why the 10min transaction times is something which "must" occur in order to maintain security.

The 10 minute interval isn't something that brings security. Not directly, at least. The only reason I can think of is the orphaned blocks.

[vjudeu]

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

Because they cannot be joined. There are many transactions like that: Alice -> Bob -> Charlie -> Daniel. That could be replaced with Alice -> Daniel transaction.

why we are not seeing many changes to bitcoin

Because every big change have to be done in a soft fork way, discussed and developed for months, and later activated by miners signalling their readiness for that change.

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

Because the network is more decentralized if this time is not too short. If you have shorter block time, then when you hit some block, you can build instantly on top of it. The shorter that time, the more blocks in advance you can create, turning lottery-based mining into race-based mining when the more power you have, the more boost you get, which is unfair.

With the internet, connection speeds increased from 56kbps dialup to adsl to cable to adsl2 to now 500mbps. We could see progress being made and changes to the technology.

The biggest bottleneck is not downloading time, you can download all blocks quite quickly. The verification is what takes the most of the time. If you take some altcoins, especially CPU-based with slow and complicated mining algorithms on purpose, you can clearly see that. But in Bitcoin, ECDSA verification also takes a lot of time. And when it comes to processing speed, we stopped at around 8 GHz and going faster is very hard.

[brainactive]

• The scaling issue requires increasing the size of the chain.
• The decentralization occurs when it's not increasing.

Why is it that decentralisation is at odds with scaling? Is it a hardware bottleneck? If miners were 100x more powerful (or 100x less powerful) than they are currently, would that change the transaction time? Or would it still be 10 minutes (on average)?

And if it is 10 minutes (on average), I'm curious why 10 minutes is the optimal parameter and how we would even measure the level of security/decentralisation for different parameters (e.g. 1 min vs 5 min vs 10 min)?

[ranochigo]

The verification is what takes the most of the time. If you take some altcoins, especially CPU-based with slow and complicated mining algorithms on purpose, you can clearly see that.

It shouldn't make that much of a difference. The most algorithms don't actually take far longer than Bitcoin nor does it take the bulk of the time to verify.

But in Bitcoin, ECDSA verification also takes a lot of time. And when it comes to processing speed, we stopped at around 8 GHz and going faster is very hard.

IPC has been increasing on year on year basis. It is becoming less of a problem and my validation from scratch takes about 7 hours. The issue here isn't about that though; the whole point about having more bandwidth is such that blocks can be relayed though the network quickly and thus reducing forks. The main concerns with a block interval that is too fast is that if the propagation is too slow, the network would be less secure due to the possibility of different forks on it.

It is all about compromise. If you increase the block size to match the current levels of your major payments systems, the block size would be absurd. It is possible to have faster block times and larger block size, other altcoins have done it and are still surviving well right now. Segwit is in effect a block size increase as well.

This email is quite old[1] but this was in the middle of the block wars.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

[BlackHatCoiner]

Why is it that decentralisation is at odds with scaling? Is it a hardware bottleneck? If miners were 100x more powerful (or 100x less powerful) than they are currently, would that change the transaction time? Or would it still be 10 minutes (on average)?

As I said, the 10 minute interval has nothing to do with the decentralization or better, it's not directly related. You should think it in another way; if the network generated a new block every 5 minutes instead of 10, how many blocks should you wait? Wouldn't that be 12? Probably yes, but there is another thing to count too. The orphaned blocks. The shorter is the generation time, the more will be the orphaned blocks. By that, I conclude that 6 10-minute interval blocks provide better security than 12 5-minute interval blocks.

Here, read this: Why was the target block time chosen to be 10 minutes?

[vjudeu]

It shouldn't make that much of a difference. The most algorithms don't actually take far longer than Bitcoin nor does it take the bulk of the time to verify.

It depends on mining algorithm, because sha256d is quite fast, Scrypt is a bit slower, but take yescrypt and see how long it would take, even if two nodes are connected on localhost.

[franky1]

i know people love positive PR and try geting any critisism or factual negatives deleted: but lets see how long my post lasts

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

There has been improvement with the adoption of Segwit and Taproot in which the transaction fees are reduced up to 50% while the Taproot transactions will be more efficient with also 2.5x faster block validation and 30% to 75% savings on multisig.

but segwit stalled out at a 1800-2500 tx per block average

• The scaling issue requires increasing the size of the chain.
• The decentralization occurs when it's not increasing.

getting people onto sidechain /altnets where they are mainly using lite phone apps is actually going to cause alot of people to not be full archive nodes for bitcoin. especially when they have bitcoin locks for more then a month. they see no purpose to run full nodes everyday

The biggest bottleneck is not downloading time, you can download all blocks quite quickly. The verification is what takes the most of the time. If you take some altcoins, especially CPU-based with slow and complicated mining algorithms on purpose, you can clearly see that. But in Bitcoin, ECDSA verification also takes a lot of time. And when it comes to processing speed, we stopped at around 8 GHz and going faster is very hard.

mhm and yet. the altnet proposed as bitcoin solution that wishes people to migrate over to long term.. says people can create and swap public keys and then create multisig addresses and then create transactions and validate signatures in the millions per second... thus debunking your theory. that computers cant handle large capacity transaction verification

in short.
the 1mb 4weight limit is some maths of 2009 whereby internet was 0.5mb/s.. 12 years later the internet is 100x
hard drives were 250gb. but are now 10x that at 2TB
.
even if we went to a old style 4mb limit to allow an average of 8-10k transaction count (near true 4x capacity growth)
it would take 8-10 years to fill a 2TB hard drive. and most people update their computers every 5 years.
heck you can get a 4tb hard drive cheaper than 1 weeks grocery bill. and that would give you more then a decades buffer

..
last criticism of some posters false beliefs
some posters in this topic still believe that changes to bitcoin code in the last 5 years has made transactions cheaper. yet if you read the code youwill see they made legacy transactions a 4x premium. thus segwit are not 'discounted' in any way. they are miscounted atleast.

[tromp]

Because they cannot be joined. There are many transactions like that: Alice -> Bob -> Charlie -> Daniel. That could be replaced with Alice -> Daniel transaction.

They can be joined in Mimblewimble, stripping out all intermediate outputs.
Which is particularly nice since Mimblewimble uses confidential transactions in which each output comes with a large rangeproof. Thanks to cancellation of spent outputs, an Initial Block Download only needs to download rangeproofs for the UTXO set.

It still leaves a ~100 Byte kernel as a permanent record of each transaction though.

[d5000]

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

Because they cannot be joined. There are many transactions like that: Alice -> Bob -> Charlie -> Daniel. That could be replaced with Alice -> Daniel transaction.

The problem is that these transactions not very often converge into one. Most of the time the amounts will change in an unpredictable way (e.g. Alice -> Bob: 1 BTC, Bob->Charlie 0.3, then Charlie->Daniel 0.8 with another input and so on). The transactions could be joined into one anyway, but the size advantage then becomes small because this transaction would have lots of inputs and outputs.

Lightning is just made to solve that: due to the interconnection between a large number of nodes representing different roles: merchant, consumer, exchange etc. it has enough flexibility to allow the joining of a large number of transactions even with unpredictable amounts, and the "joining" = channel closing transaction only involves two parties (and in ideal cases is not even needed).

But the basic problem is verification, like you already mentioned. We could bring it down to the phrase: "Every Bitcoin user has to verify that every other user, with each transaction (even a coffee), did own their money and did not double spend, and we have to take into account up to 12 year old data" (fortunately most of them only once, with the initial blockchain download). This becomes much more problematic with bigger blocks, like already this old study showed - even if we have better hardware now in 2021, 10 MB blocks (a bit more than double of current maximum) would be the maximum to be handled relatively comfortably on average PCs. And no, limiting the verification process to miners does not solve the problem, because then miners could impose their conditions and modifications at will.

There were attempts like the Mini-blockchain scheme (which is, with some modifications, used in a handful of altcoins) to limit verification work to a relatively recent dataset (e.g. 1 week), but they have their own tradeoffs. Basically these approaches consider everything which is older than a certain block height as "finalized", but this opens attack vectors on the "finalized data", above all when the network interconnection is unstable and single users could be sybil-attacked. I nevertheless consider these attempts interesting.

[ranochigo]

As I said, the 10 minute interval has nothing to do with the decentralization or better, it's not directly related. You should think it in another way; if the network generated a new block every 5 minutes instead of 10, how many blocks should you wait? Wouldn't that be 12? Probably yes, but there is another thing to count too.

That is actually the equivalent security only (given similar conditions except blocktime). The math, as with the whitepaper involves the calculation in terms of the number of confirmations, not time. The probability of an attacker catching up from X blocks behind decreases exponentially with an increased X, given a hashrate of <51%. Probability People often approximate it for 1 hour, just because 6 conf = ~1hr.

The orphaned blocks. The shorter is the generation time, the more will be the orphaned blocks. By that, I conclude that 6 10-minute interval blocks provide better security than 12 5-minute interval blocks.

Orphan blocks are child blocks received by a client that has not yet received the parent block. You are most likely referring to stale blocks instead.
It depends. As said, it is a tradeoff between getting stales and a faster block interval. I don't think faster blocks are necessary, but if you need on-chain capacity right now then a bigger block would be the most direct solution.

Stale block occurs if miners aren't mining on the same chain as a result of them seeing different blocks at the same height due to a delay in propagation, etc. To prevent this, the miners just have to well connected, not a problem, we already know miners were having internal network of sorts and in certain cases SPV mining on one another. Ensuring good connectivity is to their best interest. Validation of blocks takes less than a second for miners and propagation throughout at least 50% of the network takes less than 10 seconds, I know a few research papers referenced the propagation time[1], not sure about the accuracy but I'm compelled to think that it is rather fast. So long as you can propagate the blocks efficiently and ensure that the miners are able to receive information in a timely manner, that shouldn't result in a far greater increase in the stale rates. As long as the majority of your miners are well connected to each other, then the stale rates wouldn't become that big of a factor.

Propagation of blocks or information in the network has improved tremendously throughout the years. Compact block helps with decreasing the delay with the propagation, FIBRE used to do so as well.

It depends on mining algorithm, because sha256d is quite fast, Scrypt is a bit slower, but take yescrypt and see how long it would take, even if two nodes are connected on localhost.

I can't find any benchmarks on that. I'm assuming that since hashing the (relatively) few block headers is about the least resource intensive task, a small increase in the time shouldn't affect it too much. Signature and script validation are far more time consuming. Unless you're telling me the CPU hashes at the rate of 1 per second?

[1] https://sites.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/bitcoin-delay says 6.5s for median, but it was quite a few years ago.

If the actual stats is 6.5s, then 6.5/600 is the stale rate would be 1.08%, if 300, then 2.15%, assuming the majority of the miners also sees the block at ~6.5s. It is twice the probability but the pros would still outweigh the cons. Bitcoin's landscape and some of the functions has changed throughout the years, not all assumptions still hold true. Note that the percentage also assumes that the economic majority receives the block around 6.5s. The actual time could be even lower <50% of the sample size.

[vjudeu]

Unless you're telling me the CPU hashes at the rate of 1 per second?

No, but something around 1024 hashes per second is realistic. But because people still want to mine on their CPU's, they create more and more complex algorithms that slows down everything, instead of focusing on decentralizing mining without changing mining algorithm, so I expect future CPU-based altcoins will slow down hashing even more, as soon as some people will start developing specialized devices where it will be profitable.

Edit: Actually, it depends. If only mining algorithm is changed, so only block headers are hashed in a different way, then that slows down everything to 1024 hashes per second. But if you have 1024 hashes inside merkle tree to compute and if transaction hashes use the same algorithm as in mining, then everything gets worse and the more transactions are there, the more time is spend on verification. So, I expect when there are many transactions in the block, then it can actually take one second per 1024 transactions (or maybe 512 transactions, because they are hashed twice, or maybe even 256 transactions, because of internal leaves in merkle tree doubles that), so one second per block only for hashing is possible.

[songchunlai]

In some place, one TCP connection may take more than 5 minutes and usually drop line. Maybe now more shorter.

[PrimeNumber7]

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

With the internet, connection speeds increased from 56kbps dialup to adsl to cable to adsl2 to now 500mbps. We could see progress being made and changes to the technology.

Internet speeds have increased a lot over the past 30 years, but I don't see residential speeds increasing by a lot from what is available currently. In the 90's and early 2000's, if you were using a residential internet connection to perform some task using the internet, generally speaking, the internet connection would represent a bottleneck, for example, if you were downloading a song, the song would download at a rate that is slower than your ability to listen to the song, or if you were visiting a webpage with many high-resolution pictures, you would have to wait for the pictures to load. Today, if you are using a residential internet connection, you can download  a movie in HD in a matter of seconds or minutes, and your bottleneck is your computer's ability to process and save the information received via the internet. I also don't see things like video or image quality increasing the extent they have increased in the past because there becomes a point in which the human eye will not see the difference in quality of an image/video if the quality is increased.

The point I am trying to make in the above is that there will not be demand to justify the investment required to increase residential internet speeds by amounts speeds have increased in the past.

There is also the issue of processing speed. When a block is received by a node, the node needs to validate (or have validated) every transaction in the block, and it needs to do so very quickly so it knows which transactions to accept or reject, and if it should accept or reject a future block. The processing capacity of chips has improved, similar to how internet speeds have improved, and there is demand for increased processing capacity of chips, however, it has become more difficult to further increase the processing capacity of chips, and this will likely be the bottleneck that prevents bitcoin from scaling without a 2nd layer. There is the potential that advances in technology will make verifying on-chain transactions more efficient, however, there are theoretical limits to this technology.

Finally, in the year 2051, why should I care that you paid $5 worth of coin on a Starbucks coffee today in 2021? Why should I have to store this transaction, along with the millions of other people that bought coffee at Starbucks on a given day? Granted, there is a setting in bitcoin core that allows you to only save x number of recent blocks. If you have a billion people using bitcoin every day, a billion people will need to store every transaction that every other person makes. With LN, or other second-layer solutions, only a small number of users will need to even be aware of any particular transaction

[franky1]

seems someone is trying just a little tooo hard to push for excuses not to evolve
residential internet in the 90's was dialup 56kb/s
in the 00's it was 0.5mb/s broadband 10x dialup
in 10's it was 5mb/s adsl 10x broadband

which is where satoshi based his limits in 2010

in 2020 its now 50mb/s fibre/5g
so internet has sped up 10x since satoshi limit. yet the limit has sped up 0x
the transaction count per block has not increased above the proposed 4700tx possibility
we have never had a single day of satoshis proposed 4700tx (7tx/s)

so we are actually performing at minus 2x of potential suggested in 2010
...

no one is screaming the need of 100x by midnight. not even 10x.
but atleast a true progress above the average 2500x tx that we have seen for 12 years

devs deem 4mb(weight) safe and so allowing for full utility of 4x legacy. with no cludgy /4 wall crap. would atleast get things moving to where things should be 12 years into a project

and also including a better fee mechanism would help too
after all devs have made legacy a premium by encoding a 4x treatment of legacy transactions so how about have code for a ?x treatment of transactions under 6 blocks to stop spammers
to segregate/split the spammers from the occassional user

as for the not wanting to store other peoples transactions from 30 years ago (the 2051 scenario mentioned in post above) well dont be a full noder if you dont care about other peoples transactions.
after all what becomes your acceptable value you do "want" to store of other peoples spending habits

is your limit that you only want to have
transactions of 1% of bitcoin price($330 today) be stored in the blockchain
transactions of 0.1% of bitcoin price($33 today)
transactions of 0.01% of bitcoin price($3.30 today)

so do you want "dust" limit raised to 0.0001($3.30 today) to avoid 'coffee spends'
..
lets word your presumption of desire of storage another way
how much would you consider its worth to spend on computer equipment to allow you full node utility for say average PC upgrade period of 5 years

..
if you want to be more biased about unwanted spends.
dont make it about the amount spent
make it about the confirm age
be biased and hate transactions with a UTXO thats only 1-3confirms old being spent
hate spam.. then you might have a talking point worthy of discussion

[NotATether]

seems someone is trying just a little tooo hard to push for excuses not to evolve
residential internet in the 90's was dialup 56kb/s
in the 00's it was 0.5mb/s broadband 10x dialup
in 10's it was 5mb/s adsl 10x broadband

which is where satoshi based his limits in 2010

in 2020 its now 50mb/s fibre/5g
so internet has sped up 10x since satoshi limit. yet the limit has sped up 0x
the transaction count per block has not increased above the proposed 4700tx possibility
we have never had a single day of satoshis proposed 4700tx (7tx/s)

so we are actually performing at minus 2x of potential suggested in 2010

ISP consumer router speeds do not scale with technical advancements in routing technology, for example in the US nearly all the ISPs there throttle your internet speeds to say 7Mbit/s despite having some of the fastest network stacks in the world.

This also includes so-called "5G" packages that throttle your connection from the datacenter and give you a mediocre speed.

[franky1]

hers the thing though..
even your 5mb/s
is more then needed to stream HD movies..
far more than a block needs
https://www.download-time.com/
you can download 500mb in 5 minutes
1gb in 10 minutes
10gb in 100 minutes (1hour 40min)
100gb in 1000 minutes (16hours 40min)
300gb in 3000 minutes (under 50 hours)

so even in your less than ideal country only offering 5mb/s
your not waiting weeks to download the blockchain..
(unlike the unoptomised method 7 years ago that felt like weeks to download just under 50gb)
yep things have moved forward in the last 7-12 years

[kano]

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.

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

[ndalliard]

isn't the problem with increasing the block size, that that is no solution at all - where do you stop? bitcoin on the base layer will never support all transactions happening in the world today by just increasing the blocksize. so i think it is a good idea to have a small blocksize und look for other solutions

[franky1]

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"

[ndalliard]

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]

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

[fresheneesz]

> 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]

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

[kano]

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

[garlonicon]

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]

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]

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.

[ndalliard]

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]

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]

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]

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.

[ndalliard]

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]

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/

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

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.  

[garlonicon]

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.

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]

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.

[ndalliard]

core has no power.

Hmm, you must have been sleeping

sure attack me personally but don't provide anything with substance... 

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/

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

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

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