20mb block increase = 20 times more transactions possible?

[BlackJacky]

Hi all,

is it right, if we increase the block size to 20MB, there will be 20 times more transactions possible? Currently we can process round about 3-4 transaction per second. That means we would be prepared for 60-80 transactions per second?

Thanks for an answer!

[1713533748]

1713533748

[1713533748]

1713533748

[Amph]

as far as i know the 1mb isn't fully saturated, so expect more than x20 the current number of transaction/s

the limit is around 7 so it will be 140

but another question could be raised now, does 140 per second are enough if we reach fully adoption? or we need to raise it again in the future?

[BlackJacky]

currently we have 100.000 transactions per day so round about 1 per second...

[Benjig]

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 47,000 transactions per second, however they never actually use more than about a third of this even during peak shopping periods.

PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps.

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps.

[dothebeats]

Adjusting the number of transactions that could be handled by the network could probably be an interesting topic when bitcoin see widespread adoption and is widely-used by many people all around the world. 3-4 tx per second could be raised. Maybe a lower goal of a hundred tx per second? There isn't much need for a couple hundred tx per second because the network sees only a hundred thousand tx per day.

[LiteCoinGuy]

https://www.youtube.com/watch?v=8zVzw912wPo

[jaberwock]

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 47,000 transactions per second, however they never actually use more than about a third of this even during peak shopping periods.

PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps.

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps.

but how many wire transfer are made everyday?

For smaller transactions I think altcoins and off chain transactions might be an alternative

[Buffer Overflow]

the limit is around 7 so it will be 140

7 tps on paper. In reality, transactions are bigger than expected as they have multiple inputs and outputs, also multisig ones are bigger. I think 2 to 4 tps is more closer for a maxed out 1MB block in practice.

[SISAR]

1 block up to 20MB in size every 10 minutes on average is cool but it could be a dissaster if couple of such blocks are generated just few seconds appart by the same miner or miners that agreed on longest chain. It also does nothing in terms of speeding up the process of transaction confirmations, waiting over an hour for 1st confirm would still occur so how about 5 blocks up to 4MB in size every 2 minutes on average? Makes perfect sense to me but feel free to debate, I might be missing something with this whole deal.

[Gladdy]

20MB in size maybe needed in the future 5 - 10 yrs from now when majority of merchants start accepting bitcoin as payment....then TPS will shoot up to match credit cards transaction per day.

[tokeweed]

I'd say Gavin and co just go for it.  The majority wants it, let them have it.

[Nagle]

I'd say Gavin and co just go for it.  The majority wants it, let them have it.

The big miners have to approve. They control the block size and the minimum fee.

[louise123]

as far as i know the 1mb isn't fully saturated, so expect more than x20 the current number of transaction/s

the limit is around 7 so it will be 140

but another question could be raised now, does 140 per second are enough if we reach fully adoption? or we need to raise it again in the future?

Well, we should be praying that we will need to raise it again 

The real question is: will the new block size be fully saturated?

[BlackJacky]

As far I understand one transaction has around 200-250 Bits and it has to send two times (One from sender and one from recipient). That means, we could process with a 20MB block around 60-90 tx per second.

Is that right?

[e1ghtSpace]

1 block up to 20MB in size every 10 minutes on average is cool but it could be a dissaster if couple of such blocks are generated just few seconds appart by the same miner or miners that agreed on longest chain. It also does nothing in terms of speeding up the process of transaction confirmations, waiting over an hour for 1st confirm would still occur so how about 5 blocks up to 4MB in size every 2 minutes on average? Makes perfect sense to me but feel free to debate, I might be missing something with this whole deal.

Having blocks come quicker provides no advantage over 10min blocks. Why?

The same hashing power; faster blocks means more orphans and if we had 1 block every minute, we would have 10x less security from a double spending attack. Right now a doublespend would take ~ 2 hours, if 50% hashpower was used. (actually i'm probably wrong, its longer)

Now if we reduce blocks to 1 minute blocks it will take far less power to doublespend and a quicker time.

Basically, faster blocks will be less secure, cause more orphans and pretty much just bloat the blockchain. So yes, you are missing something.

[SISAR]

1 block up to 20MB in size every 10 minutes on average is cool but it could be a dissaster if couple of such blocks are generated just few seconds appart by the same miner or miners that agreed on longest chain. It also does nothing in terms of speeding up the process of transaction confirmations, waiting over an hour for 1st confirm would still occur so how about 5 blocks up to 4MB in size every 2 minutes on average? Makes perfect sense to me but feel free to debate, I might be missing something with this whole deal.

Having blocks come quicker provides no advantage over 10min blocks. Why?

The same hashing power; faster blocks means more orphans and if we had 1 block every minute, we would have 10x less security from a double spending attack. Right now a doublespend would take ~ 2 hours, if 50% hashpower was used. (actually i'm probably wrong, its longer)

Now if we reduce blocks to 1 minute blocks it will take far less power to doublespend and a quicker time.

Basically, faster blocks will be less secure, cause more orphans and pretty much just bloat the blockchain. So yes, you are missing something.

An attacker with 51% or more hashpower will own the network regardless of block time. If we drop block time to 1 minute that same attacker would still need 51% or more hashpower to successfuly double spend. The only way to "protect" from double spends is to wait certain period of time, not number of new blocks added to blockchain. If I wait 1 day and only then send you whatever you bought from me it is almost impossible you'll double spend on me, block times can be 1 second or 1+ hour.

The same goes for orphans, it makes no difference how many of them will be created if you wait long enough. I think you are underestimating the traffic volume and existing bottlenecks when it comes to moving 20MB blocks around especially if they are spread just seconds appart (not orphans but blocks that add on top of each other). Few such blocks would basically stall any nodes except very fast ones and that does not really work toward more decentralization because over time there would be less people running full nodes.

[BlackJacky]

As far I understand one transaction has around 200-250 Bits and it has to send two times (One from sender and one from recipient). That means, we could process with a 20MB block around 60-90 tx per second.

Is that right?

What do you think about that above?

[BlackJacky]

I guess its right...

[Amph]

As far I understand one transaction has around 200-250 Bits and it has to send two times (One from sender and one from recipient). That means, we could process with a 20MB block around 60-90 tx per second.

Is that right?

What do you think about that above?

yeah it's correct, you should count about 3 transactions for every 1mb of space(there are multisig too to be counted) so more near 60 than 90

[Delek]

We can just add a compress_block -> send -> decompress_block to mantain the 1mb limit while having space for more transactions?