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

Pages: [1] 2 3 4 5 6 7 8 ... 64
General Discussion / Re: Site problem
« on: July 17, 2017, 02:41:47 pm »
This should be resolved, pls reply if you find any other errors.

General Discussion / Re: Cryptofresh update, feedback
« on: July 17, 2017, 02:39:27 pm »
Hi guys, thanks for the support. I'm still considering open-sourcing the site; keep in mind the only reason it's not yet is because my last worker got voted out. Keeping it closed source protected me from giving everything away without getting paid.

Last week, I ran into server issues/constraints (as mentioned, server upgrade is on the wishlist) which caused some downtime. I then upgraded the bitshares node to latest version so I could have access to the max-ops-per-account option to get memory usage under control. I had postponed updating the node because I'd seen API changes on GitHub over the last few months and was concerned some of them could be breaking changes.

I've found the issue with the assets pages and some APIs was due to a change in get_market_history_api, now fixed.

Let me know if there are any other issues.

Hi @roadscape and all, i am about to submit a worker proposal that includes work in the new explorer:

the worker is mainly for bitshares core development, the explorer development is just 1 of the tasks i was planning to work on. i started to work in a block explorer when the community claimed for it by different channels. it is not my intention to compete with cryptofresh for a worker or anything like that. i really like cryptofresh and it is probably the bitshares company standard. if it is updated and open source my explorer project will never started.

in the other hand i will love to continue with we can maybe find a solution working together somehow.

let me know.

Great work, @oxarbitrage. I'll think about how we could collaborate, but there's room for more than one block explorer. A healthy ecosystem should have options!

General Discussion / Re: Cryptofresh update, feedback
« on: June 28, 2017, 02:20:06 am »
I remember you have got about 4 million BTS from your last worker,
can you tell us what's the 4 M BTS pay for?

This is not correct.

My original worker requested 30k BTS per day over 3 months; this is 2.7M total. The worker was voted out several times, and in the end paid around 1M BTS. BTS was hovering around $0.004 during this period. Also, I delivered several months of work up front (for free) to demonstrate my commitment.

You can see all the details of my previous work here:,21532.0/all.html
And the early stuff here:,19507.0.html

General Discussion / Cryptofresh update, feedback
« on: June 27, 2017, 10:34:03 pm »
Just brought CF back up. As far as I can determine, a double-produced block caused issues with cf sync, which then led to an out-of-memory condition. The node just finished replaying and the site is caught up with the chain.

I'd like to start a dialogue about cryptofresh and its future. My witness has been voted out for a while so I'm maintaining (plus witness node) out of pocket, including dev hours and hardware upgrades.

IMV the witness was a convenient method of funding maintenance. I understand the desire for separation of roles, but I have experience with both so it avoided worker overhead. Would voters support a maintenance worker?

I'm also evaluating ways to continue development of cryptofresh. Here's a brief list of pending projects/todos:

 - fork handling
 - upgrading node, evaluate new APIs & check compatibility
 - upgrade server
 - improve rate bridging calcs
 - load charts faster (async generation)
 - tuning views
 - check API load/performance
 - open source
 - custom reports
 - worker caching bug

Any other issues I should know about?

Technical Support / Re: Cryptofresh worker "Current Balance" bug
« on: June 25, 2016, 05:31:14 pm »
@Chronos - I'm having a hard time seeing why the balance wouldn't be refreshing! It used to be cached but now the value should be loaded directly from the node. Restarting the the site updated the numbers.. I'll check back on it in a few days.

As to the green bits -- dannotestein nailed it, it's the margin by which a worker is considered "in". It shows the relative amount of support you can stand to lose without losing funding.

It has been fixed, thanks +5%

Yes, I caught this the other day. For some reason Cryptofresh was having a hard time calculating USD values for some of the more illiquid tokens.. now you will see a '--' where dollar value could not be calculated!


  Hallo Roadscape, I am using Cryptofresh every day to analyze bitshares adoption. I realy need a couple of tool:

1) The total bts fee paid to the network on a daily basis (whit a graph)
2) A better graph were is possible to where you can vary the time frame and set a some mobile mean (at least just a weekly mobile mean)

 Total fee paid to the network expressed in bts (and if it is possible in bitcoin) is crucial to better understand the real network adoption.

Thanks in Advance
Paolo Rebuffo

Hi @prebuffo, IIRC this was looked into it wasn't trivial with the current data. It requires a way to access historical CER data which is currently not indexed on my side nor in the core. The easiest way to get this data may be to replay the chain block by block and read the CER at each step. Then as you iterate over all the operations you would have the information required to convert UIA fees to the BTS equivalent. If we didn't have the ability to pay with UIA's it would be easier. But since many of our fees are already so low (and potentially free in the long run), isn't the number of transactions a better measure?

Surprised to see my worker (Blockchain Explorer and API Development) back in, even though there's only a few days left.. these weeks are busy but I'll gladly put this pay towards more updates in June!

I'm currently maintaining the block explorer.

OpenLedger / Re: Thank you Ronny
« on: May 03, 2016, 02:33:19 pm »
we need more posts like this! Let's stop arguing between ourselves when we all want the same thing, and recognize people such as Ronny that devote an incredible amount of energy to making this project successful. I agree with btswolf that the project wouldn't be the same without him.

Go Ronny!


General Discussion / Re: Working on BitShares..
« on: April 28, 2016, 05:34:04 pm »
I've already said that you guys are, as usual, overreacting to something that 1. should not have been news to you and 2. is being misrepresented.


I have  Z E R O  doubt bytemaster fully believes in his original vision for what BitShares should become. The problem may well be in his ability to communicate that vision effectively to the masses, but that's a marketing function, not that of a technical guru.

The problem in a nutshell isn't that BM has lost his passion for BitShares, it's that "BitShares" has lost its dedication to the mission. So as Stan says BM is simply looking for another way to fund his passion, and my hats off to him for the way in which he is doing that.



I've left a personal statement here:,21532.msg291084.html#msg291084

Ya'll really kept me on my toes the last few weeks.. only on BitShares can devs
be regularly fired and hired the same day, yet be expected to plan weeks ahead.. :p

Regardless.. it was overall a positive experience & I learned a lot! And most
importantly, I accomplished a lot I wouldn't have without the worker, things that
continue to provide ongoing value for the community.

Thank you for that opportunity.

But it does seem like the right time to shift priorities.
Returns from this worker are diminishing, and I'm running low on steam.

Of course, I'll continue working on cryptofresh, at my own pace.
As always, I'll be focusing my skills and energy where they are most effective.

It's great to see the true leaders stepping up in this community.
Hopefully you can figure out the funding situation :p
Just glad to see @svk's worker (critical) is still in..

Technical Support / Re: BitShares 0.9.3c won't sync
« on: April 25, 2016, 10:36:03 pm »
If you had a lot of TITAN transactions/orders, you may want to download and rescan the whole chain (there is a copy of it floating around so you don't have to sync from scratch). Otherwise, you don't need the chain at all.. and also when I perform wallet recovery I set my firewall to deny all incoming/outgoing connections for the BitShares 0.9.3 client, it seems to run way smoother when not trying to talk to the network.

Technical Support / Re: is the witness thing running under win?
« on: April 25, 2016, 04:48:03 pm »
I tested it and confirm the issue to do with low resources - ie low cpu power or bandwidth.
It's strange that it occurs on exactly same block: 2821722.

I replaced the blockchain folder on one node with a full backup, then it runs well. And the other node is catching up as well.

Trying to reproduce.

Most probably you're correct. Lots of these kind of entries in the log:
Code: [Select]
2016-04-21T12:03:29 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b0e5a206413b5f17ee209705b51b3cb90fa4c to peer, (full request is ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571c3f3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"])                     node.cpp:2427

2016-04-21T12:03:30 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Disconnecting peer because they didn't respond to my request for sync item ids after ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571cf3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"]                   node.cpp:1403

I think it can be optimized. In the code :
Code: [Select]
        // set the ignored request time out to 1 second.  When we request a block
        // or transaction from a peer, this timeout determines how long we wait for them
        // to reply before we give up and ask another peer for the item.
        // Ideally this should be significantly shorter than the block interval, because
        // we'd like to realize the block isn't coming and fetch it from a different
        // peer before the next block comes in.  At the current target of 3 second blocks,
        // 1 second seems reasonable.  When we get closer to our eventual target of 1 second
        // blocks, this will need to be re-evaluated (i.e., can we set the timeout to 500ms
        // and still handle normal network & processing delays without excessive disconnects)
        fc::microseconds active_ignored_request_timeout = fc::seconds(1);
The timeout applies even when syncing (batch fetching), but 1 second is perhaps too short for that?
Further thinking: why it happens magically on block 2821722 ?
@cube @arhag @pc @theoretical @bytemaster

The block after this one contains a huge operation.. 1MB of text in the asset description field. Very likely the source of the problem.

General Discussion / Re: Poor Man's Patent
« on: April 25, 2016, 04:30:34 pm »
That sounds promising.  Does it exist?  This seems like a fairly straight forward request - like the first thing that blockchain would have been used for.  So an application should exist, true?

PM sent

Pages: [1] 2 3 4 5 6 7 8 ... 64