Toms Blog

Where I talk about Bitcoin Cash and more

My report on the Instant Transactions Workshop

2018-10-18 Bitcoin cash

In the past week the very well organised workshop for instant transactions (also called zero-conf) took place in lovely Italy where we had 3 days with a schedule packed with the main goal of aligning the views of the different implementer and players in the Bitcoin Cash space.

Practically all Bitcoin Cash node implementer were represented with actual developers present. This meant the discussions went from high level to quite intense technical detail.

I would like to go over the different ideas we’ve seen and I’ll describe what my impression was on how well they were received.

Double-spend transaction relay

This concept has been present on the network for some time already and we have seen clear indicators from players it was very valuable in doing the research into this topic.

The relaying code as it is today leaves various use-cases unsolved, SPV being a big one. At the same time it covers some use-cases which other ideas don’t cover. Those cases don’t seem to pose any economic danger, though.

Most of the developers present had little against this idea, but the proposal failed to entice more teams to implement it for their projects.

Relay and super-standard

Seen as a package-deal with transaction-relay was a proposal from Tom Harding to make miners do transaction replacement on certain criteria. This is similar to replace-by-fee, except that only transactions that already are very badly supported can be replaced.

The proposal has as a requirement that its roll out is practically like a hard fork, which raises the bar considerably. The proposal is much less useful without transaction relay being widely deployed and as such there wasn’t anyone in the room who said they would implement it.

Double spend proofs

The proofs idea is aimed at merchants, both full node and SPV wallet using ones. About a full day of discussion was about this proposal (by imaginary-username and myself) and a lot of corner cases were considered and discussed.

Great questions were raised and answered, many of which will greatly help implementer of this concept avoid making mistakes.

A good example of this was the question of propagation. As a proof is intended to propagate as fast as possible, helped by its small size, we get a little problem where the proof may outrace the transaction it is about. This is a problem because a spam-protection requires the transaction to be part of the mempool before the proof is relayed.

Identifying these kind of design ideas are crucial to solving them, which is not too hard once you are aware of the requirements. For the technical inclined, the solution is a short-lived proof mempool. I explained more in the panel discussion video.

The proofs proposal had a 100% (with one abstention) vote of support, we can expect further technical work to continue on this with actual code and testing in the not-so-far future.

NP (non priority) transactions

This proposal should not be confused with the super-standard proposal, although there is a certain overlap.

The NP transactions are essentially transactions that are not accepted by the majority of the nodes. But some nodes and miners do accept them which is a problem because this makes it more probable to create a successful double spend.

The proposal states that in the case a miner accepts, for instance, zero fee transactions it will replace that transaction with a standard transaction should the standard transaction come in later. Which is essentially a heuristic applied to guess that makes it in line with the majority of the network.

A lot of people found the idea interesting and were open to trying it out, but as a phase 2 after the proofs are already present on the network.

The fact that this is optional and there is no need for a majority of miners or anything similar makes this easier.

One thing was clear, though. Should a mature full-network pre-consensus solution be rolled out that such a solution would make the tx replacement irrelevant. As such people may just skip this project and focus on the (bigger and thus longer term) project of pre-consensus.

Weak blocks (pre-consensus 1)

Weak blocks is an idea to essentially synchronise participating miners based on less-proof (throwaway) blocks.

This technique is essentially not new as it is used by some mining pool software for a long time. The difference is that this project would be used to synchronise multiple mempools.

There were some objections to this, the main one being that its tricky to roll out on a big scale. There has to be a balance between how often a block is found and the distance to nodes.

Some mining nodes were interested in trying this on a short notice because bigger miners have maybe 40 full nodes worldwide that are currently not doing any synchronising at all.

Project Avalanche (pre-consensus 2)

This project is being researched and written for some time now and has learned a lot from previous ones. Everyone at the workshop found the research very interested and were eager to work towards a Bitcoin Cash version that miners would be able to use.

The authors currently suggest this as a softfork based on the idea that the network would be able to use the state as a way to warn users and merchants. It would be a soft fork because there is a need to orphan blocks that mine something that goes against the implicit promise made by the network. For instance if the network states TX to Alice will be mined and a miner instead mines the double spend paying Bob.

The suggestion we make to the authors is to drop the need for a soft fork, making the miners run this voluntarily, based on the idea that proofs will be more than enough for users and merchants. Turning this into a mandatory thing can be done at any time in the future based on actual performance and usage, as well as client support.


This proposal is based on a new opcode we expect to get activated in a month and it allows a user to create what I’d call an anti-replace-by-fee transaction.

The normal most used way to do double-spend is to pay a higher fee for the transaction you send to yourself. This proposal suggests the crafting of a new output in the transacting that pays the merchant which counters this.

The choice for a miner in the replace-by-fee situation is that the one stealing from the merchant is better for the miner, and this proposal turns that up-side-down by using a clever trick which allows a miner to actually get a huge payout from mining the “real” transaction. The one paying the merchant.
This means that a replace-by-fee double spend can’t work anymore, you would have to make the fee insane to override the forfeit amount .

This proposal is completely orthogonal to all other proposals, but requires integration from both wallet and merchant software as well as awareness (and probably code to support it) on the miner side.

While everyone really liked the idea, the author made clear he wants more peer review and actual user interface people to push this forward.

Network health (monitoring)

Based on a talk by myself we talked about how it would be very useful to create either more proofs or simply to have a network-monitoring setup that does things like detect the amount of double spends, that detects if miners mine obvious replace-by-fee transactions and any other such odd behaviour we can come up with.

This was universally seen as a good thing, as one participant clearly stated that nobody will object to observing more about our network.

Final thoughts

This was a most amazing workshop or mini conference where months long disagreements were solved in days, where exciting ideas were shared and where there was a really great vibe in general.

The Bitcoin Cash ecosystem is very much alive and kicking, there were half a dozen implementations represented and most of them were thinking largely along the same lines.

The future is bright, the future is Cash.