Weekly musing #15 - Signs of growth

ABC contributors growing

The number of contributors to Bitcoin ABC keeps growing, which is encouraging. At this stage, a heartfelt thanks to all who volunteer their time and effort on this project.

I don't want to call out anyone individually, but if you're interested you can of course see the contributions to the project coming in at https://reviews.bitcoinabc.org.

ABC is using Phabricator as its main developer site. Phabricator is a nice (open source) solution for managing projects, with good code review and workflow features.

We are using the Github repository at the moment to push out finished code (releases).

Gearing up for 0.14.3 release

In the upcoming release, we will roll out better branding and client identification for ABC, something that several users had been asking for. Awesome work by the designer of the logo, if you ask me.

There are some changes related to the transaction signing - now ABC produces replay-protected transactions by default when the fork is active.

The release will also include a bugfix for a crash that could happen occasionally, and did happen to some users. Let's hope as we get more eyes reviewing code changes, such things will not re-occur.

Description of the ABC release process

Mengerian and I had a constructive session adapting the document which describes the release process. This document is still in review at this time (https://reviews.bitcoinabc.org/D335). I post the link here because some people are wondering about the process ABC follows to release its software.

I would caution that the processes are still very young and are going to evolve. And there is still a lot of documentation to adapt, but Mengerian has been doing fantastic work on getting it into shape.

Preliminary look at larger blocks with ABC

One question that had been on my mind was:

How big blocks can ABC handle without running into some limitation?

This question had been particularly nagging on my mind since we had an outstanding issue with a test which seemed limited to 16MB blocks.

That turned out to be trivial to fix (the test simply needs to be generalized a bit more).

The next obvious target is 32MB.

Since MAX_PROTOCOL_MESSAGE_LENGTH is set to 32MB, we would expect to be able to produce blocks of almost that size.

And this is true - the test we have now generates blocks of exactly the size requested and so we can easily turn it up to generate a 32MB block. But of course there will be some overhead to wrap that block data into a peer-to-peer protocol message. As the test did not consider this overhead, it will fail when attempting to process a 32MB block.

So, raise MAX_PROTOCOL_MESSAGE_LENGTH? Yes.

Then I tried going to larger blocks. 64 MB?

No. One runs into another limit at around 33554432 bytes. Where does this strange number of ~33,5MB come from? It is of course 32 * 1024 * 1024 bytes, and is another limit encoded in the software (MAX_SIZE in serialize.h).

Can it be raised? Yes, of course. Bitcoin Unlimited for example has raised this to 256MB .

Let us be bold and try doing the same - raising both MAX_PROTOCOL_MESSAGE_LENGTH and MAX_SIZE .

This I did (both to a very large number around 256MB). That should be enough to attempt really large blocks.

I then ran the test with increasing block size by 1MB at each step.

I got up to processing a 134MB block correctly. On the next block my bitcoind process exited with a memory allocation error:

Error: Out of memory. Terminating.

I think my machine has adequate memory, so I have to resume this investigation.

But initial results from this test are very encouraging.

As others have reported in the past, there is massive potential to scale the blocksize dormant in Satoshi's client.