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 - R

Pages: 1 ... 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 ... 68
421
General Discussion / Re: Introduce CEX in governance?
« on: April 14, 2019, 11:43:27 am »
No thanks. CEX shouldn't vote with the funds users deposit onto their system. If they want to be more involved then they should create their own gateway on the BTS DEX.

422
what difference it would do to have such a script and have this in ptokax, except the the time involved to change?
I don't know what ptokax is, can you elaborate?

----

On another note - to any active/standby witnesses I'm still seeking additional price feed publishers for the Norns. We've been stuck at 6 for over the last month unfortunately, only 1 more to activate.

423


There's currently 6 active price feed publishers, looking for more interested price feed publishers to begin publishing.

424
General Discussion / Re: Bitshares HUG REST API
« on: February 26, 2019, 01:56:13 pm »
Please explain what you consider a "User" in your statistics.
The Google Analytics is very limited, it's implemented using the measurement protocol as you can see here:
https://github.com/BTS-CM/Bitshares-HUG-REST-API/blob/master/hug_script.py#L74
https://developers.google.com/analytics/devguides/collection/protocol/v1/reference

The following shows device breakdown, with a 'mozilla compatible agent' being the highest, there seems to be continuous fetching of some cryptobridge market orders which Google Analytics is interpreting as between 70-100 continuous users. I'd imagine that if someone was implementing a production grade solution that they would run their own private HUG REST API with increased security though.




425
Updated again https://steemit.com/beyondbitcoin/@cm-steem/blockchain-activity-google-assistant-action-v13-approved-by-google-try-it-out-ok-google-talk-to-blockchain-activity

I'd greatly appreciate any honest reviews of the bot, more use and reviews results in the action being promoted to more users.

Cheers 👍

426
General Discussion / Re: Bitshares HUG REST API
« on: February 25, 2019, 04:35:28 pm »
The intention of the Bitshares HUG REST API is to provide users an open-source high performance interface to the Bitshares network through simple GET requests. It's implemented using python-bitshares, HUG, nGinx and Gunicorn to offer 'unparalleled performance'. It's fairly easy to set up for a private API and doesn't require running a full server (though do respect usage limits).

I'm interested in potentially continuing development of the Bitshares HUG REST API through a Bitshares worker proposal, I've been maintaining it for the last 2 years as a fully open source project.

Would you support such a worker proposal in the future? If so, what would you like to see included? Is anyone running their own private HUG REST API?

Potential scope of worker proposal development:
  • Functions which query account details are slow - this needs debugged/investigated
  • Some functions are only for 1 asset, like getting price feeds for smartcoins, making more generic than specific functions
  • Increase server size to increase gunicorn worker count
  • Implement anti-abuse functions - currently there's nothing preventing anyone from consuming more than their fair share of resources, though caching does counter some of this concern
  • Improve analytics dashboard - currently limited to what functions are hit and frequency over time
  • Static HTML front end pages for some of the functions, the hertz page is fully generated rather than simply populated so it's pretty slow.
  • Bitshares github org fork of my repo is behind in commits: https://github.com/bitshares/Bitshares-HUG-REST-API
  • Create tests for the functions
  • Create user requested functions
  • Create a more sophisticated API key mechanism
  • Host Bitshares full node server locally to the REST API so as to further reduce latencies
  • Host a testnet REST API - currently only production available to save on billing costs.
  • Implement basic 'write' functions for private API usage - currently all functions are read-only.
  • Fine tune Gunicorn & server configuration
  • Stream account history from full node via ZeroMQ into a Google BigQuery table. Implement HUG functions which interact with BigQuery.
  • Split the python script down into separate python files for easier maintenance.
  • Maintaining inter-worker data stores. Currently a few functions save to disk to get around this limitation, this could be optimized.
  • Create example scripts to query the API using different languages

Current Github stats
* 8 stars
* 7 forks
* Forked into the bitshares github org

Last month's public HUG REST API analytics:


Related links:
https://github.com/BTS-CM/Bitshares-HUG-REST-API
https://github.com/bitshares/python-bitshares

427
Proposal created: http://open-explorer.io/#/objects/1.10.7806

CF has a better UI https://cryptofresh.com/p/1.10.7806 but it's currently down.

Thanks for previously increasing this, could it be further increased to say 50 the next time similar values are being updated?

Thanks

428
RE: ZeroMQ implementation - https://github.com/oxarbitrage/bitshares-core/tree/zeromq/libraries/plugins/zeromq

Could produce a ZeroMQ client which streams to postgresql 👍

429
Quote from: vianull
1) Develop a Postgresql-based plugin. We are going to build a structured on-chain data storage  using Postgresql.

I like the idea of developing new plugins for exporting the data from the bitshares full node, the more plugins the merrier in my opinion. If you could split the development of the plugin from the other two goals to reduce the cost of the worker proposal then I'd support this WP.

None of your images are loading for me, could you upload them to an alternative image server please?

I'd be very interested in a plugin for Google's BigQuery, streaming directly into a table for running REST API based queries on Google's servers.

431
General Discussion / Re: BTC MPA backed by gateway.BTC
« on: February 20, 2019, 11:10:00 am »
If one from few gateway will be bankrupt, then MPA.BTC backed UIAs.BTC also will be uncollateralized. I think it bad idea merge risks few UIA in one asset.
Not a bad idea to back an MPA with multiple trustless assets though 👌

432
Stakeholder Proposals / Re: please vote witness :xman & abc123
« on: February 19, 2019, 11:01:36 pm »
Would you be interested in publishing price feeds for 3 new Algorithm Based Assets on the BTS DEX? They're called Verthandi, Skuld and Urthr.

About: https://github.com/BTS-CM/Norns/blob/master/about.md

Here's the price feed script repo: https://github.com/BTS-CM/Norns

Parallel price feed script: https://github.com/BTS-CM/Norns/blob/master/parallel_feed.py (change the min price feed value difference at your discretion).

https://cryptofresh.com/a/VERTHANDI
https://cryptofresh.com/a/URTHR
https://cryptofresh.com/a/SKULD

It would be massively appreciated, thanks 👍

433
General Discussion / Re: BTC MPA backed by gateway.BTC
« on: February 19, 2019, 10:57:57 pm »
My english is definitly too bad :), sorry for that.
Thank you for your response
What I tryed to describe it's more an idea to make what it could be the biggest DEX BTC market.
Instead of having open.BTC market, bridge.BTC market, Spark.BTC market, EASYDEX.BTC market, rudex.BTC market ... we could have a MPA cumulating the liquidity of all those market.
a Mpa backed by all those UIA (MPA backed by multiple assets) can do that ?.
Sorry if I'm not clear
Problem is that you'd need to trust these multiple gateways to be fully collateralized when using their exchange backed asset (EBA|UIA) to back new MPA being issued, if one is compromised then they could flood the MPA, so it's not ideal. If there was a means of limiting issuance per backing asset type that'd possibly offset this risk.

434
General Discussion / Re: BTC MPA backed by gateway.BTC
« on: February 19, 2019, 08:44:26 pm »
It's already possible to issue an MPA using UIA as backing collateral, you'd need to contact the gateway to see if they're alright, though technically there's nothing they can do to stop you doing this.

435
Stakeholder Proposals / Re: [Worker Proposal] Core Team 2019
« on: February 14, 2019, 05:27:49 pm »
$125-$150 per hour for C++ developer?!?! seriously?!
An average wage is $42/hour. The highest is $96/hour.

see https://www.payscale.com/research/US/Job=C%2B%2B_Software_Engineer/Salary

You're looking at salaries, not contractor rates. I've known of people on $1000/day when contracting.

Your proposal is very inadequate. It needs to be revised.

It's now actively voted in, it doesn't need to be revised, technically.

Pages: 1 ... 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 ... 68