What miner are you using? It seems to be submitting shares with a fixed difficulty of 1 rather than paying attention to the 'target' in the getwork message, in which case frequent messages like this would be normal.

I'm working on a successor to p2pool that is completely decentralized. I'd recommend not trying to use p2pool as it is now; technically it's fine - there network is up and I'm mining on it, but it probably won't generate a block before I finish the successor. Also, accordingly, the SVN repo is in flux; if you still want to use p2pool, use the released version.

What miner are you using? It seems to be submitting shares with a fixed difficulty of 1 rather than paying attention to the 'target' in the getwork message, in which case frequent messages like this would be normal.

I'm working on a successor to p2pool that is completely decentralized. I'd recommend not trying to use p2pool as it is now; technically it's fine - there network is up and I'm mining on it, but it probably won't generate a block before I finish the successor. Also, accordingly, the SVN repo is in flux; if you still want to use p2pool, use the released version.

p2pool is a great idea! I bet it will sometime implemented naturally on bitcoin client because it is the p2p-way to mine, as the whole bitcoin project is. Go on!

So I'll follow your advice and I'll get fresh versions from SVN for my tests.

Proposals for improving bitcoin are like asses: everybody has one1SheveKuPHpzpLqSvPSavik9wnC51voBa

p2pool is a great idea! I bet it will sometime implemented naturally on bitcoin client because it is the p2p-way to mine, as the whole bitcoin project is. Go on!

there should be a more general solution where you join a network and then the bitcoins get distributed by the client itself somehow without any kind of operatorin fact this should be done with the bitcoin network somehow

Having this integrated with the BitCoin client would be very nice and I strongly agree that this should have been the mining process all along.

So I'm just trying to understand the implication of this:

If, let's say, I have 1 Gh/s of mining the current network hashrate is: 11148 GH/s. Is the suggestion that every time a block is found (every ~10 minutes) that I would get 1/11148 of 50BTC (or 0.00448511) every ~10 minutes?

If, let's say, I have 1 Gh/s of mining the current network hashrate is: 11148 GH/s. Is the suggestion that every time a block is found (every ~10 minutes) that I would get 1/11148 of 50BTC (or 0.00448511) every ~10 minutes?

About the first point : okay, I didn't consider that. This pool is still not very scalable though (even if it represents 10% of the network, that's 1 share every 10 seconds).About the second point : seems complicated. How about simply putting the 599 previous shares in every found share, and when one is a "winner", pay all the previous 599 shares ? Regardless whether they are from a previous block or not. This is much simpler, allows complete decentralization and still pool-hop resistant.

Brilliant plan!1) Totally decentralized2) Each client can pick the Factor (ease factor) {F} from 1 = no sharing (they keep the whole blockreward), up to an arbitrary maximum of 600 (integer only).3) Clients will only share work history with other clients set to the SAME ease factor (as normal BTC client does) and building a chain of addresses up to {F} length (older address/submissions are dropped after normal btc chain confirms the new ones are validly added, maybe 12 rounds of normal btc chain adds) This will allow picking which network to work in based on your own variables and hopefully there will be some stats on the different networks block history to help choose where to start.4) If blocks are added too quickly, client can be set to automatically lower the ease Factor (go to {F} = {F} - 1), so every time the network gets to be at the critical size, it automatically slows down the fastest miners. I'd suggest 10 minutes as the target time for submitting blocks across each {F} network as a whole, and no single miner on each {F} network is allowed to submit 2 blocks in 10 minutes, unless the second is a winning block. So if a client would submit 2 in 10 minutes, instead it lowers down {F} factor.5) blocks are based off the current or previous main BTC blocks, so if work is submitted promptly, it must be included by the other miners onto the p2p block chain, with minimal stale blocks. It will use a similar check for adding blocks as the main client, with the added check of comparing the work to main client (current or previous round).6) If a winning block is found before {F} blocks were submitted, the winner keeps the extra shares.

EXAMPLE:At F = 600, XXX miners connect and mine fast, building the speed up to submit shares every 10 minutes. blocks are created, adding to the chain. at 400 chain length, the next block is a winner, giving winner 1/3 of reward (credit for blocks 1-199 & 600 -or- 1 & 402-600, depending how you count it), and the previous 400 submitters get rewarded for each block they added (200-599)After blocks are found faster, maybe if 100 blocks were added in last hour, triggers the split for all clients set to auto lower {F} - all client set to auto adjust go to (or create if necessary) a new network.Also, Any clients that find 2 blocks per 10 minutes will do the same. Being the first miners on any {F} will be just as good as being a later miner, allowing them to add blocks and start the chain, to eventually get all the shares contributed.On long rounds, the earliest shares contributed will not get rewarded, but that's a drawback for not contributing shares continuously.

The only way to make sure people you agree with can speak is to support the rights of people you don't agree with.

Keeping track of the last 600 shares in a distributed environment seems hard. Let me suggest an alternative for you that seems much simpler, and in fact I came up with specifically to design a decentralized pool:

noone in that thread understood it, but hopefully as a programmer it should be clear to you. The idea is simple: just auction the block reward to the N highest bidders, where a "bid" is a share and "high" means "low hash".

Keeping track of the last 600 shares in a distributed environment seems hard. Let me suggest an alternative for you that seems much simpler, and in fact I came up with specifically to design a decentralized pool:http://forum.bitcoin.org/index.php?topic=25540.0noone in that thread understood it, but hopefully as a programmer it should be clear to you. The idea is simple: just auction the block reward to the N highest bidders, where a "bid" is a share and "high" means "low hash".

Your method there is rather askew from the standard btc client and mining protocol, no?

The only way to make sure people you agree with can speak is to support the rights of people you don't agree with.