[ALONE]

Seriously folks.  Why are you mining there?  You are giving up SO MUCH coin.  Here's just the past 24 hours:

In the past 24 hours, Antpool has made 29.50355862BTC for themselves from transaction fees ALONE.  They've solved 17 blocks, which means they've made an average of about 1.74BTC per block.  That turns into 13.88% fees they are charging their miners.

Why are you giving up 13.88% of your income?

Mine on a pool that pays you for your work.

All,

I just want to ensure I understand what I need to do to support the segwit changes from a pool operator perspective.  Please comment/correct/add anything I may miss.

1) Call to GBT.  I must add the following when I call getblocktemplate:

Code:

{"rules":["segwit"]}

2) Use txid instead of hash from GBT output to calculate merkle root. I don't ever have to use the "hash" because even transactions from non-upgraded wallets will, when my upgraded node processes them, replicate the value in "hash" to "txid".

Code:

{
      "data": "010000000201647651a5699449ef97d5fdeb71233401d36f727826c0c0949dee3971b1690d00000000fc0047304402204e92b2e7a58a8f73351f0fe0f889826cc5760ba83ac4d380a911f4749e5e610f02200bd00f948af01c7b7336089430e5bb02b6e80a9135160d95d81b5843cb68099d01473044022015d4229114b2e3fc3d56eb026860189600f0b076b0d74aabe227128138cb1f4402202bbb82fdcb375042ede6f82e3f65953265544eaabe318bdaab857117321f8e9f014c6952210237679c99cf1548455c2dbdd95398308527d22bb8eb78c6f2f8bfc098151fbc192102a5c087ca7b03f6dd98611f204fd976d773eeae4248a49b790c283b1ec31025012103382f2f9dc0f901344ffda60bb330df103159015c0b2fd436ffcb5a8f5da35cc353aeffffffffbaadf8627fa17569d1d24aa4c8d433ae00edfb9d4a2b84e450e440cdaead7e9500000000fdfd00004730440220132f5c91d923c7d9baeb1c3f47b2dbd16b5e646b80af3a0ef0adb4880859d23d022022629c007bb581de55e4710f79c4d2e8115082328b0eacc0c659206fcee3981801483045022100ca2175bcb9a56473745a1341276b0d51cbc34829b70292de971e6ce608bd6234022032a71e54c345e45d78fcaf31cf6b36ed39cf2349a8a47b3fde030c2dc4dfc58a014c6952210237679c99cf1548455c2dbdd95398308527d22bb8eb78c6f2f8bfc098151fbc192102a5c087ca7b03f6dd98611f204fd976d773eeae4248a49b790c283b1ec31025012103382f2f9dc0f901344ffda60bb330df103159015c0b2fd436ffcb5a8f5da35cc353aeffffffff02a0860100000000001976a91496e85759feba955df98e8af83e3ca97ba0bf4ea488acb88201000000000017a914e830166009d9b44ff7c8e9ade5fdc1a5bcf3a2858700000000",
      "txid": "9b18cadc4124913f12c16bd0a97b8df5437761f1d08cabb84a216a72b818c086",
      "hash": "9b18cadc4124913f12c16bd0a97b8df5437761f1d08cabb84a216a72b818c086",
      "depends": [
      ],
      "fee": 1000,
      "sigops": 28,
      "weight": 2660
    }

3) Append witness commitment to coinbase transaction as OP_RETURN in the following format:

Code:

0x6a24aa21a9ed + witness root hash

The witness hash can be pulled from GBT call as "default_witness_commitment".

Anything I've missed here?

Thanks in advance!

Jonny

All,

Firstly, I apologize if this should have been started in another area.

I've recently started work on supporting SegWit on my pool.  As is typical, I always ensure I execute against testnet well before I put anything into the live network.

So, I fire up my trusty dev box and build 0.13.1 from source (I had 0.12.0 on the box already).  Everything goes swimmingly, and I start up the daemon.  Blocks start downloading and everything synchronizes just fine.  First call I make is

Code:

bitcoin-cli getblocktemplate

The result was rather shocking:

Code:

error code: -8
error message:
Support for 'segwit' rule requires explicit client support

I've got 0.13.1 running locally on my laptop, so I called GBT there.  Returned exactly what I was expecting.  The obvious difference between the two networks is that segwit is active on testnet, while it isn't on live.

I now called

Code:

bitcoin-cli getinfo

Rather strange message came back from that call:

Code:

{
  "version": 130100,
  "protocolversion": 70014,
  "walletversion": 60000,
  "balance": 819.87897567,
  "blocks": 1031754,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 75262.00820103039,
  "testnet": true,
  "keypoololdest": 1459284919,
  "keypoolsize": 100,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": "Warning: unknown new rules activated (versionbit 28)"
}

Is this what is preventing me from successfully building a block template, but allowing other calls to successfully execute?

Any help or guidance would be greatly appreciated.

So, I've got a few bitcoin daemons running on multiple OS.  Things typically go smoothly; however, every now and then one of them will simply stop getting new blocks.  Even though it is fully connected to the network and is responding to queries fine, it's just not caught up.  I could understand if it were a few seconds back because of block propagation, but sometimes it's many minutes and multiple blocks behind.

The process itself isn't frozen, the debug log shows nothing amiss - typical advertise local messages, connections coming in, etc.  Yes, the proper ports are opened.  The CPU isn't spiked.  There's plenty of free RAM.  It's like it just decides to forget about the fact that it's supposed to get new blocks.  If I restart the process, it immediately gets the blocks it was behind.

Any thoughts?

[typical miners]

So we all know what happened with Nexious, and a bunch of people got burned.  We also know that it seems to be the latest fashion for newbie accounts to announce their own pools.  Whether or not they are sincere, or are just trying to play the same scam Nexious did, I don't know.

In light of this, I decided to open up my own pool.  I figured I'd do the community a favor and offer my own. No frills, no BS. The pool is here for a simple reason: to give you a choice.  The pool mines BTC.  No merge mining.  No alt coins.  Straight up BTC mining.

You can see my announcement here: https://bitcointalk.org/index.php?topic=104664.msg13126185#msg13126185

I've actually updated the maximum difficulty since I wrote that to better manage large hash miners.  Here are the current specs:

Pool:                        Jonny Bravo's Mining Emporium
Website:                   http://www.bravo-mining.com
Proxy:                      No
Generation address:  14KxdJ7DfAPsxCYkpcDTcKotjeProcfRPo
Coinbase signature:   /bravo-mining/
Payout method:         PPLNS
Fee:                         0.5%
Pay Tx Reward:         Yes
Vardiff:                    starts at 1042.  Range from 8 to 1048576.
Local Work:              stratum
Pay Orphans:           No
Min Withdrawal:       0.001
Merge Mining:          No
Location:                 US

I've actually held off making this announcement and soft launched the pool at the end of November.  Well, now I'm making it public.

The pool has already found its first block: https://www.blocktrail.com/BTC/block/000000000000000003c3a6ee87941ea88ab99490e7774ae25dc48deb9aa2bf72

Oh... and here's the important bit... the miners were paid for their contributions .

How to connect typical miners:
US

Code:

./cgminer -o stratum+tcp://stratum.bravo-mining.com:3333 -u Weblogin.WorkerName -p WorkerPassword

EU

Code:

./cgminer -o stratum+tcp://eu.stratum.bravo-mining.com:3333 -u Weblogin.WorkerName -p WorkerPassword

For large hash rate renters, I've opened up port 3334.  Starting diff is 2097151.  Minimum diff is 1048575. Max is 16777215.
US

Code:

./cgminer -o stratum+tcp://stratum.bravo-mining.com:3334 -u Weblogin.WorkerName -p WorkerPassword

EU

Code:

./cgminer -o stratum+tcp://eu.stratum.bravo-mining.com:3334 -u Weblogin.WorkerName -p WorkerPassword

For miners with an S2 or similar device that doesn't play well with vardiff, I've opened up port 3999.  This is a fixed diff of 999 and should help lower your reject rates.
US

Code:

./cgminer -o stratum+tcp://stratum.bravo-mining.com:3999 -u Weblogin.WorkerName -p WorkerPassword

EU

Code:

./cgminer -o stratum+tcp://eu.stratum.bravo-mining.com:3999 -u Weblogin.WorkerName -p WorkerPassword

For miners with firewall blocks or issues, I've opened up port 80.  This is a vardiff port.  Starting diff is 10042.  Min diff is 1042.  Max diff is 1048576.
US

Code:

./cgminer -o stratum+tcp://stratum.bravo-mining.com:80 -u Weblogin.WorkerName -p WorkerPassword

EU

Code:

./cgminer -o stratum+tcp://eu.stratum.bravo-mining.com:80 -u Weblogin.WorkerName -p WorkerPassword

• You MUST register and use a valid email address because the pool requires you to validate
• PPLNS payouts with 5N share life
• MPOS front end running on NOMP stratum
• NO SPV MINING - we mine only on fully validated blocks

So, if you're looking for somewhere to point your hash, give us a try.  You aren't going to get scammed, bamboozled, swindled or defrauded here.  Proof is in the pudding: we've found our first block and miners were paid.

How to Contact Us

• Here on this thread
• Email: admin@bravo-mining.com
• IRC: #bravo-mining
• Twitter: @bravo_mining
• Facebook: Bravo Mining
• On the pool's website: Contact Us

Thanks, and I look forward to seeing some of you there.

Hey everyone,

I run a NOMP/MPOS Bitcoin mining pool and have seen a number of issues related to duplicate share submission and the resolutions to address them.  Can somebody post a log snippet of what that would look like?

Also, to implement the fixes, is it just a matter of making the change in the appropriate JS files and restarting the stratum servers, or are there then some other steps that need to be taken?

Thanks in advance!

The past few days I've seen a ton of bogus posts from brand new users that are just basically random words thrown together.  What gives?  I've seen this on other forums before, but never here...

At least my "report to moderator" finger has been getting a workout

[MUST]

So we all know what happened with Nexious, and a bunch of people got burned.  We also know that it seems to be the latest fashion for newbie accounts to announce their own pools.  Whether or not they are sincere, or are just trying to play the same scam Nexious did, I don't know.

In light of this, I decided to open up my own pool.  I figured I'd do the community a favor and offer my own. No frills, no BS. The pool is here for a simple reason: to give you a choice.  The pool mines BTC.  No merge mining.  No alt coins.  Straight up BTC mining.

You can see my announcement here: https://bitcointalk.org/index.php?topic=104664.msg13126185#msg13126185

I've actually updated the maximum difficulty since I wrote that to better manage large hash miners.  Here are the current specs:

Pool:                        Jonny Bravo's Mining Emporium
Website:                   http://www.bravo-mining.com
Proxy:                      No
Generation address:  14KxdJ7DfAPsxCYkpcDTcKotjeProcfRPo
Coinbase signature:   /bravo-mining/
Payout method:         PPLNS
Fee:                         0.5%
Pay Tx Reward:         Yes
Vardiff:                    starts at 1042.  Range from 8 to 1048576.
Local Work:              stratum
Pay Orphans:           No
Min Withdrawal:       0.001
Merge Mining:          No
Location:                 US

I've actually held off making this announcement and soft launched the pool at the end of November.  Well, now I'm making it public.

The pool has already found its first block: https://www.blocktrail.com/BTC/block/000000000000000003c3a6ee87941ea88ab99490e7774ae25dc48deb9aa2bf72

Oh... and here's the important bit... the miners were paid for their contributions .

How to connect:

Code:

./cgminer -o stratum+tcp://stratum.bravo-mining.com:3333 -u Weblogin.WorkerName -p WorkerPassword

• You MUST register and use a valid email address because the pool requires you to validate
• PPLNS payouts with 5N share life
• MPOS front end running on NOMP stratum
• NO SPV MINING - we mine only on fully validated blocks

Currently we're averaging about 25TH; however, I regularly throw 500TH - 1PH rentals at the site (that's how we found our first block) so the hash rate varies considerably and is why I didn't put any value in the thread title.

So, if you're looking for somewhere to point your hash, give us a try.  You aren't going to get scammed, bamboozled, swindled or defrauded here.  Proof is in the pudding: we've found our first block and miners were paid.

For any support issues, you can reach me here on this thread, by PM, by email admin at bravo-mining dot com, or if you like to chat, I setup an IRC channel on freenode: #bravo-mining.

Thanks, and I look forward to seeing some of you there.

Hey everyone,

I asked this in the Technical Support forums as well, but thought I'd try my luck here, too.  Since a lot of alt coin pools run on the NOMP/MPOS combination, perhaps some of you pool operators have run into a similar issue, and have a solution.  Below is the text from my post:

All,

Very recently I have run into an issue with my bitcoin daemon.  I am wondering if it might have to do with the pool software I'm running on top of it, and will likely ask this same question if I can find a forum thread for the pool .  Here's what I notice:

1) I start up the bitcoin daemon process and all is happy.
2) After about 24 hours, the process becomes completely unresponsive.  Typing:

Code:

bitcoin-cli getpeerinfo

Or any other command just hangs without returning.
3) This causes all kinds of havoc on my pool.  Website runs exceptionally slow.  I get bombarded with mail from the cron jobs saying they're already running.  Things like that.  When I look at my debug.log, all I see is it trying to create new blocks:

Code:

2015-12-03 12:26:06 CreateNewBlock(): total size 998979
2015-12-03 12:26:12 CreateNewBlock(): total size 998945
2015-12-03 12:26:18 CreateNewBlock(): total size 998993
2015-12-03 12:26:24 CreateNewBlock(): total size 998883
2015-12-03 12:26:30 CreateNewBlock(): total size 998978
2015-12-03 12:26:36 CreateNewBlock(): total size 998837
2015-12-03 12:26:42 CreateNewBlock(): total size 998842
2015-12-03 12:26:48 CreateNewBlock(): total size 998971
2015-12-03 12:26:54 CreateNewBlock(): total size 998913
2015-12-03 12:26:58 keypool reserve 3
2015-12-03 12:26:58 keypool return 3
2015-12-03 12:27:00 CreateNewBlock(): total size 998914

The fact that it's trying to create a new block every 6 seconds seems a bit odd, but looking at the log shows that is pretty consistently happening, even when things are running smoothly.

My only recourse is to kill the process and restart it.  Doing so makes everything run smoothly once again.  Once restarted, I can see typically "normal" things in the log:

Code:

015-12-03 13:00:45 CreateNewBlock(): total size 696619
2015-12-03 13:00:48 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-12-03 13:00:48 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:00:52 CreateNewBlock(): total size 701939
2015-12-03 13:00:53 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:00:56 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:00:58 CreateNewBlock(): total size 707323
2015-12-03 13:00:59 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:01:03 CreateNewBlock(): total size 719860

By the way, I'm running 0.11.2 compiled and built from source on Ubuntu 15.10.  Pool is running MPOS/NOMP.  Processes are running on a 4 core box with 8G RAM.  Looking at CPU usage, bitcoind is about 150% or more when it is unresponsive.  Typically it ranges anywhere from 30% to 80%.

I'm wondering if having a max block size of 1M is causing problems.  If you look at the two log snippets I included above, when it was completely unresponsive, all it was doing was trying to create new blocks of max size (or very close to it).  When things are running smoothly, the blocks its trying to create are considerably smaller.

Thanks in advance for any suggestions.

All,

Very recently I have run into an issue with my bitcoin daemon.  I am wondering if it might have to do with the pool software I'm running on top of it, and will likely ask this same question if I can find a forum thread for the pool .  Here's what I notice:

1) I start up the bitcoin daemon process and all is happy.
2) After about 24 hours, the process becomes completely unresponsive.  Typing:

Code:

bitcoin-cli getpeerinfo

Or any other command just hangs without returning.
3) This causes all kinds of havoc on my pool.  Website runs exceptionally slow.  I get bombarded with mail from the cron jobs saying they're already running.  Things like that.  When I look at my debug.log, all I see is it trying to create new blocks:

Code:

2015-12-03 12:26:06 CreateNewBlock(): total size 998979
2015-12-03 12:26:12 CreateNewBlock(): total size 998945
2015-12-03 12:26:18 CreateNewBlock(): total size 998993
2015-12-03 12:26:24 CreateNewBlock(): total size 998883
2015-12-03 12:26:30 CreateNewBlock(): total size 998978
2015-12-03 12:26:36 CreateNewBlock(): total size 998837
2015-12-03 12:26:42 CreateNewBlock(): total size 998842
2015-12-03 12:26:48 CreateNewBlock(): total size 998971
2015-12-03 12:26:54 CreateNewBlock(): total size 998913
2015-12-03 12:26:58 keypool reserve 3
2015-12-03 12:26:58 keypool return 3
2015-12-03 12:27:00 CreateNewBlock(): total size 998914

The fact that it's trying to create a new block every 6 seconds seems a bit odd, but looking at the log shows that is pretty consistently happening, even when things are running smoothly.

My only recourse is to kill the process and restart it.  Doing so makes everything run smoothly once again.  Once restarted, I can see typically "normal" things in the log:

Code:

015-12-03 13:00:45 CreateNewBlock(): total size 696619
2015-12-03 13:00:48 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-12-03 13:00:48 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:00:52 CreateNewBlock(): total size 701939
2015-12-03 13:00:53 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:00:56 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:00:58 CreateNewBlock(): total size 707323
2015-12-03 13:00:59 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-12-03 13:01:03 CreateNewBlock(): total size 719860

By the way, I'm running 0.11.2 compiled and built from source on Ubuntu 15.10.  Pool is running MPOS/NOMP.  Processes are running on a 4 core box with 8G RAM.  Looking at CPU usage, bitcoind is about 150% or more when it is unresponsive.  Typically it ranges anywhere from 30% to 80%.

I'm wondering if having a max block size of 1M is causing problems.  If you look at the two log snippets I included above, when it was completely unresponsive, all it was doing was trying to create new blocks of max size (or very close to it).  When things are running smoothly, the blocks its trying to create are considerably smaller.

Thanks in advance for any suggestions.

[(from bitcoind) EXCEPTION: St12out_of_range CInv::GetCommand() : type=513 unknown type bitcoin in ProcessMessages()]

I run my own p2pool node (have for well over a year).  Today, I started seeing something I've never seen...

(from bitcoind) EXCEPTION: St12out_of_range CInv::GetCommand() : type=513 unknown type bitcoin in ProcessMessages()

First time I've seen this... Anyone have any ideas?

My p2pool node is 104.131.12.128:9332 if anyone wants to see the error...

Here's the snippet from the p2pool log:

Code:

2015-06-26 09:58:14.329592 P2Pool: 17376 shares in chain (17380 verified/17380 total) Peers: 41 (34 incoming)
2015-06-26 09:58:14.329634  Local: 2680GH/s in last 10.0 minutes Local dead on arrival: ~6.4% (4-9%) Expected time to share: 1.4 hours
2015-06-26 09:58:14.329676  Shares: 1048 (85 orphan, 68 dead) Stale rate: ~14.6% (12-17%) Efficiency: ~96.1% (93-99%) Current payout: (0.0000)=0.0000 BTC
2015-06-26 09:58:14.329724  Pool: 1259TH/s Stale rate: 11.1% Expected time to block: 2.0 days
2015-06-26 09:58:15.623680 Peer sent entire transaction 1170fcf19ad833fb8f237004c0efc59e46697dab9b81850478d4fa6f8ae18575 that was already received
2015-06-26 09:58:16.125142 Peer sent entire transaction 0b7dbeb74599087db6b263919499c71cf05da374b7d809a47585ce2c5f4f0dd2 that was already received
2015-06-26 09:58:17.291632 Peer sent entire transaction ea49a8b720dd2b4eea58f9eaff5b58fd780f5375b6de3ed6e328557658ffc71b that was already received
2015-06-26 09:58:17.333289 > ########################################
2015-06-26 09:58:17.333419 > >>> Warning: (from bitcoind) EXCEPTION: St12out_of_range
2015-06-26 09:58:17.333473 > CInv::GetCommand() : type=513 unknown type
2015-06-26 09:58:17.333520 > bitcoin in ProcessMessages()
2015-06-26 09:58:17.333567 >
2015-06-26 09:58:17.333620 > ########################################

Here's what the bitcoin log shows:

Code:

2015-06-26 13:58:02 socket recv error Connection reset by peer (104)
2015-06-26 13:58:03 CreateNewBlock(): total size 749911
2015-06-26 13:58:21 CreateNewBlock(): total size 749862
2015-06-26 13:58:38 CreateNewBlock(): total size 749950
2015-06-26 13:58:38 receive version message: : version 40000, blocks=0, us=104.131.12.128:8333, peer=122431
2015-06-26 13:58:38 Added time data, samples 200, offset -40 (+0 minutes)
2015-06-26 13:58:55 CreateNewBlock(): total size 749874

Not a lot of help there...

From bitcoind:

Code:

miner@devildog:~/bitcoin-0.10.2/src$ ./bitcoin-cli getinfo
{
    "version" : 100200,
    "protocolversion" : 70002,
    "blocks" : 362645,
    "timeoffset" : 0,
    "connections" : 97,
    "proxy" : "",
    "difficulty" : 49692386354.89383698,
    "testnet" : false,
    "relayfee" : 0.00001000,
    "errors" : "EXCEPTION: St12out_of_range       \nCInv::GetCommand() : type=513 unknown type       \nbitcoin in ProcessMessages()       \n"
}

I also posted this in the p2pool thread, but since it's directly from bitcoin core, I thought I'd cross post it here as well in case anyone might be able to provide some more information.

Edit: some potentially relevant information...

Bitcoin is compiled from source and is running on Ubuntu 14.04

Code:

miner@devildog:~/bitcoin-0.10.2/src$ uname -a
Linux devildog 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

So, as a fun side project I decided to write some code to traverse the blockchain and look for "empty" blocks.  An empty block is one that contains only a single transaction - the coinbase transaction that awards the generated coins.  Not surprisingly, a whole bunch of the early blocks are indeed empty.

However, what truly surprised me is when I tried to parse the transactions.  For a very large number of transactions, Bitcoin Core just doesn't return anything useful.  Here's an example below for block 337104:

Code:

getblockhash 337104
00000000000000000cc790ec61cd20d394f9d0f0c3e34adb1005d2d909b3f691

Code:

getblock 00000000000000000cc790ec61cd20d394f9d0f0c3e34adb1005d2d909b3f691

{
"hash" : "00000000000000000cc790ec61cd20d394f9d0f0c3e34adb1005d2d909b3f691",
"confirmations" : 23233,
"size" : 256,
"height" : 337104,
"version" : 2,
"merkleroot" : "57224de458d9356a471099c5ab9f5e68f395ec5f2822915bdf3c6b296c1428e2",
"tx" : [
"57224de458d9356a471099c5ab9f5e68f395ec5f2822915bdf3c6b296c1428e2"
],
"time" : 1420197655,
"nonce" : 3357110901,
"bits" : "181b0dca",
"difficulty" : 40640955016.57649231,
"chainwork" : "00000000000000000000000000000000000000000003beb652b37a2f4b948166",
"previousblockhash" : "00000000000000001654d3aa9abac3e815391b9b5eca90e15767cc1ee6ce1dc2",
"nextblockhash" : "00000000000000001686943c32233916b9d9485230bf63fc0f9144c94be4c1af"
}

Code:

getrawtransaction 57224de458d9356a471099c5ab9f5e68f395ec5f2822915bdf3c6b296c1428e2 1
No information available about transaction (code -5)

The key piece is that last call about the transaction.  Core doesn't know anything about it.

Yet, if I look at that same transaction on blockchain.info I can see it clearly, and can parse the coinbase script to see the block was mined by Discus Fish:
 �$七彩神仙鱼��mmvs��̮���M���,���w, z1FaW���f
Z�rMined by andy518038

Anyone have any idea?

There's been quite a bit of discussion on this topic throughout the forum.  Some feel empty blocks are valuable.  Others feel they are of no value.

I thought it might be fun to write a small program to see just how many of these blocks exist in the blockchain.  For those who don't know, an empty block is a block that is mined containing only the coinbase transaction that awards the new coins.  To be honest, I was quite frankly surprised by the number there were, especially since people seemed to think they were rare occurrences.  Sure, I expected there to be quite a few at the beginning of the blockchain when BTC was pretty much an unknown and only a select few were mining it.  However, I was not expecting there to be so many empty blocks as there are.

As of block 360189 there are 85295 empty blocks on the chain.  For the math challenged, 23.68% of all blocks are empty.  8 of the last 189 blocks are empty.  25 of the last 1000 are empty.

Maybe I'll get ambitious and write the output to a spreadsheet so I can get some good data points out of this to see trends.

Where do you stand on this debate?

EDIT: I've uploaded the data from my last run.

https://www.dropbox.com/s/2rt64pt6hyhr41b/btc_stats.zip?dl=0.  Has blocks up to 364144

Archive contains two files:

empty_blocks.csv has the raw data in the following format:

Block Height, NumTx, BlockTime (UTC), BlockSize (Bytes), WhoMined (if I could figure it out, BTC address of coinbase transaction if I couldn't, or unknown if no BTC address could be deciphered from coinbase transaction).

stats.csv has data on pools, how many blocks they've mined, how many were empty and percentage of empty to total.

Enjoy.

[Running totals]

TL;DR - Comparison of payouts of NastyPoP and NastyP2P.  Here's the current chart showing payouts over time:



Expected Payouts vs Actuals



Raw spreadsheet:

https://www.dropbox.com/s/vv7r7ejq2pquynl/pop_vs_p2p.xlsx?dl=0

A couple weeks ago I wrote a post comparing p2pool's payouts to those of BAN, clearly showing that p2pool has paid out an average of 112.63% of expectations over the lifetime of the BAN pool.  BAN pays 110% PPS, so p2pool has beaten it by 2.63%.  You can see my post here: https://bitcointalk.org/index.php?topic=875644.0.

After reading my thread, OgNasty asked if I would do a similar comparison between p2pool and his newly created NastyPoP pool.  For those of you who do not know what that is, let me briefly describe it.  OgNasty has been running his own p2pool node for a long time at nastyfans.org.  During the existence of his pool, he's offered some pretty interesting additions to standard mining, including the ability to purchase "seats", which effectively give the owner of a seat a membership to the nasty fan club.  The seats themselves are special 1 ounce silver coins that are actually pretty cool.  You can check them out here: https://nastyfans.org/mint.

As anyone who has been involved with p2pool is aware, one of the biggest problems with the pool is variance.  Specifically, as the pool grows, individual miners suffer greater and greater variance.  This is precisely the opposite of what happens in a more traditional pool like BTCGuild, where the larger the pool gets, the steadier the payouts become.

OgNasty and Nonnakip decided to do something about it and introduced NastyPoP.  Effectively, this is the first real attempt by anyone to try and tackle the p2pool variance problem.  Bitmain's p2p AntPool is also out there, but it seems to be stuck in limbo, so who knows.  So how does it work?  Well, with a regular p2pool node you connect your miner by providing a bitcoin wallet address as the username and anything as a password.  If and when your miner finds a share with a difficulty greater than the target share chain difficulty, your share gets added to the chain.  When the pool finds a block, you get paid for the shares you have in the current payout list of the chain.

NastyPoP is a bit different.  When you connect, you still provide your bitcoin wallet address, but you append -PoP to the end of it.  This signifies to the nasty pool that you are going to use their proprietary payout system.  Underneath the scenes, OgNasty and Nonnakip have created a sort of "pool on top of a pool".  Everybody who is connected using the -PoP suffix is in reality mining to the node's payout address.  You can try this on your own node.  Simply provide something that isn't a valid wallet address as the user name, and if you find a share, it is the node's default payout address that gets the credit for the share.

Well, here's where the custom code comes into play.  OgNasty and Nonnakip have devised a way to put a PPLNS payout system very similar to a traditional pool in place on top of p2pool's backbone.  They are tracking shares for your miner just like a traditional pool would.  Every miner who has the -PoP suffix shares in the block reward when p2pool finds a block, based upon how many valid shares that miner has contributed during the payout shifts.  I don't have the exact details on how long shifts are, or what the share clip length is, and as I wrote, the code is proprietary and not yet open-sourced.  Payouts from NastyPoP are on Fridays at 19:00 UTC.  They are sent just like any other transfer and require only 6 confirmations.  P2Pool payouts happen as soon as the block is found and require 101 confirmations.

How does this reduce your variance?  Simply put, your miner is paid out in small increments based upon your contributions, rather than being dependent on finding a share to add to the share chain.  That job is left to the node's payout address.  All in all it's quite a clever implementation of reducing p2pool's variance for smaller miners.

One thing that's very important to note here about NastyPoP: you can't take your work with you if you move to a traditional p2pool node.  No other node out there has any clue whatsoever of the work you've been doing on NastyPoP.  In this fashion, NastyPoP behaves much more like a centralized pool the likes of BTCGuild than a p2pool node.  I think it's great that OgNasty and Nonnakip have taken the initiative and are trying to help solve the variance problem.  Unfortunately, the solution they've come up with defeats the very nature of the decentralized p2pool.  Yes, it helps eliminate variance, but at the cost of forcing you to remain tied to the NastyPoP node.

That's all fine and dandy, but how does it compare?  To test this out, I pointed an Antminer S3 at the NastyPoP node, and another S3 at my own standard p2pool node.  Each S3 is configured to run at stock speeds (440GH/s), and I set a static pseudo share difficulty of 500 on both.  Both are powered by an EVGA 1300 G2 and hardwired into an always-on gigabit home network with more than enough up and down bandwidth.

Let's take a look at the ping times from my miner to the pool:

--- nastyfans.org ping statistics ---
57 packets transmitted, 57 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 115.153/144.510/277.534/45.255 ms

An average of 144.51 would stop me from pointing a miner there if it were a standard p2pool node.  Let's see where the server is.  Running a traceroute shows the last hop in Germany.  Well, that explains the ping time - I had to go to Europe .  Our friends on that side of the pond would probably be better served.

Another thing I noticed was a much higher reject rate from the NastyPoP pool than I do on my own nodes.  This could be due to the latency, but it turned into about 12-14% rejects, whereas I typically see less than 1% on my own nodes.

Alright, so how did the payouts work?  Here are the results:

11/28 - 12/5
NastyPoP - 0.03379787BTC
P2Pool - 0.03589959BTC
Expected - 0.0385BTC

12/5 - 12/12
NastyPoP - 0.03238691BTC
P2Pool - 0.03937531BTC
Expected - 0.0387BTC

12/12 - 12/19
NastyPoP - 0.03382075BTC
p2pool - 0.07363736BTC
Expected - 0.0389BTC

12/19 - 12/26
My p2pool node - 0.05615571BTC
NastyPoP - 0.05015601BTC
Expected - 0.0393BTC

12/26 - 1/2
My p2pool node - 0.03205607BTC
NastyP2P - 0.03861873BTC
NastyPoP - 0.02812263BTC
Expected - 0.0388BTC

1/2 - 1/9
My p2pool node - 0.024337627BTC
NastyP2P - 0.06870469BTC
NastyPoP - 0.04531921BTC
Expected - 0.0381BTC

1/9 - 1/16
My p2pool node - 0.00419189BTC
NastyP2P - 0.01805329BTC
NastyPoP - 0.02152612BTC
Expected - 0.0367BTC
P2Pool 7 day luck - 62.25%

1/16 - 1/23
My p2pool node - test discontinued due to hardware failure
NastyP2P - 0.03989456BTC
NastyPoP - 0.02833329BTC
Expected - 0.0352BTC

1/23 - 1/30
NastyPoP - 0.01963295BTC
NastyP2P - 0.02061486BTC
Expected - 0.0361BTC
Luck - 81.85%

1/30 - 2/6
NastyPoP - 0.05905592BTC
NastyP2P - 0.02003162BTC
Expected - 0.0375BTC
Luck - 93.32%

2/6 - 2/13
NastyPoP - 0.00435959BTC
NastyP2P - 0.00938869BTC
Expected - 0.0361BTC
Luck - 14.3%

2/13 - 2/20
NastyPoP - 0.00698833BTC
NastyP2P - 0.01822003BTC
Expected - 0.0348BTC
Luck - awful

2/20 - 2/27
NastyPoP - 0.03798674BTC
NastyP2P - 0.04202049BTC
Expected - 0.0338BTC
Luck - 100.64%

2/27 - 3/6
NastyPoP - 0.02048889BTC
NastyP2P - 0.00942830BTC
Expected - 0.0332BTC
Luck - 51.98%

3/6 - 3/13
NastyPoP - 0.05138458BTC
NastyP2P - 0.05908961BTC
Expected - 0.0328BTC
Luck - 131.5%

3/13 - 3/20
NastyPoP - 0.03402797BTC
NastyP2P - 0.05156673BTC
Expected - 0.0327BTC
Luck - 101.66%

3/20 - 3/27
NastyPoP - 0.02843568BTC
NastyP2P - 0.01970915BTC
Expected - 0.033BTC
Luck - 90.54%

3/27 - 4/3
NastyPoP - 0.03301631BTC
NastyP2P - 0.05550941BTC
Expected - 0.0332BTC
Luck - 97.55%

4/3 - 4/10
NastyPoP - 0.02866930BTC
NastyP2P - 0.03528256BTC
Expected - 0.0318BTC
Luck - 113.4%

4/10 - 4/17
NastyPoP - 0.00028594BTC
NastyP2P - 0BTC
Expected - 0.0313BTC
Luck - 0%

4/17 - 4/24
NastyPoP - 0.05554895BTC
NastyP2P - 0.05281205BTC
Expected - 0.0321BTC
Luck - 165.47%

4/24 - 5/1
NastyPoP - 0.02111442BTC
NastyP2P - 0.02415729BTC
Expected - 0.0325BTC
Luck - 59.99%

5/1 - 5/8
NastyPoP - 0.03294026BTC
NastyP2P - 0.05447989BTC
Expected - 0.0325BTC
Luck - 127.84%

5/8 - 5/15
NastyPoP - 0.03472755BTC
NastyP2P - 0.02216391BTC
Expected - 0.0325BTC
Luck - 84.97%

5/15 - 5/22
NastyPoP - 0.05258228BTC
NastyP2P - 0.03171723BTC
Expected - 0.032BTC
Luck - 182.64%

5/22 - 5/29
NastyPoP - 0.04249927BTC
NastyP2P - 0.03263267BTC
Expected - 0.0307BTC

5/29 - 6/5
NastyPoP - 0.03711295BTC
NastyP2P - 0.03414086BTC
Expected - 0.0312BTC

6/5 - 6/12
NastyPoP - 0.04351160BTC
NastyP2P - 0.04518917BTC
Expected - 0.03144BTC
Luck - 122.76%

6/12 - 6/19
NastyPoP - 0.01964088BTC
NastyP2P - 0.02788807BTC
Expected - 0.030107BTC
Luck - 65.12%

6/19 - 6/26
NastyPoP - 0.02159208BTC
NastyP2P - 0.0193531BTC
Expected - 0.030107BTC
Luck - 60.76%

6/26 - 7/3
NastyPoP - 0.02828584BTC
NastyP2P - 0.01623161BTC
Expected - 0.030263BTC
Luck - 81.3%

7/3 - 7/10
NastyPoP - 0.02039533BTC
NastyP2P - 0.02521461BTC
Expected - 0.030289BTC
Luck - 71.40%

7/10 - 7/17
NastyPoP - 0.02054230BTC
NastyP2P - 0.02884854BTC
Expected - 0.03493028BTC
Luck - 71.40%

7/17 - 7/24
NastyPoP - 0.04771791BTC
NastyP2P - 0.04040042BTC
Expected - 0.03465856BTC
Luck - 162.79%

7/24 - 7/31
NastyPoP: 0.04298881BTC
NastyP2P: 0.03145364BTC
Expected: 0.03401418BTC
Luck - 134.83%

7/31 - 8/7
NastyPoP: 0.01487946BTC
NastyP2P: 0.01145337BTC
Expected: 0.02962897BTC
Luck - 55.38%

8/7 - 8/14
NastyPoP: 0.03914884BTC
NastyP2P: 0.07990332BTC
Expected: 0.02941349BTC
Luck - 241.06%

8/14 - 8/21
NastyPoP: 0.03640067BTC
NastyP2P: 0.04331323BTC
Expected: 0.02939197BTC
Luck - 138.27%

8/21 - 8/28
NastyPoP: 0.01170063BTC
NastyP2P: 0.02753223BTC
Expected: 0.02857788BTC
Luck - 54.07%

8/28 - 9/4
NastyPoP: 0.0455039BTC
NastyP2P: 0.04888988BTC
Expected: 0.02846873BTC
Luck - 180.68%

9/4 - 9/11
NastyPoP: 0.01466154BTC
NastyP2P: 0.00815205BTC
Expected: 0.02719480BTC
Luck - 63.24%

Running totals
NastyPoP: 1.54926483BTC
NastyPoP from 12/26: 1.39910329BTC
NastyP2P: 1.48230244BTC (test started 12/26)
Expected earnings: 1.69383675BTC
Expected earnings from 12/26: 1.53839914BTC
My P2Pool Node: 0.265653547BTC - discontinued 1/16

NastyPoP vs Expected Earnings from 11/28: 91.46%
NastyPoP vs Expected Earnings from 12/26: 90.95%
NastyP2P vs Expected Earnings from 12/26: 96.35%
My P2Pool Node vs Expected Earnings from 11/28 - 1/16: 98.76% - discontinued

[Miners and dates, with hash rate and expected earnings]

As some of you know, I have been a staunch supporter of p2pool and have posted quite a few times regarding its advantages.  There used to be a great thread comparing p2pool to Eligius and BTCGuild.  Unfortunately, that thread has not been updated since August.  Recently, however, BAN has claimed they are the best paying pool, bar none.  Well, here's the proof that they are not.

Just for fun, I checked everything from the time BAN opened its doors (I used the announcement on BAN's website of 7/20/2014 as the start date) and compared that to my mining on p2pool for the same timeframe: 7/20/2014 until 11/26/2014.  I used http://retrocalc.net to figure out the expected earnings during this timeframe for my hash rate.  During this time, I have had S1s, SP10 and S3s mining.  I sold the S1s and the SP10 and the dates and data reflect them hashing until I unplugged them and shipped them out.  Here are the results:

Miners and dates, with hash rate and expected earnings
7/20 - 7/30, 2xS1 @ 400GH/s.  Expected: 0.1121BTC
7/20 - 11/26 1xS3 @ 440GH/s.  Expected: 1.0367BTC
7/20 - 11/26 1xS3 @ 420GH/s.  Expected: 0.9896BTC
7/20 - 8/1 1xSP10 @ 1.35TH/s.  Expected: 0.4509BTC
8/1 - 11/26 3xS3 @ 1.32TH/s.  Expected: 2.6692BTC
8/9 - 11/26 3xS3 @ 1.32TH/s.  Expected: 2.3875BTC

Expected total earnings from mining: 7.646BTC

Actual mined BTC: 8.61186032BTC

Difference: 0.96586032BTC

P2Pool has beaten expectations for the time period that BAN has been in existence by 12.6%.  In other words, p2pool has paid 112.63% of expected earnings.

Feel free to check the data.  Here are the addresses to which I've mined:
1DeVLDoGvkbbB5n3dPvbpDbwiKGjYckCy9
1H2uK38p6XEpiqPkECVNpC3CSTWxVwPGBS
1FEztNFHXvx7pCDSVy4xJ9JGxFGFSDKNXg
1BST6cuZ2ZhpsFaq3eY1xwFKzEDLfAWgqF
1DLcDRVncY7Zasd91oBw12XrQfLPohtNZP
1FWTtUBVk9XdkrfWkvS3uBN6CRkGgaMrQv

You can validate this against the blockchain, as well as see the payouts by going to http://minefast.coincadence.com/miner.php and plugging each of those addresses.

Therefore, in the BAN thread here: https://bitcointalk.org/index.php?topic=854368.0, the rankings should put p2pool as the number 1 paying pool.  By the way, I checked out the test as linked in that thread.  Nowhere does that test give actual proof of wallet addresses that can be verified as I have.  If I use the exact dates as that test, here are the numbers:

10/20 - 10/27 8xS3 @ 440GH/s. Expected: 0.3485BTC.  Actual: 0.60947698BTC.  Difference of 0.26097698BTC.

During the tested timeframe, p2pool beat expectations by 74.86%.  You're reading that right.  During the timeframe from 10/20 - 10/27, p2pool paid 174.86% of expected earnings, which absolutely destroys any other of the tested pools.  Once again, please feel free to validate my data.  I mined to 1DeVLDoGvkbbB5n3dPvbpDbwiKGjYckCy9, and the payouts can be easily verified.

So, in conclusion, p2pool has consistently beaten expectations and has beaten BAN's payouts, not only for the period they tested, but for the entirety of BAN's existence.

EDIT: semaster has updated his comparison thread of p2pool vs Eligius vs BTCGuild.  The thread is located here: https://bitcointalk.org/index.php?topic=416933.0.  According to his tests, p2pool is in the lead paying:

p2pool - BTC16.9718 VS btcguild (PPLNS) - BTC16.0933 VS Eligius BTC15.8041

Using his 6 S1s @ 1080GH/s total, expected earnings for that timeframe (2/1 - 10/30) are: 18.0886BTC.  So, none of his tested pools have met expectations.  However, p2Pool still wins here at 93.83% of expectations.

Hey everyone,

I'm just putting this out there to see if anyone might be interested in purchasing an unlocked 64G Space Gray iPhone 5s. It was on AT&T, but they have unlocked it, so you can put in whatever SIM you want. I upgraded to a Space Gray iPhone 6 Plus 128G and don't have much use for the 5s any longer.

The phone has been in an Apple case the entire time I've had it, and there isn't a scratch, ding, dent, scrape on it. It's on iOS 8.1 and ready to go.

These are selling on eBay for over $400, but I'm willing to cut the community a deal and sell it for 1.05 BTC (the 0.05 BTC would cover the shipping). I'm only going to sell to a US buyer because I don't want to deal with the hassle of customs and international shipping. I will only use a trusted escrow service, and the buyer will pay any associated fees.

I'm also posting this on hashtalk and if I don't get enough interest or serious offers, will also be throwing it up on eBay.

Hey Everyone,

This is more a question of curiosity on my part than anything else.  If this isn't the proper place for it, I apologize.

I see a bunch of threads in the group buys to the effect of "Selling X shares of Y hardware for Z price."

How does one accomplish this splitting?  I know, for example, that you can use quotas in cgminer, and can setup the config file like this:

Code:

"pools" : [
        {
                "url" : "poola:porta",
                "user" : "usernamea",
                "pass" : "passa"
        },
        {
                "quota" : "2;poolb:portb",
                "user" : "usernameb",
                "pass" : "passb"
        }
]

Assume, for example, I'd like to split an Antminer S2 into 10 shares of 100GH/s each.  The web UI only allows one to setup 3 pools; however, I'm sure I could hack the config files directly to do something like the above - or maybe not, I haven't tried this out.

Or, do people doing these kinds of selling simply just keep a record of who's signed up and have a script running daily that makes payments from a wallet to those who have signed up?  This approach would be more difficult/risky to implement I would think.  Possible, sure... since that's likely how the larger pools make payouts to miners.

Anyway, like I wrote, this is just out of curiosity to see how people manage this sort of thing.

Thanks for any input.

Hey everyone,

This topic is geared towards those of us who are mining in our homes, and how to distribute your mining gear within those confines.  What I'm really interested in finding out is how people who have multiple TH/s at home are doing it.  You so-called garage miners, hobbyists, etc, tell us how you've set things up!

Your standard residence has both 15 and 20 amp circuits.  Those 20 amp circuits are usually occupied by things like your electric range, washer/dryer, etc.  The 15 amp ones manage everything else - outlets, lights, etc.

Under continuous load a 15 amp circuit can provide 1440 watts.  Since you've got your miners running 24/7, that's what I'd count as continuos load .  We'll use the Antminer S1 as our hardware.  It's pretty cheap (about 0.5BTC) and at normal settings claims 360 watt power usage for 180GH/s, so it's a great candidate for the hobbyist.

I read accounts on these boards about folks with 6+ S1s running at their home.  At most you're driving 4 of them on a single circuit, which would max out that circuit's capacity for continuous load.  So, you'll need to consume about 1.5 circuits for your mining.  Do you all just shut those rooms down to anything other than mining?  Sorry kids, you can't have separate bedrooms any longer, daddy's gotta mine some BTC!

I'll share my setup, which is currently 2 S1s.  I have them over clocked and both are driven from a single Corsair HX1050.  Together they draw about 800-850 watts.  They are in the basement for a few reasons:

• It's cooler down there
• Not a lot of power used down there on a regular basis
• No more complaining from the significant other about "those damn mining things"

So, tell us your setups!  How'd you distribute your miners around the house?