Quote from: ripper234 on July 31, 2013, 08:04:48 PM

I would also add a section that attempts to model the economic behavior and effects of MasterCoin. How many mastercoins will there be now? Ever? How is the expected rate of Bitcoin-Mastercoin expected to behave under a few scenarios? Didn't you have such text in the first version of the paper?

The number of MasterCoins is defined as the number which are purchased. The last revision of the paper did have a complicated scheme to make sure bitcoins stayed valuable long enough, but I took it out since that seems like less of a concern now that bitcoin is more mature.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

0. What is the MasterCoin three letter abbreviation? You should clarify that your original MasterCoin, and the new "usurper" MasterCoin are not related in any way, and that you have prior claim to the MasterCoin name.

I did mention the usurper in the OP on this thread

I haven't decided on a three-letter abbreviation. I'm open to suggestions.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

1. Aren't you begging the question?

Quote

Summary
-----------

The new protocol layers described in this document
...
Will richly reward early adopters of the new protocol, in proportion to how successful it is.

Assumptions
---------------

New protocol layers on top of the bitcoin protocol will increase bitcoin values, consolidate our message to the world, and concentrate our efforts, while still allowing individuals and groups to
issue new currencies with experimental new rules. The success of any experimental currency protocol layer will enhance the value and success of the foundational bitcoin protocol.

Hmmm. Maybe. I'm open to suggestions for rewording that.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

2. Fair release schedule

You should pre-declare a date on which you will reveal the precise exodus address. Since the protocol gives bonuses to early adopters on a per week (and part of) before August 31th 2013, which isn't too far away, the address should be revealed way before that, and ample time (at least 1-2 days, preferably 7 days) should be be given where no extra bonus is given. In other words, people should have at least a few days from the moment the exodus address is revealed, in which all funds sent to the exodus address are capped in the amount of Bitcoins they send. There can be a bonus for early adopters, but everyone should have a fair chance to invest.

The cat is out of the bag now. The exodus address is posted in the latest revision of the spec and in the OP here. (The one Ripper was looking atbefore didn't have the Exodus Address in it)

Nobody has sent any coins there yet though, and I am delaying my own purchase so I don't make everyone mad by getting the best exchange rate moments after the announcement

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

3. Who has the private keys for the exodus address? If it is you, this should be stated explicitly. It can also be a m-of-n address where there are n "MasterCoin project directors". Or rather, is this a sinkhole address like the original MasterCoin design, which has no feasible private key? (instead of this, you can send to an unspendable script which is guaranteed to be a sinkhole, not just computationally infeasible)

The Exodus address is controlled by a wallet in an offline-only computer running the armory client. I'm the only one with access right now, although my family does have a procedure to recover that wallet if I die.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

4. Hiding MasterCoin Protocol Data in the Block Chain
I would rename it to Encoding MasterCoin Protocol Data in the Block Chain.
I think this section deserves some more elaboration on motivation and technique.

5. Fake bitcoin addresses require more explaining. How does one generate a fake address? Where did the magical "20 bytes" come from?

The hash of the public key which becomes the bitcoin address is 160 bits (20 bytes) plus a checksum and version number. You can read about that here: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Basically, I'm replacing that 20 bytes with my own data.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

6. Using block times gap to encode transaction is vulnerable. A coalition of miners might collude in order to postpone some of a group of transactions that were broadcast to the network at the same time. This might also happen naturally as network traffic grows - we do not know enough at this point to predict how fast transactions will get mined, and how that would depend on fees.

That is an interesting attack vector. Note that using sendmany avoids this possibility. Also, colluding miners might be able to corrupt a transaction which is broken up, but they couldn't change it.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

7. I think that the Saving/Guardian model, while perhaps not adding anything qualitative to Bitcoin (it can be "implemented" by correctly securing and backing up your private keys and passwords), does add some nice ease of use to the protocol.

Thanks!

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

8. "Selling MasterCoins for Other MasterCoin-Derived Currencies" seems to lack a time limit parameter, by mistake I assume.

Offers to sell are good until cancelled under the current spec, although that could easily be changed, I suppose.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

9. "Registering a Data Stream" can use some motivational example. When would someone want to "publish the price of Gold" in the blockchain? What does this mean? (which Gold price? His price?)

Data stream providers make money when people bet on their data streams. Presumably they would get the price of gold per ounce from public sources.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

10. "Only the first payment sent from that address in a given day (as determined by block-chain timestamps) will be considered ticker data" - why is the timespan of "a day" special here? What does it mean to "be considered as ticker data"?

After reading ahead, I understand the motivation of the division to days is the aggression factor of trust funds. It should be noted at this point of the paper ("Tickers and the reason for their granularity will be explained later on").

I don't want a ticker flooding the block chain, so I chose a day, since a lot of medium-term traders use that timescale by default. If a ticker published 10 updates in a day, the protocol would only look at the first one (the rest would be ignored). I agree that the day-limit could use better explanation in that spot.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

11. Bet fees ("The other 0.5% goes to the creator of the data stream") - These should be configurable by the stream owner. I should be able to create streams with arbitrary fees.

I like that. I was trying to keep things simple, but this would be a fairly easy change to make.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

12. Aggression factors - when during the day do the trust funds take action? One idea is at the end of each day, or (giving the data sources ample time to publish data whenever they want during the day).

I meant to mention in the paper that the protocol actions are calculated when the ticker sends the data, since the data is known to be accurate at that time.

Quote from: ripper234 on July 31, 2013, 08:04:48 PM

I suggest giving an option for alternate aggression tactic - instead of increasing the buyout each day, simply buy X% of the relevant currency each day, without increasing X. It is not immediately clear which aggression tactic is "better", so it would be prudent to support both and let creators of coins decide which tactic they prefer. More variations on the aggression tactic is possible (you can allocate a protocol field to the tactic, and not necessarily decide on all the precise tactics now, but allow room for improvement in a future MIP (MasterCoin Improvement Proposal).

I definitely would like to experiment with other ways of doing this. I modeled my method after the integral gain of PID loops.