Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 121. (Read 2591920 times)

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.

blockmaxsize=640000

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

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.

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.

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.

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.

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.

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.

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%.

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.

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...

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)

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

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.

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

Another EMPTY BLOCK 

Another BLOCK 

Two blocks in 24 hours - nice - & both with less than 1 Ph.....not bad at all.

The problem it's cgminer bitmain version, please read https://bitcointalksearch.org/topic/m.13056325


I believe can help. I would like to make another donation when we reach 2 Ph/s and if we advertise this might help.... do not you think?


For firmware: http://ck.kolivas.org/apps/cgminer/antminer/

For the problems of beginners, or for simplicity, you can use one public node  

I believe at this time that the only thing that could help most is this:

I am using the S7 and haven't had many issue with running it on p2pool.  All that was needed was to adjust the queue size.

If you want to hang around IRC there are a few of us there usually, we can work on fixing up some of the documentation around if possible.

Interesting. Perhaps with some kind of share reward? I don't think it would gain much traction but it could be fun enough.

I am just a newbie here, but there are many others like me.

I know it's easier said than done, but I would like to make a couple comments about my experience as a newbie on p2pool.

First of all p2pool was not all that easy for me to get going.  It took me a couple attempts and some help from this board.  We need a "official" set of instructions for setting up p2pool on Windows, Mac, and Linux.  I tried to follow what was out there and kept getting hung up when I tried to run "make" which turned out not to be necessary.  I still don't know what "make" is all about.

I sense that there are a lot of die hard old timers here who run older equipment mostly as a hobby.  That is all good, but I am a newer user with newer equipment and was disappointed to see that there are problems with my S5's and S7's.  I put a bunch of s5's on here only to see my hash rate decline to roughly half.  I am selling off my s5's for s7's and would not be excited about them running only half or three quarter potential speed.  My problem is that the firmware for the S5 took some asking around to find, and it still does not exist for the S7.  My question is how do we attract people to p2pool without making it SIMPLE for guys like me to jump in with our new equipment?

If we want p2pool to grow, we gotta make firmware for the S7, which is basically all the new hardware being sold these days, especially to individuals.

I understand the luck thing, but it is a big rat race out there and the prize goes to the pools with the best performance.  After going back and reading all the comments here over the past year or so, I think there is much room for improvements in p2pool itself.  I plan to spend the next few weeks learning what I can and looking into it.  I will have lots of questions, so please don't consider me to be a pain.

My next move will be to get a book on GIT and learn what that is all about.  I started programming long before GIT and the open source stuff came along.  This old dog needs to learn to git along with the young dogs.  I then plan to brush up on python and probably "c".  I want to get comfortable doing what Kano and the others do where they grab the main version of ckminer, tweek it to our needs, and then turn it into a modified firmware for an Antminer.  I usually learn just enough about these things to become dangerous, but it should not be necessary for a newbie to learn anything at all if p2pool is to grow.

Tom Travis