The data feed should be event-based. Whenever price changes or bid / ask is placed, such an event should be immediately reflected in the data feed.
Data feed stamping precision should be in millisecond or microsecond.
Topic: [POLL] What is the best policy for Mastercoin data feed update frequency? (Read 1427 times)
December 16, 2013, 01:41:52 PM
December 14, 2013, 04:02:12 PM
How will the update frequency cause a hard fork?
Or is it that you missed the disastercoin train and you a slinging mud around because you can't now participate?
Or is it that you missed the disastercoin train and you a slinging mud around because you can't now participate?
< Rationalization one, recorded >
December 14, 2013, 02:51:29 PM
I'm watching this closely, because the route you take will determine how fast you get hard-forked to irrelevance. This ought to be illuminating. Also, nice one about not wanting to "inconvenience" your disastercoin users, (to the detriment of everyone else) because hey, you're already hooking in to the Bitcoin hashing power, why limit your blockchain resource usage?
Just speaks volumes to what the priorities are here.
< Cue rationalizations about why disastercoin is doing the "right thing".... >
How will the update frequency cause a hard fork? Just speaks volumes to what the priorities are here.
< Cue rationalizations about why disastercoin is doing the "right thing".... >
Or is it that you missed the Mastercoin train and you a slinging mud around because you can't now participate?
December 14, 2013, 12:18:16 PM
I'm watching this closely, because the route you take will determine how fast you get hard-forked to irrelevance. This ought to be illuminating. Also, nice one about not wanting to "inconvenience" your disastercoin users, (to the detriment of everyone else) because hey, you're already hooking in to the Bitcoin hashing power, why limit your blockchain resource usage?
Just speaks volumes to what the priorities are here.
< Cue rationalizations about why disastercoin is doing the "right thing".... >
Just speaks volumes to what the priorities are here.
< Cue rationalizations about why disastercoin is doing the "right thing".... >
December 14, 2013, 07:26:44 AM
I think it would depend on the particular data feed...some commodity prices are more volatile than others.
It might cause problems if you implement an arbitrary timing....the data feed update interval should be determined by the initiator of the data feed itself.
It might cause problems if you implement an arbitrary timing....the data feed update interval should be determined by the initiator of the data feed itself.
December 14, 2013, 06:46:13 AM
Let's not try to police or safeguard Mastercoin (or Bitcoin).
Users and feed providers decide. There's no other way.
Every magic number in the protocol (e.g. "1 day frequency") needs to be eliminated.
Another target of mine is the fixed 0.5% fee on data feeds - there is no reason to have that fixed in the protocol rather than having feed providers compete for the fees.
Users and feed providers decide. There's no other way.
Every magic number in the protocol (e.g. "1 day frequency") needs to be eliminated.
Another target of mine is the fixed 0.5% fee on data feeds - there is no reason to have that fixed in the protocol rather than having feed providers compete for the fees.
December 13, 2013, 09:55:40 PM
I'd just let the open market decide if you can't come up with the ideal frequency (and I don't see a way how you could do that).
As far as I understand it, feeds anyways would be transactions in the Bitcoin network, so you'd need to use transactions which (if mined) will cost mining fees. If someone wants to send an update every 2 seconds, he'll quickly run out of funds then...
As far as I understand it, feeds anyways would be transactions in the Bitcoin network, so you'd need to use transactions which (if mined) will cost mining fees. If someone wants to send an update every 2 seconds, he'll quickly run out of funds then...
December 13, 2013, 09:36:09 PM
Let the user decide how many feeds they want to send. But charge a fee in the form of a higher dust to the exodus address depending on the number of seconds between feeds.
Ex.
Daily feeds dust is .00006 per feed
Hourly feeds .00006 x 24 hours = 0.00144 per feed
Minute feeds .00006 x 24 x 60 = 0.084 per feed
Ex.
Daily feeds dust is .00006 per feed
Hourly feeds .00006 x 24 hours = 0.00144 per feed
Minute feeds .00006 x 24 x 60 = 0.084 per feed
December 13, 2013, 03:36:42 PM
My feeling is that you will lose some functionality if you don't do it at least once per hour. I'd prefer once every 5 minutes. In view of SatoshiDice and further the notion of blockchain bloat, this is a comparatively very small burden on the blockchain.
December 13, 2013, 01:42:23 PM
We're currently discussing whether the Mastercoin spec should be changed to allow more frequent updates to data feeds: https://github.com/mastercoin-MSC/spec/issues/10#issuecomment-30528940
Background: The mastercoin spec allows users to create data feeds which publish prices for real-world assets (for instance, the price of gold) and for other users to place bets on those price tickers.
My original spec limited data feed updates to once per day, in an attempt to avoid bloating the bitcoin block-chain by attracting high-frequency day-traders. However Ron believes that we should not enforce such artificial limitations on our users (see discussion linked above).
I'm starting this poll to see what whether the community thinks we should change this limit, and if so, to what.
Background: The mastercoin spec allows users to create data feeds which publish prices for real-world assets (for instance, the price of gold) and for other users to place bets on those price tickers.
My original spec limited data feed updates to once per day, in an attempt to avoid bloating the bitcoin block-chain by attracting high-frequency day-traders. However Ron believes that we should not enforce such artificial limitations on our users (see discussion linked above).
I'm starting this poll to see what whether the community thinks we should change this limit, and if so, to what.
Jump to: