Proposal: lock supply or the ability to change issuer on record

[dexX7]

In particular, for properties created via tx 54: New Property with Managed Number of Tokens it is possible to issue new tokens, revoke tokens and to transfer ownership of a property to another entity.

In my opinion moving ownership of a property can create a security risk and there may be reason to lock it to one maintainer. Likewise, there may be reason to lock and freeze supply at some point.

I therefore propose two new transaction types to "downgrade" and "lock" properties, so that managed properties become immutable.

One transaction to restrict changing the issuer on record and one to restrict the creation and revocation of units of property.

Locking or freezing a property should not be reversible.

[dacoinminster]

Interesting idea.

I'm not sure locking would actually help though. If the issuer is
compromised, how does it help if the issuer cannot transfer issuer rights?
The address is already compromised . . .

On Tue, Dec 9, 2014 at 5:33 AM, dexX7 notifications@github.com wrote:

In particular, properties created via tx 54: New Property with Managed
Number of Tokens
https://github.com/mastercoin-MSC/spec#new-property-with-managed-number-of-tokens
it is possible to issue new tokens
https://github.com/mastercoin-MSC/spec#granting-tokens-for-a-managed-property,
revoke tokens
https://github.com/mastercoin-MSC/spec#revoking-tokens-for-a-managed-property
and to transfer ownership
https://github.com/mastercoin-MSC/spec#change-issuer-on-record-for-a-smart-property
of a property to another entity.

In my opinion moving ownership of a property can create a security risk
and there may be reason to lock it to one maintainer. Likewise, there may
be reason to lock and freeze supply at some point.

I therefore propose two new transaction types to "downgrade" and "lock"
properties, so that managed properties become immutable.

One transaction to restrict changing the issuer on record and one to
restrict the creation and revocation of units of property.

Locking or freezing a property should not be reversible.

—
Reply to this email directly or view it on GitHub
#294.

[zathras-crypto]

Issuer cannot be changed:
Outcome is both issuer and attacker have access to perform actions with the property

Issuer can be changed:
Outcome is only attacker has access (since assumption is attacker transfers ownership)

I haven't had time to reflect on this properly and I'm not sure which scenarios this would or would not help. Just thinking out loud...

[dexX7]

Might be the time to revive this topic, and maybe #293 as well, or rather more generally, a discussion about handling unlocked properties, in the context of:
mastercoin-MSC/mastercore#282: Restrict TX70 when a crowdsale is active.