Robin Linus RobinLinus

Emulating CTV with a Trust-minimized Committee

The following describes a trust-minimized scheme to emulate op_checktemplateverify. The high-level idea is to run a everyone-can-join multi-party computation in a publicly verifiable way, by inscribing every message of the protocol into the Bitcoin blockchain.

A committee of Bitcoin stakers combined with onchain proofs of publication prevent censorship and guarantee liveness. The protocol is secure, that means the covenant is unbreakable, if there is at least one honest staker.

Naive Deleted-Key Covenant using a Single Co-Signer

Firstly, we discuss some "naive", oversimplified solutions, which do not work in practice. That helps to understand our final solution.

We want to emulate op_checktemplateverify scripts like

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
 OP_CLTV OP_2DROP

Raw Bitcoin Transactions

P2PK

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

Raw

https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704000000004847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901ffffffff0200ca9a3b00000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000

Parsed

Mapping a Secret Scalar Value between Elliptic Curve Groups [broken]

This document outlines a method to map a secret scalar value x from one elliptic curve group (secp256k1) to another elliptic curve group (a pairing-friendly curve). This method leverages a variation of the Schnorr signature scheme to prove that the same secret scalar is used in both groups without revealing the value of x. This approach can be useful in applications where compatibility with different cryptographic groups is required. For example, in the context of using the Lightning Network to purchase in a PTLC a key to be used with pairing-based cryptography. In general, it is interesting for Adaptor Signatures, Scriptless Scripts, and Discreet Log Contracts.

Setup

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

Sats4Files [Simplified]

The client wants to buy from the server the file corresponding to a particular file_id. The following is a very basic scheme solving the problem in a naive way.

The file gets chunked into 32-byte chunks. They are hashed into a Merkle root, which is the file_id.
The client buys from the server one Merkle branch after another via Lightning payments. The payment's preimage is the Merkle leaf.

Limitations and Optimizations

Sending 32 MB requires 1 million Lightning transactions. That means equally many signatures.

Sats4Files: Decentralized File Hosting based on Lightning

A decentralized file hosting protocol in which clients pay per request. Client and server perform a fair exchange of coins against files, using a Lightning payment combined with a proof of encryption. This document describes a naive system which is probably too slow, however it intends to spark a discussion about which proof systems could make it practical, because that could allow to decentralize the web.

Sats4Files Problem

A “Sats4Files protocol” allows users to request data from servers, and upon receiving the encrypted data, they can pay for the decryption key, e.g., 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.

Proof of Encryption

Servers respond to client requests with a zero-knowledge proof, which expresses

zkCoins

Edit: here you can find our research paper describing the protocol more in-depth.

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

	#
	# This is a scheme to encrypt a backup of a t-of-n Multisig spending script
	# such that any combination of t-of-n xpubkeys can recover the missing (n-t) xpubkeys.
	#
	#
	# In this example, we encrypt the 5 xpubkeys of a 3-of-5 Multisig
	# and demonstrate how to recover from any 3 xpubkeys the other 2 missing xpubkeys.
	#
	# The scheme is a simple variation of Shamir's secret sharing.
	# It is nicely compact. The encrypted payload is only the size of 2 xpubkeys.

	#
	# A variation of Shamir's t-of-n Secret Sharing scheme,
	# which allows to use any `n` values as secret shares
	# at the expense of having to store `(n-t)` many public shares.
	# This overcomes a drawback of the orginal scheme,
	# which requires to use the secret shares resulting from the scheme.
	#
	# For example, for a 3-of-5 this requires to store 2 public points.
	#