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

Ok thanks again Tachikoma.

Zathras, it seems I am lacking some validations on my end on Purchase Offers that you do have. Could you take a look at this post and tell me why Masterchest rejects that offer?

Edit: I'm guessing this is because there is no selling order to match to? You consider that an invalid transaction? I think this is a good way to go, shall I add this to the spec?

The person with the highest position in the block. This already has been decided a long time ago and goes for all transactions types.

My guess is full development of the protocol could take 1-3 years. We (the Mastercoin community) are all doing something to accelerate this, whether it be clearing up misconceptions in other fora, participating in the giveaway or actively volunteering themselves to run a manual orderbook, to developing incentivized and structured bounty systems and evaluating the huge talent pool that have been asking how they could help, or of course, encouraging the developers (best accomplished by using and buy testing their work!).

Play your part

Another scenario.

User A sells 10 msc
User B and User C buys 10 at the same (block) time.
Who gets the 10 msc?

I'm thinking it should be order by time, then address.

+1
User D's transaction should be invalid.

Good to know our order book matches




I only recalculate  and validate dev mastercoins only if the exodus address sends msc.

Developers; I've been thinking about invalidating Purchase Offers which want to buy from a Selling Offer when the Selling Offer is exhausted. Normally you adjust the amount bough to the total amount for sale. But it's not stated what to do when the amount is actually zero. Technically it doesn't matter anyway because both transactions have zero impact on the balance but just to let people know what's going on, and make sure they don't end up paying I would still like to invalidate these type of transactions.

Just an example to make sure everybody understands me.

User A sells 10 MSC
User B buys 8 MSC and gets them
User C buys 2 MSC and gets them
User D sends his request for 5MSC just a little after C and gets added behind him in the block.

Right now user D's transaction would come through but the accepted amount would be 0 MSC. I would propose to invalid this transaction so it's clear this offer is sold out.

I think I need to implement two more validation cases, mainly around reserved balances, and then it should be done on my part. However this is where the fun starts. We will need to do a whole lot of testing to make sure we got all the edge cases. I think the best way is to start trading for real and see what happens. We should have three sites online very soon that will be able to parse the transactions so we can check if we all have the same idea.

I think the ultimate question will actually be; when will the Mastercoin users trust the MSC <> BTC exchange protocol enough to actively choose this over doing everything by hand. I'm afraid this might be still a long way out. Technically you could use it right now.


See this is what I currently hate about doing all the MSC stuff. I'm currently switching between projects (wallet, site, validation site, library) and I often forget I was doing something else before switching energy. It's just too much stuff to do. I modified it and I now get the proper amount. Although if we want to do it totally correct we should round the last digit up so in theory it should be 8932.02250395 instead of 8932.02250394. If we can agree on this I can finally consider vesting to be perfect


I need to do a fresh import & validation on the Purchase Offer code. These transactions were verified using older code an I need to recheck them. It is probably fixed by now but I need to look into it when I can find enough time to do something useful. I'm still having huge issues getting proper block numbers from Bitcoin-ruby which is really a time sink at the moment, once I fix that I can move on

Thanks   Re my wallet, not too long I hope - I want to make sure we all (the devs) are seeing exchange transactions the same way first.

Wow! That looks awesome!  I can't wait.  Any eta on releasing your wallet for testing?

It's difficult to estimate - there's a lot of effort going into it but we want to make sure we do it right. 

I've hardcoded for test MSC only in my wallet (which I haven't even released yet) & I think Tachikoma has done the same - we'll need to see reliable and repeatable test MSC distributed exchange transactions happening that we all agree on - only then would we allow exchange of real MSC.

Speaking of which - Tachikoma, I'm keen to identify why our orderbook states don't match.  I've taken a quick look at Bitoy's site and his orderbook state looks like mine - I'll look into each transaction to see if I can figure out where we differ.  Is your orderbook on mastercoin-explorer your latest? 

I've uploaded the working copy of my next update to https://masterchest.info/sneakpeek - it looks a little different as I skinned it to look more like my wallet.  You can see my order book & current parsing of exchange transactions there.  Note this is not the completed update, just a WIP but it'll at least allow you to see what my engine is doing with the transactions.  Oh and on the subject of the dev MSC calculations you can use https://masterchest.info/sneakpeek/lookupadd.aspx?address=1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P to check your dev MSC numbers against mine (as at time of latest block).

Thanks!

It's not just you. Traffic has increased dramatically for Mastercoin. The Giveaway thread has had more traffic this past week than ever before. It's only a matter of time before I will not be able to keep up. These are good things but it I suspect our services will be replaced soon by automated techniques which will be better for us because there is a lot of other contests and jobs to do now.

Question to all devs working on creating a distributed exchange: in your opinion, what's a realistic timeframe for a decentralized MSC <> BTC exchange? 1 week? 2 weeks? 1 month?

Together with Pouncer I'm running the Mastercoin order book. Adding and editing entries is done manually and takes quite a lot of time.
So I was thinking about setting up a self-service order book where people could add, edit and remove orders on their own. This would be done by signing messages with their Mastercoin addresses so there would be no fake orders (balance of addresses can be easily checked using the Mastercoin-explorer API).

Creating such an improved order book would take some time and effort and I'm wondering if it makes sense to do this at this point in time. If we have a working decentralized exchange within a week or two it might be better to continue with the current order book. But if we're talking about a month then I guess it would make sense to invest time in an improved order book. After all, Mastercoin trades are really booming right now.

So what's your estimates, when will we see a decentralized MSC <> BTC exchange?

Armory has coin control. It's one of the expert features.

Anybody who is using the bitcoin protocol for anything other than shuffling money is going to use the smallest standard transaction. Parsing for an output of a specific value would narrow it down, sure, but I don't know if it'd be worthwhile as the "flag" that identifies a mastercoin transaction - it would only do a decent job at separating transactions where moving bitcoin is the main intent from transactions associated with blockchain-notary, colored coin, mastercoin, and of course the losing rolls of Satoshi Dice.


I have an idea that may actually solve the concern with mastercoin that the exodus address is "privileged" due to receipt of bitcoin for every mastercoin transaction. It should work conceptually, however I'm not sure how it would affect mastercoin explorers and if the implementation of validating the mastercoin transactions would be feasible.

At a predetermined blockchain height (by which time the exodus will have unspent outputs totaling 0.0 BTC) the private key of the exodus address is made public. Any mastercoin transaction above the height at which the exodus address's private key is revealed will be identified as follows:

The output of a mastercoin transaction that currently goes to the exodus address will be replaced with an address that is generated on-the-fly in a manner that allows the movement of mastercoin to be publicly verified, yet the bitcoin output claimable only by the sender. The "identifying" output will be to the address that is generated by combining the public key of the change address with the private key of the exodus address (see Casascius's "Key Combiner" in the bitcoin address utility). The way this works is that an address is generated with the private key of the exodus address with the public key of the change address - however in order to spend the bitcoin sent to that address, BOTH private keys are required. The result:

1.) Mastercoin transactions no longer make donations to any entity (and not at the expense of creating unspendable outputs).
2.) Mastercoin transactions would not be deprioritized (or left unconfirmed) due to reuse of the exodus address.
3.) Potentially very good for mastercoin's image. Maybe it would feel much less centralized?
4.) Significantly more difficult to calculate balances (correct me if I'm wrong here - speculation)
5.) Requires a change/4th output.


Few other notes while I'm thinking about it:

• Mastercoin transaction identified as a transaction in which the change address, when combined with the private key of the exodus address, produces an address that also received bitcoin in that transaction.
• Probably some interesting things that can be done with redeeming the bitcoin sent to the "identifying" address. Spending the bitcoin from that address can be defined as some option/feature/choice that the sender can make. (or maybe a game, the sender bets x mastercoin and sends it to the opponent. The opponent has to spam this address with the intent of keeping the sender from confirming a transaction to retrieve his deposit. If address emptied before agreed upon time limit/# of blocks, mastercoin is "charged back" and sender keeps extra bitcoin in identifying address. If address isn't emptied, opponent wins the mastercoin minus anything sent to the identifying address.)

https://bitcointalksearch.org/topic/miners-time-to-deprioritisefilter-address-reuse-334316


This is an interesting problem to solve.

Without the exodus address, we can just parse the block looking for .000006 transactions.  (Right now I just check the exodus address for transactions)

Thoughts?

I've run some test cases and I can get your number - same as before mate, you're using 9 decimal places in your dev MSC total.

In this part of your formula you are effectively multiplying by 56316.223576222 - note the additional decimal.  You can fix your code by changing:


to either of:


I've been hammered with the day job this last week but I can see there is some stuff I need to catch up on the main thread (eg Luke's patch).  I'm determined to get the Masterchest update out today, at least to the website - once I've got that finished I'll catch up on what's been happening.

Thanks!

Tested the new peek and decode algorithm.   This transaction looks valid.

fd093d901c4baf20ea2525fe3b36b2519b9a7915683b45b996023fe2b5dd04e6


Date: 11/15/2013 12:57:28 PM      
Sender: 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd      
Amount Sent: 0.20000000 MSC      
Recipient: 1P8GMhC3qYkuvRRBsS5gqGegT7GvQoxAwY    

I have almost the same number
8932.0225039472534


(1 - (0.5 ^ (  (1385856000 - 1377993600)    / 31557600))) * 56316.23576222