<monerobull:matrix.org> do we have any network engineers in here?

<monerobull:matrix.org> I've noticed that many UK users have issues syncing their wallets and it looks like its not isolated to just one ISP

<monerobull:matrix.org> I dont have the skills to do proper research on this but maybe someone in here does and wants to look into if they are blocking or interfering with monero nodes deliberately

<hbs:matrix.org> @monerobull:matrix.org: Is it better via a VPN?

<monerobull:matrix.org> Yes, i usually tell people to use ProtonVPNs free netherlands server

<monerobull:matrix.org> A bunch of VPN providers + apple private relay also cause issues

<hooftly:matrix.org> you could try binding RPC to a port other than 38081. If they are blocking/shaping traffic based on the standard port this would tell you.

@monero I'll: does it happen only on plaintext servers or also ones with TLS?

<rucknium> @monerobull:matrix.org: Are you sure it's not just a coincidence that they are in the UK? Monero exchange rate volatility usually increases load on remote nodes because users are syncing older wallets.

<rucknium> Recently, my remote node crashed for the first time in months. May have been caused by high number of syncing wallets.

<rucknium> Usually, sethforprivacy's node has 90% uptime. It is now at 50%: xmr.ditatompel.com/remote-nodes

<rucknium> Low uptime doesn't necessarily mean it crashed. Probably just failure to connect because so many wallets are already connected, AFAIK.

<ravfx:xmr.mx> There are some Tor anomalies too, at least in my rpc graph, since a little while

<ravfx:xmr.mx> It always been "flatish" except during exceptions.

<ravfx:xmr.mx> mrelay.p2pool.observer/m/xmr.mx/NVKruhFHvBNvVjFOiPqshVqE.png (clipboard.png)

<ravfx:xmr.mx> Now... It look like that (both node, different graph but similar

<ravfx:xmr.mx> mrelay.p2pool.observer/m/xmr.mx/oqzeAHRaRuYRujXbvRlQQFPU.png (clipboard.png)

<ravfx:xmr.mx> (Other node)

<ravfx:xmr.mx> mrelay.p2pool.observer/m/xmr.mx/OplvRglJbFnYVItUKuJFOdnF.png (clipboard.png)

<ravfx:xmr.mx> Started to do that 11/03

<rucknium> DataHoarder: I can put Coinbase Consolidation Tx Type on tomorrow's agenda. Will you be available to discuss? > <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)

I can. Any specific data needed ahead of time?

<rucknium> Thanks. Maybe consolidation costs for p2pool coinbases, as a percentage of the miners' reward. Assume for now same cost per byte with FCMP, but the larger tx byte sizes.

I think we can gather some of the identified sweep transactions as usage for main/mini p2pool.observer/sweeps / mini.p2pool.observer/sweeps

and regular payouts vs consolidation cost

and different cost on main as that's the most efficient/dense payouts at the moment due to high hashrate (enabling dynamic PPLNS), vs main that might be hit harder

I think sech1 maybe should be around as well for that topic then :)

My latest sweep costed me 1.14% in fees: mini.p2pool.observer/sweeps?miner=8…xj44usPKNwesZ45ooHyjDku6nVZdT3Q9qrz

This is the level most miners would like to stay at. Lower is better of course :)

the tx details mini.p2pool.observer/transaction-lo…66da6b55c15f0f5e1259c02f0fc07c10651 p2pool.io/explorer/search?value=19c…66da6b55c15f0f5e1259c02f0fc07c10651

Have we gotten final values for fees for given byte size for FCMP++? Otherwise I'll assume ~4x byte size and just list that, no "new fee" just old one

Then plop in the numbers once we have proper FCMP++ fee numbers/weights

AFAIK consensus is weight = byte size but what formula does weight have to get to fee levels I don't think it's agreed upon?