Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 125. (Read 448462 times)

• In the bitcoin protocol, "sent tx" has no meaning to the consensus if the tx is not confirmed (e.g. double spend, hanging transactions, etc). Time of a sent tx is only the time of the corresponding block.
• It is not totally true that the sender has no control when the transaction are processed. See  https://blockchain.info/tx/d1a7922993d7ed20a597b931fe30b10fca08382ecbb087f6325e71ea08750758 which paid 0.5 bitcoins fees to make sure that the tx is really confirmed, while 20 seconds later (according to blockchain.info timings) https://blockchain.info/tx/935dfdcb31237ab4435877f2c6d28dd3906974753b0072c6921fa30c8239e4f3 had no fee, and it was not confirmed on time (although there was theoretically enough time). Obviously if there was no block found in those 18 last minutes, also the 0.5 bitcoin fee would not have helped.
• If we decide to extend the deadline, I would prefer that it is extended a little longer - to the last block confirmed before 1.10.2013. Then it would be more fair ...
• There is nothing like "receive Mastercoins" for the bootstrap purchases. The mastercoin protocol says that they are simply there, and we use this information. There is no need for extra transactions.
• At this point I agree that  J.R. Willett is the one to decide on the exact interpretation of the spec, so please ..

Just in case you don't know it and to avoid spending bitcoins, are you doing this on the testnet blockchain ?

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

I concur that everyone who sent the coins prior to the deadline should receive Mastercoin since they performed according to the spec, and they have no control when the transactions are processed by the system. It is like deadlines of postmark vs. received. The postmark is an objective measure by a third party and under the control of the sender (fair) while a recipient can claim receipt whenever it suits them, and the sender has no control over what happens once the item is placed in the mail (not fair as a deadline).

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.

Answers to both issues you addressed below can be found in the blockchain, and for the protocol, there is actually nothing else (with consensus) but the blockchain.
You claim that the sending time of the tx which were included in block 255362 is before midnight but there is no way to prove it, as the timestamps are not in the blockchain. Those tx could have been available to my node only after midnight. I could easily report that tx from block 255363 or even later were seen on my node and claim that they were sent before midnight (although blockchain.info node saw them later). I see no reason to prefer blockchain.info node over my node.
Looking at the blockchain also answers your seconds question.
I would suggest a general guideline saying that we check the tx according to their order in the blockchain, and whenever a tx is invalid or it doesn't have enough funds, it is ignored.

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

The miner chooses in which order to put the transactions. (If there are dependencies, a tx must come before those that depend on it.) Once he sets the order it is a fixed property of the block, putting the txs in a different order would result in a different Merkle root and thus invalid block hash.

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

Transactions in a block are ordered so it could use the first transaction.

Or the mastercoins could be destroyed in this case.

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?

For now, this really doesn't have much effect.  But in about 5 years - this loss of transaction is going to cost someone about 13 million dollars.  Better take a moment to get it right.  I'd include them.  Leaving them out exposes you to a claim later by a fast talking lawyer who will argue ambiguities in the spec should be enforced against the author rather than the investor.  He'll win with that line of reason.  The writer of the document had the ability to set it correctly - and that failure results in the liability shifting towards him.

Now, no lawyer will touch this case.  When it is worth $13 million there will be a long line of shark attorneys at the courthouse filing paper.  

I know it is a stupid way to settle the question, but it is worth considering.  

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)

OK - these instructions were very helpful, I managed to setup pycrypto very easily. Only difference is that the article is a bit outdated and uses the 2.1.0 version of pycrypto.

Here: https://www.dlitz.net/software/pycrypto/ you can find the latest one (2.6) and the instructions are basically the same. You download and uncompress the file, run terminal in the path of the uncompressed folder and use python commands (of course you are supposed to have python installed before that) for building and installing the package.

Now let's see if I can send some MSC...

Willet, can you add a link to the FAQ to the op?

Block 255362 has the timestamp of 2013-09-01 00:00:58 which is after end date, so it should be also refunded.
If we change that, this would be already considered as a modification of the spec (and we would like to avoid that, like bitcoin avoids hard forks).

I have seen somewhere the suggestion that some early investors could send valid mastercoins to those addresses.

I am using 1377993600 as well, so I don't understand the difference in the results.

Here is my detailed calculation:
===================
1. check https://blockchain.info/address/1PA8qhEzW7to6EeqBAdhVZYGbVj2MfmN2n
2. The relevant tx is https://blockchain.info/tx/546a406a131089e7c2f27d34a93a4d27441d98d096404d6737c5ad5b5e61a09b
3. That tx was included in block 249498 which has timestamp (in the blockchain) of 2013-07-31 21:32:31
4. converting the block timestamp to epoch: 1375306351
5. calculate difference between tx and end date: 1377993600-1375306351=2687249 sec
6. calculate bonus percent: 10%*2687249/(3600*24*7)=44.432027116%
7. calculate total amount of mastercoins: 1600000000*100*(1+0.44432027116)=231091243385.6 -> 2310.91243386

I just assume you took a different timestamp for the tx.
It is important to note that the only relevant timestamp in the blockchain is the one of the corresponding block.
Any other "Received Time" is node-dependant value (e.g. one may get the tx few seconds minutes or even hours before of after blockchain.info, and there is no way to verify it), and that value should be ignored.

The key phrase here is "hopefully start the discussion going in the right direction" no one is proposing a "focus" on marketing. As someone who as worked as a developer and marketer, I am cautious not to develop tunnel vision by planning for success. I think planning ahead is beneficial. I can't say much for letting day to day operations drive out planning. Waiting till the project is complete before thinking about a plan to get the word out is ill advised at best.

I am sure you all have heard of bitshare, bitcoinx e.t.c?  https://docs.google.com/document/d/1RLcjSXWuU9vBJzzqLEXVACSCdn8zXKTTJRN_LfoCjNY/edit?pli=1, https://github.com/InvictusInnovations/BitShares...they are making progress and I am sure there will be more competitors: The point is the reason you are working to make this successful is that hopefully this catches on and immense value is created. Problem is "catching on" does not happen by coincidence especially when there are competitors who might be at an advantage by being the first movers and capitalizing on the network effect.

There is a fundamental flaw with the logic saying that "if you build it they will come" if you have bigger competitors who already have an established name and network effect. The network effect concept plays a big role here because it determines how easy and why the customers or users will want to switch or use another technology with similar functionality. A problem with adoption might develop because there is a huge cost involved for customers to switch from one complex system to the next. Case in point bitcoin-litecoin-primecoin.



So like I said, the idea is not to start building a marketing campaign at the moment, because you don't want to "paint the idea". The idea is to have a plan ready to go on, once the usefulness of mastercoin is proven. I don't think its wise to wait till full functionality to start planning

"failing to plan is planning to fail"--alan







What about the suggestions of using op-return to alleviate the UTXO set issue in a customized client? you should stress this in the details of the bounty for development of the client.

I am the official forum user for http://www.BuyMastercoin.com.

We launched BuyMastercoin on Aug 31st in order to provide a safe and reliable place for people to exchange Mastercoins since after this date you could no longer buy Mastercoins through the exodus address.

Our current format is over the counter yet we plan to launch a real-time Mastercoin exchange soon. We will allow people to buy and sell Mastercoins using dollars, euros, litecoins, altcoins, ripples, bitcoins and more.

We want to help build the Mastercoin ecosystem, especially now that the client is not yet developed and has some time to go. We also look to provide valuable information to the Mastercoin community such as MSC/BTC price charts, and tools for Mastercoin derived markets.

Visit us at http://www.BuyMastercoin.com and subscribe for news updates and to sign up for our beta.

For up to date pricing information or to receive an exact price quote please email us through our contact form.

Thank you.

-BuyMastercoin.com Team

For maximum transparency, here's a message I just sent to the oversight board: