Bitcoin Forum
June 25, 2016, 10:39:53 AM *
News: Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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]
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 1826812 times)
veqtrus
Newbie
*
Offline Offline

Activity: 6


View Profile WWW
June 20, 2016, 09:28:35 AM
 #14621

Classic isn't supported because it doesn't support the CSV softfork yet. Considering CSV will almost certainly reach 95% hashpower signaling before the difficulty retargets, CSV will be enforced from the start of the retargeting period after the next (in about two weeks). Unless Classic adopts CSV miners using it may have their blocks rejected.

Note that simply changing the share version to get them accepted by the P2Pool network is an attack after CSV is enforced.
.   VegasCasino.io. .Bonus Code: BTCTALK. .Get 150% Special Bonus .
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1466851193
Hero Member
*
Offline Offline

Posts: 1466851193

View Profile Personal Message (Offline)

Ignore
1466851193
Reply with quote  #2

1466851193
Report to moderator
jtoomim
Hero Member
*****
Offline Offline

Activity: 538


View Profile WWW
June 20, 2016, 09:38:01 AM
 #14622

Unfortunately, Bitcoin Classic has not been updated to support CSV and BIP9 yet. Consequently, it will be inadvisable to mine with it after the CSV fork activates. If you try, you will probably have any blocks that you mine get orphaned. This will make other p2pool users unhappy, as you will basically be freeloading off the others in the pool. So please don't.

You can still vote for the Classic BIP109 2 MB hardfork without running Classic. You can do so quite easily in p2pool by editing the source code to bitwise OR the block version with 0x30000000. I will be doing this myself soon. Something like this should work:

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

If the BIP109 vote exceeds about 10-15% of the network hashrate, or if a large miner (e.g. Bitfury or Bitmain) asks me to, I will take a week and merge in CSV, BIP9, and whatever else needs merging into Classic, if Gavin and Zander haven't beaten me to it. In the mean time, I will keep voting for BIP109 but using Core, similar to what f2pool does.

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

Activity: 840

CoinCadence.com


View Profile WWW
June 20, 2016, 03:23:44 PM
 #14623

P2Pool release 16.0 - commit hash: d3bbd6df33ccedfc15cf941e7ebc6baf49567f97

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary: http://u.forre.st/u/wanckfqm/p2pool_win32_16.0.zip
Windows binary signature: http://u.forre.st/u/wqjnuihh/p2pool_win32_16.0.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/16.0
Source tarball: https://github.com/forrestv/p2pool/tarball/16.0

Changes:
* CSV compatibility
* Requires Bitcoin >=0.12.1

Several BIPs will take effect in the next few days and in order for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded before the Bitcoin changes takes effect, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

So, please upgrade to 16.0 now and also tell everyone else to.

Thanks Forrest!

CoinCadence is now running P2Pool 16

ziiip
Newbie
*
Offline Offline

Activity: 5


View Profile
June 20, 2016, 03:55:12 PM
 #14624

Unfortunately, Bitcoin Classic has not been updated to support CSV and BIP9 yet. Consequently, it will be inadvisable to mine with it after the CSV fork activates. If you try, you will probably have any blocks that you mine get orphaned. This will make other p2pool users unhappy, as you will basically be freeloading off the others in the pool. So please don't.

You can still vote for the Classic BIP109 2 MB hardfork without running Classic. You can do so quite easily in p2pool by editing the source code to bitwise OR the block version with 0x30000000. I will be doing this myself soon. Something like this should work:

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

If the BIP109 vote exceeds about 10-15% of the network hashrate, or if a large miner (e.g. Bitfury or Bitmain) asks me to, I will take a week and merge in CSV, BIP9, and whatever else needs merging into Classic, if Gavin and Zander haven't beaten me to it. In the mean time, I will keep voting for BIP109 but using Core, similar to what f2pool does.

Makes sense, hopefully Classic will be updated soon. I wasn't looking forward to re-building bitcoind but looks like it's necessary.
Thanks!
sawa
Sr. Member
****
Offline Offline

Activity: 412


View Profile
June 20, 2016, 05:53:50 PM
 #14625

Thanks Forrest!
In version 16.0 an issue #253 in work with pypy disappeared.
This version works correctly and has the fastest speed.

Try my p2pools: http://crypto.office-on-the.net:9332 - 0% fee.
smooth
Legendary
*
Offline Offline

Activity: 1092



View Profile
June 21, 2016, 12:40:43 AM
 #14626

Either way, I'm pretty sure you are incorrect
If you can specify how you think the system is flawed, I'm all ears. However, simply stating that you think it's flawed without going into any detail or even demonstrating that you understand the system is not very helpful.

I already explained that the expected value of the next hash attempt is lower if M is higher and if payouts are divided equally* between all accepted shares a depth N (M, a variable). This should be obvious given that the block reward is (approximately, ignoring tx fees) a constant and M is not, but apparently it is not obvious.

If I have misstated something in the above paragraph please let me know because it is still possible I misunderstand your proposal.

* assuming constant difficulty.
jtoomim
Hero Member
*****
Offline Offline

Activity: 538


View Profile WWW
June 21, 2016, 12:17:16 PM
 #14627

I already explained that the expected value of the next hash attempt is lower if M is higher and if payouts are divided equally* between all accepted shares a depth N (M, a variable).
As far as I can tell from what you've written, you're objecting that the amount of payout for you per peer's share decreases with the number of shares that go into the last N levels of the DAG. This is true, and is not a problem. What I'm not sure about is whether you're claiming that the sum of the expected payouts for you over all of the peers' shares in the last N levels will be lower if that number of shares decreases. If that's not your claim, then the only other claim that I think you might be making is that the sum of expected payouts is perturbed not by the static level of M/N, but by the rate of change of M/N. Is your objection one of those two? If so, which?

This should be obvious given that the block reward is (approximately, ignoring tx fees) a constant and M is not, but apparently it is not obvious.
The size of each block reward is a constant, but the expected number of block rewards per N levels is not. The number of block rewards per N levels is proportional to M.

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

Activity: 1764


Linux since 1997 RedHat 4


View Profile
June 21, 2016, 01:59:39 PM
 #14628

If the "expected reward" per 1 diff share falls over time since the last block, then it is hoppable.
If you understand why Prop is hoppable then the above statement should be obvious.

PPLNS has a 'relatively' constant N diff shares, thus the "expected value" of any 1 diff share at any particular time, after the previous block, does not change.
(this of course isn't true over a diff change, but that's out of the context of the issue being brought up)

I can't make head nor tail of your description, but the above is what's relevant, and I imagine is what smooth is saying.
If your payout system does indeed pay a 'relatively' constant N diff shares per block, then it at least doesn't have the obvious Prop issue.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
jtoomim
Hero Member
*****
Offline Offline

Activity: 538


View Profile WWW
June 21, 2016, 05:40:47 PM
 #14629

If the "expected reward" per 1 diff share falls over time since the last block, then it is hoppable.
No, we're talking about expected reward given to you by someone else's share. This is a p2pool conversation, not a traditional pool conversation. You have a probability of other people rewarding you in the shares they find after you find your own share. If there are more peer shares that are supposed to reward you, then the size of the reward that each share would give you (should that share also be a block) will be less. The point I have been trying to make is that the expected reward you get for mining a 1-diff share is not dependent on the number of peer shares that your reward is distributed over.

If your payout system does indeed pay a 'relatively' constant N diff shares per block, then it at least doesn't have the obvious Prop issue.
My simulation for the naive PPLNS-on-DAG system gave about 1% typical variation in payouts when the number of shares per level of the DAG varied uniformly between 1 and 10. Note that the variation is not predictable: you can't guess how many shares per level will be mined in the future unless you're actively manipulating it (and large enough to do so). For the PPLKD system, your reward will be split over a constant amount of other people's work, so the variation due to changes in M should be basically 0%.

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

Activity: 1764


Linux since 1997 RedHat 4


View Profile
June 22, 2016, 12:08:58 AM
 #14630

...
If your payout system does indeed pay a 'relatively' constant N diff shares per block, then it at least doesn't have the obvious Prop issue.
My simulation for the naive PPLNS-on-DAG system gave about 1% typical variation in payouts when the number of shares per level of the DAG varied uniformly between 1 and 10. Note that the variation is not predictable: you can't guess how many shares per level will be mined in the future unless you're actively manipulating it (and large enough to do so). For the PPLKD system, your reward will be split over a constant amount of other people's work, so the variation due to changes in M should be basically 0%.
You mean big enough like you currently are? Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
jtoomim
Hero Member
*****
Offline Offline

Activity: 538


View Profile WWW
June 22, 2016, 07:48:14 AM
 #14631

You mean big enough like you currently are? Smiley
Unfortunately, yes.

On that note, I've been meaning to ask other p2poolers what I should do about that, if anything. My nodes currently comprise around 46% of the p2pool hashrate. This means I could perform selfish mining attacks if I wanted to, and if I boosted my hashrate a bit, I could 51% attack the p2pool network and get 100% of the shares. Mostly, this happened because p2pool shrank from 2 PH/s to 0.8 PH/s, not because we grew much. One way of dealing with this issue is that I could take some of my hashrate off of p2pool (and maybe solo mine instead), but that would make p2pool blocks even rarer. (I think my nodes have found the last 4 p2pool blocks.) I could also maybe spread some of my hashrate among other nodes, although this would reduce our revenue. Or we could get more people to mine on p2pool, somehow.

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

Activity: 538


View Profile WWW
June 22, 2016, 07:50:41 AM
 #14632

Unfortunately, Bitcoin Classic has not been updated to support CSV and BIP9 yet.
BitcoinXT release F has been tagged. It has BIP9, BIP68, BIP112, and BIP113 support, plus Xthin blocks. As such, it should work fine even after the CSV fork is activated, and should be compatible with p2pool version 16.

https://www.reddit.com/r/bitcoinxt/comments/4p7pl3/bitcoin_xt_release_f_has_been_tagged/

Keep in mind that this is based on the 0.11 branch, so performance may be sub-par.

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

Activity: 412


View Profile
June 22, 2016, 06:13:24 PM
 #14633

You mean big enough like you currently are? Smiley
Unfortunately, yes.

On that note, I've been meaning to ask other p2poolers what I should do about that, if anything. My nodes currently comprise around 46% of the p2pool hashrate. This means I could perform selfish mining attacks if I wanted to, and if I boosted my hashrate a bit, I could 51% attack the p2pool network and get 100% of the shares. Mostly, this happened because p2pool shrank from 2 PH/s to 0.8 PH/s, not because we grew much. One way of dealing with this issue is that I could take some of my hashrate off of p2pool (and maybe solo mine instead), but that would make p2pool blocks even rarer. (I think my nodes have found the last 4 p2pool blocks.) I could also maybe spread some of my hashrate among other nodes, although this would reduce our revenue. Or we could get more people to mine on p2pool, somehow.
I think, you don't have to do anything. Neither go to other nodes nor remove your hashrates from p2pool. Everyone who wanted to leave have already gone on ckpool and further reduction of hashrate is unlikely. There left those who will never remove their powers from p2pool, and, most likely, will attract other people to join here.

Try my p2pools: http://crypto.office-on-the.net:9332 - 0% fee.
jtoomim
Hero Member
*****
Offline Offline

Activity: 538


View Profile WWW
June 22, 2016, 10:09:51 PM
 #14634

Is anyone else having trouble with peer acquisition? vps.forre.st seems to be down.

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

Activity: 538


View Profile WWW
June 23, 2016, 12:05:43 AM
 #14635

Bitcoin Classic 1.1.0 is out. It supports CSV and in my limited testing works fine with p2pool v16.

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
ramsis
Newbie
*
Online Online

Activity: 2


View Profile
June 23, 2016, 06:57:55 AM
 #14636

You mean big enough like you currently are? Smiley
Unfortunately, yes.

On that note, I've been meaning to ask other p2poolers what I should do about that, if anything. My nodes currently comprise around 46% of the p2pool hashrate. This means I could perform selfish mining attacks if I wanted to, and if I boosted my hashrate a bit, I could 51% attack the p2pool network and get 100% of the shares. Mostly, this happened because p2pool shrank from 2 PH/s to 0.8 PH/s, not because we grew much. One way of dealing with this issue is that I could take some of my hashrate off of p2pool (and maybe solo mine instead), but that would make p2pool blocks even rarer. (I think my nodes have found the last 4 p2pool blocks.) I could also maybe spread some of my hashrate among other nodes, although this would reduce our revenue. Or we could get more people to mine on p2pool, somehow.

Hello! I have p2pool at 10% of capacity throughout its network. And I'm not going to leave him!!! And all that I acquire. I will be adding to p2pool
Since the wire is not one experience comparing pool Kano and p2pool.
I can safely say that those who believe in the fairy tale about the bad pool. Continue to believe in. Many people do not know how to count money. I do not understand how people do not understand this..
Here is a link https://forum.bits.media/index.php?/topic/253-p2pool-detcentralizovannyi-pul/?p=441341, Google translator to help.

The hosts of other pools, well able to hang noodles on the ears!

p/s My English is at the level of Google. So I apologize.
jtoomim
Hero Member
*****
Offline Offline

Activity: 538


View Profile WWW
June 23, 2016, 02:13:41 PM
 #14637

I have switched my nodes over to p2pool v16. The current hashrate is approximately 97% v16 over the last hour, and about 76% v16 over the last day. This means that anyone still on v15 will soon have their shares ignored by the rest of the network.

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
ramsis
Newbie
*
Online Online

Activity: 2


View Profile
Today at 10:11:59 AM
 #14638

In Russia we built three nodes. The overall capacity of 400TH/s
By the end of June. We plan to raise up to 500-700TH/s.
Pages: « 1 ... 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]
  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!