pull down to refresh

Excited to see you have continued development plans for the rest of the year.

I looked at some of your previous posts about Bitcoin Backbone, but I'm still a little fuzzy on the particular advantage or approach you are taking (as opposed to libbitcoin or Toby Sharpe's Hornet Node project or Floresta, for example). Have you written about this somewhere and I have just missed it?

Your website says

The full node architecture and development is focus on reliability,
modularity and performance.

But I'd be interested to read a slightly expanded version of your approach.

1084 sats \ 0 replies \ @theariard OP 1h

That’s a good question.

Not super familiar with Hornet or Floresta, a bit more with libbitcoin.

Anyone is free to correct me if I’m wrong, but Hornet iiuc is more a formally verified re-implementation of the consensus rules, aiming to offer all of this in clean and modern C++ code. Backbone is re-using directly libbitcoinkernel which is shared with bitcoin core, this is an engineering advantage to ease the support of future consensus change (e.g bip54), where for Hornet, any future consensus change would be to have independently re-implemented and re-tested.

About Floresta, from what I understand, it’s more a lightweight client which is leveraging utreexo as a validation backend. It’s very interesting and imho it’s worthy to follow a client building on utreexo principles. However, one has to be aware off that utreexo is trade-off (disk I/O vs bandwidth), so as all trade-offs it’s all trade-offs (tautology).

Libbitcoin is more a complete bitcoin development kit (i.e a library and a full-node) written in C++. Dunno if you remember the history of Libbitcoin, but the historical goal was to have a fully FOSS free bitcoin service stack by combining Electrum and Libbitcoin (never really delivered on, though one can see bip 33 for ideas).I think it was a great idea, and it was never really pursued consistently. Somehow Backbone is more similar to this (being a full node and not a lightweight one like Floresta or Hornet) and written in rust.

I have strong thinking in terms of security and it’s aimed to be very conservative in terms of consensus. For the usage, it’s not very aimed to be a “ready-to-deploy” full-node for the bitcoin hobbyist that is not familiar with running a full node, more to be a stable backend for people that wish to build bitcoin native services.

E.g if you’re a team of 2 and you’re building a collaborative custody service and you wish to have a watchtower for your collaborative custody (e.g on a given tx format, do some tx broadcast or whatever), I’m interested to talk with you. I would say for now think about Bitcoin Backbone as a stable backend for bitcoin native services run by SMBs (small medium businesses).

In my view, we have one single well-maintained bitcoin full node software, and somehow alone it’s powering a 1T bucks ecosystem. My wonder is what if we have half a dozen of high quality full nodes, would this grow the ecosystem to 2T bucks, 3T bucks, 4T bucks, more ? Maybe the real bottleneck in the real-world growth of bitcoin is that so far we had only one serious full-node, and everything upstream is frustratingly slow down on that. Better to grow the pie for everyone and compete from the top, by innovation.

Back down to earth, I don’t wish to over-promise with Backbone neither to engage myself to strongly and for now it’s just boring-but-necessary quality assurance, documentation and basic testing works. This is a marathon, not a sprint.

reply