Quote from: jtoomim on February 20, 2016, 08:17:42 PM

Quote from: -ck on February 20, 2016, 01:07:24 AM

Hmm... not much good using a fork designed to increase the max blocksize limit if you can't... increase the max blocksize.

It's a p2pool bug, not a Classic bug.

Quote from: p3yot33at3r on February 20, 2016, 11:15:43 AM

I see the issue was brought to forrestv's attention over 5 months ago on github - it would be nice if he followed it up or privided some additional info/update.....

Fixing this issue will likely require a hard fork of the p2pool share chain. (You would have to increase the max_remembered_txs_size value, which may result in your node creating shares that other nodes would not be able to accept or validate. I could be wrong though. This would be a good research project for someone who has time to read the code.)

The posts below from earlier in this thread below may be related to the issue...

Quote from: K1773R on July 27, 2015, 07:33:24 AM

Quote from: forrestv on July 26, 2015, 04:25:18 AM

Quote from: K1773R on July 23, 2015, 04:25:57 PM

Quote from: CartmanSPC on July 23, 2015, 06:55:30 AM

Was reviewing the code and came across this one part:

https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L152

Question: Why limit it to "50 kB of new txns/share"?

i even contacted you about that bug months ago Wink

was asking forrestv about it, but he didnt respond. created a hackish fix in my repo.

It's limited to prevent DoS attacks on P2Pool by e.g. making a bunch of fake transactions and then forcing them to be relayed across the entire P2Pool network. With this limit, an attacker can only force every other P2Pool node to download, at most, 50kB per share the attacker mines.

Given that 100kB transactions are possible, it should probably be 100kB, not 50kB, but it doesn't have much of an effect otherwise, since 50kB/share is comparable to the maximum transaction throughput allowed by Bitcoin (500kB/block).

K1773R, your "hackish fix" will result in your shares being orphaned if it ever results in differing behavior. The contents of the generate_transaction function are used to determine consensus, so if your version acts different, other nodes will see your shares as invalid.

Good that we talk about it now. When i was still mining BTC with p2pool, i wondered why not all of my (sometimes bigger than 100kB) would be included in p2pool blocks. It didnt really bother me back then, as some other pool would mine them.
I think raising it (not as high as my hackish fix) would be a good addition to a future hardfork.

Im absolutely aware that i would get my shares rejected. I wasnt using it for BTC.
I wanted to mine the huge ANC stuck txs, so i had to create my own p2pool and set the limit higher.