Bitcoin Forum
December 04, 2016, 10:29:20 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 ... 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 2029615 times)
jtoomim
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
June 18, 2016, 05:33:44 AM
 #14601

If you attempt to apply a score to correct for this, you can do that, but then you have the issue of how to score multiple shares at the same level. To do this fairly and unexploitably, you need an order. Back to square one.
It's actually quite simple to fairly order shares within a level, as long as you don't care whether the ordering is chonological. For example, you can sort the shares by their hash -- lowest hash (closest to mining a block) comes first. Fair, simple, easy, and unnecessary.

It's also trivial to make a DAG with a constant M/N ratio. Instead of allowing shares to specify as many uncles as they want, you can force each share to specify exactly K parents, and create a rule where the parent with the lowest hash is the canonical parent, and only the canonical parent's parents are counted as grandparents. Fair, simple, easy, and unnecessary.

The best solution is just to make sure that the portion of the share chain that's used for calculating rewards always represents the same amount of work. This puts the fewest restrictions on the DAG structure, and ensures that the ratio of the numbers that actually matters -- the amount of work used to calculate the size of the payout, and the amount of work done by others that would have made the payout -- remains a constant 1.0. As in the PPLKD scheme I described earlier.

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

Posts: 1480890560

View Profile Personal Message (Offline)

Ignore
1480890560
Reply with quote  #2

1480890560
Report to moderator
1480890560
Hero Member
*
Offline Offline

Posts: 1480890560

View Profile Personal Message (Offline)

Ignore
1480890560
Reply with quote  #2

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

Posts: 1480890560

View Profile Personal Message (Offline)

Ignore
1480890560
Reply with quote  #2

1480890560
Report to moderator
1480890560
Hero Member
*
Offline Offline

Posts: 1480890560

View Profile Personal Message (Offline)

Ignore
1480890560
Reply with quote  #2

1480890560
Report to moderator
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
June 18, 2016, 05:34:43 AM
 #14602

This reminds me very much of the arguments I used to have 5 years ago when people denied that pool hopping worked at all.

It was tedious then and it is tedious now. The problem is that logical falacies involving probability are subtle and difficult to explain convincingly if you lack a formal background.

I may return to the discussion later, or I may not. Either way, I'm pretty sure you are incorrect, but I'm not the one working on a project based on a faulty model, so its not really my problem. It may also be fixable without drastic changes (your later post that showed up while I was typing this may be sufficient, or close enough), but it will almost certainly be more complicated and probably still vulnerable to something. It is also possible, somewhat, that I'm still misreading what you are proposing. I don't think so though.

BTW, I was always assuming a constant difficulty for each share for simplicity of description, but that doesn't change anything in general.
jtoomim
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
June 18, 2016, 06:23:54 AM
 #14603

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.

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

Activity: 1


View Profile
June 19, 2016, 03:47:19 PM
 #14604

Recently got a warning that over 50% have voted for an upgrade to v16?
jtoomim
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
June 19, 2016, 04:09:24 PM
 #14605

Recently got a warning that over 50% have voted for an upgrade to v16?
You should upgrade. Do a git pull.

I have not yet upgraded my nodes. Once I do, due to the size of my mining operation, almost all of the network hashrate will be on v16, and v15 shares will start to be rejected. It would be a good idea to upgrade before I do.

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

Activity: 1078



View Profile
June 19, 2016, 08:30:37 PM
 #14606



 Cry binaries isn't here ... https://github.com/p2pool/p2pool/releases/tag/16.0

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

Activity: 510


View Profile
June 19, 2016, 09:25:02 PM
 #14607

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.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
ziiip
Newbie
*
Offline Offline

Activity: 28


View Profile
June 20, 2016, 04:27:36 AM
 #14608

Which coin daemons are supported this release? Just core 0.12.1+?
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
June 20, 2016, 04:33:20 AM
 #14609

Which coin daemons are supported this release? Just core 0.12.1+?

For the Bitcoin network, yes. For other P2Pool networks, no requirements were changed.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
ziiip
Newbie
*
Offline Offline

Activity: 28


View Profile
June 20, 2016, 04:41:32 AM
 #14610

I see Classic 0.12.1 isn't supported. This just for BIP 9 compatibility or what?
ziiip
Newbie
*
Offline Offline

Activity: 28


View Profile
June 20, 2016, 05:20:58 AM
 #14611

I suppose i'll just dirty up the code a bit . . .
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
June 20, 2016, 06:04:35 AM
 #14612

I suppose i'll just dirty up the code a bit . . .

It should run fine with Bitcoin Classic...

EDIT: I don't really know. I assumed Classic would support and indicate that it provides support for the upcoming softforks, but I don't know.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
ziiip
Newbie
*
Offline Offline

Activity: 28


View Profile
June 20, 2016, 07:35:57 AM
 #14613

i'm running Classic 0.12.1 and i get
coin daemon too old! Upgrade!
unless i replace the helper.py from version 15.
Was this tested with Classic?
I don't believe Classic is signaling CSV or BIP 9, they just removed the upgrade warning from the code in 0.12.1.
veqtrus
Newbie
*
Offline Offline

Activity: 14


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

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

Activity: 555


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

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: 938


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

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: 28


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

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

Activity: 555



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

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

smooth
Legendary
*
Offline Offline

Activity: 1246



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

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: 555


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

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