bump.
@jakub will you have time to update the sticky roadmap?

bump

I don't know if this been thoroughly discussed, so write it here. What if an exchange for example BTC38 act this way?

* create an IOU, for example BTC38.BTS, issue say 37 billion of IOU to a self owned account, for example btc38-market-watcher
* btc38-market-watcher set up a sell wall in DEX's BTC38.BTS:BTS market at 1:1, so anyone can convert her BTS to BTC38.BTS at 1:1
* btc38-market-watcher set up a buy wall in DEX's BTC38.BTS:BTS market at 1:0.9999 with all the BTS it bought from the same market, so anyone can convert her BTC38.BTS to BTS at nearly 1:1

So each outstanding BTC38.BTS is backed by one BTS on the buy wall

* BTC38 create another account for deposit/withdraw, for example btc38-d-w-account
* anyone can transfer her BTC38.BTS to btc38-d-w-account, as a deposit method, then the amount transferred will be shown in the user's personal inventory on BTC38's website.
* same way, users can withdraw from btc38
* users can trade BTC38.BTS on the central exchange

So balance of btc38-d-w-account is actually how many shares are trading on BTC38's central exchange

With this way, co-op can still be traded on external exchanges. And, the exchange can also vote with the co-ops. The steps are a bit more complex than current one, but looks like practicable. The exchange has no risk, users of the exchange bear all the risks.

I think a percentage-based order-filling fee on co-ops (to the network) would be a real barrier for this behavior, however the exchange can always transfer this cost to the customers.

Thoughts?

Why not post to General discussions board?

My system clock isn't synced with the time the bitshares network assumes. Might that be the problem?

Would be.

Quote from: xeroc on February 25, 2016, 09:33:44 pm

Hey there,

good to have you on board and your are doing a great job!
I would recommend to take a look into https://github.com/cryptonomex/graphene-ui/tree/master/dl
this directory contains quite a nice amount of coffeescript and es6 code that deals with the bts blockchain.

There is also a python library https://github.com/xeroc/python-graphenelib
and a lot of documentation about the API of BitShares and how to use it:
http://docs.bitshares.org/api

It's late over here and I would leave you with these for now .. If you have more questions, don't hesitate to drop me a line either here or in slack.

@besson I'd like to extend a question!
AFAIK BitShares node require 32GB RAM. Such DigitalOcean instance cost $320 monthly. It's quite expensive for our small project to maintain such node just for checking BTS balances (our overall server costs now about $250). @besson @xerox Is there any possibility to use publicly available nodes or some centralized APIs now? Because if not though necessary functional concerning BitShares will be implement in a Quantum library it will not be used in production on https://cyber.fund and BitShares will be the only without support that is literally bad.

Currently, with BitShare 2.0, 2GB RAM is more than enough for witness nodes. The 32GB thing is maybe refer to BitShares 0.x.

Hello bitshares community. Nice to meet you, guys.
I am developer in cyber.fund and now I'm working on crypto-balances library which written with CoffeeScript.
You can easy check addresses balances of various crypto tokens. Script automaticaly recognize a protocol by address and return balance of tokens associated with it.
Library supports following: Bitcoin, Litecoin, Dogecoin, Ethereum, Counterparty, Open Assets, Ripple and IOUs, NXT and NXT AE, NEM, Dash and some other altcoins
In current milestone I'm working on Factom(done), Omni(done) and Bitshares.
I spent a lot of time trying to figure out how bitshares and ecosystem works.
So, I need yours help guys. What I have at this point:
1. Found that bitshares addresses have regex like  BTS[a-zA-Z0-9]{50} (for example BTS7tqXBbtJwDoT8b2LY3kx547ocVfSacTirBMFEsDyhGf2FNR48p)
2. Wrote code for RPC API calls.
3. Started my own node using digital ocean instances for tests.
4. Googled and read bitshares docs and now I'm really confused about bitshares API.
Methods which I found not working and another ones use ids and names, not addresses to return balance.
(blockchain_get_balance, blockchain_list_address_balances, get_account_balances, get_named_account_balances)
Maybe I missed something out, don't know
So, to finish milestone with bitshares integration I need api which can return balance on address and nodes which will return responses.
Sorry for my english guys, I didn't have enough practice. Hope for your help and advices 

The first 2 APIs you mentioned above is outdated, they are for BitShares 0.x. Currently with BitShares 2.0 we have new APIs (the last two), you need to take a look at http://docs.bitshares.org/api.

BTS now no longer uses addresses to store balances. The new APIs for balances is documented in libraries/app/include/graphene/app/database_api.hpp
      /**
       * @brief Get an account's balances in various assets
       * @param id ID of the account to get balances for
       * @param assets IDs of the assets to get balances of; if empty, get all assets account has a balance in
       * @return Balances of the account
       */
      vector<asset> get_account_balances(account_id_type id, const flat_set<asset_id_type>& assets)const;

      /// Semantically equivalent to @ref get_account_balances, but takes a name instead of an ID.
      vector<asset> get_named_account_balances(const std::string& name, const flat_set<asset_id_type>& assets)const;

In regards to nodes, you have several options:
* set up your own witness_node and cli_wallet, connect your application with your cli_wallet, so you can use command-like APIs (raw RPC or HTTP-RPC calls).
* find a public API server, for example wss://bitshares.openledger.info/ws which can be found in the light client setting, set up your own cli_wallet to connect to that API server, then do command-like RPC calls
* connect your application with the API server or witness_node directly via web socket, so you can do request/response style API calls as well as subscription/notification, however the APIs of API servers are a bit different to wallet APIs.
* use APIs of cryptofresh.com, which is one of BitShares's public block explorer.

So, if your application communicates with cli_wallet, the correct syntax would be like:
{"jsonrpc": "2.0", "method": "list_account_balances", "params":["an_account_name"], "id":1}

Any questions please don't hesitate to ask

Quote from: agree on February 25, 2016, 01:41:33 am

支持先搞起来，哪怕是人为刷出来的交易量，只有交易量上去了，买卖价格合理了，才有机会吸引更多的人参与，更多人参与了，才有机会扩展应用。

我顶，让BM先搞起来 

如果，我只是说如果，开发资金需要500w bts，你同意出吗？