300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)

[Tachikoma]

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

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

If you guys think there are better ways though let's look at those

I already said before that flexibility is welcomed for more advanced uses of mastercoin.

I'm not sure I agree with this - the whole idea of using the sender for change (which I believe both Tachikoma and I do) is to 'solve the change problem' in the simplest manner.

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.

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.

[dacoinminster]

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!

[Tachikoma]

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?

[dacoinminster]

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

[dacoinminster]

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.

I believe this is not correct. As quoted from mastering explorer

Total bought via Exodus     MSC 563,162.36

Total MSC that will ever exist
563,162.36 × 110% = 619,478.596 Cap

Total reward MSC
563,162.36 x 0.1 = 56,316.236 Reward MSC

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

[zathras]

If you guys think there are better ways though let's look at those

I already said before that flexibility is welcomed for more advanced uses of mastercoin.

I'm not sure I agree with this - the whole idea of using the sender for change (which I believe both Tachikoma and I do) is to 'solve the change problem' in the simplest manner.

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.

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.

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

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!

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.

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.

I believe this is not correct. As quoted from mastering explorer

Total bought via Exodus     MSC 563,162.36

Total MSC that will ever exist
563,162.36 × 110% = 619,478.596 Cap

Total reward MSC
563,162.36 x 0.1 = 56,316.236 Reward MSC

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

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!

[Bitoy]

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!

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.)

[zathras]

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!

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.)

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:

Code:

Dim dif As Long = 1377993600 - tx.result.blocktime
Dim bonus As Double = 0.1 * (dif / 604800)
If bonus < 0 Then bonus = 0 'avoid negative bonus
Dim totalmscexo As Double = exoamount * 100 * (1 + bonus) * 100000000

Thanks!

[Bitoy]

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:

Code:

Dim dif As Long = 1377993600 - tx.result.blocktime
Dim bonus As Double = 0.1 * (dif / 604800)
If bonus < 0 Then bonus = 0 'avoid negative bonus
Dim totalmscexo As Double = exoamount * 100 * (1 + bonus) * 100000000

Thanks!

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?


   

[Tachikoma]

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. Also you should already have an MSC address for me, since I took part of the original bounty in MSC as boss

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?  

[zathras]

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:

Code:

Dim dif As Long = 1377993600 - tx.result.blocktime
Dim bonus As Double = 0.1 * (dif / 604800)
If bonus < 0 Then bonus = 0 'avoid negative bonus
Dim totalmscexo As Double = exoamount * 100 * (1 + bonus) * 100000000

Thanks!

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?
 

Always happy to help

I'm working on the Reward MSC implementation at the mo, there are a few extra complexities when considering Exodus MSC sends because of the way reward MSC is accrued but long story short no not all simple sends from Exodus would be valid (vector for abuse) - the Exodus address will have a Mastercoin balance and must have enough to fund a simple send just like any other address.

[zathras]

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 )

[Tachikoma]

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.

Mastercoin-explorer is already doing this. So for my code the outline I presented works, I think ^^

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

Could somebody confirm my vesting calculation is correct?

Let's set the time to 2013-10-31 10:45:45 +0100 the output I get for the Exodus vesting is MSC 6103.51504811.

[zathras]

And now I feel like a right monkey!

Rather than just delete my post (which might look a bit dodgy) I'll simply admit to having completely misread Tachikoma's post.  You're already suggesting calculating reward MSC at transaction blocktime so my entire point is moot.

Sorry!

[zathras]

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.

Mastercoin-explorer is already doing this. So for my code the outline I presented works, I think ^^

Yeah sorry, we're on the same page and yep I think this method will work.  Just a blonde moment or something

I'll come back to you on the numbers, unfortunately have to head out.

[vokain]

Also, this "Reward MSC" really needs a new name. I find it easily confused with the bonus MSC investors received, when having conversations. Why call it "Reward MSC"? How about "Funding MSC"?

Personally I call them Development MSC

[grazcoin]

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

182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

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

I will gladly add the support

[grazcoin]

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.

+1

Should we also support other Mastercoin messages from the Exodus address or just simple sends?  

I am for simple send only (which includes also multisig).

[dacoinminster]

OK, so grazcoin posted a MSC address, and tachikoma said to use the one he gave me for the contest. Just need one from zathras now

No big hurry on this (the distributed exchange is way more important). Sorry for the distraction. The board just wanted to get some concrete evidence that the "dev mastercoins" (I like that name, vokain) would be treated as valid.

[zathras]

OK, so grazcoin posted a MSC address, and tachikoma said to use the one he gave me for the contest. Just need one from zathras now

Sure 1zAtHRASgdHvZDfHs6xJquMghga4eG7gy

No big hurry on this (the distributed exchange is way more important). Sorry for the distraction. The board just wanted to get some concrete evidence that the "dev mastercoins" (I like that name, vokain) would be treated as valid.

No problems - the dev Mastercoins deliverable is likely to be another couple days work and should be quite straight forward to do Still working on adding exchange support to my wallet too - at the moment I'm playing with a bunch of variations on trading by unconfirmed transactions (which greatly increases the speed of the exchange but brings a whole new set of significant problems not all of which may be solvable) - if I can get it right though our distributed Exchange will be as close to real-time as unconfirmed transaction propagation allows.