Bitsocket 2.0 demonstrates how Bitcoin SV is growing up

Getting your Trinity Audio player ready...

Pseudonymous developer unwriter released Bitsocket 2.0 which is a professional version of the server-side event tool released over a year ago. The original Bitsocket was built at a time where BCH and now Bitcoin SV (BSV) frequently had sub-1 megabyte blocks and low transaction volume which did not require for professional grade software.

Developers in the space have recognized this and have been hesitant to leverage these tools in their own applications.

Unfortunately real world experience has been that old Bitsocket did have a few too many wobbles for me to consider Proxypay a serious production class solution. I know @_unwriter has been laser focused on stability and reliability recently so I'm confident of big improvements.

— Libs (@libitx) January 14, 2020

However, over the past few months Bitcoin SV has regularly had multi-megabyte blocks and a surge in transaction volume, thus the need for tools the scale along with the network has become clear.

Tech entrepreneur Calvin Ayre has had strong rhetoric around the need for a public blockchain to scale in order to be taken seriously by any enterprise customers, so the need for its development tools to match is paramount.

scale or die

— Calvin Ayre (@CalvinAyre) December 8, 2019

The problem

As unwriter points out, the issue with the old Bitsocket was that if the volume of transactions was too high; the service could go down causing a gap in time where subscribers would not be notified when their type of transaction was broadcast to the network.

Retail outage scenario

In a situation where a business was leveraging this tool, this issue would be unacceptable. A common scenario like this in retail is when a point-of-sale (POS) terminal goes offline or the store loses connectivity to the Internet for whatever reason.

Does the retailer just pack up and close shop early?

Do they just stop accepting transactions and kick their customers out?

No!

Most modern POS systems have functionality to continue accepting credit card transactions while offline. Once connectivity is re-established, the system then batches those recorded transactions and sends them to the credit card processor.

Invoice integration scenario

Another common integration scenario for businesses is when they have a need to import invoices from some third party vendor. Most companies want to pay invoices as quickly as possible for various reasons such as establishing good faith with trading partners, tidying up financial statements for a clean month-end close or in a drop-ship scenario (third party vendor ships the goods) in order to be able to then invoice their customers as soon as possible.

Any system outage interrupting this process would result in added cost in various areas, whether it is an increase in internal resources time spent invoicing, IT troubleshooting, support or both.

A technical solution to this integration often involves downloading the invoices from some endpoint on recurrence (ex. every 15 minutes) while keeping a last record identifier so that the system knows not to process the same invoice twice.

This has the benefit of not only ensuring no invoices are missed, but also improves the performance of the code such that no check must be performed against previously downloaded invoices. The integration only needs to download invoices greater than the previous value stored.

For example, at 10:00 a.m., the company’s ERP system downloads invoices #1-4 from an API endpoint.

A value of 4 is stored as the last invoice downloaded.

By 10:15 a.m., invoices 5-8 are added to the queue.

The batch job in the ERP runs next at 10:15 a.m. and checks that the last invoice number downloaded was 4, so it makes a query to the API endpoint to only download invoices with number greater than 4.

The batch job downloads only invoices 5-8.

It turns out unwriter has implemented this exact type of solution in Bitsocket 2.0 that enterprises commonly implement for integration scenarios.

A timestamp server

If a business used Bitsocket 2.0 to download transactions from the blockchain as described above, this type of algorithm would be built in; it would not need to be re-implemented in their system of record, reducing development costs.

Of course, this type of solution is only possible with a single, global timestamp server (Bitcoin SV).

As a technical consultant who has implemented this type of solution many times for clients, I can state that this is a great example of Bitcoin SV development maturing.

The timing of such growth could not be better with the Genesis upgrade on February 4 rapidly approaching.