As part of the transaction, there is a locking script that only Bob can unlock. The UTXOs are transferred once the transaction has been submitted, and it is added to the Bitcoin blockchain. By providing his signature, Bob can remove a locking script (or scriptPubKey) and he can use the UTXO as an input into a transaction.

The most common and basic form of bitcoin transactions utilise the Pay-to-Public-Key Hash (P2PKH) script. Bitcoin’s script language uses commands (or functions) that determine the instructions recorded with each transaction with more complicated transactions. Known as OP_CODEs, they enable us to set up certain conditions to transfer the ownership of coins.

For example, a multi-signature scheme (multi-sig for short) may specify that 3-of-5 participants must provide their signatures to spend the coins. Another example is the use of timelocks (such as nLockTime) to lock coins until a specified point in the future.

Another advanced type of transaction is Pay-to-Script-Hash (P2SH), which allows the sender to commit funds to a hash of an arbitrary valid script. The use cases for P2SH include multi-signature and non-native SegWit transactions. Also, several spending conditions can be combined to create complex smart contracts.

The locking script in a P2SH transaction is replaced by the ‘redeem script’. All scripts are revealed when the owner of the coins spends them as well as the solution to the script that locks up the bitcoins. Using the hash of the script included in the blockchain, anyone can check the conditions of the script to spend those bitcoins were met.

P2SH addresses start with a ‘3’, unlike P2PKH addresses which start with a ‘1’. As a result, a drawback with P2SH transactions is that they reveal all possible conditions and identities within the multi-sig.

From the Bitcoin rich list, we can easily distinguish between P2PKH and P2SH addresses. The addresses that start with a ‘3’ above are identified as multi-signature addresses (3-of-5 and 2-of-3). Addresses starting with a ‘3’ may also be SegWit scripts or Lightning Network end points. Addresses starting with a ‘1’ are P2PKH addresses and are not SegWit enabled.

Since P2SH transactions reveal the entire script once coins are spent, network participants can uncover of all the different ways they could have met the conditions (enabling the distinction between multi-signature transactions and P2PKH transactions). Network participants may also be able to deduce what type of wallet was used.

There’s also a disadvantage for scalability: complicated scripts have higher transaction sizes requiring more space on the blockchain (resulting in higher transaction fees).

Schnorr Signatures (BIP 340)

The first of the three-part BIP put forward by Pieter Wuille, BIP 340, lays out the specification of a more efficient digital signature scheme for Bitcoin: Schnorr signatures.

What are Schnorr Signatures?

As explained in the preceding section on how bitcoin transactions work, a scripting language controls the spending of coins and involves the use of digital signatures to transfer ownership of coins. Bitcoin checks cryptographic signatures using the Elliptic Curve Digital Signature Algorithm (ECDSA) (which doesn’t provide native support for multi-sig transactions and led to the standardisation of P2SH transactions in 2012).

In short, the Schnorr signature scheme (hereafter referred to as ‘Schnorr’) is a more efficient signature scheme. Developed by Claus-Peter Schnorr in 1989, this signature scheme was patented up until 2008. Bitcoin relied on OpenSSL for its cryptography, as ECDSA had become the standard and is the main reason for its use.

Schnorr builds on top of Segregated Witness, which was activated on Bitcoin to fix malleability problems in August 2017. With SegWit, it moves all scripts and signature data to the ‘witness’. The witness is a part of the transaction that is appended as a separate structure and no longer included in the list of inputs.

Let’s look at the main properties of Schnorr and the benefits for Bitcoin. First, we look at key aggregation, which follows on from the linear property.

Key Aggregation

The main benefit of Schnorr relates to multi-signature transactions.

Schnorr signatures are linear in that they can be subject to addition (or subtraction). The result is a valid signature corresponding to the same addition (or subtraction) of the public keys. The same does not hold with ECDSA and adding or subtracting these types of digital signatures is meaningless.

From its linearity, Schnorr enables key and signature aggregation. Aggregation means that we can combine several public keys into one, so that one signature is required for all parties. By summing the keys of the inputs, they are aggregated into a single signature where each signer contributes a partial signature.

The equations below illustrate aggregation with Schnorr thanks to its linear property. No one (apart from the participants) knows that there are three people behind the public key/signature.

Key/signature aggregation with Schnorr

With M-of-n multi-sig transactions, partial signatures are called threshold signatures. As shown by the diagram below, in a 3-of-5 multi-sig at the moment, you have M=3 signatures (out of n=5) as part of the inputs of the transaction.

How a 3-of-5 multi-signature currently works with bitcoin. The observer can recognise a) it’s a multi-sig setup and b) the public keys behind the multi-sig.

M-of-n multi-sig transactions need M signers at the very least (and each signature needs to be verified) and to prove ownership of a UTXO of a multi-signature key, the scriptSig (or Unlocking Script), would have to contain M number of ECDSA signatures. The size of scriptSigs grows linearly according to M number of signatures, which increases the size of these transactions (and increases transaction fees).

Also, an observer will know that A, B, and C signed a transaction and they can also identify the multi-sig setup used.

But, with Schnorr, M signatures are aggregated into a single signature. Once the threshold public keys and threshold signatures are provided, the transaction is authorised and looks like a normal P2PKH transaction to an observer.

3-of-5 multi-signature transaction with Schnorr. The observer does not recognise it’s a multi-sig setup and can only link the aggregated signature/public key to the transaction.

Schnorr enables us to produce only one signature for all M parties. The unlocking script would have one signature representing an aggregate of the participant’s signatures. An observer can no longer link a transaction’s signature to one person, many people or a threshold of people.

While the addresses and transaction amounts are still publicly visible, Schnorr by itself makes wallet/use-case fingerprinting more difficult (which are both used in taint analysis).

Going further with Schnorr’s ability to be added or subtracted opens up new and interesting applications. One example is Scriptless Scripts, a method of executing smart contracts on Bitcoin. Scriptless Scripts relies on Schnorr’s linear property to create adaptor signatures, enabling atomic swaps.

The table below shows the advantages of Scriptless Script atomic swaps.