Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 53. (Read 129207 times)

Hi Zathras,

I see.  Thank you for for pointing out the difference and "Bonus" code! 

(Will double check the results with your website =)

btw for the "Rewards MSC" how will this be implemented?  Any simple send made by the Exodus address will be a valid generated MSC?


   

Hey Bitoy,

For clarity

* Bonus/Early Adopter MSC were extra Mastercoins awarded to people based on how early they invested
* Reward MSC are extra Mastercoins awarded to the Exodus address for additional development funding

It looks like you're trying to calculate the Bonus/Early Adopter MSC amount.  For this you can simply use my library using getmastercointx with the "generate" flag to see how many MSC were generated in a given transaction.  Since you asked how it's computed I'm guessing your heading in your own direction though (which is also great ) - I notice you're working in .NET too so here's a quick copy/paste on Masterchest's code for working out the bonus:


Thanks!

Speaking of reward MSC. How is it computed?

Example sent 5 btc on 8/31/2013

MSC = 5  x 100 = 500

Reward MSC is 500 *   (8/31/2013 - 9/01/2013) / 7 *  10 % ? 


(I'm trying to build another mastercoin website,  but my MSC reward calculations is wrong.)

Sorry for the delayed responses guys, things have been a little crazy at the day job!

Re above, I think that's mostly what's already been agreed, though the outputs being the same we don't currently apply & I don't think we need to.  Class B is really nice and simple:

* For pubkeyhash outputs, we only have two (Exodus & Recipient), plus a possible third for change as long as it equals sender - no ambiguity here
* For multisig outputs, we can have as many as we need, then we just scoop up all the data pubkeys put them in order and we have our data payload from 1 to 7,650 bytes - no ambiguity here either

As such there isn't really a need to try and enforce same output values etc with Class B again contributing to the simplicity

We can always build another transaction class if we find in future we need to do something different (though I can't see what we're restricting with Class B but then I also don't pretend to see the future!), but for now I'm with Tachikoma that Class B should be effectively locked in now.  The only remaining debate is the ongoing compressed/uncompressed public key for the sender discussion, but that doesn't need to be set in stone yet - we all support decoding both types and my case for encouraging the use of compressed keys is a case for lightening the transaction weight, not changing the way the transaction works.  I guess the compressed sender pubkey could be considered a discussion on best practice rather than specification if that helps set the context


Wow, that's really generous!  Thanks!   I'll take a day or two away from building distributed exchange into the masterchest wallet and look at putting some code together to handle reward MSC & Exodus sends.


The figure in the wiki is accurate.  You may remember we had a discussion on the semantics of reward mastercoins and the outcome of that was to consider all reward mastercoins created, but only spendable as per the formula specified in the spec. 

This helped to counter the "mastercoins are continually created in an ongoing process" misconception and helped establish that Mastercoin has a fixed cap of 619478.59338440 MSC.

563,162.35762218 were purchased from the Exodus address, which created 56,316.23576222 reward MSC giving a total cap of 619,478.59338440 MSC.
 
Thanks!

You are correct - I was multiplying 10% times the total of all MasterCoins, rather than 10% of the total sent to 1exodus. Thanks for the correction.

I got my number for the total number of MSC from the FAQ here: http://wiki.mastercoin.org/index.php/FAQ#How_many_mastercoins_exist.3F

It might need to be updated

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

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?

Can I get a MSC address from Tachikoma, Zathras, and grazcoin please?

I'd like to send you each some MSC from the Exodus Address (needs to be approved by the board, but I'm thinking 500 MSC each). A MSC send from the Exodus Address will currently be invalid on all of your implementations, but the board has been pestering me about when we'll have access to reward MSC (the 10% which is slowly vesting over the next few years) for use in bounties. That work is outside the scope of the current coding contest, so I figured I'd provide an incentive, by sending you each some of those MSC so you'll be motivated to find a few minutes to add support for those coins

The balance at the Exodus Address varies over time, so there may be a bit of complexity with supporting those coins. As long as you check the balance as of each send from 1exodus, there shouldn't be any problem determining that a send is valid. I'd suggest that you round down to midnight of the previous day when displaying the balance. The formula for percent vested is 1-(0.5^y) where y is the number of years since the fundraiser ended September 1st 2013. Right now, y is about 0.16666, so the reward MSC are about 11% vested. Since there are 619478.59338440 MSC in the world, 61947.859338440 of those are reward MSC. 11% of those is a bit less than 7000 MSC available there right now.

Thanks!

Yeah I did a successful exchange on Sunday. The post can be found here. 


I think for now we have enough ways to send the messages, we just need to code up support for more of them. I'm happy with the current implementation and think we should leave this discussion for when we are a bit further along.

Did someone mention that they successfully sent an exchange message on the forums?  I thought I read it yesterday, now I cannot find it.  Sorry about the trouble just trying to stay upto speed.

BTW, is there there an interest in forking the Bitcoin QT client to support mastercoin? 
 
Thanks,
Dan

This is a strategic question that we are dealing here with, and more people have to decide on this (J.R., board, ...):
Do we want masterchain to be future compatible or not?

I obviously think that the answer is YES, and I try to come up with solutions that keep the common tx simple, but leave an option for more advanced uses (in a similar way to bitcoin's protocol approach). Any solution that enables reasonable future compatibility is fine with me.
Taking zathras comments into consideration I modified my porposal to the following:

TX with 3 outputs: exodus, recipient, BIP11 - is valid (trivial case). The redeeming public key inside BIP11 MUST be the one of the sender.
TX with 4 outputs: exodus, recipient, change, BIP11 - is valid (change case). Like above + the change MUST go to the sender (to identify easily the recipient).
TX with more than 4 outputs (future compatible) - valid ONLY under the following set of rules:

• Exodus and recipient outputs MUST have the same value (we have it already today).
• Change MUST go to sender (tachikoma+zathras suggestion).
• Pubkey in BIP11 MUST belong to sender (tachikoma+zathras suggestion).
• Other outputs CANNOT have the same value like the Exodus one.

"Other outputs" (which are easily detectable) are ignored for mastercoin purposes.
If tx has more than 4 outputs (the advanced sender uses future-compatible feature intentionally), the sender knows that by not following the above 4 rules, his tx will be invalid.

Awesome, let's do that for now

+1 for 1.

My view is definitely on option 1 as I think it will cause branding issues and disappointment if users can't accept trade offers knowing reliably they will be fulfilled.  Also helps to reduce spam & fake offers as you note.

Also rather than simple send transactions sent while his offer is open being invalidated, ideally they shouldn't be sent in the first place - the wallet should just say insufficient funds.  

Sorry I wasn't clear about the contest start date. I consider the new contest to be adjacent to the old one. Any work which supports the goals of this contest counts toward the contest. For instance, we need multi-sig issues ironed out for creating the distributed exchange, so that work definitely counts towards the contest.

Thanks guys.

"J.R. hinted that the the Mastercoin spec is being rewritten to markdown."

Yes this is the case. I've talked to J.R. about this and its just a matter of him taking the time to get this done. The plan is to put it in Markdown and upload it to Github to get this part of things fully distributed.

If someone wants to volunteer to do the markdown conversion I'm sure J.R. would gladly hand off the document. You might just want to email him first to make sure he hasn't already done it.

Zathras / Grazcoin need your thoughts on the following.

User A has 300 Mastercoins and creates/broadcasts selling offer to sell these 300 coins. What happens with user A's balance?

Two options as I see it:

1. The 300 get deducted from his balance making it 0 and simple send transactions sent while his offer is still valid open will get invalidated until he cancels the offer.
2. The 300 stay and are not reserved, only accepted offers get deducted from the balance. If User A sends 100 coins while the offer was still open and User B wants to purchase 300 coins his Purchase Offer will be invalid and he should not send the funds.

I prefer option 1 since it makes things easier to work with and it's expected behaviour on exchanges. This would also mean that you can't make an valid offer that is larger then the amount of MSC that you hold.

J.R. hinted that the the Mastercoin spec is being rewritten to markdown. If this is the case documentation will get a lot easier to do. Currently J.R. has sole control over this and I believe this is a real problem since we are currently amending it by forum posts and other documents spreading the documentation out and making everything harder.

What we need is a complete technical specification on the wiki. I can't develop for it either because as soon as I think I understand it, some change is made and it's slightly different. So it's a fast moving target.

A wiki is required which puts everything in one place. We also need a reference/command list so people know what to do because even the best programmer isn't going to just know how to do stuff. Basically a detailed road map is needed, code has to be commented so that other people can read it, and the specifications along with the to-do list have to be clear. Finally there needs to be an API or at least something similar to what Open Transactions has where you have a high level API which everyone can connect to. Python is relatively easy to read which is a good thing but for stuff like building a user interface or bug testing that is something people can help out with after the basic code is finished.

Documentation documentation Documentation.

So if we're redeeming the multisig outputs via Mastercoin software, could I enquire what are your reasons for wanting the Bitcoin client to pick them as your own?  And do those reasons provide value that exceeds the extra 32 bytes per multisig output cost (which scales horribly as we use more packets)?

I do support uncompressed keys already so it's not a question of compatibility, I'm just looking for all the places we can trim the fat as it were


OK I'll keep change as-is in the amendment then