How/When to calculate crowdsale "percentage for issuer" number of indivisible tokens?

[marv-engine]

For indivisible tokens, rounding down separately for each purchase can yield a lower number of tokens for the issuer than if the calculation is done on the grand total.

Simple example:

• Percentage for issuer = 20 (%)
• 5 users each purchase 1 token
  • amount for issuer is .2 tokens per purchase, which is rounded down to 0 for each purchase
• 20% of 5 is 1 so issuer should end up with 1 token after these 5 purchases

The calculation can be done on a cumulative basis as each purchase occurs and give the issuer the integer difference between the cumulative number for the issuer and the number already given to the issuer. Or, the catch-up calculation could be done when the crowdsale closes, but that means the issuer won't receive the accumulated fractional tokens until then. Both cases require a running token total for the issuer.

[curtislacy]

Wait, these tokens can be indivisible? Really? Suppose I issue an indivisible token for that costs 0.1 MSC. Someone buys in with 0.15 MSC - What do I give them? Is that even valid? The horror!

[dacoinminster]

VERY good point. What do you think about just granting the coins to the issuer in one lump at the END of the fundraiser? I want the simplest possible solution, so if you can think of something simpler, let me know :)

On Thu, Apr 10, 2014 at 9:26 AM, Marv Schneider notifications@github.comwrote:

For indivisible tokens, rounding down separately for each purchase can yield a lower number of tokens for the issuer than if the calculation is done on the grand total.

Simple example:

• Percentage for issuer = 20 (%)
• 5 users each purchase 1 token
  • amount for issuer is .2 tokens per purchase, which is rounded down to 0 for each purchase
  • 20% of 5 is 1 so issuer should end up with 1 token after these 5 purchases

The calculation can be done on a cumulative basis as each purchase occurs and give the issuer the integer difference between the cumulative number for the issuer and the number already given to the issuer. Or, the catch-up calculation could be done when the crowdsale closes, but that means the issuer won't receive the accumulated fractional tokens until then. Both cases require a running token total for the issuer.

Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/120 .

[curtislacy]

Isn't the "simplest" approach to just not allow crowdsales to be indivisible? That handles the rounding error, AND my partial-purchase error.

[marv-engine]

I think the issuer should have the same immediate access to his tokens as purchasers do. Is there a business-logic reason not to?

[dacoinminster]

The divisible/indivisible flag is display-only. That is, an indivisible currency we just display the number of Satoshis instead of putting the decimal point in.

So, banning indivisible currencies doesn't actually change anything from a protocol perspective. Divisible/Indivisible don't affect anything in the protocol - they only affect where we put the decimal point when displaying to the user.

So, if somebody says their coin costs 0.1 MSC per Satoshi, we still have to handle that case. Somebody paying 0.15 MSC would get . . . 1 token. Calling a coin divisible or indivisible isn't really relevant to the discussion.

There's no business reason to limit the issuer's tokens. Just looking for the solution with the smallest technical complexity and testing burden.

On Thu, Apr 10, 2014 at 12:24 PM, Marv Schneider notifications@github.comwrote:

I think the issuer should have the same immediate access to his tokens as purchasers do. Is there a business-logic reason not to?

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

[curtislacy]

"Somebody paying 0.15 MSC would get . . . 1 token." - so the general rule is that we "round down, and keep the change"? That seems pretty broken.

[marv-engine]

And, if we're going to do cumulative calculations for the percentage to the issuer, we should use the same approach when an address makes multiple purchases. In this case, a second payment of 0.15 MSC would result in the purchaser owning 3 tokens, not 2.

[dacoinminster]

I don't think it's broken. I don't want to make it invalid, and I don't want to try to do refunds, and I don't like the idea of keeping track of multiple purchases from the same buyer. I'd rather treat each purchase as a separate event.

We need to avoid all complexity we possibly can. If somebody sends the wrong amount, that is user error, and we can help them avoid that at the UI layer.

On Thu, Apr 10, 2014 at 12:38 PM, Marv Schneider notifications@github.comwrote:

And, if we're going to do cumulative calculations for the percentage to the issuer, we should use the same approach when an address makes multiple purchases. In this case, a second payment of 0.15 MSC would result in the purchaser owning 3 tokens, not 2.

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

[dacoinminster]

So, yes, round down, keep the change. This is an artifact of choosing to price your property so expensively on the sellers side, and the buyer sending the wrong amount.

I'm flexible on what to do with the issuer's shares. If you guys would rather accumulate as we go, that's fine with me too. Just promise me you'll choose the least complex route :)

On Thu, Apr 10, 2014 at 12:56 PM, J.R. Willett jr.willett@gmail.com wrote:

I don't think it's broken. I don't want to make it invalid, and I don't want to try to do refunds, and I don't like the idea of keeping track of multiple purchases from the same buyer. I'd rather treat each purchase as a separate event.

We need to avoid all complexity we possibly can. If somebody sends the wrong amount, that is user error, and we can help them avoid that at the UI layer.

On Thu, Apr 10, 2014 at 12:38 PM, Marv Schneider <notifications@github.com

wrote:

And, if we're going to do cumulative calculations for the percentage to the issuer, we should use the same approach when an address makes multiple purchases. In this case, a second payment of 0.15 MSC would result in the purchaser owning 3 tokens, not 2.

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

[zathras-crypto]

Hey guys, On rounding - that's really a no-choice scenario. No choice but to round. And no choice but to round down (obviously rounding up is ripe for exploitation, just send lots of small payments). I think before we talk about some kind of accumulation we need to step back and consider the complexity that introduces. Not only do we need to maintain an additional state of balances for overpayments, but we also introduce skew on things like bonus payments - in Marv's scenario where the second payment gets accumulated to purchase a 3rd token - do we apply partial bonus calculation for the first half of the accumulated purchase different to the second half of the accumulated purchase and so on - all those questions would need to be explored and thought through to ensure there is no way to exploit it (eg such as making half a payment early and then another half later on to secure the earlier bonus etc). Just first ramblings of course - not thought about it in detail, but my initial reaction is simplicity = elegance - do we want to introduce a whole bunch of complexity at protocol level to handle a user level issue (overpayment).
Thanks Zathras

[zathras-crypto]

Also the fundraiser address having access to his premine tokens just like the users during the fundraiser doesn't fit if you want to calculate the percentage at the end.

[zathras-crypto]

Also from my own perspective refunding overpayment would be far easier than accumulation.

[dexX7]

The divisible/indivisible flag is display-only. That is, an indivisible currency we just display the number of Satoshis instead of putting the decimal point in.

Wait, just to clarify: are you implying indivisible tokens are actually divisible? There are a lot of use-cases where tokens can't be devided into fractions. What would be the purpose of owning 0.5 cars? Or 0.132 gift coupons?

[dacoinminster]

Keep in mind that we already store everything as 64-bit integers. The 8 decimal places are already display-only.

A car is just a property with 1 unit. You mark it as indivisible, and the number of units shows up as 1 instead of 0.00000001 :)

On Thu, Apr 10, 2014 at 4:02 PM, dexX7 notifications@github.com wrote:

The divisible/indivisible flag is display-only. That is, an indivisible currency we just display the number of Satoshis instead of putting the decimal point in.

Wait, just to clarify: there are a lot of use-cases where tokens can't be devided into fractions, say for example I'm going to sell a car. What would be the purpose of owning 0.5 cars? Or 0.132 gift coupons?

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

[dacoinminster]

Oh, and Zathras is absolutely, completely right about the complexity issue. It's like he's reading my thoughts or something. :)

On Thu, Apr 10, 2014 at 7:49 PM, J.R. Willett jr.willett@gmail.com wrote:

Keep in mind that we already store everything as 64-bit integers. The 8 decimal places are already display-only.

A car is just a property with 1 unit. You mark it as indivisible, and the number of units shows up as 1 instead of 0.00000001 :)

On Thu, Apr 10, 2014 at 4:02 PM, dexX7 notifications@github.com wrote:

The divisible/indivisible flag is display-only. That is, an indivisible currency we just display the number of Satoshis instead of putting the decimal point in.

Wait, just to clarify: there are a lot of use-cases where tokens can't be devided into fractions, say for example I'm going to sell a car. What would be the purpose of owning 0.5 cars? Or 0.132 gift coupons?

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

[marv-engine]

We're conflating at least two related, but separate, questions.

1. See my original question at the beginning of this issue - about dealing with truncation when calculating number of tokens based on "Percentage for issuer". We need an answer for this issue.
2. Curtis then brought up the truncation question that could apply to purchases of indivisible tokens. What to do with a payment that's worth an integer number of tokens plus a fractional number as well. J.R. says to round down to the integer (and silently thank the purchaser for sending you extra funds).

I'll discuss what I think is involved with displaying & manipulating divisible vs. indivisible tokens in a new issue. Maybe everyone does it correctly, so it would be a non-issue - if there's only one correct way to do it.

[zathras-crypto]

Re divisible/indivisible - I'm really not sure where the confusion comes from here - but let me just be real simple in laymans terms - value stored is always 64-bit int. If indivisible display as is, if divisible divide by 100000000 and display to 8 decimals. It's all the same data, there is no math to be done here :)

Example: Data stored - 123400000 - same regardless of divisibility: Indivisible - Display as: 123400000 Divisible - Display as: 1.23400000 (or 1.234)

@Marv, re 1) - I dislike the idea of amending anything after the fact. So IMO we either calculate the premine tokens at the time of the send, or at the time the fundraiser closes. The idea of calculating premine tokens at the time of the send and then amending those values at the time of the fundraiser close (eg to add extra accumulation) seems convoluted.

re 2) - Again overpayment is a user level issue not a protocol level issue. If we are REALLY concerned about it, then we can return change as the simplest way to address it. But again I see this as a non-issue. Ever used BitPay? If you overpay by a small fraction that's a user error and tough luck. The merchant can instruct BitPay to return substantial overpayments but that's an entirely manual process. TL:DR; if the price is $9.75 and I send you $10 then as the user I am effectively saying "keep the change", otherwise I would have simply sent $9.75.

EDIT - just to really drive the point home on 2) - this is really only relevant for some kind of manual transaction - and who is sending manual transactions, really? Wallet software can handle all of this at the UI layer to send only an exact multiple of the indivisible token cost. We're talking a "what if" scenario here (what if the user overpays) and in this RARE scenario only relevant when either a) wallet software is badly written or b) they are doing transactions manually

[marv-engine]

Re divisible/indivisible - see Have to resolve conflicts for quantities of divisible vs. indivisible properties

121https://github.com/mastercoin-MSC/spec/issues/121

re 1) amending after the fact - I don't like it either, but strictly speaking we're still before the fact. (We shouldn't sacrifice the future by not fixing fixable mistakes of the past.) I had suggested 2 approaches -

1. calculate cumulative indiv tokens for the issuer at each send and keep a running total of the number issued to the issuer. At each send, give the issuer the difference between what he's now due and what he's already received.
   • the issuer receives the tokens at the same time the purchasers do, which seems equitable.
   • when the crowdsale closes, calculate how many the issuer should receive and give them to him then. I don't think the issuer should have to wait until the end to get his tokens. He's at a disadvantage WRT the purchasers.

How does the issuer's transaction history represent his receipt of these tokens, and each distribution to a purchaser?

re 2) incorrect payment is a user-level issue. the issuer gets to keep anything extra. As you said, tough luck for the user error.

Marv Schneider VP, User Experience/Product Usability Engine, Inc. marv@engine.co 240-462-6123 cell

On Fri, Apr 11, 2014 at 4:56 PM, zathras-crypto notifications@github.comwrote:

Re divisible/indivisible - I'm really not sure where the confusion comes from here - but let me just be real simple in laymans terms - value stored is always 64-bit int. If indivisible display as is, if divisible divide by 100000000 and display to 8 decimals. It's all the same data, there is no math to be done here :)

@Marv https://github.com/Marv, re 1) - I dislike the idea of amending anything after the fact. So IMO we either calculate the premine tokens at the time of the send, or at the time the fundraiser closes. The idea of calculating premine tokens at the time of the send and then amending those values at the time of the fundraiser close (eg to add extra accumulation) seems convoluted.

re 2) - Again overpayment is a user level issue not a protocol level issue. If we are REALLY concerned about it, then we can return change as the simplest way to address it. But again I see this as a non-issue. Ever used BitPay? If you overpay by a small fraction that's a user error and tough luck. The merchant can instruct BitPay to return _substantial_overpayments but that's an entirely manual process. TL:DR; if the price is $9.75 and I send you $10 then as the user I am effectively saying "keep the change", otherwise I would have simply sent $9.75.

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

[zathras-crypto]

Unfortunately option 2 is far easier to implement. What you're talking about with option 1 requires us to hold a new separate state of outstanding payments.

Two simple methodologies could be in play currently: Method A: Every transaction to the fundraiser triggers three immediate actions:

• Move X MSC from buyer to issuer
• Create Y tokens and assign to buyer
• Create Z% of Y tokens and assign to issuer

Transaction is considered complete, nothing is locked.

Method B: Every transaction to the fundraiser triggers two immediate actions:

• Move X MSC from buyer to issuer
• Create Y tokens and assign to buyer

Transaction is considered complete, nothing is locked.

At fundraiser completion triggers one immediate action:

• Create Z% of total tokens and assign to issuer

So as you see they are both very simplistic models that fit well within the existing data structures like balances and property tokens.

If we introduce some kind of 'difference owed' function we then need to tag on another layer of state to track that and since we can't credit any address with those funds (since we store balances as ints and we can't add eg 0.2 to an int) we effectively have those funds existing, but not credited to any address in the DB (coding wise I try to avoid any scenarios that allow for funds/tokens to be floating in the system but not owned by any address).

I'm sure with a bit of thought a solution could be coded - initial would be to simply store the fractional values elsewhere away from the address balances structures and then do some kind of lookup each send, but I'm conscious of time given go live is in ten days.

[dacoinminster]

The raw, difficult fact is, we are NOT in an early stage where we can still tweak our spec. With our go-live date just a few days away, the spec should be frozen except in the most dire of emergencies.

Regarding Zathras' method A and method B, I haven't heard anybody say "my code does X". Whatever the code currently does is what we should formalize. If we don't have any code written yet, I'd suggest method A, as it requires less state memory between transactions.

I'm not in the least concerned with over-payments. That is entirely UI-avoidable.

Similarly, with the pre-mine, we need to know what your code currently does. I'm fine with an accumulation until the end, and I'm fine with an accumulation with each transaction. All I care about is what the code currently does so we can get it formalized.

If your code has two differing implementations, we'll go with Mastercoin-Tools, simply because we can't afford the time to talk about it. Even this conversation is adding to schedule risk.

I know it hurts horribly to sacrifice everything else on the altar of the schedule, but I'm certain it's the right call. Please everybody adjust your mindset and sharpen your sacrificial knives.

I'm going to create an urgent email for Zathras/Curtis/Graz/Alvin to get them to post here what their code currently does.

Thanks guys!

On Fri, Apr 11, 2014 at 7:57 PM, zathras-crypto notifications@github.comwrote:

Unfortunately option 2 is far easier to implement. What you're talking about with option 1 requires us to hold a new separate state of outstanding payments.

Two simple methodologies could be in play currently: Method A: Every transaction to the fundraiser triggers three immediate actions:

• Move X MSC from buyer to issuer
• Create Y tokens and assign to buyer
• Create Z% of Y tokens and assign to issuer Transaction is considered complete, nothing is locked.

Method B: Every transaction to the fundraiser triggers two immediate actions:

• Move X MSC from buyer to issuer
• Create Y tokens and assign to buyer Transaction is considered complete, nothing is locked. At fundraiser completion triggers one immediate action:
• Create Z% of total tokens and assign to issuer

So as you see they are both very simplistic models that fit well within the existing data structures like balances and property tokens.

If we introduce some kind of 'difference owed' function we then need to tag on another layer of state to track that and since we can't credit any address with those funds (since we store balances as ints and we can't add eg 0.2 to an int) we effectively have those funds existing, but not credited to any address in the DB (coding wise I try to avoid any scenarios that allow for funds/tokens to be floating in the system but not owned by any address).

I'm sure with a bit of thought a solution could be coded - initial would be to simply store the fractional values elsewhere away from the address balances structures and then do some kind of lookup each send, but I'm conscious of time given go live is in ten days.

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

[Bitoy88]

My implementation works like this

Move X MSC from buyer to issuer Create Y tokens (round down) and assign to buyer Recalculate Z% of total Y tokens and assign to issuer (same as what we do to dev mastercoins in exodus address)

[dacoinminster]

That sounds like "Method A" to me! Hopefully everybody is doing it this way??

On Sun, Apr 13, 2014 at 7:41 AM, Bitoy88 notifications@github.com wrote:

My implementation works like this

Move X MSC from buyer to issuer Create Y tokens (round down) and assign to buyer Recalculate Z% of total Y tokens and assign to issuer (same as what we do to dev mastercoins in exodus address)

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

[Bitoy88]

Yes method A.

Also when calculating tokens with early bird bonus and property is indivisible Ex 1 msc 30 tokens 10% bonus

If 1 msc is sent 1.5 weeks before deadline Token is 34 (30 x 15% = 34.5 trucate decimal)

[zathras-crypto]

Bastardized version of A & B.

Marv is correct that we have a pretty ugly potential outcome for indivisible fundraisers with premine. Let's say 5000 tokens were issued with a 10% premine, yet the issuer only gets 250 tokens instead of 500 due to fractions. That my friends will label us as a 'broken system'.

My current method:

At time of a 'fund' transaction: Move X MSC from buyer to issuer Create Y tokens and assign to buyer Create Z% of Y tokens and assign to issuer

At the close of a 'fundraiser' open position: Repeat and sum calculations on ALL fund transactions to total what premine already awarded Total funds issued and take premine percentage Create (total premine % - awarded premine %) tokens and grant to issuer

This method requires no additional state, requires no 'floating' balances where funds exist but are not owned by any address and sidesteps the issue of the issuer sending/receiving tokens during the fundraiser as we don't use the issuer balance in anyway when closing the fundraiser.

Thanks Zathras

[zathras-crypto]

Additionally should probably be in a new issue so sorry for going off topic but I'm obviously redesigning consensus to be smart property aware so it can monitor consensus on all property balances, not just MSC/TMSC.

Can @Bitoy88 @Grazcoin you guys confirm that your API's will support SP and confirm your URLs: https://masterchain.info/mastercoin_verify/addresses/12345678 http://www.mymastercoins.com/jaddress.aspx?CurrencyID=12345678

Can the Omni guys confirm if they will support verification API and if so URL.

Thanks Zathras

[zathras-crypto]

@Devs - quick sanity check - you guys agree?

Thanks Zathras

[Bitoy88]

Zathras

http://www.mymastercoins.com/SmartProperty.aspx I only have 3 smart properties created. Where can I see your SP listings? We should have an api that list SP for checking.

I will update jaddress to support SP.

[zathras-crypto]

Yeah that screenie is incorrect, fundraisers that were thrown out were still creating the properties themselves without a fundraiser.

Currently 5 I think:

FYI rows 2 & 5 are fundraisers.

[Bitoy88]

Zathras bastardized A and B (let's call it C :) looks better.

[Bitoy88]

Ok I also got 5 smart property. (2 fundraiser)

http://www.mymastercoins.com/SmartProperty.aspx

Note address 1DYb5Njvcgovt9gUMdMgYkpaQjAEdUooon has 3 sp.

[ghost]

So, quickly; haven't implemented the premine/bonus code yet, planning to today with the latest discussion from this thread as the basis.

"Can the Omni guys confirm if they will support verification API and if so URL." Yes, we are working on that, you can see https://github.com/mastercoin-MSC/omniwallet/pull/352 for the actual commit, unfortunately it doesn't conform to the official API, but we might have conformance shortly. It would be up on /v1/properties/list/, with the offical docs at https://github.com/mastercoin-MSC/omniwallet/pull/370/files

[ghost]

"At fundraiser completion triggers one immediate action:

Create Z% of total tokens and assign to issuer"

Does the fundraiser being replaced also constitute "completion" or is that word reserved for only fundraisers that reach the deadline?

Relevant to our implementation because new fundraisers replace old ones unceremoniously, ie. If a new fundraiser appears, the old one is replaced without comment or fuss.

If the above is true, I'll have to create more state to be managed for this particular action.

[ghost]

"At the close of a 'fundraiser' open position: Repeat and sum calculations on ALL fund transactions to total what premine already awarded Total funds issued and take premine percentage Create (total premine % - awarded premine %) tokens and grant to issuer"

Also it appears to me this will create a state where some unknown portion of tokens will be unusable by the issuer until the end of the fundraiser, which is if I'm not mistaken a situation Marv wanted to avoid.

Just clarifying

[zathras-crypto]

Really good question about replacement = completion - I don't have replacement code in yet. What's the strategic intent here?

Re unknown portion of tokens unusable by issuer until end of the fundraiser, yep that's definitely true, though we're only talking fractions that could not be committed at the time of the investment.

The original solution as proposed (adding fractions each subsequent investment) has a number of problems with regard to holding an additional state of fractional payments - plus I don't like it full stop as it makes the assumption there will always be flow of subsequent investment transactions to continue to credit the intermediate fractions which is not an assumption we can make IMO.

My model is simple (it's supposed to be), I'm happy to deviate to something else if someone wants to propose something :)

Thanks Zathras

[zathras-crypto]

Also should be noted explicitly that closing a fundraiser early has no affect on already granted tokens. You get your bonus x% for every week you're early, but that's always based on fundraiser closing time at time of investment. Closing the fundraiser early cannot change bonuses already granted.

Eg fundraiser closes in 4 weeks @ 10% early bird, I invest and get 40% bonus. Fundraiser is closed early tomorrow, so I'm now only 1 day early bird not 4 weeks early bird. Regardless, I still get my 40% bonus because at the time of investment (which is what counts), I was still 4 weeks early bird.

You guys may already be on top of this but just thought I should mention.

Thanks Zathras

[marv-engine]

@faizkhan00 asked: Does the fundraiser being replaced also constitute "completion" or is that word reserved for only fundraisers that reach the deadline?

Read all of J.R.'s comment on Mar 27 to #98. It begins: "Every time I talk about this field (Property Type), I seem to be misunderstood. Everyone assumes that this field affects the protocol in some way, but it does not. It has no effect whatsoever on anything related to balances, consensus, fundraisers, trading, etc."

[zathras-crypto]

@Marv Ah perfect - thanks for the reminder.

@Faiz yeah I recall this now, that field is display only to allow you to kind of 'link' properties at a UI level - actually tripped my own self up this morning - thought I'd got myself all tizzled up when I didn't have code to handle replace SP nor did I have it on the todo list... I thought I'd dropped the ball, but now makes complete sense!

[zathras-crypto]

So many different variables haha, I'm tempted to just flip the networking on test to allow public access - I'm sure there are 101 things I've not got quite right!

[marv-engine]

@zathras-crypto I'll add words that an early close has no impact on tokens already issued. In fact, nothing (except, I think, a re-org that moves a purchase to after the close or deadline passing) will undo a crowdsale purchase and any associated percentage to the issuer.

Re maintaining a running total of token fractions not credited to the issuer - it seems that this is similar to reserved or escrowed funds, so it's another classification for such funds. If the code can handle reserved or escrowed funds, it should be able to handle this.

Re "fractions that could not be committed at the time of the investment" - it may be fair to say it's an average of .5 tokens per investment. So with thousands of investors, it's a sizable number though it may be a small percentage of the total tokens to be credited to the issuer.

[zathras-crypto]

Hey Marv,

Understood but not quite the same as reserved funds - reserved funds are actual amounts of funds we can commit to an address as owning but reserved. Fractions we inherently cannot commit to an address - that's the problem, we have to store them somewhere else so we effectively have these floating fractions of funds waiting to be committed to an address. Not saying it can't be done, of course it can - I'm just saying it adds a fair degree of complexity to an otherwise simple process.

Can be done, don't get me wrong - but deadlines are deadlines - if we want to take a complex approach to solving this that's cool, but powers above me will need to provide the direction.

Thanks Zathras

On Tue, Apr 15, 2014 at 12:13 PM, Marv Schneider notifications@github.comwrote:

@zathras-crypto https://github.com/zathras-crypto I'll add words that an early close has no impact on tokens already issued. In fact, nothing (except, I think, a re-org that moves a purchase to after the close or deadline passing) will undo a crowdsale purchase and any associated percentage to the issuer.

Re maintaining a running total of token fractions not credited to the issuer - it seems that this is similar to reserved or escrowed funds, so it's another classification for such funds. If the code can handle reserved or escrowed funds, it should be able to handle this.

Re "fractions that could not be committed at the time of the investment" - it may be fair to say it's an average of .5 tokens per investment. So with thousands of investors, it's a sizable number though it may be a small percentage of the total tokens to be credited to the issuer.

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

[ghost]

Up above, I did actually mean replace without reference to the Property Type field:

Say an address initiates a fundraiser, then five minutes later another fundraiser is started, all subsequent sends will be funding the latest fundraiser and making the other fundraisers old/expired/not active; does a "replacement" in this way (without the first fundraiser reaching the deadline or manual close) constitute Zathras' earlier word "completion" for eligibility in the final calculation of tokens for the premine?

ex. 1
Fundraiser 1 starts
Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Fundraiser 1 ends via deadline reached (final premine pass calculated, tokens issued to fundraiser owner)
Fundraiser 2 starts
Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Fundraiser 2 ends via manual close (final premine pass calculated, tokens issued to fundraiser owner)

ex. 2
Fundraiser 1 starts
Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Fundraiser 2 starts
Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner)
Fundraiser 2 ends via manual close (final premine pass calculated, tokens issued to fundraiser owner)

in ex2, the fundraiser 1 fails to close and is instead replaced by an oncoming fundraiser, should we consider those closed and the final pass performed, even though the action was not explicit but implicit?

[zathras-crypto]

Ahh I see where you're going. Simply put mate, second fundraiser is invalid.

If a fundraiser comes in from an address that already has an active fundraiser (ie hasn't expired or been manually closed), the new fundraiser is invalidated. This is just the one fundraiser per address restriction in play :)

Thanks Zathras

On Tue, Apr 15, 2014 at 1:07 PM, Faiz Khan notifications@github.com wrote:

Up above, I did actually mean replace without reference to the Property Type field:

Say an address initiates a fundraiser, then five minutes later another fundraiser is started, all subsequent sends will be funding the latest fundraiser and making the other fundraisers old/expired/not active; does a "replacement" in this way (without the first fundraiser reaching the deadline or manual close) constitute Zathras' earlier word "completion" for eligibility in the final calculation of tokens for the premine?

ex. 1 Fundraiser 1 starts Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner) Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner) Fundraiser 1 ends via deadline reached (final premine pass calculated, tokens issued to fundraiser owner) Fundraiser 2 starts Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner) Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner) Fundraiser 2 ends via manual close (final premine pass calculated, tokens issued to fundraiser owner)

ex. 2 Fundraiser 1 starts Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner) Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner) Fundraiser 2 starts Send of 1MSC from buyer (premine calculated, tokens issued to fundraiser owner) Send of 2MSC from buyer (premine calculated, tokens issued to fundraiser owner) Fundraiser 2 ends via manual close (final premine pass calculated, tokens issued to fundraiser owner)

in ex2, the fundraiser 1 fails to close and is instead replaced by an oncoming fundraiser, should we consider those closed and the final pass performed, even though the action was not explicit but implicit?

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

[ghost]

Cool, np; can I get a reference in the spec/discussion where that was the intended implementation/behavior (ie. all fundraisers that aren't closed manually or expire are invalid)?

From the spec:

The attributes of an existing property cannot be changed. 
However, a new property can be created to replace or append an existing property. 
Only the address that issued a property can replace or append that property.
Attempts by other addresses are invalid. 

The behavior I'm stating is completely independent of the "property type"(cosmetic) field, its the creation of a new property to replace the active fundraiser; I guess I read the spec differently, but there's still 1 fundraiser per address, its just that the most recent fundraiser gets preference to "replace" the last one (which is behavior I'm fine to remove, but I'd like to do so according to the discussion if there are caveats).

[ghost]

In any event, I suppose I'll revert my changes tomorrow.

Thanks for clarification

[dexX7]

There is no "real" replace but only the cosmetic append/replace. One may use the combination of the two atomic transactions "close crowdsale" + "create a new crowdsale" which would be close to what you described but at no time more than one "active" crowdsale is possible (per ecosystem).

[zathras-crypto]

Sure - from the spec on crowdsale - can only have one crowdsale active, so as long as one is open at the time of processing a new fundraiser message we throw out the new fundraiser message.

A MSC address may have only one crowdsale active per ecosystem at any given time, eliminating the need for participants to specify which crowdsale from that address they are participating in when they purchase.

That is of course if we don't want to go down the road of having update actions/byte and all that come in last minute hehe ;)

Thanks Zathras

On Tue, Apr 15, 2014 at 1:38 PM, Faiz Khan notifications@github.com wrote:

Cool, np; can I get a reference in the spec/discussion where that was the intended implementation/behavior (ie. all fundraisers that aren't closed manually or expire are invalid)?

From the spec:

The attributes of an existing property cannot be changed. However, a new property can be created to replace or append an existing property. Only the address that issued a property can replace or append that property. Attempts by other addresses are invalid.

I guess I read the spec differently, but there's still 1 fundraiser per address, its just that the most recent fundraiser gets preference to "replace" the last one (which is behavior I'm fine to remove, but I'd like to do so according to the discussion if there are caveats).

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

[zathras-crypto]

Note DEx behaviour is different - sell offers in DEx update the previous sell, but we have a different context with fundraisers and to my knowledge there is (currently) no provision in the spec to automatically close an open fundraiser and replace it with the new one if a new fundraiser message is received from an address that already has one open.

Thanks Zathras

On Tue, Apr 15, 2014 at 1:54 PM, zathras crypto zathrasc@gmail.com wrote:

Sure - from the spec on crowdsale - can only have one crowdsale active, so as long as one is open at the time of processing a new fundraiser message we throw out the new fundraiser message.

A MSC address may have only one crowdsale active per ecosystem at any given time, eliminating the need for participants to specify which crowdsale from that address they are participating in when they purchase.

That is of course if we don't want to go down the road of having update actions/byte and all that come in last minute hehe ;)

Thanks Zathras

On Tue, Apr 15, 2014 at 1:38 PM, Faiz Khan notifications@github.comwrote:

Cool, np; can I get a reference in the spec/discussion where that was the intended implementation/behavior (ie. all fundraisers that aren't closed manually or expire are invalid)?

From the spec:

The attributes of an existing property cannot be changed. However, a new property can be created to replace or append an existing property. Only the address that issued a property can replace or append that property. Attempts by other addresses are invalid.

I guess I read the spec differently, but there's still 1 fundraiser per address, its just that the most recent fundraiser gets preference to "replace" the last one (which is behavior I'm fine to remove, but I'd like to do so according to the discussion if there are caveats).

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