Side effect: granting tokens can imply participartion in a crowdsale

[dexX7]

So this is actually an interesting behavior: because the simple send (tx 1) logic embeds the logic of participation in crowdsales and granting tokens (tx 56) uses simple send as mechanism to transfer value, granting tokens can trigger participation in crowdsales.

I'm not saying that this is wrong, but it should be noticed. As broader follow up I suggest to seperate core logic from the rest altogether and treat those as single and individual operations.

[CraigSellars]

Good catch - granting to an address that is running a crowdsale would do exactly as you describe - however, that token must have been listed as a supported crowdsale-accepted token. Interesting edge case.

[zathras-crypto]

Very interesting - could be played as a question of semantics I guess...

If we consider that a grant is a "create N tokens at address X" then that should not be a crowdsale participation action, because there is no implicit send to the crowdsale. If we consider that a grant is a "create N tokens at the issuer address and automatically send them over to address X" then that should be construed as a crowdsale participation action.

My $0.02

On Tue, Dec 9, 2014 at 10:16 AM, CraigSellars notifications@github.com wrote:

Good catch - granting to an address that is running a crowdsale would do exactly as you describe - however, that token must have been listed as a supported crowdsale-accepted token. Interesting edge case.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/mastercore/issues/227#issuecomment-66206700 .

[dexX7]

I'm "voting" for seperation here. Using "simple send" for granting tokens looks like a workaround for me and might become more relevant, if/when base operations are tied to an audit trail. Basically we don't want to end up with "simple send" transactions that are none. This is mostly the technical aspect.

Another one is functionality: similar to how a "simple send" could as well be a "participation in a crowdsale" or a transaction during the initial Exodus funding periode can initiate two effects ("simple send", "exodus invest"), this behavior is not a no-go by all means. Furthermore it's legit (spec wise and current behavior) for a crowdsale issuer to participate in his own crowdsale, even when using the issuing address.

Nevertheless, I think it would be cleaner to avoid the implicit participation altogether in this context. Even though there might be some nice combinations of features for some interesting effects, it can always be substituted by an explicit "simple send" transaction. The reason for this is to isolate effects. Let's take a closer look at this:

Managed property creation (tx 54): [create property] Fixed units property creation (tx 51): [create property] [lock managed issuance] [issue n units] Crowdsale creation (tx 50): [create property] [lock managed issuance] [create units via crowdsale]

We might already replace tx 51, if there were a seperated "lock managed issuance" flag or operation.

TL;TR: I think the goal should be to reduce chaining of effects and work into the direction of cleaner "base operations". Thus my opinion: let's not do an implicit participation here.

[zathras-crypto]

I actually concur with the concept of base operations. If we had an internal (auditable) 'MOVE' function a grant could be a create & move just as per current without also being a send.

Inherited behavior can sometimes = unexpected behavior so at a high level, all for simplistic base ops that are layered together to complete transactions - not sure where in the priority list this would go but would help towards stability imo.

[dexX7]

Ah, I was just thinking loud, so to speak, not literally meant everything should be split into base ops, but the "concept" is the reason why I'd prefer to remove the "side effect" of a crowdsale participation while granting tokens in this case.

[dexX7]

I suggest to address this before the release.

[dexX7]

After a discussion via email with @zathras-crypto, I noticed a small detail, which I completely missed earlier. From the spec#granting-tokens-for-a-managed-property:

After issuance, tokens may be added to the balance of a referenced address by broadcasting a this type of transaction.

Now, I'm still not sure, if this strictly implies a simple send, and I'm going to bring up this topic again, once we are closer to an audit ledger, where the validity of each action is important, but for now I think this can be closed.