AntPool, BTCChina Pool, 21 Inc., BW Pool and KNCMiner support 8MB

[yeponlyone]

By looking at https://www.blocktrail.com/BTC/blocks/1, we can now see that AntPool, BTCChina Pool, 21 Inc., BW Pool and KNCMiner support 8MB.

Of the major pools, DiscusFish/F2Pool, Bitfury and Eligius (surprise  ) do not (yet) support 8MB.

[keepdoing]

Why are their gaps in the voting?  Antpool for example as you go down the chain sometimes votes 8mb, and sometimes it doesn't.  Pools are comprised of many, so isn't this a bit misleading to say "The Pool" supports blah blah blah.

[entertainment]

f2pool signed for 8mb support, so they will accept soon I suppose.

http://www.8btc.com/blocksize-increase-2

[Lauda]

Yeah, it was better that I realized on time that I would say this another few thousand times.
Supporting block size increase =/= supporting XT
Supporting 8 MB blocks (or BIP 101 - if they support addition increases) =/= supporting XT

Unless they state we support 8 MB blocks in addition to XT, then you're taking things out of context for the sake of this tiring political battle between Core and XT.

[entertainment]

Yeah, it was better that I realized on time that I would say this another few thousand times.
Supporting block size increase =/= supporting XT
Supporting 8 MB blocks (or BIP 101) =/= supporting XT

Unless they state we support 8 MB blocks in addition to XT, then you're taking things out of context for the sake of this tiring political battle between Core and XT.

They only implementation right now supporting 8mb (BIP101) is XT. If Core doesn't implement it, they will go to XT.

Btw, Antpool has said that they are reasy to switch to XT: https://twitter.com/JihanWu

[S4VV4S]

Yeah, it was better that I realized on time that I would say this another few thousand times.
Supporting block size increase =/= supporting XT
Supporting 8 MB blocks (or BIP 101) =/= supporting XT

Unless they state we support 8 MB blocks in addition to XT, then you're taking things out of context for the sake of this tiring political battle between Core and XT.

They only implementation right now supporting 8mb (BIP101) is XT. If Core doesn't implement it, they will go to XT.

Not necessarily.
There is no immediate need for larger blocks.
And if there is and there is no consensus reached by the developers by then, then IMO, we as community should step in and fork the Community version of Bitcoin Core.
The version we as Bitcoiners want to use and not the one imposed to us.

[Lauda]

Btw, Antpool has said that they are reasy to switch to XT: https://twitter.com/JihanWu

See, you're doing it again. Taking things out of context. They put a big IF in that sentence:"IF we see majority has switched.". Obviously they are simply stating if the majority switches then they will to (logic, else they'd be behind). That statement has no words of support in regards to XT.

They only implementation right now supporting 8mb (BIP101) is XT. If Core doesn't implement it, they will go to XT.

Wrong. I support bigger blocks (maybe even 8 MB), but I will never go XT (take this as an example).
Also: Supporting 8 MB blocks =/= supporting BIP 101.
People simplify this too much. While someone might support 8 MB blocks, they might not support the additional increases that BIP 101 contains (they are unsustainable).

There is no immediate need for larger blocks.

Most people do not realize this and think that their opinion is the absolute correct one. Dunning–Kruger effect shines bright around here.

[entertainment]

Btw, Antpool has said that they are reasy to switch to XT: https://twitter.com/JihanWu

See, you're doing it again. Taking things out of context. They put a big IF in that sentence:"IF we see majority has switched.". Obviously they are simply stating if the majority switches then they will to (logic, else they'd be behind). That statement has no words of support in regards to XT.

They only implementation right now supporting 8mb (BIP101) is XT. If Core doesn't implement it, they will go to XT.

Wrong. I support bigger blocks (maybe even 8 MB), but I will never go XT (take this as an example).
Also: Supporting 8 MB blocks =/= supporting BIP 101.
People simplify this too much. While someone might support 8 MB blocks, they might not support the additional increases that BIP 101 contains (they are unsustainable).

There is no immediate need for larger blocks.

Most people do not realize this and think that their opinion is the absolute correct one. Dunning–Kruger effect shines bright around here.

I sencerely don't like Core in the last time, where a sifnificant number of devs are working or presiding a company for profit, a company that will be probably favored if the limit does not scale.

If the majority switch, you will have to do it also. If not, at least XT will push to solve this issue earlier. Come on, we can't continue otheres 24 months speaking about the same...

[pedrog]

How are they voting for 8MB?

[LiteCoinGuy]

[LiteCoinGuy]

i guess now there is 75-80% of all hashpower for bigger blocks = XT (because there is no other solution at the moment)

[Lauda]

I sencerely don't like Core in the last time, where a sifnificant number of devs are working or presiding a company for profit, a company that will be probably favored if the limit does not scale.

Exactly what is wrong with that? The developers decided to make a company to profit via something that they're going to build on top of Bitcoin. Are you trying to tell me that if you were in their position, that you would not try to do the same?  
They will increase the block size limit, they just have to reach consensus in regards to how much and when.

If the majority switch, you will have to do it also. If not, at least XT will push to solve this issue earlier. Come on, we can't continue otheres 24 months speaking about the same...

Wrong. I don't have to do anything. There are plenty of coins that are better than XT (due to their bugged "patches"). XT is one of the worst outcomes of this debate.

i guess now there is 75-80% of all hashpower for bigger blocks = XT (because there is no other solution at the moment)

No.

[entertainment]

Exactly what is wrong with that? The developers decided to make a company to profit via something that they're going to build on top of Bitcoin. Are you trying to tell me that if you were in their position, that you would not try to do the same?  
They will increase the block size limit, they just have to reach consensus in regards to how much and when.

What is wrong with that?  That company could force Bitcoin development to advantage themselves!!

"They will increase the block size limit"

Let's see. I have readed LUKEJR saying that the first priority is Lightning, not the block limit. ADAM BACK saying that not every transaction should be on the blockchain or will be collapsing the whole Internet. PETER TODD saying that blockhains doesn't scale well. And SZABO proposing 4mb blocks for 2025!

10 years ago, the average hdd was 1GB of capacity, today is close to 1TB! How can he proposes a 4MB limit in 10 years? Where is the logic for that?

[BitUsher]

10 years ago, the average hdd was 1GB of capacity, today is close to 1TB! How can he proposes a 4MB limit in 10 years? Where is the logic for that?

The concerns of most devs has nothing to do with hard drive space but propagation time, bandwidth limits(especially upload) and mempool problems created by larger blocks.

[S4VV4S]

10 years ago, the average hdd was 1GB of capacity, today is close to 1TB! How can he proposes a 4MB limit in 10 years? Where is the logic for that?

The concerns of most devs has nothing to do with hard drive space but propagation time, bandwidth limits(especially upload) and mempool problems created by larger blocks.

http://wallstreettechnologist.com/2015/08/19/bitcoin-xt-vs-core-blocksize-limit-the-schism-that-divides-us-all/

Selfish miners

Selfish mining, is one such attack which was clearly explained in Satoshi’s paper as a possible weakness of Bitcoin.  This entails a miner, who has a significant amount of hashing power, mining blocks but not publishing them, thereby creating a secret longer chain that the rest of the network does not know about, with the intent of broadcasting it later, and in doing so will reverse some transactions that may have already been confirmed on the public (but shorter) chain.  This is the infamous double spend attack.  Normally this can only be accomplished reliably when one possesses over 51% of the hashing power of the network.  What most people don’t know is that network propagation is also a factor here.  Satoshi admitted that his calculations on the percentage of hashing power in order to be able to pull off a 51% attack reliably assumes no significant network propagation delays.  Indeed the danger of allowing block size to increase to the point where the expected delays in block propagation through the network has been discussed ad infinitum in the past, and the reason why the block debate has been ongoing since at least 2011.

In this regard, I can understand why Gavin feels that he must do something drastic to force the issue.  The attack goes as follows: If blocks were allowed to be ‘too big’ (big enough to add plausible delays to propagate to all nodes) then a miner would be incentivized to stuff the block they are mining full of txns that pay himself (or a cohort), up to the allowable block limit.  They do not broadcast these transactions to the network unless they solve the block themselves, removing the possibility of paying miner fees to some other miner.  If they manage to solve the block, they immediately broadcast all their spam txns and block solution.  The other miners would have to drop what they are mining, and start downloading the new (very large) block (which may take some time) and verify it, which involves checking the validity of all contained transactions (which will take some more time).  All this results in a appreciable head start that the attacking miner can enjoy in mining the next block.  So what he has successfully done is increased his ‘effective’ hashing power giving him a slight edge over his competitors.  Of course this is a game-theoretic problem, so we can assume that once one miner starts doing this, then either all miners will start doing this, as well (and make orphan blocks and double spends a lot more common) or band together to share high bandwidth connections/nodes (and push the system more towards a centralized one) both situations are bad for Bitcoin.  So everyone can agree that too big of a block size would open up bitcoin to a certain type of fragility that has up until now, not been a problem.

[pedrog]

10 years ago, the average hdd was 1GB of capacity, today is close to 1TB! How can he proposes a 4MB limit in 10 years? Where is the logic for that?

The concerns of most devs has nothing to do with hard drive space but propagation time, bandwidth limits(especially upload) and mempool problems created by larger blocks.

http://wallstreettechnologist.com/2015/08/19/bitcoin-xt-vs-core-blocksize-limit-the-schism-that-divides-us-all/

Selfish miners

Selfish mining, is one such attack which was clearly explained in Satoshi’s paper as a possible weakness of Bitcoin.  This entails a miner, who has a significant amount of hashing power, mining blocks but not publishing them, thereby creating a secret longer chain that the rest of the network does not know about, with the intent of broadcasting it later, and in doing so will reverse some transactions that may have already been confirmed on the public (but shorter) chain.  This is the infamous double spend attack.  Normally this can only be accomplished reliably when one possesses over 51% of the hashing power of the network.  What most people don’t know is that network propagation is also a factor here.  Satoshi admitted that his calculations on the percentage of hashing power in order to be able to pull off a 51% attack reliably assumes no significant network propagation delays.  Indeed the danger of allowing block size to increase to the point where the expected delays in block propagation through the network has been discussed ad infinitum in the past, and the reason why the block debate has been ongoing since at least 2011.

In this regard, I can understand why Gavin feels that he must do something drastic to force the issue.  The attack goes as follows: If blocks were allowed to be ‘too big’ (big enough to add plausible delays to propagate to all nodes) then a miner would be incentivized to stuff the block they are mining full of txns that pay himself (or a cohort), up to the allowable block limit.  They do not broadcast these transactions to the network unless they solve the block themselves, removing the possibility of paying miner fees to some other miner.  If they manage to solve the block, they immediately broadcast all their spam txns and block solution.  The other miners would have to drop what they are mining, and start downloading the new (very large) block (which may take some time) and verify it, which involves checking the validity of all contained transactions (which will take some more time).  All this results in a appreciable head start that the attacking miner can enjoy in mining the next block.  So what he has successfully done is increased his ‘effective’ hashing power giving him a slight edge over his competitors.  Of course this is a game-theoretic problem, so we can assume that once one miner starts doing this, then either all miners will start doing this, as well (and make orphan blocks and double spends a lot more common) or band together to share high bandwidth connections/nodes (and push the system more towards a centralized one) both situations are bad for Bitcoin.  So everyone can agree that too big of a block size would open up bitcoin to a certain type of fragility that has up until now, not been a problem.

Satoshi never intended to a limit to exist, so what was his solution?

[LiteCoinGuy]

and sidechains / lightning need bigger blocks too. so where is the point? maybe XT is too much but 1 MB is too little.

[Lauda]

What is wrong with that?  That company could force Bitcoin development to advantage themselves!!

Everyone would probably do it if they were in their places. (almost) Everyone strives for money/profit. They can't force anything to the software, people would be aware and reject the client.

"They will increase the block size limit"

Let's see. I have readed LUKEJR saying that the first priority is Lightning, not the block limit. ADAM BACK saying that not every transaction should be on the blockchain or will be collapsing the whole Internet. PETER TODD saying that blockhains doesn't scale well. And SZABO proposing 4mb blocks for 2025!

You mean you have read, as 'readed' is not existent. You will definitely have to do a lot of reading on the mailing list and reddit. The only ones who are strongly against the hard forking (now) are Maxwell and Luke.
You only look at one side of the picture, and thus your view is biased. What about Jeff Garzik who proposed both BIP 100 and BIP 102? Is he not a core developer?

10 years ago, the average hdd was 1GB of capacity, today is close to 1TB! How can he proposes a 4MB limit in 10 years? Where is the logic for that?

Wrong. It is more about the network bandwidth than about storage (even though we are reaching the maximum with the current technology). The increase has started to slow down over the last few years. The problem is persistent in developing countries.

[BitUsher]

and sidechains / lightning need bigger blocks too. so where is the point? maybe XT is too much but 1 MB is too little.

95%+ of the devs are fine with increasing the blocksize above 1MB , they just want more testing done.

This is preciously what is attempting to be done here:

https://scalingbitcoin.org/montreal2015/

[LiteCoinGuy]

and sidechains / lightning need bigger blocks too. so where is the point? maybe XT is too much but 1 MB is too little.

95%+ of the devs are fine with increasing the blocksize above 1MB , they just want more testing done.

This is preciously what is attempting to be done here:

https://scalingbitcoin.org/montreal2015/

yes i know about that. hopefully that will bring more clarity.

Warren, a leading Litecoin Dev is in the Montreal Workshop Planning Committee.