Topic: what would be the implications of reducing blocktime to 5m and size/reward by 2x (Read 121 times)

It would have the same effect as doubling the block size in terms of blockchain capacity and storage requirement for full nodes. And that would be pretty bad because the blockchain is already large enough that people who don't have a lot of storage space on their computers don't run a full node anymore.

Also, Bitcoin confirmations at 10 minute block times are considered to be quit secure, some businesses accept 1 confirmation transactions, typically it's 3 at most. With faster block times the demand for confirmations will rise, and it would take the same time to actually have your transactions finalized, despite them technically being confirmed faster. Ethereum or Litecoin have much faster block times, yet when you send them to exchange the exchange asks for more than 10 confirmations, so it often times take as much time as depositing Bitcoin.

You'll change behavior of Bitcoin script which depends on block height as it's spending condition. LN's HLTC depends on block height., which give additional reason to reject this idea.


Roughly it's just 2x increase. I expect Bitcoin node's hardware can handle that, unless it uses old Raspberry Pi or very old PC. There's not much complain about it when SegWit increase maximum block size from 1MB to 4 million weight unit.

For any change you should first start by saying what you think you can achieve by that change before we can start discussing its implications. That's because in every change there is always pros and cons (it's not all good or all bad) and knowing what the change is trying to achieve helps put the disadvantages (or implications) into a better perspective.

For example I am just guessing that you are trying to speed up confirmation time. With that assumption we can start discussing the change better.
In this case turning 10 min on average to 5 min on average doesn't change anything whatsoever. So in other words you are talking about a fundamental change in the consensus rules that doesn't really solve anything. Which means even the smallest disadvantage is considered a major negative reason not to do it. Like the small possibility of a small increase in number of stale blocks.

you do know that average 10 minutes vs average 5 minutes makes no difference in the real world
people have already done loads of surveys, run scenarios, tested the economics, etc
(your idea is not original and has been discussed any times over the years)

firstly, the results are that whether a block is produced per 5 or 10 minutes, it doesnt then open up any new utility..
for instance physical retail checkouts will still see people waiting too long for a confirm before they can leave a store with their groceries that they still wont use bitcoin at a grocery supermarket checkout even with an average 5 minute confirm model
people are not even happy waiting 1 minute for fund clearance(confirmation) when using cash/cards. so a 5 minute wait for payment clearances wont add any extra utility of real world use.. this lead discussions down a rabbit hole of how about 2min30sec averages, how about 1min15sec averages, how about 37sec averages

secondly, without addressing the spam/bloat issues. it will still be the spam/bloaters getting first priority so genuine bitcoiners end up waiting for the next block anyway

thirdly, although it does not harm the nodes in regards to block data propagation(tests/commonsense/reality prove we have 2024 technology not 1998 slow technology(some idiots pretend people use old tech as excuse not to scale more data per 10min average)).
by having blocks being hashed by mining asics of mining pools. those miners have half the time to hash, meaning it causes the hashrate to be halved. (hashes per 300sec instead of hashes per 600sec) which is weaker security per block, compared to a 10 minute block average.

fourthly, for pools to work making block templates after a solved block appears, there will be more instances of "empty block" due to how mining pools send out templates to miners in the initial few seconds of previous block solve and then slowly fill blocks per update request over the next few minutes. due to the fact if all pools are then required to average 5minutes, it would cause more 'lucky' blocks found in less time. meaning more "empty block" chances, for them lucky blocks that find a solution in less than 5 min

also due to the lower hashrate and difficulty due to hashes per 300sec instead of hashes per 600sec.. people end up instead of waiting 6 confirms for large amounts will wait 12 confirms for same large value amounts. and 2 confirms instead of 1 confirm for same smaller amounts.. due to security metrics of economics


thus your idea has no advantages

The block size and reward would be reduced by 2x (or multiplied by 0.5), and halving time amount of blocks (to halving still happen every 4 years, despise faster blocks), this to not increase the speed the blockchain increases and not change the reward dinamics.

dont be silly
the argument of blocksize cost is moot
when the trolls that want people to abandon bitcoin that say "dont increase blocksize", but instead say "just pay more $$ per tx".. they are the ones saying cost is not an issue

if people at basic use DCA transact say once a month.. thats $600 a year in just congested fee's
they dont have a problem with this and infcat promote its continuation..

.. yet they then try to say lies that a $50 hard drive is too much for 20 years of decentralising the blockchain of everyones transactions


think about it
if they think paying $50 for one congested tx is ok.. how is that better than paying $50 for a harddrive to store decades of everyones transactions
if they are ok with $50 then there is no "cost problem" of blockchains

..
that said doing it by halving a blocktime is the silly convoluted way of doing it and not going to achieve anything long term..
its better and easier to allow more transactions per block of the current blocktime methodology/policy

..
and (pre-empting the usual replies of silly responses) dont be silly to then say increasing transactions per block in current blocktime policy 'need to achieve leaping to millions of transactions a second ASAP'
that too is again another silly narrative not based on rational thought, but done by silly people to say extreme dumb things as another way to make people fear any change at all
bitcoin does not need to leap to extremes of millions of transactions a second (but i expect you were probably itching to press reply to insinuate that is the next step people should fear, to avoid any change)

The result of a shorter time between blocks is an increase in stale blocks and reorgs. However, ten minutes is a long time and reducing the block time to five minutes would probably have no significant effect. The first confirmation would occur sooner, but but the waiting time in order to guard against a double-spend would remain the same because you would need to double the number of confirmations for the same security.

As for "reducing ... size/reward by 2x", I assume you mean by ¹/₂ in order to offset the more frequent blocks, and the only effect that I can think of is a reduction in the maximum size of a transaction.

Sure this is possible but these type of proposals were presented about maybe 10 years back. You need to remember if you do this then the block chain size will increase and so will the required bandwidth. So what will happen is that it will take more resources to secure the network by node operators. Eventually the resources will be too much so node operators would stop providing the service.

The solution to this problem is to leave the main bitcoin network as is and just use l2 when you need to do frequent transactions. This way you can store your main balance on the main chain and from time to time keep some on some l2 which you spend daily.

to achieve it
210k blocks would occur in 2 years instead of 4 years
meaning you would have halvings happen sooner and the supply cap mature sooner than 2142
so you would need to adjust the halvings to be at 420k instead of 210k

also the formulae for hashrate difficulty adjustments would also need to change from 2016 blocks per fortnight to 4032 blocks a fortnight

also you would need 2 sets of rules for initial block download/syncing checks..
rules for pre milestoned date/blockheight of old rules(blockrewards per 210k blocks). then second set for rules after milestone

theres other things too.. (i wont bore you with all the details, but what i said should be enough to show its not as simple as changing 2 variables)
..

doomad has no clue about bitcoin, and no clue about block propagation, latency.. its buzzwords he throws around without understanding of them

here is one example
nodes do not validate transactions after a confirmed block hash..
nodes relay most transactions pre-confirm at the relay stage. meaning when transactions are in mempool 99% are already validated... thus when then getting a blockheader+the hash(solved block) and its merkle root and leafs of TXID.. its actually less data a node actually needs to process when a solved block is propagated. and requesting missing tx not in mempool but has a TXID in the merkleroot leaf of a block header is a milisecond action not a 1-10 minute delay act

so his FUD fear of issues are stupid due to his lack of knowledge of bitcoin... he simply recites stupidity he read from others without doing further research beyond some social rhetoric he reads
...
but with that said
changing blocktimes is not a simple act and will impact many other mechanisms of bitcoin which can then cause other issues so its not a simple change nor one that will be as simple as just letting more transactions into a block at the current blocktime methodology

It sounds like you are trying to increase the transaction speed.  Is that correct? I think they are great questions.

There is an additional issue relating to RBF. RBF stands for Replace By Fee.  Bitcoin Cash does not have RBF because it allows the sender to cancel or change a transaction after it has been sent and before it is confirmed.

For starters, unless you can get the rest of the network to agree with you, you'd fork yourself off the network.   

And you probably won't get the rest of the network to agree with radically changing fundamental aspects of the formula like that.  The implications impact security, propagation, latency, orphans, etc.  They're all things you don't screw about with lightly.

What would be the implications of reducing blocktime to 5m, while also reducing the size and reward by 2x.
The amount of blocks needed to have the halving would be increased by 2x, so they still happen every 4 years at average.