Bitcoin Forum
July 17, 2018, 12:46:38 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 745 746 747 748 749 750 751 752 753 754 755 756 757 [758] 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 ... 815 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2559396 times)
windpath
Legendary
*
Offline Offline

Activity: 1233
Merit: 1000


View Profile WWW
April 04, 2017, 01:36:52 AM
 #15141

Whom ever is doing the rain dance for the block gods, thank you and KEEP DANCING!! This is pretty damn awesome Cheesy
I mined two of them.

I'm probably going to fork off of p2pool soon in order to increase the limit of 50 kB of new transactions per share. That limit has been severely curtailing p2pool's average block sizes and fee revenue. It looks like we're only getting about 90% of the revenue we could be getting if our block sizes didn't suck.

I know you have received some opposition on the PR on github, but I'd ask that you give it a little time before forking. I'd love to have the time to review and understand the proposed change better, and I imagine as it's been less than a day others would as well  Smiley

Either way your contributions to p2pool have been appreciated, thanks.

1531831598
Hero Member
*
Offline Offline

Posts: 1531831598

View Profile Personal Message (Offline)

Ignore
1531831598
Reply with quote  #2

1531831598
Report to moderator
1531831598
Hero Member
*
Offline Offline

Posts: 1531831598

View Profile Personal Message (Offline)

Ignore
1531831598
Reply with quote  #2

1531831598
Report to moderator
1531831598
Hero Member
*
Offline Offline

Posts: 1531831598

View Profile Personal Message (Offline)

Ignore
1531831598
Reply with quote  #2

1531831598
Report to moderator
The World's Betting Exchange

Bet with play money. Win real Bitcoin. 5BTC Prize Fund for World Cup 2018.

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

Posts: 1531831598

View Profile Personal Message (Offline)

Ignore
1531831598
Reply with quote  #2

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

Activity: 818
Merit: 1001


View Profile WWW
April 04, 2017, 03:36:07 AM
 #15142

I know you have received some opposition on the PR on github, but I'd ask that you give it a little time before forking. I'd love to have the time to review and understand the proposed change better, and I imagine as it's been less than a day others would as well  Smiley

Either way your contributions to p2pool have been appreciated, thanks.
The beauty of a clean hard fork is that the existing version will continue to work normally, just with less hashrate. Both versions should be able to run in parallel without interfering with each other. In order to make that happen, though, I need to find a change that I can make that will cause existing nodes to reject my shares and also cause my nodes to reject the network's shares. I think *reducing* my share version to e.g. 14 or below would work, as long as I also change my code to require a share version number less than or equal to my new share version for received network shares. (I think there's a lambda in networks/bitcoin.py I can use for that.) There might be a better way to achieve the fork, though, and I'm open to suggestions.

This isn't a "screw you guys, I'm going home." It's a "this issue needs to be fixed, and it takes a hard fork to fix it cleanly, so I'm just going to do it, and you can join me if you want to."

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
Perseverance
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile
April 04, 2017, 04:14:10 AM
 #15143

Whom ever is doing the rain dance for the block gods, thank you and KEEP DANCING!! This is pretty damn awesome Cheesy
I mined two of them.

I'm probably going to fork off of p2pool soon in order to increase the limit of 50 kB of new transactions per share. That limit has been severely curtailing p2pool's average block sizes and fee revenue. It looks like we're only getting about 90% of the revenue we could be getting if our block sizes didn't suck.

I know you have received some opposition on the PR on github, but I'd ask that you give it a little time before forking. I'd love to have the time to review and understand the proposed change better, and I imagine as it's been less than a day others would as well  Smiley

Either way your contributions to p2pool have been appreciated, thanks.

It's totally understandable, and I appreciate your presence and contribution to the fullest as well, thank you very much! Do what you gotta do Smiley

Always around and down for the cause!
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
April 04, 2017, 05:07:44 AM
 #15144

As a separate issue, I now realize that current P2Pool doesn't allow *expressing* support for SegWit, due to line 372 in work.py, which veqtrus's changes don't touch:

Code:
version=max(self.current_work.value['version'], 0x20000000),

If anyone can confirm that fixing that is as simple as changing it to

Code:
version=max(self.current_work.value['version'], 0x20000002),

, then I will publish a new P2Pool release with that change.

forrestv, I think you might be confusing min and max here. The current code allows for people to signal for SegWit if they want, but it requires that people signal for BIP9 (that is, if 0x20000000 is greater than bitcoind's reported version, then we use 0x20000000). The code you are proposing would *require* p2pool users to signal for SegWit, even if they're running a version of bitcoind that doesn't support SegWit, and even after SegWit is activated (which itself is a violation of BIP9).

It might be best to change that line of code to this, and end the editing of this line once and for all:

Code:
version=self.current_work.value['version'],

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
squidicuz
Jr. Member
*
Offline Offline

Activity: 58
Merit: 0


View Profile
April 04, 2017, 08:05:19 AM
 #15145

Sorry don't know.
It's the http://uk.p2pool.science:9332/static/ node.
Possibly bitcoin system wallet is outdated

So the alert was added along with BIP9 (version bits) and is triggered when:

> If at any stage 50 of the last 100 blocks have unexpected bits set, you get Warning: Unknown block versions being mined! It’s possible unknown rules are in effect.

It's likely the node is running either BU or bitcoin Classic and that is what triggered it. In an attempt to stay apolitical, if you support that you should stay there, if you don't, find a SegWit signaling node, if you don't care find a node that signals that (thanks to veqtrus's graph we now know that's ~90% of the P2Pool network).

Right now the node is mining valid shares and will continue to until a soft/hard fork occurs, at which point Forrest will likely release a hard fork of P2Pool.... after that it gets very political and messy so I'll stop there Wink

Bitcoind updated.  It was previously running v0.12

Warning has been cleared from that node.
windpath
Legendary
*
Offline Offline

Activity: 1233
Merit: 1000


View Profile WWW
April 04, 2017, 01:03:43 PM
 #15146

I know you have received some opposition on the PR on github, but I'd ask that you give it a little time before forking. I'd love to have the time to review and understand the proposed change better, and I imagine as it's been less than a day others would as well  Smiley

Either way your contributions to p2pool have been appreciated, thanks.
The beauty of a clean hard fork is that the existing version will continue to work normally, just with less hashrate. Both versions should be able to run in parallel without interfering with each other. In order to make that happen, though, I need to find a change that I can make that will cause existing nodes to reject my shares and also cause my nodes to reject the network's shares. I think *reducing* my share version to e.g. 14 or below would work, as long as I also change my code to require a share version number less than or equal to my new share version for received network shares. (I think there's a lambda in networks/bitcoin.py I can use for that.) There might be a better way to achieve the fork, though, and I'm open to suggestions.

This isn't a "screw you guys, I'm going home." It's a "this issue needs to be fixed, and it takes a hard fork to fix it cleanly, so I'm just going to do it, and you can join me if you want to."

I hear what your saying, I was thinking from the viewpoint of trying to keep our variance as low as possible, up until about a week ago it was getting pretty brutal Wink

My understanding so far is that you want to double the p2pool share size and increase mempool, fixing this will fix the issue you identified with p2pool producing blocks smaller then Bitcoins available mempool?


jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
April 04, 2017, 06:40:37 PM
 #15147

My understanding so far is that you want to double the p2pool share size and increase mempool, fixing this will fix the issue you identified with p2pool producing blocks smaller then Bitcoins available mempool?

Right now p2pool shares can contain up to 50 kB of new transactions, plus an unlimited amount of previously-shared transactions. The way p2pool works is that it takes a block template from bitcoind, then iterates through the transaction list. It adds each transaction to the share one-by-one, noting whether that transaction has been included in previous shares or not, until 50 kB of the transactions in the share are being included in a share for the first time. Once the 50 kB limit has been reached, p2pool stops adding transactions to the share, and truncates the block that would be mined. This means that it takes about 20 shares (or around 10 minutes) before p2pool is capable of mining a 1 MB block.

If we use the current 50 kB limit on new transactions per share, and if Antpool mines a block, then we mine 3 non-block shares followed by a block (i.e. about 2 minutes after them, what we'll see in our share sizes is something like this:

1. Antpool block (clears out our mempool)
2. 50 kB share mined (50 kB new)
3. 100 kB share mined (50 kB new)
4. 150 kB share mined (50 kB new)
5. 200 kB share mined (50 kB new) -- block!
6. 50 kB share mined (50 kB new)
7. ...

When I say "100 kB share mined", I mean that the block for that share would have been 100 kB, not that 100 kB of data were sent over the network. Network messages are much smaller than block sizes.

If we allowed 100 kB and increased the mempool size, we might see something like this:

1. Antpool mines a block (partially clears out our mempool)
2. 400 kB share mined (100 kB new, 300 kB reclaimed from mempool)
3. 520 kB share mined (100 kB new, 20 kB reclaimed from mempool)
4. 640 kB share mined (100 kB new, 20 kB reclaimed from mempool)
5. 760 kB share mined (100 kB new, 20 kB reclaimed from mempool) -- block!
6. 120 kB share mined (100 kB new, 20 kB reclaimed from mempool)
7. ...

I want to either get rid of the limit entirely or increase that limit to 1000 kB of new transactions, which means we would see something like this:

1. Antpool mines a block (partially clears out our mempool)
2. 990 kB share mined (690 kB new, 300 kB reclaimed from mempool)
3. 990 kB share mined (20 kB new, 970 kB reclaimed from mempool)
4. 990 kB share mined (20 kB new, 970 kB reclaimed from mempool)
5. 990 kB share mined (20 kB new, 970 kB reclaimed from mempool) -- block!
6. 990 kB share mined (890 kB new, 100 kB reclaimed from mempool)
7. ...

While the second scenario is an improvement over the status quo, I consider it still broken. I think miners have an obligation to users to mine blocks with as many transactions as feasible, and the second scenario does not do that. A 100 kB limit might result in something like 1/4 of our blocks being under 990 kB.

As I believe that I am ethically bound as a miner to process as many user transactions as possible, I personally am not willing to continue mining under scenarios 1 or 2. I think that p2pool truncating a block template from bitcoind is simply unacceptable.

The third scenario is the only one that would ensure that every block mined by p2pool is as large as the node trying to mine it wants it to be. This scenario means that the first share after each new block is published will include a relatively large number of new transactions, which means that the network size of the share might be large. This could cause propagation delays for that share, and might increase the disparity in share orphan rates between nodes with different hashrates or different hardware speeds.

However, I suspect most of the network data will be transmitting transactions between the node's bitcoind's p2p port (localhost:8333) and p2pool, or sent in advance of the share as a transaction announcement via p2pool's p2p network. If I understand the network protocol correctly, share messages over the network are just a set of hashes, which means that a 990 kB share with 890 kB of transactions in it that were being included in a share for the first time should have close to 0 transactions that hadn't already been shared over the p2p layer. If I'm right, the network message size of such a share should be on the order of 32 bytes * 2500 transactions = 80 kB. If this is true, then raising the limit to 1000 kB won't change typical orphan rates much or at all. I intend to do some packet sniffing after I hard fork and increase the max new share size to see how big the network messages actually become.


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

Activity: 1233
Merit: 1000


View Profile WWW
April 04, 2017, 10:37:47 PM
 #15148

Thank you for the detailed explanation.

Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1000



View Profile
April 05, 2017, 05:58:38 PM
 #15149



We have waves, gentleman : https://www.youtube.com/watch?v=r_E7yrCAq58

halvors
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
April 07, 2017, 05:11:34 PM
 #15150

New P2Pool node: http://p2pool.halvors.org:9332/
Dibblah
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
April 08, 2017, 10:52:40 AM
 #15151

Block! Smiley

Also, am I misunderstanding something here? Overall pool efficiency is sitting at 87%. http://p2pool.org/stats/index.php sits at exactly this efficiency.

Why? http://uk.p2pool.science:9332/static/ has a current listed efficiency of 103%. Why would anyone chose to lose almost 20% of their hashing power?

I understand that connectivity and processor limits apply here - nodes need to be well connected and low-latency. But why would someone use one that... Isn't? "just" to have control?
tubexc
Hero Member
*****
Offline Offline

Activity: 501
Merit: 500


View Profile
April 09, 2017, 09:27:13 AM
 #15152

Block! Smiley

Also, am I misunderstanding something here? Overall pool efficiency is sitting at 87%. http://p2pool.org/stats/index.php sits at exactly this efficiency.

Why? http://uk.p2pool.science:9332/static/ has a current listed efficiency of 103%. Why would anyone chose to lose almost 20% of their hashing power?

I understand that connectivity and processor limits apply here - nodes need to be well connected and low-latency. But why would someone use one that... Isn't? "just" to have control?

You should not have doubts or distrust of anything because everything is automatically
populated by your web browser  Roll Eyes
Dibblah
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
April 09, 2017, 09:29:08 AM
 #15153


You should not have doubts or distrust of anything because everything is automatically
populated by your web browser  Roll Eyes

I would completely agree, if my external-to-the-node stats didn't show my hash rate about right for the stated efficiency.
tubexc
Hero Member
*****
Offline Offline

Activity: 501
Merit: 500


View Profile
April 09, 2017, 09:48:13 AM
 #15154

Try this one http://www.p2pool.io/static/
Or stay tuned to a p2pool node finder  Grin
in2tactics
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
April 09, 2017, 11:24:10 PM
 #15155

Block! Smiley

Also, am I misunderstanding something here? Overall pool efficiency is sitting at 87%. http://p2pool.org/stats/index.php sits at exactly this efficiency.

Why? http://uk.p2pool.science:9332/static/ has a current listed efficiency of 103%. Why would anyone chose to lose almost 20% of their hashing power?

I understand that connectivity and processor limits apply here - nodes need to be well connected and low-latency. But why would someone use one that... Isn't? "just" to have control?
Frequently, efficiency discrepancies can be explained by the locality of the clients connecting to the node. The efficiency for a node with clients that are co-located on the same LAN with the node should be higher than a node with clients that must traverse the internet.

Casual Miner: 3x 2PAC and 3x Moonlander 2
Retired HW: 2x AntMiner S7-LN, 5x AntMiner U1, 2x ASICMiner Block Erupter Cube, 4x AntMiner S3, 4x AntMiner S1, GAW Black Widow, and ZeusMiner Thunder X6
tubexc
Hero Member
*****
Offline Offline

Activity: 501
Merit: 500


View Profile
April 10, 2017, 05:36:26 PM
 #15156

Sorry don't know.
It's the http://uk.p2pool.science:9332/static/ node.
Possibly bitcoin system wallet is outdated

So the alert was added along with BIP9 (version bits) and is triggered when:

> If at any stage 50 of the last 100 blocks have unexpected bits set, you get Warning: Unknown block versions being mined! It’s possible unknown rules are in effect.

It's likely the node is running either BU or bitcoin Classic and that is what triggered it. In an attempt to stay apolitical, if you support that you should stay there, if you don't, find a SegWit signaling node, if you don't care find a node that signals that (thanks to veqtrus's graph we now know that's ~90% of the P2Pool network).

Right now the node is mining valid shares and will continue to until a soft/hard fork occurs, at which point Forrest will likely release a hard fork of P2Pool.... after that it gets very political and messy so I'll stop there Wink

Bitcoind updated.  It was previously running v0.12

Warning has been cleared from that node.

   Hello squidicuz.
   Nice to meet you.
   I would like to donate for your good performance in operating this node.
   Tell me which bitcoin address to donate.
   And by now also thanked you if you could clear the node list of shares that is already very long.
   Regards Wink
squidicuz
Jr. Member
*
Offline Offline

Activity: 58
Merit: 0


View Profile
April 11, 2017, 12:04:59 AM
 #15157

...
   Hello squidicuz.
   Nice to meet you.
   I would like to donate for your good performance in operating this node.
   Tell me which bitcoin address to donate.
   And by now also thanked you if you could clear the node list of shares that is already very long.
   Regards Wink

Hello, Nice to meet you as well.    Grin
I try to keep the nodes well tuned and performing well with p2pool and the network, I appreciate the feedback and utilization.
If you would like to help support, you may use this address: 1M6bcAhc7sGxC2yvXwPRs7fHeCFUppkyGR

The front-end starts to lag on load when there is a long list of shares; Thanks for letting me know. I will reboot that node tonight to clear the long list of shares.. Smiley
tubexc
Hero Member
*****
Offline Offline

Activity: 501
Merit: 500


View Profile
April 11, 2017, 10:33:55 AM
 #15158

Quote
Hello, Nice to meet you as well.    Grin
I try to keep the nodes well tuned and performing well with p2pool and the network, I appreciate the feedback and utilization.
If you would like to help support, you may use this address: 1M6bcAhc7sGxC2yvXwPRs7fHeCFUppkyGR

The front-end starts to lag on load when there is a long list of shares; Thanks for letting me know. I will reboot that node tonight to clear the long list of shares.. Smiley

Ok.
Donation sent : https://blockchain.info/tx-index/d3c99c73746a46a1655f833bd0fdd0d492d6af34800d71fddca7af19fed37a3d
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1000



View Profile
April 11, 2017, 01:04:07 PM
 #15159

They stay ... good !

Rw13enlib88
Legendary
*
Offline Offline

Activity: 1498
Merit: 1023



View Profile
April 13, 2017, 06:21:02 PM
 #15160

Hi,

is p2pool merge mining Pesetacoin?

https://bitcointalk.org/index.php?topic=1809867.0
https://coinmarketcap.com/currencies/pesetacoin/

Pages: « 1 ... 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 745 746 747 748 749 750 751 752 753 754 755 756 757 [758] 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 ... 815 »
  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!