Bitcoin Forum
May 07, 2021, 01:04:04 PM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2  All
  Print  
Author Topic: Why all blocksize propositions are round numbers ?  (Read 3255 times)
Erkallys
Legendary
*
Offline Offline

Activity: 1120
Merit: 1000



View Profile
January 23, 2016, 08:58:53 PM
 #1

Actually the blocksize is 1 MB, and Bitcoin classic propose to increase it to 2 MB, Bitcoin XT to 8 MB. Why no one actually proposed 1,25 MB or 1,5 MB blocks ? Is it "allowed" by Bitcoin's code ? Is there any other reason that make that no proposition like this exist ? 1,25 MB or 1,5 blocks would be a softer transition than going directly to 2 MB.
1620392644
Hero Member
*
Offline Offline

Posts: 1620392644

View Profile Personal Message (Offline)

Ignore
1620392644
Reply with quote  #2

1620392644
Report to moderator
1620392644
Hero Member
*
Offline Offline

Posts: 1620392644

View Profile Personal Message (Offline)

Ignore
1620392644
Reply with quote  #2

1620392644
Report to moderator
1620392644
Hero Member
*
Offline Offline

Posts: 1620392644

View Profile Personal Message (Offline)

Ignore
1620392644
Reply with quote  #2

1620392644
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 2464
Merit: 3743


Just writing some code


View Profile WWW
January 23, 2016, 09:03:17 PM
 #2

I don't think there really is any reason for it. I think that it is just because people like round numbers, not decimals. Also, if the increase is really small, like only 0.25 Mb, then it really isn't worth going through the pain of hard forking for such a small increase.

guoyu78
Hero Member
*****
Offline Offline

Activity: 1190
Merit: 541



View Profile
January 23, 2016, 09:05:22 PM
 #3

it's the same if you count in byte ( you loss decimals Tongue ) but a change is hard to accept for both ways....
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106
Merit: 1052


View Profile
January 23, 2016, 09:33:26 PM
Merited by gmaxwell (2)
 #4

Because they're not based on science.

Erkallys
Legendary
*
Offline Offline

Activity: 1120
Merit: 1000



View Profile
January 23, 2016, 09:56:23 PM
Last edit: January 24, 2016, 10:26:27 AM by Erkallys
 #5

I don't think there really is any reason for it. I think that it is just because people like round numbers, not decimals. Also, if the increase is really small, like only 0.25 Mb, then it really isn't worth going through the pain of hard forking for such a small increase.

So there's no real reason except marketing. Also, I don't think that they should do an hard fork, whichever number they choose.


Because they're not based on science.

How could they be based on science ? Please explain.
RocketSingh
Legendary
*
Offline Offline

Activity: 1627
Merit: 1038


View Profile
January 24, 2016, 12:35:38 AM
 #6

Actually the blocksize is 1 MB, and Bitcoin classic propose to increase it to 2 MB, Bitcoin XT to 8 MB. Why no one actually proposed 1,25 MB or 1,5 MB blocks ? Is it "allowed" by Bitcoin's code ? Is there any other reason that make that no proposition like this exist ? 1,25 MB or 1,5 blocks would be a softer transition than going directly to 2 MB.
To the best of my understanding, neither BIP 103 nor BIP 106 Proposal 2 will yield round number as block size max cap.
Erkallys
Legendary
*
Offline Offline

Activity: 1120
Merit: 1000



View Profile
January 24, 2016, 10:28:08 AM
 #7

Actually the blocksize is 1 MB, and Bitcoin classic propose to increase it to 2 MB, Bitcoin XT to 8 MB. Why no one actually proposed 1,25 MB or 1,5 MB blocks ? Is it "allowed" by Bitcoin's code ? Is there any other reason that make that no proposition like this exist ? 1,25 MB or 1,5 blocks would be a softer transition than going directly to 2 MB.
To the best of my understanding, neither BIP 103 nor BIP 106 Proposal 2 will yield round number as block size max cap.

These are flexible blocksize propositions, they are specific cases. When it is a constant blocksize, it is round numbers.
watashi-kokoto
Sr. Member
****
Offline Offline

Activity: 476
Merit: 258



View Profile
January 26, 2016, 01:30:11 PM
 #8

What about 1.337 MB?
Grin
Jet Cash
Legendary
*
Offline Offline

Activity: 1974
Merit: 2090


https://fittotalk.com/english-talk/


View Profile WWW
January 26, 2016, 03:53:34 PM
 #9

Why not pi. Then we can argue about the number of decimal places. Smiley

[
Offgrid campers allow you to enjoy life and preserve your health and wealth.
Erkallys
Legendary
*
Offline Offline

Activity: 1120
Merit: 1000



View Profile
January 27, 2016, 02:12:09 PM
 #10

Actually the blocksize is 1 MB, and Bitcoin classic propose to increase it to 2 MB, Bitcoin XT to 8 MB. Why no one actually proposed 1,25 MB or 1,5 MB blocks ? Is it "allowed" by Bitcoin's code ? Is there any other reason that make that no proposition like this exist ? 1,25 MB or 1,5 blocks would be a softer transition than going directly to 2 MB.

I'm speculating here without real research, but it's likely because of computational efficiency. Things work best as powers of 2, e.g. 1,048,576 (1MB), 2,097,152 (2MB), etc.

This haven't been proposed yet, and I have to confess that it is a really clever idea ! It seems the most probable reason with the psycological effect proposed early.
DannyHamilton
Legendary
*
Offline Offline

Activity: 2464
Merit: 1988



View Profile
January 27, 2016, 04:55:29 PM
 #11

I'm speculating here without real research, but it's likely because of computational efficiency. Things work best as powers of 2, e.g. 1,048,576 (1MB), 2,097,152 (2MB), etc.

No.  The current block limit is not a power of 2:

https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/consensus/consensus.h#L10
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;

Glucose
Hero Member
*****
Offline Offline

Activity: 861
Merit: 1001



View Profile
January 27, 2016, 06:16:30 PM
 #12

I'm speculating here without real research, but it's likely because of computational efficiency. Things work best as powers of 2, e.g. 1,048,576 (1MB), 2,097,152 (2MB), etc.

No.  The current block limit is not a power of 2:

https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/consensus/consensus.h#L10
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;

I guess there is no more choice. The Block size has to increase soon or later. And sooner will be better than later.

I can see how transactions are getting slower and slower. In a few weeks / months the fees are going to explode.

I'll for sure switch to bitcoin classic. 2 MB seems a good first step.

There's probably no reason for 2 MB instead of 1.5 or 5. It's just marketing. 8 MB was too much and noby liked the way the Bitcoin XT project as been presented.

Erkallys
Legendary
*
Offline Offline

Activity: 1120
Merit: 1000



View Profile
January 27, 2016, 06:56:29 PM
 #13

I'm speculating here without real research, but it's likely because of computational efficiency. Things work best as powers of 2, e.g. 1,048,576 (1MB), 2,097,152 (2MB), etc.

No.  The current block limit is not a power of 2:

https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/consensus/consensus.h#L10
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;

I guess there is no more choice. The Block size has to increase soon or later. And sooner will be better than later.

I can see how transactions are getting slower and slower. In a few weeks / months the fees are going to explode.

I'll for sure switch to bitcoin classic. 2 MB seems a good first step.

There's probably no reason for 2 MB instead of 1.5 or 5. It's just marketing. 8 MB was too much and noby liked the way the Bitcoin XT project as been presented.

Please don't do this big mistake ! Bitcoin Core will increase the blocksize soon or later, so don't help the secessionists !
DannyHamilton
Legendary
*
Offline Offline

Activity: 2464
Merit: 1988



View Profile
January 27, 2016, 08:14:55 PM
 #14

I'll for sure switch to bitcoin classic.

I already have.

Please don't do this big mistake ! Bitcoin Core will increase the blocksize soon or later, so don't help the secessionists !

That's ok.  If they increase it to 2 MB then Core and Classic will be compatible.  Then I can just switch back to Core if I like.
BlockSense
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
January 27, 2016, 11:00:04 PM
 #15

Yes in general round numbers are probably easier to work with when defining parameters
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1410


No I dont escrow anymore.


View Profile WWW
January 28, 2016, 08:01:08 AM
 #16

I'm speculating here without real research, but it's likely because of computational efficiency. Things work best as powers of 2, e.g. 1,048,576 (1MB), 2,097,152 (2MB), etc.

No.  The current block limit is not a power of 2:

https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/consensus/consensus.h#L10
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;



Thanks for correcting me! I guess if I took even a few seconds to research I would have come across this  Embarrassed

What you had in mind is 1MiB[1] not 1MB. Sadly its common to use 1MB for both, which means almost anyone is confused with what 1MB actually means (1million bytes or 10242 bytes)

[1] https://en.wikipedia.org/wiki/Mebibyte

Im not really here, its just your imagination.
Glucose
Hero Member
*****
Offline Offline

Activity: 861
Merit: 1001



View Profile
January 28, 2016, 01:39:39 PM
 #17

Please don't do this big mistake ! Bitcoin Core will increase the blocksize soon or later, so don't help the secessionists !

As I said, sooner would be better than later.

I trust Bitcoin Core developpers and I would really be happy if they do so. But they have to do it in time. Right now it seems critical and change has to come really fast.

+ Several secessionists are high profile. They are not just a bunch of idiots trying to break bitcoin.

DumbFruit
Sr. Member
****
Offline Offline

Activity: 433
Merit: 253


View Profile
January 28, 2016, 01:46:49 PM
 #18

+ Several secessionists are high profile. They are not just a bunch of idiots trying to break bitcoin.
These are not mutually exclusive.

By their (dumb) fruits shall ye know them indeed...
DannyHamilton
Legendary
*
Offline Offline

Activity: 2464
Merit: 1988



View Profile
January 28, 2016, 02:39:02 PM
 #19

+ Several secessionists are high profile. They are not just a bunch of idiots trying to break bitcoin.
These are not mutually exclusive.

Those supporting Core are the secessionists, right?

Classic is the original protocol with all of the latest updates, and Core is the software that is trying to split off into their own fork of the blockchain by ignoring some valid blocks and rejecting recent updates.

DumbFruit
Sr. Member
****
Offline Offline

Activity: 433
Merit: 253


View Profile
January 28, 2016, 03:00:21 PM
 #20

+ Several secessionists are high profile. They are not just a bunch of idiots trying to break bitcoin.
These are not mutually exclusive.

Those supporting Core are the secessionists, right?

Classic is the original protocol with all of the latest updates, and Core is the software that is trying to split off into their own fork of the blockchain by ignoring some valid blocks and rejecting recent updates.
I'm genuinely surprised that you support Bitcoin Classic, that should give anybody pause. I thought you were joking earlier. Why do you prefer a simple 2MB hardfork over the Segregated Witness softfork?

By their (dumb) fruits shall ye know them indeed...
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!