Added smart property fundraisers, improvements to other future features #52
Conversation
Also various cleanup and clarifications
| @@ -110,6 +95,7 @@ Technical notes: | |||
| * Any Mastercoin implementation implementing Exodus balance should recalculate the Development Mastercoin amount on each new block found and use the block timestamp for y. | |||
| * When calculating the years since the Mastercoin sale we assume a year is 31556926 seconds. | |||
| * 1377993874 is the Unix timestamp used to define the end-date of Exodus and thus the start date for the Development Mastercoins vesting. | |||
| * Current implementations do not have Test MSC which vest alongside dev MSC, but such coins may be recognized at some point in the future if it is deemed desireable | |||
There was a problem hiding this comment.
Not sure what this means. How does this relate to Test MSC currency id=2?
There was a problem hiding this comment.
Well, under current implementations, the total number of MSC will eventually be about 50k more than the total number of test MSC because of the dev MSC which vest slowly over time. So far nobody has recognized test MSC which vest slowly over time in parallel to dev MSC.
| 1. [Property ID](#field-property-id) = 8 | ||
| 1. [Number of Mastercoins](#field-number-of-coins) = 300,000,000 (3.00000000 Mastercoins) | ||
|
|
||
| This transaction permanently destroys Mastercoins in exchange for favorable placement of this property in the default sort-ordering of properties on every UI. Protocol parsers should accumulate all promotions of a property (which can be done by any address which has Mastercoins), with newer promotions being worth more than older promotions. |
There was a problem hiding this comment.
Given that ordering is UI dependent, is it true there's no guarantee that this transaction will have exactly the desired effect, and that placement is dependent on promotion and activity for all the properties?
There was a problem hiding this comment.
Yeah. The ordering is the aggregate effect of all promotions, and the UI using those scores. UIs could even weight the scoring differently than described here if they wanted to, but I didn't want to complicate things by talking about that.
|
Yes, I am cutting the number of properties in half for MSC and test MSC. There are several other messages which use currency ID, and it will now be possible to infer from the currency ID they are using whether they operate in Test MSC ecosystem or real MSC ecosystem. A similar change was made to data streams. Yes, in the (essentially impossible) event that somebody produced a bitcoin address which matched a fake address that had coins sent to it, they would own those coins. The same thing would happen if my client generated the same address that you are using. Again, it won't happen in many lifetimes of this universe :) I think I have now made all changes and fixes according to your very helpful comments. I'm going to start inviting a wider audience to see this PR. Thanks so much. |
|
This might be too radical a change, but rather than cutting the number of properties in half (something we can't control the generation of), how about using the upper bit of Transaction Type instead? It seems much less likely that we'd fill up 15 bits for Transaction Type than the whole community might fill up 31 bits of currency id. So the test ecosystem would use potentially different transaction definitions - which can be recognized and processed separately from the production ecosystem. I think it would actually be simpler using the same coins in two separate ecosystems rather than two sets of coins to imply two separate ecosystems. |
|
I thought about doing exactly that. I would probably have gone that way if Keep in mind that it would be trivial to get around this 2-billion property In summary, I prefer to let our children or our grandchildren worry about On Fri, Feb 21, 2014 at 9:08 AM, Marv Schneider notifications@github.comwrote:
|
|
There's a typo- Marv Schneider On Fri, Feb 21, 2014 at 12:58 PM, dacoinminster notifications@github.comwrote:
|
|
Should have been 0/1/2. Fixed. |
|
Investment Send and Pay Dividends (Send All) are both still 1. Marv Schneider On Fri, Feb 21, 2014 at 5:18 PM, dacoinminster notifications@github.comwrote:
|
|
D'oh!! I was thinking of the ones I just added, even though you clearly said "pay dividends" was one of them. Sorry - fixed. |
…ct hash for a property (proof of existence)
|
Hey Marv, I added a "property data" field in the latest commit. Can you please merge Thanks! On Fri, Feb 21, 2014 at 2:35 PM, Marv Schneider notifications@github.comwrote:
|
Added smart property fundraisers, improvements to other future features
|
Merged. Marv Schneider On Mon, Feb 24, 2014 at 6:45 PM, dacoinminster notifications@github.comwrote:
|
Also various cleanup and clarifications