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

If the BIP148-like part of SegWit2x activates Core will probably merge it (otherwise there would be risk that blocks produced by Core could become stale). The hard fork part isn't mandatory at all.

Edit: Does p2pool.org also signal in its coinbase string?

What is signaled is intent to signal intent to signal intent to enforce segwit. The hard fork part can't be enforced by miners.

Hey folks, just checking in with an update on my node. The absolute last thing I want to do is to inflame any debate further, but I also feel like I have an obligation to share what my node is doing...

So as of this morning the New York Agreement (NYA) A.K.A SegWit2x has reached almost 80% miner signaling of acceptance in just a couple days.

While it is certainly not my ideal outcome it appears to be time to accept compromise, and to that end http://p2pool.org is now signaling for the NYA while still running Core 0.14.1.


Once there is a full release of https://github.com/btc1/bitcoin, assuming continued support and p2pool compatibility, we will upgrade

Talk about interesting timing: segwit2x now has over 80% of the global hashrate. Any thoughts on how an eventual 2MB block increase will effect this P2Pool fork?

Is there still an incentive @jtoomin to run your fork if the new block size is 2 MB?

Indeed, the solution is to reserve the blockchain mostly for higher value transaction which can afford higher fees and move low value transactions which don't require the security of the blockchain to off-chain systems, preferably decentralized ones like LN.

Been there, done that.

I think the proper response to our little flamewar is to bring popcorn.

veqtrus makes some good technical comments and observations at times, and I value his contributions. However, when he trolls me on how my fork is gonna doom p2pool to a centralized future, I think the proper response is to troll him back, laugh it off, and move on.

I'm not very good at trolling, though. Maybe I should ask Kano for a lesson.

That is a red herring of an argument at best. For those who believe Satoshi is a god as you so finely put it, you missed the clear and obvious argument that it was Satoshi that introduced the 1mb block size limit. However, "who" introduced the change has nothing to do with my argument. The fact is that it is an arbitrary limitation that only constrains things and does not really solve the flooding problem. It only limits it.

I would say that the part of the commissions is the most difficult to obtain 

Just some humor for perspective...  
Digital consensus is the easy part, the human part is far more difficult to obtain.  We are all P2Poolers, and discourse to improve the software is going well.  Perhaps we should use more formal improvement channels, such as GitHub?  Just a thought. 

I think I know exactly what would make everyone in this discussion feel better - Both P2pool chains hit a block!

New shares are already as big as they're going to get in the absence of explicitly malicious behavior or Bitcoin blocksize increases.

Do you mean in the sense that nobody has attacked the p2pool network with large, difficult-to-propagate shares, as an adjunct to doing a selfish mining attack, because somehow that's easier than just renting a bunch of hashrate on Nicehash and 51% attacking p2pool?

Or intentionally creating large shares with the intent of forcing low-bandwidth miners off of p2pool and onto other pools because somehow there's an incentive for someone to want to do that?

Keep in mind that with a 1 MB block size limit, the only way to have shares that require 1 MB of network traffic is to create block templates that use transactions that nobody has heard of before (i.e. transactions you created yourself). This also requires hacking p2pool so that it does not notify peers of transactions when they're first seen (i.e. disabling the have_tx p2p message). Normally, shares require only 2 to 32 bytes per transaction when transmitted regardless of the transaction size, but the 50 kB/1 MB limits apply to the total summed size of the transactions (e.g. 500 bytes).

Even to the extent these attacks are possible, they wouldn't be very effective. If you want to DoS someone, there are much easier ways than mining big shares.

Satoshi also:

• Introduced numerous bugs like the output coin amount overflow
• Introduced soft forks in backdoor like manner like the sigop limit
• His whitepaper contradicts itself
• Isn't a god

Satoshi never imposed a block size limit in the beginning. There was something like a 32mb network message limit, but that is it. What is your point?

That's because new shares aren't 1MB yet as your fork allows. Then again you advocate making Bitcoin's block size limit infinite...

Maybe because my fork has lower CPU usage, lower memory usage, lower orphan rates, better fairness, and substantially higher revenue from tx fees? And maybe because your premise of that causing centralization is, I dunno, wrong?

Anything
As long as this brings more blocks  
Blocks where are you ?

We can't force miners to care about decentralization. If they want centralized pools they can use them but that doesn't mean p2pool has to change.

More lucrative for the miners who come here to complain, you wanted to say !?!

Why would forrestv want people to use a p2pool fork which would only make it more centralized?

Looks like another nicehash miner with high DOA rates, but on mainnet this time. It's interesting to see how they drive the orphan rates down even as they drive the DOA rates up.