Bitcoin block size limit

[walerikus]

If Bitcoin network transactions increase in number, so that the current block size limit is not enough to proceed all transactions in time, what will Bitcoin community do? Will they finally agree to increase the block size, or will try to find new ways to make transactions smaller in size, so they can fit in a small block size? Why it is so important to keep the size small 1-4MB? For a 1MB size block to be propagated on network within 10 minutes with current internet speed connections is not a hard task since most nodes can download 1MB per second. That's up to 600MB in 10 minutes. I am just referring about the abilities, no need of that large size, but why not making the block size more flexible, so it can handle more transactions when it is necessary?

Since Satoshi was explaining that it's not required to have a node with full data.

Whitepaper chapter 7. Reclaiming Disk Space

A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

Whitepaper chapter 8. Simplified Payment Verification

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.


It's been a long time since Satoshi was explaining the block size limit

jgarzik proposed to make a patch

We should be able to at least match Paypal's average transaction rate...

Code:

diff --git a/main.h b/main.h
index c5a0127..c92592a 100644
--- a/main.h
+++ b/main.h
@@ -14,7 +14,10 @@ class CBlockIndex;
 class CWalletTx;
 class CKeyItem;
 
-static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+   TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;
 static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
 static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
 static const int64 COIN = 100000000;


URL: http://yyz.us/bitcoin/patch.bitcoin-block-sz-limit

First Satoshi warned that increasing Block size limit was a bad idea at the given time.


+1 theymos.  Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it.

Satoshi Nakamoto


Than Satoshi gives an example how larger block can be settled on the protocol.

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

Satoshi Nakamoto

Original thread: https://bitcointalk.org/index.php?topic=1347.0

[TheNewAnon135246]

Why it is so important to keep the size small 1-4MB? For a 1MB size block to be propagated on network within 10 minutes with current internet speed connections is not a hard task since most nodes can download 1MB per second. That's up to 600MB in 10 minutes. I am just referring about the abilities, no need of that large size, but why not making the block size more flexible, so it can handle more transactions when it is necessary?

At your rate the blockchain will expand by 84+ GB a day. Not every country has unlimited plans and not everybody can afford it. You'll also need to store everything (unless you run a pruned node). It will take you just over 12 days to fill up a 1TB HDD. Increasing the block size could be an option if LN can't handle the demand anymore but that'll be years from now (if that even is a scenario).

[pooya87]

Will they finally agree to increase the block size, or will try to find new ways to make transactions smaller in size, so they can fit in a small block size?

the latter is better. increasing block size is easy but the result is not as good. for example with current Schnorr signature proposals we can compress transactions so that more tx can fit in the same size.

Why it is so important to keep the size small 1-4MB? For a 1MB size block to be propagated on network within 10 minutes with current internet speed connections is not a hard task since most nodes can download 1MB per second. That's up to 600MB in 10 minutes. I am just referring about the abilities, no need of that large size, but why not making the block size more flexible, so it can handle more transactions when it is necessary?

you aren't streaming a video! you are downloading data then verifying all of it. that is thousands of signature verifications and even more hashes to compute. the bigger the size, the more time it will take to verify blocks. and it is not just that, a node is also verifying a lot of transactions in its mempool so there is a lot of traffic that is being spent already that way.

[franky1]

the latter is better. increasing block size is easy but the result is not as good. for example with current Schnorr signature proposals we can compress transactions so that more tx can fit in the same size.

schnorr does not compress transactions.
schnorr makes it so a certain category of a mltisig script only uses one sig-length script.
if i was spending 4 UTXO of 4 addresses. i will still have 4 sigs.
if i had UTXO that were not multisig.. it wont be schorr
if i had UTXO that were old gen multisig.. it wont be schorr

schnorr is not a 'fix all' compression.. its a new tx format that people first need to pay into a multisig. to then be able to have a slim script when spending.
it does not apply to all tx types.

also there are flaws to schnorr which can make it ripe for abuse and scamming. when involving multiple parties. so it should not just be used randomly and trusted to be unbreakable

you aren't streaming a video! you are downloading data then verifying all of it. that is thousands of signature verifications and even more hashes to compute. the bigger the size, the more time it will take to verify blocks. and it is not just that, a node is also verifying a lot of transactions in its mempool so there is a lot of traffic that is being spent already that way.

now adays when a block solve is transmitted .. the whole block data is not sent. infact its just the header that is sent. the transactions would have already been relayed and say in nodes mempools long long before the block is even begun hashing. so all the fears of transaction verification bottlenecks due to blocks. are false.

its like your trying to paint a picture that people check the ware on their car tyres while the car is in motion.. sorry but no they check it even before they get into the car.

[walerikus]

My idea has been something like this a single patch that solves the blocksize issue permanently, X number of full blocks in a row = .1 mb blocksize increase.

The maybe it's 100 blocks in a row maybe it's more, I am sure others smarter than me have reasons for why there is a perfect number.

This way we don't see a troll able to spam up the blocks without paying a very large amount and they have to keep it up for 100 (or more) blocks in a row all for .1 increase at a time.

There could also be a way to shrink the size in the same fix if this brings concern to uncontrolled block size inflation. I'd suggest if 100 blocks are 1/5th block size cap for 200 blocks in a row shrink block size by .1mb.

This way the network scales on it's own and there is no need for a fight or a ritual for increase if we do hit that limit habitually.

Exactly block size could be adjusted just like the difficulty adjustment works for miners.

The problem with spam is not a big issue, because a spammer will have to pay fees for every microtransaction, which will make him spend a lot of money to make such a spam / ddos attack.

[walerikus]

Why it is so important to keep the size small 1-4MB? For a 1MB size block to be propagated on network within 10 minutes with current internet speed connections is not a hard task since most nodes can download 1MB per second. That's up to 600MB in 10 minutes. I am just referring about the abilities, no need of that large size, but why not making the block size more flexible, so it can handle more transactions when it is necessary?

At your rate the blockchain will expand by 84+ GB a day. Not every country has unlimited plans and not everybody can afford it. You'll also need to store everything (unless you run a pruned node). It will take you just over 12 days to fill up a 1TB HDD. Increasing the block size could be an option if LN can't handle the demand anymore but that'll be years from now (if that even is a scenario).

84gb per day or 30 terabyte annually with 1 Mbps.
We already have enough internet speed and storage space to support that. But.

My point was not to switch to a large block from now on, despite it's still possible, but to adjust the block size accordingly to transaction count, if required, which means raise the size to 8mb per block once the chain gets closer to that demand. Something like block size adjustment could be added on protocol, which would eliminate the onchain scalability issue every skeptic is talking about.

And yet, Satoshi was referring that it's not necessary for everyone to have the full node, miners can easily afford it. For the rest of users, it's possible to run the node with block headers only to enable simplified payment system onchain, which requires only 4,2Mb storage per year.

[Stalker22]

...

For someone who is interested in Bitcoin Core development, you should first learn how to quote properly.

[squatter]

My idea has been something like this a single patch that solves the blocksize issue permanently, X number of full blocks in a row = .1 mb blocksize increase.

Adaptive block size increases like this are easily gamed. An attacker intent on bloating block sizes can simply flood the network with transactions. The attack will actually become cheaper over time as block size increases, which makes it especially dangerous.

[walerikus]

My idea has been something like this a single patch that solves the blocksize issue permanently, X number of full blocks in a row = .1 mb blocksize increase.

Adaptive block size increases like this are easily gamed. An attacker intent on bloating block sizes can simply flood the network with transactions. The attack will actually become cheaper over time as block size increases, which makes it especially dangerous.

What can someone achieve by making lots of transactions? Except spending BTC for transactions and fees?

[squatter]

My idea has been something like this a single patch that solves the blocksize issue permanently, X number of full blocks in a row = .1 mb blocksize increase.

Adaptive block size increases like this are easily gamed. An attacker intent on bloating block sizes can simply flood the network with transactions. The attack will actually become cheaper over time as block size increases, which makes it especially dangerous.

Then we use an adaptive increase with a limit, instead of just an increase to 8mb it would be the limit, this would slow things down until their is the demand and nodes and can adapt if they have storage related issues, rather than the flip of a switch, if games by miners once they let up the blocksize would regress naturally to the true limit.

It wouldn't regress because the attack gets cheaper and cheaper to mount over time.

Even outside of an explicit attack scenario, consistently full blocks is the natural state of the network. Whatever incremental limits you put on block size, blocks will become filled shortly afterwards.

So, raising the block size in this manner is a classic "tragedy of the commons" scenario. Block space = highly distributed, permanent storage. It is a very valuable commodity, and users will naturally want to obtain it at the lowest possible price. By allowing demand for transactions to solely determine block size, we would therefore create an endless race towards zero fees and larger block sizes. There would be no built-in check on blockchain growth.

Monero was able to solve this problem by implementing two properties: 1) A penalty function for oversized blocks which lowers the mining reward, and 2) a tail emission. This cannot be implemented in Bitcoin unless users are willing to remove the hard cap on supply.

[franky1]

Block size limit has always been controversial topic and everyone have different opinion about it. But the reason why Bitcoin stays at 1 MB/4 kWu are :
1. Bitcoin community agree low-end/barebone device should be able to run full node
2. Not everyone have fast connection or their connection isn't fast because they use Tor
3. Time for Initial Block Download/IBD (download and verify whole Bitcoin blockchain)

come on.. you been round long enough to know these myths been busted.
1. blockheaders and other optimisations made bitcoin many many times faster than 2011 version of bitcoin. so yep thats right barebones devices can handle more.

2&3. the whole 4mb weight is where the core devs admit that bitcoin can handle users transmitting 4mb of data.. yet they refuse to allow a 4x of transaction count increase. the whole segwit is nt about more transactions. but allowing bloated scripts(dead weight)

4. time for IBD can be made to be a background concern. getting nodes to have a reliable UTXO set to atleast see an 'available balance' so people can just get on and use the node. and then, in the background the IBD can occur. yep people are not frustrated with the time to download the blockchain. they are peed off that they cant see balance or make transactions until the blockchain is downloaded. so the solution is available. let users usee bitcoin and then they dont notice the IBD occuring behind the scenes

as for the debate about speed. in previous posts shows the scale of 1mb's . come on.. even in africa they have 4/5g and fibre. heck even quiet villages of good old england have fibre. we are not in dial-up era anymore. and cant just keep using the dialup conundrum all the time as an excuse to promote the insecure non blockchain networks made for commercial profit..

come on you been around long enough to seen passed all the old myths..

[Artemis3]

Block size limit has always been controversial topic and everyone have different opinion about it. But the reason why Bitcoin stays at 1 MB/4 kWu are :
1. Bitcoin community agree low-end/barebone device should be able to run full node
2. Not everyone have fast connection or their connection isn't fast because they use Tor
3. Time for Initial Block Download/IBD (download and verify whole Bitcoin blockchain)

come on.. you been round long enough to know these myths been busted.
1. blockheaders and other optimisations made bitcoin many many times faster than 2011 version of bitcoin. so yep thats right barebones devices can handle more.

2&3. the whole 4mb weight is where the core devs admit that bitcoin can handle users transmitting 4mb of data.. yet they refuse to allow a 4x of transaction count increase. the whole segwit is nt about more transactions. but allowing bloated scripts(dead weight)

4. time for IBD can be made to be a background concern. getting nodes to have a reliable UTXO set to atleast see an 'available balance' so people can just get on and use the node. and then, in the background the IBD can occur. yep people are not frustrated with the time to download the blockchain. they are peed off that they cant see balance or make transactions until the blockchain is downloaded. so the solution is available. let users usee bitcoin and then they dont notice the IBD occuring behind the scenes

as for the debate about speed. in previous posts shows the scale of 1mb's . come on.. even in africa they have 4/5g and fibre. heck even quiet villages of good old england have fibre. we are not in dial-up era anymore. and cant just keep using the dialup conundrum all the time as an excuse to promote the insecure non blockchain networks made for commercial profit..

come on you been around long enough to seen passed all the old myths..

I agree that datasize shouldn't be such a strong a deciding factor, but disagree with your view about the universality of internet in the world. There are still many places with little or no internet access. Sure i have 4g, but the only existing data plan is only 600mb per month... Its been more than a year since we lost adsl here, and there is still no (cheap enough) alternative in sight.

Of course those people aren't going to bother with running a node, they won't use the core wallet, they go lite spv wallet and be done with it. There is no other realistic option, but your idea isn't bad either, i would still not use core even if the wallet showed immediately the funds available, at least until i somehow get uncapped internet again.

Remember how it took me 3 months to sync last time i tried running a full node the last months i still had working adsl? those of us in a bad internet situation will not be running nodes anyway. The current blockchain is huge and if it were to increase its size even more rapidly, it would make no difference to us in the low end.

Its like telling someone earning 5 USD a month that the plane ticket price was slashed from 2000 USD into 1000 USD. Gee thanks, it would still take 17 years of savings (assuming you magically don't pay bills or need to eat)...

I would simply drop the idea of running full nodes on very small simple devices as well. A full node requires gigs of storage, 300g but preferably 500g so it lasts a bit more, and even if you trim the node it still needs to download all that. The issue i see is that simply enlarging the block size doesn't appear to solve the issue but delay it a bit.

I don't like LN much, but at least its optional. I can stick to doing 1 sat/B transactions, until they let me do 0.1 sat/B transactions. Segwit bech32 native addresses has saved me satoshis, so i welcome it.

[pooya87]

schnorr does not compress transactions.

yes they do. every Schnorr signature drops the stupid decision to use DER encoding and that is compressing transactions by removing the extra 8 bytes garbage that each signature currently has and that is a 11% compression of signatures. also another byte is dropped from the public keys that come with each signature so the size goes up to 9 bytes.

signature aggregation (you refer to as multisig) is another characteristic of Schnorr signatures.

schnorr is not a 'fix all' compression.. its a new tx format that people first need to pay into a multisig.

wrong. Schnorr is the alternative to ECDSA signatures that is currently we have ECDSA and in the future we can have ECSDSA. it has nothing to do with tx format!

[franky1]

schnorr does not compress transactions.

yes they do. every Schnorr signature drops the stupid decision to use DER encoding and that is compressing transactions by removing the extra 8 bytes garbage that each signature currently has and that is a 11% compression of signatures. also another byte is dropped from the public keys that come with each signature so the size goes up to 9 bytes.

signature aggregation (you refer to as multisig) is another characteristic of Schnorr signatures.

schnorr is not a 'fix all' compression.. its a new tx format that people first need to pay into a multisig.

wrong. Schnorr is the alternative to ECDSA signatures that is currently we have ECDSA and in the future we can have ECSDSA. it has nothing to do with tx format!

i said new tx format.. you said alternative...
AKA schnorr does not help compress current transactions. people need to move funds into new formats.

also currently core discounts the 'witness' script data. meaning schnorr wont make transactions cheaper because the witness/script area has no cost anyway.

cant believe you think that schnorr is a fix for current ecdsa while then saying its an alternative..
yep i said its a new tx format using a different signing protocol. its not the same schnorr does not work with old tx formats..

thus i think you need to figure out which flip flop your trying to push and stick with one.
id suggest sticking with the flip that schnorr is new and doesnt compares legacy/traditional. and also is only really useful for bloated scripts. not everyday 1in 2 out transactions.

try if you really wanted to promote it as being a possible cure to prevent future bloated scripts from decreasing transaction counts by removing the bloat of such future scripts.
dont even bother trying to suggest it can be used as a tx count increaser.. so but no.. thats not its purpose

[franky1]

Additionally, it doesn't change the fact SegWit allows more transaction in block.

^ great comedy moment there

ok so satoshi years ago calculated a 4200 tx capacity of bitcoin 1mb... (7tx/s) (600k a day)
ill just sit here patiently while i wait for your evidence of a single day that has surpassed 600k tx in a day..
.. ill wait
...
.....
......
........
...........
ok no evidence.. ok fine so segwit has not increased transaction count..
maybe try giving up on that joke you said and try another
upto 4mb of hard drive space but not 4x tx average increase.. so do you really think segwit is really hard drive efficient.. go on e honest with yourself.. 4x hard drive utility but not 4x tx utility. its simple math

P.S
bitcoin block 540107 = 4mb hard drive utility and......... wait for it.. 230 tx
https://www.blockchain.com/btc/block/00000000000000000021868c2cefc52a480d173c849412fe81c4e5ab806f94ab

yep its time to say that segwit is NOT hard drive efficient for transaction count.

[pooya87]

because the witness/script area has no cost anyway.

it does have a cost!
each byte of witness is responsible for 1 unit of weight. considering fees per size it reduces the cost.
also considering storage, communication,... reducing the size even by small amount reduces the cost.

cant believe you think that schnorr is a fix for current ecdsa while then saying its an alternative..

i don't know why you are putting words in my mouth!

try if you really wanted to promote it as being a possible cure to prevent future bloated scripts from decreasing transaction counts by removing the bloat of such future scripts.
dont even bother trying to suggest it can be used as a tx count increaser.. so but no.. thats not its purpose

again with putting words in my mouth!
Schnorr like SegWit can contribute to scaling bitcoin, when more people use it whether it is multisig or not. for example if one exchange that is using a 2 of 3 multisig for its hundreds of daily payment switches to Schnorr musig it will start taking up a lot less space daily hence leaving that space for other transactions to be included in blocks.

FWIW i am not opposed to block size increase. in fact i have always supported proposals such as SegWit2x since i believe the hard fork to increase block size itself is long overdue. but i prefer all these other proposals that compress everything more, specifically Schnorr due to its compressed signatures, natural signature aggregation feature and much faster verification (single or batched).

[franky1]

again with putting words in my mouth!
Schnorr like SegWit can contribute to scaling bitcoin, when more people use it whether it is multisig or not. for example if one exchange that is using a 2 of 3 multisig for its hundreds of daily payment switches to Schnorr musig it will start taking up a lot less space daily hence leaving that space for other transactions to be included in blocks.

like i tested ETF.. ill test you..
show me one day thats surpassed 600k transactions.. and ill concede that segwit is for 'scaling' bitcoin.

and when schnorr is around ill ask the same question again..

what your not seeing as the truth is that schnorr and segwit are tactics to hide counting data from the rules to falsify numbers.
take segwit by not counting the witness area hard drives fill up by upto 4mb a block but the rules treat it as if only 1mb is being transmitted around.
the whole and sole point of the 1mb limit. to limit data transmission to 1mb a block..
so by core saying more than 1mb is allowed to transmit. theres no point in the 1mb limit.. yet they keep it for stupid reasons

these new features are not about scaling up bitcoin (dont ever expect more than 600k transactions.. definetly dont expect 2,400k tx's)
its about trying to prevent de-scaling(less transactions) by hiding information they wish to add to bloat up the blocks.
yep they want more bloated scripts but know if they did have the bloated scripts less transactions would average out.. so segwit/schnorr is just hiding data to try keeping to an average tx count. thus not scaling up. but just preventing bitcoin from scaling down
basically keep it at a stifled level of transaction count. all to persuade people that bitcoin cant scale. and introduce people to other networks

if you cant see whats really going on especially with these features only benefitting making other networks compatible and getting people to use these other networks. then you need to start taking a more critical look at all their excuses against allowing more than a 600k tx a day average cap
truly ask yourself why allow 4mb with all the cries against hard drive and bandwidth limits.. yet saying no to 4x tx capacity.. for the same space/bandwith

[ABCbits]

Additionally, it doesn't change the fact SegWit allows more transaction in block.

^ great comedy moment there

--snip--

Simple math can prove SegWit allows more transaction in a block. For reference, i use https://blockchair.com/bitcoin/transaction/868f240241c8fd0c13e9c69805612b647cc30aa1e982a9b0c9735b38d8607f7b and https://blockchair.com/bitcoin/transaction/d046a5746b0ebe9d86103852f1ed36edb553dc8d60187a52b1dfbee3f22eb9d6 where both of them have 1 input/1 output.

Block size limit (in weight unit) : 4.000.00 weight unit
SegWit transaction size (in weight unit) : 441
Non-Segwit transaction size (in weight unit) : 768

Total SegWit transaction size can fit in a block : 4000000 / 441 = 9070.2947845805 -> 9070
Total Non-SegWit transaction size can fit in a block : 4000000 / 768 = 5208.333333333333 -> 5208

If you still think SegWit doesn't allow more transaction fit in a block, then there's nothing else i'd say.

[franky1]

Simple math can prove SegWit allows more transaction in a block. For reference, i use https://blockchair.com/bitcoin/transaction/868f240241c8fd0c13e9c69805612b647cc30aa1e982a9b0c9735b38d8607f7b

Block size limit (in weight unit) : 4.000.00 weight unit
SegWit transaction size (in weight unit) : 441
Non-Segwit transaction size (in weight unit) : 768

Total SegWit transaction size can fit in a block : 4000000 / 441 = 9070.2947845805 -> 9070
Total Non-SegWit transaction size can fit in a block : 4000000 / 768 = 5208.333333333333 -> 5208

If you still think SegWit doesn't allow more transaction fit in a block, then there's nothing else i'd say.

might wanna double check your math.
if you had a block of the transaction you quote as 441wu
it will be only 5208..... why.. because even in segwit the 192 bytes that are not witness still limited to the 1mb base
there is no way to get 9000tx ...

maybe you need to retrain your 'simple maths' because it doesnt appear you recognise the simple stuff so just avoid including it

also the calculation that satoshi and others done YEARS ago was a 1in 2 out.. which got the 4200 (7tx/s)
you know.. its more likely people dont wanna spend all their funds so more likely have a 'change' address attached to. hense why it was used as a primary use representer.

now i dare you to try a segwit 1in 2out to be a more a fair comparison.. because your math is more about not knowing the 1mb base is still involved in segwit.. and instead you try to use thin(1n 1out) transactions which make it look like its due to segwit. when reality shows its due to thin transactions rather than the representer transaction of 1in 2out.
shame on you.

heck.. i can do a thin in 1out non segwit(legacy). and guess what... same 5208 tx as segwit.. but hard drive size taken up is actually 1mb
your first example of a similar 1in 1out segwit would take up 2.29mb
kinda funny you dont actually see that.

after all your dribble about bandwidth and hard drive capacity worries.. your not actually realising that
a non segwit block of 1in 1out would be hard drive 1mb 5208 tx
a segwit block if 1in 1out would be hard drive 2.29mb 5208 tx

so dont go using the stupid math hiding trick. if you actually cared about hard drive and bandwidth like you pretend you do. you would be counting the actual bytes involved and not playin g the segwit tricks of hiding information and forgetting which rule apply.

but i do laugh you think that segwit can achieve a 1.29million tx a day scaling...
ill wait and see that happen.. and wait..
and wait..
and wait...
...... or probably faster you realise your math mistakes and your inability to recognise whats really happening at code and hard drive level to realise where your mistakes have been made

.. just remember.. in non-segwit(legacy) the weight is not a real number. its s stupid multiplication done to make transactions more expensive. legacy WU is not the actual bytes of tx. nor the hard drive space it takes up nor the bandwidth usage.

have a nice day though

[johnyj]

I can not believe that there are still people talking about this in 2020, especially after seeing miserable adoption of LN, the same as bitsquare or bisq today. The problem is not the technical part, it is the decision making ability of the dev team, they made one after another wrong decisions

As predicted, segwit and LN has permanantly polluted bitcoin blockchain and there is no way to remove them, raising the block size might get a bit help, but in todays world, 10 minute confirmation is just too slow, many other coins are already in place for the fast confirmation, and with lots of other improvements in both theory and practice, once their marketcap have been pumped above bitcoin, we will see what will happen