How many lines of code do I have to change to move the protocol to 10mb blocks?

[B1tUnl0ck3r]

I bet it's a few 0 to add, and it's done? I read that 10mb blocks require more computational power to be processed by miners before being distributed and as such costing time which may lead to the block being orphaned or that 10 mb blocks would be to big to be move through the internet.

please let's move to the future. most pools have gb/s internet connection and super server machines. a few ns or ms more may truely be a little bit slower but if everyone has to process the 10mb block there is no edge.

and with pruning it will be as light on the disk...

[1714777135]

1714777135

[mezzomix]

One line (src/consensus/consensus.h):

Code:

static const unsigned int MAX_BLOCK_BASE_SIZE = 1000000;

Typically you want to adjust other parameters as well.

[achow101]

Well first you have to add deployment code, and that could take a few hundred lines. Then you have to write tests for it in both C++ (unit tests) and Python (RPC tests) to make sure that deployment works and that you are producing properly sized blocks before and after the hard fork has deployed. That will take a few hundred more lines. Then, not only do you just have to consider the blocksize, you also have to consider big transactions taking up the entire block. Dealing with that could take a few hundred more lines of code. Overall, it's probably around a thousand or two lines of code.

Of course, if you want to do it completely naively without considering that it is a consensus change that requires consensus, you could just change 1 line and call it a day, but your fork will not happen safely at all.

[JaredR26]

I bet it's a few 0 to add, and it's done? I read that 10mb blocks require more computational power to be processed by miners before being distributed and as such costing time which may lead to the block being orphaned or that 10 mb blocks would be to big to be move through the internet.

please let's move to the future. most pools have gb/s internet connection and super server machines. a few ns or ms more may truely be a little bit slower but if everyone has to process the 10mb block there is no edge.

and with pruning it will be as light on the disk...

You'd have to convince an overwhelming majority of bitcoin users to accept your code change.

[JonHind]

One line (src/consensus/consensus.h):

Code:

static const unsigned int MAX_BLOCK_BASE_SIZE = 1000000;

Typically you want to adjust other parameters as well.

yup this would set the parameter enough for the change because the more blocks are mined the blockchain transactions would increase over time

[jonald_fyookball]

Well first you have to add deployment code, and that could take a few hundred lines. Then you have to write tests for it in both C++ (unit tests) and Python (RPC tests) to make sure that deployment works and that you are producing properly sized blocks before and after the hard fork has deployed. That will take a few hundred more lines. Then, not only do you just have to consider the blocksize, you also have to consider big transactions taking up the entire block. Dealing with that could take a few hundred more lines of code. Overall, it's probably around a thousand or two lines of code.

Of course, if you want to do it completely naively without considering that it is a consensus change that requires consensus, you could just change 1 line and call it a day, but your fork will not happen safely at all.

Gavin basically did all this for 8mb blocks and released it as BitcoinXT with Hearn, right?

[B1tUnl0ck3r]

Thank you for your replies! I learned a lot.

[Carlton Banks]

How many lines of code do you have to change to increase the maximum BTC supply from 21 million to 21 trillion

[B1tUnl0ck3r]

How many lines of code do you have to change to increase the maximum BTC supply from 21 million to 21 trillion

None, I change the default unit and call statoshis bitcoin .

Personnally I would even raise the block to 100mb. I mean common, it's 2017. What's the point to have sidechains, when with 100X increase their will be a little space to increase usage.

[achow101]

None, I change the default unit and call statoshis bitcoin .

That's incorrect. You would actually have to change a lot of code to change the default unit (at the very least, all of the display code, not necessarily consensus code). All values in Bitcoin are actually in satoshis, not BTC. This makes it so that we never have to deal with decimals, only integers. Only for display purposes (for us humans because big numbers are hard to understand) are things in BTC.

Personnally I would even raise the block to 100mb. I mean common, it's 2017. What's the point to have sidechains, when with 100X increase their will be a little space to increase usage.

You clearly have not thought through all of the considerations involved in changing the block size. There is not just disk space considerations. You also have to consider that all nodes on the network need to download that block, check all of the transactions in it, and then broadcast it to their peers (so sending multiple hundreds of MB every ten minutes). I don't think many people have internet connections that provide enough bandwidth to allow them to download 100 MB of data (aka one block) in a reasonable amount of time (reasonable being on the order of a few hundred milliseconds since we're talking about computers here). Since block propagation time will likely increase, orphan rates will increase too as miners will have more time to mine a block at the same height as one that was already found.

Then there's the quadratic sighashing problem. A 1 MB block can take 30 seconds to validate because of the quadratic sighashing problem (also remember that, to a computer, seconds is a very long time). Since the problem is quadratic, just increasing the block size to 100 MB means that a block could take 30 * 100^2 seconds to validate, which is 300000 seconds, ~3 and a half days.

There are also several other considerations too like the time it takes to do the initial sync (which includes downloading the blockchain and then verifying all the blocks and transactions), the CPU and RAM resources required to process the block, etc. So if you think increasing the block size to 100 MB is a good idea, please, think again and actually consider everything that goes into sending, receiving, storing, and validating blocks, not just storing blocks on disk.