December 2017

nice :-)

Back in libbitcoin v2 we used to maintain unconfirmed txs in a "memory pool". That led to problems during the "spam attacks" when we started seeing upwards of 20,000 txs in the pool. As a result v3 eliminated the memory pool, storing validated but unconfirmed txs on disk. Eventually most txs get mined, and we have already validated and stored them, so there is no extra cost - it's actually a great performance improvement. Now with well over 200,000 txs in the tx pool we are humming along with zero performance degradation. I noticed that blockchain.info has had a little trouble today with their mempool but cancoin's voyager https://voyager.cancoin.co has been solid. Nice work!

Hi everyone! I'm Ty, I work with libbitcoin mostly using the Elixir programming language. I've built a client library and a high performance libbitcoin helper library, both of which were used to make the 'voyager' block explorer. You can see all the code here: https://github.com/cancoin

And IIRC voyager passes websocket calls directly to the zeromq APIs for libbitcoin-server right?

Yes, websocket calls get passed directly to the zeromq API.

I've been looking at providing a light weight websocket interface in the library, using mongoose. I'd really like to get your thoughts on it.

I think a light weight websocket interface would be a cool addition. I was thinking of using binary websockets and doing all decoding client side at one point.

We could easily provide different encodings. My main initial issue with mongoose was whether it would support push notifications.

We use a lot of HTTP EventSource sockets for our app's push notifications.

I'm also planning Electrum wallet and mining integration. I spoke with Thomas about it and he seemed to prefer using ZeroMQ in the client, but this will be a tough sell on the miner side. So probably going to have to integrate stratum at some point as well 😕

I could imagine ZeroMQ being a tough sell on the miner side.

A client-side dependency that's not C is a bit of an issue, but we should probably just create a miner client library at some point 🙂.

But it would make sense for them to use a more efficient protocol than JSON over TCP.

exactly

A miner client library that speaks to bs via ZeroMQ would be pretty good. That could be used to re-broadcast via stratum or whatever.

Right, client-side proxy is what has been recommended. Still not optimal, but then you work your way out of the proxy and go native eventually.

Wow, ZeroMQ in Electrum would be great for bs!

BS is becoming a high performance mining pool platform. IOW one BS server will be able to run the entire pool, emitting accounting data over a notification endpoint.

It's got the fastest block validation out there as far as I know.

Yeah, in v4 server is getting some pretty significant upgrades to initial block download, validation performance (and compact blocks for low latency), and index space reduction...

Websockets are a can of worms, that's for sure

Here is the websocket library we use: https://github.com/ninenines/cowboy , It's in Erlang, so not something that can be integrated into bs.

Yeah, nice, but...

I know, not much help. But it's good at handling millions of near-idol connections. http://phoenixframework.org/blog/the-road-to-2-million-websocket-connections

I'd like to know what our limit is on native zeromq. Are you using an in-process, local or remote binding to zeromq?

We are using local bindings for zeromq. I bet on the right server bs would do the same! I think they were limited by ulimit in the end.

metaverse used the inproc zeromq binding, which I think makes sense for integration of mongoose.

I wonder if libbitcoin-client could be integrated into Nginx as a module. That's gotta be one of the most efficient web servers around.

Client needs a bit of an overhaul.... it should be mostly using the new work in libbitcoin-protocol, which would make it a lot simpler and a little more efficient.

Oh ok, I don't actually use the client for anything ATM

It would simplify implementation of the web server though, vs writing it directly in zeromq.

I agree, it would be incredibly useful. You could have a personal/local block explorer with one HTML file.

exactly

Libbitcoin version 3.4.0 has been tagged for release.

👍

I've completed a full validation of mainnet with segwit forks enabled.

mainnet1/testnet1 and mainnet2/testnet2 going down for some extended downtime starting today

Okay, bitprim is supposed to be resyncing with 3.4.0

Once these are up I'll transition the default (mainnet/testnet) DNS names to them.

servers going down very shortly

K, I'll swap dns now.

thanks, hope it goes smoothly

Hi eric ! ....

Hi!

I need an invitation to slack -> fpelliccioni@gmail.com

Hello

No, mainly because Libbitcoin has no wallet store.

Looking forward to your pull request!

I will read the Bip and see what can I do

I'll gladly offer advice and review on implementation. Best thing is to issue PR and request a review. Should be in the bc::wallet namespace and directory structure.

@fpelliccioni About bip44, I've got working code using libbitcoin so if you need pointers for a bx integration, or have questions about how it's done, I'm happy to help!

@fpelliccioni - Lots of BIP44 bx scripting examples are found at https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings#7-bitcoin-btc-bip-3944-technology-examples. I believe @neillm just added Electrum seed word support that complements native BIP44 support.

I've patched a trivial issue in libbitcoin-network that required backport to v3. Without the fix testnet does stall and mainnet could at any future point. The problem was an incoorect max size on network messages that can affect segwit blocks and txs. I've also patched a client issue and similar issue in explorer, whereas witness data is not decoded. I cheated a bit and retagged v3.4.0 in several repositories. Also, note that v3.4 requires a resync of the chain so that witness data will be captured for earlier blocks. Finally, ensure that network.services=9 is set so that witness data will be retrieved from (and provided to) peers. Also ensure that segwit forks are set (as desired): https://github.com/libbitcoin/libbitcoin-server/wiki/Fork-Settings Although if not specified all forks except for easy_blocks are enabled by default.

Libbitcoin now has fully-generated Visual Studio projects in master, thanks @pmienk! The previous support for VS2013 is now generated from libbitcoin-build (along with all other build artifacts) for all repos. But we now also have identical generated support for VS2015 and VS2017 in all repos. This means we also support Qt 5.5 and later on Windows (VS2015/17 with static linkage).

Not a windows guy, but 👍 for those that can use this!

I’m retiring shortly. This means I will have more time to muck around with the cool toys you guys have created from an OSX perspective! Have also have started to capture the attention of my brother that is a JavaScript Architect.

Nice!

Thanks:-) It will be nice to have extra time to do things that interest me. Be aware that I never was formally trained as a developer. I’m really a BSEE that became a hacker years ago. I’m still coding and comping on a Mac using old fashion UNIX commands with Homebrew. Any pointers for URLs to examine concerning Xcode IDE will be my starting point.

Recently upgraded to macOS High Sierra (Version 10.13.2) and I’m in the process of reloading Xcode Version 9.2 (9C40b).

Okay, I just assumed you were working in Xcode. An IDE can be a big productivity enhancement when debugging, especially when dealing with a high degree of concurrency. It also tends to lower the bar for beginners to use the library.

I’m an old Makefile hack for managing projects on a single platform. I need to locate reading/video material to get me up to speed more efficiently. Is your desire to have an Xcode project for each libbitcoin library?

Just for the three binaries in the base libbitcoin repo. With that as an example we can generate it and the others.

bx, bs, and ???

just libbitcoin/libbitcoin

Thanks for the Autotools link. This [Autotools](https://www.amazon.com/Autotools-Practitioners-Autoconf-Automake-Libtool-ebook/dp/B003WUYEL6/ref=pd_cp_351_1?_encoding=UTF8&psc=1&refRID=S69RY143Y19C2AHHYCWW) resource still had much to be desired. Will focus on these: 1. libbitcoin/libbitcoin 2. libbitcoin/libbitcoin-explorer 3. libbitcoin/libbitcoin-server

Again, if you just get libbitcoin we can set up generation for all others. Getting bx and bs will require you to build all (9) repos.

Setting a baby step goal of staying focused on libbitcoin/libbitcoin and using the libbitcoin/libbitcoin-explorer/blob/master/Makefile.am to drive the development of a libbitcoin.xcodeproj file.

Cool!