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/1BnbYeLnz5Cpry6H7NRwgV5pofkEXokac8which 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.
Show Posts
