Allow fundraiser to accept BTC only, or some combination of BTC/MSC

[ripper234]

Clarification - this is a proposal in discussion. We will discuss and hash this out before reaching a decision. Edit - instead of the direction originally proposed here, and alternative suggestion is to just drop the restriction in the protocol and allow BTC as the single currency a fundraiser accepts. This change is even simpler that the original proposal, and is sufficient for the time being.

I believe it is essential we give everyone creating a fundraiser the option to manually choose the currencies they prefer, including the option to exclude MSC and only accept BTC. My rational is that MSC is still a very volatile currency, and a lot of users will simply not use the Master Protocol unless we give them absolute certainty that they can raise funds without getting any MSC.

This is something that can be simulated today, either manually, or with scripts. You can create all units of your smart property beforehand, setup a website and put up a BTC address, and then distribute these tokens to everyone who sent in BTC payments. I want to make life as easy as possible on every user of Mastercoin. Whenever something can be done as a manual/scripted operation, and is desirable by our users ... I would vote to include that into the core protocol itself if feasible.

So, my suggestion:

When a fundraiser is created, the user can declare independently:

1. How many tokens are generated per MSC sent (including 0 as a valid option).
2. How many tokens are generated per BTC sent (including 0 as a valid option).

As a reference material I would like to present:

1. The MaidSafe retrospective, which details some of the problems MaidSafe had with the conversion process from BTC to MSC.
2. Other companies we are discussing with, who are going to issue their tokens on the Master Protocol, and manually sell them for BTC. Such companies would definitely enjoy and have less hassle if the protocol supported BTC fundraisers internally.

While this change could reduce the short term utility of MSC, I believe it will be a powerful driver of our ecosystem as it will enable more companies to issue tokens in a more stable manner. With the upcoming Metacoin DEx, betting, and other use-cases of mastercoins, I believe we will find our monitization model - but it should not be based on purposely denying users something that can easily be allowed, protocol wise.

[jkandah]

I think this is absolutely a requirement for this type of feature going forward.

[dacoinminster]

On a technical level, I suggested to Ron that we could rev the fundraiser command in the protocol to add a parameter for # coins per BTC in addition to # coins per MSC.

This is a pretty simple change, but basically opens the door to issuers choosing how much they want in BTC or MSC.

The decision here is whether it is better for MSC holders to require MSC to be used in fundraisers, or if it is better to grow our user base as quickly as possible. Ron is thinking the latter is best, and I'm starting to lean that way too.

I want to emphasize that growing the value of MSC is the ONLY yardstick we use when making decisions like this.

[CraigSellars]

More simply: allow BTC as the desired currency. We can make it more complex later.

[DavidAJohnston]

I agree with Craig. Lets keep the solution very simple here. Enable BTC as a desired currency for the crowdsale. I was skeptical of this for a while, but thinking through it fully I don't think we want to create barriers for adoption when it comes to the Master Protocol and requiring the use of MSC in this particular feature isn't compelling for a technical reason. (In comparison the use of MSC for example is technically compelling in the Decentralized Exchange feature).

[ripper234]

I'm completely fine with just enabling BTC as a supported currency.

[dacoinminster]

So, David Johnston and I just spoke about this. We need fundraisers to be able to do dual currencies (BTC/MSC, for instance) otherwise we end up with multiple tokens (one from a BTC fundraiser and one from a MSC fundraiser).

I think the original proposal to just add a bitcoin exchange rate field to the fundraiser command is actually the best. It still allows bitcoin-only fundraisers for people who want them, but does not exclude dual-currency fundraisers.

[jkandah]

How would this be managed for setting prices. Would you set a btc price and an msc price? Or set one? If you set both then there should be some amount of arbitrage at current volumes and lead to maidsafe like issues— Sent from a mobile device

On Tue, May 6, 2014 at 5:08 PM, dacoinminster notifications@github.com wrote:

So, David Johnston and I just spoke about this. We need fundraisers to be able to do dual currencies (BTC/MSC, for instance) otherwise we end up with multiple tokens (one from a BTC fundraiser and one from a MSC fundraiser).

I think the original proposal to just add a bitcoin exchange rate field to the fundraiser command is actually the best. It still allows bitcoin-only fundraisers for people who want them, but does not exclude dual-currency fundraisers.

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

[dacoinminster]

That would be up to the issuer. They can accept BTC, MSC, or both. If both, they won't be like Maidsafe, because bitcoin investments will be processed instantly. They will still have to decide what value to place on each token. If that value is way different than the current market, and the fundraiser is huge, that could bounce prices around (like with Maidsafe), but that is up to the issuer.

Note that issuers can ALREADY do all this, and are doing so (using scripts, borrowed MSC, etc). We are just contemplating building it into the protocol so that we get more issuers.

On Tue, May 6, 2014 at 3:30 PM, Jeremy Kandah notifications@github.comwrote:

How would this be managed for setting prices. Would you set a btc price and an msc price? Or set one? If you set both then there should be some amount of arbitrage at current volumes and lead to maidsafe like issues— Sent from a mobile device

On Tue, May 6, 2014 at 5:08 PM, dacoinminster notifications@github.com wrote:

So, David Johnston and I just spoke about this. We need fundraisers to be able to do dual currencies (BTC/MSC, for instance) otherwise we end up with multiple tokens (one from a BTC fundraiser and one from a MSC fundraiser). I think the original proposal to just add a bitcoin exchange rate field to the fundraiser command is actually the best. It still allows bitcoin-only fundraisers for people who want them, but does not exclude

dual-currency fundraisers.

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

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

[dexX7]

Just to throw this in: crowdsales are just "sell a token" type transactions, too and I'm wondering, if it may be possible to use atomic transactions instead of creating many crowdsale transaction types which are quite specific? E.g. one could create the tokens beforehand and then sell them for whatever token or price one can imagine - or say for example I create one crowdsale for token X which can be bought with token Y. At the same time I create more than one sell offer for Y in different token currencies.

[dacoinminster]

Yeah, the spec already has a transaction to create a set of properties upfront, which the user could then sell using whatever method they like. :)

On Tue, May 6, 2014 at 3:55 PM, dexX7 notifications@github.com wrote:

Just to throw this in: crowdsales are just "sell a token" type transactions, too and I'm wondering, if it may be possible to use atomic transactions instead of creating many crowdsale transaction types which are quite specific? E.g. one could create the tokens beforehand and then sell them for whatever token or price one can imagine - or say for example I create one crowdsale for token X which can be bought with token Y. At the same time I create more than one sell offer for Y in different token currencies. Sorry, I'm a bit vague, because I'm not yet sure what I'm really thinking about, but the basic idea: use several transactions in combination to yield the desired set of properties.

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

[DavidAJohnston]

Jeremy, The choice of setting prices or running a duel token offering would be left to the end user issuing the token rather than forcing that choice for people in the protocol level.

[jkandah]

Understood. But which way does it work or both?

Option 1: Set BTC rate and MSC rate Option 2: Set BTC rate and MSC rate floats relative (or the opposite way)

Option 1 could lead to issues if the exchange rate fluctuates Option 2 could lead to issues as you would need a trusted data source

If Option 1 is used then the question might be, will you be able to change rates overtime based on information. Such that if an issuance lasts 30 days and the exchange rate changes dramatically are you able to change the issuance amount as that may be desirable.

Finally, I would assume that there would be some kind of capping function that would apply to each currency individually. Such that if I only want to accept 10% of either currency (or a specific number of units) I could set that.

On Tue, May 6, 2014 at 10:04 PM, David Johnston notifications@github.comwrote:

Jeremy, The choice of setting prices or running a duel token offering would be left to the end user issuing the token rather than forcing that choice for people in the protocol level.

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

Jeremy Kandah (e) jkandah@gmail.com (c) 248-921-4502

[Bitoy]

I think it is up to the issuer to set the ' number of coins per btc ' or ' no of coins per msc' (not price) Ex.
'number of coins per btc '= 17,000 'number of coins per msc'= 3,400

If a buyer send 1 btc he gets 17,000 coins If a buyer sends 1 msc he gets 3,400 coins

[Bitoy]

For the capping function 2 new fields can be added.

'Total number of coins' = 2,000,000 'Percent btc' = 80 (80% of the coins must be paid by btc, 20% in msc)

If the allocation for bitcoin is filled, no more btc investment will be accepted. Investor has to buy at dexx. This will create a demand for msc.

If the allocation for msc is filled, no more msc investment will be accepted. This gives the issuer more liquidity as investor can now only buy coins using btc.

[dacoinminster]

Interesting idea Bitoy. So in summary, the fields added would be:

1) Coins issued per BTC 2) Total # of coins to issue 3) % reserved for BTC

I think this will be a big improvement, and will push adoption of our protocol forward a lot. Especially if we can get our web and desktop wallets to do the issuances :)

[jkandah]

So what if u want to be flexible like I want no more than x% of a certain coin I could say 60% of either. That way the mix is still flexible. So you could say 100% for both and accept everything until sold out. 

This might assume a limited initial supply. How would this work if it were not limited? Could it maintain a Min ratio or max ratio? — Sent from a mobile device

On Wed, May 7, 2014 at 1:52 PM, dacoinminster notifications@github.com wrote:

Interesting idea Bitoy. So in summary, the fields added would be: 1) Coins issued per BTC 2) Total # of coins to issue 3) % reserved for BTC

I think this will be a big improvement, and will push adoption of our protocol forward a lot. Especially if we can get our web and desktop wallets to do the issuances :)

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

[dacoinminster]

We could, but the complexity of implementation would be a bit higher.

Enforcing a ratio on an open-ended fundraiser would be REALLY tricky. For instance, if a bunch of one currency comes in, it might at first appear to be partially invalid, and then later be completely valid once the ratio balances out.

I think the easiest thing to do is to disable % BTC for open-ended fundraisers. I don't want to open that can of worms!

[dacoinminster]

So now the proposal of fields to add is:

1) Coins issued per BTC 2) Total # of coins to issue (0 = no cap) 3) % reserved for BTC (only valid when there is a cap on total coins)

[marv-engine]

Some details to be dealt with:

1. Specifying a limit on number of coins issued (total, % reserved for BTC and implied % available for MSC-based currency) requires some mechanism to handle purchases that hit one of the limits and can be honored only partially. What happens to the excess funds that were sent, and is this done automatically or manually?
2. What happens to attempted purchases that arrive after the corresponding limit is reached? Currently, the spec says "If the transaction is confirmed after the crowdsale is closed or if for any other reason no crowdsale is active, no purchase will be made and no tokens will be credited to the sending address, but the Simple Send itself will complete." That can be pretty harsh for a user who innocently saw that a crowdsale was active and got shut out for reasons beyond his control and prior knowledge. If sad tales of money lost start to spread, investors may become gun shy.
3. All implementations will have to handle rounding and truncating of the number of tokens issued exactly the same way and calculate exactly the same number of tokens issued and remaining.
4. I think the early bird bonus interacts with the % reserved for BTC, but I haven't thought it through. Earlier purchases will take larger chunks of the limited number of coins to be issued. It seems that can throw off (reduce?) the number of BTC ultimately raised.

[dacoinminster]

1. Yes, the last investor will probably get a partial fill. Refunds are manual for now
2. Don't invest in untrustworthy crowdsales. Trustworthy issuers will refund in cases like this
3. Yes
4. Yes

thanks

On Wed, May 7, 2014 at 2:43 PM, Marv Schneider notifications@github.comwrote:

Some details to be dealt with:

1. Specifying a limit on number of coins issued (total, % reserved for BTC and implied % available for MSC-based currency) requires some mechanism to handle purchases that hit one of the limits and can be honored only partially. What happens to the excess funds that were sent, and is this done automatically or manually?
2. What happens to attempted purchases that arrive after the corresponding limit is reached? Currently, the spec says "If the transaction is confirmed after the crowdsale is closed or if for any other reason no crowdsale is active, no purchase will be made and no tokens will be credited to the sending address, but the Simple Send itself will complete." That can be pretty harsh for a user who innocently saw that a crowdsale was active and got shut out for reasons beyond his control and prior knowledge. If sad tales of money lost start to spread, investors may become gun shy.
3. All implementations will have to handle rounding and truncating of the number of tokens issued exactly the same way and calculate exactly the same number of tokens issued and remaining.
4. I think the early bird bonus interacts with the % reserved for BTC, but I haven't thought it through. Earlier purchases will take larger chunks of the limited number of coins to be issued. It seems that can throw off (reduce?) the number of BTC ultimately raised.

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

[Bitoy]

1. If the msc quota is filled and the fundraiser is still open, the msc simple sends to the fundraiser is invalid (This is like an automatic refund).

The last one will get a partial fill.

2 msc or btc sent after the fund is closed can be manually refunded by the issuer.

Note: this will not affect maidsafe. This auto refund will work only if 'total number of coins' > 0

On May 8, 2014 6:13 AM, "dacoinminster" notifications@github.com wrote:

1. Yes, the last investor will probably get a partial fill. Refunds are manual for now
2. Don't invest in untrustworthy crowdsales. Trustworthy issuers will refund in cases like this
3. Yes
4. Yes

thanks

On Wed, May 7, 2014 at 2:43 PM, Marv Schneider notifications@github.comwrote:

Some details to be dealt with:

1. Specifying a limit on number of coins issued (total, % reserved for BTC and implied % available for MSC-based currency) requires some mechanism to handle purchases that hit one of the limits and can be honored only partially. What happens to the excess funds that were sent, and is this done automatically or manually?
2. What happens to attempted purchases that arrive after the corresponding limit is reached? Currently, the spec says "If the transaction is confirmed after the crowdsale is closed or if for any other reason no crowdsale is active, no purchase will be made and no tokens will be credited to the sending address, but the Simple Send itself will complete." That can be pretty harsh for a user who innocently saw that a crowdsale was active and got shut out for reasons beyond his control and prior knowledge. If sad tales of money lost start to spread, investors may become gun shy.
3. All implementations will have to handle rounding and truncating of the number of tokens issued exactly the same way and calculate exactly the same number of tokens issued and remaining.
4. I think the early bird bonus interacts with the % reserved for BTC, but I haven't thought it through. Earlier purchases will take larger chunks of the limited number of coins to be issued. It seems that can throw off (reduce?) the number of BTC ultimately raised.

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

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

[dacoinminster]

Well . . . invalidating sends WOULD be an auto-refund, but note that any old parsing engine would lose MSC consensus that way. Currently we have managed to keep consensus.

Eventually we will have to ask the world to upgrade, but it should be a decision made carefully :)

On Wed, May 7, 2014 at 8:12 PM, Bitoy notifications@github.com wrote:

1. If the msc quota is filled and the fundraiser is still open, the msc simple sends to the fund will be invalidated. (Simple sends to the fund will be valid after it is closed) This is like an automatic refund.

The last one will get a partial fill. Refund for this last tx must be automatic.

2 issuers manually refund msc and btc for coins sent after the close. On May 8, 2014 6:13 AM, "dacoinminster" notifications@github.com wrote:

1. Yes, the last investor will probably get a partial fill. Refunds are manual for now
2. Don't invest in untrustworthy crowdsales. Trustworthy issuers will refund in cases like this
3. Yes
4. Yes

thanks

On Wed, May 7, 2014 at 2:43 PM, Marv Schneider notifications@github.comwrote:

Some details to be dealt with:

1. Specifying a limit on number of coins issued (total, % reserved for BTC and implied % available for MSC-based currency) requires some mechanism to handle purchases that hit one of the limits and can be honored only partially. What happens to the excess funds that were sent, and is this done automatically or manually?
2. What happens to attempted purchases that arrive after the corresponding limit is reached? Currently, the spec says "If the transaction is confirmed after the crowdsale is closed or if for any other reason no crowdsale is active, no purchase will be made and no tokens will be credited to the sending address, but the Simple Send itself will complete." That can be pretty harsh for a user who innocently saw that a crowdsale was active and got shut out for reasons beyond his control and prior knowledge. If sad tales of money lost start to spread, investors may become gun shy.
3. All implementations will have to handle rounding and truncating of the number of tokens issued exactly the same way and calculate exactly the same number of tokens issued and remaining.
4. I think the early bird bonus interacts with the % reserved for BTC, but I haven't thought it through. Earlier purchases will take larger chunks of the limited number of coins to be issued. It seems that can throw off (reduce?) the number of BTC ultimately raised.

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

.

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

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

[marv-engine]

Also, does it make sense to auto-refund the MSC-based simple sends when we can't auto-refund BTC-based sends when the BTC limit is hit?

Actually, is "% reserved for BTC" a hard cutoff for BTC or does it just implicitly specify the max allowable % for the MSC-based currency?

After further thought - I don't see how "% reserved for BTC" is calculated & enforced for each incoming incremental investment, unless it's computed based on the "Total # of coins to issue" amount, which might not be reached if there's insufficient interest. So the final percentage split could be dramatically different than the specified "% reserved for BTC".

As I alluded to in an earlier comment, there's also the question of whether the "% reserved for BTC" applies to the funds invested or to the number of tokens issued (base plus early bird bonus or just base?). The linearly degrading early bird bonus eliminates any fixed ratio between the funds invested and the number of tokens issued.

[dexX7]

I assume the mechanics that may apply here due to too late payments are similar to those applied to sends which confirmed after a manually closed crowdsale: no refund and the transaction is considered as simple send -- also quite similar to buy-MSC-for-BTC after the block deadline (but less predictable).

[dacoinminster]

@marv-engine great point.

Maybe instead of a cap and a percentage reserved for BTC, we should have a number of coins reserved for the fundraising currency, and a number of coins reserved for BTC. That might make the situation more clear.

That means we would add the following fields: 1) Coins issued per BTC 2) Maximum # of coins to issue for fundraising currency (0 = no cap) 3) Maximum # of coins to issue for bitcoin (0 = no cap)

[marv-engine]

We could also have a separate early bird bonus percentage for BTC. That's another way to influence purchasers one way or the other, depending on the relative bonus percentages as well as coins purchased per unit sent.

[dacoinminster]

I'd rather not have separate early bird bonuses (complexity of implementation, and complexity of explaining it). Unless, of course, the market demands it.

On Thu, May 8, 2014 at 4:30 PM, Marv Schneider notifications@github.comwrote:

We could also have a separate early bird bonus percentage for BTC. That's another way to influence purchasers one way or the other, depending on the relative bonus percentages as well as coins purchased per unit sent.

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

[Bitoy]

Max number of coins to issue for bitcoin sounds better than percent for btc.

Should we set a maximum for it? To encourage people to buy msc when btc quota is filled. Ie 90% of total coins.

Also a minimum for coins per msc must also be set relative to coins per btc.

Ex. If current dex Msc price is .1 btc

Coins per Btc 1000. Coins per msc. 200 Price of Msc should rise to about .2 btc

Coins per btc 1000 Coins per msc 1 That will put a sell pressure on msc.

[dacoinminster]

I'm not sure we can easily put a restriction like that into the protocol (minimum valuation for MSC). I'm fine with leaving this up to users, as I think the overall impact on MSC will be positive.

Yeah, if a bunch of big crowdfunding efforts happen that are BTC-only, that might hurt MSC some, but I don't think many companies will do that, since the bitangels fund wouldn't participate, and that's leaving a lot of money on the table.

I'm getting close to starting work on a pull request for this (adding the fields as described above). I expect we'll just increment the version number of this TX, and set a block height where the new version number becomes valid. I'd suggest we also invalidate the previous version number starting at that block-height, just to keep things simple.

On Fri, May 9, 2014 at 12:21 PM, Bitoy notifications@github.com wrote:

Max number of coins to issue for bitcoin sounds better than percent for btc.

Should we set a maximum for it? To encourage people to buy msc when btc quota is filled. Ie 90% of total coins.

Also a minimum for coins per msc must also be set relative to coins per btc.

Ex. If current dex Msc price is .1 btc

Coins per Btc 1000. Coins per msc. 200 Price of Msc should rise to about .2 btc

Coins per btc 1000 Coins per msc 1 That will put a sell pressure on msc.

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

[ripper234]

I would like to reiterate how vital it is that this is accepted into the protocol ASAP. People need the stability of directly investing with BTC.

Let's make it happen.

[petertodd]

Agreed. After all, the community beyond existing Mastercoin owners obviously want this ability, and if you don't provide it, another system will anyway.

[marv-engine]

On May 8, @dacoinminster proposed:

That means we would add the following fields: 1) Coins issued per BTC 2) Maximum # of coins to issue for fundraising currency (0 = no cap) 3) Maximum # of coins to issue for bitcoin (0 = no cap)

We have to decide if the max # of coins includes early-bird bonuses. If it does, then that will reduce the number of BTC and/or fundraising currency received. Crowdsale issuers get only one chance to do it right (for each new currency), so we have to make sure this will work for issuers and participants, and that it's easy for issuers to understand what they're doing and what to expect.

[ripper234]

I'm fine with whatever solution that allows people to do pure BTC fundraisers.

[dacoinminster]

Just a quick update: this issue is still being hotly debated internally, and my current best guess is that we will incorporate some kind of structural incentive to use MSC over BTC when we directly enable BTC fundraisers in the protocol.

For instance, I proposed a 1% fee on properties created using direct bitcoin fundraising. Basically an extra 1% of the property would be created and sold for MSC for any properties created in this way. Property created with MSC investments would not have this fee attached.

It's just one idea, but I am very doubtful that direct BTC fundraisers will happen without some kind of protocol fee to increase MSC values.

On Sun, May 25, 2014 at 12:50 PM, Ron Gross notifications@github.comwrote:

I'm fine with whatever solution that allows people to do pure BTC fundraisers.

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

[Bitoy]

Another option is to require the issuer to pay an msc fee based on the btc he wants to raise. Ex. 10 % msc fee for each btc. Issuer wants to raise 1000 btc. He must pay 100 msc to have the issue listed. (100 msc can be burned or donated to charity)

No fee is charged if fundraising requires only msc.

[dexX7]

What, if a fee for Bitcoin crowdsale participants is applied, but this fee is forwarded to all the other participants who pay in MSC?

Let's say this fee is 5 % and instead of giving MSC holders a 5 % bonus or simply reducing the amount for BTC payees by a few percent, those 5 % are indeed subtracted from the amount BTC payees receive, but added to a pool which is credited to all MSC payees after the crowdsale? In the case where most users pay with BTC there is an extreme benefit for those few who paid in MSC and thus there may always be some kind of balance between BTC and MSC payees.

[jkandah]

Pretty sure counterparty does this without any xcp or a dust amount (my understanding from asking them specifically -- however I can't find this info online). If you're requiring something that is more complicated for the end-user or customer it may not be as attractive.

On Tue, May 27, 2014 at 9:17 PM, dexX7 notifications@github.com wrote:

What, if a fee for Bitcoin crowdsale participants is applied, but this fee is forwarded to all the other participants who pay in MSC?

Let's say this fee is 5 % and instead of giving MSC holders a 5 % bonus or simply reducing the amount for BTC payees by a few percent, those 5 % are indeed subtracted from the amount BTC payees receive, but added to a pool which is credited to all MSC payees after the crowdsale? In the case where most users pay with BTC there is an extreme benefit for those few who would paid in MSC and thus there may always be some kind of balance between BTC and MSC payees.

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

Jeremy Kandah (e) jkandah@gmail.com (c) 248-921-4502

[ripper234]

The state of the affairs as I know it:

1. Right now both Colored Coins, Counterparty and Mastercoin can issue assets without a significant cost (certainly with Mastercoin there is no MSC cost to creating assets)
2. AFAIK only we have the Crowdsale feature where the protocol itself distributes the assets. CC and Counterparty doesn't have this.
3. However, this feature can be easily implemented by both of these, and moreover it can be easily implemented as a 3rd party script that resides over either of these systems.

Because of 3, I strongly believe we need to be as open as possible. As @dacoinminster said, we're still debating this internally.

[taariq]

I agree with @ripper234 here as well. The more you force folks to have to use MSC to get the job done and all MSC functions as is a tax on the system, you'll get more forks or pursuit of forks where there is no such tax: Forking the crowdsale functionality is trivial and I wouldn't be surprised if there aren't more forks already on the way.

@dacoinminster if you want to raise the value of MSC, then continue to build functionality that users want and that require a "carrier currency" in order to function due to the complexity and difficulty of doing it with Bitcoin.

[ripper234]

Just to add on:

I think @dacoinminster believes it is necessary for all Master Protocol features to require MSC in some way.

I believe it is essential for some MP features to require MSC, but I also believe that having some major features that do not require MSC at all isn't a curse but rather a boon to us - it helps add in more players to our ecosystem that wouldn't otherwise be a part of it. If 80% of even 50% of the MP features require MSC, but 20-50% of the features do not, the Mastercoin ecosystem can still be huge, and I believe it will be more huge and less risky than if we insist of 100% monetization from the start.

[LOLLOLOOLOL]

I want to point out that confidence in the Mastercoin token is very low right now, because there isn't a use for it. By unnecessarily forcing people to use Mastercoin in an attempt to make it useful, people will leave in droves for simpler alternatives. The only value that Mastercoin could have will be based on what functions it makes possible on the Master Protocol that are inherently not possible elsewhere. That's why we funded the Master Protocol development - for the protocol, not for the expectation that Master Protocol development would specifically focus on the valuation of Mastercoin.

I'm sorry, but it's so backwards to focus directly on increasing the value of Mastercoin. It's double dipping - first we fund development, and now you're just using our investment to artificially drive up the price of the asset which is supposed to represent the value of the protocol???

Mastercoin will become valuable when it is supported by a good protocol. To think otherwise is to be delusional about the meaning of value.

Anyway, remember that Mastercoin is selling a product, colored coins are not. The incentives for development are much different. I wouldn't worry about CC automatic issuance because nobody wants to deal with non-fungible outputs, lack of exchange (coinprism anyway, chromawallet still in beta), and absolutely 0 publicized support, and moreso because there's no financial incentive to code test and implement this feature.

[ripper234]

Cross linking to my Open Letter that discusses these issues.

[ripper234]

We decided to go the open route regarding this feature, and allow direct BTC fundraisers.

[marv-engine]

Closing - the spec allows a crowdsale to accept multiple currencies, including BTC.