Catena: Efficient Non-equivocation via Bitcoin

Abstract

We present Catena, an efficiently-verifiable Bitcoin witnessing scheme. Catena enables any number of thin clients, such as mobile phones, to efficiently agree on a log of applicationspecific statements managed by an adversarial server. Catena implements a log as an OP_RETURN transaction chain and prevents forks in the log by leveraging Bitcoin's security against double spends. Specifically, if a log server wants to equivocate it has to double spend a Bitcoin transaction output. Thus, Catena logs are as hard to fork as the Bitcoin blockchain: an adversary without a large fraction of the network's computational power cannot fork Bitcoin and thus cannot fork a Catena log either. However, different from previous Bitcoin-based work, Catena decreases the bandwidth requirements of log auditors from 90 GB to only tens of megabytes. More precisely, our clients only need to download all Bitcoin block headers (currently less than 35 MB) and a small, 600-byte proof for each statement in a block. We implement Catena in Java using the bitcoinj library and use it to extend CONIKS, a recent key transparency scheme, to witness its public-key directory in the Bitcoin blockchain where it can be efficiently verified by auditors. We show that Catena can secure many systems today, such as public-key directories, Tor directory servers and software transparency schemes.

Secure Consistency Verification for Untrusted Cloud Storage by Public Blockchains

“…Similarly, CloudProof [20] requires the untrusted server to attest to the operation log and relies on the trusted clients to audit the operation history for a variety of consistency models. Catena [23] is a unique Blockchain-based log attestation scheme, which prevents the server-forking attack by "abusing" the Blockchain security in no double-spending transactions.…”

“…Attestation Auditing by Blockchain by Blockchain SUNDR [17], Caelus [16], CloudProof [20] ✗ ✗ Catena [23] ✓ ✗ ContractChecker ✓ ✓ 3 Research Formulation…”

“…Blockchain write availability: The Blockchain may drop transactions based on its current load and transaction fee. A transaction with a higher fee will have a lower chance of being dropped [23] and have shorter latency to be included. This assumption will be tested in our evaluation.…”

“…1) Low client cost: By delegating log audit to the Blockchain, one can significantly relieve the burden from the clients. Existing consistency-verification protocols are based on client-side log auditing [23,25], which requires a client to persist not only her own operations but also operations of all other clients, limiting the system scalability. By delegating log auditing to the Blockchain, a client can be relieved from accessing other clients' operations, and can have a minimal overhead of receiving log-auditing results from the Blockchain.…”

“…Asserting the storage consistency in a client-server system entails two conceptual steps: W1) establishing a globally consistent view of operation log across clients (i.e., operation log attestation), and W2) auditing the log for checking consistency conditions (i.e., log auditing). To the best of our knowledge, all existing approaches including Caelus [16], CloudProof [20], and Catena [23], assume trusted clients and rely on them to audit the log.…”