Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - monsterer

Pages: 1 ... 118 119 120 121 122 123 124 [125]
1861
Technical Support / Re: blockchain_market_price_history last parameter accepts only 0->2 not strings
« on: October 08, 2014, 09:46:47 am »
Quote from: svk on October 08, 2014, 08:31:23 am
I'm using it in an RPC call but I'm not explicitly serialising anything, although the library I'm using might do so behind the scenes I suppose. I played around with the CLI to figure out how to structure the command though, and I always just passed "each_hour" or "each_day" etc. I don't have access to the client since I'm at work, but will have a look later.

Are you passing the string each_hour enclosed like so:

Code: [Select]
blockchain_market_price_history USD BTSX 20141003T220010 86400 "each_hour"

You're right - it just needed the quotes :)

1862
Technical Support / Market containing assets with different precisions? [solved]
« on: October 08, 2014, 08:47:18 am »
What happens if you have a market containing two assets which each have different precisions?

1863
Technical Support / Re: blockchain_market_price_history last parameter accepts only 0->2 not strings
« on: October 08, 2014, 08:05:55 am »
Quote from: svk on October 07, 2014, 09:11:25 pm
Pretty sure I'm using "each_hour" without issue on my backend.

I'm guessing that your json serialisation is set to serialise the value of enums, rather than the identifier?

You can confirm the behaviour in the client console.

Cheers, Paul.

1864
Technical Support / Re: blockchain_market_price_history last parameter accepts only 0->2 not strings
« on: October 07, 2014, 08:58:36 pm »
Quote from: xeroc on October 07, 2014, 08:49:17 pm
Good to know someone figured it out ..
I also tried around with this cmd but could get any results :(

could you be so kind and give as a full example?

The trick is to mess up the timestamp formatting; instead of yyyy/MM/ddTHH:mm:ff, you should pass yyyyMMddTHHmmff.

blockchain_market_price_history USD BTSX 20141003T220010 86400 2

Will return 24 hour granularity on USD BTSX with a start date of oct 3rd, 22:00:10

Hope that helps!

Cheers, Paul.

1865
Technical Support / blockchain_market_price_history last parameter accepts only 0->2 [solved]
« on: October 07, 2014, 08:37:43 pm »
blockchain_market_price_history is documented as accepting a string: each_block, each_hour or each_day for the granularity parameter. In actual fact, it only accepts the enum definitions of 0,1,2.

Cheers, Paul.

1866
Technical Support / RPC returns timestamp in two different formats
« on: October 07, 2014, 06:20:08 pm »
get_info returns YYYY-MM-DDThh:mm:ss

blockchain_get_asset returns YYYYMMDDThhmmss

Why the inconsistency?

Cheers, Paul.

1867
Technical Support / Re: Feature request: CORS in HTTP server to allow users to authorise website access
« on: October 06, 2014, 06:32:13 pm »
Quote from: xeroc on October 06, 2014, 06:03:45 pm
I spanned a VPN for my machines and can access all of them via RPC interface ..

What's the difference to COR?

This is about enabling websites to talk with localhost for end users. So end users run the existing GUI client, authorise a website by domain name and then the external website is permitted to communicate with localhost (and therefore the GUI client) in order to place orders and perform other private functions.

This means the external website never has to store private keys which is great for security.

Cheers, Paul.

1868
Technical Support / [Feature request] CORS in HTTP server to allow users to authorise website access
« on: October 06, 2014, 02:44:40 pm »
It would be great if the client supported Cross Origin Resource Sharing so that different web-based front-ends could be created that ran on top of the client.

Obviously there would need to be a way for users to allow a given (set of) domain(s) to access their client as it would otherwise pose a security risk.

The use case is allowing third party website developers to provide slick, exchange like web interfaces which talk directly to the client running on localhost. This would allow the websites to hold no private keys, yet still provide a trading interface.

Cheers, Paul.

1869
Technical Support / Re: blockchain_list_assets returns asset names differently from the market tab
« on: October 06, 2014, 02:21:13 pm »
Quote from: toast on October 06, 2014, 10:21:07 am
Market-pegged assets get the "bit" prefix, user-issued assets do not

Sent from my SCH-I535 using Tapatalk

How can you tell if the asset is market pegged?

1870
Technical Support / blockchain_list_assets returns asset names differently from the market tab
« on: October 06, 2014, 08:38:51 am »
When trying blockchain_list_assets in the console, I get asset names such as USD, CAD, LOVE etc. When looking in the desktop client, in the markets tab, I see BitUSD, BitCAD but not BitLOVE.

Which is the proper name and how is it derived?

Cheers, Paul.

1871
Technical Support / no rpc blockchain_list_markets?
« on: October 06, 2014, 08:27:21 am »
I'm trying to get a list of valid markets via RPC, as is displayed in the client.

Since there is no direct command for this, I assumed that a market is simply a combination of any quote asset and any base asset. However, when trying 'blockchain_market_status AUD CAD' in the console, I just get an asset error.

Any ideas?

Cheers, Paul.

1872
General Discussion / Want to build web-based trading interface but need to manually enable RPC calls?
« on: October 03, 2014, 02:07:14 pm »
Hi there,

I was considering building something like NXT's secure asset exchange, which is basically a web-based front end to the NXT client. However, with the current bitshares client, users have to manually enable RPC calls by editing a config file, which would put a huge hurdle in the way of using any such site.

Should I just give up with this idea, or is there a way this could still work?

Cheers, Paul.

Pages: 1 ... 118 119 120 121 122 123 124 [125]

Page created in 0.022 seconds with 23 queries.