Bitcoin Forum
December 03, 2016, 01:46:31 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 2029002 times)
jtoomim
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
February 20, 2016, 08:17:42 PM
 #14361

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

It's a p2pool bug, not a Classic bug.

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

Fixing this issue will likely require a hard fork of the p2pool share chain. (You would have to increase the max_remembered_txs_size value, which may result in your node creating shares that other nodes would not be able to accept or validate. I could be wrong though. This would be a good research project for someone who has time to read the code.)

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480772791
Hero Member
*
Offline Offline

Posts: 1480772791

View Profile Personal Message (Offline)

Ignore
1480772791
Reply with quote  #2

1480772791
Report to moderator
1480772791
Hero Member
*
Offline Offline

Posts: 1480772791

View Profile Personal Message (Offline)

Ignore
1480772791
Reply with quote  #2

1480772791
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 20, 2016, 09:10:01 PM
 #14362

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

It's a p2pool bug, not a Classic bug.
I don't recall saying it was a classic bug anywhere... but I understand your desire to pop up here and defend classic in that way.

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

Activity: 1078



View Profile
February 20, 2016, 11:06:28 PM
 #14363

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

Yes.


Delete "share" files on share folder on bitcoin folder ... on P2Pool folder.

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

Activity: 206



View Profile
February 21, 2016, 12:10:35 AM
 #14364

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.
 

I have successfully ran p2pool with no issues for a day using those settings mentioned above. This was tested with 5 TH. I'm not sure if there is anything in the code preventing use of the whole 1MB but my node was stable with minimal stale rates and minimal orphans. It was pulling shares fine and my income steadily increased and stayed where i expected it to sometimes climbing even higher than what would normally be with default settings. This is on a older machine running 8 gb of ram and Intel® Core™2 Quad CPU Q6700 @ 2.66GHz × 4. I would love to stay on p2pool but the variance at the moment is killing me because I was goxed or crypted by cryptsy im behind on my electric bill I will return when im caught up.
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 21, 2016, 12:09:08 PM
 #14365


blockmaxsize=1000000
 

I don't get it - if p2pool can only handle blockmaxsize of 750000, how can setting it to 1000000 in bitcoin.conf be beneficial? Wont that cause problems?

Thanks.
CartmanSPC
Legendary
*
Offline Offline

Activity: 1148



View Profile WWW
February 21, 2016, 12:33:05 PM
 #14366

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

It's a p2pool bug, not a Classic bug.

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

Fixing this issue will likely require a hard fork of the p2pool share chain. (You would have to increase the max_remembered_txs_size value, which may result in your node creating shares that other nodes would not be able to accept or validate. I could be wrong though. This would be a good research project for someone who has time to read the code.)


The posts below from earlier in this thread below may be related to the issue...

Was reviewing the code and came across this one part:

https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L152

Question: Why limit it to "50 kB of new txns/share"?
i even contacted you about that bug months ago Wink was asking forrestv about it, but he didnt respond. created a hackish fix in my repo.

It's limited to prevent DoS attacks on P2Pool by e.g. making a bunch of fake transactions and then forcing them to be relayed across the entire P2Pool network. With this limit, an attacker can only force every other P2Pool node to download, at most, 50kB per share the attacker mines.

Given that 100kB transactions are possible, it should probably be 100kB, not 50kB, but it doesn't have much of an effect otherwise, since 50kB/share is comparable to the maximum transaction throughput allowed by Bitcoin (500kB/block).

K1773R, your "hackish fix" will result in your shares being orphaned if it ever results in differing behavior. The contents of the generate_transaction function are used to determine consensus, so if your version acts different, other nodes will see your shares as invalid.
Good that we talk about it now. When i was still mining BTC with p2pool, i wondered why not all of my (sometimes bigger than 100kB) would be included in p2pool blocks. It didnt really bother me back then, as some other pool would mine them.
I think raising it (not as high as my hackish fix) would be a good addition to a future hardfork.

Im absolutely aware that i would get my shares rejected. I wasnt using it for BTC.
I wanted to mine the huge ANC stuck txs, so i had to create my own p2pool and set the limit higher.

mmouse
Full Member
***
Offline Offline

Activity: 174


View Profile
February 21, 2016, 10:40:16 PM
 #14367

blockmaxsize=1000000
I don't get it - if p2pool can only handle blockmaxsize of 750000, how can setting it to 1000000 in bitcoin.conf be beneficial? Wont that cause problems?

For me it looks like p2pool has problems with reaching the 1MB limit, but not with being close to it.

My impression after running v0.12 for about 2 days now: it has much better latency and much less memory consumption than v0.11.

So I'd recommend v0.12 (classic or core, up to your taste) to every p2pool node out there. I use
Code:
blockmaxsize=930000
in the bitcoin.conf on my node and don't have any problems with orphan rate or tx errors.
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 22, 2016, 12:03:48 AM
 #14368

Fixing this issue will likely require a hard fork of the p2pool share chain.

It looks like that's what will be needed then, as it seems that most (80%) of the hash rate has finally come to an agreement with Core to increase the blocksize:

http://www.coindesk.com/bitcoin-miners-back-proposed-timeline-for-2017-network-hard-fork/

So I'd recommend v0.12 (classic or core, up to your taste) to every p2pool node out there. I use
Code:
blockmaxsize=930000
in the bitcoin.conf on my node and don't have any problems with orphan rate or tx errors.

According to forrestv on github:

Quote
I wouldn't recommend for you to change that value. Depending on where the problem is, it could either work or split you off from the P2Pool network.

...which I think is what happened to me & I had to re-download a new sharechain. If it works for you, that's great, but I'll take forrestv's advice & keep it at the default setting of 750000 until/if the problem has been fixed.
lightfoot
Legendary
*
Online Online

Activity: 980

Hacking KNC stuff because it goes FOOM well.


View Profile
February 22, 2016, 02:31:40 AM
 #14369

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.
That would explain all the orphaned shares I have been pulling as of late. Off to fix bitcoin.conf again...
mmouse
Full Member
***
Offline Offline

Activity: 174


View Profile
February 22, 2016, 11:03:26 AM
 #14370


According to forrestv on github:

Quote
I wouldn't recommend for you to change that value. Depending on where the problem is, it could either work or split you off from the P2Pool network.

...which I think is what happened to me & I had to re-download a new sharechain. If it works for you, that's great, but I'll take forrestv's advice & keep it at the default setting of 750000 until/if the problem has been fixed.

Sorry, but IMHO forrest was referring to tampering with the p2pool settings, namely
Code:
max_remembered_txs_size = 2500000
- not with the bitcoind blockmaxsize.

I didn't touch a thing inside p2pool, so my shares stay perfectly valid Wink Of course blockmaxsize is just a workaround to use v0.12 with p2pool at all. It's no solution for an increased blocksize > 1M, which we seem to get sooner or not.
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 22, 2016, 03:17:00 PM
 #14371

Sorry, but IMHO forrest was referring to tampering with the p2pool settings, namely

Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though.
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 22, 2016, 03:20:03 PM
 #14372

Sorry, but IMHO forrest was referring to tampering with the p2pool settings, namely

Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though.

If max block size is increased it will require a hard fork of P2Pool (not nearly as big of a deal as a Bitcoin HF, we did 2 in the last year), not much to do about it now as any block > 1MB will be rejected by the network.

wariner
Legendary
*
Offline Offline

Activity: 852


P2Pool.cloud


View Profile
February 22, 2016, 03:22:30 PM
 #14373

Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though.

+1  Wink

You know how the efficiency is calculated? On my public node changes efficiency (up and down) even without sending share..

Also, it is possible that some miners with high ping connect to my node and their decrease the node efficiency?

ps: sorry for my bad english... Wink

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

my BTC: 1KiMpRAWscBvhRgLs8jDnqrZEKJzt3Ypfi
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 22, 2016, 04:24:11 PM
 #14374

Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though.

+1  Wink

You know how the efficiency is calculated? On my public node changes efficiency (up and down) even without sending share..

Also, it is possible that some miners with high ping connect to my node and their decrease the node efficiency?

ps: sorry for my bad english... Wink

https://github.com/p2pool/p2pool/blob/master/p2pool/web.py#L165

Code:
efficiency=(1 - (stale_orphan_shares+stale_doa_shares)/shares)/(1 - global_stale_prop) if shares else None,

It will change without you submitting a share based on global pool efficiency.

If there is more than 1 miner on your node then it's really not a relevant number to you specifically. All that matters is your miners efficiency as compared with the pool as a whole.

p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266



View Profile
February 23, 2016, 03:59:42 AM
 #14375

Regarding this:

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


I've been in contact with forrestv on github, if anyone else who is having this problem can send him their log file he would appreciate it. There is a "tentative" fix available on git but I'm unable to test it atm, so if anyone can try it & provide feedback, that will also help forrestv out.
wariner
Legendary
*
Offline Offline

Activity: 852


P2Pool.cloud


View Profile
February 23, 2016, 01:04:36 PM
 #14376

I've been in contact with forrestv on github, if anyone else who is having this problem can send him their log file he would appreciate it. There is a "tentative" fix available on git but I'm unable to test it atm, so if anyone can try it & provide feedback, that will also help forrestv out.

if you want you can try "test.warp2pool.eu:9332" I'm doing a test with the latest version p2pool and bitcoin classic (0.11.2).

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

my BTC: 1KiMpRAWscBvhRgLs8jDnqrZEKJzt3Ypfi
M8BWNNRFMNdak68c
Sr. Member
****
Offline Offline

Activity: 301


View Profile
February 23, 2016, 04:45:37 PM
 #14377

so where is P2Pool heading? 8 days expected to find a block.. shouldn't we at least remove the "pay only the last 3 days" part? and make sidechain with longer block time ( less work restarts, longer chain )..
so PPLNS could average over the last 30 days or so?
Richy_T
Legendary
*
Offline Offline

Activity: 1246


1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k


View Profile
February 23, 2016, 05:12:10 PM
 #14378


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.



Looks like Slackware is immune. Woot!

http://www.linuxquestions.org/questions/slackware-14/glibc-security-patch-cve-2015-7547-a-4175572402/

1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
Richy_T
Legendary
*
Offline Offline

Activity: 1246


1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k


View Profile
February 23, 2016, 05:15:23 PM
 #14379

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

It's a p2pool bug, not a Classic bug.
I don't recall saying it was a classic bug anywhere... but I understand your desire to pop up here and defend classic in that way.

You can increase the max block size limit, just not the soft limit when mining with p2pool.

You overlooked that these are two different things in your urgent need to snark.

1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
Richy_T
Legendary
*
Offline Offline

Activity: 1246


1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k


View Profile
February 23, 2016, 05:23:08 PM
 #14380

When I search for "p2pool blocks", I still get the seriously out-of-date p2pool.info page. I know there is a more accurate one out there but it doesn't appear to show in the search results. Any ideas on what we can do to either get p2pool fixed or disabled with a redirect and/or get the other page promoted in the search rankings? The defunct page is also cited in the first post in this thread (paging forrestv)

I wouldn't be surprised if this page has been fairly damaging to p2pool to be honest.

1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
Pages: « 1 ... 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!