Multi weighted priorities

We had a good number of proposals to tackle the spam problem: TaaC, PoS4QoS, bounded backlog and others. Going forward, I think all (or some) of these proposals could be consolidated into a single priority number, that would determine the order of the transactions into the (bounded) backlog.

Meaning that, for every transaction, the node would do a calculation weighting several factors like, for example:

  • POW
  • Time since the last tx/period (TaaC).
  • Balance of the sending account (PoS2QoS) or even the receiving account.
  • Amount in the transaction.
  • Age or number of blocks in the sending and/or receiving accounts.
  • Whitelisting of accounts (for tipbots, exchanges, fountains, et cetera).
  • ...and others.

Every node operator could modify, starting from default values, how each factor is weighted into the final priority value that would determine it's order (or non inclusion) of insertion into the bounded backlog. Thus, the network could adapt with flexibility to specific attacks, changing how the nodes evaluate all this to make the vectors used by the spammer have less priority.

Additionally, it would be interesting if the node operators could provide custom factors in the form of easily plugable code (either in C++ and/or some easily embedable scripting language like Lua or Javascript) so for example they could fight a dust attack like the one the network is currently experiencing with something like:

if (txamount < 0.00000000000000000000001) priority -= 1000 

If, to avoid this, the spammer switch to send 0.001+random amounts back and forth between 1000 accounts he would be heavily hit by the TaaC factor whose weight the operators could temporarily increase in the priority calculation.

1 Like

I'm fairly certain that transaction ordering needs to be uniform across the network otherwise CPS would come to a crawl, as block elections would not overlap. In other words, if each node is voting on different sets of blocks, then a block will have a difficult time reaching the threshold needed for confirmation. Thus, nodes need to independently order transactions the same for quick settlement and high throughput of confirmations.