Quote from: Akado on April 21, 2017, 10:54:30 am

Quote from: yvv on April 20, 2017, 11:21:26 pm

Should we raise this question again next week if BTS prise drops to what it was a month ago?

Make it dynamic. We have USD feeds so use that to make the chain adapt and pay the equivalent of X USD worth of BTS. That way even if price changes witnesses will get roughly the same dollar value every month.

Agree. We have a price feed, let's use it for good. What are those "smart" contracts worth if we can't use them to fix witness wages?

The only obstacle I see here is witnesses collude and start manipulating the feed, because they all benefit from this.

This is a very real obstacle that a lot of people suggesting this seem to have neglected. I wouldn't want to fix the pay in bitUSD because of this risk, specially with the number of witnesses just dropping like it has in the previous months.

I just wrote some code that decrypts and uncompresses the .bin file resulting from the backup procedure available at the Open Ledger, and have some comments and questions regarding this specific topic.

I would appreciate if other more informed parties can engage in a discussion here, and maybe that could help me expand the documentation about this feature, since I feel that it is somewhat lacking in that aspect.

First lets take a look at the resulting JSON string:

{
  "wallet": [
    {
      "public_name": "bilthon-25",
      "password_pubkey": "BTS7bq4tVD5CLBTPowT4WJJHmSh8YumfoDYMiZHiCzNWQMq8DcGFX",
      "encryption_key": "9f95ca531a6750f3749ea8a2b70202bd59a9a051875608c04237cab3fda7f0c31129297a36af9c46f83a68713389a83d",
      "encrypted_brainkey": "b71760d18703a7bba4c2525277dfedb9042aab58c71190deeb05bc90f2097bf634bc0533ac375395cfd0263cd3614abf22f90e53e7e7b88ca811f2b614ff053f60e9ec842bdd034adaa5f795e25c9615a6d9a60c73f03dc101c97bf7877d7897",
      "brainkey_pubkey": "BTS5hfdU3ihm8wDPYuavWrGFopGySMcgEewmCDvTGPV29o14mtp7p",
      "brainkey_sequence": 1,
      "brainkey_backup_date": "2017-02-14T21:07:19.819Z",
      "created": "2017-02-14T21:07:20.193Z",
      "last_modified": "2017-02-14T21:07:20.699Z",
      "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8",
      "id": "bilthon-25",
      "backup_date": "2017-02-14T21:08:56.382Z"
    }
  ],
  "private_keys": [
    {
      "encrypted_key": "2ed26a282ae4ed06b594c91a352036d79a35c6c1a24d9d42523a74b5edde2c0f71155097cc9f6306a92a25ed2b846b83",
      "pubkey": "BTS5ynSurmrfWj1HrF81wxaLuAtTbp4yxWDsZzc7b93XPEK4aiR1i",
      "brainkey_sequence": 0,
      "id": 1
    }
  ],
  "linked_accounts": []
}
All the sensitive information here is encrypted, so I guess there's no harm in publishing it here. And the referring account is just a test one with not much funds in it anyways.

1- My first observation regarding this object is the replication of data in both the "public_name" and "id" fields. They are always the same. No matter what I do, I always seem to be getting the name of my wallet there. Which in this case just happened to be the same as my account name, but that is not necessarily always the case. Anyways I don't see the point of having 2 fields which always hold the same data.

2- The previous remak actually leads me to the second point, which is that it would be really useful to have the name of the account a key is referring to also stated here. I do recognize that the authority scheme can be more complex than just 1 key per account, and maybe this information was not included because of the desire  to just keep things simple. But I don't see why the JSON object could not be expanded in order to accomodate a current snapshot of an account's authorities for instance.

3- There's also an issue with the "brainkey_sequence" field. I noticed it is being 1. It turns out that this account specifically was created outside of the web wallet with a key derivated using the sequence value of zero. This is suggesting me that the this field is not actually being dynamically generated. Or at least not for imported accounts. The "brainkey_sequence" was assumed to be 1 here, when in fact it was 0, and thus the information provided here is wrong.

4- Also there's the "private_keys" array. This field can also seem kind of redundant, since the information contained in the brainkey and brainkey_sequence can be very well be used to derive the encrypted key at the field called "encrypted_key".  I say kind of, because I acknowledge situations where we might have just the private key and not an associated brain key, and we might be interested in store that into the bin backup. But my recommendation would be to use this field only for those specific cases.

5- And now my final point has to do with the "linked_accounts" field. This is a question actually (remember I told you I had one? . I modified bilthon-25 to be controlled by bilthon-24, assuming that this would make the "linked_accounts" array have at least one element. But nothing happened here. So I'm in the dark with respect of what this field is actually supposed to have. Does anyone have any idea?

Best regards
Nelson R. Pérez

Down for me too, right now.

Hello! I'm using the database API, more specifically the "list_assets" call to get the complete list of known assets. Of course, since the maximum number of assets returned is 100, I have to schedule repeated calls with slightly different arguments to the witness in order to retrieve them all.

Now what I want to do is to further classify and filter out this assets. I would like to first be able to tell which assets are UIA, smartcoins or prediction market. And filter out some of them based on their market cap, much like cryptofresh does at the assets list: http://cryptofresh.com/assets. How can this be archieved ideally with the minimal amount of API calls?

I'm sure the witness_fed_asset flag must be set for both smartcoins and prediction markets, but I'm not really sure how to tell them apart. Is it possible to do so just based on the issuer_permissions and/or flags? or will I need to issue more API calls? I don't see how to avoid this, specially to calculate the market cap.

Any thoughts on the issue?

Hello there, I'm trying to figure out exactly how to use the 'get_trade_history' database API call. The documentation seems to be a bit off for this one, since the order of the arguments displayed here http://docs.bitshares.org/api/database.html seems to be wrong.

Taking a look at the graphene code itself, I can find at /libraries/app/database_api.cpp:110 the following:

vector<market_trade> get_trade_history( const string& base, const string& quote, fc::time_point_sec start, fc::time_point_sec stop, unsigned limit = 100 )const;
But this is kind of at odds with what I actually find when querying the API, since it seems to be expecting a date format.

Connecting directly to a via wscat I get the following:

> {"id":1,"method":"call","params":[0,"get_trade_history",["BTS","EUR","20161215T0130000","20161212T233000", 100]],"jsonrpc":"2.0"}
< {"id":1,"result":[]}

And no, reverting the start and stop values doesn't seem to change anything either. Same result. Can anyone give me a hand with this?

Nelson

Well in the lack of one I began writing my own . Could use some help for some operations though, any resource suggestions? the docs seem very vague.