Shorthand
Discussion participants: Makoto Takemiya, Andrei Lebedev, Nikita Puzankov
I also don’t think rejected transactions should be in a block. Is there a good reason to have them there?
Otherwise it is possible to replay a rejected transaction, and it may be committed, e.g. when someone got enough assets after some time if there were no assets when the transaction was initially rejected
I didn't catch that
I see
Unfortunately it also has the problem of filling up the blockchain
Potentially for free
If this was in bitcoin, for instance, one person could add petabytes of transactions for free and no one would be able to use it. Sora faces this potential problem
I wonder how this problem is solved in other networks. Because your concern is valid, and it should be already solved somehow.
I think it isn’t solved. I think if something is replayed, you can just pay twice (assuming you created a new transaction).
In NEM we had a timestamp with each transaction and there’s a threshold required. I forget the number, but if a transaction was, say, 3 hours old, it would be ignored.
I think we can do this in Iroha2. I haven’t said all my plans yet, but I want to incorporate something like a network time service, like NEM had.
The same thing is also present in Iroha. But it is quite possible to do this spending attack in a short timeframe.
That way nodes can try to reject transactions that are outside the time. Sure, but it is not our problem, but the sender’s :)
that what I was talking about with concept of TTL for tx processing
What do you mean?
Like a usual packets on internet - Time to Live
Yes, For example, it could be like 10 minutes or something configurable. I think this is the best way.
TL;DR
To prevent transactions "spamming" (with transactions that will be rejected by validation, but accepted and stored in queue before for some period of time) we may introduce Transactions Time to Live and clean up queue when this time comes.