[150+ PH] SlushPool (slushpool.com); World's First Mining Pool

[TheRealSteve]

Is there a break down some place on the pool as to where that increased hash is pointing to?  Like 10PH voting yes, 7PH voting no?

Nope.  You could make an extremely rough estimate.  Block 370434 was their first BIP101 block.  Including that block they have since mined 31 blocks.  3 of which were BIP101.  That's 9.68%.  9.68% of the 15.93Ph/s currently shown on the site ~= 1.54Ph/s.  Statistically  (given the sample set) that's an optimistic estimate - could be lower, could be higher.

[1506442438]

1506442438

[larry12]

Can you both read?
By default your hashrate is a vote for Core/QT not XT.
If you want to support XT, you need to change your miners to different port.

to read what?
i dont like XT idea, slush's pool support it so goodbye slush.....

[KNK]

Can you both read?
By default your hashrate is a vote for Core/QT not XT.
If you want to support XT, you need to change your miners to different port.

to read what?
i dont like XT idea, slush's pool support it so goodbye slush.....

He does not support it! He gives us the choice to (NOT) support it which is completely different ... Stay on the old port and vote against XT what more simple?!

I think that increasing the block size is the most decentralized option, even if full nodes will only be able to be hosted on powerful computers, since miners do not run full nodes, the pools do.

If you don't own/control your private key - you don't own your Bitcoins. You need your own full node or you need to trust someone's else full node, while Bitcoin's whole idea (under the word decentralised) is Trust no one

[RealMalatesta]

There are only 3 "XT blocks" in the last 500 - all 3 slush - and only slush.
https://www.blocktrail.com/BTC/blocks/1

Edit: well actually it is 2 (as I first posted) the 3rd one is just outside 500

Moot point (and offtopic).
There are many more (bigger) 8MB blocks, and not many from slush, actually none from slush. (now go spam somewhere else!)

<nonsense_snip> ...</nonsense_snip>
XT - BIP101 - gives block size control to Hearne and Gavin - not to the pools and miners.
So basically you are voting to give control to those two, rather than the bitcoin network.

Oh well.

Nope. You are wrong again and you've taken the opportunity to spam even more.
So, I'll draw a clean line and stop feeding this troll.

Would you care to elaborate? I think it is an interesting question and do not see this as trolling.

[pekatete]

Would you care to elaborate? I think it is an interesting question and do not see this as trolling.

The vote on slush is, and I quote: Right now, every Slush Pool miner can vote for larger blocksize.
So clearly (and if you cared to have read the last couple of pages here), it is not about XT, BIP100, BIP101 or whatever. Just bigger block size, which can be achieved any of different ways, including XT.

And no, not all other pools mine bigger (than standard 1MB) blocks, though some (mainly Chinese) pools mine 8MB blocks. The troll would have you believe otherwise.

Additionally (and as far as I am aware), only slush has ACTUALLY offered the choice to users to vote for bigger blocks.

That much the troll knows, though he keeps trying to whip up some kind of negativity towards slush by attributing patently false aims to slush in a veiled attempt to get miners to elope to his his own pool.

[KNK]

Additionally (and as far as I am aware), only slush has ACTUALLY offered the choice to users to vote for bigger blocks.

Exactly and that's the important thing - even if you disagree with BIP101 or larger blocks (BIP100), you have the choice and a way to have your voice heard. Ignoring the BIPs and leaving your users the only choice to leave if they disagree with you is not the right thing to do IMHO

And no, not all other pools mine bigger (than standard 1MB) blocks, though some (mainly Chinese) pools mine 8MB blocks.

Small correction. No pool is mining larger blocks yet as they will be rejected anyway, but they do vote for larger blocks via BIP100, while Slush provides the choice for BIP101 - both are ways to vote for larger blocks, but with different strategies (one time fixed increase or every two years doubling) and both with their own disadvantages

[pekatete]

No pool is mining larger blocks yet as they will be rejected anyway, but they do vote for larger blocks via BIP100, while Slush provides the choice for BIP101 - both are ways to vote for larger blocks, but with different strategies (one time fixed increase or every two years doubling) and both with their own disadvantages

I see one vote as a vote of the actual miners and the other as a vote of the pool operators (though the lines can be blurred).
Still, an overwhelming majority of pool operators (99.99%) do not give that very simple option to vote to their users, and for me (with the hindsight of slush's brilliance), that is not a vote at all, simply the wishes of pool operators (if a clear distinction can be made from the miners).

[jonnybravo0311]

Would you care to elaborate? I think it is an interesting question and do not see this as trolling.

The vote on slush is, and I quote: Right now, every Slush Pool miner can vote for larger blocksize.

Wrong.

The vote is "do you support XT or Core".  Other pools (AntPool, BW Pool, etc) are putting things in their coinbase sig (like "8MB") to show they support larger block sizes (BIP100).  They have NOT altered their core clients to XT, which alters the block version number (core is "3", XT is "536870919").  If, come January of 2016, enough blocks are found using XT, a hard fork will occur.

Using XT means more than just "I support larger block sizes".  It also means you support everything else that comes with XT.  Things like:

• Longest chain no longer wins, chain validity is determined using checkpoints periodically added by the XT devs to the code
• Tor nodes are deprioritised from connection as an anti-DOS measure
• Permitted Tor exit nodes are, at present, hard coded into the XT client
• Altered methods of tracking potential double spend transactions

[pekatete]

Would you care to elaborate? I think it is an interesting question and do not see this as trolling.

The vote on slush is, and I quote: Right now, every Slush Pool miner can vote for larger blocksize.

Wrong.

The vote is "do you support XT or Core".

YOU are wrong as the vote (which I quoted) clearly says otherwise. Other pools do not offer the vote, they just vote using (amongst others) others' hash.

That XT offers a larger blocksize (as opposed to core) is sufficient for the vote to be about blocksize, notwithstanding (and irrelevant to the fact) that it'd also result in a hardfork. In any case, there is a vote so may the one who garners the highest blocks (at the core specified time) win. If it is XT, then we get the bigger blocksize that has been voted for.

[jonnybravo0311]

I am absolutely not wrong here.  XT is the only client that implements BIP101.  It changes the block version as I described.  Therefore, Slush has XT running on one port, and Core running on the other.

If you use the port that is running XT, you not only vote to support BIP101, but you also vote to support the other things that I listed.

There's a very distinct difference between saying "I want larger block sizes" and "I'm using XT".

[pekatete]

Those so called distinct differences are what belong to (and should have) another thread.
Bottom line is, the vote is for larger blocksizes as I have repeatedly quoted (however much you may scream to the contrary). It is secondary that slush is actually both running XT (which offers larger blocksizes as opposed to core) and core, the important point being there is an option to easily "vote" either way. (I wonder, does the pool you mine at offer even a choice to vote for 100?)

[VeritasSapere]

I am absolutely not wrong here.  XT is the only client that implements BIP101.  It changes the block version as I described.  Therefore, Slush has XT running on one port, and Core running on the other.

If you use the port that is running XT, you not only vote to support BIP101, but you also vote to support the other things that I listed.

There's a very distinct difference between saying "I want larger block sizes" and "I'm using XT".

Actually there is an alternative version of XT that only changes the block size, or you could even run a patched version of Core that implements BIP101. The block size increase is the only fundamental change to the protocol, the other features within XT are all optional. Therefore if you use the port that is listed it is essentially just a vote to support BIP101 and not the other features that are within XT.

[chiguireitor]

[...] You need your own full node or you need to trust someone's else full node [...]

Wrong, Electrum and SPV wallets keep their private keys, and they still are reliable as you can tell from the current state of affairs.

The only thing needed for controlling your bitcoin is having the private key for them. Full nodes are just for maintaining the network's infrastructure (which is kinda a big deal).

However, web wallets that rely on servers to "keep" the private keys are the real cancer here, people need to stop using them asap.

[chiguireitor]

[...] Actually there is an alternative version of XT that only changes the block size [...]

What version is that? I would really like a Non-XT BIP 101 toting client for my full node, as i'm real busy atm and can't modify my own core for that.

[VeritasSapere]

[...] Actually there is an alternative version of XT that only changes the block size [...]

What version is that? I would really like a Non-XT BIP 101 toting client for my full node, as i'm real busy atm and can't modify my own core for that.

Here you go:
https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/

[KNK]

[...] You need your own full node or you need to trust someone's else full node [...]

Wrong, Electrum and SPV wallets keep their private keys, and they still are reliable as you can tell from the current state of affairs.

The only thing needed for controlling your bitcoin is having the private key for them. Full nodes are just for maintaining the network's infrastructure (which is kinda a big deal).

However, web wallets that rely on servers to "keep" the private keys are the real cancer here, people need to stop using them asap.

You are right - there are clients with which you have your private key, but you still depend (and need to trust) on someone's full node to confirm you have your funds or even worse that the transaction you just received (as a merchant for example) is not a double spend.
The fee is not the only expense for sending or receiving Bitcoins - you need to trust someone to confirm it is not a double spend or run your own full node for that.
As a merchant will you spend thousands for high speed connection and powerful servers?
If you need to use some of the few (centralized) full nodes on the network, what is it different than using Visa, Master Card or Pay Pal?

[VeritasSapere]

[...] You need your own full node or you need to trust someone's else full node [...]

Wrong, Electrum and SPV wallets keep their private keys, and they still are reliable as you can tell from the current state of affairs.

The only thing needed for controlling your bitcoin is having the private key for them. Full nodes are just for maintaining the network's infrastructure (which is kinda a big deal).

However, web wallets that rely on servers to "keep" the private keys are the real cancer here, people need to stop using them asap.

You are right - there are clients with which you have your private key, but you still depend (and need to trust) on someone's full node to confirm you have your funds or even worse that the transaction you just received (as a merchant for example) is not a double spend.
The fee is not the only expense for sending or receiving Bitcoins - you need to trust someone to confirm it is not a double spend or run your own full node for that.
As a merchant will you spend thousands for high speed connection and powerful servers?
If you need to use some of the few (centralized) full nodes on the network, what is it different than using Visa, Master Card or Pay Pal?

I do not necessary think that it will cost thousands to host a full node, it is not that expensive to hire a server within a data center after all. However I would argue that it would still be more decentralized then being "forced" to use third party payment processors instead of being able to use the main chain directly since that is what would happen if we do not increase the block size and adoption also increased.

[KNK]

I agree that block size should increase at some point in time, when the adoption is increased and there is demand for that, but just not yet, not with fixed steps (ignoring the tech limits) and blindly 'just because we should'

Bitcoin was designed as self-tuning system in terms of difficulty and that when the reward is reduced the fees would cover the mining expenses, but Satoshi had single software as both wallet and miner, the wallet contained the whole blockchain, so being a full node at the same time. Now we have wallets, pools, miners and full nodes separated - by putting the burden on some of them and providing the fees (that should cover the expenses) to others just forces centralisation - wallet providers and pools will remain the only full nodes, which gives them the power to force their own rules later

I do not necessary think that it will cost thousands to host a full node, it is not that expensive to hire a server within a data center after all.

8MB blocks 6 times per hour is 1GB+ per day, so 1TB is enough for just a bit less than 3 years ... if doubled after 2 years its just a bit over 2 years and for the next year you need another 1TB and then double triple (to include the old data) that space every two years.
Storage space is expensive in a data center and bandwidth is expensive at merchant's location in both cases you also need CPU power to scan that whole data (for confirming a transaction) and to do it fast and for several transactions on each block not just your own - thousands is not that far as a figure.

[VeritasSapere]

I agree that block size should increase at some point in time, when the adoption is increased and there is demand for that, but just not yet, not with fixed steps (ignoring the tech limits) and blindly 'just because we should'

Bitcoin was designed as self-tuning system in terms of difficulty and that when the reward is reduced the fees would cover the mining expenses, but Satoshi had single software as both wallet and miner, the wallet contained the whole blockchain, so being a full node at the same time. Now we have wallets, pools, miners and full nodes separated - by putting the burden on some of them and providing the fees (that should cover the expenses) to others just forces centralisation - wallet providers and pools will remain the only full nodes, which gives them the power to force their own rules later

I do not necessary think that it will cost thousands to host a full node, it is not that expensive to hire a server within a data center after all.

8MB blocks 6 times per hour is 1GB+ per day, so 1TB is enough for just a bit less than 3 years ... if doubled after 2 years its just a bit over 2 years and for the next year you need another 1TB and then double triple (to include the old data) that space every two years.
Storage space is expensive in a data center and bandwidth is expensive at merchant's location in both cases you also need CPU power to scan that whole data (for confirming a transaction) and to do it fast and for several transactions on each block not just your own - thousands is not that far as a figure.

"wallet providers and pools will remain the only full nodes, which gives them the power to force their own rules later" I do not think that the people that benefit from Bitcoin would attempt to undermine it, not because I trust them but because of how peoples incentives are aligned and game theory, that is how Bitcoin mining works after all.

"thousands is not that far as a figure." Even if I was running a full node with full twenty megabyte blocks for instance it would still only be in the hundreds not in the thousands per year. https://www.vultr.com/pricing/

I am glad that you do think that the block size must be increased, what concerns me is that if we did have a spike in adoption possibly after some global event, then the network would become overloaded. the consequences of this would seriously hamper adoption and public perception. Some of the Core developers like Peter Todd literally do not want the block size increased at all, so that a "fee market" can develop. They think that this would "incentive" third party payment processors which we would then all have to rely on, since transacting on the main chain directly would be to expensive for a normal person and the Bitcoin blockchain will be used primarily as a clearing house for banks, large corporations and payment processors. This is a fundamentally different vision then what Bitcoin was initially intended to be. We should stay true with the original vision of Bitcoin, and if we do really want something different, then it should be implemented as an alt coin and then the market can decide.

I do not think that Core will ever increase the block size, that is why if we want bigger blocks we must fork away from the Core development team. That the majority of users would eventually not be able to run full nodes was part of the original design of Bitcoin, quoting Satoshi Nakamoto:

"The eventual solution will be to not care how big it gets."
"But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore."
"The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users."

https://bitcointalk.org/index.php?topic=1164464.msg12267335#msg12267335

[JorgeStolfi]

Using XT means more than just "I support larger block sizes".  It also means you support everything else that comes with XT.  Things like:

• Longest chain no longer wins, chain validity is determined using checkpoints periodically added by the XT devs to the code

That has been talked about, but, AFAIK, it is not in the released BitcoinXT yet.

• Tor nodes are deprioritised from connection as an anti-DOS measure
• Permitted Tor exit nodes are, at present, hard coded into the XT client
• Altered methods of tracking potential double spend transactions

People should check what the XT authors say about these.  However, there is a fork of XT that has only the block size limit increase patch, not the other controversial ones.  (Since these are node/client policy changes, not protocol changes, they will not cause a fork of the chain, not even a soft one.)

And anyone could make a clone of BitcoinCore with the increased block size limit.   Such a version too would be compatible with the other BitcoinXT options.