after switching from i2p-zero to i2pd i have way more i2p peers, i can recommend it for everyone that still uses i2p-zero

i2pd works so much better than that java i2p crap

can second (third) that, i2pd is solid

also the new i2p patch that removes the port numbers makes me unreasonably happy

my peer list looks so good. also got a ton of i2p peers. lookin great

I remember when using i2p was absolute trash, is come so far

<b​lurt4949:matrix.org> requesting review of monero-project/monero #9180

i2pd definitely better than the alts

<x​fedex:matrix.org> Hello. Is there any plan on increasing the transaction fee or doing something else to counter the spam? I understand that it doesn't affect the normal operations of the network. However, the attackers are spending as little as ~ 20 XMR ($2800) a day. In the long term this WILL affect users. Syncing time will be a lot bigger, running a node will be more expensive and wallets will t<clipped message>

<x​fedex:matrix.org> ake much longer to scan blockchain. This is also a threat to decentralization - if running a node becomes too much expensive, then more and more miners will rely on third party nodes for mining Monero, or switch to centralized mining pools.

<x​fedex:matrix.org> Yesterday's average block size is ~330 KB. One week ago, it was ~120KB. 330 KB a block is about 237 MB a day, or ~87 GB a year. Blockchain size is currently 131GB. It means that if this spam continues, then it will generate 87% of the all-time blockchain size in one year. +40% blockchain size increase in one year.

<m​ainnet_pat:monero.social> what is the meaning of `reserve_size` in `get_block_template` and `generateblocks`?

<x​fedex:matrix.org> moneroj.net/transcost is an interesting chart. Transaction cost in XMR has decreased significantly with this attack. Spammer's expense is so low because of this. Perhaps the block size limit increase is too fast.

<m​ainnet_pat:monero.social> what is the meaning of `reserve_size` in `get_block_template` and `generateblocks` rpc calls?

<x​fedex:matrix.org> reserve_size is the number of reserved bytes for the nonce_extra in the blocktemplate blob.

<m​ainnet_pat:monero.social> cool, thanks, I though it is a reservation for n transactions

<m​ainnet_pat:monero.social> somehow `check_tx_key` returns me 1 confirmation even if I mine 10 blocks after submitting the transaction. is there something I miss?

"Blockchain size is currently 131GB" Nope. More like 180 GB.

<x​fedex:matrix.org> idk, that's what moneroj.net/blockchainsize tells

Looks strange. My number is from my SDD, actual Monero blockchain file

<x​fedex:matrix.org> maybe that chart is the sum of the size of the blocks

<x​fedex:matrix.org> any database has overhead

Possible

<x​fedex:matrix.org> If blockchain size is 131GB, and actual size is 180GB, then overhead is approx. 27%. So, database size will grow by 110GB in one year if this attack continues.

Well, today blocks mostly were not full ... whatever that means. The size limit dropped from 370 or so to 350 or so.

<x​fedex:matrix.org> perhaps the block size adjustment window should be increased to prevent future peaks?

<h​ardenedsteel:monero.social> current dynamic block size allows increasing block size little with very little penalty.

<s​packle_xmr:matrix.org> There have been no dynamic fee adjustments the last few days.

<s​packle_xmr:matrix.org> There will be no dynamic fee adjustments for at least the next ~68 days.

<s​packle_xmr:matrix.org> To lower the minimum fees, the long term median must increase. That will not happen for months.

<s​packle_xmr:matrix.org> It makes sense that the average tx cost is lower when there is a flood of minimum fee tx. That doesn't mean the minimum fee has been lowered.

<r​ucknium:monero.social> xfedex: The dynamic block adjustment rules are the maximum. Consensus does not require that miners fill mined blocks if the mempool is full. If there is strong reason to believe that the txs are being created as a black marble flood attack, miners can run a patched version of `monerod` that constructs blocks below the maximum size.

<r​ucknium:monero.social> If a majority of hashpower runs the patch, the median block parameter of the dynamic block size rules will reset to about 297kB. That could prevent a share of black marbles that could cause an unacceptable loss of privacy.

<r​ucknium:monero.social> Miners would be sacrificing a little fee revenue. But current network conditions are causing a larger number of re-orgs than usual. It may be in miners' best interest to run a patch like that. By "miners" I mostly mean centralized mining pools, since they construct most blocks.

<r​ucknium:monero.social> spackle_xmr: That's how the dynamic block size algorithm works, right? Just need majority hashpower (majority of blocks) to reset down to the 297Kb?

<r​ucknium:monero.social> Most mining pools fixed their block template updating config pretty quickly after I figured out it was misconfigured last year: reddit.com/r/Monero/comments/11nu4a…ransaction_confirmations_are_now_60

<s​packle_xmr:matrix.org> For sure. Just need to mine 51 of the last 100 blocks.

<r​ucknium:monero.social> So maybe they would run a patch for better network stability and privacy if block size goes 600kB+

<r​ucknium:monero.social> Requires no hard fork or anything.

<r​ucknium:monero.social> Maybe add block size as a parameter to the `get_block_template` RPC call to `monerod`

I can make a PR to add this parameter

<r​ucknium:monero.social> Let's do it! Thanks. spackle_xmr has been showing some scary plots of how max block size can rise to a level that could potentially threaten user privacy (if the tx volume increase _is_ an attempt at black marble flooding by an adversary).

<s​packle_xmr:matrix.org> That strikes me as an elegant (but also severe) intervention. If this is the direction people want to go, I would ask it to be considered carefully and only do the minimum that is absolutely necessary.

<s​packle_xmr:matrix.org> I would also wait until it is absolutely needed before activating it. Keep in mind that the penalty median decreased as recently as 3101830. The decrease was the equivalent of about 2 days of block expansion from minimum fees.

What exactly are you trying to change about the fee/size algorithm?

Miners can have different reasons to limit blocks they create. For example, some pool nodes can be weak/overloaded and it will be an easy way for pool admins to reduce load

And this parameter will be 0 (=unlimited) by default

Doesn't tell me what is being changed.

get_block_template RPC

what mining pools and solo miners use

right now they're bound to monerod default behavior which is to fill the block as long as there is anything to fill it with

<b​lurt4949:matrix.org> (no consensus change)

Binaries for v0.18.3.2 are online

Yeah I see that much, still don't know what the goal is. The RPC is just informational.

Miners do have an incentive to fill blocks, but they might want to limit it if theire servers can't keep up

So either we'll haves miner nodes falling behind, or miner nodes that work fine but mine smaller blocks

I'm talking about huge transaction counts, much more than we have even now

We already have mempool limiter (command line option) which can be used to limit block sizes, but in a less controllable way

I already know all this lmao. So basically you want miners to have enough information to make personal decisions about block contents based on the expected block size?

yes

With the expectation that miner software will be updated to expose options?

yes

pool software to be precies

Ok it makes sense to me, this kind of choice has always been available. The current fee algo is just a suggested default policy.

monerod solo mining ("start_mining" command) will have this optional parameter too

p2pool has its own stuff entirely, it doesn't use get_block_template RPC

and it doesn't have these performance issues, although its limited to 3800-4000 transactions per block in current implementation

which is an arbitrary constant and can be increased if needed

I see, interesting

<b​lurt4949:matrix.org> if this type of blocksize "soft" limit is to be implemented, it should be done now instead of waiting for when its needed

<b​lurt4949:matrix.org> more time for miners to update their software

I will make this "max_weight" limiter pull request to master branch only. Those who really need it, will be able to compile and use it themselves. Not sure about release branch, this PR is getting big.

jeffro256: can you take a look at monero-project/monero #9235 ?

I have seen this in the GUI where it would sporadically say wrong password when connecting to a remote node with RPC login. I thought it was a GUI bug but this user now has a similar issue and the linked commit could be related since it touches http auth code.