P2pool: Decentralized, DoS-resistant, trustless, censorship-resistant pool.

[jtoomim]

The person creating bad blocks and shares only has 3% of LTC p2pool's hashrate. It's worth fixing, but it's not worth panicking over.

[Kiefff]

https://www.youtube.com/watch?v=IAYAqRP-zc8 video of me running through Jtoomims 1mb_segwit setup running pypy on fresh install of ubuntu. Setup of me doing LTC merge mining Dogecoin.

[X.R]

Curious question:

- p2pool node that has no miners connected to it (no hashrate, no shares).
- does CreateNewBlock(): block weight: XXX txs: 18 fees: XXXXXX sigops XXX

Will it ever generate any revenue for itself or it needs to have at least one share?
What are the pre-requisites to generate a revenue for p2pool node? Is that only a fee from miners?

Thanks!

[Kiefff]

Curious question:

- p2pool node that has no miners connected to it (no hashrate, no shares).
- does CreateNewBlock(): block weight: XXX txs: 18 fees: XXXXXX sigops XXX

Will it ever generate any revenue for itself or it needs to have at least one share?
What are the pre-requisites to generate a revenue for p2pool node? Is that only a fee from miners?

Thanks!

So a p2pool node only generates revenue from its miners. Even then, a 1% fee sometimes is so minimal, it doesnt payout.

[X.R]

I understand it is not profitable. Thanks.
I was under impression these CreateNewBlock(s) would add to the totals that will be generated by the solving a block.
otherwise what are the mintxfee and minrelaytxfee are for?

[jtoomim]

You can think of it sort of like writing a legal contract. CreateNewBlock() (or GetBlockTemplate() -- it has two names, but is basically the same thing -- GBT calls CNB and returns the result via RPC) will write a draft of the legal contract, but a contract isn't legally binding unless it is executed (signed). The parameters like minrelaytxfee affect what goes into that contract. If there's a bug in the CreateNewBlock code or in the poolserver code that assembles that contract, then even if it's signed it will be invalid and not legally enforceable, kinda like you can't sign a contract that gives someone permission to murder you.

The mining process is equivalent to a signature. One of the interesting things is that the PoW mining "signature" is equivalent to a signature from the entire Bitcoin (or whatever) network, not just a signature from your node. That is, the Bitcoin network works under the rule that anybody who can prove a certain level of work gets permission from the rest of the Bitcoin network to assemble a block, confirm some transactions, collect transaction fees, and collect a block subsidy.

[jtoomim]

There is a similar problem on the LCC p2pool - the hashrate disappears simultaneously on different nodes.
http://crypto.mine.nu:5055
http://siberia.mine.nu:5055
http://37.29.116.122:5055
https://lcc.crabs.pro

I believe this issue was fixed by commit be975b4.

Sawa, if you're interested, sometime I'd like to connect with you somehow and show how to use git and github a bit better. If you had created your LCC fork as a regular git fork and branch that tracked 1mb_segwit as the upstream, you could have fixed this issue with a git pull 1mb_segwit, and it would also be very easy for you to submit a pull request to get your LCC support merged back into the mainline,

[ArchimedesIX]

New version IXC will start paying out again starting with block 450000 shortly

- source is in https://github.com/ixcore/ixcoin

no new coins will be created - community donated to a mining pool which the new version will distribute

[X.R]

Installed pool for LTC but getting close to 100% of DOA.
I do have Litecoin script module installed for pypy.
Tried version 0.15 and 0.14 of LTC daemon.
Rented a scrypt miner close to the server, but that did not help.
Is there anything I could have missed or better, how to debug this?
Thanks!

[jtoomim]

Your node's CPU is probably too slow. What CPU are you using?
What is your GetBlockTemplate latency?
Is your node publicly accessible? Can you tell me your IP address so I can take a look?
What type of miner are you using? Have you manually adjusted the difficulty?
What branch of code are you using? What OS?

[X.R]

RE:> GetBlockTemplate latency

How to check this?

I have followed instructions in this post to install the proper git branch.

This is CentOS 7.3 running pypy
It is 2 CPU Virtual hosting but CPU load "seems" ok (it is IDLE)

Code: Select all

top - 00:38:06 up 76 days, 3:28, 1 user, load average: 0.04, 0.03, 0.00 Tasks: 1121 total, 1 running, 1120 sleeping, 0 stopped, 0 zombie %Cpu0 : 2.0 us, 1.0 sy, 0.0 ni, 97.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 0.7 us, 0.0 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 4194304 total, 1994748 free, 1607908 used, 591648 buff/cache KiB Swap: 0 total, 0 free, 0 used. 2296312 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18260 litecoin 20 0 973060 456788 13852 S 2.6 10.9 29:19.52 pypy 24114 root 20 0 53052 3208 1468 R 1.0 0.1 0:00.16 top 18026 litecoin 20 0 1999792 658892 6124 S 0.7 15.7 4:04.61 litecoind

http://164.132.5.30:9327/static/

I must have missed something...

[jtoomim]

You're right, CPU looks fine. GBT latency looks good too.

I'm running one of my Antminer L3+s on your node right now and it seems to be working fine. The problem is probably with your hashrate rental.

[X.R]

Thank you very much for helping out! I have rented yet another scrypt miner, this time "Dream Antminer L3+" and it seems to be doing the job.
Not ideally as I can see warning about "Low Worker Difficulty" or "Too high worker Difficulty" assigned by the pool.
[Q] What username / difficulty combination have you used? is that WALLET+DIFFICULTY or WALLET/0+difficulty?

[Kiefff]

Jtoomin,
lots of miners lately seem to think something is wrong with their predicted payout on p2pool LTC. Sometimes, one antminer L3+ will have a higher PP vs two antminer. Seems any miner on your node has around 200-300K diff, while other nodes seem to be 17k-23k on average. Also seen another node have a miner set to 52k diff. These are all from multiple miners that have the same hashrates. All the nodes being used are running ~100% efficiency, so its not like the nodes are causing bad submits. One person has a theory of having multiple miners from IP address using same wallet id is causing this issue, but no hard evidence. We would like to know what your input is on this. I told most to be patient, and that shares take a long time to submit now with current hashrate / diff, but they dont like that answer =D


*edit* all difficulties i have referenced, is from miners GUI

[Kiefff]

**double post**

[jtoomim]

Kieff, it's just share variance. Just like you can get lucky or unlucky when mining blocks, you can get lucky or unlucky when mining LTC shares. The LTC p2pool has a share chain length of 24*60*60//10 = 8640 shares. P2pool's hashrate is about equal to 1000 L3+s, so if you have 1 L3+, that's 0.1% of the hashrate. If you're mining on a node with an average share difficulty, you would have an average of 8 shares in the share chain, but that number could easily vary between 2 and 14 depending on your luck. If you're mining on a node with high share difficulty, you might have 2 shares in the chain on average (same expected payout, because each share is worth more), but when you're unlucky you might have 0, and when you're lucky you might have 4 or 5.

Share variance is just variance. It is not a sign of unfairness. It's just a sign of good and bad luck. P2pool reduces the influence of luck on mining revenue a lot, but it doesn't eliminate it.

The difficulties you see in the miner's GUI are the pseudoshare difficulties, and are used for hashrate estimation but not for payout generation. The actual share difficulties are much higher, typically in the millions or tens of millions (after applying the DUMB_SCRYPT_DIFF adjustment factor).

[jtoomim]

Another invalid block was mined on LTC p2pool by LZzzELrQifCah5oafpNuCA6dLiyacVJNDa, after a streak of 27 valid blocks.

http://ml.toom.im:9327/static/share.htm ... 4aee5ae83e

I've made a lot of progress on getting fee/block reward checking done. I may have a fix for this soon.

[Kiefff]

Another invalid block was mined on LTC p2pool by LZzzELrQifCah5oafpNuCA6dLiyacVJNDa, after a streak of 27 valid blocks.

http://ml.toom.im:9327/static/share.htm ... 4aee5ae83e

I've made a lot of progress on getting fee/block reward checking done. I may have a fix for this soon.

Awesome stuff Jtoomim. And thanks for the reply in regards to share variance. Its pretty much what Ive been telling most, but not as clearly =D This will go up in our FAQ section on the community discord channel that came from doing p2pool videos.

https://discord.gg/QGFv555 - Cool little feature we have is block announcements for blocks mined on p2pool LTC.

[Staim]

Hi jtoomim!
There are still old issue.
The hashrate disappears simultaneously on different nodes.

For example:
http://213.110.141.21:9334/
http://37.194.10.30:9334/
http://ml.toom.im:9334/

Screenshots: https://imgur.com/a/9MFOE
Time: 6:20 and 12:35

[jtoomim]

This is promising! Looks like my excessive fee code is starting to work:

Code: Select all

2018-03-05 03:30:20.931715 > Traceback (most recent call last): 2018-03-05 03:30:20.931847 > File "/home/bch/debugltc/p2pool/data.py", line 474, in check 2018-03-05 03:30:20.932083 > raise ValueError("Excessive block reward in share! Naughty. Max allowed = %i, requested subsidy = %i" % (max_subsidy, self.share_info['share_data']['subsidy'])) 2018-03-05 03:30:20.932170 > ValueError: Excessive block reward in share! Naughty. Max allowed = 2511566649, requested subsidy = 2512063149

Gonna do a bit more testing before I push to github.

[jtoomim]

Added a bit more code. It's looking like it's basically working now:

Code: Select all

2018-03-05 04:18:15.682756 > Traceback (most recent call last): 2018-03-05 04:18:15.682868 > File "/home/bch/debugltc/p2pool/data.py", line 478, in check 2018-03-05 04:18:15.683182 > raise ValueError("Excessive block reward in share! Naughty. " + details) 2018-03-05 04:18:15.683293 > ValueError: Excessive block reward in share! Naughty. Max allowed = 2507693731, requested subsidy = 2508235131, share hash = 82167b0718a48f65456f44daf620d78d7da895086c9acb0230825e0af41b5909, miner = LZzzELrQifCah5oafpNuCA6dLiyacVJNDa 2018-03-05 04:18:15.686428 Punishing share for 'naughty share (excessive block reward or otherwise would make an invalid block)'! Jumping from f41b5909 to d45184d6! 2018-03-05 04:18:17.761892 Punishing share for 'naughty share (excessive block reward or otherwise would make an invalid block)'! Jumping from f41b5909 to d45184d6! 2018-03-05 04:18:17.763209 Punishing share for 'naughty share (excessive block reward or otherwise would make an invalid block)'! Jumping from f41b5909 to d45184d6! 2018-03-05 04:18:22.765500 Punishing share for 'naughty share (excessive block reward or otherwise would make an invalid block)'! Jumping from f41b5909 to d45184d6! 2018-03-05 04:18:22.766764 Punishing share for 'naughty share (excessive block reward or otherwise would make an invalid block)'! Jumping from f41b5909 to d45184d6! 2018-03-05 04:18:24.099056 Max allowed = 2511213328, requested subsidy = 2511213328, share hash = 3134e4c2c6850f3aee33cce9e3eb1f6da7878deaf87d4cdd8482e06c71d45c2b, miner = LanyWSFZwRFs4Qtv95h67KL9zYmDEYMxmc

[jtoomim]

Okay, the fee checking code is now running on my two main LTC mining nodes. You can switch to it like this:

Code: Select all

git fetch git checkout feechecking

This is a temporary branch for Litecoin. I have not tested this code on other cryptocurrencies yet, and it may have bugs, so I recommend for now only using this code if you're mining Litecoin. Once it has been a bit better tested, I'll merge it back into 1mb_segwit.

The code is a bit of a hack, unfortunately. It's impossible to just look at a transaction and determine what the fee is. You need to have a copy of all of the UTXOs that the tx spends first, and in order to do that, you need to be a full node. P2pool is not a full node. Fortunately, each time we do a getblocktemplate call, our full node tells us exactly what the fee is for each transaction in that template, so this code makes p2pool remember all of those txid:fee mappings for a while so that we can calculate the fees properly when someone else sends us a share.

A much better solution would be to simply assemble the share as a block and send it to our full node for testing, with the explicit request that the full node not test the PoW at the beginning so that we know if anything is wrong with the share/block besides the PoW, but that would require getting Bitcoin Core changed, and Bitcoin ABC, and XT, and BU, and Litecoin, and vertcoind, etc...

Currently, the code will chose not to mine directly on top of any shares that violate the block reward limit. It's possible to make the punishment more severe, and to flat-out reject shares that violate the block reward and ban any peers that send them to us, but doing so would fork the network, so it would be better to synchronize the switching to that rule if we chose to use it. That approach is also more likely to result in bugs, since the hack that I used won't catch these naughty shares 100% of the time; a peer that was recently restarted might get a naughty share without being able to detect its naughtiness, then try to send it to its own peers and immediately get disconnected from the good guys. But maybe it would work okay in practice.

Oh well. The hack should work well enough for now. LZzzEL's current expected payout is 0.85712754 LTC. We should see that go down from now on, especially if lots of other miners upgrade. (The orphaning rate for LZzzEL is proportional to the share creation rate of the people who upgrade, which is quite different from their hashrate. Share creation weight is strongly weighted towards small miners, since large miners tend to create a smallish number of high diff shares.)

Time to punish some naughty children. LZzzELrQifCah5oafpNuCA6dLiyacVJNDa, you have been warned.

[jtoomim]

I added a second commit that will reduce the work share difficulty when punishing shares in order to increase the punishment effectiveness.

Edit: This commit turns out to not help as much as I had hoped, since it only takes effect after the next getblocktemplate result from litecoind. It looks like we're only getting about 10% rejection of his naughty shares so far.

[Kiefff]

Updated my node to run branch feechecking. So far so good. I did get this error hard in the beginning, but seems to have gone away. Good stuff Jtoomim.

Code: Select all

2018-03-05 12:44:50.666343 Total block stripped size=32902 B, full size=35979 B, weight: 134641 WU Unhandled Error Traceback (most recent call last): File "/home/skynet/p2pool/p2pool/main.py", line 692, in run reactor.run() File "/usr/local/lib/pypy2.7/dist-packages/Twisted-15.4.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1194, in run self.mainLoop() File "/usr/local/lib/pypy2.7/dist-packages/Twisted-15.4.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1203, in mainLoop self.runUntilCurrent() File "/usr/local/lib/pypy2.7/dist-packages/Twisted-15.4.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 825, in runUntilCurrent call.func(*call.args, **call.kw) --- <exception caught here> --- File "/home/skynet/p2pool/p2pool/bitcoin/stratum.py", line 38, in _send_work x, got_response = self.wb.get_work(*self.wb.preprocess_request('' if self.username is None else self.username)) File "/home/skynet/p2pool/p2pool/bitcoin/worker_interface.py", line 129, in get_work x, handler = self._inner.get_work(*args) File "/home/skynet/p2pool/p2pool/work.py", line 360, in get_work self.node.bitcoind_work.value['bits'].target)*self.node.net.SPREAD)*self.node.net.PARENT.DUST_THRESHOLD/block_subsidy)) exceptions.UnboundLocalError: local variable 'block_subsidy' referenced before assignment 2018-03-05 12:44:50.950811 Generating a share with 30600 bytes, 112512 WU (new: 472 B, 1231 WU) in 68 tx (2 new), plus est gentx of 5771 bytes/23120 WU 2018-03-05 12:44:50.950999 Total block stripped size=33155 B, full size=36451 B, weight: 135872 WU

[Rabinovitch]

Hi guys! Today I have upgraded bitcoind to 0.16.0. Please don't ask me why. But after system restart p2pool can't connect to bitcoind:



What should I do to fix this issue?

[jtoomim]

Bitcoin Core 0.16 changed the RPC interface, and I haven't had time to update p2pool to use the new RPC interface. You can either add support to the new RPC interface yourself, or you can continue to use 0.15 for now.

[jtoomim]

We are also seeing some invalid shares produced on LTC by user LZ8PWsRzfKW1de6fGE7UcgXxbWvsDajQNi. It looks like we're getting about 20% many as we're getting from LZzz. They're probably mining on the same node. Currently, LZ8P's payout is only 0.05226525, but as it appears he started mining recently, that number may be increasing.

The commit I made earlier that was supposed to reduce the share difficulty when punishing wasn't working. The share difficulty was clipped by later code, so the change had no effect. I'm working on something now to fix that, and also to begin the aggressive punishment as soon as a naughty share is received rather than 1-10 seconds later (at the next GBT result). Hopefully, this will actually make a difference in how much of the naughty shares we eliminate.

It also looks like most of the orphan races that result from punishing a naughty share are being lost, since non-upgraded nodes are following the earliest share rather than the highest validity share. Consequently, I may need to extend the punishment for a few generations after the naughty share is issued.

This would all be much simpler if we just forked the network and banished anyone who accepted an invalid share, of course, but I'm trying to avoid doing that. Maybe I'll add something to prevent our nodes from propagating naughty shares to make a future fork less disruptive...

[jtoomim]

I have some code now which is far more aggressive in trying to punish these naughty shares. It will very rapidly switch to low-diff shares, and it will also persevere for several generations to make sure that everyone else sees the best share as being one that is not naughty, even if they can't recognize naughtiness themselves. It seems to be working properly. I'm going to let it run for a few hours (or overnight? It's 10pm here) and then clean up the code a bit before pushing it to github. If this code works as well as I think it will, then my big node running it plus a couple other nodes running the older code should be enough to orphan between 50% to 98% of all naughty shares.

[Rabinovitch]

Bitcoin Core 0.16 changed the RPC interface, and I haven't had time to update p2pool to use the new RPC interface. You can either add support to the new RPC interface yourself, or you can continue to use 0.15 for now.

I have switched to https://github.com/ilsawa/p2pool-jtoomim instead. It works with 0.16 bitcoind.

[bitlock]

What up on the LTC p2pool ???
2018-03-07 19:58:56.590906 > ########################################
2018-03-07 19:58:56.591097 > >>> Warning: A MAJORITY OF SHARES CONTAIN A VOTE FOR AN UNSUPPORTED SHARE IMPLEMENTATION! (v33 with 53% support)
2018-03-07 19:58:56.591172 > An upgrade is likely necessary. Check http://p2pool.forre.st/ for more information.
2018-03-07 19:58:56.591315 > ########################################