MasterCoin: New Protocol Layer Starting From “The Exodus Address”

[TomHirsch]

I am so sad that the contest isn't going to fairly compensate everyone for their work, but I'm really pumped that so many people are excited to contribute!

J.R. - I don't think you have a good read on these people.  They are all going to be fairly compensated.  Their compensation comes in producing fine results on a very interesting project.  Probably very few people are in this for the money. 

Don't spend another second being 'so sad that...' - your efforts to keep the project healthy and going down a good path are all they need as compensation to work hard.  Your organization of the project assures their efforts are not wasted.  It is a perfect synergy.  Forget about $$$, BTC, or MSC.  Building something cool is far more rewarding than having a pocket full of money.
However, hot chicks tend not to agree with that I suspect.

[1715051280]

1715051280

[1715051280]

1715051280

[1715051280]

1715051280

[1715051280]

1715051280

[1715051280]

1715051280

[1715051280]

1715051280

[dacoinminster]

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong.

Question 1:
Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs).

I sent Jeff Garzik another PM asking him to comment on this.

I'm pretty close to saying we should just go with Tachikoma's multisig approach, leaving the door open to OP_RETURN in the future if that actually gets released and is clearly an improvement.

Incidentally, we shouldn't be surprised if people working on the bitcoin core protocol are suspicious or even hostile to the MasterCoin project. Frankly, we are creating work for them while taking most of the benefit for ourselves. I personally think this project will benefit bitcoin in the long run, but we shouldn't be surprised if other people don't see it that way. Rather than argue with them, I intend to prove them wrong

[dacoinminster]

I am so sad that the contest isn't going to fairly compensate everyone for their work, but I'm really pumped that so many people are excited to contribute!

J.R. - I don't think you have a good read on these people.  They are all going to be fairly compensated.  Their compensation comes in producing fine results on a very interesting project.  Probably very few people are in this for the money.  

Don't spend another second being 'so sad that...' - your efforts to keep the project healthy and going down a good path are all they need as compensation to work hard.  Your organization of the project assures their efforts are not wasted.  It is a perfect synergy.  Forget about $$$, BTC, or MSC.  Building something cool is far more rewarding than having a pocket full of money.
However, hot chicks tend not to agree with that I suspect.

LOL!

I'm deeply gratified that most people seem to be in this for personal satisfaction rather than money (the project will make progress much faster this way). However, ignore the opinion of the hot chick(s) in your life at your peril!

[jgarzik]

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong.

Making the outputs redeemable is a good and welcome improvement -- but that doesn't eliminate their UTXO storage cost.  It just makes that storage recoverable and transferable.

The extraneous data continues to be stored in the UTXO set, with this multisig method.  One person may redeem a MasterCoin multisig transaction, yes, but the payment target will just create another multisig output that consumes similar amount of UTXO storage space.  The data continues to bloat the UTXO dataset, because there is always some multisig output sitting around, waiting to be spent.

Question 1:
Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs).

Correct.  OP_RETURN data is provably not spendable.  Anything provably unspendable may be eliminated from the UTXO data set.

Note!  Besides OP_RETURN, there is yet another possibility:  P2SH:  https://en.bitcoin.it/wiki/BIP_0016

With P2SH, the MasterCoin data could be stored in the input scriptSig, as a part of redeeming.  This may be unworkable, because the MasterCoin data would only be revealed when you spend a MasterCoin, and not when you receive a MasterCoin.

[Tachikoma]

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong.

Making the outputs redeemable is a good and welcome improvement -- but that doesn't eliminate their UTXO storage cost.  It just makes that storage recoverable and transferable.

The extraneous data continues to be stored in the UTXO set, with this multisig method.  One person may redeem a MasterCoin multisig transaction, yes, but the payment target will just create another multisig output that consumes similar amount of UTXO storage space.  The data continues to bloat the UTXO dataset, because there is always some multisig output sitting around, waiting to be spent.

Question 1:
Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs).

Correct.  OP_RETURN data is provably not spendable.  Anything provably unspendable may be eliminated from the UTXO data set.

Note!  Besides OP_RETURN, there is yet another possibility:  P2SH:  https://en.bitcoin.it/wiki/BIP_0016

With P2SH, the MasterCoin data could be stored in the input scriptSig, as a part of redeeming.  This may be unworkable, because the MasterCoin data would only be revealed when you spend a MasterCoin, and not when you receive a MasterCoin.

I really appreciate the answer. I am happy that even though you are probably not a big supporter of Mastercoin you still take the time to answer a question that is in essence a Bitcoin question.

Before deciding on a spec I think we should exhaust every option presented to us. I will see if I can find a way of doing it via P2SH if that really is the best way to prevent any type of bloat. If that is indeed not possible I suggest we switch to multisig encryption until OP_RETURN becomes available at what time we can switch back to using address encoded data.     

[dacoinminster]

I really appreciate the answer. I am happy that even though you are probably not a big supporter of Mastercoin you still take the time to answer a question that is in essence a Bitcoin question.

Before deciding on a spec I think we should exhaust every option presented to us. I will see if I can find a way of doing it via P2SH if that really is the best way to prevent any type of bloat. If that is indeed not possible I suggest we switch to multisig encryption until OP_RETURN becomes available at what time we can switch back to using address encoded data.     

Emphatically agreed! Thanks everybody - I think we have a pretty clear path ahead of us now.

[zathras]

Tachikoma, on mastercoin-explorer you have a total MSC of 563,162.36 - could you advise how you are reaching this result?  Are you including anything other than Exodus purchases?  

My code calculates the total purchased from the Exodus address to be 559,302.41, then when the 10% dev fund is added on I make the total MSC created during the 'minting' if you will to be 615,232.65.

Given that Mastercoins will never again be created (ie both the initial mastercoins and the delayed reward dev fund were 'minted' during August, a once off process) and thus the total number of MSC should forever stay fixed unless they start getting destroyed for some reason.  If my reasoning is accurate then we should be able to define 'THE' fixed number of MSC that exist, a number that should not change and put that fundamental to bed once and for all.

Edit: occurs to me reading the spec - "For every 10 MasterCoins sold, an additional “reward MasterCoin” will also be created which will be awarded to the Exodus Address slowly over the following years" -I would read this as implying the 'reward mastercoin' was created at the point in time the 10 mastercoins were sold, thus all 'reward mastercoins' have already been created, but are not spendable until they are awarded.   Is this interpretation in line with your intentions JR?

[grazcoin]

Yup, biggest contributor gets the coins. I believe the latest rev of the spec now says this explicitly.

This is a convenience for the user, especially those that bought from twenty different addresses at once. I know it makes the parsing a bit trickier . . .

https://github.com/grazcoin/mastercoin-tools got updated.
Tachikoma: can you please verify that mastercoin per address of mastercoin-tools and mastercoin-explorer is identical?
https://raw.github.com/grazcoin/mastercoin-tools/master/outputs/msc_per_address.csv

19 differences
 

Code:

Explorer has: 11000200066, Tools has: 10700200066 for 12LSJoCAqvVQyvW5qaKGp6ZKMaaZpUcCv3
Explorer has: 574619940476, Tools has: 699619940476 for 12bDX26J84x545pzfSZouULeqjfBtAe9Lv
Explorer has: 21234827433, Tools has: 21134827433 for 13P8CSqRoboefrNsXKZieWYtZhJ4KcQHhH
Explorer has: 4058607308, Tools has: 3608607308 for 13qJCzNQUx7dFcixjq9Rab7wPgUCtYS48v
Explorer has: 2087679398, Tools has: 1087679398 for 13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw
Explorer has: 24701309524, Tools has: 24601309524 for 158qYAqDu4GKeVHDiTYA2xAu5Ew4sEU2Ug
Explorer has: 39434328263, Tools has: 52934328263 for 15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b
Explorer has: 53568692130, Tools has: 53168692130 for 16QkgycuGwFvwQ8oZ5cYHgVjDNSavcwovS
Explorer has: 7056807478, Tools has: 6056807478 for 17QqwZtZ221Dod33bY33SAZMXrSmi89rsP
Explorer has: 10273350529, Tools has: 10173350529 for 1AgZvwAoNDFGkQYEF193RAm3qxipWAEFAH
Explorer has: 15342266518, Tools has: 15142266518 for 1ApWmGDViVjTPqRKBhPydpBZ5DRjpuEEic
Explorer has: 10227878638, Tools has: 10127878638 for 1Bitcoin4yZjSSPoXUceJaiyQLABx7B2LL
Explorer has: 501650257937, Tools has: 501780257937 for 1Eo6FGPytuYvuA3ZS6ToXqP8sScWWtKhWN
Explorer has: 2220500793, Tools has: 5720500793 for 1GaNupdUBzfVF2B3JUAY1rZwHoXJgjyzXj
Explorer has: 9933326720, Tools has: 10103326720 for 1K5Tofy7UTfcrpWBnXcJhHZzvLTksDdasQ
Explorer has: 301315819775, Tools has: 300315819775 for 1K5ZEkQ8Pzwqedg2WHsKQd3xiAGnj7MeCD
Explorer has: 32276650397, Tools has: 31776650397 for 1Kk6eLpM3cpgC4NEzXLzjKvdndd8bPox6f
Explorer has: 10812380845, Tools has: 10712380845 for 1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm
Explorer has: 10526380622, Tools has: 10476380622 for 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm

Diving into the why right now

Edit: Are you counting incoming/outgoing payments towards the balance; or is this just exodus payments? If the latter that accounts for the difference

I just noticed that mastercoin-explorer.com added "Bought via Exodus" field, which has the exact values that msc_bootstrap.py of mastercoin-tools generated.
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_bootstrap.py checks only the bootstrap phase, which means only "Bought via Exodus", so it fits.
The parsing of transactions is done separately on https://github.com/grazcoin/mastercoin-tools/blob/master/msc_parse.py

bottom line: we're still in sync (at least with the current transactions).

[grazcoin]

Tachikoma, on mastercoin-explorer you have a total MSC of 563,162.36 - could you advise how you are reaching this result?  Are you including anything other than Exodus purchases?  

My code calculates the total purchased from the Exodus address to be 559,302.41, then when the 10% dev fund is added on I make the total MSC created during the 'minting' if you will to be 615,232.65.

Given that Mastercoins will never again be created (ie both the initial mastercoins and the delayed reward dev fund were 'minted' during August, a once off process) and thus the total number of MSC should forever stay fixed unless they start getting destroyed for some reason.  If my reasoning is accurate then we should be able to define 'THE' fixed number of MSC that exist, a number that should not change and put that fundamental to bed once and for all.

Edit: occurs to me reading the spec - "For every 10 MasterCoins sold, an additional “reward MasterCoin” will also be created which will be awarded to the Exodus Address slowly over the following years" -I would read this as implying the 'reward mastercoin' was created at the point in time the 10 mastercoins were sold, thus all 'reward mastercoins' have already been created, but are not spendable until they are awarded.   Is this interpretation in line with your intentions JR?

You can see the exact calculation on:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_bootstrap.py
the result of msc per exodus address on:
https://github.com/grazcoin/mastercoin-tools/blob/master/outputs/msc_per_address.csv
and the exact total sum is:
563162.35762218
Tachikoma has confirmed that out calculations agree.

It is possible to interpret that the 10% were already generated and they are not yet spendable.
Trying to keep the bitcoins interpretation i.e. ~21M BTC will be generated, but we still consider a bitcoin existence only after it got mined, I rather use the dual approach and interpret it in a way that every year new mastercoins are being born, and only then they exist.

If you insist on your view, than the calculation is:
563162.35762218 * 110% = 619478.593384398 -> 619478.59338440

There is absolutely no practical difference between those views.

[zathras]

Tachikoma, on mastercoin-explorer you have a total MSC of 563,162.36 - could you advise how you are reaching this result?  Are you including anything other than Exodus purchases?  

My code calculates the total purchased from the Exodus address to be 559,302.41, then when the 10% dev fund is added on I make the total MSC created during the 'minting' if you will to be 615,232.65.

Given that Mastercoins will never again be created (ie both the initial mastercoins and the delayed reward dev fund were 'minted' during August, a once off process) and thus the total number of MSC should forever stay fixed unless they start getting destroyed for some reason.  If my reasoning is accurate then we should be able to define 'THE' fixed number of MSC that exist, a number that should not change and put that fundamental to bed once and for all.

Edit: occurs to me reading the spec - "For every 10 MasterCoins sold, an additional “reward MasterCoin” will also be created which will be awarded to the Exodus Address slowly over the following years" -I would read this as implying the 'reward mastercoin' was created at the point in time the 10 mastercoins were sold, thus all 'reward mastercoins' have already been created, but are not spendable until they are awarded.   Is this interpretation in line with your intentions JR?

You can see the exact calculation on:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_bootstrap.py
the result of msc per exodus address on:
https://github.com/grazcoin/mastercoin-tools/blob/master/outputs/msc_per_address.csv
and the exact total sum is:
563162.35762218
Tachikoma has confirmed that out calculations agree.

It is possible to interpret that the 10% were already generated and they are not yet spendable.
Trying to keep the bitcoins interpretation i.e. ~21M BTC will be generated, but we still consider a bitcoin existence only after it got mined, I rather use the dual approach and interpret it in a way that every year new mastercoins are being born, and only then they exist.

If you insist on your view, than the calculation is:
563162.35762218 * 110% = 619478.593384398 -> 619478.59338440

There is absolutely no practical difference between those views.

Thanks for the feedback.  I have no strong views on the reward mastercoins either way, but ambiguity is bad so would be good to get locked away...

I'm going through my code looking for discrepancy - just ran through your list of differing values and mine seem to agree with yours:

Code:

Masterchest has: 107.00200066 ,Explorer has: 11000200066, Tools has: 10700200066 for 12LSJoCAqvVQyvW5qaKGp6ZKMaaZpUcCv3
Masterchest has: 6996.19940476, Explorer has: 574619940476, Tools has: 699619940476 for 12bDX26J84x545pzfSZouULeqjfBtAe9Lv
Masterchest has: 211.34827433, Explorer has: 21234827433, Tools has: 21134827433 for 13P8CSqRoboefrNsXKZieWYtZhJ4KcQHhH
Masterchest has: 36.08607308, Explorer has: 4058607308, Tools has: 3608607308 for 13qJCzNQUx7dFcixjq9Rab7wPgUCtYS48v
Masterchest has: 10.87679398, Explorer has: 2087679398, Tools has: 1087679398 for 13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw
Masterchest has: 246.01309524, Explorer has: 24701309524, Tools has: 24601309524 for 158qYAqDu4GKeVHDiTYA2xAu5Ew4sEU2Ug
Masterchest has: 529.3432826, Explorer has: 39434328263, Tools has: 52934328263 for 15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b
Masterchest has: 531.68692130, Explorer has: 53568692130, Tools has: 53168692130 for 16QkgycuGwFvwQ8oZ5cYHgVjDNSavcwovS
Masterchest has: 60.56807478, Explorer has: 7056807478, Tools has: 6056807478 for 17QqwZtZ221Dod33bY33SAZMXrSmi89rsP
Masterchest has: 101.73350529, Explorer has: 10273350529, Tools has: 10173350529 for 1AgZvwAoNDFGkQYEF193RAm3qxipWAEFAH
Masterchest has: 151.42266518, Explorer has: 15342266518, Tools has: 15142266518 for 1ApWmGDViVjTPqRKBhPydpBZ5DRjpuEEic
Masterchest has: 101.27878638, Explorer has: 10227878638, Tools has: 10127878638 for 1Bitcoin4yZjSSPoXUceJaiyQLABx7B2LL
Masterchest has: 5017.80257937, Explorer has: 501650257937, Tools has: 501780257937 for 1Eo6FGPytuYvuA3ZS6ToXqP8sScWWtKhWN
Masterchest has: 57.20500793, Explorer has: 2220500793, Tools has: 5720500793 for 1GaNupdUBzfVF2B3JUAY1rZwHoXJgjyzXj
Masterchest has: 101.03326720, Explorer has: 9933326720, Tools has: 10103326720 for 1K5Tofy7UTfcrpWBnXcJhHZzvLTksDdasQ
Masterchest has: 3003.15819775, Explorer has: 301315819775, Tools has: 300315819775 for 1K5ZEkQ8Pzwqedg2WHsKQd3xiAGnj7MeCD
Masterchest has: 317.76650397, Explorer has: 32276650397, Tools has: 31776650397 for 1Kk6eLpM3cpgC4NEzXLzjKvdndd8bPox6f
Masterchest has: 107.12380845, Explorer has: 10812380845, Tools has: 10712380845 for 1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm
Masterchest has: 104.76380622, Explorer has: 10526380622, Tools has: 10476380622 for 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm

Could you please let me know the total count of transactions you are considering mastercoin purchases from the Exodus address?

Thanks

[zathras]

Using your CSV file of exodus purchases and running that against my implementation I come up with two addresses with discrepancies:
1Bqp4VEweM1S8FKGHWYviRRtSxv5tMAVih
1KDCt8VoY45ya3QnExwtZEdugAnRAncr1Z

The difference in amount is ~3859.95, which if added to 559302.41 comes out at the same total yourself and Tachikoma have (563162.36).

Bug somewhere in my code.  Hunting time.

EDIT: Both transactions have purchases in block 255365 & those values account for the discrepancies.  It's been agreed that purchases in that block will be included I believe.

[zathras]

OK fixed, I was being a little strict with my block time verification.

Please to say my code is now calculating a total equal to the implementations from others



P.S. that screenie is simply dev code to help me build an implementation to interact with bitcoind's RPC server and loop through the transactions in each block to parse mastercoin data - the web front end etc is still progressing nicely and will be the UI once I get to the stage of opening it up.

[grazcoin]

OK fixed, I was being a little strict with my block time verification.

Please to say my code is now calculating a total equal to the implementations from others

Take care - I think you missed 2 dacoins, probably rounding 18 dacoins to 20.
With currency systems, accuracy is very important, and in our case it is 8 places after the decimal point.

[zathras]

OK fixed, I was being a little strict with my block time verification.

Please to say my code is now calculating a total equal to the implementations from others

Take care - I think you missed 2 dacoins, probably rounding 18 dacoins to 20.
With currency systems, accuracy is very important, and in our case it is 8 places after the decimal point.

Thanks. Yep 8 decimal places is what I'm working with - the actual figure is 563,162.35762208 which is != 563,162.35762218 so there is still a slight discrepancy I'll need to trace.

EDIT: Transactions are written to the database to 8 decimal digits but I'm using raw values from the bonus calcs in the total calculation which may explain the slight skew, will look into it further.

[dacoinminster]

One thing I haven't seen any discussion of (and I don't think I mentioned explicitly in the spec) is the continuous nature of the function describing the vesting of the 10% coins. That is, you can feed 0.5 years into that equation. Technically, a small number of them are spendable right now. To my knowledge, nobody currently recognizes those coins.

Also, I didn't explicitly say the date to start counting from - I think September 1st 2013 makes sense. By my calculations, ~0.05 years have passed since then, so (1 - 0.5^0.05) = ~3.4% of the 10% would currently be unlocked. I'll try to make these details clear in the next rev of the spec.

I have no plans to use those MasterCoins soon, so I don't care much about recognizing them now, but they will probably be used at some point as part of a compensation package for full-time employees - kind of like vesting stock options.

I love seeing the collaboration here. Is anybody working on using Tachikoma's new method of data storage yet? I assume he is, at least . . .

[Tachikoma]

I've been under the weather these past days and bound to bed. I have done some initial work and I will be releasing some source code as soon I've fought of this flu

[zathras]

Sorry to hear you're unwell Tachikoma

JR, as per my question above re reward Mastercoins; I think it would be prudent to clarify - please consider the following:
Sce1) Reward Mastercoins were created along with each 10 Mastercoin purchase at the same point in time (ie during August), but cannot be spent until they have been awarded to the Exodus address
Sce2) Reward Mastercoins are created at the point in time they are awarded to the Exodus address

I concur the total number of coins does not change in either case, but let's play semantics for a moment - consider how the layperson may interpret:
Sce1) Mastercoins have all been minted (created) and no more will ever be created (layperson may interpret as fixed/finite supply of coins)
Sce2) A small number of Mastercoins are created in an ongoing/continuing process (layperson may interpret as increasing supply of coins)

For those involved in Mastercoin, we can recognize that both provide the same total supply of coins of course.  This may be considered a non-issue and perhaps I'm overthinking it, but I thought whilst less technically relevant it could have a bearing on certain perceptions of Mastercoin.

Going back to the nuts and bolts, I'm including reward Mastercoins in my implementation starting @ 1377993600 for now.

EDIT: Missed your storage Q - no work done on Tachikoma's suggested storage approach as yet I'm still knee deep in my base wallet & explorer implementation.

[bybitcoin]

I've been under the weather these past days and bound to bed. I have done some initial work and I will be releasing some source code as soon I've fought of this flu

Sorry to ask this, a long thread: are you coding in c++ or java or perhaps python? I am thinking about joining the force but am not sure yet

[dacoinminster]

Sorry to hear you're unwell Tachikoma

JR, as per my question above re reward Mastercoins; I think it would be prudent to clarify - please consider the following:
Sce1) Reward Mastercoins were created along with each 10 Mastercoin purchase at the same point in time (ie during August), but cannot be spent until they have been awarded to the Exodus address
Sce2) Reward Mastercoins are created at the point in time they are awarded to the Exodus address

I concur the total number of coins does not change in either case, but let's play semantics for a moment - consider how the layperson may interpret:
Sce1) Mastercoins have all been minted (created) and no more will ever be created (layperson may interpret as fixed/finite supply of coins)
Sce2) A small number of Mastercoins are created in an ongoing/continuing process (layperson may interpret as increasing supply of coins)

For those involved in Mastercoin, we can recognize that both provide the same total supply of coins of course.  This may be considered a non-issue and perhaps I'm overthinking it, but I thought whilst less technically relevant it could have a bearing on certain perceptions of Mastercoin.

Going back to the nuts and bolts, I'm including reward Mastercoins in my implementation starting @ 1377993600 for now.

EDIT: Missed your storage Q - no work done on Tachikoma's suggested storage approach as yet I'm still knee deep in my base wallet & explorer implementation.

It sounds mostly like a question of presentation. I'm fine with treating the coins as "created but not spendable" if that is a better message to the layperson.

Nice work so far (judging from the screenshots). I can't wait to see more!

[zathras]

It sounds mostly like a question of presentation. I'm fine with treating the coins as "created but not spendable" if that is a better message to the layperson.

Nice work so far (judging from the screenshots). I can't wait to see more!

Great stuff, thanks.  Completely agree it's an issue of presentation and I think now we're clear on this we can make the following explicit statements:

1) The total number of Mastercoins is 619478.593384398.
2) No new Mastercoins will ever be created.

By having those statements explicit (rather than with caveats such as (paraphrasing) "with the exception of new coins awarded to the dev fund" etc) we are simplifying the overview for new entrants I believe.

Thanks, I'm working through my milestones but I'm sure you know how it is with other commitments (job/family) etc - so far I've found it easier to sacrifice something else (sleep!).