OmniLayer / spec

Omni Protocol Specification (formerly Mastercoin)
The Unlicense
341 stars 118 forks source link

Change of issuer: locked for old properties? #293

Open dexX7 opened 9 years ago

dexX7 commented 9 years ago

With #257 it is possible to change the issuer or maintainer of a property, however it is currently undefined, if this ability is only granted for managed properties or all properties, including those that were not created via tx 54: New Property with Managed Number of Tokens.

So the question is: should it be restricted to managed properties or available for every property?

dacoinminster commented 9 years ago

The "issuer" has no special privileges for non-managed properties currently, but that may not always be true.

I'd suggest this change should be usable with any property, even though it currently only has an effect for managed properties.

dacoinminster commented 9 years ago

p.s. clarifying pull request welcome :)

dexX7 commented 9 years ago

Actually it's the other way around and right now there no check in place to restrict a change of issuer for "old" properties (created with tx 50, tx 51).

Because one might say this is a retroactive change, I think it's worth to discuss, if this is correct behavior.

The security aspect is two sided, and this is addressed @ #294 as well: there is a benefit, if there is the ability to transfer ownership, even in restrospective, but on the other hand: if a key got compromised and an asset was locked right from the beginning, there is no risk to begin with.

dacoinminster commented 9 years ago

I think this is correct behavior. Transferring ownership for a TX50 or TX51 coin currently does not allow the attacker to do ANYTHING.

If private key is compromised for a managed property, the attacker can ALREADY do bad things (e.g. issue new coins). Transferring ownership to another address doesn't really help the attacker that I can see . . .

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

Actually it's the other way around and right now there no check in place to restrict a change of issuer for "old" properties (created with tx 50, tx 51).

Because one might say this is a retroactive change, I think it's worth to discuss, if this is correct behavior.

The security aspect is two sided, and this is addressed @ #294 https://github.com/mastercoin-MSC/spec/issues/294 as well: there is a benefit, if there is the ability to transfer ownership, even in restrospective, but on the other hand: if a key got compromised and an asset was locked right from the beginning, there is no risk to begin with.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/293#issuecomment-66319444.

dexX7 commented 9 years ago

... does not allow the attacker to do ANYTHING.

Oh well, that's actually right. :)

The only case that I'm not able to predict at the moment is a transfer of ownership during an ongoing crowdsale, but if I recall correctly, then it shouldn't have an effect.

zathras-crypto commented 9 years ago

Great point @DexX, we'd have to model what the behaviour would be if the issuer was changed mid-crowdsale but I think we should restrict this anyway

On Wed, Dec 10, 2014 at 6:31 AM, dexX7 notifications@github.com wrote:

... does not allow the attacker to do ANYTHING.

Oh well, that's actually right. :)

The only case that I'm not able to predict at the moment is a transfer of ownership during an ongoing crowdsale, but if I recall correctly, then it shouldn't have an effect.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/293#issuecomment-66342217.

dexX7 commented 9 years ago

Meh, ... the behavior is not transparent for the end user at the moment.

So it's a bit mixed at the moment and the RPC interface does not reflect the actual token movements.

I tend to lock tx 50, tx 51 per default and allow ownership changes only for managed properties, in particular to respect history, so to speak, and to avoid behavior as described - at least for now. My other thread about "locking" properties probably already hints I'm not against the idea of stateful properties and the topic in general. ;)

dexX7 commented 9 years ago

Quick note to catch up on this, given that a change of issuer during a crowdsale is deactivated now, there is actually an use case in combination with #282 (Accepting not-yet-issued propeties in a crowdsale).

282 allows to create a trustless token swap mechanism, where:

There is, however, still some risk involved, namely that a crowdsale issuer may manually close a crowdsale.

If changing the issuer during a crowdsale were enabled, it would be possible to willingly give up any control by changing the issuer to an address that (likely) no one controls, which would remove that risk completely.