Should Coinbase Consolidation Tx Type monero-project/research-lab #108 get discussed before next stressnet/testnet? See what to do there, as these would make P2Pool non-competitive at all even on main (which reduces output count)

alternatively, allow making zero-fee txs for specifically coinbase sweeps, and allow unrestricted RPC to optionally allow these txs to be imported (via a new arg there) for miners to include them on their own templates without custom patches

that'd allow out of band handling of these txs "The other argument, efficiency, should be solved on P2Pool's (or another such protocol's) end.", for example including them in somewhat empty blocks by willing miners

I mean this on wallet, not protocol, allow the option to export them (not new rule to accept them) > allow making zero-fee txs for specifically coinbase sweeps

<monero.arbo:matrix.org> a change that is as overdue as it is obvious > <DataHoarder> Should Coinbase Consolidation Tx Type monero-project/research-lab #108 get discussed before next stressnet/testnet? See what to do there, as these would make P2Pool non-competitive at all even on main (which reduces output count)

FCMP++ is making 109 irrelevant monero-project/research-lab #109 (even in the case 108 directly signs outputs)

<monero.arbo:matrix.org> yikes, p2pool reached 20% of all recent outputs and we left it like that for over 2 years

it was mitigated on main

still quite a high number

but once it reaches high hashrate for a given pool, dynamic PPLNS window engages and reduces how many miner outputs it generates

@monero.arbo:matrix.org and most sweeps are trivially identifiable p2pool.observer/sweeps

FCMP++ will at least make this a non-issue for anyone else

in some cases the simple heuristic it's able to track even further spends without any coinbase inputs p2pool.observer/transaction-lookup?…ab5dbe570232bb166474ddb85a7aac2092c (by tagging previous sweeps)

<monero.arbo:matrix.org> damn