Neo: Network spamming - current fixes have not had the desired impact

[bpetridis]

Hi All,

Raising this as an issue again as I don't believe the fixes mentioned in

https://github.com/neo-project/neo/issues/353
and
https://github.com/neo-project/neo/issues/358

Have had the desired affect. Network is borderline unusable again with this latest spamming. My personal thought is that GAS should be mandated on all TX's as no matter how well the chain is tuned it's a hole I don't believe will ever be able to be fully plugged. I think this is beyond the point of conversation now and needs to be handled as a fully fledged outage incident.

However I have noticed that a lot of nodes are still lagging behind 2.9 - will that update once fully propagated address this?

Please let us know,

Cheers

Bill

[JustinR1]

I agree that there should be mandated gas fees on all txs.

[jibbah777]

Cant there be a limit a user can send each block

[shargon]

The NEO's difference is the free network, we can't lose it.

• We should increase the free TX size from 20 to 50
• We should add a little PoW for TX
• We should be able to remove TX from the pool, if it is a free TX and is waiting for more than X blocks (TBD)
• We should determine if is a free TX if his fee is > 0.0001, not 0.00000001

[erikzhang]

We should determine if is a free TX if his fee is > 0.0001, not 0.00000001

Fully agree with this.

[RavenXce]

The NEO's difference is the free network, we can't lose it.

• We should increase the free TX size from 20 to 50
• We should add a little PoW for TX
• We should be able to remove TX from the pool, if it is a free TX and is waiting for more than X blocks (TBD)
• We should determine if is a free TX if his fee is > 0.0001, not 0.00000001

Strongly agree with all points! Especially the PoW idea for free txs.

• We should determine if is a free TX if his fee is > 0.0001, not 0.00000001

But please make announcements before this happens so we and others can adjust the fee paying mechanisms first!

[bpetridis]

Great feedback, thanks guys. If this has now translated into a dev task is it possible to link the ticket here so we can keep track? I run a few of the community channels so it would be good to have a task that we can monitor and provides updates on.

[bpetridis]

Out of curiosity how would the PoW model work in this scenario and what would it be measured against? Are we talking more priority to nodes that contribute as opposed to clients that are simply invoking tons of TXs? Apologies if that sounds like a dumb question, just trying to wrap my head around it more.

[jsolman]

How about less than .00001 to not be considered free instead of .0001 ?

[RavenXce]

Out of curiosity how would the PoW model work in this scenario and what would it be measured against? Are we talking more priority to nodes that contribute as opposed to clients that are simply invoking tons of TXs? Apologies if that sounds like a dumb question, just trying to wrap my head around it more.

The transaction mining is already in discussion here: https://github.com/neo-project/neo/issues/408

For dropping of txs, there is an issue here (there are several other related iirc): https://github.com/neo-project/neo/issues/414

For the rest, there is no issue created yet afaik. This is the first time those have been proposed.

[EdgeDLT]

I think we'd go a long way in reducing these issues by:

1. Educating users on priority fees/simplifying the use of them (such as the way Neon v2 has done it)
2. Get exchanges to use fees when moving funds from a large number of wallets
3. Adding a small network fee for GAS claims

We can have free transactions, the problem is when too many free transactions occur all at once. Every time more than 20 free transactions are sent within 15 seconds, we end up bloating the mempool with transactions that can be processed but aren't because of the MaxFreeTransactionPerBlock limit.

Adding a network fee to GAS claims has the added benefit of reducing the frequency of claims, and allows claims to go through during congested periods when lots of free transactions are competing for one of the 20 slots in a block. That will improve the UX a lot.

[bpetridis]

Out of curiosity how would the PoW model work in this scenario and what would it be measured against? Are we talking more priority to nodes that contribute as opposed to clients that are simply invoking tons of TXs? Apologies if that sounds like a dumb question, just trying to wrap my head around it more.

The transaction mining is already in discussion here: #408

For dropping of txs, there is an issue here (there are several other related iirc): #414

For the rest, there is no issue created yet afaik. This is the first time those have been proposed.

Thanks for the links, the minor PoW idea sounds like a real winner. Just read through it, very smart. I think there really should be a push to get traction on 408 and 414 as both of those look quite well defined. Guess the others can drop into a future iteration however if there is agreement on the > .0001 I'm happy to raise a specific development ticket as the definistion for that task doesnt seem to require much more than whats already been said.

[jibbah777]

Implement auto-gas claim and/or only distribute when blocks are quiet and/,or limit gas claims to x amount per day dependant on network activity reducing the amount of transactions

[xenzorz]

As others have mentioned the network is experiencing issues again.

My personal opinions:

• Gas claim reduced from 5mins to 30min
• Gas fee's on all Transactions, even 1 drop.

[shargon]

@RavenXce https://github.com/neo-project/neo/pull/392 was merged, so now a low priority transaction will be like this

https://github.com/belane/neo/blob/7586f39db092bff5aa7bc0ff712f63fd7ca537ab/neo/Network/P2P/Payloads/Transaction.cs#L52

If the group is full, it will be cleaned, all the low priority TXs that have arrived from 20 blocks will be removed.

https://github.com/belane/neo/blob/7586f39db092bff5aa7bc0ff712f63fd7ca537ab/neo/Ledger/MemoryPool.cs#L108

[RavenXce]

@shargon so the magic number to pay is 0.001 GAS?

[WyattMufson]

I agree with @shargon on all points mentioned above and strongly agree that there shouldn't be a minimum requirement for GAS for every transaction. #408 sounds like a very interesting concept.

[Tom-Chilli]

I'm not a developer, though I am an active moderator on the community run telegram channel (have been for 12+ months).

The constant congestion is making people lose faith in the neo blockchain. We have various dapps now saying they will leave the chain, and I'm sure more are thinking about it.

There seems to be a lot of good ideas, about preventing spam.

One thing I have thought about - is why not limit free transactions to one per wallet per block. In this situation you couldn't have a project try and push through thousands of free transactions in a single block, as the rate would be limited (and hopefully this would result in them paying a minuscule fee per transaction so that they are pushed through faster).

Regardless of what we do - we definitely need some counter measures soon to bring back confidence to the neo blockchain..

[shargon]

@RavenXce Yes, is 0.001 and is defined in protocol.json

[jsolman]

@Tom-Chilli I have mentioned before the idea of having accounts throttled during situations where the mempool is large. Limiting to only one transaction for an address per block though is too simple and too limiting. I believe deriving the limit for transactions per block by an address as a function of the amount and age of the address’s gas could work well. I still hope to finish writing a NEP for it. Also I would like to make some performance improvements to the mempool. Hopefully I’ll get time to prioritize soon.

[jsolman]

Sorry on mobile and accidentally; closed and reopened. The UI should ask to confirm instead of one click to close and comment.

[Tom-Chilli]

Interesting concept, I do like the idea and very keen to see how it works!

In the situation of sending more then one transactions per block per wallet, if someone wanted to send multiple transactions - do you see a gas cost as really that limiting? A drop of gas per transaction would allow thousands upon thousands of transactions for minimal cost. This would then push these transactions out of the 'free transaction limit' pool, and hopefully prevent congestion.

It seems to me the one of the main issues of congestion is to do with the free transactions, so every attempt to persuade people to utilise a gas fee would be beneficial?

[jsolman]

This also can be closed by #500