Issue additional units of an Asset

Question

In the answer to this question you stated that once an asset is issued, additional units cannot be issued at a later point in time, the reason given being:

"The problem with allowing additional asset units to be created in a subsequent transaction is the security - it could only work if those units were issued by the same private key. In that case you might as well just issue a much larger quantity in the first place…"

If this is the case, can you please consider allowing the private key that issued the initial tranche of assets to issue more of the same, essentially making it the issuing authority for that asset? Putting aside the risk of issuing a massive amount up-front and storing them in a cold wallet (just ask BTER), you are still stuck with a finite supply if you can't.

Answer 1

MultiChain 1.0 alpha 17, just released, provides this functionality.

Comments

Great news! Thanks very much for taking the suggestion onboard and incorporating it into the product.

Answer 2

Thanks, it's an understandable feature request.

But just so you understand the security aspect, allowing follow-on issues using the same private key gives you weaker protection than issuing a massive amount up-front and distributing it across multiple addresses, which could also use cold storage. This is because that private key can create an unlimited additional quantity of the asset if it's violated - much worse than just a very large quantity.

So it seems like the main consideration is simply that the asset should appear in the listassets API output with the correct quantity, rather than some arbitrarily large number. Is there any other reason why you'd not want to issue a large amount up front?

Comments

I've discussed this with the team at length and the issues we have with fixed asset allocations (with the "spare" assets in cold wallets) are:

1) The extra development required (cold wallet generators, interfaces to inject additional assets into circulation from a cold wallet, potential multi-sig requirements to protect assets in cold wallets from single users, etc)
2) Additional manual processes and staff training to move assets from cold storage into circulation.
3) Delays incurred in manually releasing additional assets into circulation
4) Finite asset pool (merging assets or migrating to a new asset when the pool runs dry are seen as being both undesirable and risky)
5) Risk of loss of assets in cold wallets due to human error / external influences
6) Risk of being unable to access cold wallets in a suitable timeframe owing to the availability of staff with cold wallet access/training (can be mitigated by giving more people access to the cold wallets, which in turn introduces further risk)
7) If each asset has a real-world value, the client has a significant liability tied up in the cold wallets. If this were to be compromised there is a significant real-world cost (the example being the MtGox bitcoins - they're hidden now, but one day someone's going to find a way to cash them in)

Keeping the spare assets in Hot wallets is seen as an unacceptable risk.

By allowing a MultiChain address to issue additional units of an asset that it originally issued, we can bypass all of these issues. The control system can automatically issue additional units of the asset as the pool runs low (24/7 with no delays), with speed-bumps in place to guard against fraud.

Yes, there is a known risk in allowing an address to generate additional assets, but this is deemed to be less of an issue than those listed above.

If you're not comfortable enabling this "across the board", then could it be system-configurable? If it had to be set in the genesis block then there'd be no way to change it later on. This way, people using MultiChain who preferred to issue a large asset pool up-front would be safe in the knowledge that the configuration switch couldn't be "flipped", allowing a hacker to issue additional assets in their system. Those who choose to allow additional assets to be issued would do so accepting the risk of the issuing authority's key being compromised. Default the flag value to false - this way the only systems that would allow additional assets to be issued would be those that were explicitly setup this way.

---

Thanks for your thoughtful response. What you're suggesting makes sense, a little like the allow-p2sh-outputs flag, in terms of a blockchain level permission. It can also have a per-issuance permission, that when an asset is issued you can choose whether follow-on issues are allowed or not.

---

Sounds good (especially setting the permission at the point of issuing the original assets - I'd not considered that).
I'd be grateful if you could keep me informed as to if/when this gets reviewed for possible inclusion on the enhancements list and if so, what version it gets planned for.
For our proof of concept we can get by with an up-front bulk issuance, but this is something we'd very much like to have in a production-ready system.

---

OK - noted. Your other option for now is to issue multiple assets, and then on the user interface level, merge their values into one. But I can see how that would also be a pain!

---

I would like to add that being capable of extending an existing asset is something we would be in favor of in our current experiment. So if possible, it would be highly appreciated if included in a future version of multichain.

---

Any news on this request? Is it something being considered / planned for a future release? If so, I'd be grateful if you could share a timeline

---

It is certainly on the roadmap, but there are a few more burning things that need to be done first. My best estimate is we'll get to this a few months from now, but I don't want to express this as a formal commitment.

---

Multi/Chain 1.0 alpha 17, just released, provides this functionality.

---

Hi,

Looks there is some problem I could not create the assets with open option.

bc1@host1:~$ m getaddresses
{"method":"getaddresses","params":[],"id":1,"chain_name":"ms"}

[
    "1KCnJoTMc35JCpCnD25ZFNw9SYvAmU1r7kMrx7"
]
bc1@host1:~$ m issue "1KCnJoTMc35JCpCnD25ZFNw9SYvAmU1r7kMrx7" {"name":"coin2","open":true} 100 0.01
error: Error parsing JSON:open:true
bc1@host1:~$ m -version

MultiChain Core RPC client build 1.0 alpha 17 protocol 10004

bc1@host1:~$

---

You need to put JSON parameters in single quotes - this is a shell issue rather than specific to MultiChain.

---

Hi,
I am sorry it is my mistake. yes it is working fine.
Thanks & Regards,
ShenthilkumarCK