Topic: incentivize fragmentation of mining pools to mitigate threat of 51% attack? (Read 1964 times)

To begin with there's no such thing as a good or bad node, or even what a bad miner is.

A consensus failure can not be "managed" by having miners present identification to any degree other than fully or not at all. By introducing any sort of identification you either need a third party (centralization), for nodes to be able to autonomously decide if an identification is real (impossible due to the Sybil problem) or have users each make their own decisions about who to trust (insane). For the latter everybody in the network must make the same decisions about who to trust, or else the chain fragments and consensus is lost anyway. There's only one trick that Bitcoin has for getting around the Sybil problem, and that's literally the whole system of proof of work to begin with.




If there's some sort of majority or supermajority event we just need to accept the fact that the design has failed, there's no neat solution else we wouldn't have Bitcoin to begin with.

I may be guilty of presenting my train of thought in reverse, so let me see if I can correct that.


I think you are throwing the baby out with the bathwater.

Sybil attacks on decentralized distributed systems like bitcoin can be thought of as a disease. Some diseases are easily cured. Other disease, like diabetes, are not easily cured, but nevertheless need to be managed. Sybil attacks (of the type being discussed in this thread) belong to the camp of problems that have no known cure, but still need to be managed if and when they strike.

If you take cryptocurrency seriously, and I assume you do, then you have to envision a time when bitcoin (or some variation) plays an integral role in our economic system. You have to envision the possibility that someday, as unlikely as it may seem, a well funded malicious actor might actually try to pull off a 51% attack. So before The Powers That Be allow bitcoin to grow beyond the baby stages, they are going to ask the bitcoin community what will happen if a serious attack (launched by an enemy in a time of war, for instance) occurs. And I see two ways to answer:

1) Sorry guys, we'd be fucked. We never actually planned for this. We told you from the start: "it's simply a constraint of the system that a majority of mining power is assumed to be honest."
-- OR --
2) We do not have a cure, but we do have a plan to manage this scenario, and here it is.

So the first step in my train of thought is that we need a plan to manage (not cure) the doomsday-scenario 51% attack, and my ambition in this thread is to discuss what that plan might entail. Nothing more. I think if you read this thread carefully, you'll find I have been careful not to overstate what I think can reasonably be accomplished. (IOW I have not said: "and here's the miracle cure for 51% attacks!")

It is hard for me to imagine a management strategy for dealing with a 51% attack that does not involve some element of attaching somebody's real world identities to hashing power, so that we can begin the process of separating friend from foe. Does every miner need to reveal their real-world identities? No, I don't think so. I certainly hope not. So the second step in my train of thought is that some degree of real-world identification must play a role in our management strategy. If any other tractable starting point exists, I would like to hear it.

The third step in my train of thought is that, if this management strategy is going to involve separating friendly nodes from enemy nodes, then to start out, the bitcoin network needs a way to label nodes. That was pretty much my entry point in the OP. I have tentatively suggested that nodes be tracked pseudonymously by labeling them using bitcoin public addresses. I know that this is a long thread and it is understandable if someone skimming may have assumed me to be proposing:

But if you read closely, at no point have I suggested a registration system with centralized oversight. At no point have I suggested abandoning the core tenets of decentralization. At no point have I said that all, or even a majority, of would-be miners must reveal their real-world identification.

The prospect of labeling individual nodes involves problems that must be addressed, notably that:
And I have mentioned two ways to address this problem, but that would be the fourth step in my train of thought. Perhaps we should go in order, starting with step 1. Does anyone vote for telling TPTB that we'd be fucked in the face of a 51% attack and there's nothing to be done? (If no, go on to step 2  ...)

None of the methods you are describing actually do anything to prevent people from using large portions of hash power for nefarious problems. The reason that hash power is used in the first place is simply due to that it's impossible to prevent Sybil attacks in this sort of network topography, you need a registration system and oversight which is incompatible with decentralization. If nothing else you run the risk of introducing new weaknesses which can be exploited; for a system like Bitcoin working out what incentives you create is key, and this is greatly hampered by additional complexity.



Bitcoin addresses aren't really tied to anything as such. There's nothing stopping me from making 100 million of them a second and pretending that they are all individual. If anything it's actually worse than an IP address, which has some inherent cost for the vast majority of people.




You have misinterpreted the use of IP addresses in P2Pool, they are irrelevant as far the rewards and even the miners in the system are concerned. P2Pool would function the same by Royal Mail as long as you could get the latency down to a small fraction of the block time. The pages you are looking at is just a side effect of the network needing to have exposed ports to work, this is the same for Bitcoin and every other peer-to-peer system.

The share chain deals with Bitcoin addresses, it's almost completely a scale model of Bitcoin with a 30 second block time. As such you can attack it in the same way you can the Bitcoin network, with a majority of the hashrate taking all of the block reward if desired. P2Pool is a very neat concept but it doesn't really solve any problems to do with people have large portions or even a majority of the hash rate.





I feel you aren't looking at this from quite the right perspective. No matter what you attempt to achieve with convoluted ways of trying to split up hash power the result is always going to be the same, it's cheap or entirely costless for an entity to appear to be one or more people.

If you attempt to tie hash power to identities you face a horrible task of trying to verify that people exist to a decentralized network, that they control a certain amount of hash power all of the time, and that they're not all just going to work together to attack transactions anyway (which is frankly, impossible). Even if all this was somehow achievable, why not just forget the mining nonsense and give them direct control? You get the same end result.



Believing that there is a "solution" to this waiting to be found is somewhat of a problem in itself, it's simply a constraint of the system that a majority of mining power is assumed to be honest. Any further layers of complexity just add attack surface and centralization.

I should perhaps add that when I think of potential attackers, I have two categories in mind, the "single voice" attacker or the "many voices" attacker.

The "many voices" attacker is typically a large mining pool, made up of a multitude of disconnected miners -- the "many voices." Entry and exit is fluid and potentially subject to fluctuations. In my imagination I think of GHash.IO from however many months ago.

For the "single voice" attacker, I'm thinking of a situation where one actor -- wealthy individual, corporation, government -- actually owns all of the mining equipment in question. In my imagination, I think of some totalitarian regime secretly building a gigantic city of ASIC miners and suddenly, unexpectedly unleashing them all at once to take over the network.

The many voices attacker is less threatening than the one voice attacker (were a one voice attacker ever to exist), because miners would (probably) quickly and decisively flee a pool if its managers were to attempt an actual attack. Nevertheless, the perceived threat is damaging to bitcoin's public image.

The step 1 that I summarized in my previous post is designed to neutralize a "many voices" pool (cause it to fragment into individual (unconglomerated) nodes; the act of conglomeration renders each node in the conglomerate susceptible to defection by other nodes in the conglomerate), but is not designed to neutralize a "single voice" pool (which will remain visibly conglomerated, because it is financially advantageous to do so). At the very least, this will tell John Q Public when to be alarmed and when not to be. (Large conglomerate = alarmed; otherwise, not alarmed.)

Summary of my brainstorming so far, before time for me to go to bed:

Step 1: Alterations in the reward structure with a purpose of establishing economic incentives that should result in the bitcoin network congealing into approximately N independent nodes, individually labelled (pseudonymously), with any two nodes having approximately equal hashing rate (except for underpowered sham nodes), where N can be set to any desired value (100, or 1000, or variable depending on total network hashing power, or whatever). The nodes are further incentivized to organize into conglomerates. However, large conglomerates would be prone to fragment into smaller ones (achieved by setting them up for a prisoners dilemma) unless they were truly controlled by a single actor with a very firm, full control over every node in the conglomerate. Therefore, the number of large conglomerates is a good measure of the number of independent powerful actors engaged in mining, and also a good measure of how much hashing power each powerful actor controls. It would be possible for one actor to divide one conglomerate purposefully into multiple smaller ones, so that a single large actor appears to be multiple small ones, but this would come at a significant economic cost, and the only reason to pay this cost would be if you were a malicious actor planning an attack and trying to fly under the radar. It would also be possible for a small actor to set up multiple nodes in one conglomerate and appear to control more hashing power than is actually the case, but this would be expensive and would be unlikely to fool anyone for very long (nodes that never or rarely find a block are probably sham or underpowered nodes). These alterations would (I think) require a change in the bitcoin protocol, making a side chain possibly the most reasonable vehicle to try to implement it, although if I could think of a way to do this on top of the protocol, I would. The requisite changes in the protocol would not necessitate any alteration in the overall trajectory toward ~ 21M bitcoins by ~ 2140.

This does not solve the 51% attack problem, but it does do several things:
- it raises the cost of a 51% attack
- it provides a tool: transparency regarding how many independent powerful actors (one actor : one conglomerate) there are and how much hashing power each one has (proportional to the number of nodes in the conglomerate)
- it encourages miners to organize into stable pseudonymous nodes which form the elements of the social network and thereby laying the groundwork for step 2 (which actually may be much more important than step 1 all by itself).

Step 2: Layer a social network system on top of the above system of nodes, in which a small fraction of nodes voluntarily (incentive structure for doing so would need to be developed) identify their real world identities with the vast remainder of nodes remaining pseudonymous, and use the resulting social network backbone to implement a "SybilGuard" [1] type method to carve out malicious nodes in the event of an attack. (I need to learn about the process by which a new miner gains access to the bitcoin network. I think the bitcoin core has a default list of IP addresses where it "looks for the network" but I'm not sure what that means and I'm not sure who gets picked for the honor of being on that list of IPs. And whether that list is customizable.)

[1] http://www.csd.uoc.gr/~hy558/papers/sybilguard.pdf

As long as you can tolerate me going over what is old ground for you I am happy to stay here :-)  

EDIT: I like using this thread for me to develop and record my thought processes; and I would prefer knowledgeable people to provide input rather than "open minded" but less knowledgeable or informative. By guidance, I don't mean doing my homework for me, just pointers here and there if, for example, I'm trying to reinvent what someone else has already tried to invent, successfully or otherwise. I've followed several of the links you guys have showed me and will look at others -- including another read through Satoshi's original paper, I promise! 


Ahh yes. Sounds like as good a target as any for me to shoot for.


I had never looked into P2Pool before but I like the concept. Basically, iiuc, by adding to the share chain, miners are able to demonstrate PoW in smaller chunks, even if their work does not result in a bitcoin block, which is much more difficult to generate.

Despite what we've discussed in this thread, it looks like P2Pool servers are identified by IP addresses, like here:
http://p2pool.hostv.pl/
and that individual miner nodes reuse their addresses (pitfalls of address reuse notwithstanding), such as this one here:
https://blockchain.info/address/1BnbYeLnz5Cpry6H7NRwgV5pofkEXokac8
which is the address corresponding to what looks like the most powerful miner in this pool:
http://mine.p2pool.com:9332/static/

So far I still like the idea of using bitcoin addresses for node identification, but not necessarily the address that is used for payouts (like apparently P2Pool miner nodes use). And not attached to IP addresses (like apparently P2Ppools use).

I don't have an issue with this particular discussion being in this board.  I understand that you're trying to better understand how the Bitcoin mining and and distributed consensus process works, and you're hoping to discover improvements to the process.

However, if you feel that the participants in the alt-coin board are more open-minded, innovative, or more willing to "Brainstorm" with you then you can move it there yourself.  There is a "move topic" link at the very bottom left corner of the thread (right next to the "lock topic" link).

I don't know, that would be up to a mod, but if it is a technical discussion that relates to Bitcoin, I'm not sure if it needs to be even if the majority of the end result only would be applicable to an alt coin. Once side chains are active it could be part of a side chain for example.

I'd be happy to have this moved to a different board if appropriate.

Exactly! IPs would be a nightmare. Which is why my current thought is to use a pseudonymous bitcoin address for identification (distinct from the addresses used for payouts), and to make it economically advantageous for a node to pick one and not change it over time

In general IP address for peer ID is a bad idea.  For example, running over tor, proxies, running with IPv6 (eventually) when IPs will be quite plentiful and could essentially be switched every hour or whatever etc.  IDs in a p2p system without a central authority are problematic.   ;-)

As far as IDs, check out what DannyHamilton said, and take a look at the bitcoin paper pdf he linked to.  There are a lot of technical details you'll discover.  There is a lot to read and absorb to understand how bitcoin works and why some changes would be unlikely to occur in anything but an alt.

If this is impossible then my scheme would require some other identification method, e.g. generation of a bitcoin address used specifically for node identification purposes.

EDIT1:

Thanks for the various links. I've never heard of goldcoin but it looks like they make use of IP address for peer identification:

I would prefer using bitcoin address for identification (of a node, in my case) because of its pseudonymous nature. Nodes would have the ability to change identities as often as they want but would be incentivized to maintain a stable pseudonymous identity. The bitcoin address used for node identification would not necessarily be the same address used for payout.


There are two defenses that I would envision against Sybil attacks: the first is the "ante" I described in earlier posts (in the form of small PoW and/or some small amount of bitcoin required before contributing a block), thus raising the cost of launching a Sybil attack; and the second is to harness a social network layered on top of the mining network. According to this idea, nodes would have the option (and only a very small percentage of nodes would do this!!) of making known their real-world identities. If the network were to be the victim of a 51% attack, then the bad actors could be forked away from the good actors, with the social network providing the backbone for the "trusted" fork; the pseudonymous nodes could choose which fork they wished to follow (eg, the one with the greatest number of nodes controlled by real-world trusted entities, or the other one. This method assumes that the majority of your trusted nodes do not join China or EvilCorp XYZ in their bid to take over the network.) (At first glance, this paper in the footnotes to the wikipedia article describes something similar to what I am thinking: http://www.csd.uoc.gr/~hy558/papers/sybilguard.pdf although I have only skimmed the paper briefly.)

EDIT2:

The idea would be to keep the 21M limit that is projected to be attained in 2140 and to stay on the same schedule. Rewards would be reshuffled based on a few rules but not in a way that changes the final total or the general trajectory. (Bear in mind I am brainstorming!! ...)


I have read the whitepaper maybe twice since I discovered bitcoin in 2011 and make no pretense that I grokked all of it. I make no pretense that I am smarter than all the people who do this full time. Getting comments like those in this thread helps me know where to focus my energy and I am appreciative.

Nodes can (and should) use a new destination address for every block reward.  Additionally, some pools pay out the block reward directly to their participants, so the block reward transaction has many addresses.


Which would be impossible to enforce.  There'd be know way of knowing if a node used a new address or not.  Furthermore, address re-use is a bad idea and should be discouraged.


If you are trying to design anything related to bitcoin and you haven't read the bitcoin whitepaper, then you are wandering in a dense dark forest with your eyes shut.  You're just going to keep bumping into trees and hurting yourself.  Take the time to read it, then take the time to ask questions and make sure that you really understand both the original whitepaper as well as the final design of bitcoin (which has some significant differences from the original whitepaper).

https://bitcoin.org/bitcoin.pdf


You're talking about giving a bigger (or smaller) reward as incentive or punishment for individual blocks.  That is a change in the inflation schedule.

I am just trying to solve an interesting and significant problem. I have no aspirations to create an alt-coin of my own. I'd be happy for anyone to implement it as they see fit -- bitcoin, some alt coin, whoever wants it. But of course it is premature for me to speculate who might want to implement something that I am still merely brainstorming. Ultimately you may be right that my scheme would require drastic changes to the bitcoin protocol and would only be feasible for an alt, but I would strive to require as few changes to the existing bitcoin protocol as are absolutely necessary.


Perhaps the destination address of the block reward could be used as a proxy to distinguish different nodes? This would require reusing the same destination address so an individual node could maintain its identity over time. (Of course this requires that a single node has an incentive to maintain a recognizable identity that is stable over time, and that is the whole point of my scheme so far. I need to learn more about the structure and inner workings of the blockchain to know if any of this makes sense and I apologize if this is coming out as nonsensical blather ... ).

Also, I would strive not to change the inflation schedule. Perhaps the extra reward I am talking about could be carved out of the existing reward?? ...

OR: perhaps the ante would involve, not only a PoW, but also a small payment in bitcoin, and that is what is used to fund my whole scheme. No change in the inflation schedule necessary!

This is the part you are not catching on to that we've been trying to explain to you.

Nodes are not identified.  There is no centralized control that can identify anything about a node at all.  The network is entirely peer-to-peer.

When you hear about a block, you only know who relayed that block to you.  You have no way of knowing if the node that relayed it to you is also the node that generated it, or if they are just passing on a block that they received from someone else.


There is no way that any of this is going to be implemented in Bitcoin.  It would be nearly impossible to get a consensus on such a scheme (identifying nodes, changing the inflation schedule, etc).  I assume at this point, you're trying to design a Bitcoin replacement alt-coin?

Fleshing it out:
- require each individual node to provide an "ante" PoW before it is allowed to contribute a block. For example, require it to provide a hash of a previous block (must be a recent block, so the ante must be repeated periodically) + the node ID (and I need to learn how different nodes are identified -- I assume they have some sort of id?). This will make it expensive to operate lots of nodes and provides an incentive for an individual to group hashing power into fewer nodes.
- Each node gets a reward per ante, but only after it contributes a block.
- The reward diminishes (according to some preset function) if any one node contributes more than, say, 1% of the last 1000 blocks. This is what makes it profitable to fragment any node with more than 1% hash power into multiple nodes.
- It is permissible for one node to provide the PoW for multiple nodes by including the node ID into the hash. This is how multiple nodes form a conglomerate. The reward is distributed equally among all nodes in the conglomerate only after one of them adds a block. There is a time delay: the reward is distributed only after the block is, say, 50 blocks deep.
- At any point in time during those next 50 blocks, each node in the conglomerate has the opportunity to "defect." The first node to defect gets half of the total reward; the rest of the nodes get absolutely nothing.

Result: an individual mining pool with, say, 30% of the network will optimize earnings by running 30 nodes and placing them all within one conglomerate.

If N different loosely affiliated individuals, each of whom controls one node, decide to form a conglomerate, then the odds are that one of them will defect and destroy the conglomerate.

Here is my brainstorming so far:

At any given point in time, the total hashing power of the network can be estimated from the difficulty level and the block generation time.

The first goal in setting up this scheme is to design a system that will encourage a pool owner to fragment hashing power into individual nodes of some fixed percentage of the network -- let's say 1%. That means that the pool owner who controls 10% of the network will optimize earnings by running 10 nodes.

The second goal is to design the system so that disparate nodes can earn more if they cooperate as a conglomerate in some (transparent) fashion; but, defection from the conglomerate is highly rewarded (with the reward getting more and more tempting as time goes on). Therefore, the only way to make a conglomerate is to be under tight control. Loose conglomerates will quickly fall apart.

Therefore, the number of pools is the number of conglomerates, and the power of each pool is the number of nodes within each conglomerate.

As a miner, one could easily send 10% of your hash power to each of the sub-pools, with a switchover at say at midnight UTC on one day to avoid the penalty.  Or, even easier, the pool operator could divide the hashes coming in 10% to each sub-pool and switch over all at once so. The miners would get the same reward.  ;-)  (It is a tough problem!)

The key is that without some type of central authority there is virtually no way to know who is part of what pool IF the pool/pool operator were attempting to hide it.

Some useful links if you haven't seen them:
https://en.bitcoin.it/wiki/Pooled_mining
https://en.bitcoin.it/wiki/Mining_pool_reward_FAQ
https://bitcointalksearch.org/topic/1500-th-p2pool-decentralized-dos-resistant-hop-proof-pool-18313
https://en.bitcoin.it/wiki/P2Pool

The idea would be to make a Prisoner's Dilemma that would encourage defection. This would not work if you were one person who owned all 10 pools; but if the 10 pools were a loosely-maintained conglomerate, then the conglomerate would fall apart because the first group to defect from the conglomerate would get some sort of reward at the expense of the rest of the conglomerate.

That's a good question. For this idea to work, there needs to be, first of all, a way to identify individual pools and know how much hashing power they have. I'm a newbie when it comes to the technical details of mining and there is a lot I need to learn before I can make a more detailed proposal. Despite my newbishness, I'm sure there's got to be a way to come up with something workable. (Or if not, at least I'll have fun trying   )

My first newbie question: Do mining pools generally operate as a single node, or multiple?