[LIPS] LIPS Digest, Vol 3, Issue 2

Jacco jaccomintjes at yahoo.com
Tue Jan 29 14:38:01 EST 2019


Hello,

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.

Regards,

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
>    http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io
> 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 
> ?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-0001.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> LIPS mailing list
> LIPS at lists.lisk.io
> http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io
> 
> 
> ------------------------------
> 
> End of LIPS Digest, Vol 3, Issue 2
> **********************************




More information about the LIPS mailing list