Bitcoin Forum
December 09, 2016, 06:06:07 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 [718] 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2033102 times)
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 17, 2016, 04:49:25 PM
 #14341

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.



Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481263567
Hero Member
*
Offline Offline

Posts: 1481263567

View Profile Personal Message (Offline)

Ignore
1481263567
Reply with quote  #2

1481263567
Report to moderator
1481263567
Hero Member
*
Offline Offline

Posts: 1481263567

View Profile Personal Message (Offline)

Ignore
1481263567
Reply with quote  #2

1481263567
Report to moderator
1481263567
Hero Member
*
Offline Offline

Posts: 1481263567

View Profile Personal Message (Offline)

Ignore
1481263567
Reply with quote  #2

1481263567
Report to moderator
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 17, 2016, 05:38:34 PM
 #14342


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
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 17, 2016, 07:23:05 PM
 #14343


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
Legendary
*
Offline Offline

Activity: 852


P2Pool.cloud


View Profile
February 18, 2016, 06:50:15 AM
 #14344


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
Wink

P2Pool.cloud - Public Node P2Pool EU/AMERICA Bitcoin 0% fee ITA - ENG

my BTC: 1KiMpRAWscBvhRgLs8jDnqrZEKJzt3Ypfi
luthermarcus
Full Member
***
Offline Offline

Activity: 206



View Profile
February 19, 2016, 06:11:41 AM
 #14345

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
Legendary
*
Offline Offline

Activity: 1092



View Profile
February 19, 2016, 08:08:15 AM
 #14346

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

French ... but not so much   ---===---   P2P ... it's people at the end   ---===---   P2Pool (10,9 GH/s).
Comment miner des bitcoins ? Un tutoriel est là : https://bitcointalk.org/index.php?topic=1114415.0
Bitcoin change everything ... an explain of this fact : https://www.youtube.com/watch?v=joITmEr4SjY
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 19, 2016, 02:23:14 PM
 #14347

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
Full Member
***
Offline Offline

Activity: 206



View Profile
February 19, 2016, 03:55:34 PM
 #14348

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
Full Member
***
Offline Offline

Activity: 206



View Profile
February 19, 2016, 05:14:13 PM
 #14349

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
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 19, 2016, 05:18:15 PM
 #14350

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
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 19, 2016, 09:44:58 PM
 #14351

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
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 19, 2016, 10:28:13 PM
 #14352

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
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 19, 2016, 11:05:23 PM
 #14353

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
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
February 19, 2016, 11:35:15 PM
 #14354

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.

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 20, 2016, 12:09:09 AM
 #14355

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
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 20, 2016, 12:53:09 AM
 #14356

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
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 20, 2016, 12:54:04 AM
 #14357

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... Wink

But I speculate it's the same...

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 20, 2016, 01:07:24 AM
 #14358

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
luthermarcus
Full Member
***
Offline Offline

Activity: 206



View Profile
February 20, 2016, 01:46:08 AM
 #14359

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.

In the case of blockmaxsize=1000000, I was testing this earlier but have a small data set so far. I'm running bitcoin 0.12.( I recommend this bitcoin 0.12.0 for p2pool users who have high getblocktemp latency. It reduced mine under 1s which was not the case before and keeps it steady.) My first attempt like the man says there is a problem. Stale rate shot up almost 100% effective rate was (0-38%). It also stagnated payout marginally but i caught the issue because i was keeping an eye on it and acted swiftly so i don't know how much it would have impacted payout in the long run. I though it was bitcoin issue though so i changed some parameters.

blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001
maxuploadtarget=144 (I just threw this in but im testing it with max connections so I don't know how effective it is alone.)
maxconnections=20 (Was around 45 when bitcoin started to act up and p2pool started to loss connection.

Things seem good now but something worth mentioning is that p2pool is now relatively synced. Which wasn't the case before.
P2pool was lossing connection to bitcoin so i added -maxconnections and to keep latency down more -maxuploadtarget at lowest recommended levels by developers(144). Which i think could be lower but would hurt the community by slowing down nodes from syncing from what i read.

Other parameters of interest
-maxmempool=<n>       Keep the transaction memory pool below <n> megabytes (default: 300)
-maxreceivebuffer=<n>  Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000)
-maxsendbuffer=<n>       Maximum per-connection send buffer, <n>*1000 bytes (default: 1000)
-bytespersigop               Minimum bytes per sigop in transactions we relay and mine (default: 20)
-datacarrier               Relay and mine data carrier transactions (default: 1)
-datacarriersize               Maximum size of data in data carrier transactions we relay and mine (default: 83)

I'll update my findings once i have some more data. Any info on above parameters would be helpful.
 
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 20, 2016, 11:15:43 AM
 #14360

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.

I see the issue was brought to forrestv's attention over 5 months ago on github - it would be nice if he followed it up or privided some additional info/update.....
Pages: « 1 ... 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 [718] 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!