RobinLinus

zkCoins

zkCoins is a novel blockchain design with strong privacy and scalability properties. It combines client-side validation with a zero-knowledge proof system. The chain is reduced to a minimum base layer to prevent double spending. Most of the verification complexity is moved off-chain and communicated directly between the individual sender and recipient of a transaction. There are very few global consensus rules, which makes block validation simple. Not even a global UTXO set is required.

In contrast to zk-rollups there is no data availability problem, and no sequencer is required to coordinate a global proof aggregation. The protocol can be implemented as an additional layer contained in Bitcoin's blockchain (similar to RGB[^5] or Taro[^6]) or as a standalone sidechain.

The throughput scales to hundreds of transactions per second without sacrificing decentralization.

Design Principles

The core design principle is to *"use the chain for what the chain is good for, which is an immutable order

RobinLinus

The following script allows everyone to spend; the shorter your signature the earlier you can spend.

OP_SIZE
OP_CHECKSEQUENCEVERIFY OP_DROP

OP_CHECKSIGVERIFY

The point R = 1/2 G has the smallest known x coordinate -- x = 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63. If the public key is chosen P = 1 G then the ECDSA signature becomes s=2(H(m)+x). So, the smaller H(m) the smaller s (as long as it is bigger than x ~ 2^165). Thus, the above output is spendable by the miner mining the lowest TX hash.

RobinLinus

Raw Bitcoin Transactions

P2PK

https://blockstream.info/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee

Raw

https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704000000004847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901ffffffff0200ca9a3b00000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000

Parsed

RobinLinus

Covenants

Covenant-enabling Bitcoin Features

• BIP119: CHECKTEMPLATEVERIFY (CTV) by Jeremy Rubin
• BIP118: SIGHASH_ANYPREVOUT (APO) (aka SIGHASH_NOINPUT) by Christian Decker and Anthony Towns
• OP_CAT by Andrew Poelstra
• OP_CHECKSIGFROMSTACK (CSFS) + OP_CAT
• OP_TAPLEAF_UPDATE_VERIFY (TLUV) by Anthony Towns
• TXHASH + CHECKSIGFROMSTACKVERIFY (TXHASH + CSFS) by Russel O'Connor
• OP_EVICT by ZmnSCPxj

RobinLinus

OR Operator for DLCs and PTLCs

We construct an OR operator for adaptor points:

If Alice learns the dlog of T₁, or T₂, ..., or Tₙ, then she also learns the dlog of X.

This is possible using verifiable encryption (see "Juggling" by Shlomovits et al.). An OR operator allows to condense complex spending conditions into a single point. This prevents the combinatorial explosions which usually occur when using multi-oracles. An OR operator makes spending conditions easily composable. In theory, it even enables arbitrary computations on values provided by oracles.

Motivation

Applications for the OR operator include Discreet Log Contracts (DLCs), adaptor signatures, and Point Time Locked Contracts (PTLCs):

RobinLinus

OP_CAT Enables Scalar Multiplication for EC Points

CAT can reduce curve point scalar multiplication to a subtraction in the scalar field.

Subtraction of field elements can probably be emulated in less than 250 (?) opcodes. For now, let's assume we had an (emulated) opcode, op_scalar_sub, for subtracting two elements of the scalar field of secp256k1.

Given secp's generator G, we want to compute for some scalar r the point R = rG

That is possible by hacking it into a Schnorr signature (R,s) for the key P = xG = 1G = G

RobinLinus

Covenants with CAT and ECDSA

In his article, CAT and Schnorr Tricks I, Andrew Poelstra showed how to emulate OP_CHECKSIGFROMSTACK-like covenants using only OP_CATand Schnorr signatures.

Here, we show that a similar trick is possible to emulate covenants using only OP_CAT and ECDSA signatures.

The High-Level Idea

Recall the ECDSA Signature Equation

RobinLinus

Improved Stealth Addresses

This is a scheme for stealth addresses which requires little computational overhead for the recipient to scan the chain. It builds upon many previous ideas. It reduces the overhead for scans from O( #TXs ) to O( #users ).

Protocol

• All senders register on their first send a public key in a public directory.
• Recipients perform a DH key exchange with each sender key in the directory to derive all their potential receive addresses.
  • Sender key: A = aG
  • Recipient key: B = bG
• Shared secret: s = abG

RobinLinus

Commit to a Bit Value using a Schnorr Signature

This is a bit commitment (e.g. for BitVM) which allows you to commit to the value of a 1-bit variable across two different UTXOs via Schnorr signatures. If Paul equivocates on the bit's value then he leaks his private key.

Surprisingly, the commitment script doesn't need to commit to anything specific. All semantics arise from the nonces in the partial signatures. That allows you to reprogram gates after compile time.

Commitment Script

The commitment script uses OP_CODESEPARATOR such that public key P can sign off on one of two execution branches in the script. Depending on which branch is signed, the script leaves 0 or 1 on the stack.

RobinLinus

31-bit Commitment

This is a 31-bit commitment in Bitcoin Script.

OP_DUP
OP_TOALTSTACK

OP_DUP
<1073741824>