Skip to content

Instantly share code, notes, and snippets.

View RobinLinus's full-sized avatar

Robin Linus RobinLinus

View GitHub Profile
RobinLinus /
Last active February 24, 2024 04:16
zkCoins: A payment system with strong privacy and scalability, combining a client-side validation protocol with validity proofs


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 /
Created June 8, 2023 21:50
Raw Bitcoin transactions hand-parsed for educational purposes

Raw Bitcoin Transactions





RobinLinus /
Last active February 19, 2024 01:30
Emulate covenants using only OP_CAT and ECDSA signatures

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


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 ).


  • 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 /
Last active December 31, 2023 19:03
A collection of resources related to covenants
RobinLinus /
Last active November 22, 2023 23:20
OP_CAT Enables Scalar Multiplication for EC Points

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


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.


31-bit Commitment

This is a 31-bit commitment in Bitcoin Script.


RobinLinus /
Last active October 9, 2023 21:00
Sats4Files: Decentralized File Hosting based on Lightning payments

Sats4Files: Decentralized File Hosting based on Lightning

Sats4Files is a protocol for decentralized file hosting. It allows users to request data from untrusted servers, and upon receiving the encrypted data, they can pay for the decryption key via Lightning. The exchange is atomic, ensuring that the user only receives the data if they pay for it, and the seller only gets paid if they deliver the data. The protocol is an efficient form of verifiable encryption, which is similar to verifiable secret sharing using Shamir's algorithm.

This scheme is simplified and does not fully solve the problem, as discussed in the Limitations section. This writeup intends to spark interest to solve the remaining issues beyond the fixes that we suggest.

Sats4Files Problem

The client wants to buy from the server the file corresponding to a particular file_id.

Here, we assume we have PTLCs on Lightning instead of HTLCs. That means we can buy a discrete logarithm over Li

RobinLinus /
Last active September 10, 2023 20:27
A crazy two-way peg bridging BTC to other chains

Some Day Peg

A two-way peg bridging BTC to other chains. It works similar to a perpetual one-way peg; however, instead of burning the BTC they are locked up until a particular time in 20 years. Until then, the community has to figure out how to do peg-outs with, e.g., some sort of OP_ZKP_VERIFY or Simplicity.

We simply pretend that OP_NOP10 is OP_ZKP_VERIFY and let users lock BTC in the following script:

<program_hash> OP_NOP10