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

[zathras]

Bitoy, can I have a MSC address for you please? I think you should be included when I send the devs some MSC from the Exodus Address.

I was going to send 1500 between you all, and it seems that I had better get a move on before that becomes worth more than our current contest!

(This is a fun little incentive I mentioned before to make sure all our web clients recognize dev Mastercoins)

Ah fantastic, I was wondering when those exodus sends would occur, I've got some dev code I'm keen to test before it makes it into the next major Masterchest update (next update is a big one) - of course I'm very happy to be getting some MSC also!

[ripper234]

I think I'll be disabling notifications on this thread.
Too much stuff happening.

We might need a semi-official position whose role is to coordinate with all the developers since we're unable to keep track.
I think J.R is doing that right now.
We need to get him to quit his job at cozi and do this full time.

Go J.R go!

Anyway this is just random thoughts before I unwatch the thread, not sure if it's needed or not at this point.

[zbx]

W.r.t. block lag, what if an address has an insufficient balance to send X mastercoins until the block in which he attempts to send them?

[Tachikoma]

That would be an invalid transaction. I've had a night to sleep on it and I'm not sure how much I like it. I still do not like the random chance but changing the procol might be too drastic. Unless somebody really loves it let's drop it.

[Tachikoma]

Guys I need to amend the validation spec a bit. But to do so I need your opinions.

Right now Bitboy and I deal differently with addresses.

When Mastercoin-explorer displays the addresses for a certain currency_id and an address has not received any transactions for the given currency_id it omits the address from the results. As far as my application is concerned the address does not exist so it can't display it.

BitBoy's implementation however returns the address with a zero balance. Which is technically also correct.

Anybody has a reason to pick one over the other?

The code news however is that this is already proven useful.

Mastercoin explorer has 2617.47620688 for 1AGFxUanxnWnrTiwLsY4NyvNZTv3RWFnfT but Bitboy has 2617.48620688
Mastercoin explorer has 200 for 1MBrNtFBw9QQ1owGsTs6Nd1iL1Err2H4yp but Bitboy has 199.99
Mastercoin explorer has 757.23987298 for 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 but Bitboy has 752.23987298

Much easier to find which transactions to fix now.

[Bitoy]

Mastercoin explorer has 2617.47620688 for 1AGFxUanxnWnrTiwLsY4NyvNZTv3RWFnfT but Bitboy has 2617.48620688
Mastercoin explorer has 200 for 1MBrNtFBw9QQ1owGsTs6Nd1iL1Err2H4yp but Bitboy has 199.99
Mastercoin explorer has 757.23987298 for 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 but Bitboy has 752.23987298

Much easier to find which transactions to fix now.

Thanks Tachikoma,

I'll fix the the missing transactions.

Btw the "peek and decode" is already approved.  I'll update and run checks again.

[grazcoin]

Guys I need to amend the validation spec a bit. But to do so I need your opinions.

Right now Bitboy and I deal differently with addresses.

When Mastercoin-explorer displays the addresses for a certain currency_id and an address has not received any transactions for the given currency_id it omits the address from the results. As far as my application is concerned the address does not exist so it can't display it.

BitBoy's implementation however returns the address with a zero balance. Which is technically also correct.

Anybody has a reason to pick one over the other?

I think bitboy's approach is better (same behaviour of blockchain.info).
It means that I will have to change my implementation as well.

The code news however is that this is already proven useful.

Mastercoin explorer has 2617.47620688 for 1AGFxUanxnWnrTiwLsY4NyvNZTv3RWFnfT but Bitboy has 2617.48620688
Mastercoin explorer has 200 for 1MBrNtFBw9QQ1owGsTs6Nd1iL1Err2H4yp but Bitboy has 199.99
Mastercoin explorer has 757.23987298 for 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 but Bitboy has 752.23987298

Much easier to find which transactions to fix now.

I will join the comparison game whenever my sell offer/accept parsing is done.
That's a great tool.

[Tachikoma]

BitBoy some of those transactions are wrong at my site as well. You might actually parse them correctly.

Guys I need to amend the validation spec a bit. But to do so I need your opinions.

Right now Bitboy and I deal differently with addresses.

When Mastercoin-explorer displays the addresses for a certain currency_id and an address has not received any transactions for the given currency_id it omits the address from the results. As far as my application is concerned the address does not exist so it can't display it.

BitBoy's implementation however returns the address with a zero balance. Which is technically also correct.

Anybody has a reason to pick one over the other?

I think bitboy's approach is better (same behaviour of blockchain.info).
It means that I will have to change my implementation as well.

The problem is that I have no clue how I can find something that doesn't exist. I can't supply addresses that I don't know exist. I could query all currencies (there might be a lot in the future) and use data based on that but that would only bloat the verification-api without any real benefit.

I still vote to omit addresses that have no transactions for a certain currency_id.

The code news however is that this is already proven useful.

Mastercoin explorer has 2617.47620688 for 1AGFxUanxnWnrTiwLsY4NyvNZTv3RWFnfT but Bitboy has 2617.48620688
Mastercoin explorer has 200 for 1MBrNtFBw9QQ1owGsTs6Nd1iL1Err2H4yp but Bitboy has 199.99
Mastercoin explorer has 757.23987298 for 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 but Bitboy has 752.23987298

Much easier to find which transactions to fix now.

I will join the comparison game whenever my sell offer/accept parsing is done.
That's a great tool.

Once I finished the code I will put the site online. It should display an overview of all transactions that are parsed differently on all sites, we should all be able to use this.

[dacoinminster]

Bitoy sent his address via PM:

Hi dacoinminster,

Here is my msc address
1Fq37GNfyxSvnmye3QdxH6GpPAQ3enarfs

Thank you for including mymastercoins  

It may be a couple of days yet before I send the MSC. I've got a ton of other stuff to catch up on.

[Bitoy]

Hi Tachikoma

I've updated the parsing (all class A is now "peek and decode")  and Master Explorer and MyMastercoins has the same balances (yehey!)

Except for one address
15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby

MM=575     ME=570

It is TX
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc

btw First line of your API there is a null address with balance 5.0  
[{"address":null,"balance":"5.0"}

[zbx]

Yeah, that's a transaction that I botched a couple of days ago. The sequence numbers are ascending instead of descending.

[Tachikoma]

Hi Tachikoma

I've updated the parsing (all class A is now "peek and decode")  and Master Explorer and MyMastercoins has the same balances (yehey!)

Except for one address
15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby

MM=575     ME=570

It is TX
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc

btw First line of your API there is a null address with balance 5.0  
[{"address":null,"balance":"5.0"}

Woop! Awesome. As soon as I'm done with my current validation rewrite I will check out this transaction.

[grazcoin]

The problem is that I have no clue how I can find something that doesn't exist. I can't supply addresses that I don't know exist. I could query all currencies (there might be a lot in the future) and use data based on that but that would only bloat the verification-api without any real benefit.

I still vote to omit addresses that have no transactions for a certain currency_id.

If you don't find an address (which is a valid bitcoin address) in your database, simply report an empty address with all values 0.

[Bitoy]

Yeah, that's a transaction that I botched a couple of days ago. The sequence numbers are ascending instead of descending.

It is now valid because of the new specs in 1.2 "peek and decode". (Unless I read wrong

[zathras]

Yeah, that's a transaction that I botched a couple of days ago. The sequence numbers are ascending instead of descending.

It is now valid because of the new specs in 1.2 "peek and decode". (Unless I read wrong

Sorry guys, I've been snowed the last week or so.  I see JR has included my appendix in the latest revision of the spec which is great news - that means peek & decode is officially in so zbx's case in question would now be valid yep regardless of the bad sequence numbers (credit though; peek & decode was Tachikoma's idea, I just helped flesh it out and documented it ).

Note I'll need to cut a little code for this which I'll include in the coming Masterchest update.  Somehow my current implementation isn't quite up to scratch

Code:

 
...
Else
   If isvalidtx = False Then  '### fall back to peek and decode
      'peek and decode routine here
   End If
End If
....

[zbx]

Hi. I'm thinking of making a submission to the coding contest. Would people here be interested in having an implementation of the Mastercoin protocol in Go, specifically one designed to be run as a server process, e.g. to be used in a trading engine, and handling the Bitcoin protocol over JSON-RPC? The priorities in design would be to make it fast, lean and robust. Does the project need software like that at this point (assuming that I can write it well... I'm very new to Go)? Does it need another independent implementation at all right now?

[Tachikoma]

I believe there is a bounty for a FIAT/MSC exchange. Your software idea sounds like it belongs there. Exchanges need to be fast in order to function so Go might be a good fit

[zbx]

I believe there is a bounty for a FIAT/MSC exchange. Your software idea sounds like it belongs there. Exchanges need to be fast in order to function so Go might be a good fit

dacoinminster said (on Trello) that a Fiat/MSC exchange wasn't going to be a project goal for now.

[Tachikoma]

hmm weird. It's in the bounty topic.

[Bitoy]

Yeah, that's a transaction that I botched a couple of days ago. The sequence numbers are ascending instead of descending.

It is now valid because of the new specs in 1.2 "peek and decode". (Unless I read wrong

Sorry guys, I've been snowed the last week or so.  I see JR has included my appendix in the latest revision of the spec which is great news - that means peek & decode is officially in so zbx's case in question would now be valid yep regardless of the bad sequence numbers (credit though; peek & decode was Tachikoma's idea, I just helped flesh it out and documented it ).

Note I'll need to cut a little code for this which I'll include in the coming Masterchest update.  Somehow my current implementation isn't quite up to scratch

Code:

 
...
Else
   If isvalidtx = False Then  '### fall back to peek and decode
      'peek and decode routine here
   End If
End If
....

To make coding shorter, I did peak and decode to get the data address then get the largest sequence as the receipient address.