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

[notbatman]

Another BLOCK 

Another EMPTY BLOCK 

Yeah, I just noticed that - bummer. Still, at least we know that it wasn't done deliberately - unlike certain other pools I could mention......

Somebody made the point (GM I think) that even empty blocks help secure the blockchain. I don't see it as a big concern as they're missing out on BTC that some miner will pocket.

[1714912678]

1714912678

[1714912678]

1714912678

[1714912678]

1714912678

[1714912678]

1714912678

[windpath]

Another BLOCK 

Another EMPTY BLOCK 

Yeah, I just noticed that - bummer. Still, at least we know that it wasn't done deliberately - unlike certain other pools I could mention......

Well, it may have been deliberate, and actually looks like it was (10 minutes after previous block, plenty of time to refill mempool).... Also noticed it's a version 3 block....

https://chainquery.com/bitcoin-api/getblock/00000000000000000842de6ff4793f59ab08139a253f7e5622926f9d470c1ae9/true

The thing that some folks don't realize when mining on P2Pool is that we have VERY few orphaned blocks because the P2Pool network acts as it's own relay. Each P2Pool node that sees a block submission broadcasts it to other P2Pool nodes, which in tern broadcast it to the bitcoin network.

As a result block propagation for P2Pool is much faster then a regular pool.

The only real benefit is that GBT latency with an empty mempool is slightly improved.

Not worth it in my opinion...

Even with the load on my public server I still set a max block size of 750kb, has not slowed it down at all.

TLDR; if you found that block please include transactions in the future. Its good for the network, negligibly decreases your efficiency, and we all earn a little more

[lightfoot]

Well Gbt latency seems to be a problem on my node, even after bringing mintxfee to .000whatever2 it's still climbing and requiring a sw reset of bitcoind every day. At the moment it's at 4.72 seconds, with spikes to 15-20 seconds. At that rate I would fail everything with p2pool, correct?

(Mac mini server, 0.11.1 bitcoind, 8gb memory, SSD boot disk and bitcoin block disk)

[windpath]

Well Gbt latency seems to be a problem on my node, even after bringing mintxfee to .000whatever2 it's still climbing and requiring a sw reset of bitcoind every day. At the moment it's at 4.72 seconds, with spikes to 15-20 seconds. At that rate I would fail everything with p2pool, correct?

(Mac mini server, 0.11.1 bitcoind, 8gb memory, SSD boot disk and bitcoin block disk)

How many connections do you allow to bitcoind?

Had some issues with 0.11.1, running smooth since 0.11.2, might be worth the upgrade...

[btcdrak]

Just a heads up, BIP65 is currently deploying on the network. Miners needs to upgrade to Bitcoin Core 0.11.2 to support BIP65 CHECKLOCKTIMEVERIFY. Once enforcement comes, p2pool version 3 blocks will be rejected by the network so it would be advisable to upgrade asap.

Network stats: bitcoin.sipa.be/ver-2k.png
Last 1000 blocks: data.bitcoinity.org/bitcoin/block_version/5y?c=block_version&r=week&t=a

As far as I can tell al* major pools except one are already producing v4 blocks, leaving just 1 pool and p2pool.

[lightfoot]

How many connections do you allow to bitcoind?

Pretty much unlimited. Otherwise if p2pool crashes and restarts it can't get a connection. Besides, this is a nice thing to help the network overall.

Had some issues with 0.11.1, running smooth since 0.11.2, might be worth the upgrade...

Okies. I tried compiling from source but got a runtime error on launch. Will work on it. Interesting, I just checked the node (not mining) and I see:

Warning: LOST CONTACT WITH BITCOIND for 4.0 minutes! Check that it isn't frozen or dead!

Is some flunkie DOSing the nodes again? Hm. Actually python is running hot at 94% with bitcoind running at 15%.

[p3yot33at3r]

Is some flunkie DOSing the nodes again?

I'm not aware of any p2pool node ever being dos'd. There seems to be something wrong with your setup though - over 4 seconds is rather high - try limiting your connections to 12-14 instead - that should help.

[windpath]

Just a heads up, BIP65 is currently deploying on the network. Miners needs to upgrade to Bitcoin Core 0.11.2 to support BIP65 CHECKLOCKTIMEVERIFY. Once enforcement comes, p2pool version 3 blocks will be rejected by the network so it would be advisable to upgrade asap.

Network stats: bitcoin.sipa.be/ver-2k.png
Last 1000 blocks: data.bitcoinity.org/bitcoin/block_version/5y?c=block_version&r=week&t=a

As far as I can tell al* major pools except one are already producing v4 blocks, leaving just 1 pool and p2pool.

A.K.A. OP_HODL! Great BIP, looking forward to it's enforcement

Actually published a tutorial yesterday about monitoring its deployment

Monitoring soft fork enforcement using getblockchaininfo
https://chainquery.com/tutorials/monitoring-soft-fork-enforcement-using-getblockchaininfo

lightfoot: I limit my bitcoind to 15 connections on the pool node.

[lightfoot]

Is some flunkie DOSing the nodes again?

I'm not aware of any p2pool node ever being dos'd. There seems to be something wrong with your setup though - over 4 seconds is rather high - try limiting your connections to 12-14 instead - that should help.

Sorry, I was thinking bitcoind. I've noticed I have been drawing more stupid-fire ever since I brought up a full node, even more than when I started running a tor relay. Simple enough to deal with, still kind of lame.

I'll try limiting the connections some. The proper solution though is to probably fire up a ubuntu system on an old laptop and run a copy of bitcoind inside network peered to the outside one and others. That should bring it back to sub-second responses while allowing the externally facing one to serve as a full bitcoin node and a p2pool node that can supply blocks to others behind nats.

[kano]

Yeah there's an issue doing that as per design by current bitcoind

Bitcoin devs say your suggestion is how you should do it, but it's problematic:

Every node running bitcoind core of course fully verifies every block it receives.
However, there's no way to ask a node to pass it's block onto you before it has fully verified it.

e.g. check the hash, versions etc which takes only nanoseconds on a typical CPU, but not the transactions, before passing it on to another node that will also fully verify it before 'using' it.
The reason for this is of course to stop distribution of invalid blocks, but your setup is a perfect example where that simply slows it down for 'almost' every block ever found and thus you'd not want that in your configuration.

So the verification process is repeated every time in every node before it gets to you and you do it again yourself.
That verification is quite slow, but even if it was fast, it will still delay you passing your blocks around your collection of bitcoinds.

So if you have one outward facing node, talking to (all) your other internal, non-outward facing nodes, that doubles the relay (verification) time since it's done effectively twice before each internal node uses the block.

That's called trust, to allow early distribution, which is apparently, according to a bitcoin dev:
"trust settings are black magic that cannot be configured correctly even by experts"

So yeah consider that (double delay) issue of receiving EVERY block change, except blocks your node finds, in your configuration.

[windpath]

Upgrade Required: Bitcoin Core 0.11.2

Just a heads up that the last large pool started generating version 4 blocks today.

About 70% of the last 1,000 blocks were V4, at 75% transactions including CLTV will be allowed, at 95% version 4 blocks will be REQUIRED.

If you do not upgrade and find a block it will be rejected by the network.

[notbatman]

blockmaxsize=640000

"640K ought to be enough for anyone" -- Bill Gates

[-ck]

Just a heads up that the last large pool started generating version 4 blocks today.

If you're referring to antpool, they are still producing a mixture of v3 and v4 blocks so it's not quite there yet. That's no reason to stop everyone else from updating though.

[Carlton Banks]

blockmaxsize=640000

"640K ought to be enough for anyone" -- Bill Gates

BTClimit=21 000 000

"21 million coins ought to be enough for everyone"  Satoshi Nakamoto

Sensible limit is a sensible limit...




And remember kids, the blocksize limit is exactly that, a limit on the blocksize. Alot of people claim it is a transaction rate limit, 3 tps to be precise. But that's only when using the method of encoding the data that we use currently. Real scaling solutions will expand the use of 1MB until there are no ways left to cram extra tx info into that 1MB (indeed, several angles are already in contention). Then, the blocksize might need increasing. Until then, higher transaction throughput can be achieved a better way (a way that won't have all miners buying new disk drives every year).

[p3yot33at3r]

P2pool has been updated:

https://github.com/p2pool/p2pool

I see forrestv has created a new v15 tag in the repo too - maybe some more updates on the way?

Thanks forrestv  

Edit: Hmmm....since updating my system has locked up twice in 30 minutes. I'm not sure yet what the problem is until I get a chance to check the logs.......

[notbatman]

blockmaxsize=640000

"640K ought to be enough for anyone" -- Bill Gates

BTClimit=21 000 000

"21 million coins ought to be enough for everyone"  Satoshi Nakamoto

Sensible limit is a sensible limit...




And remember kids, the blocksize limit is exactly that, a limit on the blocksize. Alot of people claim it is a transaction rate limit, 3 tps to be precise. But that's only when using the method of encoding the data that we use currently. Real scaling solutions will expand the use of 1MB until there are no ways left to cram extra tx info into that 1MB (indeed, several angles are already in contention). Then, the blocksize might need increasing. Until then, higher transaction throughput can be achieved a better way (a way that won't have all miners buying new disk drives every year).

mintxfee=0.0005
minrelaytxfee=0.0005

"If you're good at something, never do it for free" -- Joker

[sawa]

P2pool has been updated:

https://github.com/p2pool/p2pool

I see forrestv has created a new v15 tag in the repo too - maybe some more updates on the way?

Thanks forrestv  

Edit: Hmmm....since updating my system has locked up twice in 30 minutes. I'm not sure yet what the problem is until I get a chance to check the logs.......

After the update, there is no visual changes. My node works without lockings.
This message appears periodically (but it was before updating):

Code:

Unhandled Error
Traceback (most recent call last):
  File "/usr/local/lib/pypy2.7/dist-packages/twisted/internet/defer.py", line 501, in _startRunCallbacks
    self._runCallbacks()
  File "/usr/local/lib/pypy2.7/dist-packages/twisted/internet/defer.py", line 588, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
  File "/opt/p2pool-btc/p2pool/util/deferral.py", line 256, in gotResult
    it(res2)
  File "/opt/p2pool-btc/p2pool/util/deferral.py", line 233, in it
    res = gen.send(cur) # external code is run here
--- <exception caught here> ---
  File "/opt/p2pool-btc/p2pool/util/deferral.py", line 284, in _worker
    self.func(*self.args, **self.kwargs)
  File "/opt/p2pool-btc/p2pool/util/expiring_dict.py", line 109, in <lambda>
    self._expire_loop = expire_loop = deferral.RobustLoopingCall(lambda: self_ref().expire())
exceptions.AttributeError: 'NoneType' object has no attribute 'expire'

[forrestv]

P2Pool release 15.0 - commit hash: 86bbdac7eaaa03438e71ee9dcb11898c7b2b8bdf

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary: http://u.forre.st/u/ovqxauzj/p2pool_win32_15.0.zip
Windows binary signature: http://u.forre.st/u/wynjbvpn/p2pool_win32_15.0.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/15.0
Source tarball: https://github.com/forrestv/p2pool/tarball/15.0

Changes:
* BIP65/block version 4 compatibility
* Requires Bitcoin >=0.11.2 (for BIP65 compatibility)

BIP65 will take effect in the next week and in order for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded before BIP65 takes effect, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

So, please upgrade to 15.0 now and also tell everyone else to.

[windpath]

P2Pool release 15.0 - commit hash: 86bbdac7eaaa03438e71ee9dcb11898c7b2b8bdf

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary: http://u.forre.st/u/ovqxauzj/p2pool_win32_15.0.zip
Windows binary signature: http://u.forre.st/u/wynjbvpn/p2pool_win32_15.0.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/15.0
Source tarball: https://github.com/forrestv/p2pool/tarball/15.0

Changes:
* BIP65/block version 4 compatibility
* Requires Bitcoin >=0.11.2 (for BIP65 compatibility)

BIP65 will take effect in the next week and in order for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded before BIP65 takes effect, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

So, please upgrade to 15.0 now and also tell everyone else to.

Thank you Forrest!

[sawa]

BIP65 will take effect in the next week and in order for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded before BIP65 takes effect, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

So, please upgrade to 15.0 now and also tell everyone else to.

I see - very few nodes been updated:
http://poolnode.info/
http://nodes.p2pool.co/
It would be better to change the values in https://github.com/p2pool/p2pool/blob/master/p2pool/networks/bitcoin.py#L15

Code:

IDENTIFIER = 'fc70035c7a81bc6f'.decode('hex')
PREFIX = '2472ef181efcd37b'.decode('hex')