bitkevin

package main

import (
	"flag"
	"fmt"
	"io"
	"log"
	"net"
	"os"
	"time"

bitkevin

yum add EPEL

cd /tmp
wget http://mirror-fpt-telecom.fpt.net/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm
# 或者
rpm -ivh http://mirror-fpt-telecom.fpt.net/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm

install nginx fcgi-perl

bitkevin

# 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

bitkevin

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

bitkevin

• http://tpfaucet.appspot.com/
  • back address: mq7se9wy2egettFxPbmn99cK8v5AFq55Lx
• http://testnet.mojocoin.com/
  • back address: n2zWWpBsFcCn5LWi7DTqJGxZKYgeEmX2Rz

You should send them back after development.

bitkevin

With Bitcoin 0.7 it's possible to keep your private keys
entirely offline without third party software.

In this example we have two hosts [offline] which is
totally offline and without a copy of the blockchain
and [online] which is a regular online node, both
running bitcoin 0.7.

This example uses the CLI, but it works equally well with

bitkevin

2-of-2 escrow example

Carbide81 wants to pay carbide80 50tnbtc but prevent carebide80 from cheating him.

First each party creates a new address, and then shares them. Then uses the 
resulting addresses to make a p2sh address (begins with '3' for bitcoin,
'2' for testnet) that requires both parties to sign to release:

The distributed redemption here (where no party has all the required keys

bitkevin

create raw transaction

• bitcoindtest = bitcoind -testnet

one input, one output

$ bitcoindtest createrawtransaction '[{"txid":"f5583dcb7ee8881e37110912f6163ddab9ffcc02e739b8683667b64c597bd635", "vout":0}]' '{"mq7se9wy2egettFxPbmn99cK8v5AFq55Lx":1}'

output hex:

bitkevin

Bitcoin/public point to address

• page souce: http://rosettacode.org/wiki/Bitcoin/public_point_to_address

Bitcoin uses a specific encoding format to encode the digest of an elliptic curve public point into a short ASCII string. The purpose of this task is to perform such a conversion.

The encoding steps are:

• take the X and Y coordinates of the given public point, and concatenate them in order to have a 64 byte-longed string ;

bitkevin

compressed and uncompressed pubkey

The private key is always exactly 256 bits, or 32 bytes. The exact same private key corresponds to two different public keys. One is uncompressed in the form of (x,y), and the other is compressed in the form of (x,p). The two forms have different representations, and thus different hashes, and thus different addresses. The compression flag just tells the system which of the two possible addresses to use.

You should pretty much always do compressed keys for new generation. There is no reason to ever use uncompressed keys, at least none that I'm aware of.

So, to create the WIF, suitable for importing later, you take the 32 byte binary private key, prepend the 0x80 bytes, and append the 0x01 flag for compression, then run through base58encode and the output is the WIF. For reference, to create an uncompressed WIF, just don't append the 0x01 before encoding.

To create the matching address, calculate the public key as usual, but when you go to encode it, check the pa