Bitcoin Forum

In another thread (https://bitcointalk.org/index.php?topic=393815.0), we've been discussing the so-called "51% attack." The point I've made there is that regardless of your personal opinions about the profitability or motivation for such an attack, the vulnerability still exists and is particularly worrisome in the context of large, consolidating mining pools.

The original Bitcoin paper mentions the following:


My interpretation of the proof-of-work concept (reading between the lines) is that it is intended to distribute power among those who legitimately control and benefit from that hashing power. The problem with most mining pools in practice is that the pool operators can ultimately control the hashing power of pool members (obviously they don't have direct control of the the members' hardware, but with respect to the members' contribution to the blockchain, they do in fact have 100% control).

Putting it another way, I find it much, much less likely that the majority of the network's hashing power would be "dishonest" (willing to collude and carry out an attack) if each of the nodes were truly controlled by their owners as opposed to mining within a pool. Mining pools obviously offer some benefits to their members (over mining individually), but in effect, they undermine the goal of spreading the network's power over a large number of independent disinterested contributors.


So here's my 2-part question:

1. Would it be technically feasible to incorporate the concept behind P2Pool into Bitcoin itself? Obviously, it would require changes to Bitcoin clients and to the Bitcoin protocol. In effect, every mined block would be required to come from the decentralized "pool" and every contributor of hashing power would be rewarded - directly - for their share of contribution.

2. Do you think such a solution would help in reducing the chance of a 51% attack from occurring? Of course, I realize that due to the decentralized and democratic nature of Bitcoin, the possibility for a 51% attack would probably NEVER be fully eradicated, but perhaps by removing the utility of mining pools, the level of control currently held by pool operators would be redistributed to those who actually own/operate mining resources.


I would appreciate respectful and thoughtful responses the the questions above. Please, I'd ask you to refrain from making statements like "no rational pool is going to destroy/attack the network on which they rely to succeed". I'm not looking for arguments about why we "don't need a solution to the 51% problem". I'm interested in a solution that will help protect the democratic and decentralized objectives of Bitcoin regardless of whether you think these threats are rational, probable, or profitable.

It would be almost trivial to implement— just bundle it, if nothing else. But I suspect the ship has already sailed for this.

We now have miners with hundreds of thousands of dollars of equipment which run it off a raspberry pi. Who send their coins directly to coinbase to be sold. Who have never used a Bitcoin client of any kind (except for the coinbase webwallet), certainly not a full node, and they have no concept of why they'd want to.  The name they trust most in mining is operator of their chosen pool— who could be robbing them blind, but maybe isn't— who has a financial interest to the tune of— say— >$700,000/month in keeping miners on their pool, and who tells them they don't need to worry about things, and who is believed because far too many people— including you— overly fixate on "51%" and ignore the fact that someone who controls 25% hashpower can reorg 6 confirms with 5% success or 2 with 31% success.

Never mind that the question of parties with large hashpower using it to harm other Bitcoin users is not hypothetical, as its recently been done (https://bitcointalk.org/index.php?topic=327767.0)— achieved huge profits in the process— and seems to have resulted in no negative consequences for the involved pool, just a lot of victim blaming, and some months delayed promises that the responsible parties have been sacked.

Perhaps many miners could be moved to running something p2pool like if doing so was easy, but just running a Bitcoin node is no longer so easy that it can be treated as costless, with now gigabytes of space wasted by pointless dust-scale messaging transactions. Transactions that the Bitcoin users didn't care about because they weren't running nodes and because many people had a monetary interest in being able to wastefully use the systems resources in that manner.

In any case, I don't think the problems you're facing are technical. The problem is that participants in the system don't know or care. I think the problem is also that to some extent people who should know better are not paying attention to the mining ecosystem and don't realize what a mess things are, and some who do are tempering their statements because saying "Hey everyone, the Bitcoin security assumptions are basically invalid in the current environment" too loudly may be adverse to the value of their holdings.

If you can figure how to educate people on the subject in a world where people have multimillion dollar a year income streams that depend on hashers not being educated and while other people own hundreds of millions of dollars of Bitcoin whos value might be eroded if the concerns become too wide spread— then I think progress could be made. Otherwise?  ::shrugs::

[I don't even intend to suggest intentional misconduct due to the monetary interest, only: "It is difficult to get a man to understand something when his salary depends upon his not understanding it."]

Thank you for your insights! It's a breath of fresh air (albeit a bit depressing) compared to the feedback given by people in the General Discussion board.

BTW - I agree with you with respect to levels of control <51% still carrying substantial risk. I mention the number "51%" because it seems like very few people on some of the boards actually believe that lower levels of control are still a significant threat, so without mentioning "51%", many people don't seem to understand what I'm talking about.


I realize that enormous amounts of money have been invested in mining hardware, and as you say, miners are all too often ignorant about the risks associated with mining pools.

But if you ask me, it would be better to try and fix this now (however painful as it may be - especially for pool operators who aren't going to essentially hand over their multi-million-dollar businesses without a fight), rather than suffer catastrophic problems down the road.

So if the problem is education and adoption (rather than technical), then I say bring it on! Save Bitcoin! :)


Thinking out loud here... if a protocol change actually enforced adoption of a P2Pool-like system, then I'm sure most of the pool operators would (strongly) oppose the change. But the ultimate power is in the hands of those with the hardware (who may or may not understand the need to adopt the change in the protocol). Aren't most miners familiar with the process of periodically updating mining software? What if an announcement were made - loud and clear - prior to the change, followed by the rollout of the updated reference client while urging all other client developers to update accordingly (perhaps there could be a cut over date/block index hardcoded in the software so that the change is somewhat coordinated)? If we could get a majority of miners to adopt the change (screw whatever the pool operators think), then the rest would have to adopt (or they'd stop getting any reward). We get companies like coinbase on board to help support the change by offering services that aid in the transition for current miners.

Thoughts? Is such a change completely out of the question?

I've mentioned this in a separate thread but again it was in General Discussion so people didn't take it too seriously.

I have a theory that a Decentralization Fund run entirely from community donations could use its resources cleverly enough to create incentives for miners to switch away from large pools. It could be possible to subsidize small mining pool operators in such a way that mining pool operators are encouraged to cap their hashrate at 20-25% for fear of mass defection to a subsidized pool.

There are many ways to potentially structure such an incentive system but I believe it would not be as expensive as it might appear at first glance (a hard upper bound is around 200,000 BTC, but in reality it could be several orders of magnitude less). Even preparing bounties for pool operators to implement obvious incentives like merged mining and low fees is a fantastic start. Or, make bounties to improve p2pool.

A big part of the problem is simply that GHash and BTCGuild are more convenient and more miner-friendly than p2pool.

Perhaps the two ideas could be used in combination (a protocol change along with a fund temporarily subsidizing miners or pools that adopt/support the change). I'm personally most interested in a technical solution to the problem - hence my posting to this board.

My only issue with a fund alone is that it seems to leave loopholes for people to game the system (e.g. pools staying "small" but secretly colluding). For that reason, I believe the solution needs to be incorporated into the software/protocol itself.

P2pool simply uses to much resources.  If you use a pool, you can run mining software on a raspberry pi or a basic router.

The problem with mining is that it's still driven by the wrong economic incentives because the block reward still dwarfs the transaction fee revenue, because the transaction rate is still minuscule.

The current situation is a self-fulfilling prophesy brought about by everyone who screamed to block progress on needed changes to allow the transaction rate to scale to a size where the perverse incentives reverse.

Got out of bed the wrong side this morning Gregory? :)

Yes, the situation with mining centralisation is pretty dire. P2Pool suffers badly from a lack of professionalism, to the extent that p2pool.org actually is now being squatted by something that isn't actually p2pool.

But it's not all bad! p2pool has proven that the underlying protocols and concepts can work. Decentralisation is always a lot harder than centralisation so we should not be surprised that things tend to centralise over time without big efforts.

This is a specific case of a more general problem, which is that the community lacks any systems for crowdfunding of decentralised infrastructure/the commons, beyond the Foundation, which at the moment is not primarily doing technical investment. So the decentralised infrastructures end up being immature and generally offputting (e.g. a website that is just a wiki), and that puts people off because they just bought expensive equipment from a professional ASIC producer and want to feel like the whole toolchain is equally commercial.

If you want to work on fixing this, IMHO the right place to start is by improving the bitcoin.org website. Create a section for miners and put best practices and advice there, make videos showing how to configure p2pool, heck, as p2pool screwed up their own website why not give it a section of bitcoin.org and work with Forrest to make that the official website? There are no other competing decentralised pools after all.

Integrating it with the Bitcoin Core software is probably less important than just making it generally easier to set up and run. I doubt the cost of a full node is all that big a deal compared to the cost of the ASIC miners themselves, lots of people run them on a cheap VPS.

Anyway, there's lots of low hanging fruit here to push p2pool forward. But someone is going to have to make it their primary project, for a long time. When I decided I wanted to build a decentralised mobile/Android wallet, it took about 2 years until it was competitive with more centralised solutions. So these can be big commitments.

Thanks Mike! Glad to hear someone on the core team is paying attention and concerned.


I'm willing to put in the effort - not sure how much I can contribute directly to p2pool development, but I'm becoming more and more interested in creating a community effort to draw attention to this and allocate resources intelligently. There is still time, but people need to take preemptive action, not wait until everything is on fire.

Integrating into the main client codebase (as basic CPU mining was/is) would have a major advantage over the current situation: the resource management in the p2pool code could be optimised to run more efficiently, and so make p2pool closer to being able to run on the less capable hardware that many people use for mining nodes (the raspberry pi and router class of computer). And the main client is already compiled for the range of hardware that p2pool typically runs on, so the argument about throwing the cross-platform runtime away would be pretty much void. But I wonder whether "closer" is all that would be achieved with such an effort at this point in time, I'm sure someone who knows the p2pool design and codebase would be better placed to judge, but my instinct is that these cheap machines would still be out of the question. And even if it did work, it would still be pretty marginal. The main client really struggles on the 512Mb RAM raspberry pi, although I've only tried that with 0.8.1, but it was painful enough to convince me not to try again.

Given a bit more time, this situation could change. As has already been mentioned, transaction fees are only going to increase as a proportion of the block reward in future. When 12.5 BTC blocks become a reality in 36+ months, possibly coinciding with a consistently higher transaction fees portion of the block reward due to network usage uptake, we could see a real change in miners attitudes towards their valuing of the fees as part of their mining efforts. Further centralising and/or corporate encroachment of the mining market could contribute to the same effect, and so priorities look set to shift when you consider the likely direction of change in these factors (although the reward halving is the only factor with any certainty). Given these assumptions and the timescale on which they could become realised, a $30 raspberry pi type device could be more than capable of running p2pool and bitcoind. Possibly even without a great deal of performance compromise in comparison to a server or desktop box.

The heart of the issue is that the design model for that current solution is functional and useful, but also has it's limits. If the hashing network were forced to switch to the current p2pool solution overnight, the share difficulty would be pushed up so high that those with low-end hashrates would feel tempted to switch off their rig. That's just inherent to the model, the dynamics make it less attractive to the lower hashrated miners, who just so happen to be the majority. So we're left with the unfortunate situation that the market is making a fairly well-informed choice right now. Sure, it makes some sense for those at the margins of breaking into the sharechain to keep using p2pool, but if you're getting shares less than half the time you're mining, you're making a more rational choice in picking a pool where low difficulty shares are accounted for. If luck goes against you in the (uncertain) window of opportunity you have left for your current mining setup, p2pool looks like a gamble, and so you choose the conservative and reliable option instead.


I don't know whether (in our present situation of a 15 GB blockchain) it might be an idea to consider increasing the length of the sharechain to achieve a lower share diffculty. The rationale being that people aren't as pushed for hard disk space as they are for hashing power.  The downloading of the present sharechain doesn't take so long in the present system, and when you consider that the sharechain size is a static number, it seems like this could change the overall balance in p2pools favour. Doubling or tripling the sharechain to establish a share difficulty of a half or a third it's present difficulty would be my suggestion. I realise this also increases the number of days that the sharechain window is spread over, so the cost of uncertainty in the face of longer term commitment might work against the idea. So maybe advertise a staged increase over time. I think the present scheme has amply demonstrated it's longevity (and it's potential market share) by how consistently p2pool has appeared in the mining pool charts. If more miners were encouraged to use it, the problem with spending 7 or 10 days to get to your hashrate-commensurate position in the sharechain might be more easy to sell than it once was. People's understanding of p2pool mining dynamics have only improved since p2pool first started, and so the argument for a longer sharechain may well be more persuasive now than when the whole concept was unfamiliar.

There is an argument that the official client should do even less rather than more.

Adding p2pool functionality to the main client just adds more code that needs to be maintained.  Most people who download the client don't use it to mine, so it is extra code which doesn't add functionality.

Having p2pool as a (semi-)official piece of software would be better, with hosting on the official site.  It keeps the 2 projects separated and they can interface via RPC (or bitcoin protocol)

I agree with gmaxwell's statements, and I'll also add that in the existing Bitcoin system p2pool will never be strictly competitive even if it were cost-free to run because p2pool will always have a higher orphan rate vs. well-run centralized pools. We're fortunate that the difference in profit is currently small enough that it's lost in the noise of variance, but increased importance of transaction fees and a larger - especially uncapped - blocksize will change that for the worse in the medium to long term. Additionally in the short-term efforts that improve block relaying efficiency by transmitting transaction lists rather than full transactions, and even just dedicated connections between large pools, will also harm p2pool by making the orphan rates of large pools less than it.

But it's not all doom and gloom you know: sure p2pool and Bitcoin itself have some fundamental flaws, but the impact of those flaws won't be fully felt until some time in the future. For now we can learn a lot about crypto-currencies and when the flaws do become critical the next system will have a chance at fixing them. I don't think efforts to improve p2pool are going to have anywhere near the impact people think they will, but they aren't going to be wasted either.

I really appreciate all of the responses here.

So to summarize what I'm learning: p2pool is a fairly sound system in concept, but its weaknesses are that (1) it doesn't currently have the visibility or level of appeal to gain the attention it might deserve, and (2) even if it gained more attention and adoption, it probably wouldn't be able to compete with well-run centralized pools.

Does that sound about right?

So, if Bitcoin's current proof-of-work reward system encourages centralized pools to emerge and flourish (which are a threat to the system), is there really nothing better we can do than wait and watch the system fall apart in time? Surely there has to be a better solution...

If p2pool faces (from what I'm hearing) an uphill battle to gain any substantial adoption in its current form, then what about the original question I asked:

Would it be technically feasible to incorporate the concept behind P2Pool into Bitcoin itself [a forced change by the protocol]?


Carlton mentioned:

To me, seeing some miners forced out as a consequence (due to difficulty or hardware limitations) seems like a price worth paying for the network's survival.

Maybe I'm missing something obvious, but wouldn't such a change ultimately solve both of the issues (adoption and being competitive with centralized pools)?

For the sake of argument, suppose ALL mining had to be done through this built-in decentralized pool (or else the official clients wouldn't accept the blocks)... would it be possible or advantageous for traditional centralized pools to even exist on top of that? Are there technical reasons (other than perhaps being a pain to implement in a non-breaking and safe way) that such a change just wouldn't work?

More overall hashrate is better, even if the providers are deluded (or "charitable"  :D). This is the crux of the proof of work security model. The bigger the network hashrate, the higher expense there is to take control of it. Simple. So we shouldn't be forcing a technical impediment that prevents otherwise useful and economic mining equipment from being a part of the network.

Also, if the p2pool codebase is to be useful and open source, multiple IP's must be able to connect to a single p2pool node. These factors will allow some form of centralised pools to continue despite any protocol changes to enforce p2pool only mining. Current p2pool allows people the freedom to create publicly accessible nodes with their own rules about payouts and service fees. So that capability would have to be removed to satisfy your proposal. We'd be better off if we can convince people to mine with p2pool on the basis of how profitable and how easy it is to set up and use.

Except that, in practice, it has a lower empirical orphan rate. The design currently has a communications advantage.

The smallest mining device that I'm aware of that you can currently buy which is within a factor of ten of the best $/GH devices (e.g. remotely competitive at all) costs about $2000.  Why is a ~$2 bottom of the end cellphone/stb microprocessor your target device for controlling thousands of dollars of hardware? Doesn't this seem more than a little ridiculous?  Especially when the consequence is an abdication of control which undermines the security assumptions of the Bitcoin system and which— if exploited— could leave your hardware and the Bitcoin previously produced by it worthless?

 

Speaking of bundles, p2pcoin (in my sig) is a complete bitcoin/namecoin/p2pool system.  I think it may be too fat for a bootable CD with the latest release, but you can put it on a USB stick, or serve it with PXE.  You can configure it locally if you have storage, or serve configuration to a farm with DNS and HTTP.  It uses bfgminer, so it should handle most miners, and can be configured to fall back to other local p2pcoin nodes, or to public pools.  Oh, and if you have enough RAM, you can run the whole thing (including bitcoind and namecoind) entirely out of tmpfs, which is crazy fast.

Which is why I said "well-run" and went on to talk about how the design advantage that p2pool currently has by forwarding txids rather than transactions won't last forever.

If the eventual goal is to have a chain where small and large players can mine together, maybe a very small change would suffice.

What if Bitcoin (or an alt-coin) used a PPLNS (Pay Per Last N Shares) system BY DEFAULT ?

P2Pool is effectively a decentralised PPLNS system ?

So - basically the last 512 blocks, or whatever, are used and payouts are made to all the miners for those blocks, every block, proportionally to the hashing power they put in. AND miners can increase their individual difficulty, like p2pool, and still be correctly paid for the work they put in. This removes the incentive to win EVERY SINGLE BLOCK. One block every 512 will make sure you are constantly being paid.

This way you could have as many as 512, or whatever, miners/minining pools running and everyone would still get their fair share. BUT if one of the miners broke down for a bit, it would have a minimal affect on the actual chain.

I would also say, that to make sure the rationale miner increases his difficulty, and his variance, to allow other miners on the chain, they get 1% more payout if they use difficulty x 512, or whatever..

This way the successful miner will try to get 1 block every 512, but as hard a block as possible. Thus maximising revenue.

This still does not fix the 51% attack, neither does P2Pool, but it does allow many more miners onto the chain.

And - no extra Bandwidth/Memory requirements. (in BTC's case - just a HERD HARD FORK Haha!)

Ah ha! This is exactly the kind of thing we need - a no-brainer setup. Heck, there's even a little business here for someone: sell computers pre-configured for mining that boot right into it. If they were done properly, we could and should recommend them on the website.

By "properly" I would mean that they ideally don't require much setup beyond simply plugging into the wall, switching on, and plugging mining hardware in. So, self configuring. The base OS should be minimal (good to avoid the machine getting hacked), and ideally it'd have a way to with user confirmation upgrade the software components automatically. For instance, when a new Bitcoin Core or a new P2Pool is out, the screen should display information about what the upgrade changes and require the user to explicitly accept (i.e. not auto-driven by the seller of the machine).

I think the arguments about whether P2Pool will be competitive in future can be put to one side for now. It's all rather speculative and one thing we can be sure of, if it doesn't grow and become easier/more popular the details of network propagation in future won't matter  - nobody will be using it anyway! There's a step one and a step two here :)

The problem is that you need a way to decrease the share difficulty.  P2pool is 2%? of the total hashing power and already there are complaints about how high the share difficulty is.

If p2pool was 100% of the network hash rate, then share difficulty would be 20X times lower than the main network (since it has a 30 second share rate).  That is an improvement, but almost as bad.  If large miners set their difficulty higher, then it would help.

The bottom line is that you need some way to increase the rate at which shares happen.

On the GHOST thread, there is a suggestion to have multiple headers referenced so that orphans are included.  This allows the block rate to be increased, but (at least in theory) not reducing network security.

Under the GHOST system, orphans add to the security of the network, but the miners aren't directly rewarded.

Why not increase the length of the sharechain? (and maintain 30 second per share, to increase the overall number of shares). I can't think of any serious drawbacks to this, the current design covers 3 days of shares right now.

I don't think the length of the sharechain really matters that much.

As long as the pool hits multiple blocks for each share, the payout per share has reasonably low variance.

P2pool is 3 blocks or 3 days, whichever is shorter.  It hits blocks about 2-3 times a day, so the 3 day rule never kicks in.

The problem is the share difficulty.  If it takes days for miners to actually hit shares, then that gives high variance.

Faster shares means lower difficulty per share.  However, there is a limit to how fast the shares can be due to network latency.

Would Satoshi turn in his anonymous grave - figuratively speaking? Just a reminder:

"We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of
ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power....."

* A system that does not rely on trust.
* "the main benefits are lost if a trusted third party is still required to prevent double-spending"
* "Unstructured simplicity"
*etc.

The fact that ASICs have enabled the security of the network is offset, IMHO, by market driven behaviour pushing people to seek greater market efficiencies in order to maximise profit. Nothing wrong with that, except that bitcoin seemed to have been partly founded on the solution to the double-spending, which was proposed to be resolved by a true and unstructured p2p CPU system.

I would have said forcing small miners out qualifies as a Gorden Gekko moment, n'est-ce pas?

If I understand correctly, p2pool currently uses a single difficulty for the entire pool.  The difficulty changes to target the 30 second share time, but changes for everyone.  And it is presently so high that non asic devices are effectively useless anymore, and even some older asics.  ( It used to be 10 second target, but was adjusted up to 30 secs to work better with BFL asics. )

What if instead the p2pool difficulty was unique to each node, based on its avg hash power, with a goal of 30 seconds per share?

So then the node would report to its peers the difficulty along with each share.  The peer can easily validate that the shares exceed the difficulty.  When a block is found, the total hashing input will be the sum of (difficulty * number of shares ) from each node.  So each node would be rewarded based on its percentage of the total.

Wouldn't this allow slower devices to participate?

I haven't looked deeply into p2pool, so most likely I'm neglecting something obvious.  In that case, please educate me.

Edit: so far the biggest obstacle I see is that if we had tens or hundreds of thousands of peers contributing to a block, then the block reward transaction could become HUGE. 

That is way to low a difficulty.  If there are 1000 nodes and each node produces shares every 30 seconds, then you get 33 shares per second.

A better target would be something like one share every 60 minutes.  However, even that gives a high share rate if there are enough nodes.

The current system ensures that there is one share every 30 seconds.

Maybe having branching chains would help.  You could have 10 chains, and every so often sync all 10.

hmm, good point.

Yes instead of 1 share approx every 30 sec we would get N shares every 30s, where N is the number of network nodes.

Okay, so let's adjust it to every 10 minutes.   Now we get N shares every 10 mins.   If 10000 nodes, that is 16.66 shares/sec.   Yeah, still too high.    Every 60 minutes with 10k nodes gives us 2.77 shares/sec.    still high.

Here's a random thought for scaling to any number of nodes.  What if the shares diminished with propogation distance?    Let's say for example that for each node your shares pass through, 20% is removed.  So it would travel at most 5 hops in any direction.  If the block is found by a node outside your circle, you wouldn't get any credit.  Possibly the number of hops could vary automatically based on the number of shares being received every X seconds.   I've no idea what the best values would be, but that's the general idea.

I'm not sure how branching chains would work.  Can you elaborate?

There is a bounty for improving P2Pool which was languishing at about 2 BTC (but that has been drawn down a few days ago).
Advancement of Decentralized Mining - Vital to Bitcoin Network Security (https://bitcointalk.org/index.php?topic=329860.0)

I agree it would be nice to see it in the reference client. The importance of decentralized mining outweighs the argument that the reference client should be focused toward the protocol.

You're missing my point. If there were more shares available over a longer period of time, the necessary difficulty per share could be reduced corresponding to the increase in the number of shares. You cite faster shares as the heart of the problem, but making more shares available is the problem, speeding up the interval between them is just one way of increasing the available shares (and reducing the difficulty by a commensurate amount)

Perhaps.


Not really. 

If you increase the length of the share chain, then 1 share pays out over a longer time.

If I hit a share, then I get paid out 10 times less every time p2pool hits a block.  However, my share remains active for 10 times longer.

The value of each share is exactly the same as before.  My variance for finding a share is exactly the same as before.

What changes is that I now have to wait 10 times longer to actually get paid for that share.

With 2 blocks per day and the sharechain running for 30 blocks, it would take 15 days for a constant miner to get their expected output.

There could be a psychological effect though.  If a miner remained at a constant output, after the 15 days, they would have lower day to day variance.


Difficulty would be completely unaffected under your scheme.  Difficulty is used to prevent spamming of the sharechain.  It gets set so that there is 1 share every approximately 30 second.

I question how much ASIC miners should be freaking out about variance. If you just sank $20k into an expensive machine, why can't you tolerate getting rewarded once a day or once a week? As long as the size of that reward is fair, it seems like anyone who can afford the hardware should be able to afford the buffer for electricity costs as well. No?

I think many people just want to get the most profit out of their miner.
I am in for the long run but early december I had a chance of getting a miner and all I think about was how can I roi as soon as possible and not about enhancing bitcoin security.
There need to be an incentive for bitcoin decentralization. Cheaper miner with p2pool contract for example if the manufacturers are willing, or plug and hash p2pool miner for people who is not tech-savvy. Manufacturers could play a role in the decentralization of bitcoin, and they should, they are getting a lot of money from the success of bitcoin.

For the short term, I think convincing miners into going to smaller pool is a priority before p2pool matures either through incentives or education of bitcoin security. ghash.io already has 1/3 of the global hashrate and it looks like it is still growing by comparing 24hr chart with 4 days chart https://blockchain.info/pools

There is a pool of shares. It is currently comprised of 17500 shares in total. The owner of each share has it ranked according to how far each share exceeded the difficulty.

So every block found is divided into 17500 unequal rewards, and those nodes with more than one share receive the sum of those rewards to their address.

If the number of shares is increased to more than 17500, the difficulty per share would have to drop by a divisor of the factor of increase in that total number in order to target the same interval.


Your suggestion is to attain this increase in the pool of available shares by increasing the shares available within the current 72 hour window that the pool currently operates over, e.g. 35000 shares with a 15 second target difficulty (I don't think this can work with the majority of ASICs out there right now, forrestv changed the target from 10secs/24hours to 30secs/72hours to accommodate them)

My suggestion is to extend the 72 hour window, and maintain the 30 second difficulty target. This would decrease the difficulty target. It would increase the length of time that a new miner would need to build up a full coterie of shares. It would also increase the size of the sharechain on the disks of the mining nodes. My rationale for this is that the current sharechain is ~500 MB on disk, and that the miners are more likely to be lacking hashing power than they are to be lacking disk space.

Right, each share has a difficulty associated with it.

It isn't a fixed number of shares that are paid out.  It is 3 block's worth of shares.  Shares are never kept more than 3 days, so if the pool finds very few block, your share can fall off the end of the chain before 3 blocks reward.


Right, but not a fixed number of shares.  It is the most recent shares equal to 3 blocks worth of difficulty.


No, again, the difficulty is determined by the rate at which the shares are generated.  Increasing the number of shares included in the system would just increase the length of time the sharechain has to be kept.

It would also mean that miners get paid more often for each share, but paid a smaller amount.


No, it wouldn't.

Once again, difficulty is determined by the average share rate. 

Ignoring the fact that miners can artificially increase their difficulty target, if you want one share every 30 seconds, then each share has to "cost" 30 seconds worth of hashing.

The share difficulty must be (p2pool hashing fraction) * (bitcoin difficulty) * (share target rate) / (600 seconds).  That is the number of hashes performed by p2pool in the target window.


Right.  They would get a smaller payout but be paid out for more blocks to compensate.

However, the total payout per share would be the same.


Well, it depends on what they are controlling their mining with.  They might not have a disk, but 500MB isn't that large.

Not sure if I'm missing something but is this not the crux point ?

You HAVE to make the miners increase their individual difficulty. By giving them an incentive to do so. By paying them more for doing so..


Maybe more than 1% would be required to make sure that miners DEFINITELY went for it but if you could get the miners to try and get 1 block in every N shares, rather than N shares in every N, the longer the chain the lower the difficulty.

If N was 1024, the successful miner would set his difficulty to 1024 times normal difficulty, so as to get 1 share ONLY at the highest difficulty possible, thereby increasing his revenue. (As long as he still got 1 share in every N, otherwise he would choose a lower extra difficulty). As 1 share at 1024 times difficulty is worth more than 1024 shares at 1 times difficulty.

This would make the chain 1024 times easier to mine on ?

If N was higher, the difficulty would again be made lower - but ONLY if the miners increase their own difficulty to match (And get paid accordingly).

What i am unsure about is HOW MUCH MORE to give the miner for increasing his difficulty ?

If you give too little the miners just won't go for it, but if you give too much, then this will give the large pools X% more and they can give this straight to their users, and attract more users, etc etc.. and they will grow even bigger..   

Maybe a market driven mechanism. Not sure how..

I was responding to Carlton Banks.  He felt that increasing the length of the share window would decrease the difficulty.


1% bonus would probably be enough.

Any miner who is getting more than 1 share an hour should definitely increase his difficulty.


No, because "small" miners would still be on lower difficulty.  A miner with 1000X the power of the other 1000 would get half the shares.

If he set his difficulty to 1000, then he would get 1 share while the rest got 1000 shares between them.  The difficulty would be halved to being things back to one share every 30 seconds.


The suggestion in the document from the donation thread was to simply charge per share.  The charge could be something like 1% of the expected payout per median share.

Okay, you've convinced me. I wasn't accounting for the relationship between the block difficulty and the share difficulty.


This is true, there's a guy on this forum who was using a 32 GB RAM disk for p2pool. I don't know how he will justify the expense to add the RAM he will need in the future, but he maybe didn't buy the RAM for a p2pool node in the first place (and the cost per GB seems to drop regularly too)

Ahh.. yes I see now.. A miner can only decrease the overall difficulty of the chain as a proportion of his own hash rate vs the rest of the network.. If he has half the hash power, he can decrease the overall difficulty by a half.

He can bring himself down to the level of the smaller miners..

..TierNolan!!  ;D

Thinking about it, if you did have a 1024 PPLNS system by default, so that the last 1024 shares were paid, and miners could increase their difficulty and get paid etc etc.., would it not be the case that all the miners would lower themselves down to the smallest miner able to get on the chain ? So that, in the ideal case, each miner still only got 1 share per 1024.

This way you would at least have 1024 miners/mining pools visible on the chain ? Rather than the 10 or so currently available on Bitcoin.

Not sure how important decreasing the difficulty of the individual shares actually is.

The weakest miner able to get on the chain would set the hashrate that the others would have to emulate by increasing their difficulty.

Having 1024 mining pools able to get on the chain is better than less than 1024. No ?

The total number of shares is equal to 3 blocks worth of shares (in terms of difficulty).

If the average difficulty per share is lower, you get more shares included (up to the 3 day limit).


If the difficulty is to high, then smaller miners would only be on the chain sometimes.


One of the proposals is sub-pools.  Rather than mining against the main network, a mining pool could mine against p2pool.

A smaller pool inherently has higher variance, since it is hard to find bitcoin blocks.  Mining against p2pool gives better variance for smaller pools due to the lower share difficulty.

Are any pools known to be mining against p2pool at present?

This (https://cryptominer.org/bitcoin/) is the only one I know of.  The admin of the pool commented (https://bitcointalk.org/index.php?topic=18313.msg4152018#msg4152018) in the other p2pool thread and his pool thread is here (https://bitcointalk.org/index.php?topic=280780.0)

That stats suggest that nobody is mining bitcoin on it though.  If a miner uses his system, they would only get the same effect as mining using p2pool.

As I said, if p2pool gets more hashing power, the minimum difficulty increases.  Pools like that act as a 2nd buffer.

P2pool has the potential to act as a backbone for lots of small pools (say 0.1% of total hashing power each).  By grouping together, they get low variance without centralising control of the system.

Normally, large pools have an advantage over small pools due to smaller pool variance.

It sounds like there may be some interest in bringing p2pool (or a similar concept) closer to the reference Bitcoin implementation (whether that be a change in the protocol, bundling p2pool with the reference client, or simply giving p2pool a stronger online presence in connection with bitcoin.org).

I'd like to try and gauge interest in the various approaches to solving this problem, and perhaps (if it hasn't been done already) formalize some kind of plan of action.

The possible directions I'm seeing are (and these are not mutually exclusive):

• More discussion leading to a formal BIP submission with changes to the Bitcoin protocol and reference client. Then, I guess we wait and hope that either the core team can get to accepting and implementing that BIP sooner rather than later (understanding that there are numerous accepted BIPs whose priority seem to be uncertain), or someone else can step up to the challenge... makes we wonder though how many developers outside the core team there really are that have the expertise, familiarity with Bitcoin, and incentive to contribute such a fundamental change in the timeline needed.
• More discussion about improvements to p2pool (as the separate piece of software it is now) attempting to address any technical shortcomings of p2pool (scaling, speed, hardware requirements, etc).
• More discussion about improving the non-technical issues of p2pool - public awareness, user experience improvements, etc.
• Discussing ways to add resources/velocity to the speedy development of one or more of the solutions above (in the form of crowdfunding, offering bounties, raising developer awareness, etc).

So my question is: how can we best contribute to this issue being solved effectively in the quickest timeframe possible?

What do the core developers feel is most needed at this point? Can we all try and reach some kind of consensus as to how this should be addressed? I feel like unless we can (most of us anyway) concentrate our efforts on one of these things, we are wasting time and resources by chasing a number of different proposals. In theory (with open-source software like Bitcoin), a number of separate contributing groups can work on different solutions to the same problem, and I suppose the best of many potential solutions would naturally emerge, but in the case of Bitcoin, I get the feeling that the number of developers in a position to make these kinds of changes is somewhat limited, and we don't have the time to wait for a solution to just roll around "naturally".

Any thoughts or opinions on how best to move forward to address this concern?

I'm afraid that if we don't act quickly, these discussions will merely become artifacts of a failed cryptocurrency replaced by something better - all because we couldn't fix these kinds of issues fast enough.

Remember that increased usage of p2pool will only increase payout variance to most miners, the opposite dynamic to that of joining a large centralised pool.


To reiterate, if all miners were forced onto p2pool tomorrow, the share difficulty would be pushed up so high that I suspect many lower hashing rigs would quit due to the uncertainty of getting a payout (people with less than > 1TH/s rigs could be mining for months with zero payout, which is a risk they won't tolerate in an environment with rising block difficulty and 24/7 multi-100 watt electricity usage)

My brief tug of war with Tier Nolan should illustrate one important area of improvement to investigate: hardware design. The current generation of hardware comprises many ASIC chips working in a single unit, interfacing with a low cost computing device to run the mining software that schedules and feeds the work to the chips. Some aspect of these current designs makes it necessary to only return the results of work in batches that last ~30 seconds. Forrestv overhauled the share interval and the length of the PPLNS window that p2pool uses just in order to accommodate this type of hardware. When GPUs and FPGAs were the dominant mining devices available, 10 second share interval spread over 24 hours was fine. This was changed to 30 second share interval spread over 72 hours for the typical ASIC.

Can we get ASIC designers to produce chips or PCB layouts that make <10 second share intervals possible once again? The dust is beginning to settle in the ASIC node geometry wars, so they'll need some different direction to go in if they wish to continue to innovate.

Sorry for potentially misunderstanding the problem, but why is hardware - in any way - dictating the direction of software development here? Bitcoin itself is built to scale with changing hardware capabilities by automatically adjusting difficulty as needed. What makes a decentralized mining pool so different conceptually?

Why do you worry about forcing out a subset of current miners who will be forced out with time (and increasing difficulty) anyway? If all miners were forced onto p2pool tomorrow and people with less than (as an example) 1TH/s rigs are no longer competitive, would the remainder of the hashing power distribution really be any less diverse in terms of control than the current situation with GHash.IO? It seems to me that with a bit of time, everyone currently mining is going to be "forced out" anyway due to the competitive forces of hardware advancement. If a software change temporarily accelerates that process in an unbiased way for everyone on the network, how is that bad? The only way I can see it mattering significantly is if the % of miners forced out is very high (e.g., a majority of all miners) causing a slightly "unfair" advantage for those with access to the best hardware (since the marginal cost for additional ASIC hardware could buy a slightly bigger piece of the pie than it could previously), but that was true when the first ASIC rigs became available anyway. The market (in my opinion) has and will adjust if there is any such economic advantage for certain classes of mining hardware.

Well, I'm not lying to you when I say that the p2pool developer changed the system to make it possible to use the type of hardware design that the first ASICs used. People tried using AsicMiner blades and Avalons on p2pool when they first came out in Spring 2013, and they didn't work. Forrestv changed the share interval and it's overall period to allow for it. So there's one way that hardware has dictated the direction of p2pool's design. Kind of pretty significant really, there was a lengthy hand-off period between the old scheme and the new scheme, after which the nodes running the old scheme were cut off from everyone running the 30sec/72 hour version.

The current range of hardware can only perform with the characteristics that it has been designed with, and I'm not sure to what extent that was to simplify the development, the design, or to help conform to standards in the protocol (the mining protocol changed shortly before ASICs, to enable their efficient usage of network bandwidth, and I believe we have two standards to replace the old CPU and GPU proficient standard)

What the challenges are with changing the hardware to send and return solution attempts in shorter batches, I'm not entirely clear on. So I'm putting it out there.


When you think about the health of the mining network overall, you've got to consider the influence the players have. The big centralised pools get consulted to secure their cooperation with any issues on the network that require emergency measures (blockchain rollbacks, emergency patches being the issues that come to mind). Forcing small players out of the network to "decentralise" may only end up further consolidating the influence of the big players. In the growing climate for big private mining firms, both now and in the near future, protecting the share of the small players is important. What you're suggesting decreases the incentive to mining hardware manufacturers for attempting to produce anything but the most dense and voluminous concentration of hashing power in a unit. What if all mining devices ended up requiring 240 volt electricity supplies, and thousands of watts of heat exhaustion? So much for vires in numeris.

We should do all we can to diversify the mining network to keep everybody pulling in the same direction, as the mining network is such a fundamental part of bitcoin's security and integrity. A small number of large firms with self run mega-mines puts too much decision making power in too few hands. There are many potential scenarios for that kind of situation to cause setbacks and imbalances. We should be aiming to make the network with a low barrier to entry, so that even very small players can have a stake in the gains and the rules that create the supply of this money. Promoting an environment that allows large firms to corner the market could put us all in a position not unlike the way money has been issued in the past. I became involved with cryptocurrency in part because it represented  an opportunity to change that situation for the better.

I guess all I can do is echo gmaxwell's sentiment:



In your mind, mining can only either be controlled by a $2 microprocessor, or "the most dense and voluminous concentration of hashing power in a unit... requiring 240 volt electricity supplies, and thousands of watts of heat exhaustion"? Really, nothing in between?

I find it difficult to comprehend how someone could make a case for delaying or hindering adoption of a critical, network-saving change just for the sake of ridiculous hardware constraints like that mentioned above... unless there is a conflict of interest involved or some kind of financial incentive to profit from the deployment of such devices.

I... simply don't have the words to describe my dismay at this kind of flawed reasoning. If the only thing standing between Bitcoin's success and failure are a bunch of overpriced machines controlled by Raspberry Pis (engineered, by the way, to be underpowered and save *pennies* for the sake of bringing technology education to the less fortunate), then I'm sorry, Bitcoin is dead. End of story. We're talking about securing a global decentralized cryptocurrency, not learning to type "print('Hello, World!')".

Er, you're kind of comparing apples to oranges there. I'm not sure that I made any case for using anything but the most basic device as a controller. Comparing a cheap controller with the amount of hashing per unit is missing the point.


You're making a strangely exaggerated argument. Which is it to be, that we should have low priced miners, overpriced miners, or that bitcoin is dead?

There is twisty logic mayhem in your post. I'm not convinced you understand mining or miner hardware too well.

Yes, I understand the difference between a controller (which admittedly can run on very low-end hardware) and hashing power. My point is, if you were using a $35 piece of hardware to control a nuclear reactor (yes, I'm exaggerating a bit to make a point), and the reactor - or rather the entire energy grid - were at risk of meltdown without a very minor, known-working hardware upgrade (compared to the reactor) for the controller to support the software fix, would you be wasting time trying to figure out how to somehow re-architect the software to run on the old hardware just to save a couple of bucks?

Do you really think that forcing/encouraging that minimal upgrade would disrupt the current (non-existent) "balance of power" on the network?

No, I don't think that's comparing apples to oranges. If anything, I think the current mining situation is even more ridiculous given the fact that (assuming the network survives), all of the current hashing power mining behind those cheap controllers is going to become worthless in a year (or less) anyway.

Go ahead and spin your wheels trying to save a small subset of current mining hardware while you watch the network crash as all those ignorant miners  who purchased pi-controlled ASICs point their hashing power at "benevolent" centralized pools who would NEVER do anything harmful (because the miners don't know better and/or they can't run something better on their controllers). Don't complain that we didn't have enough time/resources to fix the problem. Talk about missing the forest for the trees...

To put it another way, let's fast forward 10 years to a time when (if Bitcoin is still around) all of the mining hardware you're referring to is completely useless for any kind of profitable mining. The state-of-the-art mining rigs dwarf all of today's machines in comparison. Are you going to be fighting the same battle then, arguing that since some miners from years ago relied on obsolete microcontrollers for controlling their mining hardware, development should still cater to those as a least common denominator?

Because, as you put it earlier, "more overall hashrate is better." Apparently that assertion trumps all other concerns.

How could the network possibly deal with those people shutting down obsolete mining rigs? /sarcasm

(I honestly don't mean any personal disrespect in this conversation - I'm just finding it difficult to understand the rationale for catering to any specific hardware configuration, especially a hardware configuration that seems so… misguided and cheap).

People will use marginally profitable hardware while the exchange rate keeps it that way. A 100% p2pool network would give more than just the marginally profitable too much variance to tolerate, I think I quoted > 1TH/s.

I was discussing the issues with incorporating sub-pools into the protocol with Riclas.

The problem with having sub-pools is how to manage trust.

When a sub-pool connects to the network, it gets paid all the block rewards.  The pool operator is then responsible for actually making the payout.

This could be handled by a complex system of reputation tokens and fraud proofs.

But, a simple way of finding reliable nodes would be to do a few tests.  There would be some risk initially.

The miner connects to a random sub-pool and does 0.01BTC worth of mining.  If the node sends him the 0.01BTC, then he does another 0.01BTC worth of mining for that node.

The miner could do solo mining for any additional hash rate it had.

The payment channels system could be used here too.  The server puts 0.001BTC in a channel and then uses it to pay the miner as hashes arrive.

The channel size could be expanded as the miner does more work.

The rule could be that nodes which are hitting a share more than once an hour act just mine directly.  Nodes which are hitting less than one share per hour would search for super-nodes.  Nodes could indicate if they are super-nodes on connect and maybe include it in any address messages.

I envision p2pool being hierarchical for it to succeed: sharechain > sub-pools > nodes > miners
randomly connecting to nodes/sub-pools solves the high variance problem of bitcoin. Miners are no longer incentivized to join a pool/node with the most hashrate, since they should be automatically balanced.
However, doing so raises the trust issue that TierNolan described and to which he proposes an incremental trust level solution.
I believe this is the way to go for p2pool to go mainstream. People just access the network, start mining, no cares given unless they want to.

I understand what you're saying. If we're just talking about variance, then yes, I agree variance is a problem, especially if it forces a large percentage of miners to discontinue mining. But when it comes to controller hardware/software considerations, I don't think the variance argument really applies, because if tomorrow the protocol/software necessitated a slight upgrade in controller hardware in order to keep current mining hardware functional, I believe most would upgrade very quickly (if the choice is between turning your mining investment into a paperweight and spending a few bucks to upgrade the controller hardware, it's not a tough decision). The cost of controller hardware is and likely always will be a tiny fraction of the total cost of a competitive mining rig. For that reason, I still believe that the solution should not necessarily cater to any specific hardware configuration.

I don't think you understood what I was talking about wrt hardware changes. I wasn't suggesting a change to the controllers at all.

Thanks - my bad. I confused your point about the challenge (or benefits) of integrating p2pool into the reference client ("…these cheap machines would still be out of the question… The main client really struggles on the 512Mb RAM raspberry pi") with your separate/main point regarding variance. Thanks for being patient with me as I become more familiar with the details of p2pool and the mining landscape.

It sounds like there are some good discussions happening among people who know a lot more about this than I, so I'm happy about that. I'm just hoping that an effective solution can be engineered, deployed, and adopted before it's too late :)

+1

How about..

Main p2pool share-chain. (Or a blockchain that ran on a 1024 PPLNS system by default)

Then 1024 sub-p2pools, each mining the main p2pool chain.

When you connect to the network you always connect to one of the sub-pools. Basically the weakest one in terms of hashrate.

You reconnect/re-organise your miner every 24hrs/Some amount of blocks. To keep the sub pool hash rates even.

Repeat.

The goal would be 1024 p2pools with ~0.1% total hashrate each. Not that it would matter that much if one pool was a few percent more powerful than another. Your payouts would be of the same amount, just different variance.

All done automagically.. No need for user to worry about it. Just connect and go!
  

Actually, thinking about it..

How does a p2pool sub pool get paid by the p2pool main chain 1 level up ?

There could be, let's say 1000 outputs on the coinbase txn of the sub pool, and then in the p2pool main chain there could be 1000 shares from the various subpools.

This would mean having literally a million payouts in the coinbase txn..

err.. not sure now..

You can have the top level p2pool, but then you need the regular centralised pools as the sub pools, otherwise as I said, the coinbase becomes toooo large..

 ???

There would need to be a payout threshold.  At the moment, fees are 0.0001 per tx.

Centralised pools generally have a payout threshold that is larger than that too.

Even if you get a share, you don't get paid until you have increased your "balance" sufficiently.

I just opened a pull request to recommend smaller pools / P2Pool / pools with GBT in the "Support Bitcoin" page on bitcoin.org, in case anyone is interested:
Pull req : https://github.com/bitcoin/bitcoin.org/pull/296

IMO, it would be nice to have a similar recommendation on bitcoinmining.com:
http://www.bitcoinmining.com/bitcoin-mining-pools/

And I would be happy to help forrestv to make his own website a little more readable:
http://p2pool.in/

FWIW, I think it is more suitable for P2Pool to remain on a dedicated domain. Serving it on bitcoin.org would just bury it under a lot of unrelevant information and make it harder to find. The website would also be managed by people with no involvement with P2Pool, which I think isn't the logical next step.

I agree that promoting P2Pool is only a small part of the solution. Yet, still much better than not doing it.

Question..

If you were running a 10 second share chain, like p2pool, is it even possible to run a pool on that ?

The chain would be too fast to have another pool trying to find smaller shares, say every 1 second ?

The messages just wouldn't have time to propagate across the network.

Is that correct?

You would need a different mechanism. Maybe one based on sending different miners a range of nonce values they should try, so that no 2 miners search the same space, and then when someone finds a valid block just publish it with payouts made to all.. Seems like 'trust' would need to be involved for that to work though.

Hi guys, I don't usually comment in the technical section as I'm not very technical so apologies if the following is naive.

As I understand it, one the best current options to address the biggest threat facing Bitcoin - the centralisation of mining, is to have miners & hashers switch to P2Pool, but currently they are not incentivised to do so.

So the question is -  Who is most incentivised to incentivise them to switch?

Isn't the answer, the main Bitcoin Exchanges - BTC-E, Bitstamp, MTGox etc. & Bitpay?

A) Isn't the danger posed by centralisation of mining the biggest threat to their business model and income stream?
B) Couldn't addressing the problem even improve their current income stream?
C) Wouldn't it be the most positive marketing investment they could make?

If some of the above were true, would it be worthwhile asking them something along the lines of the following?..

If there was a transparent P2Pool fund set up and administered by the Bitcoin Foundation that would be used to encourage a switch over in hashrate distribution to P2Pool till until none of the other pools controlled more than 10% of the hashing power, would you?

1) Be willing to contribute 5% of your trading fees during a trial period to see if we could make demonstrable headway to achieving that goal.
2) If not 5% what would be the maximum % you could consider contributing ?
3) If you were unable to contribute would you consider giving users the ability to opt-in to a higher trading fee on an individual basis.

Thoughts?

That is an interesting idea.

They also have no conflict of interests.  They don't get an advantage to centralised pools.


There is a system for donating to p2pool.  They could be encouraged to use that directly.

P2pool already has a higher than average expected payout.  Maybe advertising would be a more effective way to contribute.  Adding info on their main pages would cost them little.

it´s sad but now when p2pool should grow (because of massive danger that big mining pools take control over BTC network) it just gets smaller and smaller.

i expect/hope shortly to get my 17TH/s shipped (CT & BM) and brought already good server to build up my own public node. Now i am just testing and optimizing it with my current miner/s, but now i´m not sure anymore that it will pay itself back even if payouts are better than in centralized pools. last 2 weeks average payout is 20% less than with my other miners make in centralized pools.

most important is to find a way, how to bring miners back to p2pool. it is important that we get/set up more stabile nodes.

other important thing would be to find funds for dev-team (and also marketing-team) to make p2pool stronger and more known. if every nod would set up a small fee and spend it to dev-team (so i will do), we would be already a small step further.

Sorry about my bad englisch (not native speaker  ;) )

Many native english speakers have worse english than that.  :)

I donate on p2pool, although I do admit to reducing the fee before I ROI-ed my equipment (adjusted to the 0.5% standard now it's making profits).

I think we have a deficit in understanding mining, this will improve with time. It's obvious when you look at the GHashIO situation. One big reason people mine there is the edge they get from merge-mining every SHA-256 altcoin under the sun. I don't want to merge mine on principle, I'd prefer to keep bitcoin strongest and weaken the influence of alts. But this is what happens when you give people freedom to exercise rational self interest.

Doing what's rational is not the same for everyone, and some people see the short term view, or take the less thoughtful view of the ecosystem as a whole. I think once we have a bit more time to get more people mining, the debate will be opened up more and the prevalent rationale will change. I say prevalent, when you could argue that the majority use a pool that's healthier for the network right now, ~66% of people are not using GHashIO currently.

I don't know that forcing everyone into a P2Pool would really accomplish anything.  The large miners would not be hurt, they will simply continue mining their private nodes and carrying on like nothing has changed.  Pool operators will also not be hurt.  Shares will be found, payments will be made, fees will be taken.

The only real change by doing this, is that the mining operators (independent farms, pools, solo) get a smoother revenue stream.  Win for all.

Individual miners would have no incentive to organize themselves in to teams to support numerous nodes and large operators will have no incentive to break up their systems.  At best, (BIGPOOL) breaks up into 100 smaller nodes, but all 100 still controlled by the same people.

I really don't think that concentrated hashing power is as big a threat as most make it out to be.  Sure, someone might execute a double spend of their own funds, but the victim should have recourse.  Honestly, who's going to accept a $50,000 payment for a new car without requiring a few dozen confirmations before completing the deal?  It's a candybar?  Oh well, you just got shoplifted, call the cops.  Virtual service?  Well, you should have required payment in advance and waited for a few confirmations.

I wonder though, if there isn't a real threat of collusion between pool operators to impose new rules on the entire community.  For example, the US Dollar is controlled by 7 people (currently 5).  They can, without explicit approval of the government, print all the money they want.

This is where Bitcoin is headed if we only have a small handful of pool operators controlling the global hash power.  What if those few decided to get together and issue a code update that allows them to generate all the BTC they wanted.  Sure, if it happened tomorrow, everyone would just walk away.  What about when Bitcoin is the only currency in wide spread use?  We'll have to launch yet another form of currency to compete and hopefully take down the Fiat Bitcoin.

No, I'm not worried about double spending.  I'm worried about the will of a few people being imposed on everyone else.

Every full node checks the validity of the coinbase transaction.  SPV nodes currently don't, but they could if we switch to using Merkle sum trees.

The power that miners have over the network is strictly limited to choosing the transaction ordering.  Their attacks are limited to denial of service (mining empty blocks), double spending (chain reorgs), and censorship (selective rejection of transactions for political reasons).

But even this rests on the assumption that the folks running non-mining, verifying nodes are economically significant enough as a whole to resist miner fraud.

Do you realize there's only 600,000 available transactions per day total? If everyone who downloaded bitcoin.exe was getting daily payouts, there'd be no room for actual peer to peer transactions. Everyone who uses bitcoin cannot be a miner.

You're right, it is up to every full node to validate the blockchain, but to implement a change in the blockchain, you don't need the majority of users, or miners.  You only need the majority of mining operators.  Once they adopt a change, they can prevent everyone else from using Bitcoin until they comply with that change.

If the majority of mining operators (a very, very small minority of people) said "In order to spend Bitcoin, you must pay a 10% transaction fee (tax)."  People would bitch and complain, but rather than letting go of their Bitcoin, they will comply with the new rules.  If they decided to set Bitcoin on an inflationary tract, who's going to tell them differently?  Uncle Joe, who's entire net worth is measured in Bitcoin?  I don't think so.  90% are Uncle Joe, 10% will be cheering because their account balances will skyrocket!

Don't underestimate the general apathy of the people, it's a powerful weapon in the right hands.

Not to make this specific to the US, but that's where I'm at, so that's the example I'm going to use...

---

1866 - fungible gold certificates - fractional reserve
1913 - federal reserve bank given power to counterfeit our money
1933 - confiscation of gold - Dollar drops to 78 cents (vs 1932 prices)
1934 - Dollar drops to 58 cents
1971 - End of Gold Standard - Dollar worth 51 cents
1972 - Dollar drops to 35 cents
2014 - Dollar worth 1.5 cents

---

What happens when Bitcoin becomes THE currency and people devolve once again into apathy.  Who's to stop the miners from destroying value just like the FED destroyed the value of the dollar by taking gold out of the equation and engaging in unlimited printing?


Congress is supposed to be representative of the people, to work the people's will.  The apathy of the people allowed Congress to do this to us.  The apathy of the people allowed the wholesale counterfeiting of our money.

Apathy happens, it's a fact of human existence.  Bitcoin does not have any controls to prevent abuses against an apathetic people.  Honestly, I don't know if there can be a 100% safety net against apathy, but making collusion between mining operators more difficult would likely be a step in the right direction.  I think I have a solution that would work on a new coin, but would be horrible at this stage of Bitcoin's development.

The daily limit of 660,000 transactions isn't an issue.  Payouts would only be done using one transaction per block, the coinbase transaction, which does not necessarily need to be limited to an arbitrary number of outputs.  The P2Pool payout logic described in the wiki is a little fuzzy, but I can see the payout being divided up between an equal number of outputs for the largest share holders and oldest (qualifying) share holders until the total award has been spent.  The only shares that would expire without compensation, would be those with a value less than a defined threshold or the limit of the monetary unit (less than 1 Satoshi).

To clarify my last post:

Satoshi wrote in his paper that "Nodes will always consider the longest chain to be the correct one..."  To expand on this, wouldn't it be fair to also say that whomever controls the longest chain has the power to impose a tax?

Even if we were to incorporate P2Pool style code directly into the client, we still won't have any way of proving that Alice is only running a single node and that her node wasn't being secretly controlled by Bob, or that Alice and Bob are not colluding towards some nefarious purpose.

I don't know the answer to this problem, or if it even is a problem.  Perhaps the 'central' nodes need to be operated in a completely open and transparent manner with positive identification of all parties involved with it's operation?

You're seriously oversimplifying this scenario.  The dynamics of such an attack are economically and socially complex, but if you think deeply about it, I think you'll find that defences can be mounted that would eventually bankrupt the attackers.  Though it would be messy while it played out.

You also don't seem to be considering the implications that this attack would have on confidence in the system, if successful.  It's essentially an existential threat, and giving in simply isn't an option.

Yes, it does need to be limited. Every output, even in the coinbase transaction, takes up bytes, and the blocksize has a very hard limit.

What about for alt coins? Would it work for them?

Yes, I am oversimplifying the scenario, much like how the banksters and our government oversimplified the issue with Gold as a currency.  The rich wanted gold as a store of wealth, while the common man just wanted something to use for purchasing everyday things like bread and milk.  The two purposes were at odds, and the common man lost.

I'm sorry to have gone off on such a tangent.  It wasn't my intention to get into the intentions of future parties or the ability of Bitcoin to fend off various attacks (monetary, technological, or social).  I was simply trying to express that there are potential threats, and that while implementing P2Pool in the client itself could be part of a solution, it cannot solve any real problem by itself.

In order to eliminate any potential threat of consolidation of power, we would need to eliminate the 'vote by hash' system.  And no, I do not believe that POS is the answer either, as that consolidates power in the hands of whomever controls the most coin.  I really don't know what the answer is.

Don't know how we got here, but I never said that ALL miners would receive DAILY payments.  Shares would grow in size and/or age until they qualified for a payout.  A 1TH miner might get a daily, while a 1GH miner might get a weekly or monthly.  Someone who only ever mined a few satoshi worth might not get a payout for several weeks.

The limits on block and transaction sizes are arbitrary and will need to be increased over time to accommodate an increase in transaction volume.  Considering the arbitrary nature of those limits, there's no reason that the limit on the coinbase transaction couldn't be modified to accommodate enough outputs to pay an equal mix of LARGE and OLD shares to the exhaustion of the block reward.  I don't think that it would take all that many outputs... several hundred at least, but probably not more than a thousand or so, which may not even require a modification of the limit.