Add optional data field with transaction

[ByronAP]

From an exchanges perspective the lisk system would be much easier to use if we could include a small amount of data with a transaction (a username or an id). This gives the ability to have 1 central account and provide users with some small simple data to include with any transaction which then allows deposits to be processed easily and efficiently. Instead of having thousands of accounts that we need to poll and then waste resources resending deposits to the exchanges master account.

[ByronAP]

can this get done plzzzzzzzzz :-)

[ByronAP]

karmacoma I know there is a lot to do but this is important and should be done early so sites can use it and not have to hardfork for something so simple. The data doesn't need to even be encrypted just a simple field.

[fix]

I believe this is a non trivial upgrade in the protocol. Don't expect to have it fixed really soon.

I agree this is something different from a Blockchain app and that could be useful.

[toschdev]

After having some further discussion on this issue, we have now agreed to implement it with the following properties:

data is only present in type 0 transaction and optional
data is located within asset property of a transaction
a type 0 tranasction costs 0.1 LSK, with data (max 64 Bytes) it will cost 0.2 LSK. Therefore 0.1 fees for using the data property
when data is present, it wil be in asset: { data: ‘…’ } . If no data is present it will be filled with a null.

[Tschakki]

@karmacoma I have a big concern with the new data field in Transactions on the Lisk Mainchain:

As we cannot verify the content of it, it could be easily abused to store ethically or legally questionable content, or links to sites with such content.

As there is no necessity for the Lisk Mainchain to include this data field, we should protect the Mainchain from possible pollutions as much as possible, as it could result in people not being allowed to store it on their computers anymore in a particular country.

As long as we don't have a real use case why we need to include it, I think it's better to be careful here. Or at least we should discuss before, how it can abused and if, what we can do against it.