Priority by transaction amount

I have an idea. Lets prioritize transactions by amount of nano sent. Bigger amount - higher priority. If someone is trying to send a big amount back and forth there will be a delay anyway as the second transaction needs to wait for the confirmation of the first one. Or there could be some artificial delay by the protocol to send nano further you have wait a certain interval after it's cemented into the ledger and fully synchronized with <50% nodes. So it means if someone is willing to hurt the network with spam must own a huge amount of nano, which is very unlikely to damage your own network you invested.

Those micro amounts spammed will be left unconfirmed forever. And we should not care about those transactions. They even can be deprecated and rejected by nodes after the certain time.


I am also a fan of this approach. Prioritization by transaction amount could be done after prioritization of DPoW, so if pow of two blocks are the same they will be prioritized by transaction amount. Given the bounded backlog is not a sure thing, it seems like this could get legitimate transactions out of limbo. Such a change would also not be easily utilized by a spammer, since they risk having large amounts of funds tied up in transactions if the network were to slow down or DPoW were to rise.


Have you digested the TaaC/P4Q proposal, and seen my analysis of how it would function with unused TX capacity donated within the priority queue?

We need to do what we can to keep Nano usable for everyone (who is legit), and not favor large balances/transactions if possible.

1 Like

and not favor large balances/transactions if possible.

Please give me a reason why 0.000000000001 transaction must be prioritized over 0.1 nano transaction? Why do I need to send to someone 0.000000000001 ???

It doesn.t mean people sending 0.1 nano will wait hours (comparing to the actual situation). I cannot see a big discrimination. The only micro spam transactions will be bloated.

Everyone on binance and other exchanges is complaining about waiting days for confirmations.

Have you digested the TaaC/P4Q proposal

Probably something very complicated. Sorry I am not interested in something I and other normal people don't understand.

I generally don't like this idea but this could be done maybe at least until we handle the spam attack.

Thanks for clarifying that, as it wasn't evident from the OP. So you are discriminating between dust-sized (or micro) TX and TX in the range of human economic activity, but not between classes of the latter? That is, there would be no prioritization between a 1 Nano and a 1000 Nano TX?

And what if the best fix has some complexity to it? In a nutshell TaaC/P4Q has a "priority queue" if a spam situation occurs. Within the PQ an allotment of available TX capacity is made based on wallet balances. (So a 1000 Nano wallet could transact far more frequently than a spammers dust wallet, and even with a large wallet a spammer would be limited to a small proportion of overall TX.)

The baseline PQ would create sizable delays for modestly sized wallets (1 TX every "X" hours or days depending on wallet balance). So a modification to it is to donate unused TX capacity to those seeking to make TX. Exactly how this would be done is TBD, but in principle it would enable anyone to transact pretty much at will, with a spammer still unable to significantly impair normal users.

Looks like a gas in Ethereum for me. Will it have additional TX balance on peoples wallets? Why do I need it? And how much the 1 TX would cost? Will it be any TX marketcap?

I'm not sure how you relate this to Ethereum gas. TX remain free (apart from the PoW calculation) in this scenario. The donation is of rights to make a transaction in the PQ, not of any amount of Nano or anything else.

I am a fan of the TaaC/P4Q proposal. However, this thread's proposal would seem to be easily implemented and tested, whereas P4Q would take a long time. Don't let perfect be the enemy of good. The current spam situation must be dispatched sooner rather than later.