Bitcoin Forum
April 19, 2019, 07:46:51 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2574327 times)
Smoovious
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500

Scattering my bits around the net since 1980


View Profile
July 07, 2012, 12:10:34 PM
 #2901

According to my math, my ~5 g/h is worth about .8 to .9 btc per block (assuming 50btc/block).  That's what it leveled out to yesterday after 24 hours of running.  30 minutes ago when I saw EVERY block in the low 60btc, my share went up 1.2.  And when we found the last block, I got a payout of 1.22.  Now every block is back down where I've always seen it (before the 60 incident), between 50 and 51, and my share is slowly decreasing, currently down to 0.9684.

I doubt my p2pool node is special, but unless I'm misreading the replies, I have yet to see a reasonable explanation as to why the blocks were in the 60s, then we found a block, now it's back down between 50-51.
It went back down because those transactions are no longer pending.

A significant number of those transactions were from satoshi-dice (I looked through the block a bit ago) which many pools have begun to either ignore, or throttle how many they will include.

In any event, one of us found the block, and we got all those fees, which is what bumped up your payout.

Now those transactions are no longer pending, and are no longer included in your next block value estimate.

-- Smoov
1555660011
Hero Member
*
Offline Offline

Posts: 1555660011

View Profile Personal Message (Offline)

Ignore
1555660011
Reply with quote  #2

1555660011
Report to moderator
1555660011
Hero Member
*
Offline Offline

Posts: 1555660011

View Profile Personal Message (Offline)

Ignore
1555660011
Reply with quote  #2

1555660011
Report to moderator
1555660011
Hero Member
*
Offline Offline

Posts: 1555660011

View Profile Personal Message (Offline)

Ignore
1555660011
Reply with quote  #2

1555660011
Report to moderator
100% New Software
PC, Mac, Android, & HTML5 Clients
Krill Rakeback
Low Rake
Bitcoin Poker 3.0
Bad Beat Jackpot
SwC Poker Relaunch
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1555660011
Hero Member
*
Offline Offline

Posts: 1555660011

View Profile Personal Message (Offline)

Ignore
1555660011
Reply with quote  #2

1555660011
Report to moderator
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
July 07, 2012, 12:22:42 PM
 #2902

According to my math, my ~5 g/h is worth about .8 to .9 btc per block (assuming 50btc/block).  That's what it leveled out to yesterday after 24 hours of running.  30 minutes ago when I saw EVERY block in the low 60btc, my share went up 1.2.  And when we found the last block, I got a payout of 1.22.  Now every block is back down where I've always seen it (before the 60 incident), between 50 and 51, and my share is slowly decreasing, currently down to 0.9684.

I doubt my p2pool node is special, but unless I'm misreading the replies, I have yet to see a reasonable explanation as to why the blocks were in the 60s, then we found a block, now it's back down between 50-51.
It went back down because those transactions are no longer pending.

A significant number of those transactions were from satoshi-dice (I looked through the block a bit ago) which many pools have begun to either ignore, or throttle how many they will include.

In any event, one of us found the block, and we got all those fees, which is what bumped up your payout.

Now those transactions are no longer pending, and are no longer included in your next block value estimate.

-- Smoov

That makes sense.  Basically what you're saying is p2pool is more likely to process satoshi-dice transactions, so if the bits align right, p2pool users get a lot of transactions in their block?

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
Smoovious
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500

Scattering my bits around the net since 1980


View Profile
July 07, 2012, 12:28:19 PM
 #2903

That makes sense.  Basically what you're saying is p2pool is more likely to process satoshi-dice transactions, so if the bits align right, p2pool users get a lot of transactions in their block?
Well, I don't know if p2pool distributes the transactions themselves or not, so this is just a guess... but I believe it depends on your bitcoind, and what it is set up to accept or reject.

I believe that your p2pool instance, is reporting the transactions your bitcoind knows about, and will include in the solved block.

-- Smoov


mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
July 07, 2012, 12:53:12 PM
 #2904

That makes sense.  Basically what you're saying is p2pool is more likely to process satoshi-dice transactions, so if the bits align right, p2pool users get a lot of transactions in their block?
Well, I don't know if p2pool distributes the transactions themselves or not, so this is just a guess... but I believe it depends on your bitcoind, and what it is set up to accept or reject.

I believe that your p2pool instance, is reporting the transactions your bitcoind knows about, and will include in the solved block.

-- Smoov

So... that implies that bitcoind is providing the work, and all the connections in p2pool (I have 32 atm) are for distributing what's found?  I think p2pool can feed bitcoind as well, which means overall the more connections on bitcoind and p2pool the better.

Yes?

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
rav3n_pl
Legendary
*
Offline Offline

Activity: 1360
Merit: 1000


Don`t panic! Organize!


View Profile WWW
July 07, 2012, 01:14:19 PM
 #2905

No. Smiley
P2pool is getting work form bitcoind. Each node do the same, but not all the nodes have exact same work because not all txes are in all places of bitcoin network at same time.
So if your node will found a block it will be closed in way your bitcoind see it. Then your "block found" and your closing tx is spread across p2pool nodes.
So it IS possible, that you see block value 61 and I see same block @ 55 and s1 else only 50.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
July 07, 2012, 01:32:29 PM
 #2906

No. Smiley
P2pool is getting work form bitcoind. Each node do the same, but not all the nodes have exact same work because not all txes are in all places of bitcoin network at same time.
So if your node will found a block it will be closed in way your bitcoind see it. Then your "block found" and your closing tx is spread across p2pool nodes.
So it IS possible, that you see block value 61 and I see same block @ 55 and s1 else only 50.

Good info, thanks.

What still puzzles me a little is why I consistently saw blocks in the low 60s.  It wasn't a one time deal, it stayed that one until we found a block, then it dropped.  And it was that way long enough for my payout to increase from .9 to 1.2, and as we know, the payout doesn't change rapidly.  I don't know how long it takes this info to propagate across the network.  That implies there's something wrong with my logic, or propagation is pretty slow.

BTW, I'm still regularly getting dupe submission messages.  I just saw this (biggest one I've seen so far):

2012-07-07 09:29:47.581000 > Worker q6600 @ 127.0.0.1 submitted share more than once!
2012-07-07 09:29:47.897000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:49.355000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:50.915000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:51.948000 > Worker miner1 @ 192.168.0.110 submitted share more than once!

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
Smoovious
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500

Scattering my bits around the net since 1980


View Profile
July 07, 2012, 01:41:39 PM
 #2907

What still puzzles me a little is why I consistently saw blocks in the low 60s.  It wasn't a one time deal, it stayed that one until we found a block, then it dropped.  And it was that way long enough for my payout to increase from .9 to 1.2, and as we know, the payout doesn't change rapidly.  I don't know how long it takes this info to propagate across the network.  That implies there's something wrong with my logic, or propagation is pretty slow.
Because other pools that found blocks, either weren't seeing the Tx's your bitcoind was seeing, or were rejecting them.

They could have been rejecting them based on their priority rating, fee amount, or simply the fact that many of them were Satoshi-Dice Tx's. Some people mining, reject all Tx's too.

If a Tx hasn't been included in a block, it stays available until someone includes it.

This is likely why you kept seeing the amount you were for as long as you were.

-- Smoov
twmz
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
July 07, 2012, 02:06:19 PM
 #2908

That block had a high reward because of these three transactions:

http://blockchain.info/tx-index/11490303/e287eb27bb543a82ce9bcad780583de9f7da4e2e1abef55395a97c931f6aa4cb
http://blockchain.info/tx-index/11490313/34b90a85b7e625f0a60ff1e3b3bdfd735d79393930e8515f9d8188dd72f638b9
http://blockchain.info/tx-index/11490553/e35818bec399da75796e7ff8235cf1fb2bfb2897f161dc4d1d17b2a8ef79bed2

The first has a 7.5 BTC fee attached, the second has a 3.1 BTC fee attached, and the third has a 2.9 BTC fee attached.

So 13.5 BTC fees between them and resulted in the block being worth 50 + 13.5 + some other small fees.

You p2pool console showed a 60+ BTC block reward for as long as these three transactions were sitting pending.  No other pool claimed them for some reason and when we eventually found a block, they were included in our block and we got the reward. As soon as we included them in a block, the estimated block reward in your p2pool console dropped back down to the normal 50ish BTC.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
rav3n_pl
Legendary
*
Offline Offline

Activity: 1360
Merit: 1000


Don`t panic! Organize!


View Profile WWW
July 07, 2012, 09:51:27 PM
 #2909

I posted a script in this thread that used git to autoupdate p2pool. Including it in the cron jobs of p2pcoin (and any Linux-based install) might be worth it.

For it to work, you must have :
- a p2pool checkout with git in a directory from which p2pool will be run,
- git...
- screen to run p2pool

If anyone's interested and can't find it I'll dig it up.

Yeah, if you can dig that up, let me know.  I'll include it in p2pcoin.
Here it is :
http://pastie.org/4166525

Everything should be self explanatory for anyone familiar with bash scripts and p2pool. It's configured for my needs but should easily be adapted. If you have any question when customizing it for p2pcoin I'd be happy to help.
Based on this script I made combination of 2 scripts that can be used at startup and in cron (every day/week) to keep p2pool updated.

First one os one-liner that atrually starts p2pool. This way you can easily edit pool options. Lets name it p2p.sh, put it in ~/ and make executable.
Code:
#!/bin/bash
screen -U -d -m python ~/p2pool/run_p2pool.py --irc-announce --merged http://nmcu:nmcp@127.0.0.1:8336/
Just add/remove merged mining in way you have it. All startup options on wiki: https://en.bitcoin.it/wiki/P2Pool#Option_Reference

Second script is checking for p2pool update and restart p2pool if need. If p2pool is not started (ie at boot) it starts it:
Code:
#!/bin/bash
EXISTINGPID=`pgrep -f run_p2pool`

cd ~/p2pool
echo "Checking for P2pool updates..."
if git pull | grep -q 'Already up-to-date'; then
    echo "P2pool is up to date."
    if [[ -z "$EXISTINGPID" ]]; then
        echo "Starting P2pool..."
        ~/p2p.sh
    fi
else
    echo "P2pool updated, starting..."
    ~/p2p.sh
    if [[ ! -z "$EXISTINGPID" ]]; then
        echo "Waiting for new p2pool to be ready..."
        sleep 90
        echo "Killing old p2pool."
        kill $EXISTINGPID
    fi
fi
I assume that p2pool is git cloned into ~/p2pool, if not edit proper line.

To avoid loss of hash power on pool restart (sometimes it might be about minute gap) remember to have backup pool in miner. It might be one of public: http://nodes.p2pmine.com/
Beauty of p2pool is, that you can mine at any node using own payout address and you get paid form sum of your shares Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
tucenaber
Sr. Member
****
Offline Offline

Activity: 337
Merit: 250


View Profile
July 08, 2012, 10:44:10 AM
Last edit: July 08, 2012, 11:08:38 AM by tucenaber
 #2910

No. Smiley
P2pool is getting work form bitcoind. Each node do the same, but not all the nodes have exact same work because not all txes are in all places of bitcoin network at same time.
So if your node will found a block it will be closed in way your bitcoind see it. Then your "block found" and your closing tx is spread across p2pool nodes.
So it IS possible, that you see block value 61 and I see same block @ 55 and s1 else only 50.

Good info, thanks.

What still puzzles me a little is why I consistently saw blocks in the low 60s.  It wasn't a one time deal, it stayed that one until we found a block, then it dropped.  And it was that way long enough for my payout to increase from .9 to 1.2, and as we know, the payout doesn't change rapidly.  I don't know how long it takes this info to propagate across the network.  That implies there's something wrong with my logic, or propagation is pretty slow.

BTW, I'm still regularly getting dupe submission messages.  I just saw this (biggest one I've seen so far):

2012-07-07 09:29:47.581000 > Worker q6600 @ 127.0.0.1 submitted share more than once!
2012-07-07 09:29:47.897000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:49.355000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:50.915000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:51.948000 > Worker miner1 @ 192.168.0.110 submitted share more than once!

M

I have this problem too and I've been doing some counting. The number as of now: accepted:29732 duplicates:2330 rejected:426. That is 7-8% duplicate shares of the total and the actual submitted good shares are only 91%.

I have also confirmed that the same hashes shows up in cgminer's sharelog and they are never submitted more than once. (EDIT: not true; occasionally the same hash is subitted three times)

Since the set contaning the submitted hashes is local to the got_response closure it seems to me that the duplicate check only affects submitted shares from the same get_work. Am I correct to conclude that this means that the problem is with cgminer?

Code:
       
    def get_work(self, pubkey_hash, desired_share_target, desired_pseudoshare_target):

        /.../

        received_header_hashes = set()

        def got_response(header, request):

            /.../

            elif header_hash in received_header_hashes:
                print >>sys.stderr, 'Worker %s @ %s submitted share %064x more than once!' % (request.getUser(), request.getClientIP(), header_hash)
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
July 08, 2012, 12:12:59 PM
 #2911

BTW, I'm still regularly getting dupe submission messages.  I just saw this (biggest one I've seen so far):

2012-07-07 09:29:47.581000 > Worker q6600 @ 127.0.0.1 submitted share more than once!
2012-07-07 09:29:47.897000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:49.355000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:50.915000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:51.948000 > Worker miner1 @ 192.168.0.110 submitted share more than once!

M

I have this problem too and I've been doing some counting. The number as of now: accepted:29732 duplicates:2330 rejected:426. That is 7-8% duplicate shares of the total and the actual submitted good shares are only 91%.

I have also confirmed that the same hashes shows up in cgminer's sharelog and they are never submitted more than once. (EDIT: not true; occasionally the same hash is subitted three times)

Since the set contaning the submitted hashes is local to the got_response closure it seems to me that the duplicate check only affects submitted shares from the same get_work. Am I correct to conclude that this means that the problem is with cgminer?

I think the problem is in p2pool, because I two of my miners are cgminer, one is phoenix, and I get dupes on all 3.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
tucenaber
Sr. Member
****
Offline Offline

Activity: 337
Merit: 250


View Profile
July 08, 2012, 12:15:33 PM
 #2912

I guess you are right. Then my only idea is the caching of work in WorkerInterface. Can someone shed some light on that?
forrestv
Hero Member
*****
Offline Offline

Activity: 516
Merit: 514


View Profile
July 08, 2012, 01:23:12 PM
 #2913

I guess you are right. Then my only idea is the caching of work in WorkerInterface. Can someone shed some light on that?

The work caching preserves the merkle root, but advances the timestamp by 12 seconds every time. It may be possible that CGminer is advancing the timestamp more than that (ignoring the X-Roll-NTime header, which is set to "expire=10"), and so redoing work.

EDIT: I'm going to add a check to P2Pool that warns about improperly rolled work. If anyone _ever_ sees this warning, we'll know that something is broken.

On the other hand, maybe CGminer retries submitting work before the original work submit is finished if it's slow? That would mean that there's no work actually being lost. I should really just look at the code...

I use CGminer and almost never see this message. Is there anything special about the mining rigs that this happens to? How many GPUs do they have?

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
tucenaber
Sr. Member
****
Offline Offline

Activity: 337
Merit: 250


View Profile
July 08, 2012, 01:38:07 PM
 #2914

I use CGminer and almost never see this message. Is there anything special about the mining rigs that this happens to? How many GPUs do they have?

I have two machines and both show this fenomenon but one has a much higher hashrate and therefore it is more noticable on that. One desktop machine with a single 5850 and a dedicated rig with 4 x 5850 + 10 x Icarus. Both of these are running linux and I have the latest version of both p2pool and cgminer.

Thanks for looking into it.
kano
Legendary
*
Offline Offline

Activity: 2786
Merit: 1151


Linux since 1997 RedHat 4


View Profile
July 08, 2012, 01:42:27 PM
 #2915

Also look at
 java API stats
that may show some interesting numbers
(though I have no idea what values to expect from p2pool)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
July 08, 2012, 02:30:34 PM
 #2916

I guess you are right. Then my only idea is the caching of work in WorkerInterface. Can someone shed some light on that?

The work caching preserves the merkle root, but advances the timestamp by 12 seconds every time. It may be possible that CGminer is advancing the timestamp more than that (ignoring the X-Roll-NTime header, which is set to "expire=10"), and so redoing work.

EDIT: I'm going to add a check to P2Pool that warns about improperly rolled work. If anyone _ever_ sees this warning, we'll know that something is broken.

On the other hand, maybe CGminer retries submitting work before the original work submit is finished if it's slow? That would mean that there's no work actually being lost. I should really just look at the code...

I use CGminer and almost never see this message. Is there anything special about the mining rigs that this happens to? How many GPUs do they have?

2012-07-07 09:29:47.581000 > Worker q6600 @ 127.0.0.1 submitted share more than once!
2012-07-07 09:29:47.897000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:49.355000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:50.915000 > Worker miner1 @ 192.168.0.110 submitted share more than once!
2012-07-07 09:29:51.948000 > Worker miner1 @ 192.168.0.110 submitted share more than once!

q6600 = my workstation, one 7870 on cgminer.  p2pool is running here.
miner1 = 4x7870 on cgminer
miner2 = 4x5870 on phoenix

I don't see miner2 that often, but I do see it.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
Peterae
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
July 08, 2012, 06:15:52 PM
 #2917

Can someone please explain to me why my local rate chart shows toal mean area 314Mhs for a week and 22Mhs Dead Mean yet P2Pool stats page only shows me @ 194Mhs and is normally way below what my live stats shows.

Thx
Smoovious
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500

Scattering my bits around the net since 1980


View Profile
July 08, 2012, 10:50:00 PM
 #2918

Can someone please explain to me why my local rate chart shows toal mean area 314Mhs for a week and 22Mhs Dead Mean yet P2Pool stats page only shows me @ 194Mhs and is normally way below what my live stats shows.

Thx

The chart is averaged out over the period the chart is displaying, and the stats shown in the console, are averaged out over the past 10 minutes or so, based on your diff-1 share submission, so luck will play a part too.

-- Smoov
rav3n_pl
Legendary
*
Offline Offline

Activity: 1360
Merit: 1000


Don`t panic! Organize!


View Profile WWW
July 08, 2012, 11:34:11 PM
 #2919

Can someone please explain to me why my local rate chart shows toal mean area 314Mhs for a week and 22Mhs Dead Mean yet P2Pool stats page only shows me @ 194Mhs and is normally way below what my live stats shows.

Thx

On p2pool.info you can see last 24hrs hashrate measured by shares accepted by pool.
On own chart you can see hour/day/wee/month measure by diff=1 shares.
Depends on your luck you can see that rate reflected in pool shares can be higher or lower than sd1 shares.
To compare what you see on p2pool.info and local page always see local last day.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1006


Poor impulse control.


View Profile WWW
July 08, 2012, 11:35:01 PM
 #2920

Can someone please explain to me why my local rate chart shows toal mean area 314Mhs for a week and 22Mhs Dead Mean yet P2Pool stats page only shows me @ 194Mhs and is normally way below what my live stats shows.

Thx


You're confusing the area (total megahashes, Mh) with the rate (megahashes per second, MHps). The actual rate you should expect from your given stats is: 314*86400*7/10^6 = 189.9 MHps. This is quite close to the 194 Mhps you quoted.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 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!