Just so I understand it correctly: The 'earned' amount of Mastercoins for the Exodus address at a given time is 1-(0.5^y). Correct?
This is trick since this does not depend on the Bitcoin protocol. A Mastercoin node who's time is drifted more then a few seconds might invalidate certain transactions. Should we perhaps somehow tie the vesting to Bitcoin?
Yeah, I think we should use the timestamp of the most recent bitcoin block, rather than the node's local clock.
I guess the full formula is actually (1-(0.5^y)) * 10% * total number of mastercoins bought at 1Exodus before the deadline
J.R. did you already try sending coins from Exodus? Having something in the blockchain already would make my job easier on supporting it. If you could send out a transaction and give us the hash that would be great.
btw for the "Rewards MSC" how will this be implemented? Any simple send made by the Exodus address will be a valid generated MSC?
This is what I propose. Whenever Exodus sends a transaction do the following.
1. Get the balance of received transactions that the Exodus address might have received.
2. Get the date of the of the block the transaction got added in.
3. Generate the reward coins based on this date.
4. Add the received transactions and reward coins together and substract any send transactions.
5. If enough balance is left for this transaction it's valid, otherwise it's invalid.
Should we also support other Mastercoin messages from the Exodus address or just simple sends?
I was initially thinking the same thing but as I flesh this out more, with this method the validity of a Mastercoin send from Exodus could potentially change over time. For example:
* Today Exodus has 50 MSC and sends 100 to Jim. This transaction is invalid.
* Tomorrow Exodus is rewarded another 50 MSC. A fresh wallet scanning the block chain tomorrow now thinks the send to Jim is valid.
This occurs because unlike other addresses where we process balance substitutions/additions in order during scanning/processing, this method calculates reward MSC as of the current date as one large addition and then looks at sends and their validity.
The solution I think is to add some logic to decoding to calculate the amount of reward MSC
at the blocktime of the transaction during decoding but I'm still working on the details.
Sorry if that makes no sense, I'm describing ideas that haven't really been thought out
Re other transaction types - simplicity would say we implement simple send and then for any other transaction types the foundation could just simple send the MSC to a second address before making the transaction. That feels like a bit of a cop-out though so I'd also be interested in what JR thinks is needed?
EDIT: for clarity (hopefully
)