Quote from: KyrosKrane on June 12, 2014, 01:26:03 PM

I'm not positive, but I think you just recreated the bitcoin blockchain itself...

Well, yes, except it wasn't me it was forrestv. :-). I am actually quite familiar with how p2pool woorks, and the few differences between the p2pool sharechain and the blockchain itself that you point it are integral to my proposal.

Quote from: KyrosKrane on June 12, 2014, 01:26:03 PM

In turn, the shares are tracked on a sharechain that's almost identical in concept to the bitcoin blockchain, except shares are issued much more quickly (once a minute, I think, rather than once every ten minutes on the blockchain).

Unless I am very much mistaken it is once every 30 seconds. And this increased rate is what allows the benefits that I highlighted in the OP. Since shares are worth less than blocks a pool mining for shares as ppart of a larger conglomerate of pools will see lower earnings variance. The pools are effectively insuring each other against bad days, while remaining completely independent as far as block construction etc. is concerned. Usually a high blockrate has a downside since it results in more orphans and wasted hashpower. However, since the block rate of the underlying network is unchanged, this does not apply in this case. And since this p2pool is intended for use by a few pre-identified centralised pools, we could even raise the share generation rate higher still if the latency of the network links between the pools is low enough.

Quote from: KyrosKrane on June 12, 2014, 01:26:03 PM

The transactions being considered for inclusion in a block by the p2pool network are obtained from a standard bitcoin node, so tracking what transactions the pool is working on would be no different from getting a list of pending transactions from any bitcoin node's memory pool. In both cases, any given transaction is not guaranteed to be in the next block, or in any block for that matter.

There is one big difference. If I get the list of pending transactions from a pool node's memory pool, I have no guarantee that the node is being truthful. It may show a tx paying me as being in the mempool, while behind the scenes it is hashing away on a different (double) spend of the same utxo. However, a sharechain provides an unforgeable proof that one or more of the participants in that chain was actually actively mining my transaction. Pools can provide the same proof in the current framework by simply publishing their best submitted share every X seconds. However they then lose the smoothing of earnings benefit.

Quote from: KyrosKrane on June 12, 2014, 01:26:03 PM

I suppose you could create a fork of p2pool with its own independent sharechain; the software's all open source. If one of the major pools shifted their backend to this forked-p2pool, it would be mostly invisible to end users. For pools where the login is a bitcoin address, no change at all would be needed to the mining end, though some changes would be needed to the UI, of course. For pools where a different login is required, I would imagine they'd still have a bitcoin address on file for eventual payouts, and that could easily be reused to pay the miners when blocks are found.

I see no reason why any pool would need to change anyythinng on their fron-end. The pool is still mining to their own address and they are still paying out users with mature coins like they currently do. Users would see very little change other than reduced earnings variance. So if Btc Guild (12%), Discus Fish(12%) and Eligius (8%) were to band together like this they would present to their users earnings variance only slightly higher than a non-aggregated pool with 30% of network hashpower, while remaining independent as far as transaction selection goes (i.e. Eligius would mine certain non-standard txs while Discus Fish does not). Even if this aggregation of pools were to grow to 60% of the network (thus providing lower variance than any non-aggregated pool operator could offer) no single pool operator would be in a position to mount a 51% attack. And the sharechain would provide early warning if a pool operator started withholding hashpower (to perform a Finney attack or selfish mining for example).

Quote from: KyrosKrane on June 12, 2014, 01:26:03 PM

Bear in mind, though, that funds from newly-found blocks are unspendable ("immature") until they have over 100 confirmations, versus the more standard six confirmations for a payment transaction that most pools currently do. That impacts usability for users.

Aware of this. Today pool operators do this by having their own stash of mature coins which they can pay out to users while waiting for the freshly mined coins which will be coming to the pool address to mature. This will remain unchanged

Quote from: KyrosKrane on June 12, 2014, 01:26:03 PM

I strongly suggest reading through the p2pool thread (or at least, the first post and the last few pages, as the thread is huge), then reforming your proposal a little more clearly and posting it there for feedback. While I use and support p2pool, I'm hardly an expert on it.

I'm pretty familiar with the working of p2pool allthough my knowledge may be a little dated. I hope I have clarified the points in my proposal that created confusion.