New transaction types - create more coins and destroy/burn coins

[ripper234]

Suppose someone created new coins with a tx 50 or some other method.

Now, they want to create more coins that are identical to these coins. There are multiple use cases for this, e.g. USDCoins. Specifically, I just talked to the RideShare/Zuz team today and this is a requirement from their part.

A workaround that is possible today is for them to create a huge amount of coins initially, keep these at a separate address, and then move from that address to their operational address. However, in my mind that is just that - a workaround. I prefer it that we actually create a new transaction type that creates more coins.

Such a transaction would only be legal from the private key/address that originally created the coins.

[CraigSellars]

Cross-posted from Issue #181 -

The prior discussion I had with JR was instead of a new transaction type, a new flag would be added to tx50 which would direct the implementations to either display (or not display) the number of coins held in the creator’s address. In this way, to create a coin, the issuer would send from their address, and to destroy a coin, a coin would be sent back to the issuer’s address.

[ripper234]

Yeah I remember that discussion. I didn't really understand why that is a cleaner solution that just changing the spec and Master Core to support create & burn ... it seems a lot cleaner to me.

@CraigSellars / @dacoinminster , can you explain the reasoning of why this direction was chosen?

For me the whole issue of having "coins that should not displayed" creates far more confusion that is needed.

[CraigSellars]

For starters, it makes us begin to think about transaction types as things that can evolve over time, and not just “make a new transaction type for this issue and we’ll just make a new one if we want to change something.” It imposes some level of discipline before we end up with 100’s of transaction types, many of which will be the same as others with only one small change.

In terms of cleaner, it will be much easier to code (which means we can have it sooner) as a display variable in tx50 than creating entirely new logic for create/destroy, while having the same visual end-result.

[ripper234]

Well, I'm all for evolving transaction types when it makes sense, I just argue that in this case it doesn't (to me).

Also I challenge the assertion that it will easier to code. @zathras-crypto, @m21, @msgilligan can you comment on this?

[dacoinminster]

I suggested that method as a very minor protocol change to make the workaround easier to use for very near-term projects who want to do this right now. If the UI is done properly, the back-end machinations of the workaround can be made completely transparent to the user, whereas the other ways of doing this are a significantly bigger chunk of work.

However, if this does prove cumbersome to users, I'm not opposed to a protocol change. Also, there may be OTHER advantages to ongoing issuance in the protocol which this kind of workaround won't support.

[zathras-crypto]

Well coding simplicity then yes a TX50 modification is the easiest to achieve, but I disagree that it's the right way to go simply because anything we try to 'hide' at the UI layer is only applicable to implementations we control - there is nothing to stop someone spinning up a website to allow you to view data that's publicly available on the blockchain but that we've decided to hide in the reference UI.

[ripper234]

Yeah, I argue that people will make these kinds of mistakes..., and so I prefer to explicitly mark these coins as 'destroyed' or 'freshly minted'.

Do we have consensus that adding explicit issue and destroy operations (basically this issue and #181) are the right way to go? If we are not in consensus, who currently disagrees?

[CraigSellars]

I also don’t think this is the best long-term means of handling creation/destruction of tokens, but I do believe it satisfies the short-term goals of upcoming fiat-issuance tokens where the amount of tokens "sent out" needs to be tracked as a separate number for audit purposes.

[ripper234]

The question is, what is the cost of the two alternatives. My estimate is a rather low difference in cost of implementation. On Jun 3, 2014 7:01 PM, "CraigSellars" notifications@github.com wrote:

I also don’t think this is the best long-term means of handling creation/destruction of tokens, but I do believe it satisfies the short-term goals of upcoming fiat-issuance tokens where the amount of tokens "sent out" needs to be tracked as a separate number for audit purposes.

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

[CraigSellars]

One version is a flag that says to the UI: "display the total number of tokens as the total number that are not sitting in the issuer's address”.

The other version implies coming up with multiple new transaction types, rules to be decided upon for who has the rights to issue versus destroy, which coins can be destroyed, under which conditions can new tokens be issued on top of others… etc. (The kinds of things that if done wrong early, will be difficult to correct later.)

[ripper234]

Well ...

1. Only the private key that created a currency can issue more coins.
2. Everybody who owns a token can destroy it.
3. New tokens can be destroyed only if a flag named "canIssueMore" was given on the initial coin creation (default = zero)
4. I really think this is the right way to go going forward...

@zathras-crypto can I interpret your comment as an agreement with me?

[ripper234]

Updated the topic to include coin destruction.

[dacoinminster]

I agree this would be useful, but disagree about the priority, There are a lot of other features I would like to see before this one.

On Wed, Jun 4, 2014 at 12:41 PM, Ron Gross notifications@github.com wrote:

Well ...

1. Only the private key that created a currency can issue more coins.
2. Everybody who owns a token can destroy it.
3. New tokens can be destroyed only if a flag named "canIssueMore" was given on the initial coin creation (default = zero)
4. I really think this is the right way to go going forward...

@zathras-crypto https://github.com/zathras-crypto can I interpret your comment as an agreement with me?

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

[zynis]

just to point out that the fiatcoin issuers need this feature, one of them is shooting for next week to make an announcement

Thanks,

Dominik Zynis Head of Business Development Mastercoin Foundation Mastercoin.org http://mastercoin.org/ dom@mastercoin.org +1-415-800-4155 +34-697-41-22-01 dominik.zynis (skype)

Assistant: Joanne joannemtria@gmail.com

On Fri, Jun 6, 2014 at 1:24 AM, dacoinminster notifications@github.com wrote:

I agree this would be useful, but disagree about the priority, There are a lot of other features I would like to see before this one.

On Wed, Jun 4, 2014 at 12:41 PM, Ron Gross notifications@github.com wrote:

Well ...

1. Only the private key that created a currency can issue more coins.
2. Everybody who owns a token can destroy it.
3. New tokens can be destroyed only if a flag named "canIssueMore" was given on the initial coin creation (default = zero)
4. I really think this is the right way to go going forward...

@zathras-crypto https://github.com/zathras-crypto can I interpret your comment as an agreement with me?

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

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

[ripper234]

Well, I doubt this will come next week. Can the fiat coin issuers work with our proposed workarounds?

On Fri, Jun 6, 2014 at 4:38 PM, Dominik notifications@github.com wrote:

just to point out that the fiatcoin issuers need this feature, one of them is shooting for next week to make an announcement

Thanks,

Dominik Zynis Head of Business Development Mastercoin Foundation Mastercoin.org http://mastercoin.org/ dom@mastercoin.org +1-415-800-4155 +34-697-41-22-01 dominik.zynis (skype)

Assistant: Joanne joannemtria@gmail.com

On Fri, Jun 6, 2014 at 1:24 AM, dacoinminster notifications@github.com wrote:

I agree this would be useful, but disagree about the priority, There are a lot of other features I would like to see before this one.

On Wed, Jun 4, 2014 at 12:41 PM, Ron Gross notifications@github.com wrote:

Well ...

1. Only the private key that created a currency can issue more coins.
2. Everybody who owns a token can destroy it.
3. New tokens can be destroyed only if a flag named "canIssueMore" was given on the initial coin creation (default = zero)
4. I really think this is the right way to go going forward...

@zathras-crypto https://github.com/zathras-crypto can I interpret your comment as an agreement with me?

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

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

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

Ron Gross Executive Director, Mastercoin Foundation mastercoin.org | ripper234.com | ripper234 on skype (Inbox != Zero http://ripper234.com/p/how-i-learned-to-let-go-of-inbox-zero/) | PGP http://pgp.mit.edu/pks/lookup?op=vindex&search=0x7468729E28277264 Schedule my time at meetme.so/RonGross

[ripper234]

It seems the technical workaround we implement (hiding the balance of the issuance address) doesn't hold water, because of hot/cold water issues ... see the description of this issue on Master Core opened by Lazooz.