Not Bitcoin XT

[kano]

Power lies with those who control the market, dictate the rules, charge the fees, and establish the infrastructure.

What I like about Bitcoin is that the distributed system of consensus pretty much eliminates the possibility to gain unfair advantages, unlike most other markets. Even core changes to the system abide by blockchain rules of consensus client wise.

As soon as we move this control away from the system itself, back in the hands of people, no matter how good the intentions are it will be corrupted like any other market. To me, the core idea is to rely on math rather than people, in a fair automated system.

Yep that's what will happen.
BIP100 is now 60% ... and hopefully 80% soon.
(XT BIP101 is still the same less than 1% it got from slush and only slush)
https://www.blocktrail.com/BTC/pools?resolution=24h

That's great and all, but my understanding is that that proposal isn't even fully fleshed out, and definitely not coded yet:

https://bitcoinmagazine.com/21747/closer-look-bip100-block-size-proposal-bitcoin-miners-rallying-behind/

How long will it take to gain consensus on even just how it's supposed to work? And, it only is supposed to go up to 32MB, so, using the small block proponents' own argument against you, will we not require yet another hard fork in the future once we approach 32MB?

Bitcoin doesn't support greater than 32MB.
Once any suggestion hits the 32MB limit in the future, a hard fork will be required to go beyond it.

BIP101 is a centrally controlled, knee-jerk reaction to spam attacks created to push an agenda, with a low consensus that wont even happen.
75% ... and it's still less than 1% and has been that since it's voting inception.

If Bitmain switches over to BIP100 it will have 80% ... so I guess some people will then come up with some other criteria, different to it's current consensus specification, for accepting BIP101 that has effectively already failed, since they want it no matter what consensus they get.

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.

[mmortal03]

Bitcoin doesn't support greater than 32MB.
Once any suggestion hits the 32MB limit in the future, a hard fork will be required to go beyond it.

So, based on this, your perspective is that none of the proposals are any good, until they can handle going over 32MB?

BIP101 is

a centrally controlled

No, you've just been comfortable with the past circumstances where the Core developers happened to all agree with regards to the changes to the code, within the context of *their* own central control. We were *always* going to reach a point where *their* central control failed, due to some important enough disagreement.

knee-jerk reaction to spam attacks

Gavin and Mike were talking about this issue long before the spam attacks.

created to push an agenda

Dramatic language here. The small block supporters can just as well be said to have an "agenda" to push, by continuing to distract with various arguments such that the status quo is maintained, and *nothing* gets done.

with a low consensus that wont even happen

Even if it doesn't happen, it's moved the discussion forward, and motivated some individuals to actually produce various alternatives (though we *still* don't have actual code).

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.

It also adds unnecessary complexity to the matter that inevitably will require further analysis to be done, instead of -- if 32MB is really the sticking point -- just doing a straight forward, algorithmic increase of some kind up to 32MB.

[canth]

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.

1) The focus on 32MB seems arbitrary and silly. XT (for example) has the 32MB limit removed - there's no reason core couldn't remove it at the same time as a block size hard fork.
2) More importantly, would you say that Bitcoin mining is suitably decentralized today? Last I checked 4 pools control 62% of bitcoin hashrate. I would not think that turning over block size limits to perhaps 2 companies which may not have overall community best interest in mind is a decentralization play.

It's going to take miners, users and industry to move forward - anything else won't work no matter what any particular group pushes for.

[kano]

...
It also adds unnecessary complexity to the matter that inevitably will require further analysis to be done, instead of -- if 32MB is really the sticking point -- just doing a straight forward, algorithmic increase of some kind up to 32MB.

Decided by which central authority would you happen to like that to be?

The BIP101 has already failed to get it's votes ... it's still under 1%
But you want everyone to be happy with the BIP101's choice about how blocks size should be controlled ...

Do you not see the whole problem with that statement?!?

BIP100 is already above 60%
https://www.blocktrail.com/BTC/pools?resolution=24h

[kano]

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.

Blah blah blah

Translated:
Damn, we lost the vote by a land slide, OK now how else can we come up with some DIFFERENT criteria vs the one WE HAD, to make us win ...

[canth]

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.

Blah blah blah

Translated:
Damn, we lost the vote by a land slide, OK now how else can we come up with some DIFFERENT criteria vs the one WE HAD, to make us win ...

When did Bitcoin cede consensus changes to miners? Remember those other nodes, exchanges, merchants? They aren't going to be overridden so easily.

Call this what you want - at best, we have impasse.

Miners voting BIP100 (which does not exist in code)
Merchants voting for BIP101
Devs divided
Users undetermined

How is it that any 'side' has lost?

[mmortal03]

...
It also adds unnecessary complexity to the matter that inevitably will require further analysis to be done, instead of -- if 32MB is really the sticking point -- just doing a straight forward, algorithmic increase of some kind up to 32MB.

Decided by which central authority would you happen to like that to be?

The BIP101 has already failed to get it's votes ... it's still under 1%
But you want everyone to be happy with the BIP101's choice about how blocks size should be controlled ...

Do you not see the whole problem with that statement?!?

BIP100 is already above 60%
https://www.blocktrail.com/BTC/pools?resolution=24h

If the devs can't all agree to something, then I'd like it to be decided by some form of voting mechanism, and with actual code, not simply a proposal. I think it's silly to vote for BIP100 and consider those numbers meaningful when we don't even know exactly how it will work yet. BIP101 can also continue to get votes until the cutoff date, so you're making a premature claim. That being said, I'm not tied down to BIP101, you're just making the assumption that I am. BIP101 may also be the catalyst that gets a different proposal off the ground, so, even if it doesn't ultimately get the votes, it isn't a failure.

[achow101]

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.

Blah blah blah

Translated:
Damn, we lost the vote by a land slide, OK now how else can we come up with some DIFFERENT criteria vs the one WE HAD, to make us win ...

When did Bitcoin cede consensus changes to miners? Remember those other nodes, exchanges, merchants? They aren't going to be overridden so easily.

Bitcoin has always had the consensus changes done by the miners. Technically, nodes, exchanges and merchants have no direct control over the consensus. It has always been and will always be the miners who make the consensus changes because the consensus changes are in the blocks, which are made by miners. Exchanges, merchants, and users have indirect control by giving miners incentives to mine for one consensus change versus another because if miners end up on a fork that no one else uses, they lose money.

[kano]

...
It also adds unnecessary complexity to the matter that inevitably will require further analysis to be done, instead of -- if 32MB is really the sticking point -- just doing a straight forward, algorithmic increase of some kind up to 32MB.

Decided by which central authority would you happen to like that to be?

The BIP101 has already failed to get it's votes ... it's still under 1%
But you want everyone to be happy with the BIP101's choice about how blocks size should be controlled ...

Do you not see the whole problem with that statement?!?

BIP100 is already above 60%
https://www.blocktrail.com/BTC/pools?resolution=24h

If the devs can't all agree to something, then I'd like it to be decided by some form of voting mechanism, and with actual code, not simply a proposal. I think it's silly to vote for BIP100 and consider those numbers meaningful when we don't even know exactly how it will work yet. BIP101 can also continue to get votes until the cutoff date, so you're making a premature claim. That being said, I'm not tied down to BIP101, you're just making the assumption that I am. BIP101 may also be the catalyst that gets a different proposal off the ground, so, even if it doesn't ultimately get the votes, it isn't a failure.

So ... you studied the copious amount of code changes in XT for your BIP101 decision? i.e. didn't base your choice on the BIP itself?

[mmortal03]

So ... you studied the copious amount of code changes in XT for your BIP101 decision? i.e. didn't base your choice on the BIP itself?

I haven't personally looked at the code, but it's available to read and to run. I didn't base my choice on the BIP language by itself, I based it on the BIP, *and* all the various descriptions by others, *including* that the code does specifically what is described in the BIP. If you've got evidence that the various BIP101 implementations *don't* do what they are said to do, please provide it. In contrast, there is no code available from the other proposals that can be read or run by anyone at the moment, and time keeps moving right along.

[canth]

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.

Blah blah blah

Translated:
Damn, we lost the vote by a land slide, OK now how else can we come up with some DIFFERENT criteria vs the one WE HAD, to make us win ...

When did Bitcoin cede consensus changes to miners? Remember those other nodes, exchanges, merchants? They aren't going to be overridden so easily.

Bitcoin has always had the consensus changes done by the miners. Technically, nodes, exchanges and merchants have no direct control over the consensus. It has always been and will always be the miners who make the consensus changes because the consensus changes are in the blocks, which are made by miners. Exchanges, merchants, and users have indirect control by giving miners incentives to mine for one consensus change versus another because if miners end up on a fork that no one else uses, they lose money.

This is different. Hard forks are difficult to pull off since they require a supermajority of the entire ecosystem to agree. This hard fork essentially takes a rule that used to be very hard to change and instead makes it relatively easy to change while taking away any input from merchants or users.

BIP 101: miners vote on it once, larger blocks are allowed but no miner would create >1MB blocks unless they believe that enough other miners AND merchants AND users have adopted the change.
BIP 100: The exact same process, except: once BIP 100 is in place miners can vote repeatedly without ANY concern that merchants and users have to adopt the subsequent changes. Only a new hard fork would veto miners from keeping blocks at 1MB or maxing out at 32MB.

Just to give you an example of why BIP 100 is so flawed, imagine for a minute that we aren't talking about block size and imagine that instead we're talking about the block reward schedule. Say that BIP 100 would give miners the ability to vote to accelerate or decelerate the halving process. If miners voted, they could keep the 25 BTC rewards going for 8 years or 12 or more. They could do this without merchants or users having any say, besides introducing a new hard fork taking the vote away from miners. Does that sound like a good idea?

[kano]

...
Just to give you an example of why BIP 100 is so flawed, imagine for a minute that we aren't talking about block size and imagine that instead we're talking about the block reward schedule. Say that BIP 100 would give miners the ability to vote to accelerate or decelerate the halving process. If miners voted, they could keep the 25 BTC rewards going for 8 years or 12 or more. They could do this without merchants or users having any say, besides introducing a new hard fork taking the vote away from miners. Does that sound like a good idea?

Or to give another example, lets say a BIP666 comes along to set the miner reward per block to 1,000,000 BTC
Of course all miners would vote for it since they are all stupid morons who only want 1,000,000 BTC per block.

Yes my example is as silly as yours.

You need to notice the blatantly obvious ...

Miner rewards depends on the health of bitcoin.
Most of them aren't stupid enough to come up with, or vote for, either your example or mine.

... and ... miners confirm blocks and transactions, no one else does. That's how bitcoin works. If you don't like that, then you are in the wrong place.

[canth]

...
Just to give you an example of why BIP 100 is so flawed, imagine for a minute that we aren't talking about block size and imagine that instead we're talking about the block reward schedule. Say that BIP 100 would give miners the ability to vote to accelerate or decelerate the halving process. If miners voted, they could keep the 25 BTC rewards going for 8 years or 12 or more. They could do this without merchants or users having any say, besides introducing a new hard fork taking the vote away from miners. Does that sound like a good idea?

Or to give another example, lets say a BIP666 comes along to set the miner reward per block to 1,000,000 BTC
Of course all miners would vote for it since they are all stupid morons who only want 1,000,000 BTC per block.

Yes my example is as silly as yours.

You need to notice the blatantly obvious ...

Miner rewards depends on the health of bitcoin.
Most of them aren't stupid enough to come up with, or vote for, either your example or mine.

... and ... miners confirm blocks and transactions, no one else does. That's how bitcoin works. If you don't like that, then you are in the wrong place.

Miners already control block size by the soft limits - I see no reason to give them exclusive control over the max hard limits too. No, miners as a whole aren't stupid but they often do run lazy code (SPV mining fork, Jul 4th) and they also may choose short term personal profit over the greater longterm good.

To me BIP101 seems a better decision where a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

[kano]

... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

A smaller majority than used in core ... hmm the "excuse" Gavin used was to disallow a larger pool from stopping it.
Odd how that's not been an issue before ... when certain pools had a much higher % of the network ...

[canth]

... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

A smaller majority than used in core ... hmm the "excuse" Gavin used was to disallow a larger pool from stopping it.
Odd how that's not been an issue before ... when certain pools had a much higher % of the network ...

Ha...c'mon Kano, you've been around long enough to answer that one yourself. Can you point to the last intentional hard fork? I think that by their very nature they will be contentious. Even if all the core devs got together, sang kumbaya and pushed BIPxxx for a 2MB block it'd be hard to get 95% adoption.

Hell, devs haven't even gotten a test hard fork with a 1.1MB block size increase just to prove that hard forks will be adopted.

[kano]

... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

A smaller majority than used in core ... hmm the "excuse" Gavin used was to disallow a larger pool from stopping it.
Odd how that's not been an issue before ... when certain pools had a much higher % of the network ...

Ha...c'mon Kano, you've been around long enough to answer that one yourself. Can you point to the last intentional hard fork? I think that by their very nature they will be contentious. Even if all the core devs got together, sang kumbaya and pushed BIPxxx for a 2MB block it'd be hard to get 95% adoption...

*me looks at BIP100 ...

[canth]

... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

A smaller majority than used in core ... hmm the "excuse" Gavin used was to disallow a larger pool from stopping it.
Odd how that's not been an issue before ... when certain pools had a much higher % of the network ...

Ha...c'mon Kano, you've been around long enough to answer that one yourself. Can you point to the last intentional hard fork? I think that by their very nature they will be contentious. Even if all the core devs got together, sang kumbaya and pushed BIPxxx for a 2MB block it'd be hard to get 95% adoption...

*me looks at BIP100 ...

C'mon...I think that you'll agree that BIP100 is lacking just a bit of indicated industry support at this point. No? Miners marking blocks is one thing. Need some others like, oh, users to go along with it too, right?

[kano]

... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

A smaller majority than used in core ... hmm the "excuse" Gavin used was to disallow a larger pool from stopping it.
Odd how that's not been an issue before ... when certain pools had a much higher % of the network ...

Ha...c'mon Kano, you've been around long enough to answer that one yourself. Can you point to the last intentional hard fork? I think that by their very nature they will be contentious. Even if all the core devs got together, sang kumbaya and pushed BIPxxx for a 2MB block it'd be hard to get 95% adoption...

*me looks at BIP100 ...

C'mon...I think that you'll agree that BIP100 is lacking just a bit of indicated industry support at this point. No? Miners marking blocks is one thing. Need some others like, oh, users to go along with it too, right?

Some users have said they want bigger blocks ... even though they have no direct vote in the hard fork change.
BIP100 gives bigger blocks ...

[canth]

... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

A smaller majority than used in core ... hmm the "excuse" Gavin used was to disallow a larger pool from stopping it.
Odd how that's not been an issue before ... when certain pools had a much higher % of the network ...

Ha...c'mon Kano, you've been around long enough to answer that one yourself. Can you point to the last intentional hard fork? I think that by their very nature they will be contentious. Even if all the core devs got together, sang kumbaya and pushed BIPxxx for a 2MB block it'd be hard to get 95% adoption...

*me looks at BIP100 ...

C'mon...I think that you'll agree that BIP100 is lacking just a bit of indicated industry support at this point. No? Miners marking blocks is one thing. Need some others like, oh, users to go along with it too, right?

Some users have said they want bigger blocks ... even though they have no direct vote in the hard fork change.
BIP100 gives bigger blocks ...

Sure and in the absence of any other options, I'd vote for BIP100 too. In the short term, there's enough disagreement amongst all the various parties that the 1MBers are going to get their wish...for the rest of 2015 at least.

[iCEBREAKER]

The focus on 32MB seems arbitrary and silly. XT (for example) has the 32MB limit removed - there's no reason core couldn't remove it at the same time as a block size hard fork.

One does not simply remove the 32MB limit.

What is it with Gavinistas and their adorably naive (yet misleading) pipe dreams of scaling Bitcoin by using find/replace in a code editor?