Jason Dreyzehner bitjson

Targeted VM Limits Benchmarks

This is a Gist designed for importing into BitAuth IDE.

To import the below template into the IDE, open this URL:

https://ide.bitauth.com/import-gist/6be7fbca3b3f77d60bc8953439e42612

We couldn’t find that file to show.

Treeless ZCE

This is a Gist designed for importing into BitAuth IDE.

To import the below template into the IDE, open this URL:

https://ide.bitauth.com/import-gist/12c7d7bba3b0a5d8ef83ef3b9096fede

Experimenting with Contract State Merkle Trees

This is a Gist designed for importing into BitAuth IDE.

To import the below template into the IDE, open this URL:

https://ide.bitauth.com/import-gist/0c0ca878e3fb5806e6f9648e44c2ce66

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

layout	title	date	activation	version	author
specification	2020-NOV-15 128-bit integer specification	2020-01-14	2020-NOV-15	1.0	Tobias Ruck

Summary

1. Problem Statement/Use Case

Without going into any history or context, what are the practical implications of solving the problem you’re trying to solve?

Bitcoin Cash already has a very powerful programming language – by solving an issue with how transactions are formatted, we'll be able to build advanced, Decentralized Finance (DeFi) applications which scale better than those on "global state" networks like Ethereum.

What use-cases would be enabled, and why should they be accommodated?

PMv3 would allow BCH developers to build almost any kind of decentralized application currently possible on other "smart contract"-focused cryptocurrency networks, including prediction markets, synthetic assets, and decentralized exchanges.

Update 2022-2-22:

This was an early demo of the ideas behind the CashTokens CHIP.

For an introduction to the latest iteration of CashTokens, see:

CashTokens (v2): Token Primitives for Bitcoin Cash →

CashChannels

Noncustodial, Privacy-Preserving, Flexibly-Denominated Recurring Payments for Bitcoin Cash

Read the blog post: CashChannels: Recurring Payments for Bitcoin Cash.

Review the authentication template in Bitauth IDE:

https://ide.bitauth.com/import-gist/ca13abf369b5ecace6437cb86afa331f

	import { instantiateSecp256k1, hexToBin, instantiateRipemd160, encodeCashAddress, CashAddressType, instantiateSha256, encodeCashAddressFormat, attemptCashAddressFormatErrorCorrection, decodeCashAddress, decodeCashAddressFormat, stringify } from 'bitcoin-ts';

	(async () => {
	const secp256k1 = await instantiateSecp256k1();
	const sha256 = await instantiateSha256();
	const ripemd160 = await instantiateRipemd160();

	// Create an address from a private key
	const privateKey = hexToBin('f85d4bd8a03ca106c9deb47b791803dac7f0333809e3f1dd04d182e0aba6e553');
	const publicKey = secp256k1.derivePublicKeyCompressed(privateKey);