Topic: Why bitcoindev prefer to SegWit, we should represent block time to 2 min (Read 977 times)

Changing the block interval is more invasive and complicated than simply increasing the blocksize.

Both would increase capacity but Core has made it clear they will only support their own roadmap,
not the simple, sensible on-chain scaling.

This is something I have been suggesting almost since I first joined Bitcoin talk. At some stage the 10 minute interval will have to be reduced for Bitcoin to stay in the market. It has been pointed out that there are problems with the creation of orphaned blocks, and that some people are working on possible solutions. I believe that this should become a priority now that core efficiency has been improved.

That is correct your suggestion might be too late since it can no longer put to test and will never be implemented. Given the time it we are only a few months earlier before we will see a birth of new altcoin which is BTU. There is nothing wrong with hardfork but its just that it stays away from the original bitcoin code. Thus the split of bitcoins into two could never be stopped anymore.

Litecoin requires 6 confirmations,

If BTC moved to a 2 minute block speed , all they have to do is increase the # of confirmations to compensate for the increased orphans.

With BTC at 10 minute & 3 confirmations, average is ~30 minutes for a Safe Transaction

With BTC at a 2 minute blockspeed , confirmations could be increased to 9 confirmations for a total of 18 minutes

So the 9 confirmation BTC would be safer than the current 3 confirmation chain and be done on average 12 minutes faster.   
(This would counter the orphan FUD being spread by deadwit supporters.)


 

this increase the orphan rate as a primary concern, you didn't see that litecoin has this issue since ever? maybe they solved it recently with the last upgrade of the code(i didn't follow litecoin anymore so i don't know here)

bu one of the solution to this was to add subchain to reduce orphan( don't confuse subchain with sidechain here, they are different things)

Some Exchange Markets try to push HF , it might be too late

@rallier  ,

You are Spot on .  

Your Idea would work and remove the blocksize debate for a few years.
Be interesting to see how the powers that be try to refute your very well made argument.

Segwit was dead before it started ,   Your Idea would fix BTC Transaction Capacity Issues for quite some time.

 

10 minutes or 2 minutes, your still playing the real life argument of

"but i cannot just stand in a grocery line or the line at the rent office for 2-10 minutes waiting for a confirm"

even 2 minutes is still too long for the majority of arguments that are being poked at the 10minute average
hence the LN service as a NICHE and VOLUNTARY side service for those wanting quick 'service' (emphasis voluntary not compulsory)

---

also. you have to think of the relay network (propagation risks)
if nodes have 8 connections(as an example), it means to get data to all the nodes requires atleast 4 hops if everyone had the 8 connections each (degrees of separation/web peer connectivity)

imagine you download a block in 1second
imagine you verify a block in 2second
but then need to push it out to 8 nodes(8seconds)

3second receive-verify 8seconds(send 8 times) relay nodes receive = 11seconds per hop
44-55 seconds for whole network to receive it

knowing that the 10 minute rule was not a exact science but an average of many blocks over a timescale.

there would be many issues of higher orphans and fighting over blockheight compared to today. where by more blocks are found within seconds of each other before the whole network has received and settled on an fully agreeable new blockheight.

we already even with the 10 minute rule have blocks being found with 20 seconds of each other but then find one of them is dismissed and thrown aside because the network believes another block deserves precedence to be added to the blockheight.

---

thirdly messing with the reward halving and the timing may seem mathematically possible and only cause mining for reward to stop 8 years earlier affecting just 0.00733~btc of total cap
the sentiment of being able to change the amounts(although end result is so far away and so small deviation) opens up the floodgate of loss of trust that it will/wont be changed again but with a bigger impact sometime in the future

---

knowing that bandwidth and storage of 1mb/2min is the same as, say 5mb/10min
is not helping bandwidth or storage. so those debates will still continue aswell as adding the debate about propagation risks (as mentioned above)

all for a 2 minute AVERAGE waiting period which some people believe is still too long for real world use anyway
..
where as
a 5mb block (based on OP's DATA of scenario used over the standard 10minutes)
the relay propagation risk has more breathing room to get the blocks around the network before worrying about the other competition as much and also without worrying about the next block height after that being solved before all nodes get the first block.
plus it doesnt mess with the reward halving timing. rewards per block, difficulty retarget or the predicted 2140~ end day of reward mining

Not a planned hard fork, it's a rogue hard fork perpetrated by miners behaving with malign intent. It could happen at any time, so it's likely that the Bitcoin devs would not have the time to prepare that code for a change like this, they would be more likely to try to do only the things that mitigate the problems of having 2 Bitcoin chains existing simultaneously.

Also, there are numerous other improvements to the transaction rate that could be implemented vai hard fork, this is only 1 such idea.


Saying that, I broadly support this idea, but only if it can be demostrated to be safe and effective with a convincing study of the issue. Orphan rates and block propagation have seen significant improvements over the Bitcoin version 0.1 design, and the performance of the internet's infrastructure has also improved since then.

So it's not something to rule out, it would be good for the network if a proper case were made for what interval could be handled safely. But it comes with trade-offs, as everything does, let's not forget the practical points against doing it, as well as the practical points in favour.


Above all, this is a very important reminder: big blocks is not the only way to increase the transaction rate, and big blocks just so happens to be the most dangerous way to do it, as it doesn't improve the scaling of the network, big blocks deteriorate the scaling properties of the Bitcoin network

Halving time will be set like block reward the original  supply plan. it won't be need to change.
In implementations, I don't worry about that, it would be adapt like SegWit.

-Update miner clients (solo/pool) What is it implementation version.
-Support new block timing.

What can we do more safe?
We will expecting like X block for auto support. Miners / Pools just update bitcoin core clients.
We can set a timer like X Block (after [X-Last block]*10 minutes),  it will be supported automatically for all updated miners

No, you just change the way the coins are generated per block afterwards to fit the original supply plan.

---

This is too drastic. How about just halving the time, so that we have 1 block every 5 minutes? I wonder what kind of implications this has, and whether it is safe? I've not seen much talk about actually doing this.

You, we need to be ready any change and understand what do we need. I want to reply in here for your other post on other topic;


Yes i know it is discussed a lot of ago, you are right but we are still facing to HF. If we need to HF with any way, we will discuss to again for best solution.

Inherent latency of TCP/IP networks will be more effective in smaller block size but i think smaller block time will be more effective than more block size because we can discuss to best timing it doesn't need to be 2 minute, we will prefer to 2.5 min, ... whatever.

An other example, if you are mining bitcoin, your network connection will be corruptible, In worst case; your miners will be affected for 10 minutes. Other hand, In worst case, it will be affected for 2 minutes.

This would be a hard fork, and better ideas could be introduced in any hard fork (as just about anything about Bitcoin can be changed in a hard fork, that's what defines a hard fork)


It's not the worst solution, but hard forks give us the opportunity to make pretty much any change, it doesn't make much sense from that perspective.

I really prefer small block times. This is better to bet at block 400 000 after 8 years than 2 000 000 after not even two...

I disagree.

The block time effects the inflation rate, how rapidly coins are created.

A shorter block time would increase inflation and I doubt very many people want that.

Bitcoin Core Dev try to adaption with SegWit. But Chinese Miners face to possible network problem because of Chinese Government Pressures.
Why shouldn't we represent block time to 2 miniutes or like that with block bounties.
Doesn't change on ecosystem. Am i right?

Ethereum didn't be fail with smaller block time than bitcoin block time.
Why are we so afraid smaller block time? If an attacker want to compromise to system with double spent (or etc/something like that..), he could be with 10 minute block time.
So either way, other attack methods doesn't easy with existing bitcoin diffuculty, you know.

I guess development need to be open minded for user requirements of ecosystem


(if i have a bad on my english grammar, sorry for that.)


I try to explain with an example why am i

Now on Bitcoin:
1 block time = 10 Minutes
1 block reward = 12.5 Bitcoin
2 weeks / 10 minutes = 14 * 24 * 60 / 10 = 2016
Bitcoin halving = 210,000 blocks
Bitcoin block size = 1 MB
Bitcoin transaction average  = 3 tx / sec ( https://blockchain.info/tr/unconfirmed-transactions you can check in there)

We could change to this : (an suggestion)

1 block time = 2 Minutes (10/5)
1 block reward = 2.5 Bitcoin   (12.5/5)
2 weeks / 2 minutes = 14 * 24 * 60 / 2 = 10080 ( 2016 x 5 )
Bitcoin halving = 1,050,000 ( 210,000 blocks x 5 )
Bitcoin block size = 1 MB > didn't change  (Chinese miners problem will be solved)
Bitcoin transaction average  = 15 (3 x 5) tx / sec ++++++++ (our problem will be solved)

If we will adopt like that, doesn't change in inflation