Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Shorthand

Discussion participants: Makoto TakemiyaAndrei LebedevNikita Puzankov

Makoto Takemiya

neI

...

also don’t think rejected transactions should be in a block. Is there a good reason to have them there?

Andrei Lebedev, [16.03.20 11:01]
[In reply to Makoto Takemiya 武宮誠 (Sora.org - Soramitsu)]
 :

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

Никита Пузанков, [16.03.20 11:01]Nikita Puzankov :

I didn't catch that

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [16.03.20 11:01]
[In reply to Andrei Lebedev]

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

...

Andrei Lebedev, [16.03.20 11:03]

I wonder how this problem is solved in other networks. Because your concern is valid, and it should be already solved somehow.

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [16.03.20 11:03]hmmMakoto Takemiya 武宮誠 (Sora.org - Soramitsu), [16.03.20 11:04]

I think it isn’t solved. I think if something is replayed, you can just pay twice (assuming you created a new transaction)

...

.

...

In another blockchain project 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

...

the other blockchain project had.

Andrei Lebedev, [16.03.20 11:05] :

The same thing is also present in Iroha. But it is quite possible to do this spending attack in a short timeframe.

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [16.03.20 11:05] :

That way nodes can try to reject transactions that are outside the time

...

.

...

Sure, but it is not our problem, but the sender’s :)

...

Nikita Puzankov :

that what I was talking about with concept of TTL for tx processing

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [16.03.20 11:06]
[In reply to Никита Пузанков] :

What do you mean?

...

Nikita Puzankov :

Like a usual packets on internet - Time to Live

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [16.03.20 11:06]
ah

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [16.03.20 11:06]
yes

...

 :

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.