Set a minimum gas price of 0.005uatom

I propose that we do like:

gaiad q globalfee params

bypass_min_fee_msg_types:
- /ibc.core.channel.v1.MsgRecvPacket
- /ibc.core.channel.v1.MsgAcknowledgement
- /ibc.core.client.v1.MsgUpdateClient
- /ibc.core.channel.v1.MsgTimeout
- /ibc.core.channel.v1.MsgTimeoutOnClose
max_total_bypass_min_fee_msg_gas_usage: "1000000"
minimum_gas_prices: []

to

bypass_min_fee_msg_types: []
max_total_bypass_min_fee_msg_gas_usage: "1000000"
minimum_gas_prices: [0.005uatom]

impact analysis

Thanks to @tom

Summary:

image498×278 32.8 KB

1. this change would double the cost of all transactions, unless the transactions are proposed by binance. While I’ve not confirmed this yet, @zmanian states that x/globalfee only really works at the mempool layer. We can think of it as a mempool filter that operates globally and is governance controlled.

Binance seems to be operating with a modified mempool, as illustrated by blocks they produce containing zero fee transactions. It is also possible that binance simply hasn’t adhered to the minimum gas settings listed in the Gaia repository.

This should definitively reduce the DDOS vulnerability of the Hub. But I’m just wondering what are the implications of removing the IBC administration messages from the bypass fee list.

The hub doesn’t have a ddos vulnerability more or less than any other system. Let’s discuss for a moment the nature of a distributed denial of service attack. A distributed denial of service attack is expensive for the attacker. That is because in a distributed denial of service attack, the attacker is using many machines to come at a single system. The issue which amulet should not have disclosed, and described poorly, does not require many machines and in fact requires only a single open API endpoint. The attacker needs exactly zero machines under their control. It would be extremely unwise to think of such an attack as a distributed denial of service attack because that would completely invert the economics of the attack. Okay, now that we have gotten basic definitions out of way, let’s get on to impact. I believe that this would be absolutely terrible for relayers and would change the economics of relaying around the hub. I think that the only viable path would be to whitelist relayers using governance. But then we would have to write the code to do that. I also believe that even though this would be absolutely terrible for relayers, we should probably do it anyway.…

Excerpt (1198 of 1553 characters). Read the whole post on the forum ↗

jacobgadikian:

Binance seems to be operating with a modified mempool, as illustrated by blocks they produce containing zero fee transactions. It is also possible that binance simply hasn’t adhered to the minimum gas settings listed in the Gaia repository.

I don’t think it’s related to a modified mempool, I would go for the second option, Binance probably has a local minimum_gas_price=0. The problem is, when both global and local minimum_gas_price are empty or equal to 0, the node’s mempool can accept transactions without fee. This is how the x/globalfee module works.

Secondly, from the tests I led, I can tell that Binance isn’t the only one with this setting.

Thank you for running tests!

You can be right about the modified mempool, but I think that we should talk about that some.

There’s more I would like to discuss, but we shouldn’t in public, so please feel free to send a DM to twitter.com/gadikian

cheers!

This seems like a good idea to me. The only issue is the concern of whether it would make things too expensive for relayers if they have to pay for gas. This is something that’s easy to test though. I think we should get some tests rolling to estimate typical costs on the testnet, and then do some napkin math to estimate the costs of running various important channels. If the extra gas cost ends up being small, it’s a clear win IMO.

Actually I’ve got the same concern.

Try on testnet first?

Yes, let’s try this on testnet first. We can plan for this coming Thursday.

OK, we can wait until thursday but I do wish to note that I don’t think that testing on the rs testnet accurately reproduces anything related to the spam issue.

The testnet has clearly experienced a netsplit and consensus is being driven mainly by banana apple and cherry.

@uditvira great talking with you yesterday!

Can you put up a gov prop w/ your testnet powers so we can see how this works out?

like the idea, down to give it a shot on the testnet to see if its viable

Indeed.

Have to wait on hypha to sort that though.

Awaiting an update on weather or not this is completed, then I can run various things to gather data.

We submitted the prop earlier today! Ping Dashboard

Unfortunately the proposal didn’t reset the bypass_min_fee_msg_types fields. The global fee is now 0.005 as expected, but the IBC messages are still in bypass_min_fee_msg_types.

https://rest.provider-sentry-01.rs-testnet.polypore.xyz/gaia/globalfee/v1beta1/params

Other than simply increasing the cost of transactions, why are we doing this?

Yes sir. That is intended to be a separate proposal.

correction: ah I see you were referring to the testnet. Yeah basically we should kill that testnet once we put up gaia-rs-2

this

Jacob Gadikian 🐳⚛️⚗️

I tried making these proposals before publicly releasing the information, Informal and Hypha did not have a complete view of the situation because they never got on a phone call with me about this matter until 10/4/2023.

My frist report of the issue was 8/15/2023 and I had completed replication by 9/21/2023.

Are you saying that this issue that you have demonstrated, with the mempools is still ongoing, and a fix would be to increase transaction fees to make it more expensive for an attack to cause this cascading collapse?

I’m saying that it was ignored by Informal Systems from CEO down, with the exception of @jtremback for over two months, yes. That is what I am saying.

Additional mitigations can be found here:

GitHub - notional-labs/placid: mitigations to p2p-storms

mitigations to p2p-storms. Contribute to notional-labs/placid development by creating an account on GitHub.

Hey Jacob,

It might not be as expensive as you think, the attacker can always spread via, nevermind, i see why this discussion should be taken elsewhere, but you probably understand what I’m trying to say

Paul

Hi Paul, Just want to let you know that it’s my opinion that none of the mitigations are super great, although when combined you can reduce the surface area for the attack. Sadly, @Jessysaurusrex saw it fit to publish the issue to the world. Here’s my mitigations repository: GitHub GitHub - notional-labs/placid: mitigations to p2p-storms mitigations to p2p-storms. Contribute to notional-labs/placid development by creating an account on GitHub. Here’s a very disappointing thread from the comet bft GitHub github.com/cometbft/cometbft ADR 110: Remote mempool `cometbft:main` ← `cometbft:thane/adr/mempool-client` opened 08:44PM - 03 Nov 23 UTC thanethomson +365 -0 Per recent discussions surrounding the default mempool in Comet and its flooding … gossip mechanism, this ADR is proposed to allow application developers to build their own mempools (or mempool clusters) that reside in entirely separate processes with a simple, standardized interface. :book:…

Excerpt (1091 of 5924 characters). Read the whole post on the forum ↗

Hi. Why 0.005uatom and not 0.0025uatom for example? How was this number determined?