jgarzik

This protocol describes a simple payment channel protocol, such as the one presented in https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

JSON-RPC methods shown here may be sent via HTTPS or stratum protocol. It is easily adaptable to protocol buffers or another favored marshalling method.

Open channel

Client requests a public key. Server responds with a public key (K2). K2, converted to a bitcoin address, forms the unique identifier for this payment channel. Each public key returned must be unique.

ExperimentGarden

find . -type f -name '*.php' -exec awk 'END {print NR}' '{}' + 2>/dev/null | awk '{ total+=$1 }END{print total}'

nacardin

use std::io::{self, Read};

fn line_to_vec<T: std::str::FromStr>(line: &str) -> Vec<T> {
    line.split_whitespace().map(|x| x.parse::<T>().ok().expect("parse error")).collect::<Vec<T>>()
}
        
fn main() {
    
    let mut buffer = String::new();
    io::stdin().read_to_string(&mut buffer).unwrap();

cpacia

package main

import (
	"fmt"
	"github.com/btcsuite/btcd/btcec"
	"encoding/hex"
	"crypto/sha256"
	"github.com/btcsuite/btcd/txscript"
	"github.com/cpacia/bchutil"
	"github.com/btcsuite/btcd/chaincfg"

fivepiece

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]

justusranvier

SPV clients lack the ability of full nodes to detect whether or not a chain provided to them by another source complies with the rules of the Bitcoin protocol.

SPV clients can connect to multiple full nodes in the hope that at least one of the nodes is honest and will provide them with the best valid chain, however situations may arise where the non-compliant chain contains more proof of work than the compliant chain. In this situation, there is no way for the honest full node to signal to an SPV client that it should disregard the chain with more proof of work.

Fraud proofs are a technique which provide honest full nodes the capability to conclusively demonstrate that chain is invalid regardless of the amount of proof of work backing the invalid chain.

If Bitcoin nodes implement the ability to create, propagate, and verify fraud proofs, the security of SPV clients will be improved.

Assumptions and Definitions

markblundeberg

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

Mengerian

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

bellbind

// - required node.js >= 10.0.0
// $ npm i elliptic
// $ node --harmony-bigint --experimental-modules check-secp256k1.mjs

import crypto from "crypto";
import elliptic from "elliptic";

import {EC, ECC, secp256k1, a2bi, bi2a, randint} from "./ecc.mjs";

// With real standard curve: secp256k1

maaku

*~