What is the motivation for someone to create a user currency and escrow?

[ripper234]

I'd like to understand this real carefully now.

Using MasterCoin, I can create escrow-backed GoldCoins.

E.g. suppose I choose an escrow of 100 MasterCoins.

1. What do I get in exchange for my 100 MSC? What incentive do I have to "sacrifice" my 100 MSC for "the good of GoldCoins"
   
2. I suppose that I don't get any specific amount of GoldCoins by creating them, but rather must buy them from the escrow fund. Is this correct?
3. The escrow fund is supposed to make a profit (buy low, sell high). Does the creator of the escrow fund enjoy that profit in any way?

[jr.wi...@gmail.com]

On Sunday, August 18, 2013 11:53:58 PM UTC-7, ripper234 wrote:
> I'd like to understand this real carefully now.
> Using MasterCoin, I can create escrow-backed GoldCoins.
> E.g. suppose I choose an escrow of 100 MasterCoins.
>
>
> What do I get in exchange for my 100 MSC? What incentive do I have to "sacrifice" my 100 MSC for "the good of GoldCoins"

> I suppose that I don't get any specific amount of GoldCoins by creating them, but rather must buy them from the escrow fund. Is this correct?The escrow fund is supposed to make a profit (buy low, sell high). Does the creator of the escrow fund enjoy that profit in any way?

The current model only gets money into escrow when people purchase GoldCoins (their money goes into the escrow fund), however, I am considering providing some incentives for currency creators to put some money straight into the escrow fund at the time of creation, as you say, "for the good of GoldCoins". The incentive would probably be in the form of receiving "overflow" if the escrow fund gets massively overfunded.

However, even if I do something like that, it will probably be optional.
3)

[Ron Gross]

Ah I see. So as creator of GoldCoins, right now I just pays the minimal protocol fee and determine the escrow parameters.

I do think there should be a way for coin creators to invest in their creation and profit from it. Otherwise we'll just see a flux of almost indistinguishable clones of each FooCoin, where each of them is just a minor variation. True, network effects will probably lead the market towards the FooCoin with the largest escrow fund (within certain parameters), but this just creates a situation where he first one of the market wins, and doesn't give the coin creators any incentive to try and create healthy coins with healthy parameters to begin with.

How about allowing coin creators to lend money to the escrow fund with a preset interest rate? When creating GoldCoins backed by MasterCoins, you would lend X MSC to the escrow fund, and get a total of Y MSC back over a period of Z years. This is advantages in:

1. Distinguishing between coins that someone actually backs from inception, and just "spamcoins" cheaply created without any initial backing.
   
2. Providing incentive for coin creators to carefully think and model the economic parameters in order to create a long-term healthy coin

Of course, the initial loan can only be repaid if the escrow fund is profitable. It is plausible that an actively traded coin will make some profit, although it might be that the market will almost always trade before the escrow fund does, and so the fund won't make significant profit. Another (possibly equivalent?) alternative is for the loan to be repaid in terms of the new currency. So, the currency creators permanently invests X MSC to the escrow fund, and gets a total of Y GoldCoins back over a period of Z years (perhaps with various inflation schedules such as Bitcoin's exponentially decaying inflation). In this formalization of the loan, the fund is guaranteed to always have enough GoldCoins to pay the creator, because it can create GoldCoins out of thin air. The coin creator has to be careful not to program the escrow to gift him with too many coins, because it will devalue the currency ... but it is a way for him to get compensated for the initial funding that made the fund's launch more stable.

Heh, this is kind of similar to how MasterCoins are created. In fact ... hmm, you could allow the user-created currencies to be created in exactly the same way MasterCoin was.

Let the new currency creator designate:

1. The start and end date of the fund-raiser
2. The type of currencies the escrow fund deals with (one existing currency and one new one)
3. A decreasing bonus for early adopters over the fund-raiser period
4. A delay, after which the fund starts paying the early adopters.

During the fund-raiser period, the fund is actually bonds of GoldCoins and not GoldCoins. These bond mature at a specified date in the future. Bonds of GoldCoins are worth less than GoldCoins (money now is always better than money in the future). The bonds can also be traded as separate objects.

The escrow fund now sells these bonds from the start, and it can always cover them because it can print GoldCoins from thin air. The trick would be how to tune the parameters ... if the fund is too aggressive (sets a very high discount for early investment in the bonds), the fund will not be sustainable and the actual GoldCoins will devalue / the bubble will burst. If there is only a very modest reward for early investment, and the bonds' maturation is set far enough into the future, this would be an excellent way for the fund to kickstart and build a solid reserve of MasterCoins.

While all this is nice in theory and I like the concept of adding bonds to MasterCoin, I'm concerned whether it can ever be sustainable under any set of parameters. I am quite conflicted and don't have a clear intuition on whether this is a brilliant or terrible idea. I would love to see us try to implement it though, and find out :)

MasterCoin code should be made simple and modular enough to allow all kinds of such experiments. Even if the first version doesn't contain advanced features, implementing the above doesn't sound too difficult given a good infrastructure, and I'd like MasterCoin's development to be open to incorporating various advanced featured as optional protocol features.

Ron Gross

Co-Founder & CEO @ bitBlu

bitblu.com    |    ripper234.com

Schedule my time at meetme.so/RonGross

--
You received this message because you are subscribed to the Google Groups "MasterCoin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mastercoin+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[J.R. Willett]

I think maybe we are kindred spirits :)

I completely agree with a heavy emphasis on modularity and experimentation. There's really no way to know which features will be the biggest winners, and I want to create simple tools for anybody to use to find out.

I'm not sure I completely understand the bonds idea, but it sounds a lot like the GoldCoins/GoldShares I had in the first version of my paper. I discarded that idea as too complicated and possibly not as good at keeping the escrow fund healthy, although I'd still love to see somebody try it. It was a lot more geared toward rewarding the currency creator, but it was really hard to explain to people :)

As you mentioned in your post on the Google Group, it's going to be tough to coordinate the "official" version if people are working on a bunch of incompatible feature sets. Hopefully everybody will experiment using Test MasterCoins then we will pull in the coolest features for everyone to use.

[Ron Gross]

:)

The idea with bonds is that they mature. An escrow fund can sell bonds at the time of its bootstrapping, but the bonds automatically convert into actual gold coins at some predetermined date in the future (I think the GoldShares proposal didn't have this maturation feature). For now I'm just throwing the idea out there, perhaps I'll come back to it in the future and see what can be made out of it.

Features are distinct, not necessarily "incompatible". Whatever features are added to core MasterCoin, even if they don't necessarily work together (e.g. betting and bonds don't have to interact), are ok. There has to be an agreement among MasterCoin users about which features are considered "MasterCoin". This goes for Test MasterCoins as well - Test MSC will only work with "the official version of the Test MasterCoin client".

It's vital that the risk of merging a pull request is isolated. You'll want to ensure that if someone is developing a module that implement CoolFeatureX, he'll be able to submit pull requests that only touch that code, and you'll have an easy way to verify that his changes don't impact the rest of the MasterCoin protocol. This will enable 3rd party feature developers to make quick progress on their features without endengarign core MasterCoin or other 3rd party features.

(I define a "3rd party feature" as a feature that someone else is leading the development of).

In fact, perhaps the core client should contain a plugin system. People would be able to "register" a plugin, and afterward work on their features in completely separate git repositories ... you won't have to be a bottleneck to such development, and they won't be able to risk anyone who doesn't opt in to install their plugin. The only thing they'll need from you is a common set of identifiers for their feature (e.g. what "object ID" is a bond).

I'll give another example - one thing that I imagine is that mathematical functions will be useful in various MasterCoin applications. E.g. perhaps in the above scenario you'd want to use something other than a linear bonus for early adopters of the bonds ... perhaps give a quadruple bonus or another mathematical function. An interesting module would build a few such core mathematical functions that can then be used in various places in the MasterCoin protocol. Now, it's likely that this is complete overkill and not needed in core MasterCoin, but if someone registered a "Math function ID" from you (custodian of core MasterCoin), he can then implement his module "on the side", and his innovation (and risk) will only be born by those who opt in to use the "Math function module" (for those who don't install this module ... such functions would be unparsable, and such coins would be unspendable until they install this module).

Ron Gross

Co-Founder & CEO @ bitBlu

bitblu.com    |    ripper234.com

Schedule my time at meetme.so/RonGross

[J.R. Willett]

Oooo. I LOVE this. I've been pondering these exact issues for awhile - trying to decide how to allow people to work on cool new features while still keeping some level of cross compatibility.

It should be fairly straightforward to mark a set of coins as needing a specific module to process and spend. The problems I keep running into are:

• Once you've got coins which have processed some new rules, they can never go back (at least, I can't think of a way)
  
• Consequently, if someone is using some new rules which fall out of favor, those coins are "stranded"

For instance, if somebody publishes a Betting 2.0 module, and a bunch of people start using it, those coins could become worthless if the competing "Betting Plus" module becomes dominant and is incompatible with the Betting 2.0 module

That is why I have (so far) favored having people run feature experiments with throwaway Test MasterCoins, then pulling the coolest features in.

Expanding on your math idea, a scripting language built in to MasterCoin might help people develop features without introducing incompatibilities, but that could be a can of worms too since everybody would have to execute every crazy script people tried, and that processing cost could build up quickly!

[Ron Gross]

The issue is not just about modules coming into and out of fashion.

Suppose that a friend of mine and myself are using Betting 2.0 module, but you are not. The friend and me enter into a wager, and I win, thus earning some coins.

Now, I'd like to send these coins to you, who aren't currently using Betting 2.0 module.

The core client should be able to recognize the "exit" of the coins from the Betting 2.0 plugin domain and into core mastercoin space ... which is probablly impossible without running Betting 2.0 yourself.

Hmm.

What do your thoughts about posting a bounty about designing a proper plugin system to work around these issues?

I don't know if it can be done, but if it can, and someone presents a working design, isn't he entitled to some MSC?

Ron Gross

Co-Founder & CEO @ bitBlu

bitblu.com    |    ripper234.com

Schedule my time at meetme.so/RonGross

[J.R. Willett]

If someone could just prove it could be done, it seems that would be worth a bounty. I personally don't think it is possible, but I'd love to be proven wrong!

[Ron Gross]

Yeah, depending how we define the scope of the problem.

i don't want people suggesting trivial/uninteresting module systems that don't solve the real problems.

I think the above use case (Betting 2.0) is pretty good - if someone can prove it can be done (by explaining an high level design, no?), he deserves a bounty.

Ron Gross

Co-Founder & CEO @ bitBlu

bitblu.com    |    ripper234.com

Schedule my time at meetme.so/RonGross

[J.R. Willett]

I would agree with that, and would also agree that announcing a bounty would produce a lot of unworkable "solutions" and would start a lot of arguments with people demanding that I prove their solution wouldn't work. I'm still having nightmares about all those arguments with bytemaster :)