BitShares Forum
Main => General Discussion => Topic started by: Agent86 on July 17, 2014, 03:49:59 pm
-
I want to suggest a different way it may be possible to bootstrap a BitAsset other than picking a minimum "market depth." Perhaps it also adds some additional safeguard or confidence to the market.
Allow delegates to provide price feeds for BitAssets (hear me out). A BitAsset must be supported by 50% of delegates via price feeds for 30days before trading starts. The price feed does not determine price, only acts as a safeguard: orders outside the median price feed +- 30% are rejected.
A BitAsset must have high visibility to be supported by most delegates and the wait time gives people a chance to get ready to participate in the market. We can also pull the plug before the 30day wait if it seems a real market has not developed.
Price feeds might sound antithetical to the BitAsset idea, but keep in mind the market still functions in the same way as proposed. The feed doesn’t determine price and if things work like we want over time the price feed would seem unnecessary. It's more of a safeguard/redundancy protection against manipulation in thin markets.
The price feed is also decentralized: no single delegate can manipulate it and delegates can be removed by shareholders.
-
This is fairly close to where we are heading (if you look at my recent post, not sure who posted first :) )
There are two options:
1) Encode the feed into the chain and use a median
2) Have a soft feed where delegates simply ignore transactions outside of range.
The first option is probably the most robust against an attack by a single delegate. The second is possible today without any hard fork.
I think I like your proposal Agent86... a 30% range of allowable orders works well and moves all attack vectors "off-chain", ie: if you can pump and dump BTSX causing a 50% fall in value. Nothing we do on chain can prevent that except increasing margin requirements beyond what a pump & dump can do.
-
Now I am more confident in BTSX. This is starting to introduce sort of a "unit of account". A 30% range is similar to how NASDAQ and NYSE have trading halts when market moves over X% in a day.
It will also ensure people don't flood the market with their wishful thinking orders, which will also require a more active participation, or a bot to monitor the market depth and then execute only when you want to.
-
I understand where you are coming from, and that this technically doesn't determine the price of the BitAsset, but it does give it upper/lower bounds of movement. A central feed would also create a central failure point, no matter how small the chance.
The first point of attack a government would use against a Bitshares DAC would be precisely this data feed. It would be trivial for governments to manipulate the public feeds and hence play around with the price movements on the DAC.
-
I understand where you are coming from, and that this technically doesn't determine the price of the BitAsset, but it does give it upper/lower bounds of movement. A central feed would also create a central failure point, no matter how small the chance.
The first point of attack a government would use against a Bitshares DAC would be precisely this data feed. It would be trivial for governments to manipulate the public feeds and hence play around with the price movements on the DAC.
There would be 100 feeds and the worst that could happen is that trading would halt until a new price feed was entered.
-
There would be 100 feeds and the worst that could happen is that trading would halt until a new price feed was entered.
Mmh. I'm not sure I'm getting it. Where do the original 100 price feeds come from? Wouldn't in most cases all price feeds for a specific BitAsset come from more or less the same centralized resources, but just get replicated by the delegates? My concern is that that central price feed where everybody gets their data from is manipulated in the first place.
This is one major issue for most global financial institutions dealing with assets from small countries. Often their data feed of the lets say Albanian stock exchange gets manipulated or corrupted by the central issuer for their own nefarious political reasons. If you are tracking a share of an Albanian company at that moment, and all delegate feeds agree with one another because there is only one central issuer of the data feed in the first place, the BitAsset will be out of touch with the real price quite considerably. This isn't a problem for the local traders because often they sit in a room with the real data but the public issuer sends out manipulated data to the outside. This is much more common for assets in small countries than you might think, hence trading BitAssets which don't have much liquidity seems dangerous.
-
There would be 100 feeds and the worst that could happen is that trading would halt until a new price feed was entered.
Mmh. I'm not sure I'm getting it. Where do the original 100 price feeds come from? Wouldn't in most cases all price feeds for a specific BitAsset come from more or less the same centralized resources, but just get replicated by the delegates? My concern is that that central price feed where everybody gets their data from is manipulated in the first place.
This is one major issue for most global financial institutions dealing with assets from small countries. Often their data feed of the lets say Albanian stock exchange gets manipulated or corrupted by the central issuer for their own nefarious political reasons. If you are tracking a share of an Albanian company at that moment, and all delegate feeds agree with one another because there is only one central issuer of the data feed in the first place, the BitAsset will be out of touch with the real price quite considerably. This isn't a problem for the local traders because often they sit in a room with the real data but the public issuer sends out manipulated data to the outside. This is much more common for assets in small countries than you might think, hence trading BitAssets which don't have much liquidity seems dangerous.
OK but in this case you are being manipulated even without price feeds giving you a range because traders are using price feeds to make their decisions... all you've said is that trading assets with only a small number of price information sources is dangerous (no matter which platform you are using), how can BTSX magically fix it? We are discussing BTSX-specific accounts
-
There is no reason to require a continuous feed and each delegate can set the window where it will work best. As long as the price doesn't move dramatically the price feed is meaningless. If a central authority is able to manipulate a feed then delegates will stop using that feed and instead pick a price they think is right, perhaps just using a feedback loop that uses the BitAsset price as a datapoint. By doing this delegates are effectively implementing circuit breakers. If the price moves by 30% then trading is stopped until the price falls or the delegates confirm the price move.
This is very different than relying on a centralized feed.
-
OK but in this case you are being manipulated even without price feeds giving you a range because traders are using price feeds to make their decisions... all you've said is that trading assets with only a small number of price information sources is dangerous (no matter which platform you are using), how can BTSX magically fix it? We are discussing BTSX-specific accounts
You are right. Anybody outside the trading room gets manipulated, and trading assets with a small number of price information sources is dangerous.
I think this means that there needs a minimum number of price sources for any BitAsset or the asset needs to be traded native on the DAC itself.
-
Make it so that people could write separate feed plugins. In other words make the RPC only support setting upper/lower limit. That way delegates could chose between available feed generators. And will be able to quickly switch between them without needing a new binary. In fact I've written some python code to do that and could work with you if interested in integrating.
-
+5% The general idea sounds good, I think it's a slight negative to say X may need to reference outside price feeds at all. But as it's version 1, it's understandable and should give a lot of confidence to the market if the trading is range bound in some way. (Or halts as you say till delegates can confirm the move.)
Then as delegates are voted for by shareholders once the majority of X feel they don't want/need such measures they can vote to remove them or only keep them for new/certain BitAssets.
-
There is no reason to require a continuous feed and each delegate can set the window where it will work best. As long as the price doesn't move dramatically the price feed is meaningless. If a central authority is able to manipulate a feed then delegates will stop using that feed and instead pick a price they think is right, perhaps just using a feedback loop that uses the BitAsset price as a datapoint. By doing this delegates are effectively implementing circuit breakers. If the price moves by 30% then trading is stopped until the price falls or the delegates confirm the price move.
This is very different than relying on a centralized feed.
Is it possible to not use any feed, You mean just to set a limit up and limit down percentage and stop trades after they reached that levels ?(it doesn't matter what the reason was to reach limit up/down I guess)
-
I don't think the idea is to integrates feeds into XTS directly. The idea was to have delegates to just refuse to process bogus transactions.
How and what a delegate does is entirely their choice. If the community disagrees with what they do - the delegates will get voted out.
This also makes it very flexible, if say delegates are using a bad feed, some possibly without realizing it, the community could just vote them out until they sort it out.
-
I don't think the idea is to integrates feeds into XTS directly. The idea was to have delegates to just refuse to process bogus transactions.
How and what a delegate does is entirely their choice. If the community disagrees with what they do - the delegates will get voted out.
This also makes it very flexible, if say delegates are using a bad feed, some possibly without realizing it, the community could just vote them out until they sort it out.
This is the soft version of it that is still subject to manipulation if the attacker can secure a delegate seat or even one delegate is too permissive. I think a hybrid approach is likely the best mode:
1) blockchain enforced limit at +/- 50% of current price based upon MEDIAN delegate price feed.
2) delegates can enforce a tighter range if the they like.
3) The default delegate mode will be to vote for the average blockchain price over the past 24 hours.
-
Good point about needing just one delegate to secure a bogus transaction.
I'm not disagreeing with your approach, However this is still more of an ad-hoc solution. My point is that it is hard to update people's clients, so try not to embed that functionality in the main client itself. Instead - open up the RPC, so that a delegate can choose a plugin, and switch between them if needed.
That way you can launch, but delegates can pick a strategy after BTSX has launched. And best of all you would be very flexible. I wouldn't mind developing plugins delegates can use. I already have code that continuously scrapes and saves feeds.
I was proposing a python script as a solution, as it requires a minimal installation and is mostly platform independent. Writing/editing/updating plugins would then be very easy.
The other nice thing about a python plug in (or any script you like) is that it is mostly readable, so it's going to be hard to sneak in malicious code.
-
Good point about needing just one delegate to secure a bogus transaction.
I'm not disagreeing with your approach, However this is still more of an ad-hoc solution. My point is that it is hard to update people's clients, so try not to embed that functionality in the main client itself. Instead - open up the RPC, so that a delegate can choose a plugin, and switch between them if needed.
That way you can launch, but delegates can pick a strategy after BTSX has launched. And best of all you would be very flexible. I wouldn't mind developing plugins delegates can use. I already have code that continuously scrapes and saves feeds.
I was proposing a python script as a solution, as it requires a minimal installation and is mostly platform independent. Writing/editing/updating plugins would then be very easy.
The other nice thing about a python plug in (or any script you like) is that it is mostly readable, so it's going to be hard to sneak in malicious code.
That is already how it is. Everything single interaction with the client is via RPC. So if he is proposing delegate input a feed, then it can be done programmatically.
-
toast, I'm not sure the current RPC interface allows for "selectively include transactions in the next block I'm forging"
-
toast, I'm not sure the current RPC interface allows for "selectively include transactions in the next block I'm forging"
Right, I'm saying, if you are allowed to enter price ranges for selectively including transactions at all (like in the proposal), then it will be available via RPC.
I guess from this response what you were saying is that you should be able to look at an entire transaction and choose to include/not include by your own rules. That is a good idea. But in any case, the "price range" criterion would still be a first-class element with its own call because the blockchain needs to compute the median of all the inputs.
-
Yes, because we may need to be able to quickly change the criteria, we may find that sometimes feeds contain bad data that needs to be filtered, exchanges go down, etc. etc.
For that I prefer to have multiple feeds and be able to say with confidence - this a very good price approximation.
But I see what you are saying - this is brainstorming, and if you decide to go that route, it will be in the RPC, since it is how everything else works.
So then a hybrid model as BM proposed would work:
1) Limit fluctuations to 50% range in 24 hour period (or less decided by the delegate)
2) Additionally allow delegates to exclude transactions based on their own criteria via RPC - I see BM's point that all it takes is 1 delegate to still be able to get their transactions in. But I think that should make it a bit harder to manipulate the market.
I think 2) is still good to have even if you don't see value in it initially. Imagine we experience some abuse, we might be able to very quickly deploy a patch and recommend community only vote for delegates having such and such filter in their system, until this is resolved. The most responsive and flexible delegates will win the community's hearts.
-
Yeah I think you have a great point. Our transactions are really easy to parse so it would not even be hard. I bet BM could add it in an hour. Anything in the pending list must be explicitly "approved".
-
BTW by the current proposal you would *not* be able to have "even 1 delegate get it in" if the range is enforced at the blockchain level from the median a specific delegate feed.
-
Right. That's how I understood the hybrid: 1) 50% is enforced by the block chain, smaller % is just the delegate itself,
Then 2) custom filtering is the same thing - just on local delegate level.
Edit: 1) will prevent massive abuse, 2) will only slow it down unless community eliminates all delegates causing trouble
-
This is where I think something like Ethereum's Turing complete scripting might be useful. But as much as I like the idea, I think forcing everyone to execute code is an overkill. If you make groups of delegates promise to run a certain script however this becomes very interesting.
UPDATE: Holy Shit, Ripple just released a paper that proposes exactly that. Bravo! Love the secure code integration with NaCl as well.
https://ripple.com/blog/smart-oracles-building-business-logic-with-smart-contracts/
I think this kicks Ethereum's butt 1000x times over!!!
-
This feels like,
(http://a.dilcdn.com/bl/wp-content/uploads/sites/8/2012/05/bowling.jpg)
We are putting more and more pressure on voting. What are the incentives to vote again?
-
We are putting more and more pressure on voting. What are the incentives to vote again?
I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it. It requires similar competencies as writing blocks: reliably perform a simple task with great up-time. Either they are doing it or they are not and it's easy to see which ones are. So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.
I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process. You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.
The incentives to vote are similar to shareholders of any company. But voting in our system is easier; you can do it with a couple mouse clicks. Info/data to make good decisions will be readily available. (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)
-
We are putting more and more pressure on voting. What are the incentives to vote again?
I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it. It requires similar competencies as writing blocks: reliably perform a simple task with great up-time. Either they are doing it or they are not and it's easy to see which ones are. So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.
I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process. You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.
The incentives to vote are similar to shareholders of any company. But voting in our system is easier; you can do it with a couple mouse clicks. Info/data to make good decisions will be readily available. (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)
I hope voting does not turn into full time job!
-
This is where I think something like Ethereum's Turing complete scripting might be useful. But as much as I like the idea, I think forcing everyone to execute code is an overkill. If you make groups of delegates promise to run a certain script however this becomes very interesting.
UPDATE: Holy Shit, Ripple just released a paper that proposes exactly that. Bravo! Love the secure code integration with NaCl as well.
https://ripple.com/blog/smart-oracles-building-business-logic-with-smart-contracts/
I think this kicks Ethereum's butt 1000x times over!!!
How is it different from Open Transactions with Smart Contracts?
-
We are putting more and more pressure on voting. What are the incentives to vote again?
I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it. It requires similar competencies as writing blocks: reliably perform a simple task with great up-time. Either they are doing it or they are not and it's easy to see which ones are. So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.
I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process. You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.
The incentives to vote are similar to shareholders of any company. But voting in our system is easier; you can do it with a couple mouse clicks. Info/data to make good decisions will be readily available. (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)
I hope voting does not turn into full time job!
I don't think it will... I think people will only come out to vote when there is a problem and there is no reason for there to be problems all the time.
-
How is it different from Open Transactions with Smart Contracts?
Not familiar with OT and their Smart Contracts. However, Ripple's proposal is using a secure sandbox that allows you to write in any programming language you please, is a very good move from practical stand point.
Also, not sure if OT allows Smart Contracts to run offline by Smart Oracles. There are some really good pieces in this whitepaper and I would love to see what Bitshares is planning for Smart Contracts.
I'm not a huge fan of the Bitcoin scripting and escrow as it currently stands. We need something more innovative and easier for developers to get involved. What Ripple's whitepaper proposes I think is a step in the right direction.
-
We are putting more and more pressure on voting. What are the incentives to vote again?
I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it. It requires similar competencies as writing blocks: reliably perform a simple task with great up-time. Either they are doing it or they are not and it's easy to see which ones are. So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.
I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process. You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.
The incentives to vote are similar to shareholders of any company. But voting in our system is easier; you can do it with a couple mouse clicks. Info/data to make good decisions will be readily available. (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)
I hope voting does not turn into full time job!
I don't think it will... I think people will only come out to vote when there is a problem and there is no reason for there to be problems all the time.
From what I see from the test up to now it is more than full time... you have to click on each one individually to see just his pay rate...
-
You can make the window a tad wider and the pay rate column will show up on the delegates tab where you can see them all.
-
You can make the window a tad wider and the pay rate column will show up on the delegates tab where you can see them all.
Which window???
I see them only under ‘Directory’ and there is no such column there…
Is there a command?
blockchain_list_delegates lists only active one…