Jason Dreyzehner bitjson

SLP Indexing Review

Overview

This report was sponsored by an anonymous donor. I'd like to thank them for the generous contribution to the industry, the PSF, and to me.

The purpose of the report is to:

Assess the current state of SLPDB and SLP indexing in the industry.
Explore the costs of improving the indexer or creating a new one.

The SLPDB indexer gave rise to a prolific token economy on the Bitcoin Cash blockchain. eCash, a fork of Bitcoin Cash, also makes use of SLP tokens as well. Both ecosystems require a robust indexer in order to sustain their token economies.

Zero-Confirmation Escrows

Instant, incentive-secure payments on Bitcoin Cash

Read the specification:

https://github.com/bitjson/bch-zce

Review the authentication template in Bitauth IDE:

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

Title: BLOCK_INTERVAL adjustment mechanism
Author: Karol Trzeszczkowski (Licho)
Status:
Type:
Created: 2020-05-18

Abstract

BCH Script Roadmap

Goal and Scope

The goal of this document is to provide a framework for organizing and evaluating potential consensus changes to the Bitcoin Cash Script system. First, an overall approach for Script will be presented, and then several potential changes will be listed, and discussed within the context of the overall roadmap.

The scope of this document is to consider incremental upgrades to BCH Script. More overarching proposals such as a new transaction format (eg. MITRA), should be evaluated separately.

Approach

Taproot is an interesting technology to enable multiparty privacy on a bitcoin. Currently, there is a problem with multiparty contracts in that they are obvious deviation from the most common script type (P2PKH), which hurts privacy. The script that gets used will typically indicate exactly what kind of protocol was at play. Also complex P2SH scripts take extra resources (transaction size and CPU cycles).

The basic idea with Taproot is that instead of P2SH where a script is committed by a hash, you can hide a script (or set of possible scripts) as a commitment within a normal-looking public key. Now there are two ways to spend from this public key:

Create a normal transaction signature using the public key, or,
Reveal the commitment, and provide parameters that satisfy the revealed script.

To do #1, it means you need to know the private key, or, you have a set of signers who are able to produce a signature (that's where Schnor

Abstract

The p2sh notification protocol is to pin the p2sh address to the wallets of contract participants and provide aditional informations that will help participants deduce what contract is it.

Motivation

The main motivation of this protocol is to make p2sh smart contracts recoverable from the seed. Some smart contracts, like Licho Last Will or Moser-Eyal-Sirrer vault may be used for long term storage of savings. In this case it is desirable to have a way to reconstruct the contract address just from the seed.

Specification

p2sh notification message is a transaction with 1 OP_RETURN output and as many p2pkh dust outputs as the number of participants of the contract and possibly a change output.

The OP_RETURN output consists of:

Progressive knockout block filters

In my last gist, I described how the BIP158 block filters are technically not quite optimal, though in an inconsequential way since the false positive rate has been made so low.

In this document I'm going to describe how it's possible to significantly beat the bandwidth requirements of BIP158 while also achieving a lower overall false positive rate. The idea is to prepare multiple independent filters per block, each of which which has a higher false positive rate. Practically this can give roughly a factor of two improvement over BIP158, but at the cost of additional complexity.

The problem

The BIP158 false positive rate was chosen with a particular size of wallet in mind -- somewhere around 1000 items (addresses) to watch in each block. There is a trade off between the overall size of the filter (which must be do

Further minimizing the redundancy in Neutrino filters (BIP158 / Golomb sets)

Last year saw the introduction of BIP158 and Neutrino wallet which use Golomb-coded sets to very efficiently encode which items are in bitcoin blocks.

The basic idea in BIP158 is that we have N items of interest (such as distinct scriptPubKeys) in a block, which we hash to integers in the interval [0,F-1] for some range F that is much larger than N. These are basically short hashes, but with an uneven number of bits. This set of hashes can be queried to check whether a candidate scriptPubKey might be in a block, by computing the hash for the candidate and checking if that integer is in the set. The false positive rate is approximately N/F, and can be therefore tuned by making F larger or smaller.

Golomb-Rice comes into play by providing a very size-efficient way of encoding the list of hashes (by sorting them and encoding just the differences with an entropy-optimized code), which is important for minimizing over

	export const chaosTestStrings = (): void => {
	const textNodes = getAllTextNodes(document.body);

	for (const node of textNodes) {
	const textNodeLength = node.textContent ? node.textContent.length : 0;
	if (node.textContent === null) {
	return;
	}
	if (node.parentElement instanceof Element) {
	if (node.parentElement.dataset.originalText === undefined) {