The largest issue remains collusion between players a new blockchain doesn't solve that.

You sit down at a virtual table and 5 of the 9 oponents are all part of a team sharing cards, strategy, etc.  You have no hope of winning.

Simple version:
p2pool (your node or any node) only has knowledge of the single payment address used.  Without -a it is a random address from the wallet (which changes on each run).  With the -a option it is the address you provide.  All compensation (block subsidy, tx fees, donations, etc) are split among all node's addresses by hashing power.

All nodes (not just yours) split the total block reward by the % each address has in the sharechain.  Anything else would be an invalid share.

More complex:
tx fees are part of block reward.  subisdy + tx fees = block reward.  For each getwork every node takes all the shares in the sharechain and determines what % belong to each address.  It then builds a coinbase sending that % of total block reward to each address.  If address a has 1% of shares in sharechain it gets 1% of reward, if address b has 10% it gets 10% of the reward. 

Maybe forrestv should slow the refreshing.  That is a legitimate point.  Even better may be someone extending the application to provide a nicer interface (GUI or web based) which would provide updated stats.

There also should be better explanation as to what all the info is.


Current payout = your cut of the block reward.  It IS per payout, you only get paid when a block is found.  If the block was found right now you would earn 0.1276.  If another block was found 2 seconds later you would earn another 0.1276.  If a third block wasn't found until 52 hours later you would still earn another 0.1276.

The number will only change if your % of the p2pool hashing power changes.  If you make up 2% of the a pool (any PPLNS pool)  you will earn ~1BTC per block (excluding tx fees).  That won't change unless either your hashing power or pool's hashing power changes.

An estimate per 24 hour average would be a useful enhancement.


Well there is no such thing as unpaid rewards in p2pool.  Your payment is part of the coinbase.  You get paid when block is found so your unpaid reward is continually 0.000 BTC forever.  That likely needs to be made more clear.


You could use -a option set a static reward address and have all payments go to a single address.


There is no such thing as a "current balance". Rewards are sent instantly to the address you specify.  p2pool never holds an funds in reserve.  The address doesn't need to be on the machine being used. 


Use the -a option.   Delete the copy of the wallet if it has any value and bitcoind will make a new empty wallet (which you will never use for anything).  p2pool needs bitcoind, it doesn't need a wallet.  There is no option to run bitcoind as just a bitcoind with no wallet but it doesn't mean you need to use it.

The "-a" option lets you set any valid Bitcoin address as the address to pay rewards.  I don't really see any difference from a "conventional pool".  Do you?


I think these posts simply reinforce the fact that p2pool is very flexible but it is hobbled by beyond horrible documentation.   It needs very detailed, comprehensiveness documentation because nothing you have expressed indicates a problem with p2pool and instead shows a lack of understanding.  Not your fault it currently requires a lot of reading, asking questions, checking forum threads, etc to get a good understanding of p2pool.  That needs to change.

Core isn't underclocked.  Stock for 5970 is 725.

Correct.  
cgminer has no knowledge that the share eventually becomes orphaned.
p2pool sends all valid blocks to bitcoind which broadcasts it to the bitcoin network.

The data flow is like this

1) cgminer finds share and submits it to your local p2pool node.
2) At the local p2pool node
   a) If the share is a block level solution it is relayed to bitcoind and broadcast to bitcoin network (block is also relayed to all peers so they can simultaneously broadcast it via their bitcoinds).
   b) If the share is DEAD (already invalid/stale) it is not forwarded or broadcast.  Dead counter incremented by one
   c) if it is valid share but not a block it is relayed to peers for inclusion in blockchain
3) At peer p2pool node
   a) If peers find the share as valid they include it in their sharechain and notify all other peers (causes an LP across p2pool network)
   b) If peers find that share height is already in the sharechain they respond with ORPHAN notification.  Local p2pool node increments OPRHAN counter by one.

That is less hacky than a tx?

Um there is a windows binary right on the first page.  The only other thing needed with the windows binary is bitcoind (which will always be necessary).

From the OP:


It displays hashrate, sharecount, and expected return every second.


What else could it provide that says "everything is working"?


Now that it is setup it requires no more extra work than a normal pool.  You have already done all the "extra work" that will ever be required.  You have your "own" pool which protects the network requires no additional work, has no fees, and pays out all tx fees.   Most p2pool users see it as a useful way to decentralize bitcoin.  

I do agree the largest thing missing is solid, clear, and detailed documentation outside of the forum.  If I ever get some time I will start work on a comprehensive wiki.  If you have a specific improvement please name it but simply saying things like "it was confusing" doesn't really help.

No. There is no linear relationship.  If all the p2pool node were on low latency links so they could share new shares in sub 100ms to to every other node of the network then it is possible it would have ~0% orphan rate even with a 10 second (or possibly 1 second) LP interval (time between shares/blocks).

Still reducing orphans to 0% achieves nothing.  Shares have no value.  They are simply a method of fairly and accurately recording work.  They record utterly useless and worthless work simply because there is no know method to fake it.  

Lastly your ~60 stales doesn't make any sense?  ~60 stales when over what time period involving what number of nodes?

Without access to the boards and some testing it is hard to say for sure.  Maybe their design is optimal but it would seem to be.  Even non-optimal maybe the design has enough airflow to keep everything coo.

If I purchase a mini-rig the first thing I would do it open it up.  I actually had little interest in the rig or mini-rig until finding out it looks like the boards are independent.  Hopefully BFL can confirm that.  BFL can the boards function removed from the rig box and connected to a host PC via USB just like the single's do?  If they boards can operate independently and they allowed pre-ordering with a deposit (say $2K) I would order today but I don't like locking up $15K on a product which hasn't even been built yet and some questions remain.

The first though I had when looking at the CAD is the 18 individual fans are counter productive to the airflow going across the boards.  I would experiment by turning all the board on their sides and using pusher and puller fans to try and force airflow front to back.  Maybe my time in datacenters is causing tunnel vision but that type of design allows multicore database servers to remain cool under higher load.  Cold air in the front, hot air out the back.

The heatsink chosen is non-optimal for that kind of airflow but it still may work depending on heat load.  Preferably one would want a heat sink with has large number of fins aligned with the direction of airflow so cooling is achieved by pushing airflow across the finds.

Something like (top view)

B = one board placed perpendicular.  View is top view so you are looking at the sides of the boards.
B

3 ranks of 6 boards = 18 boards (although no room for expansion).
You would want a baffle or shroud to force the air past the heatsinks.  So the exact layout would require some testing, experimentation.


I would imagine you could fit it in a standard 19" rack chassis.  Maybe 4U?.  I wouldn't put 10 in a datacenter rack but maybe 8 with 1U between servers.  200GH/s per rack?  

Anyways that was my first thought.

canicula is a troll who spreads anti Bitcoin FUD (either as a paid agent or simply as a jealous idiot I am not sure which).  

Still he isn't a traitor and I am sure the founding fathers would agree.

Addresses & wallets don't have unified value that is just an abstraction.  Each input must be a prior TX output.  If your wallet says you have 30.5 BTC it simply means (as an example) your wallet has the following unspent outputs.
10 BTC, 1.3 BTC, 20 BTC, 0.2 BTC.

Your wallet had no outputs that sum up to EXACTLY 11.  If it idid it would have sent that and no change would be needed.  If it had found a set of tx which sum up to 11.1 it would have sent that instead (and given you 0.1 change back).  If the only unspent output you had was a single 10,000 BTC it would have sent that and sent 11 to receiver and 9,989 back to a change address.

Think of each output as a bill.  Lets imagine you wallet has the following bills:
10 BTC bill
1.3 BTC bill
20 BTC bill
0.2 BTC bill

you owe me 11 BTC how would you pay me?  
how much change (in form of new bills) would I have to give you back?
Obviously you have a couple different options but which one makes the most sense?

Both inputs are addresses in your wallet.

Bitcoin doesn't work on the concept of "value" in an address it works on the concept of prior outputs.

All inputs all prior tx outputs.

Bitcoin can't spend part of an output.

So your wallet took
A prior tx output worth 10 BTC from one address.
A prior tx output worth 1.3 BTC from a second address.

You spent 11 BTC so that was sent to the receiver's address.  

Remember Bitcoin can't spend part of an output.  You have inputs worth 12.3 and 11 going to the destination so that leaves 0.3 left.  WE call that the "change".

The remaining 0.3 BTC was sent back to YOUR wallet in a brand new (as in never before used) address.

You may not recognize all these addresses because to provide anonymity your wallet will generate a never before used addresses for "change" automatically on each spend.  

I am lazy.  Often with a hung or crashed rig I just flip the PSU power switch off and on (with BIOS set to always power on after AC loss).  So I will stick with a manual sync just to be sure.  Still I intend to move to a PXE solution eventually (too many things to do) which makes it moot.

For people who do it "right" that is a useful feature.  I didn't realize you could make an alias of an existing command so I learned something.  Makes me wonder why the developer of BMAT uses the non-intuitive commmand "coldreboot" (which IIRC does some housekeeping before rebooting) instead of just aliasing "reboot" and "poweroff"?  Maybe he was unaware of that too?

Among non-lost coins I agree however "lost" coins will never be automatically sunset or moved by the owner to strong addresses because they are lost.  

Even then I am not saying action IS REQUIRED just that it MAY be required and certainly should be analyzed at that point.


The market will always adjust to the equilibrium price however such adjustments can be disruptive if there are large increases in supply or demand.  Those disruptions themselves can be damaging to the currency.

The other risk is that eventually "treasure hunting" becomes a more profitable venture that protecting the network.  Obviously that is in no-ones best interest.  Once again not saying it WILL happen but imagine a situation where ECC is significantly compromised.  As Bitcoin increases in value, the cost to brute force one private key falls (both due to deeper crypto flaws and Moore's law) the BTC per "GH/s equivelent" will rise.  If it is ever higher than block reward then it becomes more profitable to treasure hunt then protect the network.  Miners likely will do that leading to a tragedy of the commons scenario.  They may even form large hunting pools to reduce variance.

Still discussing it now is premature.  We don't know if ECC will be compromised.  We don't know how long such a compromise will take, we don't know how many coins will remain in compromised addresses.  If may never become "economical" to hunt for lost coins.  Even if it becomes economical the rate that lost coins are found may not be disruptive.  I am just saying that if ECC is compromised there MAY be a need for sunsetting compromised addresses.

If we did need to sunset "legacy" addresses I would advocate for permanent coin destruction rather than confiscating.  It removes the moral hazard.

The issue with the thread is it seems to things which are unnecessary are being advocated:
a) sunset addresses even if no compromise occurs
b) confiscate the wealth

Even if you agree that massive market disruptions are damaging neither are needed.  If the coins are spent after long inactivity and addresses algorithm isn't compromised then the coins were never lost.  It would be no different than Satoshi today dumping 1M+ coins on MtGox.  While not the smartest decision nobody has a right to say he "can't" and we need to confiscate the coins to make sure he doesn't.    If ECC algorithm isn't weakened there is no risk of large amounts of truly lost coins being "found".

On confiscation of wealth that is just asinine.  If the risk is not knowing if coins are truly lost then simply make them permanently lost with no profit to anyone.  The network doesn't need to have exactly 12.00000000000000000000000000000000000000000000 M BTC in circulation.   Giving the wealth to someone else creates a moral hazard.  Just destroy the coins instead.

p2pool does support longpolls.

orphans in p2pool aren't the same as other pools.  They aren't lost work they are simply a limit of the sharechain only being able to make 1 share become the next share.  

The key thing to remember is that shares are worthless.  They have absolutely no real value.  Shares are just used as a work tracking mechanism that can't be cheated.  

p2pool has a high orphan rate because the network finds one share every 10 seconds (vs 600 sec for Bitcoin).    When two nodes submit a share at roughly the same time only 1 can become the next share in the chain and the other is orphaned.   Blocks are subject to p2pool internal orphans because they don't go into the sharechain, the node finding it broadcasts it directly to Bitcoin network (and relays it to all p2pool nodes).

That isn't to say orphans don't matter at all.  For p2pool oprhan rate what matters is your stale vs network stale.  If they are similar then you will earn at same rate .

An example may help.
Say you generate 10 shares per hour and the network generates 1000.  Both you and the network average have an orphan rate of 10%.

Work completed:  
You 10, network: 1000, 10 / 1000 = you contributed 1% of work

Shares orphaned:
You 1, network 100,  1/100 = your orphans are 1% of all shares orphaned

Work recorded in sharechain:
You 9, network 900,  9/900 = your share of reward is 1%

You provided 1% of the total work and got 1% of the reward.


dead on arrival is more comparable to a conventional pool's "stale rate".  It is work that your p2pool node determined was invalid by the time it was received.  In a similar fashion a conventional pool marks shares as stale if they are invalid by the time received by the pool.  

You should strive to keep that number as low as possible to increase your profits and to make p2pool more efficient.

To lower your DOA in cgminer you may want to try the following settings:
threads per GPU: 1
queue: 1
intensity: 1 lower than w/ conventional pools (i.e. for 5970 I use I:9 on normal pools and I:8 on p2pool)

TL/DR version:
1) p2pool stales aren't comparable to other pools because they include internal share orphans.
2) As long as your stale rate is comparable to the p2pool avg you will earn the same amount
3) DOA are more comparable to stale rate in other pools.
4) To lower DOA rate use "faster" cgminer settings (less threads, smaller queue, lower intensity)

Well scrypt would be an option.  Possibly one with a massive lookup table which requires significant amount of memory.  This would make dedicated devices difficulty.  Any protocol could also support changing hashing protocol significantly enough every say 12 months to make cost of ASIC development prohibitive.

Still I agree now there would be some merit to using Bitcoin, it effectively prevents the scammer from getting a shortcut.  If they could mine coins faster then they don't need to spam.    The micropayment issue is still a steep one.  So it comes down to does the flexibility of Bitcoin based system have higher utility.

On edit: While writing I thought over another advantage of Bitcoin.
The rise of "lite clients" also make any work based solution hard to get off the ground.  I use gmail so any PofW isn't done by me it is done by google.  The PofW for 2 million legit users is staggering and I doubt that is a cost google wants to deal with.  That means google is less likely to embrace PofW system and the network effect suffers.  Using Bitcoin the cost (negigible as it is) is paid by the user so there is no pass through cost to Google other than implementation.

The good news is that everything indicates 1 RigBox = 18 independent "super singles".  So custom cases and cooling would be possible.  With mounting holes on the boards finally (yes this applies to all FPGA designers releasing a board w/ no mounting holes is asinine) even watercooling would be possible. 

Still I agree the airflow seems .... inefficient (I am trying to be more nice).

I wouldn't see why immersion cooling wouldn't also be an option.

Having a vote option of "maybe, undecided would be useful".  If forced to pick right now I would just say "No" as I don't see value of Bitcoins over native PofW.  Still I will just abstain because there may be some merit.

It is interesting and I would use it if such a system already exists and had a large enough network.

The two largest problems are:
a) network effect.  if 1% of my legit emails are on the network it does very little good.  I still need to do massive filtering to find the other 99% "legit but not on network emails"
b) micropayment issue.

On the micropayment issue there already are non-payment proposals to prevent spam involving PROOF OF WORK.  Essentially when someone emails you then need to performs a certain amount of work (few seconds of CPU time on avg computer) and sign the email.  The main problem is the network effect.  If only 1% of your legit emails are using such a system it isn't effective.

Most spam solutions would work if they had a large enough network effect.  By using Bitcoins you are simply swapping coins = manifestation of work already completed with direct proof of work.  The same network effect limit exists.  So even if you accept that generally speaking PROOF OF WORK is a valid defense against spam you have to look carefully at the INCREMENTAL BENEFIT and INCREMENTAL COST of using bitcoins vs native proof of work.

For example bitcoins would allow a "weak system" (like say a tablet) to send email as quickly as a powerful workstation but it adds the "cost" of handling micropayments.  The question becomes does the complexity of micropayments outweigh the "cost" of ipad user having emails delayed say 7 seconds while they complete the PoW?  At first glance I would say ... no but am willing to hear some arguments.


Note: proof of work is a theoretical defense to any systems where the "attack" is "cheap" by increasing the cost of the attack.
http://en.wikipedia.org/wiki/Proof-of-work_system

No need for user/pass.  If bitcoind is on the same machine as p2pool, p2pool will read pass from config file.