Bitcoin Forum
April 27, 2018, 03:57:09 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 809 810 811 812 813 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2558770 times)
Xantus
Jr. Member
*
Offline Offline

Activity: 43
Merit: 0


View Profile
August 28, 2017, 07:19:56 AM
 #15781

thnaks so far,

@blue bear :
i downloaded an direkt exe file zip container, it was compiled and i am not an coder, so i have no idea wath is in lin 58 ;-/

@frodocooper :
i downloaded the scoure code from github named p2pool master. in the helper.py line 58 i see
Code:
work['transactions'] = [x for x in work['transactions'] if x['txid'] == x['hash']] # don't mine segwit txs for now
i need to go away, will activate later my miner too look does it work or not. And i will edit my post later ...

so, p2pool is not mining segwit blocks yet ? Shocked
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1524801429
Hero Member
*
Offline Offline

Posts: 1524801429

View Profile Personal Message (Offline)

Ignore
1524801429
Reply with quote  #2

1524801429
Report to moderator
M8BWNNRFMNdak68c
Sr. Member
****
Offline Offline

Activity: 371
Merit: 250


View Profile
August 28, 2017, 09:43:32 AM
 #15782

so i tried https://github.com/jtoomim/p2pool - it worked ( although the invalid share rate was higher, sometimes 100% cpu usage.. )

now i switched back to https://github.com/p2pool/p2pool/ . but here the network is only 0.5 PH big ( 3 PH in the other version )

so am i an the wrong network, or are miners just frightened of the transition? will someone join me?

Quote
Pool: 518TH/s Stale rate: 9.1% Expected time to block: 85.2 days
P2Pool: 17358 shares in chain (10809 verified/17362 total) Peers: 23 (16 incoming)
Switchover imminent. Upgraded: 77.655% Threshold: 95.000%
veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
August 28, 2017, 10:00:33 AM
 #15783

What is happening is that my code has been checking for segwit transactions to not be included in old shares for months but I haven't included a check in the mining code since I thought that v17 shares would activate before segwit activates. Bitcoind is sending segwit txs in its block template but p2pool can't mine them yet. This has nothing to do with syncing other shares.

https://github.com/veqtrus/p2pool/releases/tag/17.1 if anyone needs windows binaries.

P2Pool donation button | Bitrated user: veqtrus.
Cryptonomist
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile
August 28, 2017, 10:02:24 AM
 #15784

so i tried https://github.com/jtoomim/p2pool - it worked ( although the invalid share rate was higher, sometimes 100% cpu usage.. )

now i switched back to https://github.com/p2pool/p2pool/ . but here the network is only 0.5 PH big ( 3 PH in the other version )

so am i an the wrong network, or are miners just frightened of the transition? will soemone join me?

Hello,

The network hash rate for the main branch (forrestv-veqtrus version) is indeed currently only 0.5 PH. It fluctuates a bit throughout the day. Since the split between the jtoomim and main branch the hash power in the main branch has decreased drastically, however, it is now again a bit higher compared to a few days ago. Before the split it was around >2PH on average (this fluctuated also a lot) if I remember it correctly, but even then P2pool was a very small pool.
The reason of the decline (this is just my assessment of the situation) is on the one hand the fact that the network has split, and on the other hand the confusion in the P2pool community during the transition to segWit, and the not so straightforward way (through github) to get the segWit compatible version of P2pool main branch. This has now changed. Forrestv has updated the links on http://p2pool.in/ and veqtrus has merged his segWit compatible p2pool with the main branch on github. I expect that this will result over time in a higher hash rate for the p2pool main branch (I hope).
Blue Bear
Jr. Member
*
Offline Offline

Activity: 31
Merit: 0

If a Bear sits on a miner does it break?


View Profile
August 28, 2017, 10:17:04 AM
 #15785

What is happening is that my code has been checking for segwit transactions to not be included in old shares for months but I haven't included a check in the mining code since I thought that v17 shares would activate before segwit activates. Bitcoind is sending segwit txs in its block template but p2pool can't mine them yet. This has nothing to do with syncing other shares.

https://github.com/veqtrus/p2pool/releases/tag/17.1 if anyone needs windows binaries.

Thanks Veqtrus

I have implemented the new code ... still have to wait until my core node finishes rebuilding to try it ...
M8BWNNRFMNdak68c
Sr. Member
****
Offline Offline

Activity: 371
Merit: 250


View Profile
August 28, 2017, 11:10:49 AM
 #15786

so i tried https://github.com/jtoomim/p2pool - it worked ( although the invalid share rate was higher, sometimes 100% cpu usage.. )

now i switched back to https://github.com/p2pool/p2pool/ . but here the network is only 0.5 PH big ( 3 PH in the other version )

so am i an the wrong network, or are miners just frightened of the transition? will soemone join me?

Hello,

The network hash rate for the main branch (forrestv-veqtrus version) is indeed currently only 0.5 PH. It fluctuates a bit throughout the day. Since the split between the jtoomim and main branch the hash power in the main branch has decreased drastically, however, it is now again a bit higher compared to a few days ago. Before the split it was around >2PH on average (this fluctuated also a lot) if I remember it correctly, but even then P2pool was a very small pool.
The reason of the decline (this is just my assessment of the situation) is on the one hand the fact that the network has split, and on the other hand the confusion in the P2pool community during the transition to segWit, and the not so straightforward way (through github) to get the segWit compatible version of P2pool main branch. This has now changed. Forrestv has updated the links on http://p2pool.in/ and veqtrus has merged his segWit compatible p2pool with the main branch on github. I expect that this will result over time in a higher hash rate for the p2pool main branch (I hope).
okay thank you.. is there a possibility to combine the two branches again? it seems to be very uselesss to split this very small pool in two even smaller, separate networks..
veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
August 28, 2017, 11:23:48 AM
 #15787

okay thank you.. is there a possibility to combine the two branches again? it seems to be very uselesss to split this very small pool in two even smaller, separate networks..
In 3 months jtoomimnet will fork off to segwit2x anyway so it seems to be pointless.

P2Pool donation button | Bitrated user: veqtrus.
Cryptonomist
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile
August 28, 2017, 11:57:26 AM
 #15788

okay thank you.. is there a possibility to combine the two branches again? it seems to be very uselesss to split this very small pool in two even smaller, separate networks..
In 3 months jtoomimnet will fork off to segwit2x anyway so it seems to be pointless.

Ok that is true, however I believe that jtoomim is planning to let his chain automatically split in 3 months. One part would be following segwit2x, and the other part segwit. In that case it is still possible to end up with two separate P2pool networks that actually follow the same Bitcoin rules. It depends all on how much miners are following jtoomim but do not support segwit2x. To be honest I have no idea how many people are in that case. Also, I don't know if jtoomim is still working on this automatic split.

Just a hypothetical question (I'm not yet far enough in understanding the code, so this might be gibberish): In case the split of jtoomim's network happens, would it not be possible to merge the two versions that follow segwit, so that the reasons that some miners have to follow jtoomim even though they only support segwit is partially alleviated?
veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
August 28, 2017, 12:25:04 PM
 #15789

okay thank you.. is there a possibility to combine the two branches again? it seems to be very uselesss to split this very small pool in two even smaller, separate networks..
In 3 months jtoomimnet will fork off to segwit2x anyway so it seems to be pointless.
In case the split of jtoomim's network happens, would it not be possible to merge the two versions that follow segwit, so that the reasons that some miners have to follow jtoomim even though they only support segwit is partially alleviated?
Merging would require creating a third network which contains a snapshot of the balances of the other two networks. It's easier to just abandon one of the networks.

I think one of the main reasons people choose to use jtoomimnet is the excessively increased new txn size/share limit which allows producing larger blocks at the expense of DoS vulnerability. Since a lot of "P2Pool miners" are just mining on centralized P2Pool instances this isn't a concern to them; they can switch to any other centralized pool at any time. Also since proof-of-hope blockchains are the domain of BU/2x/altcoin developers this represents a major disagreement.

P2Pool donation button | Bitrated user: veqtrus.
Xantus
Jr. Member
*
Offline Offline

Activity: 43
Merit: 0


View Profile
August 28, 2017, 01:39:22 PM
 #15790

now idea wath you people talking about  Roll Eyes but thanks für Windows 17.1 and thanks for updatin the links on p2pool.in.

I also would also like to see that all the p2pool miners go back to one and the same chain. and hoping that the next update will unite all of us to strengthen us pool.
by the way, i am back online  Smiley
frodocooper
Moderator
Full Member
*
Offline Offline

Activity: 195
Merit: 261


View Profile
August 28, 2017, 02:23:21 PM
 #15791

I think one of the main reasons people choose to use jtoomimnet is the excessively increased new txn size/share limit which allows producing larger blocks at the expense of DoS vulnerability.

It's not excessive when the new transaction size per share limit is pegged to the Bitcoin network's block size limit. And it should be pegged to the Bitcoin network's limit.

There have been many instances of Bitcoin blocks being found within seconds of each other. One such example is this recent block by ckpool.org that was found a mere 19 seconds after the previous block, which incidentally is well below P2Pool's share interval of 30 seconds. If a mainnet P2Pool miner were to have found ckpool.org's block, that block would have had only a little more than 100 kB of transactions in it, because there was only time for one P2Pool share to be found, and so only 100 kB of new transactions plus whatever transactions can be found in the sharechain that weren't already used by Bitcoin after the most recent block, within that share. As it is, ckpool.org, without such an arbitrary limit, mined a block that was 918.59 kB in size and 3,674.12 kWU in weight, even after only 19 seconds from the previous block.

To put it simply, with mainnet P2Pool's limit of 100 kB of new transactions per share and with each share taking approximately 30 seconds to find, it would have to take mainnet P2Pool around five minutes to mine a full 1 MB block.

Not only are you shooting yourselves in both feet with this artificial limit (in terms of deliberately limiting how much transaction fees you would earn from blocks found in less than five minutes), but you are also intentionally placing a bottleneck in Bitcoin's transaction-confirmation process (and doing the Bitcoin network a great disservice) by intentionally not mining full blocks when you could have.

(Do not confuse full with big here, lest you accuse me of being a so-called "big-blocker." I support, and intend to continue to support, the Bitcoin Core chain.)

Edit: The third sentence in the second paragraph has been amended from "and so only 100 kB of new transactions and whatever that was left from mainnet P2Pool's 2.5 MB mempool after the previous block was found, within that share" to "and so only 100 kB of new transactions plus whatever transactions can be found in the sharechain that weren't already used by Bitcoin after the most recent block, within that share" to more accurately explain P2Pool's current working design.
veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
August 28, 2017, 02:32:51 PM
 #15792

There have been many instances of Bitcoin blocks being found within seconds of each other.
That doesn't mean that Bitcoin's target block time could be reduced to 30 seconds and is no reason P2Pool's shares could be 1MB.

P2Pool donation button | Bitrated user: veqtrus.
frodocooper
Moderator
Full Member
*
Offline Offline

Activity: 195
Merit: 261


View Profile
August 28, 2017, 03:04:45 PM
 #15793

That doesn't mean that Bitcoin's target block time could be reduced to 30 seconds and is no reason P2Pool's shares could be 1MB.

You're missing the point. Bitcoin's target of 10 minutes per block is not a definite interval (where blocks can only be found precisely within 10 minutes of each other) but a probabilistic one (where blocks are to be found within 10 minutes on average). As with all things probability-related, there are always outliers. In Bitcoin's case, such outliers (i.e., blocks that have been found within seconds of each other) have been rather common. The decision to limit mainnet P2Pool's share size limit to an arbitrary value that's lower than what the Bitcoin network demands is a decision to completely disregard these (common) outliers. You therefore deliberately harm yourselves (intentionally limiting your earnings from transaction fees) and the Bitcoin network (intentionally being a bottleneck in Bitcoin's transaction confirmation process) by disregarding the very real and statistically significant probability of blocks being found in less than five minutes.

In other words, you are deliberately choosing to not take into account the inherent element of chance in the mining of each and every Bitcoin block. There is absolutely no guarantee that the next P2Pool block would be found only after five minutes from the previous block. There is always a statistically significant chance (albeit a small one) that the next mainnet P2Pool block would be found in less than five minutes after the previous block, due to how Bitcoin mining inherently relies on chance. Again, you not only deliberately limit your potential earnings within the first five minutes after each new block, but also deliberately become a bottleneck in the Bitcoin network's transaction confirmation process within those five minutes, acting against your own interests and the interests of the Bitcoin network.
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1000



View Profile
August 28, 2017, 03:41:59 PM
 #15794

and, please, flush the SHARES files in the data folder, bitcoin folder in the P2Pool install directory (when you switch from v16 to v17).  Wink

sawa
Legendary
*
Offline Offline

Activity: 1258
Merit: 1002



View Profile
August 28, 2017, 03:45:12 PM
 #15795

I've moved ports of BTC pools on my server. Miners, check what you are mining, refresh the page on the BTC pool tabs and move asics to the network you need.

http://crypto.mine.nu:9334  - BTC(1% fee, jtoomimnet)
Currently hashrate: Local rate: 62.29 TH/s (DOA 4.79 TH/s / 7.68%)
The resources used by the node (the moments of the maximum CPU load):


http://crypto.mine.nu:9330 - BTC(0% fee, jtoomimnet)
Currently hashrate: Local rate: 0.00 H/s
The resources used by the node (the moments of the maximum CPU load):


http://crypto.mine.nu:9332 - BTC(0% fee, ForrestVnet)
Currently hashrate: Local rate: 3.11 TH/s (DOA 214.18 GH/s / 6.88%)
The resources used by the node (the moments of the maximum CPU load):


CPU: AMD Ryzen 7 1800X Eight-Core Processor
For both jtoomimnet nodes one processor core is allocated.
Another one core works completely for ForrestVnet node.

crypto.mine.nu and crypto.office-on-the.net are different names of the same server with different Internet channels

veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
August 28, 2017, 03:47:45 PM
 #15796

flush the SHARES files
What do you mean?

P2Pool donation button | Bitrated user: veqtrus.
veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
August 28, 2017, 03:50:32 PM
 #15797

As with all things probability-related, there are always outliers.
By reducing the target block interval you make those outliers the new average. The new outliers will be just a few seconds.

P2Pool donation button | Bitrated user: veqtrus.
Blue Bear
Jr. Member
*
Offline Offline

Activity: 31
Merit: 0

If a Bear sits on a miner does it break?


View Profile
August 28, 2017, 04:48:39 PM
 #15798

flush the SHARES files
What do you mean?
delete the share files in the folder
veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
August 28, 2017, 04:58:47 PM
 #15799

flush the SHARES files
What do you mean?
delete the share files in the folder
Why would that be needed?

P2Pool donation button | Bitrated user: veqtrus.
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
August 28, 2017, 07:37:18 PM
 #15800

so i tried https://github.com/jtoomim/p2pool - it worked ( although the invalid share rate was higher, sometimes 100% cpu usage.. )

now i switched back to https://github.com/p2pool/p2pool/ . but here the network is only 0.5 PH big ( 3 PH in the other version )

so am i an the wrong network, or are miners just frightened of the transition? will someone join me?

jtoomimnet requires more CPU and less RAM than mainnet ("master") p2pool. Because of this, it is strongly recommended to use pypy with jtoomimnet, as pypy trades off higher RAM usage for lower CPU usage. If you use pypy on jtoomimnet, you should have lower rates of invalid (DOA+stale) shares than when you mine on mainnet.

...

Yes, jtoomimnet has more hashrate. This is unlikely to change. jtoomimnet makes larger blocks and collects more fee revenue. If p2pool finds a block within about 30 seconds after the previous block, then jtoomimnet will make a ~999 kB block (plus whatever Segwit bonus there is) but mainnet would make a ~100 kB block. After 60 seconds, it's 999 vs 200 kB. After about 300 seconds, they reach parity and mainnet can mine full blocks. If you wish to verify this for yourself, wait for a block to be published (e.g. check blockchain.info), and then check the "Current block value:" on these two nodes:

http://crypto.mine.nu:9332/static/classic/ (mainnet)
http://crypto.mine.nu:9330/static/classic/ (jtoomimnet)

You can also use the share explorer to look at how the share/block values change over time. For example, this is the first share mined by p2pool on top of block 482381 for each of the two networks (links will go invalid the next time sawa restarts his nodes):

http://crypto.mine.nu:9332/static/classic/share.html#0000000000000e27a506eb2eacacdb12ae77cd1c28fe23789e5da35edd001d69 mainnet 12.66496688 BTC
http://crypto.mine.nu:9330/static/classic/share.html#0000000000000df957e19f5712d4efbf04bc825ab673a1e0db2e696bd8ce9961 jtoomimnet 15.53978325 BTC

Those two shares were mined within 1 second of each other. If the hash had been good enough to be a valid block, then jtoomimnet would have earned 2.874 more BTC (22.7% more) than mainnet. Here's a quick table of the differences for the first few shares after block 482381:

Share#BTC_differencejtoomimnet_btc mainnet_btc
1 2.87 15.5412.66
2 2.69 15.5412.85
3 2.50 15.5713.07
4 2.82 15.6912.86
5 2.79 15.76 12.97
6 2.36 15.81 13.45
7 1.95 15.97 14.03
8 1.78 16.00 14.23
9 3.53 16.07 12.54
10 1.69 16.13 14.44
11 1.34 15.98 14.64
12 1.48 16.14 14.66

The payout per block will sometimes be the same between the two networks, especially if the current block round has been going on for a while, but when there's a difference, it should be big and in jtoomimnet's favor.

The cost of the change that allows higher revenue on jtoomimnet is that p2pool has to deal with more transactions in the share chain. This increases the CPU, RAM, and bandwidth requirements for jtoomimnet. I added optimizations to the code that more than offset the RAM requirements and partially offset the CPU requirements. I have not yet addressed the network requirements, nor have I finished addressing the CPU requirements. Unfortunately, I'm a lazy loafer and only spend on average a few hours a week working on p2pool code, so things don't get done as fast as I'd like.

If you have a fast enough CPU and networking, and enough RAM, and if you can get pypy working, then jtoomimnet will have better expected revenue (bigger blocks), more frequent payouts (higher hashrate), fairer payouts (fewer orphan + DOA shares, smaller advantage to large miners), and will be better for Bitcoin (larger blocks) than mainnet (v17). jtoomimnet's support for Segwit also appears to be less glitchy than mainnet at the moment.

...


I expect I will have the code ready to have jtoomimnet fork into a Segwit2x and a Core chain before the Bitcoin fork happens. I would prefer it if nobody mined on the Core chain, but I think that freedom of choice is more important than having people follow my choice. The code for auto-forking is about 40% done so far.

The jtoomimnet code has some problems with altcoins still, and I haven't had a chance to investigate/fix them yet, so jtoomimnet is not ready for p2pool master. I would also like to fix the CPU usage (and maybe the RAM and network usage too), but whether I do that before or after merging into p2pool master is TBD.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
Pages: « 1 ... 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 809 810 811 812 813 814 »
  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!