yellowpages is a registry of post-quantum proofs of Bitcoin ownership. We’d like to be transparent about our current trust model, explain how we can get closer to the zero trust dream for yellowpages, and realistic about why zero trust wasn’t what we set out to achieve in version 1.
So let’s discuss the trust model involved in each aspect of yellowpages, in order of importance.
yellowpages registration requires the submission of a Bitcoin signed message. This involves making an ECDSA signature over a message, and is supported by most popular wallets. However, these signatures are public-key-recoverable, which means that the Bitcoin user’s public key can be derived from the signature. Public key recovery is a feature that has been useful in Bitcoin. However, now that Bitcoin public keys are at quantum-risk, we treat them in yellowpages as highly sensitive data. Hence, we must keep these Bitcoin signed messages private, using techniques such as post-quantum encryption and Trusted Execution Environments (TEEs).
Web Application:
We currently run the yellowpages.xyz as a standard web application, which runs in any browser.
- Project Eleven: although we have open-sourced the web application, Project Eleven could in theory deploy a malicious application to
yellowpages.xyzwhich is different to the source code shown in our GitHub repository. - Vercel: we use Vercel for deployments.
- Build Tools & Dependencies: we use build tools such as Next.js along with standard software dependencies. We use best practices to ensure we are doing integrity checks and using well-audited dependencies wherever possible.
- GitHub: we use GitHub for source control.
Proving Engine:
- AWS Nitro Enclaves: our Proving Engine runs within an AWS Nitro Enclave.
- Build Tools & Dependencies: we use build tools such as Rust, Docker, Evervault Enclaves, and GitHub Actions in our deployment process, and use software dependencies to run the Proving Engine. All of the build tools and dependencies for the Proving Engine are open-source, and we use best practices to ensure we are doing integrity checks and using well-audited dependencies wherever possible.
- GitHub: we use GitHub for source control.
We can remove the Privacy trust in Project Eleven, Vercel, and GitHub by providing a non-web client application, such as a CLI or desktop application. We chose to do a web application for the version 1 of yellowpages, to provide a free application that is accessible to the maximum number of Bitcoin users, without requiring them to install anything.
If we publish a proof that a Bitcoin address has been linked to post-quantum addresses, it must be seen as a legitimate proof. Different proving methods have different trust assumptions, such as trusting cryptography schemes, cryptography implementations, and centralized entities.
- AWS Nitro Enclaves: when all proof data has been verified, we publish a Nitro Enclaves attestation document which includes the addresses whose linkage has been successfully proven. The source code of our Proving Engine can be audited by users to verify that attestation documents of this form will only be generated by the Proving Engine once all of the supplied proof data has been verified.
- Build Tools & Dependencies: we use build tools such as Rust, Docker, Evervault Enclaves, and GitHub Actions in our deployment process, and use software dependencies to run the Proving Engine. All of the build tools and dependencies for the Proving Engine are open-source, and we use best practices to ensure we are doing integrity checks and using well-audited dependencies wherever possible.
We can remove the Proof Legitimacy trust in AWS Nitro Enclaves by switching to a ZK proving technology, such as ZK-SNARKs. As these technologies rely solely on cryptography, they don’t place trust in a single entity.
As the privacy of our users’ data is our #1 priority, we decided to spend time reviewing the “zero knowledge” property of SNARKs before opting to use them in yellowpages. By uploading ZK-SNARK proofs on yellowpages, we would effectively be uploading encrypted Bitcoin public keys on the internet. Hence, it is critical that the zero knowledge property is post-quantum secure.
During our design phase, we spoke to some developers of post-quantum SNARKs, but none of them could guarantee us audited, post-quantum privacy in the near-term – they could only guarantee us post-quantum soundness. Hence, we decided not to include SNARKs in the first version of yellowpages.
Most proving technologies, including most ZK-SNARKs and TEEs, produce proofs which rely on elliptic curve cryptography (ECC). As ECC is not post-quantum secure, these proofs could be forged after Q-day. However, timestamping the proofs allows us to use proving systems which rely on ECC, provided we only consider proofs which have timestamps before Q-day to be valid.
Decentralized OR Project Eleven: AWS Nitro Enclaves don’t guarantee that the timestamps in their attestation documents will be accurate, so an extra timestamp is added to proofs when they are registered to yellowpages. If a user wants to create a decentralized timestamp of their proof, they can publish a hash of their proof on a popular blockchain.
When a proof is created, we could store a hash of the proof on a trusted blockchain, such as the Bitcoin blockchain. The block height it was entered to the blockchain can be used as a timestamp. As a more cost-effective solution, we could timestamp multiple proofs at once, by placing a merkle root or similar on the blockchain. This will take some decent engineering effort to do properly, as we don’t want to clog the Bitcoin blockchain with unnecessary data. For this reason, we decided not to include it in version 1 of yellowpages.
If a user submits a proof to yellowpages, they should have confidence that it won’t be censored via deletion, nor that a cyber attack could destroy their proof.
Decentralized OR Project Eleven: users can download their proof if they want to, and upload it onto a decentralized storage platform. Otherwise it will be stored by Project Eleven. We use best practices for database management and generate backups at a regular interval.
We could store all proofs on a decentralized storage solution such as IPFS. We want yellowpages to be free, and we decided not to add IPFS as a cost in version 1 of yellowpages.