Skip to content

Instantly share code, notes, and snippets.

Avatar

RobinLinus RobinLinus

View GitHub Profile
@RobinLinus
RobinLinus / secp256k1_to_pairing.md
Last active May 19, 2023 04:39
Mapping a Secret Scalar Value between Elliptic Curve Groups
View secp256k1_to_pairing.md

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

@RobinLinus
RobinLinus / sats4files.md
Last active April 25, 2023 00:58
Sats4Files: Decentralized File Hosting based on Lightning payments
View sats4files.md

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.

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

Polynomial Encoding

@RobinLinus
RobinLinus / Sats4Files.md
Last active April 15, 2023 12:31
Decentralized File Hosting on Lightning
View Sats4Files.md

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.
@RobinLinus
RobinLinus / sats4files.md
Last active April 17, 2023 21:41
A decentralized file hosting protocol in which clients pay per request.
View sats4files.md

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

@RobinLinus
RobinLinus / zkCoins.md
Last active May 10, 2023 01:11
zkCoins: A payment system with strong privacy and scalability, combining a client-side validation protocol with validity proofs
View zkCoins.md

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

View csv-offchain-data.md

Offchain Contract Data for CSV Protocols

Alice and Bob want to put a token in an offchain contract that expresses:

  • Alice can take the token if she reveals the sha3 preimage of a hash within a week
  • Otherwise, Bob can take the token

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:

  • Alice creates a random key K and encrypts her preimage with that key
  • In the contract she commits to the resulting ciphertext and also to K
  • She sends the contract and the ciphertext to Bob
@RobinLinus
RobinLinus / simd.cairo
Last active November 17, 2022 23:59
Parallel processing in Cairo with single instruction, multiple data (SIMD) operations
View simd.cairo
//
// 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.
@RobinLinus
RobinLinus / uint32_in_exponent.py
Last active November 17, 2022 23:58
Emulate a Uint32 number type in a subfield of Cairo's `felt` type
View uint32_in_exponent.py
# 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, ...
#
View uint32.cairo
%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
@RobinLinus
RobinLinus / covenants.md
Last active May 29, 2023 17:00
A collection of resources related to covenants
View covenants.md