Problem

My recent project presented a significant hurdle: efficiently monitoring updates on the Bitcoin blockchain. I faced a choice between two main approaches: leveraging a public API or establishing and managing a personal node. Each option carries distinct benefits and challenges. This section delves into the circumstances under which each method might be preferable for my project needs and outlines the rationale behind my eventual choice.

Project Overview

As of March 2024, I am in the process of creating a web service designed to facilitate the seamless and permanent recording of arbitrary data on the Bitcoin blockchain. This service caters to a minor range of uses and is of rather a exploratory substance, The use cases include for example commemorating significant events with text messages or safeguarding intellectual property by hashing files for copyright protection. The service’s cost is limited to the miner’s fee, ensuring accessibility and affordability. To operationalize this, I generate a unique Bitcoin address for each submission request and monitor these addresses for incoming payments, underscoring the critical need for effective blockchain state observation mechanisms.

Analysis

To monitor the chain state effectively, we have two main strategies at our disposal: utilizing an external API endpoint or managing our own node. Each approach offers distinct advantages and challenges, necessitating a evaluation to determine the most suitable option for our specific requirements.

Extern API

Pros	Cons
Ease of Use	Rate Limits
Cost Effective	Dependence
Quick Setup	Privacy Concerns
	Less Efficient Monitoring

Own Node

Pros	Cons
Full Control	Resource-Intensive
Privacy	Complex Setup and Maintenance
No Rate Limits	Initial Synchronisation Time

Given the intended small audience and non-critical nature of operations for my web service, along with a commitment to offering it for free, minimizing operational costs is paramount. This economic consideration makes the maintenance of a resource-heavy Bitcoin node impractical for my purposes. As a solo developer, the simplicity and rapid deployment afforded by using an external API are particularly attractive, allowing for a focus on development rather than infrastructure management.

Nevertheless, relying on an external API for blockchain monitoring introduces a significant challenge: the inefficiency in tracking updates. Unlike direct node access, external APIs do not inherently provide real-time notifications for blockchain state changes. This limitation necessitates the development of an effective strategy to dynamically poll for data, adjusting the frequency of requests based on immediate relevance. Initially, this means closely monitoring for incoming payments by increasing the frequency of update requests. Over time, as the urgency diminishes, these intervals can be gradually extended until we can assume that the client is not going to send the requested funds anymore and the monitoring process is deemed no longer necessary and subsequently dropped.

In conclusion, the choice to utilize a public API aligns more closely with the project’s constraints and goals.

The next hurdle we’re facing is developing a dynamic API-Request-Scheduling-Mechanism in Rust that’s both generic and thread-safe. I invite you to dive into the follow-up article, where I’ll share some insights into my scheduler. Feel free to utilize or tweak my code to fit it into your own project.

Cheers!