Pages:
Author

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

hero member
Activity: 938
Merit: 1000
I wouldn't do that if I were you. The problem is that just because somebody else did a Purchase Offer already does not mean he will end up getting it. The position of your transaction in the block could still be above the one send earlier.
It doesn't necessarily have to be a hide, it can be a highlight/color change etc - just something to let the user know that there is already an accept visible on the blockchain for this sell and thus their accept is likely to be invalidated.  

You're correct in that there is nothing stopping the user (protocol wise) from sending their own accept and hoping it gets included earlier in the block than the accept already visible.

That's essentially the crux of the scalability problem - an exchange where the lowest ask sell can only be bought once every (on average) 10 minutes just doesn't scale. To avoid everyone trying to accept the same sell we need a way to consider that lowest sell 'pending acceptance' (or 'Purchase Offered') and have users look to the next lowest sell intra-block to make it scalable in my opinion.

A color indication would be a great idea. I personally would still try to get the cheapest option since I have just as much chance of getting it then the person who already submitted an offer. All I wanted to convey is that the first message seen by a certain node has no increased chance of being the first one in the block. I would prefer the cheapest option, even if I need to fight for it. But by coloring it you at least give people an option to decide what is important for them.
full member
Activity: 284
Merit: 122
www.diginomics.com
Hey guys,

Just a quick update here, been working on the price tracking chart lately and I have a friend of mine working alongside me so progress is being made. However, I need to fix some hardware in my computer so I may be a bit delayed with a full update.

I will put the ticker on a website when it is finished and will post a full update here when the project is completed.
sr. member
Activity: 266
Merit: 250
I wouldn't do that if I were you. The problem is that just because somebody else did a Purchase Offer already does not mean he will end up getting it. The position of your transaction in the block could still be above the one send earlier.
It doesn't necessarily have to be a hide, it can be a highlight/color change etc - just something to let the user know that there is already an accept visible on the blockchain for this sell and thus their accept is likely to be invalidated.  

You're correct in that there is nothing stopping the user (protocol wise) from sending their own accept and hoping it gets included earlier in the block than the accept already visible.

That's essentially the crux of the scalability problem - an exchange where the lowest ask sell can only be bought once every (on average) 10 minutes just doesn't scale.  To avoid everyone trying to accept the same sell we need a way to consider that lowest sell 'pending acceptance' (or 'Purchase Offered') and have users look to the next lowest sell intra-block to make it scalable in my opinion.

EDIT: for clarity
hero member
Activity: 938
Merit: 1000
I wouldn't do that if I were you. The problem is that just because somebody else did a Purchase Offer already does not mean he will end up getting it. The position of your transaction in the block could still be above the one send earlier.
sr. member
Activity: 266
Merit: 250
While I'm online I thought I'd ask your opinions on scalability?  My biggest concern is that once Mastercoin is big enough to have multiple trades per hour then most of the traders are going to go for the same lowest ask 'sell offers' and by the time the next block comes around (which could be as long as 45 mins plus sometimes) most 'accept offers' are going to be invalidated.

Wallets perhaps hiding sell offers once they see an unconfirmed accept for said sell may go some way towards addressing this.
full member
Activity: 201
Merit: 100
I saw on grazcoins site, the buy and sells created so far show up as Unknown.
hero member
Activity: 938
Merit: 1000
Sure thing! Thanks :}
sr. member
Activity: 266
Merit: 250
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 Smiley

Sure Smiley 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 Smiley 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 problems) - if I can get it right though our distributed Exchange will be as close to real-time as unconfirmed transaction propagation allows.

Are you at a point where you can confirm that my Selling/Purchase offers are valid? I don't really want to move forward until I know I'm actually creating valid messages.

Not yet, sorry (I really only have a mish-mash of half written code at the mo) - give me a day or so Smiley
hero member
Activity: 938
Merit: 1000
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 Smiley

Sure Smiley 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 Smiley 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 problems) - if I can get it right though our distributed Exchange will be as close to real-time as unconfirmed transaction propagation allows.

Are you at a point where you can confirm that my Selling/Purchase offers are valid? I don't really want to move forward until I know I'm actually creating valid messages.
sr. member
Activity: 266
Merit: 250
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 Smiley

Sure Smiley 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 Smiley 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.

legendary
Activity: 1260
Merit: 1031
Rational Exuberance
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 Smiley

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.
sr. member
Activity: 284
Merit: 250
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).

sr. member
Activity: 284
Merit: 250
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 Smiley

I will gladly add the support Smiley



legendary
Activity: 1834
Merit: 1019
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
sr. member
Activity: 266
Merit: 250
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 Smiley

I'll come back to you on the numbers, unfortunately have to head out.
sr. member
Activity: 266
Merit: 250
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! Smiley
hero member
Activity: 938
Merit: 1000
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.
sr. member
Activity: 266
Merit: 250
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 Smiley

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 Tongue)
sr. member
Activity: 266
Merit: 250
Hey Bitoy,

For clarity Smiley

* 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 Smiley) - 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! Smiley


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 Smiley

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.
hero member
Activity: 938
Merit: 1000
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 Wink

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?  
Pages:
Jump to: