sipa

Beyond IP Transactions: towards a payment protocol
==================================================

IP transactions were originally introduced as a first "out-of-band" protocol
for negotiating a transaction output's public key. Being inconvenient and
insecure, they became obsolete, and recent versions of bitcoin don't support
them anymore.

The result is that static bitcoin addresses have become the most common way of
defining requested payments. This may be fine for anonymous donations, but is not

leesmith

https://www.pivotaltracker.com/help/api?version=v3#github_hooks
https://www.pivotaltracker.com/help/api?version=v3#scm_post_commit_message_syntax

SCM Post-Commit Message Syntax

To associate an SCM commit with a specific Tracker story, you must include a special syntax in the commit message to indicate one or more story IDs and (optionally) a state change for the story. Your commit message should have square brackets containing a hash mark followed by the story ID. If a story was not already started (it was in the "not started" state), a commit message will automatically start it. For example, if Scotty uses the following message when committing SCM revision 54321:

  [#12345677 #12345678] Diverting power from warp drive to torpedoes.
  

gavinandresen

I'm writing this to organize my thoughts on creating much more secure bitcoin wallets and payments.

Threat model

I assume the user starts with 2 uncompromised devices, and installs and configures trusted and uncompromised Bitcoin software for managing their wallet and confirming payments on both of them. I don't mean to imply that existing mechanisms for determining whether or not devices and software are uncompromised are sufficient, just that the problem of creating a secure starting state is outside the scope of what I want to consider in this document.

I assume that at some point after initial setup one of the devices is compromised by malware that has full access to the machine, including replacing any applications (bitcoin.exe, the user's web browser, etc), reading memory and/or altering the information displayed to the user.

The goal is to design protocols such that the user's wallet and payments are as secure as possible.

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

snikch

- (UIViewController *)topViewController{
  return [self topViewController:[UIApplication sharedApplication].keyWindow.rootViewController];
}

- (UIViewController *)topViewController:(UIViewController *)rootViewController
{
  if (rootViewController.presentedViewController == nil) {
    return rootViewController;
  }
  

gavinandresen

#!/usr/bin/env python
#
# Synchronize multisig addresses between two running bitcoinds
#
# Example usage:
#  multisigsync.py --connect1=http://abc:123@127.0.0.1:9000 --connect2=http://abc:123@127.0.0.1:9001 2MsrtHjVXGdT7RuTEiUWzec87Cik1rPpmyD
#
# Connects to both bitcoinds, figures out which one knows all the public keys for
# the mulitisig address, then tells the other about the address.
#

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

Motivation

Make it easy for end-users to use multi-signature transactions to more securely spend and store their bitcoins.

Identify what infrastructure needs to be built, what existing infrastructure can be re-used, and agree on an interoperable standard so users running different Bitcoin clients can cooperate to create multi-signature wallets and create multi-signature transactions.

User experience

I've created a mockup of a GUI for two use cases:

dergachev

OS X Screencast to animated GIF

This gist shows how to create a GIF screencast using only free OS X tools: QuickTime, ffmpeg, and gifsicle.

Instructions

To capture the video (filesize: 19MB), using the free "QuickTime Player" application:

rxin

#!/bin/bash

# From http://tech.serbinn.net/2010/shell-script-to-create-ramdisk-on-mac-os-x/
#

ARGS=2
E_BADARGS=99

if [ $# -ne $ARGS ] # correct number of arguments to the script;
then