[LIPS] Remove redundant properties from transaction objects

Andreas Kendziorra andreas.kendziorra at lightcurve.io
Wed Dec 19 04:01:00 EST 2018


Dear community,


With this email, I would like to kickoff the discussion for a LIP 
regarding the roadmap objective “Remove redundant properties in 
transactions”.


The current protocol allows, and partially even enforces, to set some 
property-value pairs in transaction objects that are neither required 
nor used. For example, the “amount” or the “recipientId” properties are 
only required for balance transfer transactions, but not for any other 
transaction type. Some other properties, e.g. “requesterPublicKey”, are 
not needed for any transaction type. This increases the size of 
transaction objects unnecessarily, leads to confusion when reading the 
protocol and decreases the readability of the implementation. Therefore, 
we propose to clean up the property-value pairs of transaction objects.


Currently, the following properties are allowed for transaction objects 
independent of the type (all properties that are optional are marked):

  * amount
  * asset
  * fee
  * id
  * recipientId
  * recipientPublicKey (optional)
  * requesterPublicKey (optional)
  * senderId (optional)
  * senderPublicKey
  * signature
  * signatures (optional)
  * signSignature (optional)
  * timestamp
  * type

We propose to remove the following properties from transaction objects:

  * amount
  * recipientId
  * recipientPublicKey
  * requesterPublicKey
  * senderId

Moreover, the asset object for balance transfer transactions gets 
extended by the “amount” and the “recipientId” property. That means, the 
asset object is allowed to contain the properties

  * amount
  * recipientId
  * data (optional),

whereby the “data” property is optional.

For all other transaction types, the asset object does not need to be 
changed.


Note the following:

  * The “recipientPublicKey” property is not needed at all. The
    recipient of a balance transfer should always be identified by its
    address. All other transaction types don’t have a recipient.
  * The “requesterPublicKey” was initially intended to be used to
    request multisignature transactions by non-account holders. This
    functionality is, however, currently not enabled and therefore not
    required.
  * The “senderId” property is never needed since the “senderPublicKey”
    is a required property, and the address/id can always be computed
    from the public key.
  * The “fee” property is currently not required due to fixed fees.
    However, since it is planned to replace fixed fees by dynamic fees
    in the near future, we keep this property.


Best regards

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/20181219/13e10487/attachment.html>


More information about the LIPS mailing list