"Not Your Keys, Not Your Coins"... Is Not Enough.

https://link.medium.com/KYpn9Qmg9ab 

1/

Today we’re excited to launch Nunchuk Journal: a collection of articles that documents our thought processes in the creation of Nunchuk, how things impact the users & our observations about the industry at large.

The 1st episode: “Not your keys, not your coins” is not enough. 2/

"Not your keys, not your coins", coined by Bitcoin evangelist @aantonop (?), has been popular among the Bitcoin community for some time. “Keys” refer to the private keys, implying that those who are in possession of the private keys own the bitcoins controlled by those keys. 3/

While this slogan was true in the early days of Bitcoin, it is becoming increasingly irrelevant. The reason is the growing sophistication of key generation and smart contracts, including, but not limited to, multisig. 4/

Since Nunchuk’s mission is the proliferation of multisig, it is crucial that our first step is to clear up this misconception. 5/

(I) Back to basics: Bitcoin addresses

Bitcoin addresses are constructed using 2 components: a data component, and a script component that explains how those data should be used in locking up the bitcoins. 6/

In the early days of Bitcoin, both the data component and the script component were incredibly simple. The data was usually one single public key in uncompressed form. 7/

The script component was similarly straightforward. It either involved a single operation, OP_CHECKSIG (P2PK), or a slightly longer list of operations (P2PKH), but still highly predictable. In those early days, the addresses acted ultimately as aliases for the public keys. 8/

In this context, “not your keys, not your coins” makes sense. Whoever possesses the private keys can deduce the public keys. And from the public keys, the addresses. 9/

(In those early days) Possession of the private keys means that:

(a) We know which addresses our bitcoins are stored in, and
(b) How to unlock the bitcoins, once we know the addresses. 10/

(II) BIP16/BIP32

Things started to change with the introduction of more advanced scripting capabilities, beginning with BIP16 (P2SH). With P2SH, the script component can be almost anything. 11/

A good example is @peterktodd's bounties for finding cryptographic hash collisions. But a more typical use case for P2SH involves multisig wallets, where funds are controlled by more than one public key. 12/

Addresses of a P2SH-enabled multisig wallet are not predictable, because the order of the public keys included matters. For example, a 2-of-3 P2SH multisig address could be built 6 different ways, depending on how we order the 3 public keys. 13/

If we don’t back up the redeemScript, which contains this multisig key order, we might not even know which addresses belong to us! All is not lost, since we can “try out” all permutations. But this brute-force approach is costly and non-scalable, as we shall see later on. 14/

Another development occurred on the key component side of the address. Some time after P2SH was created, Hierarchical Deterministic (HD) wallets arrived, later standardized in BIP32. 15/

Prior to HD wallets, a wallet is simply a collection of random private keys. HD wallets create a key hierarchy so that the private keys belong to the same family, all generated from the same root called the master key. 16/

HD wallets also made addresses less predictable. For each address in a HD wallet, we need to know from which lineage that particular public key descended from the master key. This is called the BIP32 derivation path. 17/

To sum up: the introduction of BIP16 and BIP32 meant that possession of the private keys no longer suffices. We might also need the redeemScript (for BIP16) and the derivation paths (for BIP32) in order to fully "own" bitcoins. 18/

(III) SegWit and Taproot

Things became even more complicated with the activation of Segregated Witness, a much-anticipated suite of protocol updates that fixed critical issues such as transaction malleability. 19/

SegWit introduced a new and improved address format, called Bech32.

The problem is that now there are even more ways addresses can be generated from a single master key. 20/

For each address type (there are now 3: legacy, native segwit, and a hybrid called nested segwit), we face the same problems of BIP16 and BIP32. So we end up with permutations upon permutations of address possibilities! 21/

Levels of address permutations:

* Address types
* Script types
* Derivation paths
* Order of keys, if multisig

22/

This is where we are today. Both the key component and the script component of the address have gotten highly complex that possession of the private keys makes up only a small part of ownership. 23/

During this period, wallet vendors coped with this rising complexity through their own ad-hoc, proprietary ways, which led to unfortunate consequences. 24/

First, wallets became less compatible with one another. As an example, to recover a wallet created with one vendor in another requires looking up magic “recovery paths” and manually running conversion scripts, a process that is error-prone. 25/

Another negative side effect is the invention of poor concepts such as YPUB/ZPUB that further complicate the process and confuse the user.

We will discuss YPUB/ZPUB and why they should be avoided separately in another article. 26/

But it doesn’t stop there. Soon Bitcoin will have even more advanced scripting capabilities, such as Taproot. When that happens, the number of address permutations increases even further. 27/

(IV) Solution: Descriptor Language

Perhaps realizing the urgency of this problem, Core developer @pwuille set out to solve it. Pieter realized what we ultimately lacked was a higher-level language to tame this monstrous address complexity. 28/

The purpose of the descriptor language is to express precisely how keys are derived and how they are used in creating addresses.

With descriptors, the user only needs to back up 2 things for their wallet: the master keys (or BIP39 seeds), and the descriptors. 29/

There would no longer be any ambiguity, either in knowing which addresses on the blockchain belong to us, or how to recover the wallet using third-party tools.

In the future, it is crucial that all Bitcoin wallets move to a descriptor-first architecture. 30/

The days of “not your keys, not your coins” are over. Perhaps it is more fitting now to say:

“Not your keys, not your descriptors, not your coins”.

31/

Nunchuk leverages Core code directly, and treats descriptors as first-class citizens.

Everything in Nunchuk is designed around descriptors: from generating addresses, to wallet backups, to calculate transaction sizes and determine the optimal fee rates. 32/

Nunchuk’s core engine will be open-sourced on Friday the 13th. We will elaborate on our architecture decisions in future articles, once the code is out. Stay tuned! 33/

We will also start open-sourcing a Bitcoin Crash Course, an internal training curriculum designed to get you up to speed in Bitcoin in 1 to 2 weeks. All our new members, devs or non-devs, are required to complete the course. Stay tuned! 34/