Bitcoin 20MB Fork

[DeathAndTaxes]

A grep of my debug.log says otherwise. Looks like this "version 2" thing got up to 5% for a time, and then dropped back down to 1%.

Do you just parrot what other people say without even understanding the meaning of the words or the context in which they are said?

100% not 1% or 5% of blocks are version 2 because any miner producing version 1 blocks would be on a separate fork for years now.  The sad thing is anyone who does independent thinking could figure this out by simply looking at the block header of any recent block.  Current block? Yup version 2.  The one before that?  Yup version 2.  The one before that?  Yup version 2.  Going back 100,000 blocks in sequence?  Yup all version 2.

Once 750 of the last 1000 blocks the block height rules started being enforced in version 2 blocks and once 950 of the last 1000 blocks were version 2 then version 1 blocks were considered invalid. That happened over three years ago.  

Version 3 blocks are currently a low percentage but version 3 blocks first became available as an option to miners in v0.10 of bitcoind which was release a whole two days ago.  The idea that it won't eventually reach both the 75% and 95% thresholds is just silly.  Non-enforcement of DER encoding just enables txn malleability.  There is no purpose to it.  The network currently treats non DER signatures as valid but non-standard.  It is very rare for any block to have a txn with non DER encoding anyways.   Last time I checked it wasn't even 0.1% of transactions with non-standard encoding.  The election of version 3 would simply make this existing behavior a permanent part of the consensus rules.

Of course neither of these versions have anything to do with raising the block limit.
Version 2 - enforces recording block height in coinbase txn (BIP 34)
Version 3 - enforces DER encoding of signatures (BIP 66)

The first possible version which would integrate a new block limit would be version 4.

https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki

[NewLiberty]

The ttl of a future block height was the method proposed by satoshi years ago as part of the method of increasing the maxblocksize

The WWSD argument has been refuted already.

IV. Satoshi himself envisioned much larger blocks.

The discussion of what "Satoshi himself" did or didn't do, meant or didn't mean, so on and so forth is about as interesting and discussing the Mormon "bible".

This is called "arguing to authority", and it tries to give pecuniary value to that only truly worthless article of all times and places : the esteem of the mob. This may work well in electing United States presidents, ensuring that "while the voting public knows best what it wants, it deserves to get it long and hard". Bitcoin specifically and deliberately does not work in this way.

Bitcoin is not a reflection of your hopes and aspirations, but a check on them. Bitcoin isn't here to make it easier for you to do what you want to do ; Bitcoin is here to make it trivial for others to prevent you from doing what you want to do every time that's stupid. The sooner you comprehend this fundamental difference between Bitcoin and "technology" especially in the "revolutionary & innovative" subsense of that nonsense, the better, for you.

Satoshi probably doesn't even know what's in his code, let alone how to improve it.

Sure... except this was not an appeal to an authority.

In case the point of this comment was lost to you, it was this:
The part of the conversation that was interesting to sed (what was referred to as the ttl) was not novel to the #bitcoin-assets discussion but was discussed in 2010 when the maxblocksize was initially created.

But since you brought it up, why are you attacking someone here that isn't going to be able to respond? (satoshi)  What satoshi would or wouldn't do, or what he does or does not understand, is not part of this discussion. 

[sed]

The ttl of a future block height was the method proposed by satoshi years ago as part of the method of increasing the maxblocksize

The WWSD argument has been refuted already.

IV. Satoshi himself envisioned much larger blocks.

The discussion of what "Satoshi himself" did or didn't do, meant or didn't mean, so on and so forth is about as interesting and discussing the Mormon "bible".

This is called "arguing to authority", and it tries to give pecuniary value to that only truly worthless article of all times and places : the esteem of the mob. This may work well in electing United States presidents, ensuring that "while the voting public knows best what it wants, it deserves to get it long and hard". Bitcoin specifically and deliberately does not work in this way.

Bitcoin is not a reflection of your hopes and aspirations, but a check on them. Bitcoin isn't here to make it easier for you to do what you want to do ; Bitcoin is here to make it trivial for others to prevent you from doing what you want to do every time that's stupid. The sooner you comprehend this fundamental difference between Bitcoin and "technology" especially in the "revolutionary & innovative" subsense of that nonsense, the better, for you.

Satoshi probably doesn't even know what's in his code, let alone how to improve it.

Sure... except this was not an appeal to an authority.

In case the point of this comment was lost to you, it was this:
The part of the conversation that was interesting to sed (what was referred to as the ttl) was not novel to the #bitcoin-assets discussion but was discussed in 2010 when the maxblocksize was initially created.

But since you brought it up, why are you attacking someone here that isn't going to be able to respond? (satoshi)  What satoshi would or wouldn't do, or what he does or does not understand, is not part of this discussion. 

Agree, thanks for pointing that out to me (about satoshi's suggestion for using a sort of min blockchain height to do a time-to-live sort of delay).

[cbeast]

Visa seems to get along fine with a peak tx volume that's about 12 times their average tx volume.

STOP COMPARING BITCOIN TO VISA! THEY ARE NOT ANYWHERE NEAR THE SAME THING.

I weary of this comparison. Bitcoin isn't about becoming the singularity of payments. Bitcoin is about Fair Money. Indebtedness should be a choice, not forced upon by governments.

[solex]

I thought that the most interesting idea in that log was the one about implementing the fork with a ttl of 2 years.  By the time those two years have passed, everyone will have forgotten that this was such a big issue.

Fantastic! It is now only 4 days until two years since I was concerned enough to post a topic and poll on the 1MB issue. Only 4 days until everyone forgets about it and maybe Gavin can do what he thinks is best without any blowback?  

The poll result in Feb 2013 was:

Leave as one megabyte - 20 (21.5%)
Let Core Dev decide   - 34 (36.6%)
Agree to increase   - 39 (41.9%)

Looks like the vote to leave as 1MB is still just 20% and unchanged in 2 years.  

Note: this topic was posted when Litecoin was the only alt with any real potential. There are 1000 alts issued since then, and some do have the potential of making Bitcoin the Myspace of cryptocurrency, if it trips up. Also, the prediction of running out of block space in 2013 was based upon SatoshiDice pumping out 50% of the transactions and only getting bigger. Erik Voorhees slowed it down and Core Dev increased fees to eliminate a lot of spam. That is how we have reached 2015 with the 1MB limit still intact and not yet being consistently hit.

Max Block Size Limit: the community view [Vote - results in 14 days]

Satoshi Nakamoto decided upon a one megabyte block size limit for Bitcoin. He viewed it as a temporary measure, but because it has remained fixed for so long it can reasonably be considered by some as a permanent limit. This means currently that the Bitcoin blockchain can not grow faster than 1Mb every 10 minutes.

If the limit remains fixed then Future A will be the road ahead. If the limit is raised or set by an algorithm, then Future B lies ahead.

Future A: Bitcoin will never handle more than 7 transactions per second. This is a tiny fraction of that handled by major payment systems. Evenutally 99+% will need to be handled by third-party services (such as Coinbase), bitcoin "banks", trusted transfer layers or even alt-chains. Only large transactions (with high fees) get included on the main blockchain. Bitcoin never makes large payment systems obsolete (Visa, Mastercard, PayPal) but full nodes can be run by individuals with moderate computing power and bandwidth. People can personally verify the integrity of the bitcoin network, even though it operates analogously to an internet backbone, but for currency, and people's transactions and holdings are held elsewhere. Mining the main blockchain will remain a niche business,

Future B: Bitcoin grows to handle hundreds or thousands of transactions per second. Perhaps Moore's Law can keep up so that some individuals can run full nodes, although lightweight nodes will be necessary for nearly all. Big companies run nodes. All transactions which people want to have on the main blockchain (with low fees) are supported. Third-party services do not have to be used unless they add value, faster confirmations, etc. Existing large payment systems will wither. Mining the main blockchain will become a big business.

It is fair to say that this subject has been exhaustively discussed in many threads. There are many arguments for and against, so people are invited to wade through the history of the debate before deciding to vote.

Any change will require a hard-fork i.e. everyone will need to upgrade their software. It will likely be necessary before the end of 2013 based upon transaction growth rates. Of course, if no change is decided upon then the limit will become a real constraint, fees will rise, zero-fee transactions will no longer be processed, third-party services must fill the gap.

Jgarzik > [PATCH] increase block size limit
https://bitcointalk.org/index.php?topic=1347.0

caveden >  Block size limit automatic adjustment
https://bitcointalk.org/index.php?topic=1865.0

barbarousrelic > Max block size and transaction fees
https://bitcointalk.org/index.php?topic=96097.0

Jeweller > The MAX_BLOCK_SIZE fork
https://bitcointalk.org/index.php?topic=140233.0

Misterbigg > Why do people pay fees? Why are free transactions accepted by miners?
https://bitcointalk.org/index.php?topic=144421.0

Retep  > How a floating blocksize limit inevitably leads towards centralization
https://bitcointalk.org/index.php?topic=144895.0

notig > The fork
https://bitcointalk.org/index.php?topic=145072.0

hazek  > Why the Bitcoin rules can't change (reading time ~5min)
https://bitcointalk.org/index.php?topic=145475.0

[NxtChg]

So I would suggest a block size limit set once every 2016 blocks at the same time as difficulty retargeting, at 12 times the average for the previous 2016 blocks.  

Why once? Why can't it be a sliding window of 2016 blocks?

So here are some changes I propose:

1. A sliding window of, say, 2016 blocks.

2. We track median block size in this window. (Median makes it impossible to game unless you can generate 51% of blocks and is also more conservative to occasional random spikes).

3. We set the block limit to something a bit smaller than VISA, again to be conservative, because blockchain has a cost. So, say, x10 or x8, not x12.

4. We track median transaction fee in each block and then the median of those inside the window to get Median Tx Fee.

5. We impose a line of minimal tx fee for each new block. It starts at 10% Median Tx Fee (to protect from spam and unimportant txs) and raises slowly to something like x2 at the block limit. The exact parameters can be tweaked, but the general idea is to put additional pressure on miners not to blow up block size.

It would also be nice to put both block size and median tx fee for this block into the block header, so it's easier to validate chains or calculate min tx fee required.

Here's a graph to illustrate.



If a miner wants to add Sample Tx at that point, he must make sure it has the fee that will be above minimum tx fee imposed by the red line.

The farther into the block you go, the larger the minimum fee must be.

[onemorebtc]

So I would suggest a block size limit set once every 2016 blocks at the same time as difficulty retargeting, at 12 times the average for the previous 2016 blocks. 

Why once? Why can't it be a sliding window of 2016 blocks?

So here are some changes I propose:

1. A sliding window of, say, 2016 blocks.

2. We track median block size in this window. (Median makes it impossible to game unless you can generate 51% of blocks and is also more conservative to occasional random spikes).

3. We set the block limit to something a bit smaller than VISA, again to be conservative, because blockchain has a cost. So, say, x10 or x8, not x12.

4. We track median transaction fee in each block and then the median of those inside the window to get Median Tx Fee.

5. We impose a line of minimal tx fee for each new block. It starts at 10% Median Tx Fee (to protect from spam and unimportant txs) and raises slowly to something like x2 at the block limit. The exact parameters can be tweaked, but the general idea is to put additional pressure on miners not to blow up block size.

It would also be nice to put both block size and median tx fee for this block into the block header, so it's easier to validate chains or calculate min tx fee required.

Here's a graph to illustrate.



If a miner wants to add Sample Tx at that point, he must make sure it has the fee that will be above minimum tx fee imposed by the red line.

The farther into the block you go, the larger the minimum fee must be.

i'd prefer something like ema over median because it reacts faster in case of changes. but i still think we dont need any limit at all.

(this works even if one miner tries to outcompete others by producing one 1tb block - just think about the why for yourself)

[NxtChg]

...but i still think we dont need any limit at all.

(this works even if one miner tries to outcompete others by producing one 1tb block - just think about the why for yourself)

There is a grey area where the sizes are somewhat "reasonable", and since miners are essentially paid per byte and everybody else isn't, having some additional pressure on them would be good.

There are also indirect costs, like risks of centralization, difficulties with TOR, etc., which are not priced in for miners.

[onemorebtc]

...but i still think we dont need any limit at all.

(this works even if one miner tries to outcompete others by producing one 1tb block - just think about the why for yourself)

There is a grey area where the sizes are somewhat "reasonable", and since miners are essentially paid per byte and everybody else isn't, having some additional pressure on them would be good.

There are also indirect costs, like risks of centralization, difficulties with TOR, etc., which are not priced in for miners.

miners are not paid by byte - atm they are paid by reward.
they have the incentive to keep bitcoin going
and they want smaller blocks to reduce their orphan rate

[NxtChg]

miners are not paid by byte - atm they are paid by reward.

I am not talking about what's happening right now. My concerns are for the future, when reward is low and fees become more important.

[onemorebtc]

miners are not paid by byte - atm they are paid by reward.

I am not talking about what's happening right now. My concerns are for the future, when reward starts to drop and fees become important.

that still means that they have the incentive to produce smaller blocks to not get orphans.

btw. IPOcoin scammer.... why are you here? maybe finish simcoin?

edit: full disclaimer: i "invested" a little in simcoin because i live simplicity. i realized too late it was pos. i got out as fast as possible and made a small win.

[NewLiberty]

This is where my conversation with Gavin fell apart.  He was not able to acknowledge the concept of a too-high limit.  His reasoning was that since the limit was only one-sided (blocks with size above it are prevented) that it couldn't be too high.

Huh what?
...

If you want to continue the conversation, please be very explicit about what problem you think needs solving, and how whatever solution you're proposing solves that problem.

As simply as I can put it:
The proposal is both inaccurate and indefinite, the proposal should not be both.  


Now a few words on why...
We do not yet have the mechanism for an accurate limit (one that conforms to need such as those I and many others have proposed), so an indefinitely increasing limit should not be suggested.
It should not be done because it might be good enough for a while, and then suddenly not be good enough and we won't be prepared for that (whether it is too high or too low at that point, we can't say now).  It introduces pernicious catastrophic failure potentials.


It may help to think about the US debt limit debates...
The US Congress keeps raising the debt limit.  Congress will keep doing it. They wont let it get hit, or if they do, not for long.  There is a history of exponential debt growth.  So why not propose one that increases exponentially forever?  Wouldn't that make sense?  It would be practical.  There are arguments in favor of it.  What it would also do however, is remove the incentive to get it right until it becomes VERY wrong.  Its just a limit, congress doesn't have to spend it all.

We have a similar problem with the block chain data size.  It is a problem of the commons.  The storage and maintenance is done by many, but each individual block doesn't bear the cost.  There is a small marginal cost in orphan risk, but this risk fades over time as block rewards increasingly become fees rather than coinbase.  There is no economic incentive to run a node, only mining, but the nodes are also necessary for the security and resilience and speed of the network.

[davout]

If you want to continue the conversation, please be very explicit about what problem you think needs solving, and how whatever solution you're proposing solves that problem.

Actually, that's something the one proposing to fork should answer. And yes, that's you.
So far I'm really not convinced it is necessary.

[NewLiberty]

If you want to continue the conversation, please be very explicit about what problem you think needs solving, and how whatever solution you're proposing solves that problem.

Actually, that's something the one proposing to fork should answer. And yes, that's you.
So far I'm really not convinced it is necessary.

I'll assume for the sake of discussion that it is necessary (or ultimately will be).

What we need is a proposal that is either definite or accurate. 
We can't safely move to a guess with an infinite progression.  It is a great idea, but it is too risky.

[davout]

I'll assume for the sake of discussion that it is necessary (or ultimately will be).

"I'll assume, for the purpose of discussing X, that X is already granted".

Seriously. What kind of braindamaged logic is this?

[onemorebtc]

I'll assume for the sake of discussion that it is necessary (or ultimately will be).

"I'll assume, for the purpose of discussing X, that X is already granted".

Seriously. What kind of braindamaged logic is this?

i still would like to hear when you think such a change is necessary.
you dont seem to be against any blocksize change as long as it is not needed: how do you define needed in this case?

[Lauda]

i still would like to hear when you think such a change is necessary.
you dont seem to be against any blocksize change as long as it is not needed: how do you define needed in this case?

In his view, there is no definition of needed in this case. (hope that I'm not mistaken)

[danielpbarron]

I'll assume for the sake of discussion that it is necessary (or ultimately will be).

"I'll assume, for the purpose of discussing X, that X is already granted".

Seriously. What kind of braindamaged logic is this?

i still would like to hear when you think such a change is necessary.
you dont seem to be against any blocksize change as long as it is not needed: how do you define needed in this case?

I define "needed" as when MP says so.

Along those lines, I am against anything proposed by Gavin; even a cure for cancer.

danielpbarron: SetBestChain: 1 of last 100 blocks above version 2 << anyone else seeing this in their .bitcoin/debug.log ? does it have to do with 0.10 coming out?
punkman: blocks version 3 now
danielpbarron: well.. 1 in 100 at least
punkman: oh and they are already talking about version 4
danielpbarron: bu-but.. the forum poll said it had 60% support!? how can this 1% be?
asciilifeform: axe-time, sword-time, coming closer.
punkman: well v3 brings strict signature format, not such a bad thing
asciilifeform: punkman: not bad thing if -we- do it
asciilifeform: if phoundation does it - cure for cancer is bad thing.
asciilifeform: ipso facto.

[NewLiberty]

i still would like to hear when you think such a change is necessary.
you dont seem to be against any blocksize change as long as it is not needed: how do you define needed in this case?

In his view, there is no definition of needed in this case. (hope that I'm not mistaken)

A max block size is needed because of the asymmetric incentive structure. -- There is no increase in revenue for node running with larger blocks, only increased costs.  Under free market conditions, the larger the block chain data set gets, the worse our node/miner ratio should be expected to gets, and we should expect a declining # of nodes overall, even with increased mining.
This is a bad result for network resilience and performance.

But... that is just the benign bad effect, one of the pernicious risks that would aggregate (with an indefinite and inaccurate max block size) would be an increasingly easy attack on this pain point.  Eventually, someone who wishes bad things for Bitcoin could mine fully padded blocks of transactions to from and to themselves and increase the costs for everyone else at no marginal cost to the miner.

If the economic incentive structure were fully resolved (and I don't think that we know how to do that yet), there might be no need for a max block size!

The root of your question is another problem, I've discussed elsewhere.
For so long as we are stuck with some hard-fork based solution, we ought also set forward a criteria for changing it.  Currently it is structured in a central banking type small group of deciders which is going to be a source of criticism.
What is needed also is some mathematical method of determining when it should be raised (or lowered).  Getting this right would give us the "accurate" part of the solution of not being both inaccurate and indefinite.

So... assuming there is a problem, the current proposal is not the solution.

[NewLiberty]

We look to change max block size for expediency's sake only.  (bigger faster)  Not because any of us know yet what it should be.

If we get a (TBD) criteria for changing max block size that makes sense.  An inaccurate but definite change would be just fine with me.  Whatever arbitrary max block size is picked is ultimately going to be "wrong" in the same way that the one satoshi picked is "wrong" based on the (TBD) criteria.

So...  a new static limit of X MB would be inaccurate but not indefinite.  Still wrong, just less wrong, and so acceptable for expediency's sake.