BSV
$44.48
Vol 10.66m
0.13%
BTC
$60600
Vol 30699.29m
-0.57%
BCH
$322.29
Vol 173.57m
-0.14%
LTC
$64.73
Vol 242.99m
-0.25%
DOGE
$0.1
Vol 703.88m
-0.3%
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.

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.

Source: Blockchair

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.

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.

Source: Medium

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).

Source: Bitcoin whitepaper

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.

Recommended for you

Treechat resurrects archives from Twetch and Hodlocker
CoinGeek spoke to Treechat founder Dmitriy Fabrikant about the process of resurrecting on-chain social networks following the restoration of Twetch...
October 9, 2024
BTC miner Hut 8 pivots to AI as BTC profits dry up
Hut 8 now allows AI clients to use a cluster of 1,000 Nvidia GPUs powering HP supercomputers after a $72...
October 4, 2024
Advertisement
Advertisement
Advertisement