Jason Dreyzehner bitjson

I want a cryptographic accumulator[^accumulator] that has the following properties:

It can be build incrementally using a small amount of persistent memory
Witness proofs are reasonably small.
Witness proofs are computationally easy to verify.
Must have at least 100-bit security.

The idea is to minimize on-chain storage; the accumulator will live on-chain, maintained by a smart contract. Transactions submitted to the smart contract can add to the accumulator. And then later transactions can be created that include proofs that a value is part of the accumulator.

BCH floating transactions: SIGHASH_NOINPUT emulation using CHECKDATASIG covenants

A new sighash flag has been proposed (originally for Lightning, now for Eltoo) which redacts information about the spending inputs, most notably their transaction IDs.

This facility is both powerful and dangerous: it means that signatures intended for one transaction can be used on other transactions. It also makes up a very strong increase in the malleability of transactions. SIGHASH_NOINPUT allows for much more flexible off-chain smart contracts than nonmalleable transactions. Note that Eltoo requires SIGHASH_NOINPUT, for instance. It's not clear whether such a dangerous feature will be adopted on BCH any time soon.

In this gist I'm going to explain that CHECKDATASIG covenants let us write smart contracts that emulate SIGHASH_NOINPUT. This capability alone should in principle allow to build Lightning, Eltoo with bilaterally funded smart contracts on BCH (though, with some significant

Two new features are coming to Bitcoin Cash soon, hopefully in the May 2019 upgrade. I'd like to take the time to explain why I'm so excited about them. In short, we will be able to do:

Payment channels hidden as ordinary payments.
Atomic swaps hidden as ordinary payments.
Lightning-style payment channel networks too, if we want.
Secure chains of unconfirmed transactions involving multiple parties (layer 2).

That all may sound incredible, and I'm going to explain in this document how it is so.

--- Mark B. Lundeberg, 2019 Jan 29 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

It's quite common to see smart contract constructions like this:

OP_IF
    <clause 1 conditions>
    <pubkey1> OP_CHECKSIG
OP_ELSE
    <clause 2 conditions>
    <pubkey2> OP_CHECKSIG
OP_ENDIF

Questions and concerns about ZCF
https://gist.github.com/awemany/619a5722d129dec25abf5de211d971bd

1

In "Creating a Zero Conf Forfeit transaction", it is mentioned that :

... a transaction that has the following structure:

Inputs: [P2PKH inputs 1] ... [P2PKH input I]

Outputs: [any-type-output 1] ... [any-type-output O] [Forfeit Output]

Quadratic sighash remains in Segwitv0/BCH/BSV digest algorithms.

Mark Lundeberg 2018 Oct 17

Abstract: Both BCH post-forkday signatures and the BIP143 Segwit signatures are ostensibly designed to remove the 'quadratic hashing problem', however as I will show, they are still vulnerable for long scripts. Back-of-the-envelope calculations show that it will become a serious concern if the existing script limits are relaxed.

Facts

Every OP_CHECKSIG requires hashing a potentially large amount of data, limited only by the size of scriptCode. The precise length is 159 + len(scriptCode) for scriptCodes longer than 255 bytes, up to 65535 bytes.
Since many OP_CHECKSIG calls are possible within a given script, this means transactions can be made where the required hashing time is quadratic in the length of script. (though, see the non-push opcod

Solving the 0-conf problem using forfeits

by /u/awemany

Overview

The problem of ensuring good security for unconfirmed transactions in Bitcoin is repeatedly discussed in the community. Right now these so-called 0-conf transactions are usually expected to be of low risk in the case of small amounts and face-to-face interaction of merchant and customer.

Using PGP signatures with bitcoin script OP_CHECKDATASIG

Dr. Mark B. Lundeberg, 2018 August 30 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

Since version 2.1, GnuPG is able to use the very same secp256k1 elliptic curve signature algorithm (ECDSA) as used in bitcoin. Quite soon Bitcoin Cash will add a new script opcode OP_CHECKDATASIG that is able to check signatures not just on the containing transaction, but also on arbitrary data. For fun, let's try to intersect the two signature systems and see what can be done!

Background

OP_CHECKDATASIG signatures

  Layer: Relay Policy 
  Title: Standard Priority and Doublespend Proof
  Author: @im_uname <[email protected]>, Tom Zander <[email protected]>
  Created: 2018-07-16
  Last updated: 2018-08-09
  License: IDGAF

	{
	"description": "Definition file for Bitcoin Script Templates",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"$id": "http://p2sh.cash/bst.schema.json",
	"title": "Bitcoin Script Template (BST) JSON Schema",
	"type": "object",
	"properties": {
	"v":{
	"description": "BST schema version",
	"type": "integer",