Wanted: Fixup of the Data Feed / CFD spec

[ripper234]

I have a few issues with the Data Feed and CFD spec is written today. Would someone care to submit a pull request and fix these issues? :

1. The 0.5% fee for using a data feed in a CFD/bet is only mentioned as an afterthought. It should be emphesized when introducing the concept of Data Feeds.
2. Instead of a fixed, arbitrary 0.5% fee, the fee author should be able to determine this number.
3. The number should be adjusted according to the period of time the feed is used. Meaning, if using a price feed to lock in a bet or CFD for 1 month would cost you an X% of your principle, then using the same price feed for 12 months should cost 1-(1+X)^12. Currently the spec means that using 12 1-month CFDs is 12 times more costly than 1 12-month CFD, without any good reason IMO.
4. The CFD definition should make it clear how one can take an initial position in Mastercoin, and completely replace that position with a position on the other asset. I detailed how this can be done in a wiki article. The current spec for CFD is just a placeholder, and we need to flush out a lot more details before we can officially say CFDs are in our spec.
5. We need to think about expiration dates for the CFD. I think that the spec should contain an optional expiration date by either parties. This is optional - there is no reason why 2 parties can't keep a single CFD open for an arbitrary amount of time.
6. We need to encode a way for the parties to specify their "risk/liquidation threshold". In the "Pegger vs Saver" example in the wiki, the Pegger is safe as long as there isn't a single price swing that brings the total locked funds below 50% of the principle. So, each party to the CFD should be able to specify the threashold he is comfortable with. A conservative Pegger can specify that if the funds drop below 70% of the principle, the CFD is broken up, while a risk taker can specify 55% of the principle as his threshold.

[dacoinminster]

I think there's definitely some room for improvement on the CFD spec, and I'll look at implementing some of these suggestions right away. I'm doubtful however that we can come up with a solution that gives the "pegger" the kind of stability you imagine in your example. The problem is that bettors will want to exit their positions, breaking the peg. There may be a way to seemlessly provide new bettors for the pegger. I need to give this some more thought.

[ripper234]

We can have contracts that are time-locked and thus not allowing any one side to break the contract. Once the contract finishes, we can have an auto-renewal policy that will automatically match the CFD request with the best outstanding bid for a CFD that matches the required parameters.

I really think this can be made into an air-tight implementation of "backed/pegged currencies".

I forgot one additional issue - the spec speaks of "24 hours periods" that count for the price (the first price in a day counts). In reality we'll have much finer granularity for price feeds, and CFDs will be able to use this finer granularity to reduce risk and terminate CFDs that are approaching their limit. I don't think the spec should place any special meaning into "1 day" periods, each feed provider will provide their own update frequency anyway.

[ABISprotocol]

Here are some additional thoughts regarding fees that you may wish to consider.

[dacoinminster]

I was trying to avoid attracting day-traders ("hyperactive chart-monkeys"). I think we need some kind of time limit on update frequency. What would you suggest?

[mindposeidon]

Dear Ron:

You've got the neurons brother this post rocks!

Best,

Harold

On Fri, Dec 13, 2013 at 1:31 AM, Ron Gross notifications@github.com wrote:

I have a few issues with the Data Feed and CFD spec is written today. Would someone care to submit a pull request and fix these issues? :

1. The 0.5% fee for using a data feed in a CFD/bet is only mentioned as an afterthought. It should be emphesized when introducing the concept of Data Feeds.
2. Instead of a fixed, arbitrary 0.5% fee, the fee author should be able to determine this number.
3. The number should be adjusted according to the period of time the feed is used. Meaning, if using a price feed to lock in a bet or CFD for 1 month would cost you an X% of your principle, then using the same price feed for 12 months should cost 1-(1+X)^12. Currently the spec means that using 12 1-month CFDs is 12 times more costly than 1 12-month CFD, without any good reason IMO.
4. The CFD definition should make it clear how one can take an initial position in Mastercoin, and completely replace that position with a position on the other asset. I detailed how this can be done in a wiki article http://wiki.mastercoin.org/index.php/Contracts_for_Difference. The current spec for CFD is just a placeholder, and we need to flush out a lot more details before we can officially say CFDs are in our spec.
5. We need to think about expiration dates for the CFD. I think that the spec should contain an optional expiration date by either parties. This is optional - there is no reason why 2 parties can't keep a single CFD open for an arbitrary amount of time.
6. We need to encode a way for the parties to specify their "risk/liquidation threshold". In the "Pegger vs Saver" example in the wiki, the Pegger is safe as long as there isn't a single price swing that brings the total locked funds below 50% of the principle. So, each party to the CFD should be able to specify the threashold he is comfortable with. A conservative Pegger can specify that if the funds drop below 70% of the principle, the CFD is broken up, while a risk taker can specify 55% of the principle as his threshold.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/10 .

Thanks & Best wishes,

Harold http://about.me/haroldglascock/#

[ripper234]

@ABISprotocol can you elaborate how this is related to this specific github issue? Or are you just posting this in general?

@dacoinminster Day traders are an essential and important part of the eco-system. They provide liquidity. I think our first goal should not be supporting High Frequency (algorithmic) Trading ... but sub-day traders should definitely be included. Later on we might even support HFT ... but I won't get into that because it's not a design goal at this point.

Beyond the added liquidity in sub-day trades, the important part is that this increased resolution will enable you to play with much lower leverage and still have the same level of security. To showcase how that's important, think about the other direction - let's say we only worked within 30 day time point delta - a price point every 3 days. The odds of an asset moving very large price movement is much bigger within that period, so a price movement that would leave the "Saver" in my example unable to collect on his dues because the underlying asset changed to much as much more likely. Using a smaller temporal resolution is just better ... and should be kept to the feed and CFD issuers, not in the protocol itself. The more magic numbers we can eliminate from the protocol, the better - and "1 day" is just a magic number that shouldn't be there.

[zynis]

Isn't the a physical limit due to bitcoin block creation and bitcoin tx fees enough? On Dec 13, 2013 1:29 AM, "dacoinminster" notifications@github.com wrote:

I was trying to avoid attracting day-traders ("hyperactive chart-monkeys"). I think we need some kind of time limit on update frequency. What would you suggest?

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30476433 .

[ripper234]

Dominik - you're correct that the current Mastercoin implementation as a Bitcoin backed system is limited by the 10 minute Bitcion interval. However we can achieve higher resolution with other more complicated designs, if we need to. We can do various side chains, and it's even possible we'll migrate the entire project some day to a faster blockchain for various other reasons.

It's too early today to tell how this will evolve - right now my focus is on getting it within an ~ hour resolution, not minute.

Ron Gross Executive Director, Mastercoin Foundation mastercoin.org | ripper234.com Schedule my time at meetme.so/RonGross

On Fri, Dec 13, 2013 at 8:29 AM, Dominik notifications@github.com wrote:

Isn't the a physical limit due to bitcoin block creation and bitcoin tx fees enough? On Dec 13, 2013 1:29 AM, "dacoinminster" notifications@github.com wrote:

I was trying to avoid attracting day-traders ("hyperactive chart-monkeys"). I think we need some kind of time limit on update frequency. What would you suggest?

— Reply to this email directly or view it on GitHub< https://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30476433> .

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30522378 .

[dacoinminster]

I'm really worried we'll get a lot of flack for "abusing the block chain" if we allow the data feeds to move too quickly. I had hoped daytraders would use centralized websites while people with longer time-horizons would use our system.

I chose once per day, because the definition of a day-trader is someone who trades more frequently than that. I think we need to get wider feedback before changing that time window.

[zynis]

regarding centralized exchanges are any of the implementations on github at a stage (or close enough) were they can be used by a hosted exchange to facilitate input/output with the blockchain?

meaning some kind of API exists for interaction between the wallet software and an exchange transaction server for receiving / sending MSC?

i know they haven't been scale and security tested but if an API exists that someone like cryptsy can integrate their system I know people make feature requests on cryptsy to add virtual currencies.

i made one for mastercoin, so if you all think we can move with this, I can share this out and get a bunch of votes

https://cryptsy.freshdesk.com/support/discussions/topics/45070

Thanks,

Dominik Zynis Skype: dominik.zynis USA: +1-415-800-4155 dominik.zynis@gmail.com

On Fri, Dec 13, 2013 at 5:21 PM, dacoinminster notifications@github.comwrote:

I'm really worried we'll get a lot of flack for "abusing the block chain" if we allow the data feeds to move too quickly. I had hoped daytraders would use centralized websites while people with longer time-horizons would use our system.

I chose once per day, because the definition of a day-trader is someone who trades more frequently than that. I think we need to get wider feedback before changing that time window.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30526570 .

[ripper234]

We should have really as minimal centralization as possible ... zero, really. It is an "element of synchronization" if we try to protect the blockchain against too much scale by introducing magic constants and artificial limitations.

Mastercoin should be a free protocol designed top down to answer our needs. I am treating the Bitcoin blockchain as a "proof of concept" data store, but there is really no reason to assume it is the best one for us long term ... but rather just the best one to get us started quickly. Peter Todd is going to do some major analysis here and explore our alternatives.

I'm fine with collecting any feedback you want (you can post this on the main bitcointalk thread), but the key point I'm making is this - let not try to "police Mastercoin" in any way. Let it be usage agnostic just like Bitcoin is usage agnostic. The less we assume about potential usage, the better.

Specifically regarding this issue, I maintain my strong opinion that an hour's granularity is way more powerful for our users than a day's granularity.

Regarding centralized exchanges - I think the basic send/receive functionality is pretty solid by now. If and when we make contact with a centralized exchange that is willing to adopt us (nobody has picked up that $2000 by now ?!), then we will work out the fine details with them.

Dominik - that's a great idea to add the feature request - let's publish this ticket massively on all our channels. Perhaps even write a blog post about the $2000 bounty for the first existing centralized exchange that adds MSC support - I think people aren't aware of this. I posted on the support ticket that you opened.

Once we have a foot in the door with the first exchange, others are sure to follow quickly.

Ron Gross Executive Director, Mastercoin Foundation mastercoin.org | ripper234.com Schedule my time at meetme.so/RonGross

On Fri, Dec 13, 2013 at 9:51 AM, Dominik notifications@github.com wrote:

regarding centralized exchanges are any of the implementations on github at a stage (or close enough) were they can be used by a hosted exchange to facilitate input/output with the blockchain?

meaning some kind of API exists for interaction between the wallet software and an exchange transaction server for receiving / sending MSC?

i know they haven't been scale and security tested but if an API exists that someone like cryptsy can integrate their system I know people make feature requests on cryptsy to add virtual currencies.

i made one for mastercoin, so if you all think we can move with this, I can share this out and get a bunch of votes

https://cryptsy.freshdesk.com/support/discussions/topics/45070

Thanks,

Dominik Zynis Skype: dominik.zynis USA: +1-415-800-4155 dominik.zynis@gmail.com

On Fri, Dec 13, 2013 at 5:21 PM, dacoinminster notifications@github.comwrote:

I'm really worried we'll get a lot of flack for "abusing the block chain" if we allow the data feeds to move too quickly. I had hoped daytraders would use centralized websites while people with longer time-horizons would use our system.

I chose once per day, because the definition of a day-trader is someone who trades more frequently than that. I think we need to get wider feedback before changing that time window.

— Reply to this email directly or view it on GitHub< https://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30526570> .

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30528940 .

[dacoinminster]

OK. I created a poll for this on bitcointalk: https://bitcointalk.org/index.php?topic=369991.0

[B1tMaster]

I am just coming up to speed and will be more productive later, here are my first 2 cents:

1. I did not see anything for a contingency where data-feed that was used for creating a contract no longer exist by the time the contract is due.
2. People who create feeds, should be able to quote a price for use of their feed and there should prob be multiple feeds competing (reverse auction ) on the price. At the same time, higher quality feeds (more user support and "user rating" should be able to charge more.
3. I know quite a few traders as I come from 17 years of working in financial industry, they will love the ability go to long/short bitcoin vs other assets, but duration of transactions will have to include short periods. (maybe not phase one, but the infrastructure should be built or designed in such a way that it will be possible in phase 2x ). With that, limitation of Bitcoin blockchain to handle high volume of transactions will need to be addressed in some way. I am willing to work on this and we should have a few brainstorming sessions to see how to design it. How would like to participate in a brain-storming session?

On 14 Dec, 2013, at 2:42 am, dacoinminster notifications@github.com wrote:

OK. I created a poll for this on bitcointalk: https://bitcointalk.org/index.php?topic=369991.0

— Reply to this email directly or view it on GitHub.

[B1tMaster]

I am yet to understand (please point me to a write-up where it is defined: What does it mean "locked by block-chain". It prob means that a contract is written into the "meta-data" space of some small transaction that is done using "mastercoin" as mean of exchange? If so, when we talk about contract "liquidation triggering" , let me ask you, who is watching it to trigger? Are we assuming that the people who made the contract, have their desktop clients running and each client knows about the transaction they entered into and constantly monitor the "data feed" for updates that may trigger "liquidation" or other liquidity event for the contract?
Or are we implying that there is another central authority (some server) which takes on responsibility to monitor all currently pending active transactions and issues some other event which is recorded in block-chain at any time IT (third party) detects that an event related to a transaction happened? This could be a solution and thus, this third party monitoring platform may charge a small fee for monitoring a transaction that the other two parties entered into. The negative for such approach would be reliance on some third party to monitor a transaction.
Another approach would be, NOT monitor a transaction at all, but relay on a "feed provider" database of back ticks on his feed. (Ie: at the time of expiration of the contract, go back and request all data points from a data vendor and at THAT time to determine if there was any triggering point in the past that actually annulled the current contract and dissolve (close it ) back-dated to that point in time.

If none of the above methods are implied or being used, I would like to understand how it is proposed to work.

Dmitry.

On 14 Dec, 2013, at 12:25 am, Ron Gross notifications@github.com wrote:

@ABISprotocol can you elaborate how this is related to this specific github issue? Or are you just posting this in general?

@dacoinminster Day traders are an essential and important part of the eco-system. They provide liquidity. I think our first goal should not be supporting High Frequency (algorithmic) Trading ... but sub-day traders should definitely be included. Later on we might even support HFT ... but I won't get into that because it's not a design goal at this point.

Beyond the added liquidity in sub-day trades, the important part is that this increased resolution will enable you to play with much lower leverage and still have the same level of security. To showcase how that's important, think about the other direction - let's say we only worked within 30 day time point delta - a price point every 3 days. The odds of an asset moving very large price movement is much bigger within that period, so a price movement that would leave the "Saver" in my example unable to collect on his dues because the underlying asset changed to much as much more likely. Using a smaller temporal resolution is just better ... and should be kept to the feed and CFD issuers, not in the protocol itself. The more magic numbers we can eliminate from the protocol, the better - and "1 day" is just a magic number that shouldn't be there.

— Reply to this email directly or view it on GitHub.

[ripper234]

@B1tMaster , yeah, the issue of recovering from a feed provider that decides (or is forced!) to stop is not defined yet. This is a bit too large for the scope of this issue, so I opened issue #11 for that.

As to your question about "locked in" - regardless of the specific encoding, once you commit into a CFD, any operation you take that tries to spend these MSC is just considered invalid by the protocol, because it knows your funds are "locked". The funds get credited to your account only when the CFD breaks.

No desktop clients need to be running for liquidation. The protocol itself defines a liquidation trigger, and will break off the CFD when the right price data comes up. We're certainly not suggesting a central authority!

We do not need to go back and poll historic data from a feed provider. The feed provider embeds his data inside the blockchain, everything is timestamped, secure and unforgeable, so the protocol (and each client parsing it) can determine who has what. This does not need to be happening in real time ... I can leave my desktop client off and come back 2 months later, to find that my CFD was liquidated.

[B1tMaster]

Locked-In quesiton: My understanding thus far is that a MSC is a subclass of BTC ("coloured") or otherwise marked by metadata only understood by Mastercoin protocol layer. It still remains a valid bitcoin also. If this is correct, then funds are Locked-in by Mastercoin protocol only correct? They are not locked-in by underlying bitcoin protocol.

Which mean that a person who stands to lose his funds at expiration of CFD or just before it breaks not in his favour on mastercoin protocol level, can spend these funds on underlying bitcoin level at least partially? Or maybe I am missing something.

The protocol itself defines a liquidation trigger:

Somebody, somewhere will have to initiate a transaction which will send funds to one or more parties on CFD expiration or at the liquidation trigger time. Who is that "somebody". Protocol is not a running process on some server is it? it's a description of rules that clients implementing a protocol should follow. So I still do not understand what we mean when we refer to protocol itself doing something. Information indeed can be embedded in a block-chain to act-upon, but somebody must actually execute a transaction at the proper time?

And if we somehow going to use the Schrödinger's cat principle to only find out the outcome of CFD at the time when we actually look at it 3 months later in the wallet, then how would such transaction be back-dated to the point in time in which it actually should have happened in the block-chain? ( http://en.wikipedia.org/wiki/Schrödinger's_cat )

[ripper234]

MSC does not work like Colored Coins, but rather is a different encoding of MSC in tiny BTC amounts. The difference is that an MSC is never tied to a specific BTC/satoshi/output.

The funds are indeed locked only by the Mastercoin protocol.

However, your conclusion is incorrect. It is impossible to "spend the funds at the BTC level". I suggest you re-review the spec to understand why. The reasoning is just like it is impossible to send MSC by accident from a BTC wallet. In order to do any MSC operation, you need to send a very specific BTC operation that is interperted by MSC only.

Any of the two parties to a CFD can choose to liquidate the CFD. We may want to have two types of CFDs - those with this option, and those that only wait until expiration in a fixed future timestamp.

I'll be happy to explain this in more detail and answer any questions you have on skype.

No Quantum Mechanics is involved here :)

Ron Gross Executive Director, Mastercoin Foundation mastercoin.org | ripper234.com Schedule my time at meetme.so/RonGross

On Tue, Dec 17, 2013 at 9:18 AM, Dmitry Avramenko notifications@github.comwrote:

Locked-In quesiton: My understanding thus far is that a MSC is a subclass of BTC ("coloured") or otherwise marked by metadata only understood by Mastercoin protocol layer. It still remains a valid bitcoin also. If this is correct, then funds are Locked-in by Mastercoin protocol only correct? They are not locked-in by underlying bitcoin protocol.

Which mean that a person who stands to lose his funds at expiration of CFD or just before it breaks not in his favour on mastercoin protocol level, can spend these funds on underlying bitcoin level at least partially? Or maybe I am missing something.

The protocol itself defines a liquidation trigger:

Somebody, somewhere will have to initiate a transaction which will send funds to one or more parties on CFD expiration or at the liquidation trigger time. Who is that "somebody". Protocol is not a running process on some server is it? it's a description of rules that clients implementing a protocol should follow. So I still do not understand what we mean when we refer to protocol itself doing something. Information indeed can be embedded in a block-chain to act-upon, but somebody must actually execute a transaction at the proper time?

And if we somehow going to use the Schrödinger's cat principle to only find out the outcome of CFD at the time when we actually look at it 3 months later in the wallet, then how would such transaction be back-dated to the point in time in which it actually should have happened in the block-chain? ( http://en.wikipedia.org/wiki/Schrödinger's_cat )

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30764897 .