I have few questions about balance API:

1. When calling wallet_account_transaction_history it returns is_market and is_market_cancel, what do they mean?

Market transactions a are generated internally when trades are executed, by applying the market logic to the existing bids/asks/shorts/covers. Not sure about is_market_cancel.

2. How to find reference for bitshares asset_id, i know BTS is 0, what is asset_id for USD?

blockchain_list_assets or blockchain_get_asset

3. Calling wallet_account_balance will return:

Quote

Array
(
    [ 0 ] => Array
        (
            [ 0 ] => accountname
            [ 1 ] => Array
                (
                    [ 0 ] => Array
                        (
                            [ 0 ] => 0
                            [ 1 ] => 889000
                        )

                )

        )

)

which 0 represents asset_id? red, blue, or green?

Thank you

green

Wow .. what an honor .. Didn't see that one coming

You certainly deserve it. Congrats!

One of the things I like about the latest upgrades, is there's no need to re-index the entire blockchain anymore. Is this a new feature?

A re-index is only necessary when there are changes in the internal database structures. 0.8.0 is only a bugfix release, so the database structure didn't change.

Future releases will most likely require re-indexing.

In my RPM repo at https://build.opensuse.org/project/show/home:p_conrad:bts I have solved the nodejs/lineman problem by creating a separate lineman package that is used for builds only. For running the GUI you don't need node.js nor lineman.

The lineman package is rather ugly, it combines several hundred node.js modules. But that's not much of a problem because it is not intended for installation, only for building BTS + derivates. Maybe a similar approach is possible for PPA, I'm not familiar with that.

^^ Is there any logic to the X.Y.Z versioning?

Because having 0.7.0 and then 0.8.0 a week or two later seems a bit.... strange.

Almost as if we're rushing madly all the way to 1.0.

Z is increased for minor updates, Y for hard forks. 0.7.0 was somewhat unplanned bugfix release.

What about feature requests tho, or a consensus driven to-do list for the devs?

Feature requests can go on github, too. At least when they're sufficiently specified. Anything that needs discussion should be discussed on the forum first.

As a general rule, small features have a certain chance of getting integrated quickly, while anything larger will most likely have to wait until after 1.0.

A consensus driven to-do list is an interesting but tricky subject. Thanks to voter apathy it's really difficult to come up with a reasonable *and* practical definition of "consensus".

Quote from: starspirit on March 22, 2015, 04:25:36 am

What's the "10%" is people are referring to? I thought in the current system expiring shorts sit at the price feed if there are no lower asks (i.e. no penalty), and that called shorts can buy as high as 110% (i.e. a 10% penalty)- is that incorrect? Sorry if my understanding is wrong, I've just not seen these confirmed.

This is another market bug that was introduced (in 6.2 I believe): not only the called shorts but also the expired ones will buy as high as 110%. How you describe it is how it should work and how it used to.

It's been like that since 0.4.19 at least. I think that will change with the new market engine.

As for the shorter's price and interest rate argument, I want to confirm that the first preference is the price (the lower, the higher priority) and if the price being equal, the system compares the interest rate (the highter, the more priority), is that correct? Thanks.

No. The interest rate is compared first, the short with the highest interest rate always wins. This has also been like that for ages.
The new market engine will prefer the higher interest rate only for shorts at the feed price, and order the others by their price limit.

I've contacted BTC38 , they did it by accident . They'll down vote them tomorrow

Good job!