fill_order_operation depends on object numbering

[theoreticalbts]

We are supposed to keep the object database out of the protocol layer, but fill_order_operation includes an object_id_type. Maybe it's OK because it's a v-op, but that implies v-ops aren't part of the protocol layer -- however, they have slots in the protocol-level static_variant.

This is basically an overall symptom of needing to more clearly separate the project into modular pieces -- or refine and consistently use architectural separations that are being ignored by the implementation like #246.

[abitmore]

Just a note here: the percentage based transfer fee feature requires an asset_object to be passed into the operation (protocol level) to be able to calculate fee. Any suggestions?

[theoreticalbts]

@abitmore : In general, your operations should use an asset_id_type, then fetch the asset_object referred to by the ID in the evaluator.

This percentage transfer fee feature actually needs a great deal of review, as it breaks one of the design principles of the Graphene toolkit, which is that the fee for an operation can be determined only from the operation and the current fee schedule. Now transferring some assets will have a fee which cannot be determined from that information alone (as you'll need to know whether the asset issuer's enabled the percentage-based fee for their asset).

This BSIP also really doesn't "play nice" with the existing machinery which converts the fee. There's really no way for you to tell the blockchain "for this operation, don't convert the fee to BTS" -- it's already converted by the time the op knows about it.

I think the sanest way to do percentage-based transfer fees is to make them an extension on the transfer operation, which basically says "I'm including this extra BTS / asset to be paid according to the BSIP rules," and then have another extension in the asset_update_operation which allows an asset owner to say "transfer of my asset is disallowed unless the transfer op includes the extension with so much on it." Then the main fee's paid into network / referral system as normal and the BSIP is an extra fee can be handled by totally custom logic.

TLDR, use the extension system to add another field to the transfer op, instead of trying to jam it into the existing fee field and have the existing fee handling code get in your way (what you're doing is different enough that it will get in your way).

This whole comment probably belongs in a new ticket :)

[abitmore]

New ticket #583 created, so I'll post replies of BSIP10 related questions there.

[vikramrajkumar]

This issue was moved to bitshares/bitshares-core#156