RubenSomsen

Silent Payments Incorrect Prior Label Issue

The issue

In collaborative transactions¹ where both A and B are sending to the same user, A is unable to validate whether the label used by B was correct, yet the validity of A's payment depends on it.

Example:

Footnotes

1. While the simple example is coinjoins, keep in mind that multisig is also a form of collaboration, and even the interaction of a single user with a hardware wallet can be seen as a form of collaboration. If you're reviewing this document, this is good to keep in mind to ensure nothing was overlooked. ↩

RubenSomsen

Out-of-Order Validation & The Single Spend Check

This is largely a summary of a series of insights and ideas around parallel validation that were discussed at the 2140 Bitcoin Consensus Code Week. This involved participants who work on Bitcoin Core, Libbitcoin, Floresta, BTCD, and various others.

Maximizing Resources

It's well-known that in order to maximize your hardware resources, software generally should try to minimize ordering constraints. The more you can do in parallel, the better you can utilize your hardware without waiting on prior things to finish. This write-up maps out the areas where we can apply this to Bitcoin and what tradeoffs it entails. Most of this is not new and summarizes community knowledge, though one small novel component is how you can parallelize double spend validation with a single spend check.

First, let's describe the ordered components of validation.

RubenSomsen

Silent Payments Output Ambiguity Issue

The issue

There is an ambiguity issue in Silent Payments (SP) where there is a risk that different clients will find different amounts of funds.

Scenario: Transaction with multiple outputs, containing (at least) one correctly generated SP output.

Variant A: The same output key appears more than once (same k-value, same label)

RubenSomsen

Comparison: BIP Style & LabelSet

This document compares the theoretical scanning cost differences for silent payments depending on whether the "BIP style" or "LabelSet" algorithm is used. It is assumed that we primarily care about the upper bound of the scanning cost. In almost all cases this is a block filled with silent payment eligible transactions. The one exception is the case where a single user is being targeted under the BIP style algorithm, in which case the worst-case shifts to a block with a maximum number of outputs.

---

Summary

• BIP style scanning speed is fairly consistent throughout
• While LabelSet is slightly faster at low label usage, it gets significantly slower as label use increases

RubenSomsen

Transaction Output Bitfield Compression

Open research/dev problem for SwiftSync

You can represent the unspent transaction output (UTXO) set as a set of bits over the ordered set of all transaction outputs (TXOs), signifying whether it is spent or unspent. The majority of the TXOs will be spent, resulting in many 0 bits and relatively few 1 bits (e.g. 00100001). The number of unspent outputs (1 bits) will increase as we get closer to the tip. These predictable patterns are well-suited for compression.

We currently use the TXO bitfield in SwiftSync inside the so-called "hints file" to speed up IBD and intend to implement this into Bitcoin Core, but the distribution of the hints file is made harder by its size. For the initial release we will likely forgo optimal encoding, but it would be nice to eventually s

RubenSomsen

The Tragic Tale of BIP30

Bitcoindev mailing list thread here, podcast discussion here.

Introduction

In my recent exploration of [SwiftSync][1], I came to the realization that [BIP30][2] has an unresolved consensus bug. It seems this bug can't be triggered without a reorg back to 2010, so its seriousness is debatable. We currently have checkpoints up to 2013, preventing such a reorg. Once we fully [remove the checkpoints][3], the bug becomes theoretically (not practically) exploitable.

BIP30 is also a bit of an odd duck in terms of consensus checks in that it involves the entire UTXO set without being related to the spending of inputs. This is inefficient, and complicates the implementation of alternative validation methods such as utreexo, SwiftSync and quite possibly ZKP systems such as ZeroSync. It would be nice if we could sunset BIP30 altog

RubenSomsen

SwiftSync

Near-stateless, fully parallelizable validation of the Bitcoin blockchain with hints about which outputs remain unspent. All other inputs/outputs are efficiently crossed off inside a single hash aggregate that only reaches zero if validation was successful and the hints were correct.

15-minute talk summarizing the protocol

Introduction

Validation is at the heart of Bitcoin. Any improvements in validation speed will have a direct impact on the scalability of the system, including everything that is built on top of it. For this reason improving validation performance may be one of the most important things we can do.

RubenSomsen

RubenSomsen

Trustless Address Server

Outsourcing handing out addresses to prevent address reuse

Also discussed on bitcoin-dev.

Introduction

Address reuse prevention generally requires interacting with the recipient in order to receive a fresh address for each payment. There are various protocols that ensure no interaction is required such as BIP47[^1] and Silent Payments[^2], though neither is without downsides.

One area that is seemingly underexplored is that of outsourced interaction. BTCPay Server[^3] is an example of this. The sender interacts with a server, which acts on behalf of the recipient and hands out an address from an xpub. The recipient controls and therefore trusts the server, so malicious addresses won't be given out.

RubenSomsen

BIP47 Prague Discussion

This discussion took place at Pizza Day Prague 2022 after a brief discussion on Silent Payments. The main points have been summarized below.

The discussion was mainly between Alekos Filini, Martin Habovštiak, and Ruben Somsen, as well as Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore Ingala, and others.

This was also posted to the the bitcoin-dev mailing list.

Improving BIP47