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

[in2tactics]

I recompiled bitcoind with the --disable-wallet option on my node. I know p2pool definitely requires the -a or --address command when running with no wallet and is a good practice to use generally, but does it need any other options to run without a wallet?

What exactly do the -i or --numaddresses and the -t or --timeaddresses options do?

They are for dynamic addresses using bitcoin wallet and not required when you use -a or -address

numaddresses is the size of the new adress pool maintained, default 2
timeaddresses is how long to use an address before geting a new one, default is 2 days

I thought as much. The documentation for the -a or --address option stated "generate payouts to this address (default: <address requested from bitcoind>), or (dynamic)" and it was not clear to me that the -i or --numaddresses and the -t or --timeaddresses options were directly tied to the -a or --address option when operating under the default behavior. Thank you for the clarification/confirmation.

Are there any advantages, speed or otherwise, to using or not using a wallet with bitcoind for p2pool?

[1714000582]

1714000582

[1714000582]

1714000582

[kano]

Completely separating the wallet from mining means a few things:
1) The wallet actions don't affect your mining
2) The wallet code in bitcoind can be disabled and thus improve bitcoind performance
3) The contents of your wallet are not accessible from anything that can access your mining
4) Your wallet can be anywhere, separate machine, cold wallet, paper wallet, whatever

In general, keeping a wallet separate from mining is a very good security precaution.
Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,
but limiting all access to a wallet is a good thing

P.S. never have a wallet bitcoind online in anything that you don't 100% control.
Slush's lesson is a good lesson to learn regarding that ... a few years ago 10's of 1000's of BTC in his pool wallets on linode were taken by someone with access in linode through the back door that they purposely had in their system ... ... ...

[in2tactics]

Completely separating the wallet from mining means a few things:
1) The wallet actions don't affect your mining
2) The wallet code in bitcoind can be disabled and thus improve bitcoind performance
3) The contents of your wallet are not accessible from anything that can access your mining
4) Your wallet can be anywhere, separate machine, cold wallet, paper wallet, whatever

Got it!

In general, keeping a wallet separate from mining is a very good security precaution.
Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,
but limiting all access to a wallet is a good thing

I am confused about your hiding the mining bitcoind statement. What exactly is counter productive to distributing blocks quickly?

P.S. never have a wallet bitcoind online in anything that you don't 100% control.
Slush's lesson is a good lesson to learn regarding that ... a few years ago 10's of 1000's of BTC in his pool wallets on linode were taken by someone with access in linode through the back door that they purposely had in their system ... ... ...

Slush's Pool, yeah, I remember that. I own and run my own server stacks. I trust no one.

[kano]

...

In general, keeping a wallet separate from mining is a very good security precaution.
Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,
but limiting all access to a wallet is a good thing

I am confused about your hiding the mining bitcoind statement. What exactly is counter productive to distributing blocks quickly?
...

Well, to state the obvious, distributing from, and getting network blocks to, your bitcoind is of course the most important part of any mining network.
If you are working on old blocks, then you are trying to generate a block that wont be accepted.
If you find a block, you want it to get out and everyone else to work off it, not some other block.

For non-p2pool that's bitcoind connections, connection to the block-relay, and any other custom distribution you have.
For p2pool that also includes the p2pool network itself, since it's a block-relay also
(as I've said before about centralising p2pool is bad for p2pool since it reduces the effectiveness of that relay)

So, a lesser one of those 3 for p2pool mining is your bitcoind connectivity.
Of course you can say, well everyone else on p2pool distributes the blocks ... but that's the same as saying ... well maybe no one else on p2pool does either.
Thus:

Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,

[in2tactics]

...

In general, keeping a wallet separate from mining is a very good security precaution.
Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,
but limiting all access to a wallet is a good thing

I am confused about your hiding the mining bitcoind statement. What exactly is counter productive to distributing blocks quickly?
...

Well, to state the obvious, distributing from, and getting network blocks to, your bitcoind is of course the most important part of any mining network.
If you are working on old blocks, then you are trying to generate a block that wont be accepted.
If you find a block, you want it to get out and everyone else to work off it, not some other block.

For non-p2pool that's bitcoind connections, connection to the block-relay, and any other custom distribution you have.
For p2pool that also includes the p2pool network itself, since it's a block-relay also
(as I've said before about centralising p2pool is bad for p2pool since it reduces the effectiveness of that relay)

So, a lesser one of those 3 for p2pool mining is your bitcoind connectivity.
Of course you can say, well everyone else on p2pool distributes the blocks ... but that's the same as saying ... well maybe no one else on p2pool does either.
Thus:

Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,

Your initial phrasing was confusing because we were talking about running bitcoind without a wallet. I thought that you may have been saying, "running bitcoind without a wallet is counter productive to distributing blocks quickly." However, I now understand that you were pointing out the obvious that p2pool is hiding the mining from bitcoind and that p2pool is counter productive to distributing blocks quickly. Well, no shit! LOL That is the price individuals pay to operate their own trusted nodes on a trust-less network.

[kano]

...

In general, keeping a wallet separate from mining is a very good security precaution.
Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,
but limiting all access to a wallet is a good thing

I am confused about your hiding the mining bitcoind statement. What exactly is counter productive to distributing blocks quickly?
...

Well, to state the obvious, distributing from, and getting network blocks to, your bitcoind is of course the most important part of any mining network.
If you are working on old blocks, then you are trying to generate a block that wont be accepted.
If you find a block, you want it to get out and everyone else to work off it, not some other block.

For non-p2pool that's bitcoind connections, connection to the block-relay, and any other custom distribution you have.
For p2pool that also includes the p2pool network itself, since it's a block-relay also
(as I've said before about centralising p2pool is bad for p2pool since it reduces the effectiveness of that relay)

So, a lesser one of those 3 for p2pool mining is your bitcoind connectivity.
Of course you can say, well everyone else on p2pool distributes the blocks ... but that's the same as saying ... well maybe no one else on p2pool does either.
Thus:

Hiding the mining bitcoind is counter productive to having it distribute blocks quickly,

Your initial phrasing was confusing because we were talking about running bitcoind without a wallet. I thought that you may have been saying, "running bitcoind without a wallet is counter productive to distributing blocks quickly." However, I now understand that you were pointing out the obvious that p2pool is hiding the mining from bitcoind and that p2pool is counter productive to distributing blocks quickly. Well, no shit! LOL That is the price individuals pay to operate their own trusted nodes on a trust-less network.

No

I was referring to not having the bitcoind out in the open as much as possible as "hiding the mining bitcoind"

i.e. if you had a wallet on it also, there may be consideration of not having it too easily accessible, but without a wallet, there's much less issue about having it well connected and "in the open"

[in2tactics]

No

I was referring to not having the bitcoind out in the open as much as possible as "hiding the mining bitcoind"

i.e. if you had a wallet on it also, there may be consideration of not having it too easily accessible, but without a wallet, there's much less issue about having it well connected and "in the open"

I was confused. My bad!

So, if the node has a 0% fee, what does the -a or --address option do?

[Rabinovitch]

Graphs: http://p2pool.info/ http://forre.st:9332/

Both those links leads to the pages with some strange info. http://p2pool.info/ says that last block was found more than a year ago. http://forre.st:9332/ doesn't even shows a hashrate... 

Here we can se a more precise and actual stats: http://minefast.coincadence.com/p2pool-stats.php

But I like an official links...

[in2tactics]

I see the same error when running p2pool and bitcoind on the same (fairly underpowered) system, an asus eeebox with intel atom cpu. There are load spikes every now and then where bitcoind and p2pool together peg the cpu at 100% and then these errors appear. It seemed to cause more than average orphans and dead shares in my case so I now run p2pool and bitcoind on a faster system, and I've never seen the error there.

What error are you referring to?

[yvcea]

Hello,

I started to mine on P2POOL. My hardware is 5x Antminner S7. I'm posting to p2pool.science and I have few questions:

1) Why it seems to be like my earnings not always go up. I've watching them go a little down instead of slowly grow when I have slow hashing power.
2) Is the term: "payouts if a block were found now" true? I mean, never received a payment from p2pool net, but is it true? is actually the amount I earn if a block if found now?
3) I found in a webpage a term: "Expected Time to Block = 12d ...." Is it an expected time to get a block on the net?

Payouts seems to be higher than in antpool. Am I wrong?

Thank you!

[squidicuz]

Hello,

I started to mine on P2POOL. My hardware is 5x Antminner S7. I'm posting to p2pool.science and I have few questions:

1) Why it seems to be like my earnings not always go up. I've watching them go a little down instead of slowly grow when I have slow hashing power.
2) Is the term: "payouts if a block were found now" true? I mean, never received a payment from p2pool net, but is it true? is actually the amount I earn if a block if found now?
3) I found in a webpage a term: "Expected Time to Block = 12d ...." Is it an expected time to get a block on the net?

Payouts seems to be higher than in antpool. Am I wrong?

Thank you!

Hi there, that is my node!  

1) Payouts from the pool will vary depending on the overall hashrate of the pool.  Your expected payout will change from hour to hour, day to day, depending on the conditions of the pool and the shares you have found.
2) That payout is for the entire node; and is only if the pool finds a block and will vary depending on fees in the current block being mined and your valid shares.
3) Expected time to block for the whole pool right now is around 10+ days, so yeah.  That is just an estimate though and due to variation could be anywhere from a couple days to a couple weeks.

Just hang in there and monitor the chart for your workers, it will tell you the expected payout for your miner.  Your current mean payout is around 0.85 BTC.

If you run your own node, you may have better results (less latency issues).  If you need help in setting one up, PM me and I will assist you.

From what I noticed, some of your miners have issues at times and your DOA rate spikes.  I have the same issue with some of my S7's; they will just timeout and stop hashing and need to be rebooted, or just produce nothing but DOA work until they settle...  Everything else looks okay, and I tweaked my node [initially] to help your miners.  

The Node's efficiency remains above or around 100%. I mostly monitor that parameter, If that is around 100% all is pretty much well.

http://p2pool.science/1DHY.png

[Meuh6879]

v16 in progress (?)

[donatebitcointome]

v16 in progress (?)

http://imagize[Suspicious link removed]ageshack.us/a/img924/4648/xTK6zb.png

maybe yes maybe not.
the developer already turn off the p2pool vps (vps.forre.st) ?
developer abandon the project ?

[in2tactics]

v16 in progress (?)

It is possible, but the last commit I see on GitHub is dated Feb 22, 2016.

[veqtrus]

v16 in progress (?)

It is possible, but the last commit I see on GitHub is dated Feb 22, 2016.

It's my pull request.

[jtoomim]

Unfortunately the issues remain the same as they've always been and the suggestions for how to get more people to use p2pool haven't changed in years but none of that is working. I don't see a revolutionary way out of this predicament unless it's totally redesigned. Alas I don't think anyone has solutions for the existing design even if they were to start from scratch again.

I do, but I haven't had time to implement it. The ten cent version is that money grows on trees, not chains: we need to switch over to a share DAG instead of a share chain. I have in mind a DAG in which every odd height contains only one share, and every even height contains a large number of sibling shares. I would still need to do some simulations and/or analysis to make sure I've got all the incentives right, but so far I think it should work. A variant of the GHOST protocol would likely work also, and would have the benefit of being better studied.

[Carlton Banks]

@jtoomin

it helps if you actually deliver any of your BrandNamedTechnologies^TM, or your idle musings about applications of brand new mathematics. On an actual day. Any day will do.

[in2tactics]

Unfortunately the issues remain the same as they've always been and the suggestions for how to get more people to use p2pool haven't changed in years but none of that is working. I don't see a revolutionary way out of this predicament unless it's totally redesigned. Alas I don't think anyone has solutions for the existing design even if they were to start from scratch again.

I do, but I haven't had time to implement it. The ten cent version is that money grows on trees, not chains: we need to switch over to a share DAG instead of a share chain. I have in mind a DAG in which every odd height contains only one share, and every even height contains a large number of sibling shares. I would still need to do some simulations and/or analysis to make sure I've got all the incentives right, but so far I think it should work. A variant of the GHOST protocol would likely work also, and would have the benefit of being better studied.

If by DAG you mean Directed Acyclic Graph, I fail to see how that solves the problem much less even addresses the problem -ck was referring to.

[jtoomim]

If by DAG you mean Directed Acyclic Graph, I fail to see how that solves the problem much less even addresses the problem -ck was referring to.

The problems with p2pool performance are that (a) miners have to switch work frequently, which causes switching losses (which are particularly bad for Antminers, due to bad firmware, but are also problematic for high-latency connections, or for p2pool nodes with slow CPUs), and (b) the amount of variance a small miner experiences is inversely proportional to the time in between each share. If you have each miner switch work once per share, these two issues are in opposition to each other, and you have to pick a share frequency that balances these two issues.

However, there is no need to have miners switch work once per share. Bitcoin's blocks and transactions need to be serialized in a canonical ordering in order to prevent double-spending or transaction conflicts, but with p2pool there's no equivalent need for each share to come one after another. All that a share needs to do is prove that work was done in a way that benefits other p2pool users, which means (a) accurately pays out to other p2pool users and (b) is working on the correct block height at any given time.

So instead of arranging the shares as a chain of single-parent single-child links, we can come up with more imaginative arrangements. My favorite is where the first share for a new block (the switcher) gets a revenue bonus, and that switcher refers to not one parent share but as many parent shares as you know of, and the size of the switcher's bonus is proportional to the number of parents it has. Once one or more switchers have been found, the other shares (the fillers) refer to a single switcher as the parent. If there are multiple competing switchers to build off of, then the miners will want to choose the switcher that has the most fillers already laid on top of it, as those fillers will give the next switcher the greatest revenue bonus on the next block. Thus, consensus quickly emerges around one switcher, and everyone goes happily on their way. Miners only have to switch work twice per block, and you can get a 1 second (or faster) share time instead of the 30 seconds we tolerate now.

Since the miners don't have to switch work as often, the pool software doesn't have to do as much work (and only needs to recompute rewards twice per block), which means that python's performance issues will become less important.

The GHOST idea is basically that you reward uncles fractionally in the share chain. This should also work, but you'd have to tweak it a bit versus e.g. ethereum's version of GHOST if you wanted to allow for a significantly lower work switching rate than share rate, and it would probably be difficult to get it to perform as well as the odd/even heigh scheme described above.

[jtoomim]

it helps if you actually deliver.... On an actual day. Any day will do.

Any day, huh? How does 3650 days from now sound to you? /s

Unfortunately, taking care of my mine is more than a full time job, and it doesn't allow me much time to volunteer for large projects like rewriting p2pool or finishing blocktorrent. (Between the two, blocktorrent is a much higher priority.) Often, the best I can do is jot down ideas and hope that someone else finds them interesting enough to implement.