BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 02:28:30 AM Last edit: November 18, 2013, 02:40:08 AM by BitThink |
|
One of the main reasons why people love BTC is that they think BTC is democratic and nobody can damage it since it is protected by millions of users. Call me stupid if you want cause I feel quite unconformable now when I realized just 3 to 5 persons (the operators of BTCGuild, GHash, Eligius, BitMinter, and Slush. See https://blockchain.info/pools) can effectively damage the who ecosystem. One example is the current proposal of Luke Jr (see https://bitcointalk.org/index.php?topic=334316.0). Yes, this time that patch may be not so harmful and you happen to side with Luke. But eventually you may disagree on other more serious issues but you have to put all your trust on that 3 to 5 operators. Could we do something in the protocol, so that no mining pool could exceeds 5% of the market share and bring back BTC to be real decentralized again?
|
|
|
|
defaced
Legendary
Offline
Activity: 2198
Merit: 1012
Franko is Freedom
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 02:46:38 AM |
|
The one word no one wants to hear "Regulation".
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 03:13:46 AM |
|
The one word no one wants to hear "Regulation".
More decentralization means 'less regulation'.
|
|
|
|
kuzetsa
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 06:08:28 AM Last edit: November 18, 2013, 05:19:05 PM by kuzetsa |
|
p2pool is decentralized, and so it would be particularly hard to restrict if it ever got big...
but at the same time, each and every p2pool node is pretty much free to run or not run whatever sort of crazy patches for transaction-restriction / inclusion rules they want to use (or even just stick with defaults... it's really a matter of whoever configured it on a per-node basis 'cause that's how p2pool works)
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 06:16:06 AM |
|
No. It isn't just tx which are psuedo anonymous, NODES are also pseudo anonymous. Generally in decentralized networks this brings up a problem called the sybill attack. https://en.wikipedia.org/wiki/Sybil_attackSay there are 50,000 nodes. What you don't know is that I personally control 49,900 of them. Not very decentralized huh. To the network all the nodes appear as equal peers but in reality a super majority are controlled by me. Given the low cost of running a node security can't rely on majority of nodes. It would be easy to circumvent. Bitcoin sidesteps this problem with the proof of work. A hash is a hash that is all that matters. 100 TH/s from a single node is no different than 1 TH/s from 100 nodes. If such silly measures were attempted pools would simply operate out of multiple nodes or split into multiple virtual pools (where miners are transferred from virtual pool to virtual pool automatically to load balance). Still topics like this make me wonder why so many people fear free markets. Luke has miners because he built a pool and people saw value in it. If in the future they don't see value in it the share of his pool will decline. Case in point take a look at DeepBit. At one time people feared DeepBit would 51% the network. Seems quaint now.
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 07:52:25 AM |
|
No. It isn't just tx which are psuedo anonymous, NODES are also pseudo anonymous. Generally in decentralized networks this brings up a problem called the sybill attack. https://en.wikipedia.org/wiki/Sybil_attackSay there are 50,000 nodes. What you don't know is that I personally control 49,900 of them. Not very decentralized huh. To the network all the nodes appear as equal peers but in reality a super majority are controlled by me. Given the low cost of running a node security can't rely on majority of nodes. It would be easy to circumvent. Bitcoin sidesteps this problem with the proof of work. A hash is a hash that is all that matters. 100 TH/s from a single node is no different than 1 TH/s from 100 nodes. If such silly measures were attempted pools would simply operate out of multiple nodes or split into multiple virtual pools (where miners are transferred from virtual pool to virtual pool automatically to load balance). Still topics like this make me wonder why so many people fear free markets. Luke has miners because he built a pool and people saw value in it. If in the future they don't see value in it the share of his pool will decline. Case in point take a look at DeepBit. At one time people feared DeepBit would 51% the network. Seems quaint now. I think you are too hasty to argue with others. Actually what you saying here exactly supports what I proposed. Sybil Attack is harmful because 'one person has too much influence on the p2p network', and that's exactly what a big pool operator can do. 'Prove by Work' avoids someone to create a large number of nodes, but cannot prevent someone from creating a pool and attracts a lot of other nodes to contribute hash rate and becomes essentially same as Sybil Attacker. One thing you said is correct. The current pool operator could create tens or hundreds of pools if there's some restriction on pool size. So restrictions on pool size does not eliminate big pools, but at least increases their difficulty. Monopoly is not free market. You may think miners can easily switch pools so it is still a free market even there're only 3 - 5 big pools. This, however, is not true. It's only true if every bitcoin user has equal power of hashing and miners are all bitcoin users care about the future of BTC. Now, however, hashing power belongs to some professional miners or miner companies, who do not care the bitcoin user's benefit at all. Therefore, no free market here. DeepBit is pulling down by DDoS attack, not because miners leave there voluntarily. BTCGuild does not excceed 40% because their own discipline, not because the miners leave them voluntarily. Most large scale miners now only care about profit, not the future of BTC, since they are not necessary BTC believers, but mostly profit hunters.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 07:58:56 AM |
|
This is why decentralised mining is so important. When I finish GBT, pools won't have nearly as much influence as they do now.
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 08:13:09 AM |
|
This is why decentralised mining is so important. When I finish GBT, pools won't have nearly as much influence as they do now.
Thanks, Luke. I will read BIP 22 and BIP 23 carefully. Currently I am curious how you find a balance between giving back block creation right to the miners and avoiding selfish miners to hide the blocks they find for themselves. I am sure I can find answers in 2 BIPs written by you.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 08:31:53 AM |
|
This is why decentralised mining is so important. When I finish GBT, pools won't have nearly as much influence as they do now.
Thanks, Luke. I will read BIP 22 and BIP 23 carefully. Currently I am curious how you find a balance between giving back block creation right to the miners and avoiding selfish miners to hide the blocks they find for themselves. I am sure I can find answers in 2 BIPs written by you. The miners still send the pool a proof-of-work including proof the pool is being paid for the reward.
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 09:46:04 AM |
|
This is why decentralised mining is so important. When I finish GBT, pools won't have nearly as much influence as they do now.
Thanks, Luke. I will read BIP 22 and BIP 23 carefully. Currently I am curious how you find a balance between giving back block creation right to the miners and avoiding selfish miners to hide the blocks they find for themselves. I am sure I can find answers in 2 BIPs written by you. The miners still send the pool a proof-of-work including proof the pool is being paid for the reward. I mean if the miner gets enough data and happens to find a block himself, he may choose to publish it himself instead sending back to the pool. Maybe a silly question since I have not read the BIPs carefully yet.
|
|
|
|
kuzetsa
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 05:13:57 PM |
|
This is why decentralised mining is so important. When I finish GBT, pools won't have nearly as much influence as they do now.
The miners still send the pool a proof-of-work including proof the pool is being paid for the reward.
Isn't the thing you're describing basically just a less-decentralized version of what p2pool already does by its very nature? ( and p2pool even manages to do GBT correctly from a python script, but without 100% cpu load at relatively modest hashrates) Reference:I am using the version 3.4.0 BFGMiner that is distributed as part of Bertmod 0.3 on my KnCMiner Saturn. I added the lines: "coinbase-addr": <my payout address>, "coinbase-sig": <My block sig>
to the end of the config file, because I wanted to solo mine on my local bitcoin-qt. It doesn't generate any errors, but the hashrate goes down from ~285 GH/s to more like 10 GH/s ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) If I remove the above two lines, it goes back to normal. Anybody have any idea what is going wrong here? Is it using 100% CPU, or less? I wonder if the BBB can't keep up with generating work via GBT... Yeah, looks like that's it - always over 95% CPU when GBT is enabled, ~22% otherwise. Bummer.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 05:18:39 PM Last edit: November 18, 2013, 09:27:19 PM by DeathAndTaxes |
|
I mean if the miner gets enough data and happens to find a block himself, he may choose to publish it himself instead sending back to the pool. Maybe a silly question since I have not read the BIPs carefully yet.
The reward tx is part of the block. I always find it humorous when people believe they need to change Bitcoin in order to save it yet have not even the most basic understanding of Bitcoin at a technical level. When a miner solves a block he is finding a nonce that when ADDED TO THE REST OF THE BLOCKHEADER and hashed produces a hash below the target. The blockheader contains the merkle root hash. The merkle root hash is a hash of all tx in the block. One of the tx in the block is the coinbase tx. It doesn't matter who broadcasts a block the reward is tied to the block created. Changing anything in the block will result in new hash thus the "solution" (nonce resulting in hash below target) is tied to a particular block's values.
|
|
|
|
kuzetsa
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 05:31:10 PM |
|
When a miner solves a block, they are finding a nonce that when ADDED TO THE REST OF THE BLOCKHEADER and hashed produces a hash below the target. The blockheader contains the merkle root hash. The merkle root hash is a hash of all tx in the block. One of the tx in the block is the coinbase tx.
It doesn't matter who broadcasts a block the reward is tied to the block created.
Right, you can't edit the work after you already completed it, that would change the hash. The current version of p2pool checks to make sure any submitted work credits p2pool, and only if the submitted work pays p2pool ( in the coinbase transaction) does the work / share submitted get added to the p2pool sharechain ( which ultimately contains the list of who needs to get paid whenever someone manages to find a proper bitcoin block) The p2pool node to find the block then transmits the block, because it doesn't matter who broadcasts it. ( This block will credit p2pool, as well as whichever transactions the node operator configured to include or not include, depending on their preference for fee & blocksize configuration, or any patches installed, etc.)
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 18, 2013, 08:31:54 PM |
|
Isn't the thing you're describing basically just a less-decentralized version of what p2pool already does by its very nature? GBT is just as decentralised as p2pool. And unlike p2pool, GBT doesn't require the overhead of p2p. (and p2pool even manages to do GBT correctly from a python script, but without 100% cpu load at relatively modest hashrates) Good luck getting p2pool to work in KnC BBB hosts...
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 19, 2013, 05:52:17 AM |
|
I mean if the miner gets enough data and happens to find a block himself, he may choose to publish it himself instead sending back to the pool. Maybe a silly question since I have not read the BIPs carefully yet.
The reward tx is part of the block. I always find it humorous when people believe they need to change Bitcoin in order to save it yet have not even the most basic understanding of Bitcoin at a technical level.When a miner solves a block he is finding a nonce that when ADDED TO THE REST OF THE BLOCKHEADER and hashed produces a hash below the target. The blockheader contains the merkle root hash. The merkle root hash is a hash of all tx in the block. One of the tx in the block is the coinbase tx. It doesn't matter who broadcasts a block the reward is tied to the block created. Changing anything in the block will result in new hash thus the "solution" (nonce resulting in hash below target) is tied to a particular block's values.Thanks for your explanation. Yes, who owns the block is decided by the coinbase tx, not who broadcasting it. So in GBT, the pool just checks whether the coinbase tx is correct and don't mind what other transactions are included. Each miner can choose other txs by themselves right? Your reply is great and will be greater if there's no sentence like that. I am not the person who believe they need to change Bitcoin in order to save it. I am a person who believe Bitcoin needs to be changed by someone who knows more than me (note 'could' in my title). Besides, I admit it may be a silly question in advance. But thanks a lot anyway for your explanation.
|
|
|
|
kuzetsa
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 19, 2013, 06:10:54 AM |
|
srsly, luke... Why you gotta go bringing up GBT again? The stuff you tried to claim just now is kinda ... well.... A fact-based " not talking out my ass" rebuttal follows: -- Part 1 of 3 -- And unlike p2pool, GBT doesn't require the overhead of p2p.
What the fuck are you even talking about? Are you saying that you feel like the decentralization ( the p2p part) of p2pool is somehow inconvenient? - 1) The pool (described in BIP22 as "server") which gives out work via GBT is a single point of failure:
Where / which exact section or wording in BIP 22 is there any language OTHER than "server" which clearly describes how the GBT JSON-RPC call is to be used for " not-using-a-centralized-server, and therefore, by definition literaly decentralized" mining? ( as an aside, modern p2pool uses GBT under the hood when communicating with bitcoind, despite the fact that p2pool was around in 2011 nearly a full year before GBT BIP 22 was even drafted) Isn't it true that for a "client" ( miner which mines via GBT protocol) the "server" ( mining pool, so let's just say "eligius" as an example) being used by that miner is a centralized, single point of failure? If a single p2pool node goes down, it's not centralized, so it doesn't act as a single point of failure and prevent every other p2pool node from being usable for mining.
|
|
|
|
kuzetsa
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 19, 2013, 06:11:59 AM |
|
-- Part 2 of 3 -- Isn't the thing you're describing basically just a less-decentralized version of what p2pool already does by its very nature? GBT is just as decentralised as p2pool. What's all this rubbish about GBT being decentralized AT ALL? What are you even claiming? - 2) BIP 22 client / server protocol claims that the blocks are (quote) "left to the miner to (optionally) customize and assemble" and as such, implies that a client (miner) has the ability to customize the selection to their own preferences for which transactions to include into blocks...
This claim in BIP 22 wasn't based in reality. To clarify, I mean to say that the claim was not based on any " actually been implemented" reality ( hypothetical doesn't count) at the time BIP 22 was drafted (February 2012) and even a year later (February 2013) there was still no implementation allowing a miner to view, audit, or modify the list of transactions proposed by the server. The transactions to be processed by the client (miner) might be hypothetically independent from GBT server (pool) input... but... ... the hypothetical process for miner (GBT client) modification of the transactions sent by the pool (GBT server) isn't even explained in BIP 22 Isn't it true that BIP 22 ( GBT specification) never clearly described any straightforward algorithm, technique, process, API call, protocol, or otherwise "usable mechanism" where miners have a non-hypothetical ability to view, audit, or modify the list of transactions proposed by the server? And furthermore, isn't it also true that to this day there is still no GBT implementation which has the required extensions / features to be able to do such things?
|
|
|
|
kuzetsa
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 19, 2013, 06:12:23 AM Last edit: November 19, 2013, 07:21:58 AM by kuzetsa |
|
-- Part 3 of 3 -- Please explain: Since BIP 22 doesn't even describe anything other than a centralized server feeding work to slave worker nodes (miners) ... where is the documented language about any form of decentralization in GBT (BIP 22)? - 3) Additionally, this thread was explicitly created because pool operators could arguably be seen as having have too much power... For example:
What are the basic steps for mining software configuration procedures for a miner ( GBT client) who chooses to mine on eligus ( which supports GBT mining, so theoretically according to BIP 22 this should be possible) to be able to re-add the transactions which were filtered ( because of address reuse) by the pool, so that this miner ( GBT client) is not subject to the whim of the GBT server operator ( pool operator of eligius, namely you, and your filtering overreach and abuse of the powers afforded to you, as being discussed in this thread)
(and p2pool even manages to do GBT correctly from a python script, but without 100% cpu load at relatively modest hashrates) Good luck getting p2pool to work in KnC BBB hosts... Cool story, bro. Tell me more about how your solution to not being able to comfortably run a full bitcoin node on beaglebone embedded hardware is... wait, don't those KnC miners come with a well-tuned, embedded version of cgminer out of the box? What was your point anyway? What is the point of your stupid anti-p2pool commentary / what was that post even about? I was making an observation about the implementation of GBT in p2pool; that is to say, it seems to me that p2pool's GBT implementation actually works quite well, despite being a python script rather than optimized / compiled C code. I know for a fact that a single p2pool node with 30 connections to the p2pool p2p network running on "not awesome" hardware ( 1.3 GHZ "green" cpu rated at 17 watt TDP) only uses about 14% CPU utilization for 6.7 GH/s, and most of that is just the p2p overhead you seemed to be bothered by ... or something ( I'm not sure what the point of that comment was either) Increasing the hashrate would be VERY scalable, and should hardly increase the CPU load on the p2pool node, if it even increases by a measurable amount because the p2pool node is talking to cgminer via stratum protocol, and cgminer itself is using almost no CPU ( it almost doesn't even register) to say nothing of the stratum itself, which is not an inherently high-overhead protocol. As a matter of fact, I know that knc saturn ( WITHOUT that bertmod BFGMiner mod installed) has no problem at all with using stratum protocol, so it could easily talk to the same low-power server which I was using to feed work to a BFL ASIC Jalapeno ( the 6.7GH/s miner in question) I know some p2pool node operators who have comfortably handled a workload of more than 1 TH/s without the node becoming CPU bound and shitting itself, getting a huge hashrate reduction, etc. GBT is not a bad protocol, but BFGMiner happens to be "not very good" for GBT, despite the fact that the GBT implementation in BFGMiner was written by the author of BIP 22
For a minute, I was half tempted to say "challenge accepted" for testing the p2pool script on a 1ghz beaglebone black, but I don't have one on-hand for testing... it's really not all that much slower than the 1.3ghz "green / power efficient" cpu I have on one of my p2pool nodes (it just happens to also host its own bitcoin node since it has enough ram and disk for that... perhaps connect an external usb hard disk to the BBB? I'll leave that for someone else to figure out)
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 19, 2013, 06:28:28 AM |
|
You really spent 3 posts on trolling and FUD? Amazing.
|
|
|
|
kuzetsa
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 19, 2013, 09:32:49 AM |
|
You really spent 3 posts on trolling and FUD? Amazing.
That wasn't trolling. I was seriously trying to ask real questions about your purpose on this thread. It's not even a new question that you've never been asked about some of this, and then simply refused to give straight answer. It's been more than a year since these GBT "fake decentralization" issues were first discussed, yet you still haven't answered the question posted: So from my view, GBT is wasting resources for no real gain.
That depends on your point of view. As a pool operator or miner with ultimate trust to the pool operator you are right. From the perspective of a miner that cares about what goes into a block it is important to see the complete information. With Stratum, the pool operator is the one that creates bitcoin blocks and makes the rules. The miner is paid for doing some work for the operator. With GBT the pool operator is a work dispatcher but miners create the bitcoin blocks and make the rules. I don't regard more information and control as a waste of resources. ... actually - no - who actually sees what goes into the blocks? The software you mine with decides - and if you use the gbt luke-jr implemented - then luke-jr decides for you ... Did you read the gbt code he wrote when you mined with his BarbieMiner? You wanna say something is wrong with GBT? Proof? To correctly state your question: What are the rules that BarbieMiner uses to select the transactions to put into the GBT blocks? No doubt you don't already know what they are ... without at least first looking them up now ... You see the point of my statement? Edit: and to add to that ... once you finally bother to look up and learn what rules he uses, do you know how to change it to suit what you think it should be? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
Basically the same as my bulleted point #3 ( in part 3 of 3, from a couple posts back) You have chosen not to refute the statement that: By simply using GBT protocol to mine, a miner is not magically able to re-add the transactions which were filtered out by the eligius (or other) pool operator. There is still not even a working "proof of concept" implementation for a GBT client which is able to do this. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FzkCGWc3.png&t=665&c=kekYkleJBKhOgw)
|
|
|
|
|