[LIPS] Enable transaction invalidation by using nonces

Andreas Kendziorra andreas.kendziorra at lightcurve.io
Tue Jan 29 05:56:20 EST 2019


Dear community,


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 
https://github.com/LiskHQ/lips/blob/master/proposals/lip-0009.md), the 
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 
identifier changes.


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 
“nonce”.


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

-- 
Andreas Kendziorra
Cryptographer, Lightcurve
andreas.kendziorra at lightcurve.io
www.lightcurve.io

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lisk.io/pipermail/lips_lists.lisk.io/attachments/20190129/14282043/attachment.html>


More information about the LIPS mailing list