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

These spikes in hashrate are from people renting hashrate from Nicehash, usually to take advantage of merged mining income. As is often the case with Nicehash renters, this person seems to have had high DOA rates (~10%) during his hashing burst, which would subtract from his profitability. My guess is that the DOA rates this miner is getting are higher or equal to the revenue bonus he is getting from the merged mining, which means that he will probably stop after he has re-evaluated his profitability using experimental data instead of his predicted revenue.

If anyone is thinking of doing a Nicehash burst on p2pool, I suggest they let me know first. There are a few configuration changes they can make in order to improve their node performance, and there are also some code changes I've got on my to-do list that will improve fairness for miners with high vs. low hashrate and high vs. low latency.

When I started before the Jtoomimnet split off mainnet was hashing in the Phash range now it in the low Thash range ...

Yet everyone seems to keep a small portion of their miners pointed at mainnet

sitting the fence is discouraging and disrupting ...

Shrugs ...

It seems that the p2pool master branch is back in business  . Currently >7000 TH. However, it still fluctuates a lot during the day. A few hours ago only 400 TH.

Hello,

I suppose you want to know your mining reward. You should be able to find it in the web interface of your P2pool node reachable through http://YOUR_P2POOL_HOST:9332/.  It should give you statistics about the payout you would get if the P2pool network finds a block now (see under "Payouts if a block were found NOW:"). If you use the default bitcoin address for your payouts, then normally you should find a plot under the link "graphs". If you use a different address it will show 0.
You can also find this information when you go to the web interface of a public node. Normally they should also list the "Payouts if a block were found NOW:". Pick a public node that follows the P2pool share chain you use for mining (jtoomim branch or master branch).
You will only find a quantity different from 0 under "Payouts if a block were found NOW:" if your miners have found at least 1 share in the last 3 days in the share chain.
Also, the "Payouts if a block were found NOW:" quantities are potential payouts. They only become real when the P2pool network finds a block that is accepted in the Bitcoin blockchain. So it may take a while before you get a real payout.

I hope this answers your question. You can find more information on http://p2pool.in/ and http://p2pool.org/.

How I can see fees for my node? Workers are in there, but I dont see money. ^)

Or add the --allow-obsolete-bitcoind command-line switch when running run_p2pool.py. That is mentioned in the error message.

Frodocooper posted exactly that two posts before yours.

is the same as https://github.com/p2pool/p2pool.git (the master branch that is).

Yeah i tried that version initially and it was screaming error messages at me that ultimately would have required me to change my core wallet... and it seemed odd... it seemed to have an agenda... so that's when i found your version.  I believe to get 17.1 it was as simple as:

"git clone https://github.com/veqtrus/p2pool.git"

Just dropping that there for noobs like me who want to show segwit support.

Thanks again!

To be fair it would be hard for miners to support 2x without knowing it as jtoomim's fork throws an error if you mine with Core.

As a complete noob to p2pool, thanks to veqtrus for creating a Segwit version that doesn't require me to move away from Core bitcoind.  17.1 seems to be working fine now with no scary error messages from p2pool or bitcoind.  I wanted to signal my support for segwit, but not segwit2x.  Thank you for giving me a way to do that!  It was a bit of a convoluted path to find it tho.  I am sure there are a lot of miners that just upgraded everything per the error message and end up supporting segwit2x without knowing it... clearly.  I wish there was a clear path of instructions out there for those that support segwit, then another for those that support segwit2x.  In any case, thank you veqtrus for supporting what i consider at this point to be "real" bitcoin.

Nice post frodo
Now translating this to C ( Windows), That's another story 

Here is a more elegant way of getting PyPy up and running for jtoomimnet P2Pool on Ubuntu 16.04 and later.

1. Add the PyPy PPA. (The PyPy in the PPA is more frequently updated than the PyPy in Ubuntu's package repository.)


2. Install PyPy and other dependencies.


3. Install pip.


4. Update pip, setuptools, and wheel.


5. Install Twisted, zope.interface, and incremental.


6. Download the 1mb_segwit branch of jtoomimnet P2Pool.


7. Run P2Pool.


For a list of jtoomimnet P2Pool command-line options:

---

Using pip to install third-party Python packages (e.g., Twisted, zope.interface, and incremental), instead of downloading and installing them directly, enables cleaner installs and uninstalls, and simpler and faster updating of the packages. For example,

(a) to update Twisted, zope.interface, and incremental:


(b) to remove Twisted, zope.interface, and incremental (if you no longer need them):


A list of handy pip commands may be found here.

A more comprehensive guide to using pip may be found here.

Meanwhile, on the jtoomimnet branch of p2pool...

I came up with an idea to improve p2pool's scalability and greatly reduce payout variance: https://bitcointalksearch.org/topic/payment-channel-payouts-an-idea-for-improving-p2pool-scalability-2135429

Please tell me what you think.

It's part of p2pool's fast block propagation technology, which for p2pool is part of the consensus layer. P2pool had one of the first systems for propagating a block without transmitting the full serialized size of the block over the network. It did this by making the share objects encode the list of transactions in a block by encoding them as a (previous share's index, transaction index) tuple. Usually, this encoding takes two or three bytes per transaction. For transactions that are being included in a share for the first time, p2pool encodes them in shares as the full 32-byte transaction hash, and assumes that the recipient of the share will already have the mapping from the 32-byte hash to the full transaction. (This is ensured by code in the p2p layer.)

P2pool in principle does not need to include the full (encoded) transaction list in the share object. But getting rid of that means getting rid of p2pool's fast block propagation tech. Since modern fast block propagation tech has advanced so much outside of p2pool (e.g. FIBRE, Falcon, Xthin, Compact Blocks), I think that p2pool should strip it out and leave that task to the better (and faster) code in bitcoind. Alternately, if fast block propagation in p2pool is desirable, it should probably be done outside of the consensus layer, so that it only gets used for actual blocks (where the resource usage is actually useful) rather than on every single share.

Thanks for your reply jtoomim.


How would you do this?

In fact, why do shares need references to transactions at all? They already commit to all the transactions via the merkle root. If a hasher turns out to have created an invalid block then they will lose money.

keep me posted would love to check it out

Not yet. I've been working on adding support for it to jtoomimnet, but it's only about 40% done.