This post has a little experimental data on results using filtering:

Yes, there's two kinds of filtering available (they can be used together, also): one filters by accounts of interest, the other filters by operations that match a regex.

I'm not sure yet of the full impact of RC rationalization on custom_json yet, because the real costs of operations will have changed due to recent optimizations. As examples, we have speeded up the json

No, even if you have an uncompressed block log, your node will compress old blocks before sending them as sync blocks. So this means your new node will do more work whenever it to provides sync blocks

When the money changes hands, it's no longer NED's. That's my point. Your point is not correct. Under the law, a company can't just throw away liabilities during a sale. And when an officer makes a promise

After all, the funds from STEEM were owned by NED, he sold it and Justin Sun had every right to conduct business in the manner that he saw fit after overtaking Steem and the backlash behind it, BEFORE

I'm for sure not on vacation : :-) Just super busy right now with final details of hardfork and HAF release. I'll make a progress report in next day or two. I'm debating whether to push hardfork out to

I've been programming for about 40 years now, and most of that time was spent developing "high performance" code where speed and memory consumption was very important. Over time, that allowed

The reputation system on Hive was a "quick fix" to problems in the distant past. I'm not aware of anyone who thinks it is particularly great, but it still has some use, so we're somewhat stuck

The 7x speedup is in full sync of a node from no blocks all the way to head block, and it was measured on a normal consensus/seed node. Note that "full node" is mostly a dead concept now, because

I'll ping @asgarth as he would be the person most likely to know the answer to this.

Yes, I only started thinking about the json parser recently after some benchmarking showed that it was becoming the next limit on performance after we eliminated some even larger bottlenecks. My original

I don't know how favorites is implemented on peakd, so I can't be sure. If they are stored as custom_json data (which would be my best guess), then it could be node-related, but if so, switching to another

I don't have a firm answer yet, because RC costs depend on real costs, and code optimizations are changing the real costs. A good example is the new json parser lowered CPU cost of custom_json ops. But

Yeah, I had a similar experience that led to this change. Whenever there's a requirement to do a sequence of commands in a specific order or "bad things happen", it's a good idea to try to prevent

The code change for raising the haircut percentage from 10 to 30% was made a while back in the develop branch (i.e. it is part of the hardfork changes). I don't believe there is any major risk at 30%.

There's nothing we can do about them, but while they are mildly annoying, I don't think they are doing any real damage, because the xbots have no real voting strength. The bot creator claims that he did

I haven't really had time to focus on onboarding, so I've left that to other groups who already had plans in that direction to work on it. But I'll probably review the state of the whole ecosystem, including

Yes, I've not bothered with a full "English" review yet (I did get the spelling of witness corrected a few places).

Little today produces more economic value than code I wholeheartedly agree with this idea: it's why I changed career paths in high school and decided to go into computers (originally I was thinking physics),