[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[roy7]

okay I will wait a bit longer to see what happen, but it used to never to this, both miners always showed  predicted payouts. On a different note the p2pool-note-status static page has been updated, it now shows the "payout if block were found now".

"Predicted payouts" is misleading because it sounds like you will be getting a payout. It's actually just the total value of your shares in the share chain at that moment, same as if you click on Payouts on the Extended interface. If a block it paid out right then, that's the amount you'd get paid, because that is your total share value in the share chain. It doesn't mean the pool will find a block (you might get paid zero). The pool could also find many blocks (you'd get paid that for each of them).

On my nodes I've changed it to say "Your Share(s)", hoping it's more intuitive that way.

[1714149486]

1714149486

[1714149486]

1714149486

[1714149486]

1714149486

[jedimstr]

Are there any benefits/limitations/issues with using alternative blockchain daemons with a p2pool node instead of the standard bitcoind/Bitcoin-qt?

I'm currently using the Bitcoin-qt OMG client with wallet disabled.

Was thinking along the lines of btcd which is currently in alpha or some other optimized client.

[zvs]

re: creating p2pools for alt currencies
(...)

Ure right, removed it on my fork
https://github.com/Rav3nPL/p2pool-rav/commit/a19b69536f0e79869a863b6603459e1055441a1a
Will restart all my nodes one by one to make it happen.

ah, nice, just noticed this

i'll probably start up the doge pool again

ah, long live doge, too boring to monitor all the new shitcoins, just leave it on there for a month or so

[GVanelly]

 if I ran my miner over night will I see the results are back on track?

[Tegija]

if I ran my miner over night will I see the results are back on track?

depending of miner hash rate you will see full results first in 3 days. if block is already longer "in work" you will not get/reach in first block full payout. P2pool is hop-proof pool.
in some alcoin p2pools you can see results earlier depending of block frequency of this coin and several other factors.

[smooth]

Anybody have any ideas how to increase the hash rate? We are sinking to a smaller and smaller percentage of the network, and round times are growing. We're having 4 day rounds now, a few more difficulty jumps and it may be weeks or longer.

Something must be done.

[forrestv]

Anybody have any ideas how to increase the hash rate? We are sinking to a smaller and smaller percentage of the network, and round times are growing. We're having 4 day rounds now, a few more difficulty jumps and it may be weeks or longer.

Something must be done.

I'm working on a revamp of P2Pool that will give us a few key features that will help:

• Running a "lite" P2Pool instance - one without a full Bitcoin node - will be possible without losing any of the promises P2Pool makes about its contribution to Bitcoin network health
• P2Pool will have a non-linear sharechain so that we can have shares more often than 30 seconds, allowing small miners to use P2Pool

Both of these make P2Pool easier to use; the eventual goal is being able to run P2Pool on the same hardware miners use, such as a Raspberry Pi, though that would likely require a laborious rewrite in C++ or another compiled language.

My current progress on this: I have a piece of software talking to bitcoind and augmenting blocks with UTXO merkle branches, feeding that to another piece of lightweight software that can trustlessly verify the blockchain, while holding O(1) state. I have a good idea about how the non-linear sharechain will work, but implementing that hasn't started yet.

[smooth]

Both of these make P2Pool easier to use; the eventual goal is being able to run P2Pool on the same hardware miners use, such as a Raspberry Pi, though that would likely require a laborious rewrite in C++ or another compiled language.

Pypy works fine with the current p2pool code, have you tried that? Not quite sure about a RPi, but it should help on a lot of small hosts.

Re: The rest.

Looking forward to it. Good stuff.

[oldbushie]

Those would definitely entice a lot more people to give it a try. Good luck!! I have a dream that one day we will reach 500 TH/s.

[smooth]

Those would definitely entice a lot more people to give it a try. Good luck!! I have a dream that one day we will reach 500 TH/s.

Too low. In six months 500 TH might well be just one block a week. This is do or die time for p2pool. If adoption doesn't pick up soon, we are facing a death spiral and the need for a full relaunch (which might be okay)

[smoothrunnings]

Is there anyway to disable the wallet function in P2Pool and have it instead forward the percentage of shares the note is to receive to a different wallet?

I have hit a stumbling block; over a week a go I initiated a transfer of over 1/2 a bitcoin and Bitcoin-QT told me I need to account for 0.0004 of the fee, so I did that and ever since the transfer has been in limbo, it looks like bitcoin-qt gave me the wrong fee to account for it if I understand the blockchain correctly.

https://blockchain.info/tx-index/7bbbc7b5fac8c2973e9c62a17cead946b9cf1832aac47479799ce566fafabcc1

Also I need to figure out if can fix this issue or have I lost those coins?

Thanks,

[jedimstr]

Is there anyway to disable the wallet function in P2Pool and have it instead forward the percentage of shares the note is to receive to a different wallet?

I have hit a stumbling block; over a week a go I initiated a transfer of over 1/2 a bitcoin and Bitcoin-QT told me I need to account for 0.0004 of the fee, so I did that and ever since the transfer has been in limbo, it looks like bitcoin-qt gave me the wrong fee to account for it if I understand the blockchain correctly.

https://blockchain.info/tx-index/7bbbc7b5fac8c2973e9c62a17cead946b9cf1832aac47479799ce566fafabcc1

Also I need to figure out if can fix this issue or have I lost those coins?

Thanks,

-a bitcoinAddress

[smoothrunnings]

Is there anyway to disable the wallet function in P2Pool and have it instead forward the percentage of shares the note is to receive to a different wallet?

I have hit a stumbling block; over a week a go I initiated a transfer of over 1/2 a bitcoin and Bitcoin-QT told me I need to account for 0.0004 of the fee, so I did that and ever since the transfer has been in limbo, it looks like bitcoin-qt gave me the wrong fee to account for it if I understand the blockchain correctly.

https://blockchain.info/tx-index/7bbbc7b5fac8c2973e9c62a17cead946b9cf1832aac47479799ce566fafabcc1

Also I need to figure out if can fix this issue or have I lost those coins?

Thanks,

-a bitcoinAddress

do I need to add anything to the bitcoin.conf?

[roy7]

-a bitcoinAddress

do I need to add anything to the bitcoin.conf?

Not to change the node fee payment address. -a sets that address, as jedimstr said above.

[freebit13]

Both of these make P2Pool easier to use; the eventual goal is being able to run P2Pool on the same hardware miners use, such as a Raspberry Pi, though that would likely require a laborious rewrite in C++ or another compiled language.

I think this will be a major win for p2pool, at the moment not everyone can run their own node 24hrs and it's not the same running on someone else's node, I would p2pool if I could run it on my miner.

Who knows, in the future miners could come with p2pool pre-installed, just plug in and go... that would be a win for p2pool and for Bitcoin.

Looking forward to it... thanks for all the hard work forrestv!

[roy7]

I have a good idea about how the non-linear sharechain will work, but implementing that hasn't started yet.

I think that sounds awesome. The thing is the disk space for the share chain isn't that big of a deal, it uses no space really compared to the bitcoind blockchain itself. And older shares once expired don't need to be saved forever. If the sharechain can work more similar to a normal PPLNS share database at centralized pools, that'd be a big win for smaller miners. (Some way to accumulate tiny shares without paying them until they exceed the dust level might be useful, but prone to abuse if someone tries to flood the sharechain with changing addresses just to bloat it.)

One option is that all stales still get passed around like valid blocks, and payments are based on all valid + stale blocks. It isn't like bitcoin where we actually need a single chain with a record of transactions. We're only using the chain's POW so we don't have to trust clients on how much work they are reporting.

Another thought on the dust issue for small miners with tiny shares is when they are served work, that work include the prior shares value that was too low to pay. That is, a normal miner finds shares A B and C. When calculating payouts, that miner is going to be paid A+B+C until those shares start to expire off the chain. A small miner finds share A that is below dust level. They don't appear in the Payouts list. However, when serving work to miner A, they are served a share to work on that includes the diff value from share A. When share B is accepted, share A is invalidated and share B has the value of A + B's new work. If B is > DUST, it goes into Payouts list. If not, then when small miner finds C, C will include B and B is invalidated.

The thought for doing DUST this way is the tiny miner can keep building a balance without storing every tiny share on the chain, and their dust won't expire off the chain before it can grow above the payment threshold since the share's age resets on each new share found. If the miner is so small they can't find even a tiny share consistently within the PPLNS window, they they probably need to mine something else. This might be more appropriate for a pay-once PPLNS structure though and not the traditional PPLNS window p2pool uses now.

(BTW, I've never looked, but p2pool needs to store the block (share chain?) difficulty when work is served so that can be logged on the share chain with the share, and payments based on the diff of work done vs diff of the block, not just the diff of the work done. Otherwise people get unfair rewards around diff changes and the pool is hoppable.)

[smoothrunnings]

-a bitcoinAddress

do I need to add anything to the bitcoin.conf?

Not to change the node fee payment address. -a sets that address, as jedimstr said above.

So I don't need the disablewallet=1 in bitcoin.conf correct, only need to add the -a {address} to my P2Pool startup string?

 

[jedimstr]

-a bitcoinAddress

do I need to add anything to the bitcoin.conf?

Not to change the node fee payment address. -a sets that address, as jedimstr said above.

So I don't need the disablewallet=1 in bitcoin.conf correct, only need to add the -a {address} to my P2Pool startup string?

 

No, you don't "need" it... but I use disablewallet=1 anyway since I only use bitcoin-qt (or bitcoin core since that's what we're calling it these days) for it's blockchain RPC and not as a wallet.

Note: disablewallet=1 only works on bitcoind/bitcoinqt OMG10 and 0.9.0 rc2 at the moment (that I know of).

[smoothrunnings]

-a bitcoinAddress

do I need to add anything to the bitcoin.conf?

Not to change the node fee payment address. -a sets that address, as jedimstr said above.

So I don't need the disablewallet=1 in bitcoin.conf correct, only need to add the -a {address} to my P2Pool startup string?

 

No, you don't "need" it... but I use disablewallet=1 anyway since I only use bitcoin-qt (or bitcoin core since that's what we're calling it these days) for it's blockchain RPC and not as a wallet.

Note: disablewallet=1 only works on bitcoind/bitcoinqt OMG10 and 0.9.0 rc2 at the moment (that I know of).

Not sure what OMG10 is? I use bitcoin-qt 0.8.6 on my P2Pool.

[cr1776]

I have a good idea about how the non-linear sharechain will work, but implementing that hasn't started yet.

I think that sounds awesome. The thing is the disk space for the share chain isn't that big of a deal, it uses no space really compared to the bitcoind blockchain itself. And older shares once expired don't need to be saved forever. If the sharechain can work more similar to a normal PPLNS share database at centralized pools, that'd be a big win for smaller miners. (Some way to accumulate tiny shares without paying them until they exceed the dust level might be useful, but prone to abuse if someone tries to flood the sharechain with changing addresses just to bloat it.)

One option is that all stales still get passed around like valid blocks, and payments are based on all valid + stale blocks. It isn't like bitcoin where we actually need a single chain with a record of transactions. We're only using the chain's POW so we don't have to trust clients on how much work they are reporting.

Another thought on the dust issue for small miners with tiny shares is when they are served work, that work include the prior shares value that was too low to pay. That is, a normal miner finds shares A B and C. When calculating payouts, that miner is going to be paid A+B+C until those shares start to expire off the chain. A small miner finds share A that is below dust level. They don't appear in the Payouts list. However, when serving work to miner A, they are served a share to work on that includes the diff value from share A. When share B is accepted, share A is invalidated and share B has the value of A + B's new work. If B is > DUST, it goes into Payouts list. If not, then when small miner finds C, C will include B and B is invalidated.

The thought for doing DUST this way is the tiny miner can keep building a balance without storing every tiny share on the chain, and their dust won't expire off the chain before it can grow above the payment threshold since the share's age resets on each new share found. If the miner is so small they can't find even a tiny share consistently within the PPLNS window, they they probably need to mine something else. This might be more appropriate for a pay-once PPLNS structure though and not the traditional PPLNS window p2pool uses now.

(BTW, I've never looked, but p2pool needs to store the block (share chain?) difficulty when work is served so that can be logged on the share chain with the share, and payments based on the diff of work done vs diff of the block, not just the diff of the work done. Otherwise people get unfair rewards around diff changes and the pool is hoppable.)

There are good ideas in here, particularly about the dust transactions for smaller miners.  Perhaps increasing the window too would be helpful with that change in order to accommodate smaller miners in the future.