gavinandresen

# Raw transaction API example work-through
# Send coins to a 2-of-3 multisig, then spend them.
#
# For this example, I'm using these three keypairs (public/private)
# 0491bba2510912a5bd37da1fb5b1673010e43d2c6d812c514e91bfa9f2eb129e1c183329db55bd868e209aac2fbc02cb33d98fe74bf23f0c235d6126b1d8334f86 / 5JaTXbAUmfPYZFRwrYaALK48fN6sFJp4rHqq2QSXs8ucfpE4yQU
# 04865c40293a680cb9c020e7b1e106d8c1916d3cef99aa431a56d253e69256dac09ef122b1a986818a7cb624532f062c1d1f8722084861c5c3291ccffef4ec6874 / 5Jb7fCeh1Wtm4yBBg3q3XbT6B525i17kVhy3vMC9AqfR6FH2qGk
# 048d2455d2403e08708fc1f556002f1b6cd83f992d085097f9974ab08a28838f07896fbab08f39495e15fa6fad6edbfb1e754e35fa1c7844c41f322a1863d46213 / 5JFjmGo5Fww9p8gvx48qBYDJNAzR9pmH5S389axMtDyPT8ddqmw

# First: combine the three keys into a multisig address:
./bitcoind createmultisig 2 '["0491bba2510912a5bd37da1fb5b1673010e43d2c6d812c514e91bfa9f2eb129e1c183329db55bd868e209aac2fbc02cb33d98fe74bf23f0c235d6126b1d8334f86","04865c40293a680cb9c020e7b1e106d8c1916d3cef99aa431a56d253e69256dac09ef122b1a9

gavinandresen

O(1) Block Propagation

The problem

Bitcoin miners want their newly-found blocks to propagate across the network as quickly as possible, because every millisecond of delay increases the chances that another block, found at about the same time, wins the "block race."

gavinandresen

SEE BIP 70

See https://en.bitcoin.it/wiki/BIP_0070 for the latest version of this document; I'll keep this document so the process of discussion/revision isn't lost.

Bitcoin Payment Messages

This document proposes protocol buffer-based formats for a simple payment protocol between a customer's bitcoin client software and a merchant.

gavinandresen

Half-baked thoughts exploring a different way of implementing a fully-validating BCH node.

The idea is to shift the storage of full transaction data to wallets, and explore how little data a fully validating node could store. This isn't a problem today (the UTXO set easily fits in the RAM of an inexpensive server-class machine), but might eventually be at very large transaction volumes.

Initial block download is a problem today (it is annoying to have to wait several hours or days to sync up a new node), and this scheme could make it orders of magnitude faster by shifting the time when full transaction data is broadcast from initial block download to new transaction announcement.

gavinandresen

#New RPC commands

Implementation: bitcoin/bitcoin#1456

listunspent [minconf=1] [maxconf=999999]

Returns an array of unspent transaction outputs in the wallet that have between minconf and maxconf (inclusive) confirmations. Each output is a 5-element object with keys: txid, output, scriptPubKey, amount, confirmations. txid is the hexadecimal transaction id, output is

gavinandresen

Blockchain Rule Update Process

We recently rolled out two changes to the Bitcoin block acceptance rules (BIP16 and BIP30); this document records the lessons learned and makes recommendations for handling future blockchain rule changes.

Note: there are "soft" rule changes and "hard" rule changes. "Soft" changes tighten up the rules-- old software will accept all the blocks and transactions created by new software, but the opposite may not be true. "Soft" changes do not require the entire network of miners and merchants and users to upgrade or be left behind.

"Hard" changes modify the rules in a way that old, un-upgraded software consider illegal. At this point it is much, much more difficult (some might say impossible) to roll out "hard" changes, because they require every miner and merchant and user to upgrade.

Lessons Learned

gavinandresen

Thumbnail sketch: Two-factor (Yubikey or Google Authenticator) protected wallets

Hardware:

Computer. Shared-secret authenticator (Yubikey/Google Authenticator/etc). Server (possibly shared with millions of other users).

Motivating use case setup:

User creates a split (2-of-2 multisig) wallet on the computer and server. Keys must be securely backed up to protect against loss. GUI to be determined, but there will be some type of "Use Authenticator" checkbox specified at setup.

gavinandresen

Design sketch: "reject" p2p message

Motivation

Mike Hearn has been lobbying for an "error" message in the Bitcoin p2p protocol for years (at least since the "ban peers if they send us garbage" denial-of-service mitigation code was pull-requested). This came up again with my proposed "smartfee" changes, which would drop low-priority or low-fee transactions.

In short, giving peers feedback about why their blocks or transactions are dropped or

gavinandresen

Introduction

It would be spiffy to use the balanced merkle forest idea for ethereum tokens or to store unspent transaction outputs.

Tadge Dryja has been working on 'utreexo' (presentation) for storing unspent transaction outputs in log(n) space; this gist is inspired by, and is very similar to, that work.

So my previous gist describes really simple algorithms for adding and removing items from a balanced merkle forest. This gist extends those operations to create

gavinandresen

KEPT FOR REFERENCE:  Optional encryption of private keys was implemented starting with Bitcoin version 0.4.


Design notes on what an ideal wallet encryption feature for Bitcoin would look like:

Encrypt only the important information-- the private keys needed to spend coins (sign transactions).

Decrypt only when a key is needed to sign a transaction (on a send).

I don't think encrypting the public keys, transactions/comments is worth it, but that might be