[LIPS] Enable transaction invalidation by using nonces
andreas.kendziorra at lightcurve.io
Thu Jan 31 13:01:41 EST 2019
Thanks for your answer!
Just to avoid any misunderstanding: When I say that a transaction with a
low fee, say tx, gets stuck in the transaction pool for a long time,
then I'm talking about the situation that tx has valid fee (above the
minimum fee that will be defined in the dynamic fee system; otherwise
the transaction is rejected by nodes) but the network is so busy such
that every block is full, and every included transaction has a higher
fee than the one from tx. Then, tx can eventually get included when
there are less transactions (blocks are not full anymore), or the fees
of the included transactions decrease (fee of tx is large enough such
that delegates prefer tx over other transactions).
In this situation it is a subjective decision if a fee is "too low". For
user A, a fee might be too low when the transaction does not get
included within 1 minute. For user B, the fee might be too low when the
transaction does not get included within 7 days. For this reason, we
cannot make a general rule that prevents transactions being broadcast
due a certain fee value (as long as the fee is valid).
There is also the objective on the roadmap to have a fee estimation
algorithm. This algorithm is supposed to help the user to choose a fee
according to its priority. This will help users to avoid sending
transactions that have a "too low fee" from their personal perspective.
Does this answer your question?
On 29.01.19 20:38, Jacco via LIPS wrote:
> Would it not be easier to prevent any transaction with a too low fee from being broadcasted to the network?
> You still need a method to determine if the fee is too low and then reject the tx.
> This greatly improves the user experience, since no one likes to find out afterwards that his transaction is not being processed.
> Jacco <korben3>
>> Op 29 jan. 2019 om 18:00 heeft lips-request at lists.lisk.io het volgende geschreven:
>> Send LIPS mailing list submissions to
>> lips at lists.lisk.io
>> To subscribe or unsubscribe via the World Wide Web, visit
>> or, via email, send a message with subject or body 'help' to
>> lips-request at lists.lisk.io
>> You can reach the person managing the list at
>> lips-owner at lists.lisk.io
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of LIPS digest..."
>> Today's Topics:
>> 1. Enable transaction invalidation by using nonces
>> (Andreas Kendziorra)
>> Message: 1
>> Date: Tue, 29 Jan 2019 11:56:20 +0100
>> From: Andreas Kendziorra <andreas.kendziorra at lightcurve.io>
>> To: lips at lists.lisk.io
>> Subject: [LIPS] Enable transaction invalidation by using nonces
>> Message-ID: <e4571a0d-a781-0bad-7c0d-822543ad085f at lightcurve.io>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>> 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
>> 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
>> Cryptographer, Lightcurve
>> andreas.kendziorra at lightcurve.io
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.lisk.io/pipermail/lips_lists.lisk.io/attachments/20190129/14282043/attachment-0001.html>
>> Subject: Digest Footer
>> LIPS mailing list
>> LIPS at lists.lisk.io
>> End of LIPS Digest, Vol 3, Issue 2
andreas.kendziorra at lightcurve.io
More information about the LIPS