Confidential Script

Inspiration

Building consensus around soft forks is extremely hard and controversial today. A trust-minimized opcode emulator could help break the deadlock by making it possible to safely use new opcodes without requiring a change to consensus.

What it does

Confidential Script is an AWS Nitro enclave that validates Taproot script path spends and deterministically produces signatures if those spends are valid. This can be used to emulate prospective opcodes on mainnet with minimal trust requirements. To prevent vendor lock-in, enclaves can be deployed by anyone and are automatically loaded with a master secret from KMS, which can be accessed by any enclave on any account running the same image.

How we built it

This project is purely architectural and has not yet been implemented. It uses AWS Nitro to securely retrieve and store the master secret and perform deterministic signatures. Nitro attestation and KMS policies are used to create a un-deletable KMS key that provably has never been and can never be accessed outside the enclave, and verified code ensures that the secret never leaks.

To create a receive address, the user first derives a child public key from the master public key and the root of a taptree of emulated scripts. This serves as the internal public key, which can then be tweaked to add fallback "real" Bitcoin scripts.

To spend from the address, the user sends to the enclave the spending transaction, the input index, the input scriptPubKeys, and the input amounts. The enclave validates the witness data at the input index using an internal script interpreter and, if valid, produces a signature using the corresponding child private key over the spending transaction, as if it were signing a key path spend. The user can then use this signature to spend the input.

Rust-bitcoinconsensus is the preferred method to validate script, though a fork would needed to validate new opcodes. As the library is now deprecated, a fork of libbitcoin-kernel or bitcoind may need to be used instead.

Challenges we ran into

I built a working a Nitro enclave but I couldn't figure out how to connect it to KMS. Nitro is poorly documented and remains hard to use.

Accomplishments that we're proud of

I'm proud of figuring out how to deploy a Nitro enclave and use Taproot to do soft fork emulation. It was also exciting to learn about AWS KMS and KMS policies, as I was not previously aware that this type of near-permissionless resource sharing was possible.