Staked free tx [idea]

[igormcoelho]

Guys, I've been wondering if a simple idea could work out to guarantee free or low fee tx, by providing the network a "guarantee" that staked address will "behave". The idea is add a "stake free tx" remark on a transfer, and after that, two things will happen:

1. address will apply for free/low fee (as long as amount is over StakeMinimumLimit of Neo or Gas)
2. if implemented filters catch transaction as "misbehavior", funds will be locked at this address for a given number of blocks

I believe this is simple and effective to prevent attacks while keeping fees low (or even zero). Another option is to use staked address signature on a different address to apply for low fees (while compromising the funds of the staked address). That may also have some applications, where funds are distributed, but staked funds are in a centralized point.

[35kus35]

That's an interesting idea and I like it if it's possible.

I also have an idea and I'm not a developer so it might be terrible... Sorry, I thought I'd hijack your issue rather than spamming NEO's github too much (my idea relates to the same problem).

I also apologise for the non technical language below!

To me it seems like most spam attacks originate from one address or go around in circles through various addresses etc. Is it possible to have a 'filter' that can detect spammy transactions and the address they originate from (including any 'children' transaction addresses below that address)? If that's possible then those addresses could then get flagged for x amount of blocks.

Then those addresses could be subject to some additional rules like this:

1. Assign the lowest possible priority, so genuine free transactions will be prioritised higher than the spammy free transactions.
2. Limit the amount of no fee spammy transactions that can be sent (ie the offending circle of addresses will be barred from sending more than 1 free transaction per a block for the next 100 blocks
3. These extra rules would only apply for free transactions and would be processed as usual if the sender then decides to pay a transaction fee.

Please delete if this isn't possible or is a terrible idea.

[igormcoelho]

I think this is the place to expose ideas and duscussion, thats fine. This is one kind of filter we can try to use, but detecting cycles in large networks can be expensive, as they can be arbitrarialy large... and banning intermediate addresses may not be effective if they have only small amounts of token, which is often the case. The stake idea is to guaratee attacks will hurt, and Im sure they wont happen anymore.

[PeterLinX]

@igormcoelho how to make an assessment to the address if it has "malicious" behavior?

[shargon]

I like the idea :)
Consensus should vote to take this fee if we detect the issue maybe?

[igormcoelho]

@PeterLinX we can start to implement simple filters (which are easy and explained in next comment), and evolve these filters as attacks become "smarter". The difference from not having a stake is that in general we cannot punish specific addresses, and even if we do, they would hold small portions of token (in millions of accounts). But if they are obliged to send tx signed by a staker (to have access to lower fees), the number of addresses is much smaller (and stake can be increased if problems reoccur). Right now, if we have a linked address we can detect all kinds of known attacks, as they are quite simple. Repeated transactions with similar values (signed by the same staker) will be interpreted as misbehavior. If the attacker don't have a stake, he will have to pay higher fees, as usual (solution to the general case). The point here is to protect exchanges and legit business on Neo to take fees they don't deserve.
It can be a good path to maintain slightly higher costs (but payable) for regular users (dollar cents), and lower/zero costs for legit business that have stakes at risk, or business that partnership with consensus nodes managers passing some votation process (that could work to authorize low fee airdrops with are legit, as discussed with Kev privately).

[igormcoelho]

How to implement the filters
As long as we have a staked address to put the blame on, we can implement filters in three ways: (1) directly on consensus nodes, they vote to block stakes according to specific rules (similar to what you said @shargon, but I'm only proposing public and automated processes, to avoid any random punishments. if some new attacks appear, new filters are created by the community to prevent them) (2) on relay nodes, that will simply block relay transactions they believe are misbehavior (which could vary from node to node), and in this case, they could block even non-staked paying tx, if they believe as misbehavior... users can always try to use other nodes, but that's bad for attackers and may indicate the attack lines on the network (3) relay nodes can pass messages to the pool and add extra information to help consensus judge the misbehavior (they could indicate why they believe punishment is necessary, for example, listing a group of bad transactions and even circular analysis that can be done better with heavy offline processing)

[igormcoelho]

@PeterLinX @shargon @localhuman if you all agree, we can try to quickly propose some simple implementation of staking (although @erikzhang would do that much faster and better hahaha), without any punishment at all, just to allow exchanges/business to escape general price changes. Obviously, the bad actors could still attack since they know there's no filtering... but I doubt someone will risk exposing itself with a high stake just to try some random attacks. I believe attacks will cease even without any filters. In my opinion, we should keep the 20 free tx strategy, adopt higher network fees and allow staking actors to escape network fees (free or zero).

[vncoelho]

I like the idea, broda. Nice and simple.

I thing that we can move towards that discussion we had with @localhuman about Machine Learning.
We can Train the Black-Box and publicly list its rules and mechanism.
Thus, everyone will be aware about which kind of action will result in misuse tag. If someone is classified wrong then we discuss about re-training (remove the rule).

[RavenXce]

I like this idea too. It simplifies paying for withdrawals from smart contracts as well.

It will be very useful in the near time but probably not as useful for neo 3.0. I'm not sure how hard it would be to agree on a mechanism for this quickly.

Since neo has a master node system and adjustable policies regarding inclusion of txns, I do feel we should make use of that to quickly adapt and maintain general usability in the short term when such attacks happen.

[jsolman]

My idea is different than this, but it has a similarity in that it involves a weight based on GAS holdings, but it would not require a stake transaction and all existing accounts can work with it automatically.

It would be to implement throttling addresses based on their GAS balance and a new balance age that is introduced. When there is a high rate of transactions being added on the network, this would trigger throttling how many transactions an address is allowed based on GAS balance and gas age. New accounts would only be throttled if there are a high rate of transactions being added on the network. Old accounts can still be throttled if they exceed their rate limit, and if they try to attack the network by splitting their gas to many small accounts or to another large account either their gas age or gas amount will cause their new account(s) to still be throttled and unable to attack the network. It should be possible to upgrade the leveldb database to include the GAS age along with storing balances. I may adjust this strategy some, but this is the basic idea for which I started working on a NEP.

[igormcoelho]

I like your idea too @jsolman , and I think we need to try multiple strategies to guarantee we can avoid different types of attacks. It's nice that you're writing a NEP, we can discuss better there, how to manage the history of GAS and how to guarantee that people that just received GAS as payment won't be affected. I will write a NEP describing the staking in details, it's not complicated and I think it's feasible to guarantee that exchanges and big business will operate normally and cheap even when general network prices rise.
@RavenXce I think this can be easily (and quickly) adopted, if the idea goes right on the point... I will put efforts to draft a NEP with implementation details as soon as possible, and community will judge if it's worth or not.

[localhuman]

I would add that gas splitting is not inherently a malicious thing to do. Any wallet that wishes to send high volume of tx with attached fees will need to engage in this.

[vncoelho]

With this stake idea we can also create a system of lending Staked Verification accounts, @igormcoelho....aheuaheuaheuaea
That is why we need that kind of special invocations on Neon-JS, @snowypowers :D

I lend you my Staked account for this locked, then, I can withdrawn the funds!

[jsolman]

@localhuman gas splitting would lower your gas age some, but not that much if you aren’t splitting off a large percentage of total owned gas, and all that would need to be done for gas age to increase is wait for gas age to increase again. The effect of gas age would be logarithmic growth probably so that just creating 10000 accounts and waiting a year won’t really let you attack the network that long and will cost a lot for initial investment and in fees; would need to buy over 10,000 gas in that example for instance. I’ll work on the NEP and people can decide.

I think it is very important that throttling be done in a way that is pretty much deterministic for two nodes at the same height. If Rpc accepts a transaction on one node all others at that height should accept; if it rejects due to throttle, all others at that height should also reject had the transaction been sent to them. I believe my proposal can achieve this. Otherwise, if one node accepts and others drop how would that become known to the original sender of the TX in a timely fashion.

[localhuman]

An exchange that is sending a high volume of TX a day will need to keep getting lots of gas and splitting it, and won't have time to wait for gas age to increase.

[jsolman]

@localhuman I think the exchange would have quite a bit of gas on hand accumulating age though so that it would work out. That being said, I got tied up with other priorities and couldn’t work on the NEP today. Maybe go for an implementation of #358 in the nearer term, it seems probably less work to implement. I’ll still work on the NEP though, but might take me a bit with my other priorities.

[igormcoelho]

@vncoelho @PeterLinX @erikzhang @localhuman @canesin @jsolman @35kus35 @shargon please join us discussing the feasibility of this NEP here: neo-project/proposals#66

[igormcoelho]

Now I think this could be one use case of this slightly broader NEP: neo-project/proposals#67. Perhaps approving this will get us ready faster to make other changes, such as this staking one.

[igormcoelho]

I will close this here, in order to redirect discussions to the Proposals section.

[jsolman]

An exchange that is sending a high volume of TX a day will need to keep getting lots of gas and splitting it, and won't have time to wait for gas age to increase.

Splitting gas wouldn't reset GAS age with the way I'm thinking of calculating it; GAS age would be based on the total balance of GAS held on the address not per UTXO.

[igormcoelho]

I'm reopening this issue, because we have more than one possible idea being discussed :)