Author Topic: Bootstrapping a BitAsset  (Read 4424 times)

0 Members and 1 Guest are viewing this topic.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
toast, I'm not sure the current RPC interface allows for "selectively include transactions in the next block I'm forging"


Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.

Offline bytemaster

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. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
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)

Offline Empirical1

  • Hero Member
  • *****
  • Posts: 884
    • View Profile
 +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.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.

Offline itnom

  • Full Member
  • ***
  • Posts: 64
    • View Profile
    • Bitsapphire - The web development group that makes disruptive startups happen
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.
Back our bid as a BitShares Delegate! http://bitsapphire.com/Bitshares-Delegate

wallet_approve_delegate bitsapphire true

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline itnom

  • Full Member
  • ***
  • Posts: 64
    • View Profile
    • Bitsapphire - The web development group that makes disruptive startups happen
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.
Back our bid as a BitShares Delegate! http://bitsapphire.com/Bitshares-Delegate

wallet_approve_delegate bitsapphire true

Offline bytemaster

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. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline itnom

  • Full Member
  • ***
  • Posts: 64
    • View Profile
    • Bitsapphire - The web development group that makes disruptive startups happen
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.
Back our bid as a BitShares Delegate! http://bitsapphire.com/Bitshares-Delegate

wallet_approve_delegate bitsapphire true

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.