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

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.


Much easier to find which transactions to fix now.

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

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

I'm not even sure I'm 100% behind it, but it would make parsing much more straight forward.

The thing I might not have explained enough is that I think this artificial lag should be protocol wide if we would even consider doing it. This would mean that Simple Sends that receive and send coins in the same block would also be invalid if the proper amount of the outgoing coins was not sufficient before this block, etc.

Grazcoin, Zathras, Bitboy could you please join the discussion on PR #1 here https://github.com/mastercoin-MSC/spec/pull/1

Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.

The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.

I hate chance, and I would like to eliminate it as a factor for Mastercoin.

My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.

Current situation
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.

If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.

Artificial 1 Block lag
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.

However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.

I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better.