You are viewing a single comment's thread:

RE: Setup a Hive witness using the new rolling block log feature

Full set of .artifacts is 2GB, not 100 :o)

I have not tested it, because I don't have HDD anymore, but block log should not require fast storage - once it is in live mode, it only needs to write couple kilobytes per 3 seconds. Even during replay HDD should be just fine.

One of the features of split block log is the ability to share all but last part. You can have multiple nodes that use the same block log parts and related artifacts symlinked to their .blockchain folders from the same actual storage location. Only the last part that is being written by each node separately needs to be stored locally for each node (but once it is filled and next part file is created, you can copy new filled part to shared location, stop the node, symlink and restart). That way all your nodes can fully participate in p2p syncing and provide block_api functionality while you only have one copy of block log. That feature is useful if you have multiple nodes on servers in the same location (for example for different services, load balancing or witness with bastion node).

0.00003407 BEE
1 comments
(edited)

Full set of .artifacts is 2GB, not 100 :o)

Depends on how long it has been running for. Mine is 97G and slowly growing. I believe mine is experiencing a bug, because most of my nodes are ~2GB, but some are growing.

image.png

One of the features of split block log is the ability to share all but last part. You can have multiple nodes that use the same block log parts and related artifacts symlinked to their .blockchain folders from the same actual storage location.

I believe this is what someguy does with his hosted witness node service.

0E-8 BEE

Dear @jacobtothe @steevc @makerhacks

It’s almost comical how you accuse us of posting "copypasta shit" while your friends like @makerhacks rush to your defense, downvoting and deflecting instead of addressing the actual issues at hand. Funny enough, @makerhacks is also one a supporter of the BuildaWhale scam farm LOL—a fact that speaks volumes about the company you keep. It seems your circle is more interested in protecting abusive practices than fostering transparency and accountability on Hive.

You claim our responses are "arrogant and flowery," yet you fail to acknowledge the substance of what we’re saying. We expose truths that make you uncomfortable, and instead of engaging in meaningful dialogue, you resort to personal attacks and suppression tactics. Downvotes don’t change facts—they only highlight your desperation to silence dissent. If you truly believed in honesty and integrity, you’d confront the truth instead of hiding behind your friends’ coordinated efforts.

We’ve said it before, and we’ll say it again: Bilpcoin stands for something. We’re here to fight for everyone on Hive by exposing corruption and abuse. What do you stand for? Apparently, silencing the truth with downvotes and enabling scam farms like BuildaWhale. That’s not leadership LOL—it’s complicity.

If you and your friends really cared about Hive, you’d stop enabling harm and start reflecting on your actions. Until then, we’ll continue shining a light on the truth because no amount of censorship or intimidation will stop us. The blockchain doesn’t lie, and neither do we.

0E-8 BEE

I wonder how does it even work (what is the content of your .artifacts) - valid file contains header (artifact_file_header) and then one 24 byte record for each block (artifact_file_chunk). If your file is bigger it definitely points to a bug. Your log might already contain some info pointing to source of a problem (look for messages originating from block_log_artifacts.cpp or any warnings/errors related to block log).

0.00003489 BEE