One group of planned features on ElectrumSV’s roadmap is related to privacy. It’s been a while since I thought about these, so there’s value in revisiting them. Especially since payment protocols are a hot topic for Bitcoin SV these days.

Potential best practices

There are no formal best practices in Bitcoin SV application development. However, these might be considered to be best practices in coin management aimed at ensuring privacy is natural in the way we use Bitcoin SV.

I have written articles on privacy-related topics before, but they were based on my understanding at that time and I’ve avoided rereading them so…

Introduction

As always, I am not a Bitcoin expert. This document is the path forward for ElectrumSV based on my understanding of the subjects at hand. Consider it a draft proposal, soliciting feedback and additional ideas to help define a path to keep ElectrumSV on track to take part in Bitcoin SV’s continuing success as experienced through larger and larger blocks.

People have always been told that all they need to do to backup their wallet is write down their seed words. But how does this really work? If you are supposed to be able to take these seed words and…

One of the things my fellow ElectrumSV developer AustEcon and I did a long time ago was hook up the mypy static type checker to our CI (continuous integration) process so that it gets run every time we push a change to our source code repository. If the type checker fails, the build is marked as failing. This then adds a strong incentive to run the type checker locally before pushing a commit.

TLDR; All our code (with a narrow set of exclusions) has been updated to use strict type checking. Some bugs were found, but nothing anyone really cares…

This article covers the release of ElectrumSV 1.3.12, and some of the more important changes that have been made since ElectrumSV 1.3.11. Skip to the “What has changed in this release?” section to see what has changed, if that is what you are here for.

We have not been making smaller releases like this. Most of the work is devoted to a larger update that prepares ElectrumSV for many of the exciting things you might see coming in the Bitcoin Association roadmap! …

For the most part there have been no critical problems with ElectrumSV that require releases. So we have been working on our next big technical upgrade. This document is intended to describe what we have been doing for that upgrade so far, and what else has to be done.

This is a technically oriented update.

Goal

The focus of this effort is to clean up the wallet code and prepare for a P2P future, removing a lot of the legacy approaches we are stuck with.

Progress so far

We’ve made a lot of great progress getting rid of a lot of technical debt and…

This document aims to record the plan for moving the focus of ElectrumSV away from monitoring the blockchain to a P2P focused approach. Due to the complicated nature of this, and the fact that it cannot be done wholesale, it is even more necessary to ensure this design document records both the reasoning and the nuances of the planned approach taken for later reference.

It is a copy of an original document shared on Google Drive, and is not guaranteed to be updated to match the original.

Overview

The way SPV was interpreted for the original Electrum wallet was that a…

Overview

As work on the second refactoring effort proceeds, we need to ensure that the model we use to respond to reorgs is correct.

Current approach

1. The wallet is notified that a transaction is mined, by examination of the scripthash history for a key that is used in the transaction.
2. The wallet knows when the blockchain is reorganised through processing the headers that it receives from any of the servers it is connected to, through a different chain of headers becoming the longest.
3. Transactions above the fork height have their proof removed, and a new proof is fetched for each.

Flaws

Reorg detection

Headers are synchronised…

When Bitcoin Cash split from Bitcoin SV to become some strange variation on what Bitcoin used to be, we were left with a problem. Transactions made for either blockchain were valid for the other blockchain. This meant that if a user sent unsplit Bitcoin SV, it would also move the Bitcoin Cash to the same payment destinations. And vice versa, sending the Bitcoin Cash would send the Bitcoin SV.

This article is not intended for non-technical users. It is intended to define the current technical state of coin-splitting for my own reference, as of the date of writing. …