My understanding is that once GBT protocol is finalized, everyone can write his own miner software follows this protocol. So there can be multiple version of Eligius miner programs, and Eligius cannot reject certain clients as long as they follow the protocol. Therefore, it could be much better than current situation, where miners either join the pool and follow operator's rules or leave.
Ah, that'd be cool, but I feel as though it's little more than baseless optimism, and seems like you might be "
repeating the unsupported claims" propaganda-style about GBT's claimed features and utility, despite the fact that certain aspects of the claims are not even explicitly part of GBT's BIP22 / BIP23 specifications or design.
First, I will start by saying that I am
NOT opposed to any sort of GBT implementation(s) which can achieve as many of these goals as possible.
That said, I think there are some systemic flaws in the "GBT server" mining design...
Here's my understanding of some ways in which GBT is basically toothless and impotent, and thus unable to fix [
some of] the problems with centralized mining pools, and potential abuses of power by pool operators...
For example, the recent incident where a popular pool operator "
wrote, and then released a bitcoin patch which modified their pool's transaction handling code to ignore bitcoin's inherent fungibility, discriminating and severely rate limiting certain types transactions" ... which ultimately inspired the original poster to create this thread:
(
and luke, please do feel at liberty to correct / refute these points if any of it is not fact-based)
... Evaluated from a "stand-alone vacuum" (
see below, *mempool*), GBT by itself doesn't do anything to prevent a pool operator from:
1) intentionally censoring / filtering transactions (
as per luke's patch which heavily rate-limits address reuse to once per block)
2) intentionally including transactions associated with executing a double-spend (
because either the pool operator themself is the one doing the double-spend, or they were bribed, compelled, or blackmailed into using the pool resources to help dishonest parties pull off a double-spend)
*cough* GHash.io
*cough*3) intentionally adding non-bitcoin data for an alternate crypto currency's blockchain (
sha-256 based, like namecoin for instance) which is piggybacked on the bitcoin blockchain merged-mining style
... These things can be done by
ANY mining pool operator (
including a pool which supports GBT) and are not likely to be detected until the block(s) have already been mined using the centralized pool's hashing power.
As for point #3, the only way GBT can help, is for a new feature (
the details for any such mechanism are not explicitly standardized, or even described in BIP22 / BIP23, but rather, the implemenation is simply "left to the imagination" of anyone choosing to implement "GBT client" based mining software) in BIP22 / BIP23 based mining software (
or better still, using a protocol, implemenation, or mining system which adds transparency for miners, but does so in a completely zero-trust manner, and thus not subject to the whim of a centralized "GBT server" pool operator) to have some implementation for fully-configurable, fully-automatic screening rules to inspect the contents of the template sent by the pool...
... ideally, these rules should be automatically used by the mining software, and customizable with full opt-in miner (
"GBT client" / end user) configured filtering / alerting / pool-banning (
stop mining on this pool, it's doing something bad so switch to a failover pool) levels which are automatically triggered upon detection of anything [
in the workload, GBT-based or otherwise] which the miner doesn't wish to blindly participate in...
(
...point #3 continued, and a bit of #2 as well) Regardless of any transparency added as a result of having the complete [
GBT] template available for inspection, upon "
reading the fine print" about BIP22's core GBT protocol functionality, there is an explicit rule wherein the "GBT server" operator is able to flag a transaction as being a "mandatory transaction" (
a per-transaction boolean true/false, GBT's JSON-encoded transaction object, field name is "required")
-- as such, because of this "
read the fine print" protocol rule, the pool will not credit a miner for proof of work shares which do not include any transaction marked as mandatory. This
"mandatory transaction" (fine print) protocol rule gives full power to the "GBT server" (pool) to force a miner to mine whichever transactions the pool operator requires to be included in blocks, and so the full power (
and full potential for abusing pool resources) still remains in the hands of a "GBT server" operator...
...even if the work submitted by a miner is "technically valid" as per the rules of the bitcoin network itself, the "GBT server" / pool operator's BIP22-compliant server will reject any shares without the required (
fine print) transaction(s), automatically punishing users for not "doing as they were told" (
miners who want to opt-out of merged mining, miner-detected double spends, or even just miners with their own preference for arbitrary or specific types of transactions being opted out of, etc. etc. etc.)
As for point #1 and #2, the "GBT client" (miner) side will need access to a bitcoind-type mempool in order to be able to compare the pool-issued [
GBT] template against the miner's own preferences...
There is no way to build a zero-trust solution to the issues in point #1 and #2 without the "GBT client" having access to a local bitcoind node (
not necessarily a full bitcoind / bitcoin-qt node, but at least SOME version of a software which speaks the full bitcoin protocol and has a mempool full of transactions, and therefore able to audit anything undesirable described in point #1 or #2)
If GBT's form of giving miners control over their own "decentralized" mining forces them to run their own local bitcoin node anyway (
just to be able have a local mempool on-hand... see below, *mempool*) then they might just as easily give up on fake-decentralzied, and take the extra time to set up a p2pool node and use it for actually-decentralized mining instead.
*mempool*
WITHOUT at-minimum, providing the "GBT client" / miner access to some form of zero-trust mempool
or otherwise provably accurate list of bitcoin's p2p network dataset for unconformed transactions...
... the upper-most limit / extent to which any "added security" can ever be provided by BIP22 / BIP23 GBT is to add "
transparency and accountability" by hypothetically being able to inspect the contents of whatever work has been sent to the miner...
... to my knowledge, at this time there is still a total lack of any public, working, proof-of-concept "GBT client" implementation with the ability to use zero-trust mempool data (
local bitcoin node or otherwise) for the purposes of auditing and amending the suggested template sent by the pool (
"GBT server") in order to make it easier for the miner (
"GBT client") to mine bitcoin in a more decentralized manner.
GBT isn't automatically decentralized just because the BIP22 / BIP23 specification for GBT doesn't explicitly forbid compliant implementations from taking //unspecified, but not-forbidden liberties// meant to mitigate the risks of using a centralized "GBT server" which assigns work to slave ("GBT client") miner nodes.Like I said near the start of this write-up:
GBT's "decentralized" features look pretty toothless and impotent, and further, it really seems as though most of the decentralization in GBT is vaporware and boastful posturing / propaganda...
If I was a pool operator, and if I really wanted to harm bitcoin in any of the above outlined ways, GBT doesn't have in-built mechanisms to empower miners to help safeguard the bitcoin network, to be able to mine in a way which best suits their own personal conscience or aspirations, to exercise their liberties of free speech in the form of their "
vote by hashpower" voices as miners, or to combat any potential pool-operator abuses on an "
actually, literally, by-definition CENTRALIZED" bitcoin mining pool such as the flagship pool supporting GBT mining protocol, eligius.
... the power (
and potential for abuse) held by centralized pool operators is no less dangerous just because "
GBT exists, and a handful of miners are willing to waste extra bandwidth and CPU cycles just to use it"
Here are ways in which p2pool is decentralized, but GBT is not (
despite any of luke's propaganda you might've been suckered into believing)
p2pool by its very design, already requires each p2pool node to have zero-trust access to the bitcoin network (
as described above in *mempool*)
P2pool does not use a centralized server to issue work. That's already more decentralized than slave-mode "GBT client" mining...
The p2pool decentralized "pool" (
a p2p network in its own right, same as bitcoin) only requires participating nodes to follow a single rule in order to get paid for their "proof of work" shares by p2pool:
If the submitted proof of work credits the pool, this valid proof of work is counted as a share, and so p2pool will FIFO-style (
first-in / first-out) add that share to the p2pool sharechain, a decentralized list of addresses which need to be paid (
PPLNS style) by any p2pool node which finds a block (
and a share continues to be paid by the p2pool network until that share drops out of the fully distributed / replicated / decentralized p2pool sharechain due to the way in which outdated PPLNS sharechain entries age gracefully, and ultimately expire)
... if the "work" done by the node meets the bitcoin network "difficulty" target, the newly found block is then directly broadcast to the bitcoin network, and quickly becomes part of the bitcoin network's blockchain since p2pool nodes themselves are already connected to the bitcoin network (
p2pool even uses the GBT JSON-RPC function: "submitblock" on the bitcoin node directly connected to that p2pool node... however, for slave-mode "GBT client" miners, there is ZERO requirement in BIP22 / BIP23 for a slave miner to have access to a decentralized bitcoin node)
As per the original topic described in the original post of this thread:
Yes, I feel as though limiting the power of mining pool operators should happen (
even if not by way of reducing the percentage of hashpower held by any one pool)
Additionally, I
STRONGLY support the idea of adding additional functionality to GBT (
or any other protocol, not limited to GBT, up to and including an overhaul of the way bitcoin adds new blocks to the blockchain) to reduce the influence of any one (
potentially abusive) bitcoin pool operator or node, etc. etc. etc.
