19 differences
 

Diving into the why right now

Edit: Are you counting incoming/outgoing payments towards the balance; or is this just exodus payments? If the latter that accounts for the difference

J.R. did the same thing with some early payments and I always considered those payments to be fine. If you want to pay more to send a transactions that is up to you. I personally don't think those payments should be considered invalid since it's your money that you are sending. However I will await J.R.'s answer as always


This should be fixed now.

I agree, but this is what J.R. told me. Could we get a clarification on this J.R.?

According to the discussion I had with J.R. the address that spend the most coins for a given transactions receives the coins.

I will compare those stats to the explorers data as soon as I can, will probably will have to wait till the weekend though.


I don't think anything should be set in stone; not yet at least. Too much needs to be added which could have effects on the previous transactions.

One of the things I was considering adding is an unified data format to the spec that we could use as replay and compare logs. It could also be used by other implementations to compare data. Basically adding a json-data format for Mastercoin.

I proposed the same mechanism but nothing came off it. So I did the same thing you did and just took a random address and promoted it to tesnet-exodus. In theory there is no reason to have an end date for the testnet address it could be a few years in the future which will make it easier for other developers to buy coins as they come on board.

Right now new transactions are added based on a cron job which I suspect might not be running well. I ran it manually now and will check why the cron job isn't working on it's own.

Thanks for the donations guys!


It tells you what Bitcoin transactions to send in order to do a Mastercoin transaction. You can see J.R's examples earlier in the thread. For now however I would want to ask you to wait until we have a better way to encode the data in the blockchain.


Awesome; I will go over it tonight. If you want to bounce ideas around for encoding data in the chain you can always hit me up with a pm or find me on irc

Hah no I think that's the only one; just think it needs to be added to the spec ^^

All the transactions up to 255365 should be added. But it's late so I did not check them all.

Sorry, wall of text incoming



I'm updating the code right now to include everything up to and including 255365. Nothing we can do about it now but I think the spec should be more pro-active to prevent problems like this in the future.


I always planned to release the underlying libraries but originally did not plan to release the source code to the website since it's just one implementation of the library itself.


This a thousand times. It's very easy to extend the functionality once there is a proper way to store data in the chain. I will focus on this next if nobody comes forward with a way to do this in the next few days.

I did not re-read it yet so forgive me if you already did this. Did you describe which timestamps to use for transactions and how to deal multiple transactions from the same user in the same block (especially if not all transactions can be satisfied)? (See discussion on the previous page)


I tend to agree. This project is barely started up and there is so much work to be done still. Although I really appreciate the gesture I think a formal bounty system would benefit Mastercoin better. I will see what I can do to just claim some bounties

Although I have no problems releasing my code but I really want to motivate others to build the same stuff I did. In order for Mastercoin to work a dialog needs to happen between developers. A lot of things in Mastercoin are open for interpretation and having multiple coders working on it in their own code might bring the problems to the surface. The other problem with releasing it now is that a lot of stuff that's written at the moment won't work when we implement a new method to encode the data and it won't work with anything other then simple send. I rather release it once these problems have been solved so it's at least future complete.

Lastly; thanks everybody for the compliments; I am happy that my work these past days is appreciated

I've just put a new version of the http://mastercoin-explorer.com online.

This version actually has some useful information. For one it can approximate balances for a given address and show what kind of transactions where done by them. As always this is an initial version of this functionality so don't expect any miracles

J.R.: I spend way more time on this then I originally planned. So to be honest I hope there will still be a bounty for something like this even if I build it already; not that that was the reason for me doing it to begin with

Cool, I've been researching the option of using OP_CHECKMULTISIG and just adding public keys with data in it. Haven't really got time to implement anything yet though since I'm mainly working on features on top of the explorer. Let me know when you have some code so I can update mastercoin-explorer to support it

The problem is that we don't have a voting mechanism to deal with decisions such as which block to use as end block. I think we probably need a Linus arch-type guy/girl who decides how to interpret the spec on such matters. For now it would make sense that J.R. has final say on these matters until an official coder is appointed or there is a mechanism in place where we can decide on such questions democratically.

Awesome, thanks for the information. I will look into this

How is this order defined; is it defined on the protocol level? If so I was unaware of this.

I have come across a theoretical problem.

Suppose 'user A' bought 10 coins from Exodus.

After the initial purchase 'user A' creates three simple send transactions for 10 coins to 'user B', 'user C' and 'user D' and relays them over the network. Assuming they all get included in the same block, to whom do the coins go?

Thanks for the detailed breakdown. I found a reference in the code where I was not using my constant for the end date and this date was 1 second off. The result is now: "Bought 1600.0 Mastercoins and got a 710.91243386 Mastercoins extra.". Which I think should be the correct amount.

Now I finally have the same output I'm considering parsing the blockchain and get some real data on the transfers happening and actual balances of addresses.


Ah; this was unclear to me. I have indeed been using the largest single one, this won't make the implementation easier. I think the spec could use one clear paragraph on how to parse the data with test vectors.


Although it's true that the spec mentions that all payments after 2013-08-31 will be considered invalid it does not tell us which time to use for this calculation. If we want to be precise then yes 255361 would be the valid answer. However people sending coins on 23:48 did so thinking they send the coins before 2013-08-31, which they indeed did. It seems more fair to use block 255362 since this would include all transactions _send_ before 2013-09-01. (and yes; perhaps 58 seconds of transactions that were sent after)

Ik heb hem deze keer moeten overslaan! Kan dus geen report uitbrengen

I would personally work a bit more on the implementation and protocol before focusing-in on the marketing message. I feel like we are still selling an idea without much practical implementation yet.

The biggest problem is still that Mastercoin data is encoded in a very parasitic way. I personally would not want Mastercoin to take off before this major problem is solved. This also means that I think we should be open to the idea that Mastercoin might have different rules on how to parse the blockchain data based on the block it's parsing. This means Mastercoin can adapt to changes in the Bitcoin protocol or when it needs to make internal changes.

Can I ask you what time you are using to define the end date? I'm using 1377993600. I think this is the difference between our results.


This should be fixed in the next release.


I've fixed this individual issue. But I'm going to run through all the transaction this weekend to make sure I got all edge cases.

On the topic of which transactions to refund; I would vote that all transaction up to block #255362 get included. The last block in August (255361) was 23:47 which seems not fair to use. The next one is #255362 which was a few minutes after.



The transaction lookup is only for real Mastercoin transactions; not transactions that are buying coins via Exodus.


Whenever I'm online I can be found at #mastercoin.