This content got low rating by people.

Neue Hive Library / New Hive Library

noctury(71)

Published in

Deutsch D-A-CH

Words

1191

Reading

6 min

Listen

Play

22d

Hallo, lange nichts mehr gepostet.

Da ich wegen meiner Splinterlands-Verlosungen gemeldet wurde, habe ich mich hier ziemlich zurückgehalten.
Aber dieses Mal gibt es etwas, das ich euch mitteilen möchte.

Seit ich auf Hive bin, entwickle ich aktiv Hive-Projekte, z. B. einen alten, klobigen Splinterlands-Bot, Trading-Bots, Hilfsprogramme usw. Ich entwickle hauptsächlich in Node.js, Python und Rust.

Für all diese Sprachen gibt es bereits Bibliotheken für Hive-Transaktionen. Da mein erstes Projekt in Python war und schon eine ganze Weile zurückliegt, habe ich mich an die Beem-Bibliothek gewöhnt. Diese ist mittlerweile jedoch stark veraltet und hat mit Hive Nectar einen guten Nachfolger gefunden. Mir wurde dann klar, dass ich eine einheitliche Bibliothek für Node.js, Rust und Python haben möchte, die in all diesen Sprachen sehr ähnlich funktioniert und ziemlich schnell ist – was z. B. für den Handel wichtig ist.

Also begann ich, gemeinsam mit Claude bestehende Bibliotheken und den Blockchain-Code selbst zu analysieren und entwickelte „hivecomb“: https://github.com/flosolcher/hivecomb

Hello long time no post.

Since i got flagged because of my Splinterlands raffles i kept really quiet here.
But this time there is something i want to announce to you.

Since i am on hive i am actively developing hive projects, i.e. an old clunky splinterlands bot, trading bots, helpers etc. I develop mostly in nodejs, python and rust.

For all these languages there are existing libraries for hive transactions. Since my first project as in python and already a long while ago, i got used to the beem library. Which is now really outdated and has a nice successor with hive nectar. I then realized that i want to have a unified library for nodejs, rust and python which should work in all these languages very similar and be quite fast - which is important for i.e. trading.

So i started to analyze existing libraries and the blockchain code itself with Claude and created hivecomb: https://github.com/flosolcher/hivecomb

No need for any credits since this was mostly done with the help of AI, i just want to give something useful to the hive community. All other hive libraries still have their purpose and are worth to credit. Thanks!

hivecomb

hivecomb — Hive keys, serialization and offline signing, in Rust

hivecomb is a Rust reimplementation of beem, with
Python and Node.js bindings. Version 0.1.0 is on crates.io and PyPI as of
2026-09-05.

This is a port, not new work. The protocol knowledge in it — the wire format, the
key derivations, the operation definitions, the signing scheme — was worked out by
other people over roughly a decade:

Holger Nahrstaedt, author of beem, the library
this reimplements. Every serialization rule here was learned by reading beem's source.
Fabian Schuh, author of python-bitshares and python-graphenelib, which beem
itself descends from.
The hived maintainers, whose libraries/protocol is the authority every byte here
is checked against.

The conversion to Rust was done by Claude (Anthropic). Full attribution, module by
module, is in CREDITS.md.

Why it exists

beem has not been maintained since 2021, and a current install quietly falls onto a
pure-Python ECDSA path — the secp256k1 binding it prefers raises
AttributeError: 'PrivateKey' object has no attribute 'ctx' against any modern version.
It still works. It is just slower than it was designed to be, and it predates every
operation Hive added after hardfork 25.

hivecomb is that library rewritten, with the post-HF25 operations added and a set of
defects fixed. It is offered alongside beem, not against it — beem is where all of this
came from.

Install

# Python
pip install hivecomb          # keys, signing, memos, every operation

# Rust
cargo add hivecomb

Already have a beem program? Don't change it:

pip uninstall -y beem
pip install hivecomb hivecomb-beem

hivecomb-beem provides the beem, beembase, beemapi and beemgraphenebase
package names and the beempy console script. Existing import beem code keeps
working. It deliberately shadows beem's package names, so do not install both.

The Node.js addon is not on npm yet — npm's automated spam filter is holding one
of the five per-platform binary packages, which blocks the package that depends on
them. Build it from the repository meanwhile. Nothing about the Rust or Python
packages is affected.

Signing never needs the network

This is the part worth knowing even if you use something else.

A Hive transaction needs exactly two things from outside itself: the chain id, which
is a compile-time constant, and a recent block reference, which stays valid far
longer than any submit window. Nothing else. So the signing key never has to live on a
machine that talks to a node.

import hivecomb

# The only input from the chain. From any node, or carried across an air gap.
ref = hivecomb.BlockRef.from_block_id(head_block_id)

tx = hivecomb.sign_transaction(
    [("custom_json", {
        "required_auths": [],
        "required_posting_auths": ["alice"],
        "id": "my_app",
        "json": {"hello": "hive"},
    })],
    ref,
    [posting_wif],
)
# tx is the exact envelope condenser_api.broadcast_transaction wants

sign_transaction(operations, block_ref, wifs) returns a dict with ref_block_num,
ref_block_prefix, expiration, operations, extensions, signatures and trx_id.
Pass expiration_seconds= for a different window, chain= for a testnet.

The same thing in Rust:

use hivecomb::{BlockRef, Chain, PrivateKey, Transaction};
use hivecomb::operations::{CustomJson, Operation};

let key = PrivateKey::from_wif(&posting_wif)?;
let block_ref = BlockRef::from_block_id(&head_block_id)?;   // cached, not fetched here

let tx = Transaction::new(
    block_ref,
    vec![Operation::CustomJson(CustomJson {
        required_auths: vec![],
        required_posting_auths: vec!["alice".into()],
        id: "my_app".into(),
        json: r#"{"hello":"hive"}"#.into(),
    })],
    60,
)?;

let signed = tx.sign(&[key], Chain::Hive)?;   // pure CPU: no network, ever

What is in it

48 signable operations and all 43 virtual ones, read and written
Encrypted memos, in the format the rest of the ecosystem uses
BIP-32, BIP-38, BIP-39, brain keys and Hive's master-password derivation
An encrypted wallet
A JSON-RPC client with node failover, and an optional async layer that can race a
broadcast at several nodes and take the first acceptance
No Python dependencies at all, where beem pulled in requests, websocket-client,
Click, click-shell, pycryptodomex and prettytable

Python wheels are abi3, so one per platform covers CPython 3.8 and up. The Rust crate
is #![forbid(unsafe_code)] and builds with --no-default-features down to keys,
serialization and signing with no HTTP client and no executor.

How it is checked

A test suite written from a belief only tests the belief, so the serialization is
checked against hived itself rather than against this project's own assumptions:

57 of 57 operations serialize byte-identically to what a live Hive node produces
26 of 26 operations are signed with the authority hived actually requires
358 unit tests, four cargo-fuzz targets, and a differential oracle against beem
CI runs three Rust toolchains across Linux, macOS and Windows, plus Python 3.8/3.12
and Node 22/24

That oracle earns its keep. On 2026-08-22 it found four defects that 292 unit tests and
a beem differential oracle had all missed — two of which round-tripped perfectly through
this library's own serializer and deserializer, because a round-trip test cannot catch
a format that is wrong in both directions. It also overturned a finding this project
had published against beem, where beem was right and this library was not. That
retraction is still in the repository, with the reasoning left visible.

A transaction signed by this library has been accepted by Hive: block
109242605.

What it is not

Not production-proven. One accepted transaction is a proof, not a track record.
Nothing depends on this yet.
Not the only option. hive-nectar is the
maintained Python library and is more mature than this project's Python side by every
measure that can be counted. hive-xylem has
five releases where this has one. In Node,
dhive serializes large batches faster
than this does, for structural reasons that are not going away.
COMPARISON.md
measures every one of them with versions stated and the places they win shown as
plainly as the places they don't.
HAF is not implemented.