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.
file gets chunked into 32-byte chunks. They are hashed into a Merkle root, which is the file_id.
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.
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.
Servers respond to client requests with a zero-knowledge proof, which expresses
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
| # The extended euclidean algorithm | |
| def egcd(aa, bb): | |
| lastremainder, remainder = abs(aa), abs(bb) | |
| x, lastx, y, lasty = 0, 1, 1, 0 | |
| while remainder: | |
| lastremainder, (quotient, remainder) = remainder, divmod(lastremainder, remainder) | |
| x, lastx = lastx - quotient * x, x | |
| y, lasty = lasty - quotient * y, y | |
| return lastremainder, lastx * (-1 if aa < 0 else 1), lasty * (-1 if bb < 0 else 1) |
Alice and Bob want to put a token in an offchain contract that expresses:
The problem is that Alice does not want to use any onchain data to reveal the preimage. This is possible with the following setup upfront:
K and encrypts her preimage with that keyK
| // | |
| // SIMD Operation for Bitwise Rotations of Seven UInt32 Values in Parallel | |
| // | |
| %builtins bitwise | |
| from starkware.cairo.common.bitwise import BitwiseBuiltin | |
| // How many bitwise steps do we want to rotate? | |
| // 2**t expresses a rotation of t bits to the right. |
| # 32-Bit Arithmetic native to Cairo's Finite Field | |
| # | |
| # A collection of operations for 32-bit arithmetic performed in the | |
| # exponents of elements of Cairo's finite field. | |
| # | |
| # The field's modulus is | |
| # 2**251 + 17 * 2**192 + 1 == 2**192 * 5 * 7 * 98714381 * 166848103. | |
| # so it contains multiplicative subgroups of sizes | |
| # 2**192, 2**191, 2**190, ..., 2, 5, 7, 98714381, 166848103, ... | |
| # |
| %builtins range_check | |
| from starkware.cairo.common.registers import get_ap, get_fp_and_pc | |
| # from starkware.cairo.common.pow import pow | |
| from starkware.cairo.common.registers import get_label_location | |
| from starkware.cairo.common.math import assert_le | |
| # P = 2**251 + 17*2**192 + 1 | |
| const G = 3 |
TL;DR: We can enhance Bitcoin's scripting capabilities with client-side validation protocols. However, off-chain protocols like RGB or Taro do require some on-chain data.
Suppose we're given a client-side validation scheme for tokens on Bitcoin such as Omni, RGB, or Taro.
We want to express a simple spending condition that we cannot express in Bitcoin Script alone. For example, a hashed timelock contract that uses SHA3 instead of SHA2. So we want to express:
<hash> within a week.