Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 646. (Read 2591920 times)

How it is possible that we see on graphs "Desired version" from 1 to 5?
v4 is just posted, so from where is v5?

o.k. I have now taken the Bitcoind and p2pool from git and anything is good.

Thanks.

Load zip form #1 post nad use stable p2pool on stable bitcoin...

Ok, I understand the difference between stable and unstable.

why did P2Pool need an unstable version of Bitcoin?

There is a reason why, if you are not beta-testing future versions, that you should just stick to release versions

-- Smoov

I use bitcoin with ubuntu/ppa. There is 0.6.3 the latest. Isn't 0.6.4 unstable?

I just git pull and complie...

LOL Ask Gavin. 

after upgrade of P2Pool this night i got :


2012-08-27 08:10:03.032304 >     Bitcoin version too old! Upgrade to 0.6.4 or newer!


where can i get the 0.6.4 bitcoin ? 

p2pool doesn't have a criteria.  Each individual p2pool node sets their own criteria.

You can look at the share chain and see if and how many shares were created that did include that transaction, but that doesn't tell you anything at all about the next share or the next block.

Thank you for the comments. First a small aside: regarding a competing tx getting into the blockchain before the first due to a higher tx fee, I don't believe this is the case. Ie if you broadcast send 10BTC from A->B with .005BTC fee and, 10 mins later, broadcast a tx from A->C with 1btc fee, I believe the latter is rejected. Otherwise I believe "race attacks" (is that the right name?) would be stupendously easy to implement.

I believe the hope is to reduce the trust you need in a pool that they will include your txn. If a centralized pool says, "yep, we got tx0, we're working on it!" you have to trust them. OTOH, if p2pool says, "consensus agrees that we got tx0, and the sharechain now requires we included it (if it matches eligibility criteria)!" you can believe this more likely to be true. Is this wrong?

Finally, AFAIK, you are correct about this doing nothing for many double spending attacks. Perhaps the benefit doesn't outweigh the cost.

Sorry I wasn't clear enough. This additionally functionality, as I interpret it, would allow a p2pool node to check the sharechain to see if a tx is going to be included or not, and know with certainty that if p2pool finds the next block, it WILL be included (if another pool finds the next block with a competing tx, then obviously all bets are off). If a tx doesn't meet p2pool criteria, it won't be added to the "include list" and it's inclusion won't be forced on p2pool by any means.

See your stats page and see wgo....

This would centralize control of p2pool, and would destroy it.  People mine on p2pool because it allows them to control the blocks that they create.  We will reject any proposal to force us to include transactions that do not meet our own local policy.

I didn't get any reward on the last few blocks. cgminer was running. p2pool was running.

Are you talking about something like regular unconfirmed transactions floating around the bitcoin network, waiting for inclusion into the next block?
So you would like to have p2pool say "we got this tx, will include it soon!"?

I don't see the advantage..
You can already see these [bitcoin] tx in your bitcoind (no idea if possible in a stock bitcoind) or on one of the pages, blockexplorer or the like. android bitcoin wallet shows tx too.
Now, seeing that tx there, or having additionally p2pool say to include it, makes no difference: as soon as someone else creates a conflicting tx, like a doublespend, and his tx gets included into the chain first (higher fees, quicker propagation, luck, he mined the next block himself), your original tx is down the toilet anyway.
p2pool is relatively small, so even if p2pool says "yep, will include your tx" as well as "..and we'll drop any future conflicting tx", it would only work if no other pool/miner finds the next block first and includes the unwanted conflicting tx.

So, what is your aim?

Ente

With 840 MH/s, you are getting 0.39/day (on 100% luck). Check if your average is close to it. Block reward doesn't matter, your average reward matter.

If it was your miner, it'll take 24 hours for your reward to increase.

Also, I know my rate varies from .8 to .9, roughly.  It seems to cycle, like a sine wave.  It's very peculiar, the entire hash rate across bitcoin seems to vary like that.

M

After luck improved I started using p2pool again (version 3.1 on win7x64). My hashrate is 840MH/s.

I ran it 24/7 for 3 weeks.

While it looked very promising at first - I got a constantly ~0.15 BTC per block - my reward started to decrease about 10 days ago. I got less and less for each block. At the moment it's only 0.03 BTC per block.

[EDIT] I just noticed that there were block where I got no reward at all. So it's like this over time: 0.15, 0.10, 0.7, 0.3, 0.0, 0.0 ...

First I thought it's a problem with my miner (cgminer 2.6.4) - so I restarted it.

But I still only get a reward of 0.03 BTC per block.

So p2pool must be the problem here.

Any ideas?

that is exactly what  I did and all is better with the world!

I wonder why it's so hard for them to put all these options in the GUI