Ok, maybe I got a little close to the solution. The asset precision seems to play some role here, like describes in this example: https://dev.bitshares.works/en/master/bts_guide/tutorials/publish-feed.html

So the price for the asset publish feed operation is computed via

...
price = price * 10 ** asset["precision"] / 10 ** base["precision"]
...

which would match the factor 10 as the precision field for BTS is 5 and for EUR it's 4. But I cannot find information about how the asset precision is handled in general. Neither in the bitshares-core source code nor in the documentation. Is there a hint to learn more about that particular topic ? What role does the asset precision play here ?

Best regards.

Hi,

I'm trying to understand the internals of BitShares. For that, I had a deeper look into the operations being passed around and I do not properly understand the "asset publish feed" operation.

If I got that right, the operations settlement/core exchange rate prices are representations of "in the real world, I get x pieces of asset A for y pieces of asset B". So for A being 'USD' and B being 'BTS', it should be possible to directly compute the real world BTS exchange rate in USD from that.

Now, after some debugging, I get values like this for, say, the 2019/2/26:

...
{"base":{"amount":238,"asset_id":"1.3.121"},"quote":{"amount":41045,"asset_id":"1.3.0"}}
...

So for 238 USD, I will get 41045 BTS which leads to a price of about 0.0052 USD/BTS.
But if I look up historical BTS pricing, the exchange rate for that particular day is about 0.046 USD/BTS, in general about 10 times larger.

So where is my error of thought here ? Is there some factor involved which is asset specific ?

Thank you very much in advance.

I'm trying to develop a plugin extracting some statistical information from the blockchain. I kept the code similar to the market history plugin and it works well - except that the in-memory database is not rebuild when the witness node has been terminated and then started again - neither for the market history nor for my own plugin. Instead, the blockchain state is rewound for some blocks and blocks will start coming in from that point of time on. All in-memory information from the blocks before is lost.

In detail, the 'applied_block' hook is used to connect to the database during plugin initialization:

database ().applied_block.connect ([this] (const signed_block& b) { my->on_block_applied (b); });

When a block is applied, I will consider both applied operations and the current block transactions:

void extractor_plugin_impl::on_block_applied( const signed_block& b )
{
        graphene::chain::database& db = database ();

        // Applied operations
        for( const optional< operation_history_object >& o_op : db.get_applied_operations () )
          ...

        // Transactions of incoming block
        operation_handler handler (_plugin, b.block_num (), b.timestamp);

        for (const auto& t : b.transactions)
          for (const auto& op: t.operations)
            ...

This is the output when the witness node is started:

...
927579ms th_a       object_database.cpp:115       open                 ] Opening object database from /data/blockchain/bitshares/blockchain ...
928582ms th_a       object_database.cpp:124       open                 ] Done opening object database.
928599ms th_a       db_management.cpp:64          reindex              ] reindexing blockchain
928599ms th_a       db_management.cpp:70          reindex              ] Replaying blocks, starting at 350003...
...

* Is this the right way to ensure that, at witness node restart, the already processed blocks are replayed ? Or is some hook missing ?
* Or do I need to care for storing the already gathered information in a local database myself because there is no replay at all ?
* Why does the official market history plugin fail in this case, too ?

Thank you in advance !

Hi,

I have difficulties calling 'get_market_history ()' via the Python API (pybitshares). If I call this function via cli_wallet (local witness node), it works fine:

get_market_history BTS USD 3600 "2017-01-01T00:00:00" "2017-01-02T00:00:00"
...

If I do the same call via the Python API, it fails:

>>> from bitshares.bitshares import BitShares
>>> node = BitShares ('ws://127.0.0.1:8090')
>>> node.rpc.get_market_history ('BTS', 'USD', 3600, '2017-01-01T00:00:00' '2017-01-02T00:00:00', api='history')
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/bitsharesapi/bitsharesnoderpc.py", line 54, in rpcexec
    return self.rpc.rpcexec(self, payload)
  File "/usr/local/lib/python3.6/dist-packages/grapheneapi/graphenewsrpc.py", line 174, in rpcexec
    raise RPCError(ret['error']['message'])
grapheneapi.exceptions.RPCError: Assert Exception: first_dot != second_dot:

What could I do wrong here ?

Thank you in advance !

Hi,

I would like to learn more about the technology bitshares is based on. For that purpose I am using pybitshares to list the raw operations in the blockchain. Now I wonder how the current (settlement) exchange rate is computed using these operations?

From time to time, an asset feed operation arrives. But this seems not to happen frequent enough to get a settlement exchange rate for every major asset daily or even more frequently. So I assume it is computed from the limit order creates and cancels instead. But how?

Is there documentation about this? Or even a link to a source file implementing the basic algorithm?

Thank you in advance!