[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[p3yot33at3r]

Are those payments from merge mining? I've been using the daemon for a few days now but didn't receive any payments as of yet.....

Yes. You can tell from the pick logo & it says mined.

You sure you got the merge setup done correctly? Especially port fowarding & restarting the wallet once each step is completed. You might want to restart your p2p node too.

It's solo mining so a little bit of luck is needed.

How much hashpower does your node have?

Hmmm....everything seems in order:





Port 65534 is forwarded on my router, allowed on the ufw firewall, upnp is also activated on the router & daemon & is showing on my router logs. I've got no errors in my p2pool logs either - looks like there's a problem with the UNO daemon. I'll SSH into my rig, build the QT wallet & run with that for a while - that should give me a clue as to if the daemon is working properly or not. I'm hashing @ ~10TH

Has anyone else who is using the UNO daemon received any payments? If not, I'll contact FallingKnife & let him know there might be a bug.

EDIT: I've been running the daemon for about a week now, so should have received a few payments according to your wallet. I never installed QT as it's not needed for the daemons, so I'll have to do that first......

[yslyung]

Hmm it should work though.

I port fowarded both 65534/65535. Use 65535 on the merged cmd line.

Your conf ?

Merged cmd line? Used the correct rpcuser, pwd & port?

Yeah with 10ths you should see something.

[p3yot33at3r]

Yep, double checked all passwords & ports - although there's no need to forward the rpc ports as they are only used locally on 127.0.0.1 for merge mining. None of my rpc ports are forwarded on any other wallets & they work fine - it's only the UNO wallet that seems to be having issues. I'm compiling the QT wallet now.....

EDIT: QT compiled & running, I'll keep an eye on it for payments. In the meantime, if anyone else using the daemon hasn't received any payments - please post here, thanks.

[yslyung]

Yep, double checked all passwords & ports - although there's no need to forward the rpc ports as they are only used locally on 127.0.0.1 for merge mining. None of my rpc ports are forwarded on any other wallets & they work fine - it's only the UNO wallet that seems to be having issues. I'm compiling the QT wallet now.....

EDIT: QT compiled & running, I'll keep an eye on it for payments. In the meantime, if anyone else using the daemon hasn't received any payments - please post here, thanks.

thx for headsup again ... i'm on windows as i'm a linux noob .... so far so good for me ... 1 block per hour sometimes more ...



keep us updated

[yslyung]

btw windpath ... how do i add this to my node ?



thx ...

and also i can't seem to add or show node efficiency ...

feel a block is coming soon 

[windpath]

btw windpath ... how do i add this to my node ?



thx ...

and also i can't seem to add or show node efficiency ...

feel a block is coming soon 

I poll bitcoin core and p2pool nodes, store it in a DB, and calculate it....

[yslyung]

btw windpath ... how do i add this to my node ?



thx ...

and also i can't seem to add or show node efficiency ...

feel a block is coming soon 

I poll bitcoin core and p2pool nodes, store it in a DB, and calculate it....

any guide ? want to add that to my node if possible.

and wut did i said few mins earlier a block ? yeah !!!

BITCOIN BLOCK FOUND by 1GEvGnXQbALcjvw6Ed4Xek6f3wyCgXQRfb! https://blockchain.info/block/000000000000000007eff6dfc2ed5478164b2627917b96d494f800175b53abcc

[windpath]

any guide ? want to add that to my node if possible.

and wut did i said few mins earlier a block ? yeah !!!

BITCOIN BLOCK FOUND by 1GEvGnXQbALcjvw6Ed4Xek6f3wyCgXQRfb! https://blockchain.info/block/000000000000000007eff6dfc2ed5478164b2627917b96d494f800175b53abcc

Unfortunately not, I'll spend some time this afternoon and describe the setup, it's not overly complex...

[yslyung]

any guide ? want to add that to my node if possible.

and wut did i said few mins earlier a block ? yeah !!!

BITCOIN BLOCK FOUND by 1GEvGnXQbALcjvw6Ed4Xek6f3wyCgXQRfb! https://blockchain.info/block/000000000000000007eff6dfc2ed5478164b2627917b96d494f800175b53abcc

Unfortunately not, I'll spend some time this afternoon and describe the setup, it's not overly complex...

thx very much, looking forward to it !

[p3yot33at3r]

Yep, double checked all passwords & ports - although there's no need to forward the rpc ports as they are only used locally on 127.0.0.1 for merge mining. None of my rpc ports are forwarded on any other wallets & they work fine - it's only the UNO wallet that seems to be having issues. I'm compiling the QT wallet now.....

EDIT: QT compiled & running, I'll keep an eye on it for payments. In the meantime, if anyone else using the daemon hasn't received any payments - please post here, thanks.

Update: Well, I just received my first payment using the QT wallet, so now I know for sure there's no problem with my settings. I'm gonna switch back to using the daemon to see if the payments stop again.....

[windpath]

This will be a high level explanation of how my node works, it's not an exhaustive tutorial...

So here goes...

I built this over a year ago (when p2pool.info died) in a bit if a rush, and there are certainly things I would change today to make it more efficient....

It runs an an AWS LAMP server, and pulls data from both bitcoind and p2pool. Everything is gathered and stored locally on the server, there are no external API's.

The first thing you will need to do (in addition to the existing p2pool setup) is add

Code:

txindex=1

to your bitcoin.conf, restart it, and force a re-scan. This will force a lengthy re-index, and makes the data of all transactions available from the bitcoin API. (note: if you do this on an operating node be prepared for some extended downtime during the re-index).

Next I set up the DB (MySQL), again it was quick and dirty, and this DB is specifically focused on p2pool:

Code:

-- Host: localhost:3306
-- Generation Time: Jun 06, 2015 at 11:56 AM
-- Server version: 5.5.36
-- PHP Version: 5.4.28

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

--
-- Database: `p2pool`
--

-- --------------------------------------------------------

--
-- Table structure for table `block_payout`
--

CREATE TABLE IF NOT EXISTS `block_payout` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `block_id` int(11) NOT NULL,
  `address` varchar(34) NOT NULL,
  `ammount` decimal(10,8) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `address` (`address`),
  KEY `block_id` (`block_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=587605 ;

-- --------------------------------------------------------

--
-- Table structure for table `found_blocks`
--

CREATE TABLE IF NOT EXISTS `found_blocks` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `share` varchar(15) NOT NULL,
  `time` datetime NOT NULL,
  `hash` varchar(64) NOT NULL,
  `height` int(8) DEFAULT NULL,
  `orphan` tinyint(1) NOT NULL DEFAULT '0',
  `luck` decimal(8,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `height` (`height`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2555 ;

-- --------------------------------------------------------

--
-- Table structure for table `found_shares`
--

CREATE TABLE IF NOT EXISTS `found_shares` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `address` varchar(34) NOT NULL,
  `share` varchar(15) NOT NULL,
  `time` datetime NOT NULL,
  `doa` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=17889 ;

-- --------------------------------------------------------

--
-- Table structure for table `pool_stats`
--

CREATE TABLE IF NOT EXISTS `pool_stats` (
  `id` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `global_rate` varchar(72) NOT NULL,
  `global_nonstale_rate` varchar(20) NOT NULL,
  `diff` varchar(20) NOT NULL,
  `miners` int(7) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

So some quick explanation of the DB structure:

3 things not to overlook: charset = UTF8,  SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO", and SET time_zone = "+00:00".

The first 2 are self explanatory, the timezone must be set to UTC as that is what bitcoin uses globally in the block chain, was going to add a way for miners to set their local timezone in the views, but never got around to it.

Table block_payout contains the payout data by public address for every block P2Pool has found, it facilitates displaying total as well as per block payouts for miners (example). Originally I wrote a script to go over all the historical blocks and let it run, now it pulls them as we find blocks.

Table found_blocks has every block P2Pool has found, the p2pool share that found it, whether it was orphaned, and its luck. Again, added historical ones from a few sources provided by someone probably 100 pages back in this thread, new ones are added as they are found.

Table found_shares is specific to my node (I hated loosing all the shares on a re-start), so if you have ever found a share mining on my node, it's in there (example on miner shares tab).

Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).

The rest of the back end is basically 2 cron files, 1 that polls p2pool's log file and another that polls bitcoind. Both run once a minute, pull new data, check for orphans, calculate luck for new blocks, and store it in the DB.

The cron also renames the p2pool log file and saves it as a date stamped archive every 10MB, this greatly reduces memory usage when reading the log into memory.

Originally was adding blocks by searching the log for "GOT BLOCK", however this missed any stale shares that happened to find a block (and there are quite a few), so now I monitor a p2pool miner payout address for generation transactions as well (look out for donations!).

The front end is an ugly (code wise) mashup of p2pool's JS front ends and PHP running on the server. I used Bootstrap, a lot of cut and paste hacking, and some PHP to query the DB, calculate everything for the view, and display it.

In a nut shell, that's it.

All of this was done pretty openly in this thread with a lot of help from the community, a lot of the code logic is buried in this thread if you want to take a look at it.

If you give it a try and have any specific questions I'd be happy to try and help out.

[yslyung]

This will be a high level explanation of how my node works, it's not an exhaustive tutorial...

So here goes...

I built this over a year ago (when p2pool.info died) in a bit if a rush, and there are certainly things I would change today to make it more efficient....

It runs an an AWS LAMP server, and pulls data from both bitcoind and p2pool. Everything is gathered and stored locally on the server, there are no external API's.

The first thing you will need to do (in addition to the existing p2pool setup) is add

Code:

txindex=1

to your bitcoin.conf, restart it, and force a re-scan. This will force a lengthy re-index, and makes the data of all transactions available from the bitcoin API. (note: if you do this on an operating node be prepared for some extended downtime during the re-index).

Next I set up the DB (MySQL), again it was quick and dirty, and this DB is specifically focused on p2pool:

Code:

-- Host: localhost:3306
-- Generation Time: Jun 06, 2015 at 11:56 AM
-- Server version: 5.5.36
-- PHP Version: 5.4.28

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

--
-- Database: `p2pool`
--

-- --------------------------------------------------------

--
-- Table structure for table `block_payout`
--

CREATE TABLE IF NOT EXISTS `block_payout` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `block_id` int(11) NOT NULL,
  `address` varchar(34) NOT NULL,
  `ammount` decimal(10,8) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `address` (`address`),
  KEY `block_id` (`block_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=587605 ;

-- --------------------------------------------------------

--
-- Table structure for table `found_blocks`
--

CREATE TABLE IF NOT EXISTS `found_blocks` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `share` varchar(15) NOT NULL,
  `time` datetime NOT NULL,
  `hash` varchar(64) NOT NULL,
  `height` int(8) DEFAULT NULL,
  `orphan` tinyint(1) NOT NULL DEFAULT '0',
  `luck` decimal(8,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `height` (`height`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2555 ;

-- --------------------------------------------------------

--
-- Table structure for table `found_shares`
--

CREATE TABLE IF NOT EXISTS `found_shares` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `address` varchar(34) NOT NULL,
  `share` varchar(15) NOT NULL,
  `time` datetime NOT NULL,
  `doa` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=17889 ;

-- --------------------------------------------------------

--
-- Table structure for table `pool_stats`
--

CREATE TABLE IF NOT EXISTS `pool_stats` (
  `id` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `global_rate` varchar(72) NOT NULL,
  `global_nonstale_rate` varchar(20) NOT NULL,
  `diff` varchar(20) NOT NULL,
  `miners` int(7) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

So some quick explanation of the DB structure:

3 things not to overlook: charset = UTF8,  SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO", and SET time_zone = "+00:00".

The first 2 are self explanatory, the timezone must be set to UTC as that is what bitcoin uses globally in the block chain, was going to add a way for miners to set their local timezone in the views, but never got around to it.

Table block_payout contains the payout data by public address for every block P2Pool has found, it facilitates displaying total as well as per block payouts for miners (example). Originally I wrote a script to go over all the historical blocks and let it run, now it pulls them as we find blocks.

Table found_blocks has every block P2Pool has found, the p2pool share that found it, whether it was orphaned, and its luck. Again, added historical ones from a few sources provided by someone probably 100 pages back in this thread, new ones are added as they are found.

Table found_shares is specific to my node (I hated loosing all the shares on a re-start), so if you have ever found a share mining on my node, it's in there (example on miner shares tab).

Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).

The rest of the back end is basically 2 cron files, 1 that polls p2pool's log file and another that polls bitcoind. Both run once a minute, pull new data, check for orphans, calculate luck for new blocks, and store it in the DB.

The cron also renames the p2pool log file and saves it as a date stamped archive every 10MB, this greatly reduces memory usage when reading the log into memory.

Originally was adding blocks by searching the log for "GOT BLOCK", however this missed any stale shares that happened to find a block (and there are quite a few), so now I monitor a p2pool miner payout address for generation transactions as well (look out for donations!).

The front end is an ugly (code wise) mashup of p2pool's JS front ends and PHP running on the server. I used Bootstrap, a lot of cut and paste hacking, and some PHP to query the DB, calculate everything for the view, and display it.

In a nut shell, that's it.

All of this was done pretty openly in this thread with a lot of help from the community, a lot of the code logic is buried in this thread if you want to take a look at it.

If you give it a try and have any specific questions I'd be happy to try and help out.

prolly too long to reply here. u got pm & hopefully we can work from there.

whereistheblock ? i've bumped pool hashrate up earlier, i think it went over 3+ ph.

any other coins worth to merge ?

[Geremia]

Code:

-- Host: localhost:3306
-- Generation Time: Jun 06, 2015 at 11:56 AM
-- Server version: 5.5.36
-- PHP Version: 5.4.28

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

--
-- Database: `p2pool`
--

-- --------------------------------------------------------

--
-- Table structure for table `block_payout`
--

CREATE TABLE IF NOT EXISTS `block_payout` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `block_id` int(11) NOT NULL,
  `address` varchar(34) NOT NULL,
  `ammount` decimal(10,8) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `address` (`address`),
  KEY `block_id` (`block_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=587605 ;

-- --------------------------------------------------------

--
-- Table structure for table `found_blocks`
--

CREATE TABLE IF NOT EXISTS `found_blocks` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `share` varchar(15) NOT NULL,
  `time` datetime NOT NULL,
  `hash` varchar(64) NOT NULL,
  `height` int(8) DEFAULT NULL,
  `orphan` tinyint(1) NOT NULL DEFAULT '0',
  `luck` decimal(8,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `height` (`height`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2555 ;

-- --------------------------------------------------------

--
-- Table structure for table `found_shares`
--

CREATE TABLE IF NOT EXISTS `found_shares` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `address` varchar(34) NOT NULL,
  `share` varchar(15) NOT NULL,
  `time` datetime NOT NULL,
  `doa` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=17889 ;

-- --------------------------------------------------------

--
-- Table structure for table `pool_stats`
--

CREATE TABLE IF NOT EXISTS `pool_stats` (
  `id` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `global_rate` varchar(72) NOT NULL,
  `global_nonstale_rate` varchar(20) NOT NULL,
  `diff` varchar(20) NOT NULL,
  `miners` int(7) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Do you have all this and supporting code up on GitHub or somewhere else? If not you should put it all up.

[kano]

...
Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).
...

How do you calculate luck?

[windpath]

...
Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).
...

How do you calculate luck?

Basically after a lot of discussion, we ended up with pretty close to what is described here:

https://bitcointalk.org/index.php?topic=18313.msg7373650#msg7373650

I dug around to find it, the discussion started when p2pool.info went offline almost a year ago (The post is from June 18, 2014).

Edit: I know our stats look crazy high right now, in fact just found another block at 222.82%, but we are on a nice streak.... Take a look at the times between the last 10 blocks we have found, all except 1 much better then expected. We have paid our dues with the bad times recently, looks like it's turned around

[yslyung]

...
Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).
...

How do you calculate luck?

thats wut i wanna add to my node .... & been trying to figure that out.

math looks right to me windpath ....

now a how to for a noob .. thx

[kano]

...
Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).
...

How do you calculate luck?

Basically after a lot of discussion, we ended up with pretty close to what is described here:

https://bitcointalk.org/index.php?topic=18313.msg7373650#msg7373650

I dug around to find it, the discussion started when p2pool.info went offline almost a year ago (The post is from June 18, 2014).

Edit: I know our stats look crazy high right now, in fact just found another block at 222.82%, but we are on a nice streak.... Take a look at the times between the last 10 blocks we have found, all except 1 much better then expected. We have paid our dues with the bad times recently, looks like it's turned around

Well, those calculations are based on other calculations that have their own accuracy issues.

The correct and direct definition of luck (where >100% is good luck and less than 100% is bad luck) is simply DifficultyExpected/DifficultySubmitted

Those are two number that you should have - the other numbers you use are calculated from them.
The pool hash rate (as you may well have seen) is, like any pool, only an estimate, and not very accurate either.

My real question, though, is do you count blocks that are not part of the share chain?
If you do, then you must also include the hashes used to find those blocks.
Adding a block into your luck figure without including the hashes expended to find that block is, obviously, incorrect.

[p3yot33at3r]

Hi all, just a heads up.

I'm using Xubuntu 14.04 64bit & have found that when using the Unobtanium daemon for merge mining I'm not receiving any payments, but if I use the QT wallet - payments are received in the normal way. I've recompiled the daemon a few times with no errors & I get no errors in my p2pool logs either - the payments just don't appear in my wallet, yet as soon as I use the QT wallet, payments resume as normal.

I will report the issue on the Unobtanium thread, but I recommend that anyone using the Unobtanium daemon on NIX to check that they are receiving their merge mined payments & if not, to switch to the QT wallet instead. Unfortunately it seems that previous lost payments are just that - lost.

I'm not sure if this issue is the same for other OS's, but I'd check anyway, just to be sure.

[Meuh6879]

this is not a p2pool direct network payment.

this screen is a pool (perhaps with a NODE connected to a P2Pool).
this POOL pay regulary.




on REAL P2Pool, you are pay when block is found only ... 1 block find with P2Pool = 1 transaction.
history of BLOCK FOUND By P2Pool is here : http://minefast.coincadence.com/p2pool-stats.php

on 6/6/15 ... only 2 blocks are found (02h17 and 15h07).

[yslyung]

this is not a p2pool direct network payment.

this screen is a pool (perhaps with a NODE connected to a P2Pool).
this POOL pay regulary.




on REAL P2Pool, you are pay when block is found only ... 1 block find with P2Pool = 1 transaction.
history of BLOCK FOUND By P2Pool is here : http://minefast.coincadence.com/p2pool-stats.php

on 6/6/15 ... only 2 blocks are found (02h17 and 15h07).

what are you trying to say ?

we're talking about merged mining uno with p2pool

lost here...maybe you wanna elaborate ?

qt works but not daemon