Block! Mainnet's first in 19 days!

---

The P2Pool branches that you tried to use are currently not compatible with Litecoin's segwit. You will not be able to mine using those P2Pool branches.

There is, however, a fork of P2Pool that is compatible with Litecoin's segwit. You can find it here: https://github.com/ilsawa/p2pool-ltc

If P2Pool were to include block propagation, would blocks received from other P2Pool nodes then be subsequently forwarded to and verified by the recipient's bitcoind before being mined on, or would the recipient P2Pool node simply assume that the received block is valid?

There is a way for your Bitcoin full node to get blocks faster: connect it to one of the Bitcoin FIBRE nodes.

Also, Bitcoin Core 0.14.0 and later has some under-the-hood performance improvements that helps to speed up block propagation and validation. If you don't want the segwit part of 0.14.0 and later but want the faster P2P block propagation and validation that 0.14.0+ offers, you can stick a non-segwit version of Bitcoin Core (e.g., 0.13.0) in between your P2Pool node and 0.14.0+ as a filter. This might introduce a bit of additional latency, however, depending on how much juice your underlying hardware has.


I disagree. P2Pool should provide any and every node with a level playing field. That's one of the points of having a decentralized pool. Having certain nodes that outperform others introduces an undesirable layer of centralization, in terms of orphan rates, etc. So yes, it is worth the time and effort to fix this issue. We should want as many miners as possible to mine at a decentralized pool.

That said, I do agree with you on the point that the empty block problem should be solved first. Demand for block space is already far outstripping supply, and P2Pool should not be a bottleneck in that regard. A decentralized pool should also be helping the network confirm as many transactions as possible. Nevertheless, I do understand that this is a tricky problem to solve; decentralization does seem to throw a spanner in the works here. But until a viable solution is found — I'm optimistic that we will find one soon — I am inclined to agree with jtoomim that mining on an empty block at the right height is a more appropriate compromise than mining on a full block at the wrong height or not mining at all.

With 110 MB of transactions waiting in the Bitcoin mempool during that time. jtoomimnet should've been able to fill its transaction cache back up to capacity with the share that found block 468173, but apparently did not.

Empty block by jtoomimnet.

This P2Pool guide should be able to help. It's a lot more beginner-friendly than the Bitcoin wiki's article.
And here is an up-to-date list of public P2Pool nodes that you can connect your miners to, if you decide to not run your own P2Pool node.


Yes, in a sense. There are multiple P2Pool nodes, and all of them make up the P2Pool network. It is very similar to how the Bitcoin network works, where multiple Bitcoin full nodes make up the Bitcoin network.


P2Pool is a decentralized pool, similar to how Bitcoin is a decentralized network. There is therefore no main or central server, nor nodes that make up a main or central server. There is only the network of P2Pool nodes.

In other words, try to look at it according to what in2tactics said: each P2Pool node is its own pool. The P2Pool network connects these nodes together through the P2Pool sharechain, similar to how the Bitcoin network connects every Bitcoin full node together through the Bitcoin blockchain. P2Pool can therefore also be described as a collection of solo miners that pool block payouts and distribute them accordingly, since each P2Pool node is essentially doing its own thing. Contrast this to a traditional pool, where the central pool server dictates what its miners do.

More accurately, a P2Pool miner will be paid according to the total worth of the accepted shares he or she has in the P2Pool sharechain when a block is found. For example, if Alice found one share that is of the same difficulty level as Bob's ten shares combined, their payouts according to their respective shares would be the same. P2Pool's payouts are weighted according to share difficulty, not share quantity.


That is incorrect. A P2Pool miner is paid according to the total worth of his or her shares remaining in the sharechain when a block is found. The sharechain contains approximately three days' worth of shares. So, for example, even if Alice were to stop mining on P2Pool two days before P2Pool finds a block, Alice still has approximately one day's worth of accepted shares that she will get paid for when the block is found.

Hello, keke51. You need to connect your node to one of the jtoomimnet nodes, using the "-n [url:port]" command-line option. jtoomimnet's sharechain is incompatible with mainnet's sharechain, which is why you're getting the "Unknown share type 16" error. jtoomimnet's protocol version number is 32; mainnet's is 16.

For example, here are instructions for connecting your node to jtoomim's node, among others:


You are also encouraged to publicly share your node details here, once you've set up your node. It would go a long way in helping jtoomim with the further testing of his fork.

Point taken, jtoomim. I too apologize if I offended you in any way; my intention was simply to get the point across that there is almost always never an optimal solution, but there is almost always a better one. In the case of P2Pool, and Bitcoin in general, my personal belief is that compromise is almost always the better solution, compared to hard-forking.

But nevertheless, you do make very good, and reasonable, points. And I'll respect that, even if I do not agree with all of them. . (Also, I'm not a programmer, so I may have skimmed over much of the finer workings of your code, simply because I do not understand code. I do apologize if I made unfair and unfounded generalizations.)


Yeah, the P2Pool page on the Bitcoin wiki does say that "Each share contains a generation transaction that pays to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640 (= [72] hours of shares), whichever is smaller."

I'm still confused as to what the first part means.

(By the way, the P2Pool Bitcoin wiki page needs to be updated. It still says that shares are valid to at most 24 hours, among other outdated information.)

Is there a simpler way of voting? I'm not a programmer — I assume that not every P2Pool node operator is a programmer too — and the only things I know how to do on GitHub are cloning the main repository and downloading releases. I also have no idea how to add text in my coinbase, let alone install a pull request (I hope that's the correct phrase for it). I would prefer to avoid tinkering in the bowels of my P2Pool node and/or Bitcoin node, for fear of messing up things that shouldn't be messed with.

That said, and for what it's worth here, I vote for the 250 kB share size limit.

Could you kindly point me to some reliable resources that show P2Pool's share lifespan being reduced from approximately three days to one day? P2Pool.org currently says that "a share in the P2Pool sharechain can be expected to last about 3 days (8,640 shares * 30 seconds = 3 days)" under "How do I get paid?".

Also, having a large miner raise his or her share difficulty to 30x the current minimum doesn't flood the sharechain with tiny shares. It does the opposite; the miner would be submitting fewer, but higher-difficulty and therefore higher-value, shares to the sharechain. Furthermore, large miners are encouraged to send higher-difficulty shares so that smaller miners would still stand a fair chance at having accepted shares — this method helps mitigate the impact of large miners on P2Pool's minimum difficulty, enabling smaller miners to still have a fair chance of submitting accepted shares.

You do get paid for every accepted share in the sharechain, according to the difficulty of those shares. Higher difficulty shares are worth more, and therefore pay out more. And you can't "flood the system" with shares; the sharechain is only as long as the last n shares, with the n being approximately 8,640 (unless this information is outdated). Anything more, and older, than that is disregarded and discarded.

Actually, they do. Or at least, I've been under the impression that they do.

The specified difficulty value after the "/" tells the miner to send only shares above the specified "/" value to the sharechain. If the specified difficulty value after the "/" is lower than the current P2Pool minimum difficulty, then the "/" value is ignored. So, if a miner desires to have only high-difficulty shares in the sharechain, he or she may do so using the "/" function.

The specified difficulty value after the "+" tells P2Pool to send only work of the specified "+" difficulty value to the miner, i.e., the pseudo-shares.


I'm getting a little confused here. Do correct me if I'm wrong. From what I am able to understand from your suggestion, you are suggesting that a share's lifetime be limited to the current round of mining, i.e., the sharechain is reset after P2Pool finds a block?

If that's the case, then the payout system would be more along the lines of the "Proportional" payout system rather than P2Pool's current PPLNS system. If what you are suggesting is a "Proportional"-like system, then I think it would be unfair to long-term miners, since the "Proportional" payout system is susceptible to pool-hopping.

Then again, I'm probably misunderstanding the whole discussion. Some clarification would therefore be nice, and much appreciated.

I concur with in2tactics on this one.


Shares do pay out. If they didn't, we wouldn't be here. The difference between (short-term) rented hashpower and non-rented hashpower on P2Pool is that the renter is essentially gambling that P2Pool finds a block while his shares remain in the sharechain (about 3 days). Their payouts therefore rely heavily on chance. Just because someone uses 2PH/s for 24 hours on P2Pool and doesn't get a payout, doesn't mean that P2Pool "sucks." All it means is that his or her gamble didn't pay off.

Also, if you're unsatisfied with P2Pool's default share difficulty, you can always set your own by appending "+", followed by your preferred difficulty level, to the end of your P2Pool mining address. And if you prefer to only have "difficult-to-find" shares on P2Pool's sharechain, simply append "/", followed by your preferred difficulty level, to the end of your P2Pool mining address.

I agree. I support this proposal.

It makes full sense to fix the bugs in the current system, e.g., transaction malleability, and optimize block space usage — which SegWit does — before making changes to block size limits. To do it in reverse, i.e., increasing the block size before fixing bugs and optimizing block space usage, would essentially mean:

• bugs in the current system would amplified in presence and in impact, and
• the ratio of wasted block space to useful block space would be preserved, therefore increasing the amount of resources wasted in propagating and storing these larger, but more wasteful, blocks. In contrast, optimizing block space usage before increasing block size would reduce wasted block space in proportion to useful block space, therefore reducing the amount of resources wasted in propagating and storing these blocks, since there would be less wasteful space to store and propagate.

Furthermore, adapting the block size according to a pre-defined interval's supply and demand is, in my opinion, a much safer method than what is proposed by Emergent Consensus. Emergent Consensus has the potential to unleash chaos on the Bitcoin network in that different pockets of the network may end up mining different blockchains because these different pockets came to different consensus regarding the appropriate block size to use, all before the Bitcoin network as a whole managed to wrangle itself into a universally-accepted block size. Frequent hard forks and chain reorganizations may become the new norm in such a scenario, undermining the integrity of the Bitcoin blockchain.

Thanks for sharing that; I do find it interesting. And disappointing (in regards to its discussion); Bitcoin's current community just can't help turning a perfectly viable and reasonable proposal into yet another political slugfest.

Still, I remain hopeful that one day, reason will prevail and the community manages to find common ground and move on to better and greater things for Bitcoin. This "debate" has become too much of a colossal waste of time, energy, and resources.

But yeah, we are taking this thread a little off the rails from its original topic.


Me too. It'd be interesting to see how Unlimited would manage to wrangle different pockets of the network into agreeing on a universally-accepted block size and mitigate, if not eliminate, the significant risk of frequent hard forks and chain reorganizations posed by Emergent Consensus. If Unlimited manages to develop and deploy a viable solution, I believe the blockchain ecosystem as a whole would greatly benefit from this.


I concur.

Me too. I'm also for flexible block sizes that scale accordingly to meet the demands of the network, but within reason, within reasonable technical limits, and based on a reference framework so that there would be less chaos in the network as a whole coming to a consensus on which block size to use. I'd propose adjusting the block size along similar mechanisms as currently employed by the network in adjusting the network difficulty — i.e., adjust the block size once every two weeks based on the demand from the last two weeks. I believe this to be a far safer solution that what Emergent Consensus proposes; Emergent Consensus has the potential to unleash chaos in that different pockets of the network may end up mining different chains because these different pockets came to different consensus regarding block sizes, all before the network as a whole managed to catch up and settle on a universally-accepted block size. Hard forks and chain reorganizations may run rampant in such a case.

Furthermore, I believe that changes to the block size should come after fixing the many bugs and issues found in the current system, especially that of transaction malleability and the network's current inefficient use of block space. Increasing the block size without fixing these bugs and without optimizing block space usage essentially means amplifying the presence and effects of those bugs, and increasing wasted block space in proportion to useful block space. (In contrast, efficiency improvements to block space usage reduces wasted block space in proportion to useful block space). The net total would essentially be a buggier but bigger block, and a bigger but more wasteful (in terms of storage space) block.

TL;DR: Fix bugs and optimize block space usage before making changes to block size limits.


Yup, classic game theory at work here.


Yeah, I haven't yet found any evidence to suggest that he's a large miner or a pool operator or both. Still, anything's possible. He seems to be a developer though, and may have contributed a fair bit to the development of Bitcoin. Nevertheless, even though I am for SegWit and would like to see it activated as soon as possible, I would not support his proposal. It does way more harm than good to the network, and I fully agree with what achow101 said in response to Carlton Banks' proposal:



You're right, FIBRE would pretty much render Banks' proposal useless, since the mining pools are essentially in a virtual private network of their own. And yes, if the pools decide to go Banks' route, then FIBRE would essentially become a mirror of what would happen on the main P2P network if his proposal goes mainstream.


Yup, and it would be a massive problem, since that is essentially an actual hard fork. The two different factions would be mining their respective versions of the blockchain and broadcasting it to the network. SegWit nodes reject the Unlimited blockchain, and Unlimited nodes reject the SegWit blockchain. A hard fork would have occurred at that point.


I ask myself that too. And the more I immerse myself in the Bitcoin community, the clearer and uglier it becomes to me: pride. The two factions have become so resolutely stubborn in their respective beliefs, that they have blinded themselves to the merits in each other's proposals (no matter how beneficial to the network), and more devastatingly, to the damage that they themselves are inflicting on the Bitcoin ecosystem — they refuse to take any responsibility for their own actions, and instead prefer to blame the other party for any damage that is inflicted on the Bitcoin ecosystem as a result of their actions. They have essentially, in my opinion, reduced themselves to comparing whose dicks are bigger (there are no women in the leading development teams). They are making pathetic fools out of themselves in front of the entire world, and the response has been damning, to say the least.


Likewise, d5000.

Cheap (adjective):
depreciated in value (as by currency inflation)

Current bitcoin price in USD, at time of posting: $1,403.78

Nope, still doesn't look cheap to me.

Yup, that's one way to put it.


True, but only if the rule change is a hard fork — i.e., the original blockchain permanently splits into two. And only if the hard fork does not have the backing of the economic majority — i.e., the new blockchain would have little, if any, economic value. So yes, miners would therefore be incentivized to mine the blockchain backed by greater economic value (in this case, the original blockchain), since it would yield more significant revenue for them. And yes, for the new blockchain (the one without the backing of the economic majority) to survive, miners seeking to preserve it and subsequently orphan the original blockchain would need both "destructive intentions" and really deep pockets; they would need to generate an extraordinary amount of hashing power not just to mount a 50%+1 attack, but to preserve that 50%+1 advantage against miners who would be incentivized into mining the original blockchain.


You are correct. Unless the soft fork — whether user-activated or otherwise — is backed by the majority of hashing power, it would most likely end up being the shortest chain and eventually get orphaned by the network. Since both upgraded nodes and non-upgraded nodes see both soft-fork blocks and non-soft-fork blocks as valid — i.e., non-upgraded nodes will accept as valid all the same blocks as upgraded nodes do — both upgraded nodes and non-upgraded nodes will accept the chain with the most proof-of-work as the best valid blockchain. The soft-fork version of the blockchain would therefore be competing for acceptance by the network with the non-soft-fork version of the blockchain. Since, in this scenario, 70% — and therefore the majority — of hashing power is mining non-soft-fork blocks, the non-soft-fork version of the blockchain wins.

However, in this scenario, since the UASF was backed by 70% of the economy, the 30% of miners who stuck with the UASF version of the blockchain would arguably be incentivized to continue mining this chain, since robust economic backing means significant revenue for them. This "orphaned" blockchain would therefore still be alive and active. In this case, a hard fork has occurred — i.e., two separate active blockchains have permanently diverged from the original chain.


I'm currently unaware of such a proposal to essentially sabotage the efforts of non-SegWit miners. In any case, I wouldn't call it an "incentive" to get those miners to signal for SegWit; I would call it coercion. Such efforts are to be condemned, pro-SegWit and non-SegWit alike.

As far as I understand it, FIBRE is merely a backhaul between mining pools. It is up to the mining pools to propagate the blocks as they see fit; the FIBRE network itself does not force the pools to propagate every block at every opportunity as quickly as possible. FIBRE's utility and value depend on mining pools being incentivized to propagate newfound blocks as quickly as possible so that they can mine on top of them as soon as possible.

Therefore, FIBRE in and of itself does not prevent malicious miners from withholding newfound blocks from pools, or delaying propagation of blocks from pools, that do not support their (malicious miners) views.

Nevertheless, I do not foresee such a proposal going very far. If a pool — no matter how big it is — decides to coerce other pools into playing by its own rules, the other pools would most likely blacklist the malicious pool on both the FIBRE network and the main Bitcoin P2P network. The malicious pool would therefore end up shooting itself in both feet; it now would be unable to utilize the FIBRE network to obtain new blocks as quickly as possible, and it would also find itself with a more limited set of mainnet nodes to obtain blocks from. Not to mention the backlash it would receive from the mining community at large; I foresee a not-insignificant number of miners leaving the pool in protest, further crippling its mining operations.

$1,316.81 (at time of posting) doesn't seem cheap to me.

Hmm, I was under the impression that it was the other way around, i.e.:
- adding a "/" followed by the desired difficulty level to the end of the Bitcoin address would tell the miner to submit only shares above the stated "/" difficulty level, and
- adding a "+" to the end of the Bitcoin address tells the P2Pool node to always give the miner work with the stated "+" difficulty level.