Skip to content

Instantly share code, notes, and snippets.

@RubenSomsen
RubenSomsen / Silent_Payments.md
Last active March 5, 2023 01:13
Silent Payments – Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead
View Silent_Payments.md

Silent Payments

Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.

Overview

The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.

Compared to previous schemes[^1], this scheme avoids using the Bitcoin blockchain as a messaging layer[^2] and requires no interaction between sender and recipient[^3] (other than needing to know the silent payment address). The main downsides are the scanning requirement, the lack of light client support, and the requirement to control your own input(s). An example use case would be private one-time donations.

@dexX7
dexX7 / send-to-many.md
Last active October 2, 2022 17:19
New Omni Layer transaction: Send-to-Many
View send-to-many.md

Send-to-Many transactions

A new transaction structure allows to include multiple transfers in one transaction.

The payload of this new transaction type includes one token identifier, which defines the tokens to send. It also includes a list of receiver -> amount mappings to specify, which receiver receives how many tokens. Receivers are specified by actual Bitcoin transaction outputs, which are referenced in the payload. One or more receivers can be defined.

The new transaction type has 7 as identifier.

The payload structure may look like this:

View softchains.md

Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs

Originally posted on bitcoin-dev.

This post describes a fully decentralized two-way peg sidechain design. Activating new sidechains requires a soft fork, hence the name softchains. The key aspect is that all softchains are validated by everyone via Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus mechanism that only requires the validation of disputed blocks. This does increase the validation burden of mainchain full nodes, but only by a minimal amount (~100MB per chain per year). It's similar to [drivechains][0], but without the major downside of having to rely on miners, since all Bitcoin full node users can efficiently validate each sidechain.

Proof-of-Work Fraud Proofs

Last year I posted the idea of [PoW FP to the Bitcoin mailing list][1] ([follow-up here][2]). The idea is that we can use the existence of a fork in Bitc

@DavidBurkett
DavidBurkett / OneSidedMWTxs.md
Last active December 17, 2020 01:38
Offline Transactions in Mimblewimble
View OneSidedMWTxs.md

Offline Transactions in Mimblewimble

Mimblewimble is a blockchain protocol that improves on bitcoin's privacy and scalability by using pedersen commitments, schnorr signatures, and a novel technique called 'cut-through'. These benefits have come at a steep cost. Building transactions have thus far required interaction between the sender and receiver to create the outputs and collectively sign the transaction. We present here a method of achieving one-sided transactions while minimizing the impact on the scalability and privacy of mimblewimble.

Current Protocol

Like bitcoin, Grin uses a UTXO model. Transactions are created by including inputs to spend, creating new outputs of equal or lesser value, and signing and building rangeproofs to verify ownership of the inputs.

Unlike bitcoin, Grin uses confidential transactions, so the inputs and outputs are pedersen commitments (r*G + v*H). Instead of the signatures being added to the inputs, there is only one signature per transaction, which is part of the

@RubenSomsen
RubenSomsen / BMM.md
Last active July 28, 2022 20:59
Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )
View BMM.md

Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

Update: the content of this gist is also explained in this Spacechains video.

This write-up was also published on bitcoin-dev.

Blind Merged Mining (BMM) is the idea of committing the hash of another blockchain into a unique location on the Bitcoin blockchain, and paying a Bitcoin fee to miners for the privilege of deciding this hash and capturing the fees inside the other blockchain. Since miners don’t have to know what the hash represents and are simply incentivized to choose the highest bidder, it requires no extra validation on their part (“blind”). This idea was originally conceived of by Paul Sztorc, but required a specific soft fork. [0]

In essence, BMM is a mechanism that allows external blockchains (altcoins, tokens) to outsource their mining to the Bitcoin blockchain. Instead of burning electricity with ASICs, th

View GitHub spoiler markdown.md

Demo:

Spoiler warning

Spoiler text. Note that it's important to have a space after the summary tag. You should be able to write any markdown you want inside the <details> tag... just make sure you close <details> afterward.

console.log("I'm a code block!");