changing supply of a currency

[zynis]

Requested by bitfinex

https://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/blob/master/5.Technology_Overview_and_Use_Cases.md#future-requirements

|Changing the amount of issued coins| do rolling issuance and destruction, meaning that when tokens are sent to the issuer for redemption they are retired/destroyed and the issuer can add more tokens to the issuance (requested by Bitfinex)|D|

[dacoinminster]

Next step: pull request on the spec. If somebody is working on this, please coordinate with me!

[Bitoy]

I'm not sure if this is what bifinex wants

Issuer creates an asset gold coin equivalent to 1000 msc (asset address) Issuer pre funds asset with 100,000 msc creating 100 gold coins with Sends dust to exodus and a sibling address Asset address is not allowed to send msc. it can sends gold coins

Issuer sends (from asset address) 30 gold coins to Alice issuer sends 70 coins to Ben

After sometime

Ben decides to redeem the gold coins. Ben sends 70 gold coins to asset address. System automatically send back 70,000 msc from asset address to Ben 70 gold coins are destroyed.

Issuer decides to add more gold coins. Sends 10,000 msc from sibling address to asset address. This creates additional 100 gold coins.

[zynis]

Use case is:

There is some bank account holding $1 Billion Dollars owned by FudCo.

FudCo creates 1 billion tokens, electronically representing $1 for each token. Exchange A and B have a contractual relationship with FudCo.

On Exchange A Alice sells 1 BTC for 1000 $1 tokens, Alice transfers 1000 $1 tokens to Exchange B using Master Protocol. On Exchange B Alice buys 1 BTC for $990 from Bob.

Alice then transfers 10 $1 tokens to Charlie. Charlie transfers these to his Omni wallet address.

Charlie goes to a Bitcoin ATM he cashes out $10.

FudCo needs to adjust the supply of $1 tokens to 999,999,990.

Now David goes to the ATM and deposits $10. FudCo needs to issue 10 more tokens and send them to David's BTC address.

Also there is this interesting use case on XCP where they need to create more supply of shares (not sure why exactly)

[dacoinminster]

OK, so let's imagine a new kind of asset issuance, where the issuer's address has an infinite balance, limited only by the highest number which can be represented in our system (64-bit unsigned integer for the number of Satoshis). Sends to that address of the asset effectively destroy them, since the address has infinite coins. Sends from the address increase the supply.

Only problem is security. If somebody EVER gets ahold of the private keys to that address, they can cause massive chaos, steal tons of money, and destroy the asset.

That's why I've always seen asset issuance as a one-time event, after which the private keys of the issuing address aren't critical to the continued use of the asset. But if lots of people want to do this, we can do it.

On Wed, May 21, 2014 at 6:05 PM, Dominik notifications@github.com wrote:

Use case is:

There is some bank account holding $1 Billion Dollars owned by FudCo.

FudCo creates 1 billion tokens, electronically representing $1 for each token. Exchange A and B have a contractual relationship with FudCo.

On Exchange A Alice sells 1 BTC for 1000 $1 tokens, Alice transfers 1000 $1 tokens to Exchange B using Master Protocol. On Exchange B Alice buys 1 BTC for $990 from Bob.

Alice then transfers 10 $1 tokens to Charlie. Charlie transfers these to his Omni wallet address.

Charlie goes to a Bitcoin ATM he cashes out $10.

FudCo needs to adjust the supply of $1 tokens to 999,999,990.

Now David goes to the ATM and deposits $10. FudCo needs to issue 10 more tokens and send them to David's BTC address.

Also there is this interesting use case on XCP where they need to create more supply of shares (not sure why exactly)

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/161#issuecomment-43836918 .

[zynis]

is it possible to use multisig input to do an asset issuance? and require m of n to change the supply?

we probably need a "freeze" or halt trading/sending command issuers could send that locks all the issued coins in place and that is not reversible

Thanks,

Dominik Zynis Skype: dominik.zynis USA: +1-415-800-4155 dominik.zynis@gmail.com

On Thu, May 22, 2014 at 8:27 PM, dacoinminster notifications@github.comwrote:

OK, so let's imagine a new kind of asset issuance, where the issuer's address has an infinite balance, limited only by the highest number which can be represented in our system (64-bit unsigned integer for the number of Satoshis). Sends to that address of the asset effectively destroy them, since the address has infinite coins. Sends from the address increase the supply.

Only problem is security. If somebody EVER gets ahold of the private keys to that address, they can cause massive chaos, steal tons of money, and destroy the asset.

That's why I've always seen asset issuance as a one-time event, after which the private keys of the issuing address aren't critical to the continued use of the asset. But if lots of people want to do this, we can do it.

On Wed, May 21, 2014 at 6:05 PM, Dominik notifications@github.com wrote:

Use case is:

There is some bank account holding $1 Billion Dollars owned by FudCo.

FudCo creates 1 billion tokens, electronically representing $1 for each token. Exchange A and B have a contractual relationship with FudCo.

On Exchange A Alice sells 1 BTC for 1000 $1 tokens, Alice transfers 1000 $1 tokens to Exchange B using Master Protocol. On Exchange B Alice buys 1 BTC for $990 from Bob.

Alice then transfers 10 $1 tokens to Charlie. Charlie transfers these to his Omni wallet address.

Charlie goes to a Bitcoin ATM he cashes out $10.

FudCo needs to adjust the supply of $1 tokens to 999,999,990.

Now David goes to the ATM and deposits $10. FudCo needs to issue 10 more tokens and send them to David's BTC address.

Also there is this interesting use case on XCP where they need to create more supply of shares (not sure why exactly)

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

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/161#issuecomment-43925684 .

[Bitoy]

Multi sig inputs are not currently allowed. (Sender can't be determined)

[zynis]

we have another group interested in this

[dexX7]

Hope you don't get me wrong, but check out how it's done in Counterparty: https://www.youtube.com/watch?v=eyzA5Lj1ajM

New units can be added, but at the same time the amount of outstanding units can be locked. Of course there should also be a way to remove tokens. (e.g. coupons which are redeemed)

[dacoinminster]

Hmmm. The ability to lock an inflationary asset would be useful. If you have the ability to transfer ownership, the UI can lock the asset by transferring ownership to 1FakeAddressForLockingAssets....

Since only the fake address could issue new tokens, there will never be any new tokens issued.

So, my proposal for flexible issuance is:

1) Allow unlimited sends from the issuing address (up to the maximum amount which can be represented: 184467440737.09551615 tokens) 2) Sends to the issuing address are "redemptions" 3) Add a command for transferring asset ownership, which also allows the asset to be locked as described above

How does that sound?

[dexX7]

1) I think even if new units can be created out of nowhere, it may be helpful to know the exact number of outstanding units. But I guess that's just a semi-problem and can be solved by simply moving the desired amount to a different address. What this doesn't tell: "how many units are issued at the very moment, but not yet distributed?" - in the case of moving them to another address, it would be required to announce this somewhere.

2) Sounds fine, but is there any reason to disallow any address to be defined as redemption address? Or use the issuer's address only as default?

3) Very, very awesome and clever idea, BUT this implies there are many BTC sends to a non-existent address which can never be redeemed -- massive bloat!

[dacoinminster]

Regarding 3, if we designate a single fake address for everybody to use, there will only be a single address of bloat.

[dacoinminster]

Regarding 2, the reason to not allow any address for redemptions is simply to keep complexity down. As long as when the asset ownership is transferred the redemption address changes to that new address, this should meet the requirements of 90% of issuers.

[dacoinminster]

Regarding 1, if the user wants a total number of assets issued but not distributed, they should use the protocol for creating a fixed number of tokens, rather than this rolling issuance model.

[dexX7]

Re 3:

It doesn't matter how many addresses are used -- the amount of unspent outputs is what matters. (!)

A workaround.. maybe.. is to use the Exodus address as "invalid address/new owner".

But I don't want to imagine what might happen, if the foundation looses control ... ;)

[dacoinminster]

I suppose if this feature went live after we switched over to P2SH, and we were encoding addresses in our data, then the UTXO problem would be fixed?

On Fri, May 23, 2014 at 4:31 PM, dexX7 notifications@github.com wrote:

Re 3:

It doesn't matter how many addresses are used -- the amount of unspent outputs is what matters. (!)

A workaround.. maybe.. is to use the Exodus address as "invalid address/new owner".

But I don't want to imagine what might happen, if the foundation looses control ... ;)

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/161#issuecomment-44070209 .

[zynis]

when i spoke about "lock" i meant that the coins cannot be moved from ALL of the btc addresses that they have been sent to.

not about ownership transfer of the issued currency.

it's more of a security breach nice to have.

[dexX7]

The "lock" was in response of the video I posted -- locking of creating new units.

[zynis]

ah thread hijacking :P

[dexX7]

No... :D We basically want both the same thing. :P

It's the complete package we discussed:

• An issuer can create a fixed amount of units (already possible)
• Tokens can be removed from the system (by sending them to a "redeem" address)
• Tokens can be added to the system ("token owner" issues new ones)

And as enhancement:

• Creation of new tokens can be freezed or locked
• Ownership of tokens can be transferred ("token owner" changes)