Bitcoin Forum
May 14, 2024, 03:08:43 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Why blocktime decrease instead of blocksize increase is not discussed?  (Read 1770 times)
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
March 02, 2016, 12:42:18 PM
 #21

This was asked, and answered in another recent thread: https://bitcointalk.org/index.php?topic=1378112.msg14031820#msg14031820
I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while

The answer was that the asymmetry is such that making the time too short (given network parameters, which are not really measurable and not stable) is much, much worse than making it too long.

I continue to assert that reducing the time should not be confused with increasing capacity. A block time reduction by a factor of two, all else being equal, would also be accompanied by a reduction in the block size by a factor of two.

Looking at the data, it seems the negatives of 5 minute block are pretty small and that would give 2MB of blockspace per 10 minutes. So if we assume the error rate difference between 5 and 10 minutes is small enough to being considered equal enough, then having 2 1MB blocks in a 10 minute period sure seems like double the tx capacity per 10 minutes.

Not sure why the blocksize is reduced at half the time, that would defeat the purpose.

given the assumption that 5 and 10 minutes are equal enough, then why would the blocksize need to be cut in half? We can also assume that 1MB per 5 minutes is not any problem for the nodes' bandwidth and wouldnt increase the error rates appreciably.

What error rate at 5 minutes requires cutting the size in half. If there is no need to cut the size in half, then how is it not a doubling in capacity?

Confused...

James

To answer your last question, if you increase the capacity then you are doubling the bandwidth and storage requirements. If you want to do that, and you have buy-in to do that from the relevant stakeholders, then you might as well just increase the block size.

What you are are ignoring in "the data" is this:

The scaling of this depends on factors like network hashpower distribution and latencies which are hard to measure and which change.

Since 5 minutes is "reasonably close" to the inflection point on the graph where being too low becomes much worse and being too high becomes only slightly worse, it seems quite reasonable in light of the above quote to err on the side of (possibly) too high and just implement a 2x capacity increase with an increase in block size rather than a reduction in block time.

In all honesty, and lacking in hard data, I do believe that 5 minutes would be fine, but what's the point? Going well below 5 minutes would most likely not be fine, so that limits any available capacity increase via that method to roughly 2x. Increasing the block size has no such limit.


thanks. mostly makes sense, but the last part sounds like doubling via 5 minutes is a onetime gain and we will have to increase blocksize at some point anyway, so no sense in doubling via 5 minutes.

using that logic, it leaves a "free" doubling unused and to me that seems a waste. Also 5 minutes would offer the advantage of half the latency, which many would view as a positive. so it is not just a lack of negative, but a presence of positive

James

P.S. There are ways to increase capacity 10x or more without increasing blocksize or even reducing the blocktime, but would require more significant changes in the core, but doing both would boost the overall capacity and I thought more capacity was better than less

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
1715699323
Hero Member
*
Offline Offline

Posts: 1715699323

View Profile Personal Message (Offline)

Ignore
1715699323
Reply with quote  #2

1715699323
Report to moderator
1715699323
Hero Member
*
Offline Offline

Posts: 1715699323

View Profile Personal Message (Offline)

Ignore
1715699323
Reply with quote  #2

1715699323
Report to moderator
1715699323
Hero Member
*
Offline Offline

Posts: 1715699323

View Profile Personal Message (Offline)

Ignore
1715699323
Reply with quote  #2

1715699323
Report to moderator
The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
kokojie
Legendary
*
Offline Offline

Activity: 1806
Merit: 1003



View Profile
March 02, 2016, 06:04:41 PM
Last edit: March 02, 2016, 06:17:24 PM by kokojie
 #22

Supposedly, changing the block time is a more complex and bigger change than changing the block size.

I still think it's worth it to have faster block time. 10 minutes is a cruel joke, just read about the many complaints that are happening in the real world:
https://www.reddit.com/r/Bitcoin/comments/48m9xq/average_confirmation_times/

btc: 15sFnThw58hiGHYXyUAasgfauifTEB1ZF6
bathrobehero (OP)
Legendary
*
Offline Offline

Activity: 2002
Merit: 1051


ICO? Not even once.


View Profile
March 02, 2016, 06:29:07 PM
 #23

10 minutes I also think is a joke for today's standards.

And it's clear that pools are strongly against having to process big chunks of data at once regardless of block frequency.
Twice the frequency would cut the amount of data that would have to be processed at a time.

Reducing transaction sizes would probably be the best solution but I'd imagine that would be the most complicated option.


The more I read about the topic the more I feel that there's way too much politics and bickering going on to reach consensus anytime soon.

Not your keys, not your coins!
findftp
Legendary
*
Offline Offline

Activity: 1022
Merit: 1006

Delusional crypto obsessionist


View Profile
March 02, 2016, 07:19:34 PM
 #24

I would suggest you all convert your BTC to nanosecond block time cryptocoins.

Oh wait...

jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
March 02, 2016, 07:44:18 PM
 #25

Supposedly, changing the block time is a more complex and bigger change than changing the block size.

I still think it's worth it to have faster block time. 10 minutes is a cruel joke, just read about the many complaints that are happening in the real world:
https://www.reddit.com/r/Bitcoin/comments/48m9xq/average_confirmation_times/
Anything is more complex than changing the blocksize, since that's just changing a #define, right?

If anybody uses code complexity to reject faster blocktime, they are not using a valid technical objection. Now maybe it is possible to be more backward/forward compatible with larger blocksize but we are talking about a hardfork change and in that context changing blocktime falls into the really easy to do category

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
March 02, 2016, 07:45:54 PM
 #26

I would suggest you all convert your BTC to nanosecond block time cryptocoins.

Oh wait...


the data we were given shows that the error rates for 5 minutes is very close to 10 minutes and I think it was several years old data?, if so, the safe blocktime would be even faster, probably 3 minutes range. Does LTC have massive amounts of orphans?

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Jet Cash
Legendary
*
Offline Offline

Activity: 2716
Merit: 2457


https://JetCash.com


View Profile WWW
March 06, 2016, 11:52:50 AM
 #27

I would suggest you all convert your BTC to nanosecond block time cryptocoins.

Oh wait...


the data we were given shows that the error rates for 5 minutes is very close to 10 minutes and I think it was several years old data?, if so, the safe blocktime would be even faster, probably 3 minutes range. Does LTC have massive amounts of orphans?

James

Thank you - that is what I've been suggesting on this board for some time now. Couple it with a 5 Bitcoin mining reward, and introduce it at the next halving. That seems to be the easiest option.

Offgrid campers allow you to enjoy life and preserve your health and wealth.
Save old Cars - my project to save old cars from scrapage schemes, and to reduce the sale of new cars.
My new Bitcoin transfer address is - bc1q9gtz8e40en6glgxwk4eujuau2fk5wxrprs6fys
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!