New BSIP: Allow arbitrary data in blocks and transactions

[abitmore]

Motivation and Rationale

Arbitrary data in blocks can be used to analyze which blocks are signed by which node software and what versions. For example, a bitcoin miner can put a short string in the coinbase transaction of a new block, which may contain useful data for analysis.

Similarly, arbitrary data in signed transactions can be used to track which transactions are signed by which client software and what versions. This topic was brought up recently in discussions about workers when debating how to evaluate a GUI worker's performance e.g. how many users are using the worker's product(s) and how much fee the users contributed to the network.

Although tracking (of client apps) can be done by client apps adding a custom operation in each transaction, it has the disadvantage that it would pollute the account history.

Another option for tracking (of client apps) is to make use of data fields which would be added by #185, however it is on the layer of operations thus is not as good. For example, Steem has a json_metadata field in comment_operation so it can be used to track data about posting (see https://steemd.com/tx/fc71ea90002a68083d78faec78380a581ad4694d), but other operations e.g. vote or transfer doesn't have such a field so less data can be used for analysis.

Implementation

We can add an optional field to extensions of block_header class as well as transaction class.

Discussion

Pros and cons about exposing version data was discussed in #120. This document mainly focuses on adding arbitrary data which is not necessarily soft versions, but not for forcing the node operators to publish special data, nor for applying special chain logic (aka hard fork) around the data.

See Also

• New BSIP: Add reference data to operations and database objects #185
• BSIP Draft: Versioning BitShares and Block Producer Publishing Version #120
• [WIP] blockchain on-chain versioning bitshares-core#1422

[bangzi1001]

It's easier for UI or APP do their own tracking. If they want, they can collect data like unique hardware, software version and number of human (regardless of multiple accounts) access to the UI or APP. They also can use referral link to track how many new registration via web or APP and fee generated.

If this feature added into core, it will put unnecessary workload to core developer and also block explorer operator eg. Cryptofresh and bts.ai since they need to parse data. FYI, Cryptofresh was down since 8 days ago, more data to parse mean they need more time back to online.

[pmconrad]

This adds unpaid bloat to the blockchain.

Clients can already embed a custom_operation with arbitrary data into their transactions. This can be bloat as well, only the client has to pay for it.

I agree that clients better do their own tracking. E. g. I use the GUI only passively for monitoring markets. This kind of usage wouldn't appear in this tracking method because I don't send transactions.