Audit charging of per-kilobyte fees about bitshares-core HOT 3 OPEN

From @theoreticalbts on July 31, 2015 15:28

It makes more sense to charge size-based fees on an operation-wide basis, i.e. you serialize the operation, see how big it is, and then charge based on that. Which would give a single size-based fee for all operations, instead of placing size-based fees on each operation. This makes more sense, as size fees are not meant to raise revenue, merely to protect network resources. Therefore size-based fees should be the same for all operation types -- there is no reason to allow them to be settable for each operation individually.

Moreover, as pointed out in the OP, setting size-based fees for each operation individually requires careful auditing to be sure that every operation of potentially unbounded size includes a size-based fee. Having unified size-fee logic would ensure that if an operation with a large serialization occurred, an appropriate fee would always be charged.

from bitshares-core.

From @theoreticalbts on July 31, 2015 15:32

The transaction signatures can potentially grow very large, e.g. if you create a large number of multisig accounts with maximum fan-out and use a custom_operation to require them all to sign. A size fee needs to be charged for signatures as well. What this suggests is that the size fee should be charged based on transaction size, including signatures!

from bitshares-core.

From @theoreticalbts on August 26, 2015 21:41

Some fee members are share_type, others are uint64_t or even uint32_t. We should be consistent and always use the same type; I recommend share_type

from bitshares-core.