08:05:56 <br-m> <monerobull:matrix.org> do we have any network engineers in here?
08:07:22 <br-m> <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 
08:08:41 <br-m> <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  
08:27:15 <br-m> <hbs:matrix.org> @monerobull:matrix.org: Is it better via a VPN?
08:27:38 <br-m> <monerobull:matrix.org> Yes, i usually tell people to use ProtonVPNs free netherlands server
08:28:05 <br-m> <monerobull:matrix.org> A bunch of VPN providers + apple private relay also cause issues
09:06:23 <br-m> <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.
14:15:20 <DataHoarder> @monero I'll: does it happen only on plaintext servers or also ones with TLS?
16:56:04 <br-m> <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.
17:03:32 <br-m> <rucknium> Recently, my remote node crashed for the first time in months. May have been caused by high number of syncing wallets.
17:07:32 <br-m> <rucknium> Usually, sethforprivacy's node has 90% uptime. It is now at 50%: https://xmr.ditatompel.com/remote-nodes
17:09:53 <br-m> <rucknium> Low uptime doesn't necessarily mean it crashed. Probably just failure to connect because so many wallets are already connected, AFAIK.
17:18:58 <br-m> <ravfx:xmr.mx> There are some Tor anomalies too, at least in my rpc graph, since a little while
17:21:03 <br-m> <ravfx:xmr.mx> It always been "flatish" except during exceptions.
17:21:04 <br-m> <ravfx:xmr.mx> https://mrelay.p2pool.observer/m/xmr.mx/NVKruhFHvBNvVjFOiPqshVqE.png (clipboard.png)
17:21:35 <br-m> <ravfx:xmr.mx> Now... It look like that (both node, different graph but similar
17:21:36 <br-m> <ravfx:xmr.mx> https://mrelay.p2pool.observer/m/xmr.mx/oqzeAHRaRuYRujXbvRlQQFPU.png (clipboard.png)
17:22:27 <br-m> <ravfx:xmr.mx> (Other node)
17:22:28 <br-m> <ravfx:xmr.mx> https://mrelay.p2pool.observer/m/xmr.mx/OplvRglJbFnYVItUKuJFOdnF.png (clipboard.png)
17:24:11 <br-m> <ravfx:xmr.mx> Started to do that 11/03
21:06:26 <br-m> <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 https://github.com/monero-project/research-lab/issues/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)
21:06:51 <DataHoarder> I can. Any specific data needed ahead of time?
21:09:23 <br-m> <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.
21:14:51 <DataHoarder> I think we can gather some of the identified sweep transactions as usage for main/mini https://p2pool.observer/sweeps / https://mini.p2pool.observer/sweeps
21:15:32 <DataHoarder> and regular payouts vs consolidation cost
21:17:46 <DataHoarder> 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
21:17:57 <DataHoarder> I think sech1 maybe should be around as well for that topic then :)
21:20:08 <sech1> My latest sweep costed me 1.14% in fees: https://mini.p2pool.observer/sweeps?miner=86eQxzSW4AZfvsWRSop755WZUsog6L3x32NRZukeeShnS4mBGVpcqQhS6pCNxj44usPKNwesZ45ooHyjDku6nVZdT3Q9qrz
21:20:20 <sech1> This is the level most miners would like to stay at. Lower is better of course :)
21:22:47 <DataHoarder> the tx details https://mini.p2pool.observer/transaction-lookup?txid=19c560622366423a8e3473715b6a366da6b55c15f0f5e1259c02f0fc07c10651 https://p2pool.io/explorer/search?value=19c560622366423a8e3473715b6a366da6b55c15f0f5e1259c02f0fc07c10651
23:51:03 <DataHoarder> 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
23:51:28 <DataHoarder> Then plop in the numbers once we have proper FCMP++ fee numbers/weights
23:55:59 <DataHoarder> 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?