incentivize fragmentation of mining pools to mitigate threat of 51% attack?

[½]

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.

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

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.

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

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.

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

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.

This does not solve the 51% attack problem, but it does do several things:

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.

[1714614471]

1714614471

[BTCtrader71]

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

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.

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:

a registration system and oversight which is incompatible with decentralization

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:

it's cheap or entirely costless for an entity to appear to be one or more people.

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

[½]

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

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.

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