Topic: What are the effects of lowering the average Bitcoin block confirmation time? (Read 232 times)

FYI, i only mention LN in first place because AFAIK LN is most common application/usage which rely on block height. Other than that, i only see people discuss nLockTime and OPCODES which rely on block height as HODL option, inheritance or organization which have specific spend/security rule.


I don't expect usage of weight/vB unit will be removed anytime soon, at least until hard fork which increase max block size limit.

Implementing a lower Bitcoin block average confirmation time in the current situation with the existence of Ordinal causing major disruptions to the network may not be ideal. Once security issues are resolved, decreasing block confirmation times can help reduce bottlenecks in the mempool and provide faster confirmation times for transactions, which can improve user experience and Bitcoin adoption. There are also negative effects to consider such as the risk of a blockchain fork that could reduce the security of the Bitcoin network. In addition, decreasing block confirmation times can increase completion at nodes, making it more difficult for smaller nodes to participate in the network as well as causing the cancellation of the overall mining imbalance. and potentially lower miner penetration in the network.

Yes this may be may possible but consider the consequences that may follows.
1. Global hash rate may have to reduced drastically as well

2. Bitcoin mining difficulty might have to increase as well in same direction

3. Miners will suffer the cost because they won't have the bigger opportunity to incentivise for more profits

4. The average block confirmation time is likely to increase or decrease from the 10minutes average confirmation time.


I don't think so, they would rather maybe think of lifting ordinals transactions off the blockchain to layer 2

on the BITCOIN network you can lock value.. and with enough confirmations. its immutable thus very strong..  where locktime is still workable.. and that lock does follow rules. (not sure how long that lasts before core devs soften that rule too.)

however on LN.. which you must treat as a separate network.. when creating channels where a SUPPOSED uxto is used to then create a child transaction that is then called a commitment. the rules on the LN side are WEAK AS F**K and not really rules at all. and yes the LN devs blame user error for accepting a channel open session with zero confirm txid as the funding. and close session with bad unlocks as user error, even though its devs fault for making such a crappy project with such lack of rules, lack of auditing, lack of controls. lack of checks

the reason i bring it up is becasue you seem to care less that bitcoin devs already did mess with bitcoin transactions. but dont want them to mess with things that can affect a broke OTHER network.. which i found amusing and strange, ..and after soo many months/years of chances you have yet to learn how broke LN is to realise its not worth caring about as something that does not securely secure/hold value. but just presumes to

just skip a few months/years and come to the realisation that LN is broke and a completely new subnetwork bridge needs to be created from scratch to service bitcoiners. rather then waste months trying to hope bitcoin does things to entertain and recruit lightning lemmings

LN has many many issues which is why more people have decided to avoid LN and use other subnetwork bridges to lock their bitcoin value to.

anyway. back to the topic.

what bitcoin devs need to do is stop with the radicalisation of sponsorship deals to just make bitcoin messy to promote corporate patented subnetworks as the saviour. and actually get back to making bitcoin efficient. where every byte of a tx counts and has purpose where actual checks are done. as was the case years ago

idea's such has messing just with difficulty lasts 2 weeks.
idea's like messing with block per adjustment and thus reward amounts per block to compensate to try to force it to last..  overall messes with too many other things including the scarcity and value proposition. thus not the fix

the real fix is to get code to actually check tx data like it suppose to do. as that was the integrity promise of blockchains. to have data which all fullnodes fully verify and meet standards

the major problem is this

when for instance you have a 2in-2out payments (norm) where the byte data of just ins and outs is under 200bytes. but where a couple signatures of ~145byte total. is not more bytes then the value moved. things seem reasonable..
the proofs bytes dont outweigh the value bytes moved. things seem good and lean and efficient

however when devs proposes the actual value data should be 25% of a transaction(txdata vs witness area segregation). and hinder utility of blockspace with cludgy math, miscounting bytes, making certain bytes a premium.. and then turning off validity checking of each bytes purpose to be in a transaction.. things go wrong

to then not want to employ rules to make bitcoin lean and efficient again, where every byte should have an assigned purpose.. is bad..  but to then instead cause more issues that mess with things like rewards per hour. halving date changes, etc(such as this topics idea). that is not the way to solve things either

the solution is to employ rules where every byte of a transaction has to meet a format/purpose for being there that meets consensus rules. no 'isvalid' bypass. no activated by default opcodes that have no requirements assigned.

instead if opcodes exist but unassigned any rules. they should be disabled. and if/when needed, it is then for devs to PROPOSE utility, show the rules they want to add to a deactivated opcode... and consensus then, when majority has the code to enforce the rules. activates its utility

Why will doubling the block size bring problems? HDD/SSDs aren't expensive nowadays, this is not an issue and I have no idea how are we gonna to handle it otherwise. So, do you think that it's better to wait hours and days to get transaction instead of increased block size? Isn't that going to halt bitcoin adoption and increase altcoin adoption? If the purpose of bitcoin is to get rid of 3rd parties and make peer to peer transactions, then we need fast confirmations. Increasing of block confirmation time is not a deal, it will only do worse because it will change the date when last bitcoin will be mined, it will change the date of halving, so, no, but what can block size increase change negatively? Storage can't be an issue today.

locking value in bitcoin network transactions is strong. once confirmed and usually best if high value to wait a few confirmations.. but on crappy networks like LN the requirement of locked value is weak and people can create channels even without confirmed locked value. so it actually does not matter to LN. they are broke to a point that a orphan event wont stop them making channels of msat balance.. yep its that bad that they dont have responsibility/restrictions on ensuring value is locked. so yea its not a problem because a bigger problem exists with LN


to break the units of measure is a big deal. its like breaking the main/first law of bitcoin that should not be broken. not only that it is not simple to achieve without alot of code re-writes and breaking some of the checks and audits of bitcoin data.. which come with their own consequences

bitcoin network is not measured in btc. its measured in sats. (the smallest unit)
a btc is only measured not in underlying code or blockdata. but only at surface GUI code(for display purposes of easy human reading/understanding)

satoshis first reward was not "50 btc" its actually 5,000,000,000 sats
or more simply
5,000,000,000 UNITS

to want to multiply units by 1000x requires messing with soo much code that it makes satoshis first reward be appearing as 0.05btc in the new paradigm

in short the scarcity of true numbers (the maximum count of 2,099,999,997,690,000 units) changing breaks scarcity/sharability promise.. which is the main law/rule of bitcoin

for those using clearnet (normal internet) sending upto 4mb around the entire network in 2minutes wont cause issues
however for those syncing blocks via TOR, their internet is slower so can cause orphan issues for blocks under 2 minutes

but here is the other thing
if blocks were changed, where difficulty adjusts from doing 2016 blocks per fortnight (the actual expectation) to being 8064 blocks per fortnight (2.5min average) then that makes the bitcoin halving happen yearly instead of every 4th year average.
it also makes the total coin supply not complete in 2140 but in the year 2060~
 - these means an even quicker rush to pressure fee's to overtake rewards even sooner. thus defeating your idea of countering this years spam fee mania, and instead causing the fee mania to want to persist due to the new fee:reward paradigm happening in years instead of decades

also more rewards per hours also means pools get a 4x increase in hourly rate. meaning they can sell their coins for 4x less because their cost/reward is 4x better. meaning bitcoins underlying "bottom" support drops by 4x.

need i go on?

Lowering the block confirmation time will put your transactions at bigger risk of double-spend, 51% attacks and more risks.

With 51% attack, the attacker will have to own 51% of network hash rate at least within a time that is long enough to make attacks. If you lowering the block confirmation time, attacker will need to spend less minutes to control 51% of network hash rate for attack.

Like now, with average block time is 10 minutes, most of exchanges and platforms require 1 confirmation for your deposit to credit it to your account; and some require 2 or 3 confirmations. If block time is like 5 minutes or 1 minutes, they will require 15 or 30 confirmations to accept your deposit.

Compare Bitcoin confirmations (6) with altcoin confirmations to have similar security.
https://howmanyconfs.com/

How many Bitcoin confirmations is enough?

Wouldn't the only way to change the block confirmation time be to reduce the difficulty? Ultimately this is the determining factor over block times, hence it increases with hash rate growth in order to maintain a 10 minute average. But by doing so this would create a fork in the protocol with one side respecting the original difficulty protocol, and others adopting a new one, so this doesn't sound like a solution at all.

Someone correct me if I'm wrong here, but there is no soft fork option imo, it'd be the same as increasing block size - there would be a conflict in the rules of the protocol.

This is basically the same thing as doubling the block size as far as the problems it brings. Only difference is that it would also have the effect of cutting the block halving frequency in half as well. That would have inflation consequences.

Bottom line is that cutting block confirmation times in half would cause the blockchain to get larger faster, which developers say will lead to centralization and would eliminate the need for a patented second layer lightning network which goes against the patent holder’s interests, who also happens to pay the developers.

The current set time frame of ten-minute delay is a built-in function of the bitcoin blockchain validation process.
 It is the standard for an exchange performing a transaction or trade, so as to avoid congestion that might lead to failed, unverified transactions. Hackers might take control too.
Developers set the system in a way that, if transactions are being created too quickly, the system would add a zero to the number of zeros that must start the computed hash for a new block in the Blockchain. Imagine the collaboration.
Before an investor invests into the market, he/she wants to be sure that their funds don't get lost in the process, hence, why a critical look at the effects of lowering the average Bitcoin block confirmation time is necessary.
Anyways, with miners having to enjoy new pay increase and super computers and AI standing aside, it is quite possible to lower the confirmation time and still have a smooth flow, because more hands would be on deck to earn more from mining and new innovations developed to fill the lapse.

If there is a situation comes that more people are making transactions let's say people moved to Bitcoin after they feel it's more convenient then surely the current system is not capable of processing millions of transactions everyday and reducing the block confirmation may not be the permanent solution as well.

But with the adoption the evolution also will be there and I assume that if most of the world moved to crypto for their daily payment then we may see offchain transaction for smaller amounts and onchain only for big transactions (crazy guess though).

However the cogestion we face on Bitcoin network is due to the brc20 crap so removing them from the network itself will solve the congestion and bring back the network to clog free status.

This is just a temporary solution or rather a solution for just two weeks. This process is done when the miners increase the hash rate (which is expensive and somewhat not profitable to the miners) and the interval between mining blocks are reduced, but once the 2016 blocks are all mined then the difficulty will adjust. The difficulty adjust in such a way that when the time to confirm a block is less than 10minutes, it will increase just to set the block average time to 10 minute again. For the miner to get transactions confirmed faster again then it has to increase the hash rate yet again

Reducing the average block confirmation time could be an option, but there are negative effects to consider.  A shorter average confirmation time could increase the risk of forks in the blockchain, as subsequent blocks could be found in rapid succession.  This could create confusion about the "correct" version of the blockchain and require more conciliation effort for the network.  Also, reducing the block confirmation time could increase the likelihood of conflicting transactions or double-spends, as there would be less time for transactions to disseminate throughout the network.

 It is important to balance security and efficiency in the Bitcoin network.  Protocol changes must be carefully evaluated to minimize adverse effects and ensure that the network remains reliable and secure.

Yes it is, in fact we do have blocks that getting confirmed with in few minutes of each other. It's random but it happens

For example, this happened about 1 hour back


This is obvious

---

Sounds reasonable

I was actually looking at it from the adoption point of view rather than the memes. The memes are useless, and we will have to find away of getting read of them. Let's say the memes are out of the picture and Bitcoin adoption has really grown huge with so many transactions streaming in from all corners per minute.

I asked this question when I first joined Bitcoin Talk, and the answer I was given was that it would create more orphan blocks, and decrease the stability of the blockchain. The answer is not more frequent blocks, but the removal of rubbish from the chain. Segwit helped, now lets get rid of the juvenile memes and other dross that is being included at the moment. Bitcoin is suoposed to be a medium of exchange, not a fancy Youtube channel.

I believe that in order to change the average block time, the way difficulty and bitcoin rewards work would also need to be adjusted...and probably would cascade into effects throughout all features of Bitcoin which would then either require adjustment or would raise the question as to if Bitcoin is still economically viable or not. Whether or not this is possible is one thing, though I would be almost certain that it would not pass consensus, as this kind of change would not just effect the speed of transaction times, though would extend all the way from the codebase to the economics of Bitcoin and its viability to operate in the future.

While some solutions seem simple in writing, generally they turn out not to be in practice.

If we reduce the block confirmation time, it could certainly help clear up the mempool faster and potentially lower transaction fees. But we should also consider the impact on network security and decentralization. It's a delicate balance between efficiency and maintaining the robustness of the network. What do you think?

Lowering the average Bitcoin block confirmation time could have several potential effects, both positive and negative:

Faster Transactions: The most obvious benefit of a lower confirmation time is that transactions would be confirmed more quickly. This would allow users to send and receive Bitcoin more efficiently, which could improve overall transaction throughput and user experience.

Higher Transaction Fees: A lower confirmation time could lead to an increase in transaction fees, as users may be willing to pay more to have their transactions confirmed more quickly. This could make Bitcoin transactions more expensive, especially during times of high network activity.

Increased Risk of Double Spending: A shorter confirmation time could increase the risk of double spending, where a user spends the same Bitcoin twice. This is because a shorter confirmation time gives attackers less time to launch a double spending attack before the transaction is confirmed.

Increased Network Congestion: A shorter confirmation time could also lead to increased network congestion, as more transactions would need to be processed in a shorter period of time. This could lead to longer wait times for users, higher transaction fees, and a higher risk of transaction failures.

Overall, lowering the average Bitcoin block confirmation time could improve the speed and efficiency of Bitcoin transactions, but it could also lead to higher transaction fees, increased network congestion, and a higher risk of double spending. Any changes to the Bitcoin protocol should be carefully considered and thoroughly tested to ensure that they do not have any unintended consequences.

Is that even technically possible?

I don't remember in my time on the forum having read anything similar, nor outside of it either, contrary to the block size debate that led to the blocksize wars.

It doesn't seem a bad idea, but we would have to see if it is feasible, and if so, how much the time could be reduced, as half the time doesn't seem enough for the current attack, not for a massive worldwide adption of people paying in the main chain.

I'm not really a technical guy, but if I were to calculate based on a common man's understanding,
If the average block confirmation is being reduced, let's say, for instance, from 4000transaction per block every 10 minutes to 4000 per block every 5 minutes. This will speed up the clearing of more transactions in less time and, as such, pave the way for other transactions to be executed if the transaction completion time is faster and more blocks are being covered than usual. Then there will be a less unconfirmed transaction, which will equally reduce the work load on miners and, as such, won't require others to pay more in order for their transaction to be upfront. Yes, it will actually reduce the fee charged per transaction.

I don't know if this has been discussed before, However let me ask here for some clarity.

Given the current overload of the mempool with around 400K unconfirmed transactions. A scenario came up in my mind where there are over 200K transactions being broadcasted in the network per hour due to an increase in adoption with different Countries using it as recognized payment method. The ~4K transactions per block which get confirmed approx every 10 minutes currently wouldn't help that much in such a scenario.

Apart from the purging of low fee transactions from the mempool, would reducing the average block confirmation time help clear up the mempool and try to keep the average transaction fees lower?

Do you think such a thing can be implemented in the current situation where Ordinals are messing up the network big time?

What are the negative effects of lowering the average block confirmation time?