Capped Crowdsale

[ripper234]

Many people want to cap the number of tokens issues in their crowdsales.

This is currently achieved by manual means.

Should we allow capping directly in the protocol?

[LOLLOLOOLOL]

Should we allow capping directly in the protocol?

No. Not unless the issuer needn't be trusted in order to return whatever coins may have arrived after the crowdsale ended.

[zathras-crypto]

The same trust is implied if we cap - say 5 users send payment during a
block, the first triggers the cap, rest must be refunded.

Less of an issue for non BTC crowdsales as we can refund MP derived
currencies automatically within the protocol.

Thanks
Zathras
On Jun 20, 2014 1:24 PM, "LOLLOLOOLOL" [email protected] wrote:

Should we allow capping directly in the protocol?

No. Not unless the issuer needn't be trusted in order to return whatever
coins may have arrived after the crowdsale ended.

—
Reply to this email directly or view it on GitHub
#205 (comment).

[dexX7]

This is not about trust, but functionallity. If I want to sell exactly 10 items, because I own 10 items, then I don't want to gamble and issue 15, only because I missed the perfect timing to shutdown.

[zathras-crypto]

Agreed, not against a cap at all (actually pro cap) just highlighting that
trust doesn't change either way :)
On Jun 20, 2014 6:47 PM, "dexX7" [email protected] wrote:

This is not about trust, but functionallity. If I want to sell exactly 10
items, because I own 10 items, then I don't want to gamble and issue 15,
only because I missed the perfect timing to shutdown.

—
Reply to this email directly or view it on GitHub
#205 (comment).

[LOLLOLOOLOL]

I agree. But as it stands any purchase from a crowdsale is made with
irreversible transactions. Bitcoin, or simple send.

I would support capping if capped crowdsales only allowed purchases with MP
coins, and auto refunds were implemented.

I realize that this doesn't address similar situations with the regular end
of a crowdsale, or the manual closing. However I find think that those
examples should not set a precedent for requiring this sort of trust.

But, at the end of the day though, I thought the whole idea of a crowdsale
was that it had a variable quantity of coins.

If you only have 10 items, under what circumstances is a crowdsale more
reasonable than just issuing 10 tokens and listing them on the Dex?

[dexX7]

Did you see #132?

If you only have 10 items, under what circumstances is a crowdsale more
reasonable than just issuing 10 tokens and listing them on the Dex?

There is indeed an overlap between the available mechanisms, but in this specific context: everything that differentiates a token creation/sale from a crowdsale:

• It can be limited by deadline
• Bonus amounts
• And most important: only what was sold is created

The example with 10 tokens probably seems trivial, but when I think about MaidSafeCoin... a cap by amount would have been handy there.

In the end it's all pretty similar, whether it's a deadline or a cap.. or a specific block height at which a crowdsale terminates.

[LOLLOLOOLOL]

Thanks for linking pointing out that issue @dexX7.

If you are investing in a crowdfund, you already have to trust the issuer.

@dacoinminster #132 (comment)

The problem with this is that trusting an issuer doesn't mean that the issuer is prompt, infallible, etc.

Sell order is different because the seller is anonymous.

@dacoinminster #132 (comment)

Does this mean to imply that an asset can't be issued by an anonymous issuer? Or that Master Protocol has the requirement of trust between issuer and investor? To frame this with the context of the "competition," colored coins boast that one of the benefits is that the tokens can persist beyond the life/intent of the issuer (no reference ATM, but I'll see if I can find it). Granted, the token models are drastically different, but the requirement of trust is very limiting, especially for smart property. For example, it's conceptually reasonable for an anonymous, untrusted issuer to crowdsale smart property that grant rights to any "state machine" that requires that tokens input.

Re-opening this issue means (I think) that we would actually be contemplating creating an "investment send", which was the original way this was supposed to work, but was abandoned due to time constraints. A positive side effect was that old clients still tracked MSC sent for investments correctly, and did not lose MSC consensus.

I'm not opposed to discussing this more if you want to reopen, but I consider this extremely low priority

@dacoinminster #132 (comment)

• Was functionality or security sacrificed by the abandonment of the investment send transaction type?
• Why should any consideration be paid to old clients? It's intentionally specified (transaction revisioning) that there's not "forward compatibility" between spec revisions. Every single revision is a MP "hard fork." Under no circumstances should it be considered acceptable to support old clients. Yes, this is a serious problem for MP, but the answer isn't encouraging the feasibility of failing to stay up to date. This is much more a failure of the flexibility of MP than the benefit of not implementing a new transaction type. Very relevant: Restrictive transaction versioning and how to reduce resulting workload on developers. #196
• I consider this a very large issue. I don't know why it should be considered reasonable to engage in purchases with irreversible transactions which cannot guarantee that the buyer will receive what he intended to purchase. Here are the following places this issue has cropped up (that I'm aware of anyway), only some of which would be resolved by an investment sent:

** Failed dex trade: https://groups.google.com/a/mastercoin.org/forum/#!topic/dev/78suD_l-Mgs
** Crowdsale deadline
** Crowdsale manual close
** Crowdsale token cap
** Any dex trade that involves bitcoin

Why not just give them what they want, and do it the right way? I propose implementing the investment send transaction type, and adding the option for a max quantity of coins/tokens created in a crowdsale. Of course, this doesn't address the exact same set of issues that bitcoin has when involved in crowdsales that cannot be resolved without trust. But, it's a step in the right direction.

[dacoinminster]

I agree capping, and probably other features, would be great for our users.
It's only a question of priorities and trade-offs. We have a very tight
work schedule for the next 3 months or so, and adding anything in during
that time would be very disruptive to other priorities.

That's not to say that we shouldn't plan these things, talk about them, do
pull requests on the spec, etc. We should. Just don't think the changes are
coming in the next three months :)

On Fri, Jun 20, 2014 at 7:37 AM, LOLLOLOOLOL [email protected]
wrote:

Thanks for linking pointing out that issue @dexX7
https://github.com/dexX7.

If you are investing in a crowdfund, you already have to trust the issuer.

@dacoinminster https://github.com/dacoinminster #132 (comment)
#132 (comment)

The problem with this is that trusting an issuer doesn't mean that the
issuer is prompt, infallible, etc.

Sell order is different because the seller is anonymous.

@dacoinminster https://github.com/dacoinminster #132 (comment)
#132 (comment)

Does this mean to imply that an asset can't be issued by an anonymous
issuer? Or that Master Protocol has the requirement of trust between issuer
and investor? To frame this with the context of the "competition," colored
coins boast that one of the benefits is that the tokens can persist beyond
the life/intent of the issuer (no reference ATM, but I'll see if I can find
it). Granted, the token models are drastically different, but the
requirement of trust is very limiting, especially for smart property. For
example, it's conceptually reasonable for an anonymous, untrusted issuer to
crowdsale smart property that grant rights to any "state machine" that
requires that tokens input.

Re-opening this issue means (I think) that we would actually be
contemplating creating an "investment send", which was the original way
this was supposed to work, but was abandoned due to time constraints. A
positive side effect was that old clients still tracked MSC sent for
investments correctly, and did not lose MSC consensus.

I'm not opposed to discussing this more if you want to reopen, but I
consider this extremely low priority

@dacoinminster https://github.com/dacoinminster #132 (comment)
#132 (comment)

• Was functionality or security sacrificed by the abandonment of the
  investment send transaction type?
• Why should any consideration be paid to old clients? It's
  intentionally specified (transaction revisioning) that there's not "forward
  compatibility" between spec revisions. Every single revision is a MP "hard
  fork." Under no circumstances should it be considered acceptable to support
  old clients. Yes, this is a serious problem for MP, but the answer isn't
  encouraging the feasibility of failing to stay up to date. This is much
  more a failure of the flexibility of MP than the benefit of not
  implementing a new transaction type. Very relevant: Restrictive transaction versioning and how to reduce resulting workload on developers. #196
  Restrictive transaction versioning and how to reduce resulting workload on developers. #196
• I consider this a very large issue. I don't know why it should be
  considered reasonable to engage in purchases with irreversible transactions
  which cannot guarantee that the buyer will receive what he intended to
  purchase. Here are the following places this issue has cropped up (that I'm
  aware of anyway), only some of which would be resolved by an investment
  sent:

** Failed dex trade:
https://groups.google.com/a/mastercoin.org/forum/#!topic/dev/78suD_l-Mgs
** Crowdsale deadline
** Crowdsale manual close
** Crowdsale token cap
** Any dex trade that involves bitcoin

Why not just give them what they want, and do it the right way? I propose
implementing the investment send transaction type, and adding the option
for a max quantity of coins/tokens created in a crowdsale. Of course, this
doesn't address the exact same set of issues that bitcoin has when involved
in crowdsales that cannot be resolved without trust. But, it's a step in
the right direction.

—
Reply to this email directly or view it on GitHub
#205 (comment).

[marv-engine]

The general capping requirement is already in the spec for crowdsales. An excerpt from the tx51 description:

The client must ensure that the number of tokens credited to the purchaser plus the number of tokens credited to the issuer will not cause the total number of tokens issued in the crowdsale to exceed the maximum number of tokens that can be issued.

So the clients will have to implement the logic for that admittedly rare case. The main (only?) difference for the issue under discussion is that the cap would be a number less than the max number of tokens that can be issued.

[dexX7]

Ah @marv-engine: I think what was proposed here by Ron was not the max. number of coins cap, but something user defined like "the crowdsale ends, if 1000 tokens were sold".

[marv-engine]

@dexX7 Yes, I understand. It's the same thing - set and obey a limit for the number of coins that can be issued in a crowdsale. The default limit is 92,233,720,368.54775807 divisible tokens or 9,223,372,036,854,775,807 indivisible tokens.

Also, at some point there was discussion about setting a limit on the number of coins issued for each currency accepted.

[ripper234]

Renamed title from 'Include a cap on the number of tokens in a crowdsale' to 'Capped Crowdsale'