The only reason nodes normally keep blocks around is to give them to other nodes that haven't seen them (i.e. new nodes being setup for the first time). In the case of lite nodes, they won't have the older

There's no security implications: lite nodes do all the cryptographic checking that a regular node does. They just don't keep all the original block data around after they process it.

Nodes still process all the blocks. But when configured as a lite node, they don't need to keep them around afterwards.

They are acting as a marketmaker, buying and selling around the price spread. They make money off the difference between these two prices (the spread) and provide liquidity (available buyers and sellers)

How does the clipping work since you're modifying three values? For example, if you red is the highest value and it is at 254, do all three values just get increased by one in order to maintain the overall

Since the vast majority of the operations are custom_json, it's not surprising the impact on the size of the operations table was small.

We have several goals for our current work: Ensure we have a completely scalable decentralized blockchain. This means we need to continue lowering the costs to operate the entire infrastructure and make

Normal nodes have no need to store the 28GB "shared_memory" file in memory now. All our nodes store it on SSD storage (which is actually advantageous in some ways since the storage is persistent

It's not related to the WAX blockchain. WAX is the name of a new multi-language API library we've been developing for Hive that directly reuses core Hive code to implement some of its functionality (ensuring

I remember spending 8 hours writing a difficult recursive program in LISP back in college as part of an AI class. In the end it only took 8 lines to solve the problem, so it no doubt counts as the lowest

It's not a major issue, but if I understood correctly, the node.js is for getting balance data. We're planning on making balance_tracker a "standard" app for HAF soon (mostly just waiting for

I tried to see how the backend is implemented, but the link in the post doesn't work for me:

Yes, it's the kind of thing that's best tested to be sure, but probably cloudflare is better. If you have someone who can test for you that isn't in the same region as your cache node (or if you have remote

Yes, page rendering is noticeably faster on hive.blog now. In the past I was a little unhappy with the speed.

Our team mostly works on the backend core code: the blockchain node software and apps that process this data (cryptography key management, programming libraries, hivemind, block explorers, etc). But in

Yes, I'm pretty happy with the speedups we were able to achieve.

Yes, this task turned out to be more of a devops issue than a programming one. I think many people don't appreciate how challenging such problems can be. The job title "system administrator"

Yes, we've been thinking about this, not so much to avoid having the imagehoster talk to hived, but just to allow for more geographically dispersed servers (only one imagehoster, but many API nodes) that

Our service is closed now, you will need to purchase from a different service. You can ask around in the Hive discord channel for possible options.