[LIPS] Enable transaction invalidation by using nonces
andreas.kendziorra at lightcurve.io
Tue Jan 29 05:56:20 EST 2019
With this email, I would like to kickoff the discussion for a LIP
regarding the roadmap objective “Enable transaction invalidation”.
The motivation for having a mechanism to invalidate transactions is the
planned dynamic fee system. With a dynamic fee system, transactions
could get stuck in the transaction pool for a long time if they have a
too low fee. For these situations, it is desirable to have a mechanism
to invalidate a transaction or replace it with another transaction with
a higher fee.
The proposed solution is to replace timestamps by nonces in transaction
objects, and to replace the uniqueness requirement for transactionIDs by
a uniqueness requirement for the combination of sender account and
nonce. With this, a pending transaction can be replaced by sending the
same transaction, including the same nonce, again, but with a higher
fee. Once the transaction with the higher fee is included, it is
guaranteed that the original transaction will not be included. This also
allows to invalidate a transaction, tx, without replacing it by a
meaningful one. The sender of tx could simply issue a balance transfer
transaction to themself where the nonce of tx is used.
If network identifiers are already used (see
uniqueness requirement can be changed to enforcing uniqueness of the
combination of sender account, nonce and network identifier. This allows
nodes to forget about all used combinations every time the network
Some words about the motivation for this specific solution:
Timestamps of transactions are currently not very meaningful. This is
because arbitrarily small values are allowed, even timestamps before the
genesis block. Enforcing a lower bound on the timestamps could lead,
however, to problems. If the lower bound is rather tight (e.g., if
timestamps are not allowed to be older than 12 hours during inclusion
time), transactions that are pending for a long time in the transaction
pool could become invalid. If the lower bound is rather loose, the value
becomes again rather meaningless.
On the other hand, the existing upper bound on timestamps (timestamps
are not allowed to be in the future during verification) sometimes
resulted in rejected transactions due to not matching system times (see
https://github.com/LiskHQ/lisk-elements/issues/191). A workaround was
provided for the client side by adding an offset to the system time. But
manipulating the time provided by the system in order to get a
transaction accepted is obviously not the right way. As this upper bound
does also not provide any advantage, it should be removed.
Removing this upper bound eliminates the meaning of the timestamps
completely. Thus, one should not interpret these values as any time
related property if there are no restrictions on timestamps. Instead,
the values should only be interpreted as a nonces. Therefore, we should
remove the mentioned upper bound and rename the property “timestamp” to
Note that completely removing timestamps (or nonces) without replacing
them by anything else would have a bad impact on usability. This is
because it is not allowed to have two identical transactions included in
the blockchain. Otherwise, one could easily perform transaction replay
attacks. Therefore, we would like to have some way to make each
transaction unique. So far we did this by using timestamps which results
in unique transactionIDs. In this proposal, we use unique combinations
of sender account and nonce (and network identifiers if they exist).
I’m looking forward to receiving your feedback.
andreas.kendziorra at lightcurve.io
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LIPS