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

[wariner]

you confirm me that for bitcoin classic it's enough use bitcoin classic instead of bitcoin core?

or need change something on this line?

 p2pool/p2pool/work.py

Code:

372 version=min(self.current_work.value['version'], 4),

You need to change the version in the line you quoted (372 in work.py) to:

Code:

version=min(self.current_work.value['version'], 0x30000000),

or

Code:

version=min(self.current_work.value['version'], 805306368),

Both work.

Thank you 

But i'm come back to bitcoin core, to me it seems more efficient at this time compared to classic...you have noticed the same thing?

[1713299268]

1713299268

[1713299268]

1713299268

[1713299268]

1713299268

[1713299268]

1713299268

[Meuh6879]

Classic and XT are based on 0.11.2 + somes 0.12.0 features.
0.12.0 RC5 is really a good build for all.

[windpath]

Classic and XT are based on 0.11.2 + somes 0.12.0 features.
0.12.0 RC5 is really a good build for all.

Both Core and Classic version 12 are release candidates and not recommended for mining.

That being said, on my testing node the speed improvements are impressive.

[windpath]

So, if you have not heard yet there is another serious vulnerability for anyone running Unix based machines.

A severe vulnerability in the Gnu C Library's DNS client has been discovered and it affects just about EVERY bitcoin implementation.

Info here: http://linux.slashdot.org/story/16/02/16/1724222/red-hat-google-disclose-severe-glibc-dns-vulnerability-patched-but-widespread

Patches are available, but you must update.

For Debian/Ubuntu:

Code:

sudo apt-get update && sudo apt-get upgrade && sudo reboot

The reboot is important.

[p3yot33at3r]

So, if you have not heard yet there is another serious vulnerability for anyone running Unix based machines.

A severe vulnerability in the Gnu C Library's DNS client has been discovered and it affects just about EVERY bitcoin implementation.

Info here: http://linux.slashdot.org/story/16/02/16/1724222/red-hat-google-disclose-severe-glibc-dns-vulnerability-patched-but-widespread

Patches are available, but you must update.

For Debian/Ubuntu:

Code:

sudo apt-get update && sudo apt-get upgrade && sudo reboot

The reboot is important.

Thanks for the heads up windpath - done.

[wariner]

So, if you have not heard yet there is another serious vulnerability for anyone running Unix based machines.

A severe vulnerability in the Gnu C Library's DNS client has been discovered and it affects just about EVERY bitcoin implementation.

Info here: http://linux.slashdot.org/story/16/02/16/1724222/red-hat-google-disclose-severe-glibc-dns-vulnerability-patched-but-widespread

Patches are available, but you must update.

For Debian/Ubuntu:

Code:

sudo apt-get update && sudo apt-get upgrade && sudo reboot

The reboot is important.

Thanks for the heads up windpath - done.

+1  Thank you

[luthermarcus]

I'm still relatively new to Linux how would i go about installing bitcoin core rc5.
I probably could figure it out but i dont want to mess anything up in the process. Thanks in advance.

[Meuh6879]

wait a little more ... https://bitcointalk.org/index.php?topic=1369194.msg13932025#msg13932025

[windpath]

I'm still relatively new to Linux how would i go about installing bitcoin core rc5.
I probably could figure it out but i dont want to mess anything up in the process. Thanks in advance.

0.12.0 has been tagged for release, no need to use the release candidate, I imagine the binaries will be out today if you do want to wait, if not you can build yourself with the directions below.

https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md

[luthermarcus]

I'm still relatively new to Linux how would i go about installing bitcoin core rc5.
I probably could figure it out but i dont want to mess anything up in the process. Thanks in advance.

0.12.0 has been tagged for release, no need to use the release candidate, I imagine the binaries will be out today if you do want to wait, if not you can build yourself with the directions below.

https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md

Thanks windpath for that link and security update too. I just finished building it then i saw your post. It was a good experience for me normally i would stick to windows but bitcoin has me working on lunix. Greatly appreciated.

[luthermarcus]

Does anyone know if the parameter -maxuploadtarget would affect p2pool negatively?
From what i read it it used to limit uploads to new bitcoin nodes who are downloading the blockchain.
I'm trying to use this as an alternative and/or in combination with -maxconnections  parameter.

[windpath]

Does anyone know if the parameter -maxuploadtarget would affect p2pool negatively?
From what i read it it used to limit uploads to new bitcoin nodes who are downloading the blockchain.
I'm trying to use this as an alternative and/or in combination with -maxconnections  parameter.

It should have no effect, it's a Bitcoin setting and unrelated to P2Pool P2P traffic.

FWIW I set -maxconnections to 15 for Bitcoin and 25 for P2Pool

[p3yot33at3r]

Running Core v0.12 I got loads or these errors:

Code:

2016-02-19 17:55:11.831105 > Error while processing Event callbacks:
2016-02-19 17:55:11.831211 > Traceback (most recent call last):
2016-02-19 17:55:11.831237 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 74, in set
2016-02-19 17:55:11.831263 >     self.changed.happened(value)
2016-02-19 17:55:11.831287 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.831311 >     func(*event)
2016-02-19 17:55:11.831335 >   File "/home/rig/p2pool/p2pool/node.py", line 243, in _
2016-02-19 17:55:11.831360 >     self.mining_txs_var.set(new_mining_txs)
2016-02-19 17:55:11.831383 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 75, in set
2016-02-19 17:55:11.831410 >     self.transitioned.happened(oldvalue, value)
2016-02-19 17:55:11.831434 > --- <exception caught here> ---
2016-02-19 17:55:11.831457 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.831481 >     func(*event)
2016-02-19 17:55:11.831505 >   File "/home/rig/p2pool/p2pool/p2p.py", line 211, in update_remote_view_of_my_mining_txs
2016-02-19 17:55:11.831541 >     assert self.remote_remembered_txs_size <= self.max_remembered_txs_size
2016-02-19 17:55:11.831565 > exceptions.AssertionError:
2016-02-19 17:55:11.833002 > Error while processing Event callbacks:
2016-02-19 17:55:11.833105 > Traceback (most recent call last):
2016-02-19 17:55:11.833132 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 74, in set
2016-02-19 17:55:11.833157 >     self.changed.happened(value)
2016-02-19 17:55:11.833182 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.833206 >     func(*event)
2016-02-19 17:55:11.833230 >   File "/home/rig/p2pool/p2pool/node.py", line 243, in _
2016-02-19 17:55:11.833257 >     self.mining_txs_var.set(new_mining_txs)
2016-02-19 17:55:11.833280 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 75, in set
2016-02-19 17:55:11.833304 >     self.transitioned.happened(oldvalue, value)
2016-02-19 17:55:11.833327 > --- <exception caught here> ---
2016-02-19 17:55:11.833351 >   File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.833374 >     func(*event)
2016-02-19 17:55:11.833398 >   File "/home/rig/p2pool/p2pool/p2p.py", line 211, in update_remote_view_of_my_mining_txs
2016-02-19 17:55:11.833421 >     assert self.remote_remembered_txs_size <= self.max_remembered_txs_size
2016-02-19 17:55:11.833445 > exceptions.AssertionError:

...& my DOA/Orphan rate was quite high - anyone else experience this?

Since going back to the previous master branch the errors have gone & my DOA/Orphan rate is fine again.

[windpath]

Running Core v0.12 I got loads or these errors:

...

...& my DOA/Orphan rate was quite high - anyone else experience this?

Since going back to the previous master branch the errors have gone & my DOA/Orphan rate is fine again.

I've been running 12 for a couple weeks, been working great, perhaps clean out your P2Pool /data/Bitcoin directory and get a fresh share chain?

[p3yot33at3r]

Think I'll wait until the official release & try again, I hate re-downloading the sharechain....lol It's running nice again now, so I'll let it ride.

Did you use the binary or compile from the 0.12 branch? (which is what I did btw)

[jtoomim]

There appears to be an issue with p2pool producing lots of orphaned shares if the blocksize is greater than about 750 kB. This is caused by the limit on the number of transactions per share being too low.

https://github.com/p2pool/p2pool/issues/274

As Bitcoin Classic sets the default block size limit to the largest allowed by the consensus rules, this can result in Bitcoin Classic nodes failing to produce valid shares. Consequently, if you run Bitcoin Classic with p2pool, you should use blockmaxsize=750000 or lower in your ~/.bitcoin/bitcoin.conf.

[windpath]

Think I'll wait until the official release & try again, I hate re-downloading the sharechain....lol It's running nice again now, so I'll let it ride.

Did you use the binary or compile from the 0.12 branch? (which is what I did btw)

I complied core rc3 and the classic 12 branch, both run fine with significantly lower getblocktemplate latency...

Edit: see jtoomim's comment above, I run at 750000 on my test node so did not test larger

[p3yot33at3r]

Think I'll wait until the official release & try again, I hate re-downloading the sharechain....lol It's running nice again now, so I'll let it ride.

Did you use the binary or compile from the 0.12 branch? (which is what I did btw)

I complied core rc3 and the classic 12 branch, both run fine with significantly lower getblocktemplate latency...

Edit: see jtoomim's comment above, I run at 750000 on my test node so did not test larger

Is it the same problem with Core as well?

[windpath]

Think I'll wait until the official release & try again, I hate re-downloading the sharechain....lol It's running nice again now, so I'll let it ride.

Did you use the binary or compile from the 0.12 branch? (which is what I did btw)

I complied core rc3 and the classic 12 branch, both run fine with significantly lower getblocktemplate latency...

Edit: see jtoomim's comment above, I run at 750000 on my test node so did not test larger

Is it the same problem with Core as well?

Best way to find out is test it...

But I speculate it's the same...

[-ck]

There appears to be an issue with p2pool producing lots of orphaned shares if the blocksize is greater than about 750 kB. This is caused by the limit on the number of transactions per share being too low.

https://github.com/p2pool/p2pool/issues/274

As Bitcoin Classic sets the default block size limit to the largest allowed by the consensus rules, this can result in Bitcoin Classic nodes failing to produce valid shares. Consequently, if you run Bitcoin Classic with p2pool, you should use blockmaxsize=750000 or lower in your ~/.bitcoin/bitcoin.conf.

Hmm... not much good using a fork designed to increase the max blocksize limit if you can't... increase the max blocksize.