Future Automatic Increases In Block Size May be Frustrating Our Efforts While Giving No Advantage

[berrtus]

I think locking in future block size increases is a mistake.  I would not post here and instead just Reddit, but I feel xt may go nowhere unless the future block size increases are taken out of the code.  I know this sounds radical, but part of my reasoning really shows my idea is not any more limited than the automatic increases are anyway.  Let me explain.  Firstly, there is a mistake in the assumption that we can predict future network growth.  Let n be the number of years forward.  I think future network growth is somewhere between 2^(n +1) and 2^(-n) as time goes forward.  It looks like future increases of every other year leave us at 2^(n/2) as our guess.  That leaves us with a max possible error of 2^(1.5n) so if we are six years forward we could be off by a factor of 2^9 a big amount.  This basically leaves the odds that the automatic increases are correct or even within a power of 2 as best approximated by zero.  Now, I am aware that the automatic increases may prevent a hard fork if they happen to be correct, but they won't be.  I am also aware they do no harm compared to not putting them in because not putting in the automatic increases in block size is also an assumption.  Except, and this is very important:  

Miners perceive xt as too aggressive, and mostly because of the future block size increases that will have to certainly be revised anyway.  

In fact more than 50% of the mining power, at least, has that viewpoint.  Read more here:  https://www.reddit.com/r/rBitcoin/comments/3vadqm/charlie_lee_creator_of_litecoin_and_bobby_lee_ceo/

So while the guess as to the correct blocksize will surely be wrong by more than a power of 2, and hence in reality useless, it is completely preventing the adoption of xt by miners.

  

Final point: We for a fact are going to need hard forks anyway to implement things like thinner blocks and other possible updates.  Hard coding in future increases is just putting people off and is not solving anything.  I propose an initial one time increase to 2mb or 4mb blocks.  Four is more reasonable, but let the miners decide what they want.  We need to take the initiative back from Blockstream Core and solve this.  We can't try to solve it for all time in the future as that won't work anyway.  In fact the automatic guess is not useful and is putting people off.    Additionally, a complete solution may come from something like dynamically sized blocks.  The best way to proceed is to make a bullet proof and error proof code and get it ready NOW, not several months out.  We should for sure take out RBF, and implement a ONE TIME reasonable block size increase.  To summarize my three main points: 

1. The probability of guessing ideal block size to within a power of 2 tends to zero as n the number of years out increases, and it tends to near zero quite quickly.

2. Miners and others think or perceive xt as too aggressive:https://www.reddit.com/r/rBitcoin/comments/3vadqm/charlie_lee_creator_of_litecoin_and_bobby_lee_ceo/ and we are needlessly creating this problem with code that did not solve the future scaling issue anyway.

3. Most likely we will need other hard forks anyway for obvious reasons like thinner blocks, and other improvements in the works.  We can increase blocksize again then.  Yes, it may have to be debated yet again, but automatic increases won't solve that problem either.  And we may solve the issues in other ways such as thin blocks.  

[Gavin Andresen]

On Fri, Dec 4, 2015 at 10:29 AM, berrtus <ber...@gmail.com> wrote:

I think locking in future block size increases is a mistake.

First: BIP101 does not lock in any block size increases, miners will continue to control how large blocks can be.

Second: I disagree. The biggest technical problem facing Bitcoin right now is uncertainty as to how this issue will be resolved. A one-time increase or series of short-term increases just extends the period of uncertainty.

--

--
Gavin Andresen

[Christophe Biocca]

If that was the case, the BIP 102 (the one time bump to 2MB) would be the one supported by miners. It isn't. We know what the other miners want, mostly, and it's the potentially faster growing BIP 100. Why? Because they've bought into (or been talked into) the "fee market through scarce block space" idea, and BIP100 provides the the perfect supply-cartel creation mechanism.

Given that, no increase will happen that doesn't have the property of keeping block sizes scarce, until and unless a majority of hashpower abandons that goal. So you might get 1.1 MB blocks right now, maybe. You could even talk them into automatic increases, as long as they're hilariously low.

But this is a philosophical disagreement. The people you find here tend towards large automatic increases (or even no limit whatsoever) because we don't believe the block size limit is meant to actually kick in at all under normal operation. It's an anti-DOS measure, and as such the question isn't "What's the ideal block size?" (because we don't expect block sizes to ever be near the limit) but "how big can a block be without crashing nodes or causing other problems with the network?". It's a substantially easier question to answer, because we don't have to drag economics/politics into it.

Hence why on this side of the divide you see people with preference for BIP101 who would still support something else if it gained traction. And on the other side you see dozens of different schemes that must try to get things exactly right and a lot of disagreements about what consistutes a good block size increase function.

[berrtus]

Miners control block size but they don't like the block size limit being automatically increased to larger numbers several years out.  They think the future increases in the block size limit are too aggressive.  This is in fact the reason they are not adopting xt code yet.  The mistake though is the assumption that the issue has been resolved by putting in some number for automatic increases.  The issue has in fact not been resolved.  It will come up again when the automatic increases in the block size limit are off by more than a power of 2, and that will happen most likely within about one to two years. We cannot end the period of uncertainty.  The reason is we cannot solve it with static blocks.  So though we do not like the uncertainty we are stuck with it.  The real reason this has become such a problem is that Blockstream Core is negligently refusing to increase block size limits.  

[HostFat]

- BTCC don't represent all the miners.

- Miners have a very little space to make choices.

The size on the blocks should be enough to achieve these goals:

- Avoid fee market

- Stop DOS attack (too much bigger blocks)

It could be even unlimited if there was something on nodes that gives high priority to smaller blocks against bigger blocks. (this should be an automatic way to go against DOS attack)

[berrtus]

BTCC accounts for 14% of hash power, they likely represent the views of other miners, they are likely a leader and would be followed.  It would be nice to have them on board:

http://www.ibtimes.co.uk/even-chinas-crypto-brothers-bobby-charlie-lee-dont-entirely-agree-scaling-bitcoin-1531695

We are making the mistake of attempting to impose our 'logical' reasoning in a way that appears unacceptable to the miners, but our reasoning is actually flawed anyway.  This is because we think we have solved the network growth issues with automatic increases and therefore ended the debate, but that is all highly unlikely.  It will only be true if the increases exceed network growth and not by so much as to allow vulnerabilities.  But other players are not willing to agree at this time to long term increases in the block size limit.  We, therefore, have not really solved the problem while we are digging our heels in on an issue that is preventing the adoption of xt.  Our position is unnecessary and giving us no benefit.  Future hard forks will give a chance to increase block size again, and future approaches may solve the issue in other ways.

[Tom Zander]

On Friday 04 Dec 2015 08:14:41 berrtus wrote:
> Miners control block size but they don't like the block size limit being
> automatically increased to larger numbers several years out.

The schedule for increase is really not doing what you are saying it does.

All the 101 schedule does is stay in step with the technological increases.
Much like a yearly paycheck raise keeps up with inflation.

Not keeping up with technology is really a decrease in size as 1MB 10 years
ago was much more expensive to send over the internet than it is today.

BIP101 is *only* keeping up with standard technological speed. It doesn't grow
the sizes of blocks.

[Peter Tschipper]

Up to the maximum blocksize, the miners can set their blocksize to whatever they find acceptable.  Nobody is forced to mine a larger block if they don't want to.

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[berrtus]

There must be some ambiguity or lack of clarity in my words because people keep advising me that the miners control block size.  I am not sure why because I am quite aware blocks can be smaller than the limit and never assumed otherwise.  I did not use the words 'blocksize limit' but only blocsize  because it is often referred to as the 'blocksize debate'.  Anyway I am talking about the blocksize 'limit'.  I am totally aware of the fact blocks are often smaller than the blocksize limit and nothing I have said assumes that there are not smaller blocks than the limit.  I admit I am not sure why a miner would put out a small block if the network was backlogged with transactions, but it is not really relevant at all to my reasoning. Please allow me to recap my reasoning:

The probability of guessing within a magnitude of 2 the correct block size limit requirement (assuming we need one at all)  tends to zero as the number of years out increases.  There are two possibilities:  If network growth exceeds the automatic increases in block size limit then the debate will be forced to continue perhaps on even less friendly terms than had we not put in automatic increases, because we will have to say they were not enough and then put in a hard fork anyway.  If network growth is less than our chosen numbers it means that there may or may not be possible unnecessary vulnerabilities created: though I agree those may be exaggerated. In either case we have achieved nothing, nor have we ended the debate or the uncertainty.  And note the probability of one of those cases holding tends to 1 quite quickly (within 3-5 years)  AND in either of the two possible ways that we will certainly err with the automatic increases we have effectively prevented the miners from adoptiong xt.  As was mentioned BTCC accounts for 14% of the hashing power, and they are not adopting xt because of the automatic increases in blocksize.  Now, I cannot promise they will switch to xt if we change that but it wouldn't hurt to ask.  So we see these automatic increases are achieving ONLY the continued delay in adopting bigger blocks.  I personally would advise something like an increase to 4mb immediately and another doubling scheduled in one year.  This is the best way to do it and it is also the way miners would like to see it done.

[Christophe Biocca]

OK, let's address your statements point by point:

> The probability of guessing within a magnitude of 2 the correct block size limit requirement (assuming we need one at all)  tends to zero as the number of years out increases.

You're assuming the "correct" limit (scare quotes because there's no such thing), needs to be guessed within a factor of 2. Why not 1024? Bitcoin's blocksize limit was more than 20 times "too big" until May 2012, and we only reached 50% utilization last May.

Hell, most of the small-block supporters claim we're not really at 50% utilization because most of the transactions are "spam" or non-economic in nature, so arguably we're not even within a factor of 2 right now! Is the limit too high then?

> There are two possibilities:  If network growth exceeds the automatic increases in block size limit then the debate will be forced to continue perhaps on even less friendly terms than had we not put in automatic increases, because we will have to say they were not enough and then put in a hard fork anyway.

If we have automatic increases that are insufficient, then better to have insufficient automatic increases that reduce the harm done while we roll out another hard-fork, rather than no automatic increases at all.

> If network growth is less than our chosen numbers it means that there may or may not be possible unnecessary vulnerabilities created: though I agree those may be exaggerated.

If you believe that can be caused by usage being lower than the cap, then bitcoin should have failed in the days the limit was at 20x the usage, or before we even put the block size limit in place. Under-usage only matters if you care about maxing out tx fees. Most of the vulnerabilities have to do with the ratio of actual block size to the bandwidth of nodes on the network. If block sizes stay at their current size even as the limit rises, then there's no amplified selfish mining attack, no full nodes dropping off the network, no problem with mining over Tor.

A situation where the limit rises but Bitcoin usage stays low is a good outcome from a small-block perspective.

> In either case we have achieved nothing, nor have we ended the debate or the uncertainty.

False. Allowing 10-20 years of growth before we have to revisit this problem is huge. Certainly much more time than could be bought by any one-off increase (we wouldn't get more than 8MB today).

> And note the probability of one of those cases holding tends to 1 quite quickly (within 3-5 years)  AND in either of the two possible ways that we will certainly err with the automatic increases we have effectively prevented the miners from adoptiong xt.

If automatic increases were the issue, and 8MB one-off would be popular, then BIP102 (2MB one-off) would also be popular with miners (hint: it isn't). Since we have evidence that existing one-off blocksize limit increase proposals aren't popular with miners, we can deduce that if BIP101 becoming a one-off blocksize limit increase would not magically make it more popular.

> As was mentioned BTCC accounts for 14% of the hashing power, and they are not adopting xt because of the automatic increases in blocksize.  Now, I cannot promise they will switch to xt if we change that but it wouldn't hurt to ask.

If you want to get BTCC on board, add miner voting on block size. That's definitely the feature they're supporting. Seriously, how you can look at massive miner support for BIP100 and infer from it that "automatic increases" is their issue with it, is a mystery to me.

And since, for many of us here BIP100 is an acceptable second choice, I'm not particularly keen on trying to siphon off its miner support at the cost of abandoning the simplicity (and sanity) of this proposal.

> So we see these automatic increases are achieving ONLY the continued delay in adopting bigger blocks.

As shown above, the "automatic" part ranks way below:

- The fact that there's a big one-time increase (It had to be revised down to 8MB from 20MB based on earlier miner feedback).
- The fact that it doesn't give miners a supply-cartel synchronization mechanism baked into the protocol.
-

> I personally would advise something like an increase to 4mb immediately and another doubling scheduled in one year.

So a more aggressive BIP102? Why would you actually expect that to gain steam?

> This is the best way to do it

Almost certainly false (if only because you strongly insist on the importance of getting the numbers right, yet don't try to justify yours at all).

> and it is also the way miners would like to see it done.

Definitely false. Miners either want BIP100 (potentially large increases and decreases driven by miner votes), or BIP101. There's no one else right now.

[berrtus]

Let me answer as many of your points as I can while providing a bit more evidence and trying to keep this on the larger picture.

>> The probability of guessing within a magnitude of 2 the correct block size limit requirement (assuming we need one at all)  tends to zero as the number of years out increases.

>You're assuming the "correct" limit (scare quotes because there's no such thing), needs to be guessed within a factor of 2. Why not 1024? Bitcoin's blocksize limit was more than 20 times "too big" until May 2012, and we only reached 50% utilization last May.

Your changing my meaning just a bit:  I am really saying guesses lose value as the differ by higher and higher magnitudes of 2.  I am aware a bad guess is no worse than leaving it the same which could also be wrong, Except our high guesses are doing lots of harm in another way as I will show again.  

>Hell, most of the small-block supporters claim we're not really at 50% utilization because most of the transactions are "spam" or non-economic in nature, so arguably we're not even within a factor of 2 right now! Is the limit too high then?

I did not say that either again your changing my meaning.  Right now I think it should be a bit higher due to the chance of a market bubble, but not more than 8mb for the moment.

>> There are two possibilities:  If network growth exceeds the automatic increases in block size limit then the debate will be forced to continue perhaps on even less friendly terms than had we not put in automatic increases, because we will have to say they were not enough and then put in a hard fork anyway.

>If we have automatic increases that are insufficient, then better to have insufficient automatic increases that reduce the harm done while we roll out another hard-fork, rather than no automatic increases at all.

Actually, I think automatic increases that are insufficient is a really negative case scenario, and don't feel this is the way to solve the problem.  Yes, that's just my view here.  It would be better to have either scheduled updates, or updates when we have other hard forks relying on automatic updates that may be insufficient is not the best way to go about this.

>> If network growth is less than our chosen numbers it means that there may or may not be possible unnecessary vulnerabilities created: though I agree those may be exaggerated.

>If you believe that can be caused by usage being lower than the cap, then bitcoin should have failed in the days the limit was at 20x the usage, or before we even put the block size limit in place. Under-usage only matters if you care about maxing out tx fees. Most of the vulnerabilities have to do with the ratio of actual block size to the bandwidth of nodes on the network. If block sizes stay at their current size even as the limit rises, then there's no amplified selfish mining attack, no full nodes dropping off the network, no problem with mining over Tor.  A situation where the limit rises but Bitcoin usage stays low is a good outcome from a small-block perspective.

You changed my meaning again.  I said possible unnecessary vulnerabilities but those may be exaggerated.  

>> In either case we have achieved nothing, nor have we ended the debate or the uncertainty.

>False. Allowing 10-20 years of growth before we have to revisit this problem is huge. Certainly much more time than could be bought by any one-off increase (we wouldn't get more than 8MB today).

I disagree that the problem will be put off 10-20 years, if anything is false, that certainly is.  More likely around 3 years so it would be best to not try guessing further out.  YES, I am aware a failed guess does no more harm than no guess at all (from the point of view of which number works best)  But a failed big guess is in fact preventing xt adoption and I would put some quotes later to back that up.

>> And note the probability of one of those cases holding tends to 1 quite quickly (within 3-5 years)  AND in either of the two possible ways that we will certainly err with the automatic increases we have effectively prevented the miners from adoptiong xt.

>If automatic increases were the issue, and 8MB one-off would be popular, then BIP102 (2MB one-off) would also be popular with miners (hint: it isn't). Since we have evidence that existing one-off blocksize limit increase proposals aren't popular with miners, we can deduce that if BIP101 becoming a one-off blocksize limit increase would not magically make it more popular.

I am going to put a couple of quotes below to refute your view about miners which I think is an oversimplification and not accurate.  

>> As was mentioned BTCC accounts for 14% of the hashing power, and they are not adopting xt because of the automatic increases in blocksize.  Now, I cannot promise they will switch to xt if we change that but it wouldn't hurt to ask.

>If you want to get BTCC on board, add miner voting on block size. That's definitely the feature they're supporting. Seriously, how you can look at massive miner support for BIP100 and infer from it that "automatic increases" is their issue with it, is a mystery to me.

And since, for many of us here BIP100 is an acceptable second choice, I'm not particularly keen on trying to siphon off its miner support at the cost of abandoning the simplicity (and sanity) of this proposal.

Because they are saying the future increases are excessive.  34% that I have found are saying this.

>> So we see these automatic increases are achieving ONLY the continued delay in adopting bigger blocks.

>As shown above, the "automatic" part ranks way below:

- The fact that there's a big one-time increase (It had to be revised down to 8MB from 20MB based on earlier miner feedback).
- The fact that it doesn't give miners a supply-cartel synchronization mechanism baked into the protocol.

I did not answer each point but left a few.  Let me begin by saying your view of the miners is oversimplified.  I also do not think they necessarily selfishly want to create a supply-cartel, though that motivation is not entirely ruled out.  I think the miners want a practical solution that works and they are willing to accept block size limit increases.  This is manifest from the quotes I have been reading.  But they are very concerned with the band width problem and they are definitely scared off by 8GB even if it is 20 years out.  In fact the biggest miner Wang Chun said exactly that and it is the reason he will not support xt.  Here a quote from Wang Chun, the operator of the China-based pool controlling some 20 percent of hashing power:

“We cannot predict what will happen years into the future, and we think a first step to 2 megabytes should be enough for now.”  “I think it is urgent, because the transaction volume is increasing on the blockchain, and if the price rises in near future, it will push the transaction volume to be even higher. I think the max block size should be raised as soon as possible, but it should not be raised too much. Two megabytes is preferred as the first step.”  Here he prefers two, but I believe anywhere 4mb initially would be acceptable for him, yes a bit of a guess based on reading his views.  So we see they at least Wang and others are quite willing to consider block size increases, but they definitely absolutely do not like 8GB. The same goes for Charlie and Bobbie Lee who represent another 14%, they absolutely do not like being locked into 8GB.  

Here is the quotes from Charlie and Bobby Lee:

Bobby Lee said: "My company BTCC actually came out publicly to support BIP100. The difference in the two proposals is very technical in nature. It has to do with how often the blocksize gets increased and whether human intervention is involved or whether it goes up automatically.

"I'm not too worried about which one eventually gets implemented. I have a firm belief our community will come together and implement the right solution that will us to grow and for Bitcoin to be more popular."

Charlie Lee added: "Some people do think that we need to play a lot more conservative. So increasing blocksize could potentially lead to a path of more centralisation and a lot of problems that could hurt the Bitcoin network. So it's better if you play it safe. So I am kind of in that camp. I think that if you increase the blocksize too much, too quickly, it could potentially destroy Bitcoin, with it becoming too centralised or the security suffering.”

Based on my reading I see the miners as willing to accept reasonable increases in block size.  They are absolutely not interested in 8GB that is putting them off.  Whether it is 'best' or not to have such an increase 20 years out it is in fact putting off the miners.  And they are willing to accept xt but for this reason.  They do not want to have to figure out the technical details themselves but think that the programmers should do that.  They are in fact practical and not necessarily interested in creating some supply cartel.  They do not have the extra money or resources to invest too much in this debate because there margins are already small.  They are miners.  Many say they will accept 2, 4, 8.  

Here is an important point: Believe it or not Gavin and Mike have a lot of support.  So maybe some other proposal for say 2 mb immediately may gain no support, but that should not be held to logically imply that if Gavin and Mike proposed it that it would not be.  I believe that in spite of the respect for Gavin Andresen and Mike Hearn miners are not willing to accept future increases that seem to aggressive to them.  I do think if Gavin and Mike Hearn had practical code ready say 4mb now and 8mb in a year that it would be likely accepted by the community.  My fear is that Blockstream Core will do something like 2-4-8 and they will have seized the initiative from us.  So that would be fine but they are totally mired in a conflict of interest scenario where they benefit only by hobbling, and bottle-necking the network.  So from my view it is high priority to take the initiative back from them.  The automatic updates too far out are preventing that.  I am sure I am correct on this be I of the ability to prove it here or not.  Please forgive editing errors doing my best here.

[Tom Zander]

On Sunday 06 Dec 2015 23:36:03 berrtus wrote:
> Let me answer as many of your points as I can while providing a bit more
> evidence and trying to keep this on the larger picture.

May I suggest we take this discussion to reddit? The /r/btc or
/r/bitcoin_uncensored subs seem like a good idea.
Or if you are daring, try /r/bitcoinxt

It just looks off-topic on this list. As we've seen all the arguments raised
here already a dozen times.

[Tom Harding]

On 12/4/2015 8:33 PM, berrtus wrote:
>
> This is because we think we have solved the network growth issues with
> automatic increases and therefore ended the debate, but that is all
> highly unlikely.

berrtus --

Your point is understood: the more uncertain the actual future growth
curve for block space, the less it makes sense to guess at it.

But should this project shadow-box itself? It would be madness to keep
"compromising" based on public speeches and forum posts in hopes of
finally offering something everybody liked. Gavin already adjusted his
solution once, in direct response to feedback from miners. 8MB was
their number. Yet the endless debate continues.

Let another solution be coded, deployed, tested and supported as widely
as BIP101, before BIP101 supporters compromise with it.

[berrtus]

I suppose somewhat in conclusion, I could offer my personal view that putting in automatic increases in the limits beyond three years out becomes counterproductive.  The reason is as you put better than I could: the more uncertain the actual future growth curve for block space, the less it makes sense to guess at it.   I cannot prove the number three but it is just a reasonable guess.  We are weighing numbers that sound too aggressive to the miners with decreasing benefits of guesses that are further and further out.  There will be other needed updates that may require possibly hard forks, and their will be other solutions that alter the nature of this problem.  At this point it is impossible to predict all the variables that will be involved while it is definitely reducing adoption of xt.  I want to see xt adopted because I see the Blockstream Core coders as acting out of a severe conflict of interest.  Additionally, I see a cultural divide between the Chinese miners and the coders.  I think they are totally willing to negotiate, they too want practical solutions.

[Mike Hearn]

The prediction curve in BIP 101 is arbitrary and not very important. In an ecosystem where miners and users felt free to adapt the system to a changing world, if BIP 101 turned out to be wrong in either direction, no problem, just schedule another hard fork and adjust it.

The only reason anyone cares about the growth curve in BIP 101 is this: some people have become convinced that either

1. Hard forks are difficult to trigger or
2. Hard forks should be difficult to trigger.

Bitcoin Core and Blockstream in particular pushes both views very strongly, but it's vital to realise that this is a purely political discussion that has nothing to do with the actual technology.

It is political because at its core, a dislike of hard forks represents something far deeper - it represents a dislike of democracy itself. This came through very strongly when I talked to the miners some time ago and you can see it play out in the arguments of Core developers/their supporters on reddit and elsewhere.

Signs you're dealing with someone who doesn't trust democracy include arguments like these:

• If we can hard fork to change the block size limit, there might be a hard fork to change the 21 million limit. Anything could happen!
• We shouldn't hard fork unless everyone agrees (phrased another way, the speaker believes they should have a personal veto that overrides even 99% support from other people)
• Hard forks are bad but soft forks are good
• Bitcoin is meant to be immutable no matter how many people agree it should be changed, and that immutability it's most important value
• Bitcoin is meant to be a digital equivalent to gold
• It's important that protocol decisions are made by intellectuals and not by "The Mob". We want there to be a single group of experts who tell us what to do.

People with the opposing views would make arguments like these:

• There's no connection between the Bitcoin monetary policy and block sizes. The 21 million limit isn't protected by requiring a dozen developer conferences to change it, it's protected by the fact that it's in the users own interests to keep it.
• A system in which any single person can veto a change no matter how strongly supported it is, is dysfunctional and non-workable.
• There is little technical difference between hard and soft forks. Without any ideology involved, hard forks may well be preferable for technical reasons.
• Money is a social construct that only has meaning because other people accept it. To try and create immutable money that can't be changed even if everyone wants it to is a nonsensical goal that fundamentally misunderstands the very nature of money itself.
• Gold is not independent of social decision making, as the general decline and abolition of the gold standard itself shows. Nor is gold especially predictable, as the Conquistador-triggered European hyperinflations showed. So to claim Bitcoin should be hard to change to make it "like gold" is just a restatement of the previous point.
• There are no "intellectuals" and "the mob" is much better described as "the user base" or even "the customers". Expertise is easy to claim and difficult to verify, so is best judged by a market. To hold the userbase in disdain is to fundamentally disagree with the basic assumption of decentralisation itself - that power is best distributed over the people whom it affects, because that's how the best decisions are made.

Unfortunately as these opposing views views are based in very deep rooted assumptions about the nature of politics and human interaction, changing them seems very difficult (though not impossible). But I don't forsee the guys involved with Bitcoin Core or Blockstream ever concluding that the wider userbase might know better than they do, for instance. It just runs counter to everything they seem to believe in.

[berrtus]

Actually,  I feel the same way about all those issues, but am coming to an opposite conclusion about future automatic increases in block size limits.  The acceptability of hard forks and acceptance of the democratic process seems to support scheduling a block size update in two or three years.    Why can't we subject ourselves to the democratic process and do another scheduled hard fork in two or three years?  I am familiar with the arguments that it doesn't matter if we guess too high, or a guess is better than no guess, but I see little value in that (mostly because it is outweighed by the negative perception it is creating with miners.  When they hear 8GB blocks it's over, maybe we can explain it to them, but some have already taken a position that they won't likely change)

[Gavin Andresen]

On Tue, Dec 8, 2015 at 10:13 AM, berrtus <ber...@gmail.com> wrote:

When they hear 8GB blocks it's over, maybe we can explain it to them, but some have already taken a position that they won't likely change)

Where are you hearing this?  Are you a miner?

The mining panel in Hong Kong the miners said they'd go with developer consensus, they don't have, and don't want to have, an opinion on stuff like this.

Bitfury being the exception....

--

--
Gavin Andresen

[berrtus]

I am not a miner.  Wang Chun, and Bobby and Charlie Lee represent 34% of the hashing power.  Wang said he was directly put off by the 8Gb blocks and Charlie and Bobby have differing views but both think xt is too aggressive going forward (they are clearly talking about future increases in blocksize)  The quotes are above.  .  Charlie and Bobby might still accept xt, but Wang won't without a change in the automatic increases.  That's pretty much all in the quotes above.  I can find the links to the articles.  Yes, I saw where they said they don't want to be figuring out the technical details, but they will be choosing Core or xt and the future increases in block sizes is a BIG DEAL for them.  We may be right that they should not be concerned, but if they have taken a view they won't be changing it easily if at all. 

[Mike Hearn]

You have to separate different things.

When I talked to the miners, I heard three things:

1. We have $RANDOM_ISSUE with BIP101, or, we don't and BIP101 would be fine

2. We will consider voting for BIP101 after December if there is no progress

3. However, we will not run anything except Bitcoin Core

The last requirement makes any change to BIP101 irrelevant because Maxwell will not accept any block size increase in Core (and it's basically Maxwell who runs that project now). Thus changing BIP101 to try and satisfy whatever their latest wishlist is would be pointless.

It also makes Bitcoin itself largely pointless, as it makes the system no different to PayPal or any other proprietary financial network. But even when I pointed this out and they accepted that was true, the miners still had huge mental difficulty with the whole idea that they should have opinions and exercise them through voting.

--

[Tom]

On Tuesday 08 Dec 2015 07:13:54 berrtus wrote:
> The acceptability of hard forks and acceptance of the democratic process
> seems to support scheduling a block size update in two or three years.
> Why can't we subject ourselves to the democratic process and do another
> scheduled hard fork in two or three years?

Because thats not how democracy works.

What people seem to misundersand from the BIP101 suggestion is that its not
infinite growth, or anything like big growth at all.

BIP 101 is basically standing still just having the normal, expected,
"inflation" of faster machines applied to it.

In my country we had for many years a law that says you can get a "home-PC",
tax free. The law didn't specify the speed of the machine as a limit (so
people don't end up abusing the law), they specified the machine must be low-
entry market.

Similar with having home-internet paid for by your boss (I work in IT, its a
perk to allow me to work from home). Its limited in cost and market valuation
and therefore a tax-free benefit.

The point I'm trying to make here is that when people look at BIP101 they seem
to only look at the number of bytes in a block.

Thats like showing a person from 1995 that the blockchain is 50GB. Its totally
distorted by the growth of the field.

In reality you can run the blockchain on a €100 machine with a €50/month
internet. Some places cheaper, some places more expensive. Some places you
can't at all. The medium is not too far off, though.

If you apply BIP101 and fast-forward 10 years, or 20. The same prices will
still apply. You can still run the blockchain on a €100 machine. You can still
run it on a €50/month internet connection.
And, yes, I've had an internet 20 years back. The numbers are actually
accurate.


The end result is that people saying the "automatic increases" of BIP101
bother them don't understand that, really, there are no increases. It doesn't
grow.
There is no reason to buy more and more expensive hardware to keep up.

This is the reason why people call BIP101 the bringing of stability and
predictability.
--
Tom Zander

[Tom]

On Tuesday 08 Dec 2015 18:11:17 Mike Hearn wrote:
> 3. However, we will not run anything except Bitcoin Core

[snip]

> It also makes Bitcoin itself largely pointless, as it makes the system no
> different to PayPal or any other proprietary financial network. But even

> when I pointed this out *and they accepted that was true*, the miners still

> had huge mental difficulty with the whole idea that they should have
> opinions and exercise them through voting.

I belief this is a marketing issue.

Remember companies supporting only internet explorer? Because, well, it was
from MS.
Before that it was IBM.

The market shifts, and the main way to do this is by having mature
alternatives that understand the customer better.

In my ideal world we have an alternative implementation of bitcoind that is
actually written from scratch (no recovery needed from past design decisions)
and can support validating nodes and miners.

Maxwell is quite smart and good at marketing of his point of view. The whole
"consensus" library is a good example of how he spins the idea that there is
no way any alternative solution could be created.
The whole "lets use sqlite" thread about the unspent DB is another example. It
can only lead to worse performance. But to suggest that it would be better
than levelDB is selling the uninformed user a lot of spin.


But the bottom line is that bitcoind is really a bad design in the context of
a mining shop. There are so many system designs that you could do different if
you don't limit yourself to a single CPU machine.

So the ideal world we get a reimplementation of bitcoind. Using some database
that is spread over multiple machines maybe.

The miners may really like that an open market would create better results.

This story of open innovation needs to be marketed. People, like miners,
should be told in so many words that if they depend on one core implementation
that they are shooting themselves in the foot.

Just like people no longer use internet explorer, or get hardware from IBM.

[berrtus]

I think I understand this argument about Moore's Law and simply assuming increases.  I don't think the miners do because they have to pay the bills and when they see 8GB blocks that's the end of the debate.  But rather than over-arguing I would like to wait possibly for more evidence to support my position.  

[berrtus]

berrtus (me)

>"When they hear 8GB blocks it's over, maybe we can explain it to them, but some have already taken a position that they won't likely change"

Gavin Andresen 

>"The mining panel in Hong Kong the miners said they'd go with developer consensus, they don't have, and don't want to have, an opinion on stuff like this."

Gavin Andresen 
>Andresen: They want 8MB as a cap, and then no change. No increase over time.

http://motherboard.vice.com/read/the-two-guys-at-the-heart-of-bitcoins-crisis?trk_source=recommended

From the same link: Mike Hearn:

>Hearn: It seems like a no-brainer assumption that technology will continue to improve, and even that basic thing people can’t seem to agree on, which is why an insistence on unanimity is ridiculous. You’ll get people who don’t share incredibly basic assumptions like: things might get better in the future.

It appears Gavin is KEENLY aware that the miners do not like the future automatic increases.  

Anyway we can now state as a conclusion:  The miners do not like the future automatic increases in block size.  And anyone who says that future increases in block size is not an issue with the miners will have to refute Mike and Gavin's historical account of it.  To Mike I would say: The miners are in China.  Are you familiar with the internet there?  It is exceedingly slow, unpredictable, and unreliable, when I was there I had a 3kb/s connection.  Maybe it has improved, but this is not just a technological issue.  Internet speed in China is way more complicated than just being a technical issue.  In fact I would say this: Dependency on excessive internet speed is actually a vulnerability.  Anyway, I am just trying to show you that the miners view is not necessarily totally irrational.  They are the ones that would know about bandwidth in their own country.  So again I say:  future increases in block size limits are putting off the miners.  That much is a fact as Gavin attests.  So then because we get very limited value from guesses 10 years out it's best not to do that, unless we never want to see xt adopted anyway.

[Tom Zander]

On Wednesday 09 Dec 2015 04:56:24 berrtus wrote:
> Anyway, I am just trying to
> show you that the miners view is not necessarily totally irrational. They
> are the ones that would know about bandwidth in their own country.

Mining is something that currently people do to take advantage of local
circumstances. For example mining in a hot country means you air-conditioning
costs go up.

This is showing the reality of shifting business requirements. It happens
everywhere. Its natural and expected.
Naturally we see that businesses that have a good profit now will want to see
it continue. We have to be careful to avoid this going against the benefits of
the rest of the system, though.

If a miner insists on having his bitcoind run on a connection that is much
slower than it is elsewhere, we can't just decide that Bitcoin will just not
ever grow beyond the 500000 people that are interested in it now. Just so
that miner will keep his business going.
It would be lying to him, because in this scenario he'd go bankrupt in a year
time anyway because the value of the coin would collapse.

> So again I say: future increases in block size limits are putting off the
> miners.

Since you seem to talk with the miners, please explain to them the reality of
the situation.

[Ivan Brightly]

On Wed, Dec 9, 2015 at 7:56 AM, berrtus <ber...@gmail.com> wrote:

berrtus (me)

<snip>

It appears Gavin is KEENLY aware that the miners do not like the future automatic increases.  

Anyway we can now state as a conclusion:  The miners do not like the future automatic increases in block size.  And anyone who says that future increases in block size is not an issue with the miners will have to refute Mike and Gavin's historical account of it.  To Mike I would say: The miners are in China.  Are you familiar with the internet there?  It is exceedingly slow, unpredictable, and unreliable, when I was there I had a 3kb/s connection.  Maybe it has improved, but this is not just a technological issue.  Internet speed in China is way more complicated than just being a technical issue.  In fact I would say this: Dependency on excessive internet speed is actually a vulnerability.  Anyway, I am just trying to show you that the miners view is not necessarily totally irrational.  They are the ones that would know about bandwidth in their own country.  So again I say:  future increases in block size limits are putting off the miners.  That much is a fact as Gavin attests.  So then because we get very limited value from guesses 10 years out it's best not to do that, unless we never want to see xt adopted anyway.

Making decisions based on a single criteria in a single geographic region should not be the mechanism. The fact that network connectivity is more problematic in China is relevant but it should not influence the decision process anymore than the relatively high cost of electricity in the EU should.

IMO, the biggest issue facing Bitcoin at this time is the lack of agreement on the ability to actually make changes via a hard fork. Without a willingness to make changes that might entail some risk, people will ultimately become disinterested in Bitcoin and move elsewhere - either to centralized solutions or to altcoins. It's either that or the miners get to keep their veto over changes that aren't directly in their best interest.

[berrtus]

>Making decisions based on a single criteria in a single geographic region should not be the mechanism.

But it is the mechanism:  Adoption of xt depends on the percentage of xt blocks mined, and that depends on miners (in a certain geographical region) adopting xt and almost all the mining is done in China.  So either the Chinese start using xt or xt is not EVER adopted.  

[berrtus]

"BTCC COO Samson Mow: Without Consensus on Block-size Limit, Stakeholders Might Implement an Increase"
https://bitcoinmagazine.com/articles/btcc-coo-samson-mow-without-consensus-on-block-size-limit-stakeholders-might-implement-an-increase-1449712869

Furthermore: “BTCC will not support BIP 101. It’s simply far too risky to have automatic scaling in the manner proposed,” Mow said. “BIP 101 presumes that its formula for increasing block size is the right one for the next 20 years, which is either incredibly arrogant or incredibly reckless. For me, the key take-away from the talks at Scaling Bitcoin in Montreal is that we really don’t know how the network will perform with larger blocks.”

This is exactly what I have been saying.  And proves yet again that the miners do have an opinion about the future blocksize increases, and I would say, IMO their view is not unreasonable.  So we either want xt adopted or it is just some irrelevant side game.   So time to put in  '2-4-8' immediately no complaining!  :)  Get to work boys.

[Mike Hearn]

Again - Samson's view makes no sense because he is assuming "hard forks" are hard. I actually have come to hate that terminology (I certainly did not invent it) because it's so misleading.

In a world in which the community feels free to execute hard forks whenever necessary, after some forward planning, setting up a BIP101 style formula is merely a convenience intended to reduce the likelyhood of needing one. But if it turns out that formula is wrong, OK, make a new BIP, and fork again.

I actually talked to Samson a few months ago. He couldn't grasp the idea that the system was changeable. The fact that Samson can't see any explanation for BIP101 beyond arrogance/recklessness says a lot about his worldview - he thinks BIP101 would be forever, even though if it happened, that would be proof that it wasn't!

[Robert B]

If they are changeable why can't we put in his preferred future blocksize limit?  Could he not say: "It's changeable why don't you adopt my view?"  If not his then the miners consensus of what it should be?  Or even an average of the entire communities consensus?  I would guess you might guess better than him, but that doesn't mean he would see it that way.  

I am a teacher I can do all sorts of logical things that leave the students in a state of total disorder.  I could say it's their problem, but I take responsibility for the outcome.  If the outcome is xt does not get adopted we have to take responsibility for that too.  What I am saying is: Even if you're right and Samson has a difficulty understanding best guesses, we have some responsibility to deal with the community effectively.  Back to my main point these future guesses are really not worth much, because there will be future hard forks anyway, but they are basically costing the adoption of xt.  It is a necessary condition for the adoption of xt that these future guesses above 8mb be dropped for now.  That may not be provable mathematically but I highly doubt xt adoption is going anywhere unless these future guesses too far out are scrapped for now, and there is a lot of evidence for that view.  

--
You received this message because you are subscribed to a topic in the Google Groups "bitcoin-xt" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoin-xt/b05mPLx1HWg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoin-xt+...@googlegroups.com.

[Mike Hearn]

If they are changeable why can't we put in his preferred future blocksize limit?  Could he not say: "It's changeable why don't you adopt my view?"

Yes, but

1. We can say the same thing: it's changeable, so why don't you adopt our view? 

2. Changing the code would mean a new BIP, new code, new testing, etc. For what? The difference between 4mb and 8mb as an upper limit is not that large.

3. They have no consistency. Different pools say different things.

4. The Chinese miners have made it very clear at Hong Kong that they won't consider running anything except Core. In fact their view is that they shouldn't have to think or have opinions on how Bitcoin works.

Reflect for a moment upon the last point, and what that means.

[Robert B]

(2) >The difference between 4mb and 8mb as an upper limit is not that large.

Their problem is not really 4mb or 8mb.  I think they could accept anything in the range of 4-8mb, 2-4-8 might be popular.  If we get a bubble soon 4-8 might be better.  Their concern is coming in on the automatic increases above 8mb.  They like 8mb it is lucky and in this situation looking not too far forward reasonable.

Their view on all this may not be totally irrational.  If bandwidth for them is slow they could find themselves effectively locked out.  They might have to make their own hard fork in that situation and for all they know it might not go well.  Why should they accept that as a default?  They want to wait and see and don't like being locked in.  It seems a reasonable business sense.

>3. They have no consistency. Different pools say different things.

It is near unanimity on not liking the auto increases above 8mb certainly above 50%.

>4. The Chinese miners have made it very clear at Hong Kong that they won't consider running anything except Core. In fact their view is that they shouldn't have to think or have opinions on how Bitcoin works.

They have said they will make their own version if Blockstream Core or xt can't get it together so I think they are totally willing to change from Core, and just wait if Core refuses on block size increases it's over for them, and miners will be coming to xt.  Additionally, if Core keeps doing strange stuff like RBF they will lose credibility also.

Here is how it could play out:

Assuming Core does not increase block sizes or does other stupid stuff like RBF

Case 1: If xt goes 2-4-8 Miners will be coming to xt.  

Case 2: If xt goes 8-16-32...8GB Miners will be making their own hard fork.  That is what the article is saying. "Mow believes the Bitcoin industry might opt to raise Bitcoin's block-size limit even if no consensus is found among the Bitcoin Core development community." 

--

[Christophe Biocca]

Looking at this discussion and the steps leading to it I'm reminded of
the efforts to make playgrounds safe:

100: Remove the most dangerous installation.
200: GOTO 100

BIP101 has already been revised once, down from 20MB as the new starting limit.
Now it's the automatic increases that are "the" issue.
Once we have 2-4-8, getting to 8 in 3 years will be to aggressive.
Then when it's 2-4-8 with 2 years between each step, 8 will have to go
because who can see 6 years in the future?
Then 2-4 should instead be as single 3MB bump to reduce uncertainty,
then that's so similar to BIP102, why don't we do that instead?
And finally, doing a hard fork for just that small of a gain is not
worth the risk, so let's go implement extension blocks, which can be
done as a soft-fork.

Given that there's always going to be someone at the margin saying
they'd be on board with a more moderate proposal, you have to draw the
line somewhere. Given that a flat 8MB is, in my opinion, worse than
BIP100 (which has a hard cap of 32MB, miner cartel shenanigans
notwithstanding), the benefit just isn't there.

[Robert B]

Just so people won't think I am advising something absurdly small I think 4mb now and 8mb in one or two years time would be reasonable.  I think it's the auto increases that are perceived as going too high is where the problem is coming in.  So if we scale those back we won't lose anything initially.  Don't forget we are getting near a doubling with Segregated Witness (from what I understand), and what about thin blocks?  

[berrtus]

Can we get to thin blocks in two years time?  Would that reduce 1MB to 70KB?  If so would that not solve the scaling issue going forward for sometime?  By my calculation 8MB thin blocks would hold 114 times the data 1MB holds today  With Segregated Witness it would be nearly double that.  There are also some spam unnecessary transactions going on.  All while the market IS willing to accept an immediate increase. So it seems we could have our cake and eat it too.

There is a lot that can be achieve incrementally that is not achieved by advance.  The real key is getting people on board.  That will be done by consistently offering a practical alternative to Core.  I am arguing for a bit of strategy.  Strategy is not the same as just developing your system logically.  We have another side in this supposed 'debate' Core. Strategically it is best to be one tiny increment in the direction that represents an improvement over Core, any more than that and you start losing supporters in the middle.  For example, all miners might support an increase, yet none might support 8GB.  We could bring all of them over with a small improvement and none of them with 8GB.  Strategically we should get as many on board as possible while at the same time achieving our objectives, and that is all possible.

[Mike Hearn]

Thin blocks doesn't change the block size limit, it just changes how the data is relayed on the network. A 1mb block remains 1mb for the purposes of the calculation.

The scaling solution - the only scaling solution that isn't totally insane - is to raise the limit and keep raising it so the network always has plenty of capacity.

I realise you are searching for a political solution. If you wish to code up and test a different proposal to BIP 101, fork Core, rebrand it, then build and distribute it, you are welcome to do so.

[berrtus]

Well forking off may be the only logical option as it is insane to put forth a proposal that 80% of the hash power will reasonably outright refuse when it is totally unnecessary to do so.  I mentioned political so can't complain if you apply the term, but would say it really has to do with making software suitable for users which can be done without ultimately sacrificing on reasonable block sizes.  In fact it increases the chances we would finally get the correct block sizes while putting forth a proposal certain to fail decreases the chances.  Remember the miners are demanding reasonable block sizes too and may fork Core if Core refuses.  Anyway I will consider forking off :) as the infinitesimal chance of that success is higher than the chance of 8GB blocks succeeding any time soon.  But I will also argue for a bit of truth here: 1.  The miners are in fact put off by the future increases in block size.  2.  The miners will in fact consider code other than Core.  and 3.  The future increases (now) are of little value all they do is put of the miners.  Thanks for considering my arguments.    

[Tom Harding]

On 12/10/2015 11:07 PM, berrtus wrote:
> With Segregated Witness it would be nearly double that.

The only "scaling benefit" of segregated witness is that signatures can
cease to be relayed to light wallets. That's pretty dubious, given that
we're constantly told that SPV wallets as currently implemented are
insecure.

We should be going the other way -- network nodes should start providing
input detail and merkle branches to light wallets, and the wallets
should start checking for spentness with other peers and doing other
checks -- such as verifying signatures.

Nothing against fixing malleability, etc. It just doesn't address the
critical scaling bottleneck at all. As the long-promised "Hong Kong
scaling plan" it scores a big fat zero. Improving historical
prunability and better support for the untested and qualitatively
different lightning network do not constitute an actual scaling plan.

[G. Andrew Stone]

On Thursday, December 10, 2015 at 11:12:35 AM UTC-5, Mike Hearn wrote:

If they are changeable why can't we put in his preferred future blocksize limit?  Could he not say: "It's changeable why don't you adopt my view?"

Yes, but

1. We can say the same thing: it's changeable, so why don't you adopt our view? 

2. Changing the code would mean a new BIP, new code, new testing, etc. For what? The difference between 4mb and 8mb as an upper limit is not that large.

I think that its very important to make people realize that 2-4-8 is really 2-4-8-8-8-8-8.... in other words Bitcoin growth will halt in a few years.

Once they realize that we may be able to introduce the idea that BIP101 imagines continued growth but that if that growth doesn't happen, the actual block size will be lower even if the limit continues to increase.
 

4. The Chinese miners have made it very clear at Hong Kong that they won't consider running anything except Core. In fact their view is that they shouldn't have to think or have opinions on how Bitcoin works.

Reflect for a moment upon the last point, and what that means.

I'm not surprised that a group of people who are unused to democracy or other forms of self-government just want this problem to magically be solved for them.

I think that it means that people who DO care need to start mining.  Or a startup (or group of them) could purchase the decision-making of a Chinese pool from that pool.  For example you could purchase the ability to change the Coinbase text and the version field, or even the client run so long as your changes do not cause this miner to deviate from the mining majority because that would cause him to lose his coinbase reward.  While activation percentages are really nice for creating gentle transitions, the ultimate arbiter here is what 51%+ of the miners are doing.

But you also have to consider that these miners are being politic.  Their assessment could be that a 1MB block limit is much safer.  If Bitcoin gets co-opted into an exclusive settlement layer whose on and off-ramps are regulated, they could imagine that it will be much less likely to be banned. 

I think that this could not be more wrong.  My personal opinion of this is that once use of the blockchain is made exclusive,  it will be transformed in such a way that early adopters, miners, etc get left out.  For example, arguments like "how can we trust a bunch of <insert nationality here> miners?  Instead we should allow each member country to submit a block in order.  First Argentina, then Brazil, then China, etc alphabetically.  And if we do that, we don't need mining; each country can just sign the block with a private key. This lets us reduce the block generation time and saves a tremendous amount of electricity so we can even green-wash the proposal into acceptance!"

 
 

 

[berrtus]

>I think that its very important to make people realize that 2-4-8 is really 2-4-8-8-8-8-8.... in other words Bitcoin growth will halt in a few years.

Here is the reality: currently we are proposing 8-16-32...8GB but in this scenario with near 100% chance (really) we, as in xt, won't ever get anything.  We will get: 1-1-1... or whatever Core gives us, or what the miners decide.

If we propose 4-8 we will have some reasonable chance of getting it.  Then it's not correct to assume it goes 4-8-8-8... because we will then propose another hard fork, but realize if people are running our code that won't be so impossible.  All it means is that, at this time, we are not dictatorially imposing our solution for all perpetuity.  Can you see how that puts some off?  Furthermore, 8-16-32...8GB is not necessarily that either it could be 8-16-8-8-8-... Why?  because Core would then come to love hard forks, while now they do not like them.  They would put in a hard fork for some pretext and limit block size based on some other pretext.  The point is we cannot predict the future so far out for so many reasons.

>4. The Chinese miners have made it very clear at Hong Kong that they won't consider running anything except Core. In fact their view is that they shouldn't have to think or have opinions on how Bitcoin works.

Reflect for a moment upon the last point, and what that means.

>I'm not surprised that a group of people who are unused to democracy or other forms of self-government just want this problem to magically be solved for them.

Sorry but all this is simply false and I have provided the links that prove that.  It is not true that the miners will run only Core.  They have said if Core will not increase block sizes they will do it themselves.  I provided the quote and the link please read it.  It is also not true as has been claimed that the miners do not have an opinion about this.  I have links to direct quotes from the top 34% of miners that do have an opinion on it, and they do not like the increases too far out that they perceive as too aggressive.  Finally, it is not true that the miners are some group of simple minded, ill reasoned, undemocratic ...fill in the blank...  That is not fair.  Their reasoning makes sense and should be considered.  They have small bandwidth and don't want to get locked into mega blocks down the road.  That would end their game (possibly)  They have a right to participate why not?  There is no reason for them to accept this.  I doubt anyone here would if they were a miner in China.  Right now it takes what 2 weeks to download the block chain.  Internet speed may not increase for them according to Moore's law or whatever.  

I have sort of made my arguments and wanting to stand back, but if people say 1.  The miners don't have an opinion on block size, or 2.  The miners will only run Core.  or 3.  Their position is somehow mentally defective.  Then I will intervene.  

Thanks, 

[Tom]

On Friday 11 Dec 2015 05:20:27 berrtus wrote:
> Anyway I

> will consider forking off as the infinitesimal chance of that success is

> higher than the chance of 8GB blocks succeeding any time soon.

Agreed, lucky that the 8GB is still 20 years in the future. Nobody is
suggesting a fork to a max block size of 8GB in anything less than 20 years
yet.

[Tom]

On Saturday 12 Dec 2015 07:21:05 G. Andrew Stone wrote:
> I think that its very important to make people realize that 2-4-8 is really
> 2-4-8-8-8-8-8.... in other words Bitcoin growth will halt in a few years.
>
> Once they realize that we may be able to introduce the idea that BIP101
> imagines continued growth but that if that growth doesn't happen, the
> actual block size will be lower even if the limit continues to increase.

I would put it in a graph where the rest of the computing world keeps growing,
where the amount of users keep growing.

This will show its not a stop of growth, its a shrinkage.

[Cypher Doc]

oh c'mon.

Sam Cole flat out said miners are free to construct whatever block sizes they want.  that's why he said they are filtering spam and not accepting 0 fee tx's.  that, by definition, is controlling blocksize.  none of the scaling targets even presume for a moment that's where block sizes will be once kicked in.  they are just ceilings.

it's really simple.

On Friday, December 4, 2015 at 7:29:31 AM UTC-8, berrtus wrote:

I think locking in future block size increases is a mistake.  I would not post here and instead just Reddit, but I feel xt may go nowhere unless the future block size increases are taken out of the code.  I know this sounds radical, but part of my reasoning really shows my idea is not any more limited than the automatic increases are anyway.  Let me explain.  Firstly, there is a mistake in the assumption that we can predict future network growth.  Let n be the number of years forward.  I think future network growth is somewhere between 2^(n +1) and 2^(-n) as time goes forward.  It looks like future increases of every other year leave us at 2^(n/2) as our guess.  That leaves us with a max possible error of 2^(1.5n) so if we are six years forward we could be off by a factor of 2^9 a big amount.  This basically leaves the odds that the automatic increases are correct or even within a power of 2 as best approximated by zero.  Now, I am aware that the automatic increases may prevent a hard fork if they happen to be correct, but they won't be.  I am also aware they do no harm compared to not putting them in because not putting in the automatic increases in block size is also an assumption.  Except, and this is very important:  

Miners perceive xt as too aggressive, and mostly because of the future block size increases that will have to certainly be revised anyway.  

In fact more than 50% of the mining power, at least, has that viewpoint.  Read more here:  https://www.reddit.com/r/rBitcoin/comments/3vadqm/charlie_lee_creator_of_litecoin_and_bobby_lee_ceo/

So while the guess as to the correct blocksize will surely be wrong by more than a power of 2, and hence in reality useless, it is completely preventing the adoption of xt by miners.

  

Final point: We for a fact are going to need hard forks anyway to implement things like thinner blocks and other possible updates.  Hard coding in future increases is just putting people off and is not solving anything.  I propose an initial one time increase to 2mb or 4mb blocks.  Four is more reasonable, but let the miners decide what they want.  We need to take the initiative back from Blockstream Core and solve this.  We can't try to solve it for all time in the future as that won't work anyway.  In fact the automatic guess is not useful and is putting people off.    Additionally, a complete solution may come from something like dynamically sized blocks.  The best way to proceed is to make a bullet proof and error proof code and get it ready NOW, not several months out.  We should for sure take out RBF, and implement a ONE TIME reasonable block size increase.  To summarize my three main points: 

1. The probability of guessing ideal block size to within a power of 2 tends to zero as n the number of years out increases, and it tends to near zero quite quickly.

2. Miners and others think or perceive xt as too aggressive:https://www.reddit.com/r/rBitcoin/comments/3vadqm/charlie_lee_creator_of_litecoin_and_bobby_lee_ceo/ and we are needlessly creating this problem with code that did not solve the future scaling issue anyway.

3. Most likely we will need other hard forks anyway for obvious reasons like thinner blocks, and other improvements in the works.  We can increase blocksize again then.  Yes, it may have to be debated yet again, but automatic increases won't solve that problem either.  And we may solve the issues in other ways such as thin blocks.  

[Robert B]

I am aware of these things, already mentioned some of them.  We know blocks are made by miners, that they can leave out transactions, and that the size is not necessarily the same as the limit.  Presumably it is a fee market, so miners would have an incentive to fill blocks.  Anyway they won't, will not, are not going to, accept future increases that they think are too aggressive.  I don't believe anyone can convince them to.  We can put together a list of simplifying arguments for them, but if its conceivably really ever 8GB blocks they wont do it - meaning they are not accepting it now.  Even if its 20 years out.  Also to be clear it is possible, if the limit is 8GB for 8GB blocks to exist, and then even if you as a miner don't make blocks so big you would still have to download them.     

--