Delegation in Bitcoin

This post was first published on Medium. Read Part 2 here.

We introduce a novel way for Alice to allow Bob to spend her UTXO/coins, without giving Bob her private key. Alice signs Bob’s public key and thus delegates the power to spend to Bob. There are many use cases for delegation. For instance, a user can authorize an app to spend money on her behalf. Or a CFO wants the head of a department to issue funds provisioned to the department.

Delegation

Previously, we have developed a way for Alice to sign arbitrary message in a transaction using her Bitcoin private key. For delegation to work, the message is simply Bob’s public key. By signing Bob’s key, Alice delegates to Bob the power to spend her coins¹.

When Alice wants to delegate, she first locks funds into the following contract.

Contract Delegate

She signs Bob’s public key using her own private key, i.e., ownerSig at Line 6. She hands the partially signed transaction to Bob. Bob adds his signature (delegateSig at Line 6) to the transaction and broadcasts it to spend the locked funds. Line 10 verifies Bob’s public key is signed² and thus authorised by Alice. Line 13 checks Bob’s signature.

Note the delegation does not create any onchain transaction, which only occurs when Bob actually spends the UTXO.

If Alice wants to spend the UTXO herself, she can simply delegate to herself by signing her own public key. She can thus revoke the delegation before Bob moves the coins.

Delegation vs Multisig

Compared to traditional 2-of-2 multisig between Alice and Bob, the above contract can delegate to anyone (e.g., to Charlie or Dave), even after the UTXO is created. The delegate is undetermined in advance and can be chosen at will later, while a multisig has to know all delegates beforehand, which cannot be changed later on. Delegation is more flexible.

Delegate Multiple Times

After Alice delegates to Bob, Bob delegates to Charlie, Charlie delegates again to Dave, and so on.

The following modified contract allows delegation multiple times.

Contract Delegate

Basically, Alice signs Bob’s public key, Bob signs Charlie’s public key, … Line 13 validates the signing and thus delegation as before. Only the last delegate has to sign to spend the coins at Line 18.

***

NOTES:

[1] Alternative signature algorithm such as Rabin Signature can also be used. We choose ECDSA here for its simplicity due to reusing Bitcoin keys.
[2] Note Oracle.verifyData() uses SIGHASH_NONE internally, so Bob can spend to whatever outputs he desires.

Watch: CoinGeek New York presentation, Smart Contracts & Computation on Bitcoin