Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 100. (Read 4382653 times)

Its probably trivial, but it was a tad under 15PH (14.86PH and now 23PH+)





EDIT: Seems to be dropping though .....

Well it was 16PH. So +6PH. It was going up from 14PH ever since first XT block was mined...

Yep ... hash rate just shot up +8PH in the last couple of hours ..... hope that comes hand inglove with improved luck to boot!

Is it just me or did hashrate go up by 8 Ph since XT or QT vote can be made on Slush? It was 14 right? Now it is 22...

EDIT: would be nice to know % of the votes...

The network/protocol should be ready for that and react accordingly, but blindly bumping the size is a bad idea.
Please read my proposal at the link provided - it allows for the fee market to develop without much pressure by keeping the blocks almost full. By adding the option for a soft limit from the miners it is even possible to amend it at some degree by mining smaller blocks and shrinking the block size to force more fees, but for that to happen it would require consensus from more than half of the miners, because empty blocks are ignored from the algorithm one can't mine only empty blocks to alter the size (not to mention he will also loose the fees he wants)

EDIT: Ooh and Slush provided the best option for each miner to vote - on another port ... let's say we have the default port 'supporting full size', then we have port 3001 'mine 50% full blocks' and few more for every 10% or 15% steps ... then each miner have the choice for the next block size direction, not only the pools

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


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.

"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://bitcointalksearch.org/topic/m.12267335

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

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.

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.

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?

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/

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.

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.

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.

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?)

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".

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.

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

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).

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

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