Peter Todd: Why I just sold 50% of my bitcoins: GHash.IO
-
tl;dr: GHash.IO shows that the economic incentives behind Bitcoin are probably very flawed, it might take a disaster to get the consensus to fix it, and if that happens I want to make sure I can pay my rent and buy food while we’re fixing it.
Bitcoin developer Peter Todd is selling half of his coins because GHash.IO is approaching 50% of the hashrate.
I have said many times that the incentive engineering within Bitcoin was the one part that Satoshi was most unsure of and probably needs the most attention. I think of all the coins out there Feathercoin has probably done more to try and address this than others particularly as our founders were miners themselves.
Peter’s points are:
-
Eliminate pools.
-
Provide a way for miners to solo-mine with low varience and frequent mining payouts even with only small amounts of hashing power.
-
Get rid of ASICs.
CEX.io have made a tweet indicating they are aware of the problem and stating that their intention is not to gain 51% of the network. There is this article in Coindesk in anticipation of a formal statement.
In other mining news we have had an incident of selfish mining at Eligius Mining Pool. One of the oldest Bitcoin mining pools is refusing to pay one of its members because they claim the individual was involved in a block withholding attack.
This forum has some of the smartest people around and I would like to hear your thoughts. I would also to know if anyone has a view on the Nothing at Stake problem with PoS coins.
-
-
Feathercoin is already “dealing” with 50% problems. This 50% network pools for Bitcoin shows that being the big fish doesn’t fix those problems. I still think the scrypt ASIC compatibility might not be the worst option for Feathercoin. Missing the ASIC boat but still being susceptibility to big actors would be worse.
However, Feathercoin would have to do something to develop a distributed set of ASICs to prevent take over of the network by big actors. This could be done by open hardware development of a combined “Merchant solution” which included an ASIC miner set up.
This could give the wider distribution of small miners that is needed for a secure long term system and be something merchants could easily set up.
-
I like the idea of distributed ASIC via the merchants. I’m guessing we currently wouldn’t have enough POS merchants though?
-
Pure PoS can be abused even easier than pure PoW. Gavin Andresen is correct in general: one may produce any reasonable number of PoS blocks using a single valid stake kernel, thus DDoS’ing the network and confusing the other miners. The whole concept of generating a PoS block upon spotting a “lucky” time stamp (the other data used for hashing is static for a particular input) is flawed, but it keeps PoS very energy efficient.
-
Peter’s points are:
-
Eliminate pools.
-
Provide a way for miners to solo-mine with low varience and frequent mining payouts even with only small amounts of hashing power.
But how to do it without one hidden central mega pool?
-
-
We need a new PoS with energy efficient and safe and fair .
-
We need a new PoS with energy efficient and safe and fair .
-
Is there anyway to limit the amount of hashing from say one IP through the check pointing, or would that be unfair on a network?
Surely along those lines may limit pool %'s unless everyone is on one pool, which IF the pool owners were ethical in the first place, they would split their miners to multiple pools would they not?
We are all aware of how much damage these new asics are capable of and I understand the need for changing the alogorythm, but instead of that, is there no way just to cap it?
Sorry, you guys are far more clued up than I am. So apologies if it sounds like a stupid question, but if I don’t ask, I’ll never learn
-
Well, if you limit the hash % per pool, the owners of the large pool simply could split their pools in to several smaller pools. These would not reach 50% of hashrate, but the owner still would control more than 51% of total hashpower.
He probably would not be able to do a 51% attack but could still get a mining advantage, if he does multicoin mining and hopping in and out at will.
This alone created some problems in the last months
-
However, Feathercoin would have to do something to develop a distributed set of ASICs to prevent take over of the network by big actors. This could be done by open hardware development of a combined “Merchant solution” which included an ASIC miner set up.
This could give the wider distribution of small miners that is needed for a secure long term system and be something merchants could easily set up.
I have always loved this idea. And you said to me ages ago that what we needed was some open source hardware, maybe that’s the next step and what’s stopping this industry from moving forward is the proprietary nature of the mining equipment itself.
-
Gavin Andreson just made this comment on the Bitcoin Foundation Blog:
Even if GHash.IO is evil and intends to destroy Bitcoin they would be able to do only two things:[/size]
The first thing they could do would be to double-spend already confirmed transactions. For example, they could send some bitcoins to an exchange, trade them for dollars, wire the dollars to their bank account, and then announce a longer blockchain where the transfer to the exchange never happened. Now they have dollars and bitcoins.Incorrect. They could send the bitcoins to Cryptsy trade them for litecoins, send the litecoins to BTCe and trade them for dollars.
There are many things to say about this blog post in general and many of them are already addressed here on Reddit.
-
Is there anyway to limit the amount of hashing from say one IP through the check pointing, or would that be unfair on a network?
Surely along those lines may limit pool %'s unless everyone is on one pool, which IF the pool owners were ethical in the first place, they would split their miners to multiple pools would they not?
We are all aware of how much damage these new asics are capable of and I understand the need for changing the alogorythm, but instead of that, is there no way just to cap it?
Sorry, you guys are far more clued up than I am. So apologies if it sounds like a stupid question, but if I don’t ask, I’ll never learn
This occurred to me as well. Surely this would be the simplest solution to implement. Each connection to the block chain is limited in khs. As I don’t know the mechanics behind things as Flodbeth mentioned there may very well be a way to limit individual connections somehow which by default would avoid a 51% attack.
-
This occurred to me as well. Surely this would be the simplest solution to implement. Each connection to the block chain is limited in khs. As I don’t know the mechanics behind things as Flodbeth mentioned there may very well be a way to limit individual connections somehow which by default would avoid a 51% attack.
I would like to hear what other people have to say but I suspect it would be easy to work around by spoofing IP or using tor nodes. It would end up being advantageous to those enterprising enough to find a way around it.
At the moment we have an asymmetry of information and value that we seem to feel the need to redress. That those favouring the short term are taking more as a proportion of their input than those who are taking a longer term perspective. It may well be that the incentives in Bitcoin are simply flawed and that we have to start again. The reason being that there seems to always be people who will put in the least amount of effort for the maximum amount of reward and then switch to a new upward trending market once they have finished fleecing that one; rinse and repeat. Then we end up living in a world where we measure success by the rate of change which then leaves behind an ever increasing number of people as they fail to keep up. I’m not saying that’s bad, I’m not saying it’s good either I am just describing what I am seeing.
I have not arrived at a final conclusion and would be willing hear what other people think.
-
Any IP address based limitation could be easy worked around by using a tor network or spoofing IP adresses.
We could try to limit the access to the blockchain based on the wallet address announcing a new block, e.g. each address can announce a new block every 2 minutes only.
This would mean a higher load on each wallet connected to the chain and also could be bypassed easily by using another address for each found block. It also would reduce overall network performance.
I don’t see an easy way to limit the connection to the block chain
-
This also just shows that changing the Hashing Algorithm, no matter how rare, doesn’t solve the large actor problem. There will always be the “biggest pool” for each coin or hashing algorithm. A big actor, with big bills, will tempted to mine the easiest coin or switch off mining when a coin’s difficulty is high.
One answer would be to encourage that biggest pool to be p2pool. Maybe a p2pool node set-up could be included with the Merchant POS / coin Network connection - solution.
The fact that there are no passwords or registration, makes p2pool an easy to assemble component of an open Merchant POS backend.The fact that it creates a higher level mining connections with the latest blocks , also means faster transaction times and increase connect ability.
Who is safe from the large actor problem?
I used to think that Bitcoin was safe from the difficulty manipulation from bad actors - as long as it had an “increasing hash rate” - the bad actor was always mining at the lower difficult, as it is always about to go up - so was incentive to remain mining (and switch off later)
However, I now see that, if the Hash rate increase is less than the % of the hash rate a large bad actor has. That bad actor can cause a variation in the hash which can be exploited to be always mine at a lower hash difficulty - than all other miners.
One can see that the temptation, where the short term gain might wipe out your investment, and you don’t care if Bitcoin goes bust, you’re already quids in… For someone who’s into making money and doesn’t care about community, its a no brainer.
