├── toc.html
├── ix.html
├── .gitignore
├── theme
├── epub
│ ├── epub.css
│ └── layout.html
├── mobi
│ ├── mobi.css
│ └── layout.html
└── pdf
│ └── pdf.css
├── cover.html
├── images
├── cover.png
├── msbt_0101.png
├── msbt_0102.png
├── msbt_0103.png
├── msbt_0104.png
├── msbt_0201.png
├── msbt_0202.png
├── msbt_0203.png
├── msbt_0204.png
├── msbt_0205.png
├── msbt_0206.png
├── msbt_0207.png
├── msbt_0208.png
├── msbt_0209.png
├── msbt_0210.png
├── msbt_0301.png
├── msbt_0302.png
├── msbt_0401.png
├── msbt_0402.png
├── msbt_0403.png
├── msbt_0404.png
├── msbt_0405.png
├── msbt_0406.png
├── msbt_0407.png
├── msbt_0408.png
├── msbt_0409.png
├── msbt_0410.png
├── msbt_0411.png
├── msbt_0412.png
├── msbt_0413.png
├── msbt_0414.png
├── msbt_0415.png
├── msbt_0416.png
├── msbt_0417.png
├── msbt_0418.png
├── msbt_0501.png
├── msbt_0502.png
├── msbt_0503.png
├── msbt_0504.png
├── msbt_0601.png
├── msbt_0602.png
├── msbt_0603.png
├── msbt_0604.png
├── msbt_0605.png
├── msbt_0606.png
├── msbt_0607.png
├── msbt_0608.png
├── msbt_0609.png
├── msbt_0610.png
├── msbt_0611.png
├── msbt_0612.png
├── msbt_0701.png
├── msbt_0702.png
├── msbt_0703.png
├── msbt_0704.png
├── msbt_0705.png
├── msbt_0801.png
├── msbt_0802.png
├── msbt_0803.png
├── msbt_0804.png
├── msbt_0805.png
├── msbt_0806.png
├── msbt_0807.png
├── msbt_0808.png
├── NetworkHandshake-corrected_msbt_0604.png
└── Transaction_Chain-corrected_msbt_0204.png
├── titlepage.html
├── code
├── hash_example.py
├── max_money.py
├── get-utxo.py
├── satoshi-words.cpp
├── extract-from-pk-script.go
├── pycoin_example.py
├── pay-to-addr-script.go
├── addr.cpp
├── ec-math.py
├── proof-of-work-example.py
├── key-to-address-ecc-example.py
├── merkle.cpp
├── vanity-miner.cpp
├── select-utxo.py
└── websocket-example.go
├── LICENSE
├── book.asciidoc
├── selected BIPs
├── bip-0071.mediawiki
├── bip-0071.asciidoc
├── bip-0035.mediawiki
├── bip-0034.mediawiki
├── bip-0035.asciidoc
├── bip-0034.asciidoc
├── bip-0072.mediawiki
├── bip-0072.asciidoc
├── bip-0013.mediawiki
├── bip-0030.mediawiki
├── bip-0013.asciidoc
├── bip-0011.mediawiki
├── bip-0011.asciidoc
├── bip-0030.asciidoc
├── bip-0039.mediawiki
├── bip-0039.asciidoc
├── bip-0014.mediawiki
├── bip-0021.mediawiki
├── bip-0044.mediawiki
├── bip-0044.asciidoc
├── bip-0014.asciidoc
├── bip-0021.asciidoc
├── bip-0016.mediawiki
└── bip-0016.asciidoc
├── tools
├── oneoffs
│ └── oneoff.css
└── intakereport.txt
├── atlas.json
├── praise.html
├── colo.html
├── planned_toc.asciidoc
├── author_bio.html
├── appdx01.asciidoc
├── copyright.html
├── glossary.asciidoc
├── README.md
├── appdx-bx.asciidoc
├── appdx-bips.asciidoc
└── appdx-scriptops.asciidoc
/toc.html:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/ix.html:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | dump.asciidoc
2 | code/python-env
3 | *.csv
4 |
--------------------------------------------------------------------------------
/theme/epub/epub.css:
--------------------------------------------------------------------------------
1 | /* Add your custom CSS styles for the EPUB here */
--------------------------------------------------------------------------------
/theme/mobi/mobi.css:
--------------------------------------------------------------------------------
1 | /* Add your custom CSS styles for the MOBI here */
--------------------------------------------------------------------------------
/cover.html:
--------------------------------------------------------------------------------
1 |
3 | Mastering Bitcoin
3 |
4 |
2 | BIP: 71 3 | Title: Payment Protocol MIME types 4 | Author: Gavin Andresen9 | 10 | ==Abstract== 11 | 12 | This BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment 13 | request messages. 14 | 15 | ==Motivation== 16 | 17 | Wallet or server software that sends payment protocol messages over 18 | email or http should follow Internet standards for properly 19 | encapsulating the messages. 20 | 21 | ==Specification== 22 | 23 | The Media Type (Content-Type in HTML/email headers) for bitcoin 24 | protocol messages shall be: 25 | 26 | {| 27 | | Message || Type/Subtype 28 | |- 29 | | PaymentRequest || application/bitcoin-paymentrequest 30 | |- 31 | | Payment || application/bitcoin-payment 32 | |- 33 | | PaymentACK || application/bitcoin-paymentack 34 | |} 35 | 36 | Payment protocol messages are encoded in binary. 37 | 38 | ==Example== 39 | 40 | A web server generating a PaymentRequest message to initiate the 41 | payment protocol would precede the binary message data with the 42 | following headers: 43 |5 | Status: Draft 6 | Type: Standards Track 7 | Created: 2013-07-29 8 |
44 | Content-Type: application/bitcoin-paymentrequest 45 | Content-Transfer-Encoding: binary 46 |47 | -------------------------------------------------------------------------------- /code/pycoin_example.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | 3 | from pycoin.key import Key 4 | 5 | from pycoin.key.validate import is_address_valid, is_wif_valid 6 | from pycoin.services import spendables_for_address 7 | from pycoin.tx.tx_utils import create_signed_tx 8 | 9 | def get_address(which): 10 | while 1: 11 | print("enter the %s address=> " % which, end='') 12 | address = input() 13 | is_valid = is_address_valid(address) 14 | if is_valid: 15 | return address 16 | print("invalid address, please try again") 17 | 18 | src_address = get_address("source") 19 | spendables = spendables_for_address(src_address) 20 | print(spendables) 21 | 22 | while 1: 23 | print("enter the WIF for %s=> " % src_address, end='') 24 | wif = input() 25 | is_valid = is_wif_valid(wif) 26 | if is_valid: 27 | break 28 | print("invalid wif, please try again") 29 | 30 | key = Key.from_text(wif) 31 | if src_address not in (key.address(use_uncompressed=False), key.address(use_uncompressed=True)): 32 | print("** WIF doesn't correspond to %s" % src_address) 33 | print("The secret exponent is %d" % key.secret_exponent()) 34 | 35 | dst_address = get_address("destination") 36 | 37 | tx = create_signed_tx(spendables, payables=[dst_address], wifs=[wif]) 38 | 39 | print("here is the signed output transaction") 40 | print(tx.as_hex()) 41 | -------------------------------------------------------------------------------- /tools/oneoffs/oneoff.css: -------------------------------------------------------------------------------- 1 | @charset "UTF-8"; 2 | 3 | /*--------Put Your Custom CSS Rules Below--------*/ 4 | 5 | /*----Uncomment to turn on automatic code wrapping----*/ 6 | 7 | pre.programlisting, pre.screen, pre.literallayout { 8 | white-space: pre-wrap; 9 | word-wrap: break-word; 10 | text-align: left; 11 | } 12 | 13 | /*----Uncomment to change the TOC start page (set 14 | the number to one page _after_ the one you want; 15 | so 6 to start on v, 8 to start on vii, etc.)----*/ 16 | 17 | @page tableofcontents:first { 18 | counter-reset: page 6; 19 | } 20 | 21 | /*----Uncomment to fix a bad break in the title 22 | (increase padding value to push down, decrease 23 | value to pull up) 24 | 25 | div.book div.booktitlepage h1.title { 26 | padding-left: 1.5in; 27 | } 28 | ----*/ 29 | 30 | /*----Uncomment to fix a bad break in the subtitle 31 | (increase padding value to push down, decrease 32 | value to pull up) 33 | 34 | div.book div.booktitlepage h2.subtitle { 35 | padding-left: 1in; 36 | } 37 | ----*/ 38 | 39 | /*----Uncomment to fix a bad break in the author names 40 | (increase padding value to push down, decrease 41 | value to pull up) 42 | 43 | p.titlepageauthor { 44 | padding-left: 3in; 45 | } 46 | ----*/ 47 | 48 | /*----Uncomment to suppress colophon, show only 49 | "About the Authors" 50 | 51 | div.colophon { 52 | display: none; 53 | } 54 | ----*/ 55 | -------------------------------------------------------------------------------- /code/pay-to-addr-script.go: -------------------------------------------------------------------------------- 1 | package main 2 | 3 | import ( 4 | "fmt" 5 | "os" 6 | 7 | "github.com/conformal/btcnet" 8 | "github.com/conformal/btcscript" 9 | "github.com/conformal/btcutil" 10 | ) 11 | 12 | // This example demonstrates creating a script which pays to a bitcoin address. 13 | // It also prints the created script hex and uses the DisasmString function to 14 | // display the disassembled script. 15 | 16 | func main() { 17 | addressStr := "12gpXQVcCL2qhTNQgyLVdCFG2Qs2px98nV" 18 | 19 | PayToAddrScript(addressStr) 20 | // Output: 21 | // Script Hex: 76a914128004ff2fcaf13b2b91eb654b1dc2b674f7ec6188ac 22 | // Script Disassembly: OP_DUP OP_HASH160 128004ff2fcaf13b2b91eb654b1dc2b674f7ec61 OP_EQUALVERIFY OP_CHECKSIG 23 | } 24 | 25 | func PayToAddrScript(addressStr string) { 26 | // Parse the address to send the coins to into a btcutil.Address 27 | // which is useful to ensure the accuracy of the address and determine 28 | // the address type. It is also required for the upcoming call to 29 | // PayToAddrScript. 30 | address, err := btcutil.DecodeAddress(addressStr, &btcnet.MainNetParams) 31 | handle(err) 32 | 33 | // Create a public key script that pays to the address. 34 | script, err := btcscript.PayToAddrScript(address) 35 | handle(err) 36 | fmt.Printf("Script Hex: %x\n", script) 37 | 38 | disasm, err := btcscript.DisasmString(script) 39 | handle(err) 40 | fmt.Println("Script Disassembly:", disasm) 41 | } 42 | 43 | func handle(err error) { 44 | if err != nil { 45 | fmt.Println(err) 46 | os.Exit(1) 47 | } 48 | } 49 | -------------------------------------------------------------------------------- /theme/pdf/pdf.css: -------------------------------------------------------------------------------- 1 | @charset "UTF-8"; 2 | 3 | /*--------Put Your Custom CSS Rules Below--------*/ 4 | /*--- This oneoff overrides the code in https://github.com/oreillymedia/
2 | BIP: 35 3 | Title: mempool message 4 | Author: Jeff Garzik9 | 10 | ==Abstract== 11 | 12 | Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool. 13 | 14 | ==Motivation== 15 | 16 | Several use cases make it desireable to expose a network node's transaction memory pool: 17 | # SPV clients, wishing to obtain zero-confirmation transactions sent or received. 18 | # Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart. 19 | # Remote network diagnostics. 20 | 21 | ==Specification== 22 | 23 | # The mempool message is defined as an empty message where pchCommand == "mempool" 24 | # Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any. 25 | # The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool. 26 | # Feature discovery is enabled by checking two "version" message attributes: 27 | ## Protocol version >= 60002 28 | ## NODE_NETWORK bit set in nServices 29 | 30 | Note that existing implementations drop "inv" messages with a vector size > 50000. 31 | 32 | ==Backward compatibility== 33 | 34 | Older clients remain 100% compatible and interoperable after this change. 35 | 36 | ==Implementation== 37 | 38 | https://github.com/bitcoin/bitcoin/pull/1641 39 | -------------------------------------------------------------------------------- /praise.html: -------------------------------------------------------------------------------- 1 |5 | Status: Accepted 6 | Type: Standards Track 7 | Created: 2012-08-16 8 |
4 |7 |When I talk about bitcoin to general audiences, I am sometimes asked 'but how does it really work?' Now I have a great answer for that question, because anybody who reads Mastering Bitcoin will have a deep understanding of how it works and will be well-equipped to write the next generation of amazing cryptocurrency applications.
5 |Gavin Andresen, Chief Scientist Bitcoin Foundation
6 |
8 |11 |Bitcoin and blockchain technologies are becoming fundamental building blocks for the next generation internet. Silicon Valley's best and brightest are working on it. Andreas' book will help you join the software revolution in the world of finance.
9 |Naval Ravikant, Co-founder AngelList
10 |
12 |15 |Mastering Bitcoin is the best technical reference available on bitcoin today. And bitcoin is likely to be seen in retrospect as the most important technology of this decade. As such, this book is an absolute must-have for any developer, especially those interested in building applications with the bitcoin protocol. Highly recommended.
13 |Balaji S. Srinivasan (@balajis), General Partner, Andreessen Horowitz
14 |
16 |19 |The invention of the Bitcoin Blockchain represents an entirely new platform to build upon, one that will enable an ecosystem as wide and diverse as the Internet itself. As one of the preeminent thought leaders, Andreas Antonopoulos is the perfect choice to write this book.
17 |Roger Ver, Bitcoin Entrepreneur and Investor
18 |
2 | BIP: 34 3 | Title: Block v2, Height in Coinbase 4 | Author: Gavin Andresen9 | 10 | ==Abstract== 11 | 12 | Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2. 13 | 14 | ==Motivation== 15 | 16 | # Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors. 17 | # Enforce block and transaction uniqueness, and assist unconnected block validation. 18 | 19 | ==Specification== 20 | 21 | # Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them). 22 | # Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number. Height is the height of the mined block in the block chain, where the genesis block is height zero (0). 23 | # 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100) 24 | # 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100) 25 | 26 | ==Backward compatibility== 27 | 28 | All older clients are compatible with this change. Users and merchants should not be impacted. Miners are strongly recommended to upgrade to version 2 blocks. Once 95% of the miners have upgraded to version 2, the remainder will be orphaned if they fail to upgrade. 29 | 30 | ==Implementation== 31 | 32 | https://github.com/bitcoin/bitcoin/pull/1526 33 | -------------------------------------------------------------------------------- /code/ec-math.py: -------------------------------------------------------------------------------- 1 | import ecdsa 2 | import os 3 | from ecdsa.util import string_to_number, number_to_string 4 | 5 | # secp256k1, http://www.oid-info.com/get/1.3.132.0.10 6 | _p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2FL 7 | _r = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141L 8 | _b = 0x0000000000000000000000000000000000000000000000000000000000000007L 9 | _a = 0x0000000000000000000000000000000000000000000000000000000000000000L 10 | _Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798L 11 | _Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8L 12 | curve_secp256k1 = ecdsa.ellipticcurve.CurveFp(_p, _a, _b) 13 | generator_secp256k1 = ecdsa.ellipticcurve.Point(curve_secp256k1, _Gx, _Gy, _r) 14 | oid_secp256k1 = (1, 3, 132, 0, 10) 15 | SECP256k1 = ecdsa.curves.Curve("SECP256k1", curve_secp256k1, generator_secp256k1, oid_secp256k1) 16 | ec_order = _r 17 | 18 | curve = curve_secp256k1 19 | generator = generator_secp256k1 20 | 21 | def random_secret(): 22 | convert_to_int = lambda array: int("".join(array).encode("hex"), 16) 23 | 24 | # Collect 256 bits of random data from the OS's cryptographically secure random generator 25 | byte_array = os.urandom(32) 26 | 27 | return convert_to_int(byte_array) 28 | 29 | def get_point_pubkey(point): 30 | if point.y() & 1: 31 | key = '03' + '%064x' % point.x() 32 | else: 33 | key = '02' + '%064x' % point.x() 34 | return key.decode('hex') 35 | 36 | def get_point_pubkey_uncompressed(point): 37 | key = '04' + \ 38 | '%064x' % point.x() + \ 39 | '%064x' % point.y() 40 | return key.decode('hex') 41 | 42 | 43 | # Generate a new private key. 44 | secret = random_secret() 45 | print "Secret: ", secret 46 | 47 | # Get the public key point. 48 | point = secret * generator 49 | print "EC point:", point 50 | 51 | print "BTC public key:", get_point_pubkey(point).encode("hex") 52 | 53 | # Given the point (x, y) we can create the object using: 54 | point1 = ecdsa.ellipticcurve.Point(curve, point.x(), point.y(), ec_order) 55 | assert point1 == point 56 | 57 | -------------------------------------------------------------------------------- /code/proof-of-work-example.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | # example of proof-of-work algorithm 3 | 4 | import hashlib 5 | import time 6 | 7 | max_nonce = 2 ** 32 # 4 billion 8 | 9 | def proof_of_work(header, difficulty_bits): 10 | 11 | # calculate the difficulty target 12 | target = 2 ** (256-difficulty_bits) 13 | 14 | for nonce in xrange(max_nonce): 15 | hash_result = hashlib.sha256(str(header)+str(nonce)).hexdigest() 16 | 17 | # check if this is a valid result, below the target 18 | if long(hash_result, 16) < target: 19 | print "Success with nonce %d" % nonce 20 | print "Hash is %s" % hash_result 21 | return (hash_result,nonce) 22 | 23 | print "Failed after %d (max_nonce) tries" % nonce 24 | return nonce 25 | 26 | 27 | if __name__ == '__main__': 28 | 29 | nonce = 0 30 | hash_result = '' 31 | 32 | # difficulty from 0 to 31 bits 33 | for difficulty_bits in xrange(32): 34 | 35 | difficulty = 2 ** difficulty_bits 36 | print "Difficulty: %ld (%d bits)" % (difficulty, difficulty_bits) 37 | 38 | print "Starting search..." 39 | 40 | # checkpoint the current time 41 | start_time = time.time() 42 | 43 | # make a new block which includes the hash from the previous block 44 | # we fake a block of transactions - just a string 45 | new_block = 'test block with transactions' + hash_result 46 | 47 | # find a valid nonce for the new block 48 | (hash_result, nonce) = proof_of_work(new_block, difficulty_bits) 49 | 50 | # checkpoint how long it took to find a result 51 | end_time = time.time() 52 | 53 | elapsed_time = end_time - start_time 54 | print "Elapsed Time: %.4f seconds" % elapsed_time 55 | 56 | if elapsed_time > 0: 57 | 58 | # estimate the hashes per second 59 | hash_power = float(long(nonce)/elapsed_time) 60 | print "Hashing Power: %ld hashes per second" % hash_power 61 | 62 | 63 | -------------------------------------------------------------------------------- /selected BIPs/bip-0035.asciidoc: -------------------------------------------------------------------------------- 1 | ------------------------------------------- 2 | BIP: 35 3 | Title: mempool message 4 | Author: Jeff Garzik5 | Status: Accepted 6 | Type: Standards Track 7 | Created: 2012-07-06 8 |
The animal on the cover of Mastering Bitcoin is a leafcutter ant (Atta colombica). The leafcutter ant, a nongeneric name, are tropical, fungus-growing ants endemic to South and Central America, Mexico, and southern United States. Aside from humans, leafcutter ants form the largest and most complex animal societies on the planet. They are named for the way they chew leaves, which serve as nutrition for their fungal garden.
5 | 6 |Winged ants, both male and female, take part in a mass exit of their nest known as the revoada, or a nuptial flight. Females mate with multiple males to collect the 300 million sperm necessary to set up a colony. Females also store bits of the parental fungus garden mycelium in the infrabuccal pocket located in their oral cavity; they will use this to start their own fungal gardens. Once grounded, the female loses its wings and sets up an underground lair for her colony. The success rate for new queens is low: 2.5% establish a long-lived colony.
7 | 8 |Once a colony has matured, ants are divided into castes based on size, with each caste performing various functions. There are usually four castes: minims, the smallest workers that tend to the young and fungus gardens; minors, slightly larger than minima, are the first line of defense for the colony and patrol the surrounding terrain and attack enemies; mediae, the general foragers that cut leaves and bring back leaf fragments to the nest; and majors, the largest worker ants that act as soldiers, defending the nest from intruders. Recent research has shown that majors also clear main foraging trails and carry bulky items back to the nest.
9 | 10 |Many of the animals on O'Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to animals.oreilly.com.
11 | 12 |The cover image is from Insects Abroad. The cover fonts are URW Typewriter and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.
13 |2 | BIP: 72 3 | Title: bitcoin: uri extensions for Payment Protocol 4 | Author: Gavin Andresen9 | 10 | ==Abstract== 11 | 12 | This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to 13 | support the payment protocol (BIP 70). 14 | 15 | ==Motivation== 16 | 17 | Allow users to click on a link in a web page or email to initiate the 18 | payment protocol, while being backwards-compatible with existing 19 | bitcoin wallets. 20 | 21 | ==Specification== 22 | 23 | The bitcoin: URI scheme is extended with an additional, optional 24 | "r" parameter, whose value is a URL from which a PaymentRequest 25 | message should be fetched (characters not allowed within the scope 26 | of a query parameter must be percent-encoded as described in RFC 3986 27 | and bip-0021). 28 | 29 | If the "r" parameter is provided and backwards compatibility 30 | is not required, then the bitcoin address portion of the URI may be 31 | omitted (the URI will be of the form: bitcoin:?r=... ). 32 | 33 | When Bitcoin wallet software that supports this BIP receives a 34 | bitcoin: URI with a request parameter, it should ignore the bitcoin 35 | address/amount/label/message in the URI and instead fetch a 36 | PaymentRequest message and then follow the payment protocol, as 37 | described in BIP 70. 38 | 39 | Bitcoin wallets must support fetching PaymentRequests via http and 40 | https protocols; they may support other protocols. Wallets must 41 | include an "Accept" HTTP header in HTTP(s) requests (as defined 42 | in RFC 2616): 43 | 44 |5 | Status: Draft 6 | Type: Standards Track 7 | Created: 2013-07-29 8 |
Accept: application/bitcoin-paymentrequest45 | 46 | If a PaymentRequest cannot be obtained (perhaps the server is 47 | unavailable), then the customer should be informed that the merchant's 48 | payment processing system is unavailable. In the case of an HTTP 49 | request, status codes which are neither success nor error (such as 50 | redirect) should be handled as outlined in RFC 2616. 51 | 52 | ==Compatibility== 53 | 54 | Wallet software that does not support this BIP will simply ignore the 55 | r parameter and will initiate a payment to bitcoin address. 56 | 57 | ==Examples== 58 | A backwards-compatible request: 59 |
60 | bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe 61 |62 | Non-backwards-compatible equivalent: 63 |
64 | bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe 65 |66 | 67 | ==References== 68 | 69 | [[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 -------------------------------------------------------------------------------- /appdx01.asciidoc: -------------------------------------------------------------------------------- 1 | [[appdx01]] 2 | [appendix] 3 | == Bitcoin financial services 4 | 5 | 6 | 7 | This appendix describes the main financial services offered in the bitcoin economy, comparing them to traditional financial services that are already familiar to consumers. It's not a list of sites or companies, as that would go stale immediately. Instead it is a list of service primitives with examples of existing implementations. For example, an escrow 8 | service would be described as an archetype, by analogy to a real-estate escrow, showing the unique characteristics, use case and need for escrow in the bitcoin world. The escrow service archetype would be followed by two or three examples of well implemented actual escrow services, each demonstrating a capability unique to bitcoin. 9 | 10 | === Currency Exchanges 11 | 12 | === Bitcoin market data services 13 | 14 | === Bitcoin ticker, order book, chart and analysis services 15 | 16 | === Peer-to-peer exchange 17 | 18 | === OTC and Web-of-Trust (WoT) 19 | 20 | === Escrow services 21 | 22 | === Monitoring services 23 | 24 | === Alert and notification services 25 | 26 | === Lending 27 | 28 | === P2P Lending 29 | 30 | === Securities 31 | 32 | === Mutual Funds 33 | 34 | === Angel investing 35 | 36 | == Appendix: Bitcoin markets and applications 37 | 38 | As above, this appendix describes services offered in the bitcoin economy. Each service is described a a service archetype which is compared to a real-world example familiar to anyone. The description of such a service is followed by real-world examples that express 39 | these bitcoin features. 40 | 41 | === Currency transfer 42 | 43 | === US domestic 44 | 45 | === Other in-country 46 | 47 | === International 48 | 49 | === Retail commerce 50 | 51 | === Physical (tangible) goods 52 | 53 | === Intangible products 54 | 55 | === Services 56 | 57 | === Technology services 58 | 59 | === Re-selling and Cross-selling 60 | 61 | === Wholesale commerce 62 | 63 | 64 | == Appendix: Bitcoin Protocol Structure and Conventions 65 | 66 | Reference index of main protocol primitives, packet structure, opcodes, state enumerations, protocol mechanics, time diagrams and protocol validation mechanisms. 67 | 68 | 69 | == Appendix: Bitcoin Transaction Script Operands and Tokens 70 | 71 | More reference material as above 72 | 73 | 74 | == Appendix: Bitcoin Cryptography Algorithms, Conventions and Conversions. 75 | 76 | More reference material as above 77 | 78 | 79 | == Appendix: Bitcoin Meta-protocols: Mining Pool Protocols, Lightweight Client Protocols 80 | 81 | More reference material as above 82 | -------------------------------------------------------------------------------- /code/vanity-miner.cpp: -------------------------------------------------------------------------------- 1 | #include
Copyright © 2015 Andreas M. Antonopoulos LLC. All rights reserved.
5 |Printed in the United States of America.
6 |Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
7 |O'Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most 8 | titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.
9 |See http://oreilly.com/catalog/errata.csp?isbn=9781449374044 for release details.
34 |The O'Reilly logo is a registered trademark of O'Reilly Media, Inc. Mastering Bitcoin, the cover image, and related trade dress are trademarks of O'Reilly Media, Inc.
36 |While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
37 |978-1-4494-9374-4
40 |[LSI]
41 |2 | BIP: 13 3 | Title: Address Format for pay-to-script-hash 4 | Author: Gavin Andresen9 | 10 | ==Abstract== 11 | 12 | This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. 13 | 14 | In essence, an address encoded under this proposal represents the encoded hash of a [[script]], rather than the encoded hash of an ECDSA public key. 15 | 16 | ==Motivation== 17 | 18 | Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services. 19 | 20 | ==Specification== 21 | 22 | The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [[Base58Check encoding]]): 23 | 24 | base58-encode: [one-byte version][20-byte hash][4-byte checksum] 25 | 26 | Version byte is 5 for a main-network address, 196 for a testnet address. 27 | The 20-byte hash is the hash of the script that will be used to redeem the coins. 28 | And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash. 29 | 30 | ==Rationale== 31 | 32 | One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism. 33 | 34 | Another criticism is that bitcoin addresses are inherently insecure because there is no identity information tied to them; if you only have a bitcoin address, how can you be certain that you're paying who or what you think you're paying? 35 | 36 | Furthermore, truncating SHA256 is not an optimal checksum; there are much better error-detecting algorithms. If we are introducing a new form of Bitcoin address, then perhaps a better algorithm should be used. 37 | 38 | This is one piece of the simplest path to a more secure bitcoin infrastructure. It is not intended to solve all of bitcoin's usability or security issues, but to be an incremental improvement over what exists today. A future BIP or BIPs should propose more user-friendly mechanisms for making payments, or for verifying that you're sending a payment to the Free Software Foundation and not Joe Random Hacker. 39 | 40 | Assuming that typing in bitcoin addresses manually will become increasingly rare in the future, and given that the existing checksum method for bitcoin addresses seems to work "well enough" in practice and has already been implemented multiple times, the Author believes no change to the checksum algorithm is necessary. 41 | 42 | The leading version bytes are chosen so that, after base58 encoding, the leading character is consistent: for the main network, byte 5 becomes the character '3'. For the testnet, byte 196 is encoded into '2'. 43 | 44 | ==Backwards Compatibility== 45 | 46 | This proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction. 47 | 48 | ==Reference Implementation== 49 | 50 | See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src 51 | 52 | ==See Also== 53 | 54 | * [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]] 55 | * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]] 56 | * [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]] 57 | -------------------------------------------------------------------------------- /glossary.asciidoc: -------------------------------------------------------------------------------- 1 | [preface] 2 | == Quick Glossary 3 | 4 | This quick glossary contains many of the terms used in relation to bitcoin. These terms are used throughout the book, so bookmark this for a quick reference. 5 | 6 | address:: 7 | A bitcoin address looks like +1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV+. It consists of a string of letters and numbers starting with a "1" (number one). Just like you ask others to send an email to your email address, you would ask others to send you bitcoin to your bitcoin address.((("bitcoin address")))((("address", see="bitcoin address")))((("public key", see="bitcoin address"))) 8 | 9 | bip:: 10 | Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP0021 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.((("bip"))) 11 | 12 | bitcoin:: 13 | The name of the currency unit (the coin), the network, and the software.((("bitcoin"))) 14 | 15 | block:: 16 | A grouping of transactions, marked with a timestamp, and a fingerprint of the previous block. The block header is hashed to produce a proof of work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus.((("block"))) 17 | 18 | blockchain:: 19 | A list of validated blocks, each linking to its predecessor all the way to the genesis block.((("blockchain"))) 20 | 21 | confirmations:: 22 | Once a transaction is included in a block, it has one confirmation. As soon as _another_ block is mined on the same blockchain, the transaction has two confirmations, and so on. Six or more confirmations is considered sufficient proof that a transaction cannot be reversed.((("confirmations"))) 23 | 24 | difficulty:: 25 | A network-wide setting that controls how much computation is required to produce a proof of work.((("difficulty"))) 26 | 27 | difficulty target:: 28 | A difficulty at which all the computation in the network will find blocks approximately every 10 minutes.((("target difficulty"))) 29 | 30 | difficulty retargeting:: 31 | A network-wide recalculation of the difficulty that occurs once every 2,106 blocks and considers the hashing power of the previous 2,106 blocks.((("difficulty retargeting"))) 32 | 33 | fees:: 34 | The sender of a transaction often includes a fee to the network for processing the requested transaction. Most transactions require a minimum fee of 0.5 mBTC.((("fees"))) 35 | 36 | hash:: 37 | A digital fingerprint of some binary input.((("hash"))) 38 | 39 | genesis block:: 40 | The first block in the blockchain, used to initialize the cryptocurrency.((("genesis block"))) 41 | 42 | miner:: 43 | A network node that finds valid proof of work for new blocks, by repeated hashing.((("miner"))) 44 | 45 | network:: 46 | A peer-to-peer network that propagates transactions and blocks to every bitcoin node on the network.((("network"))) 47 | 48 | Proof-Of-Work:: 49 | A piece of data that requires significant computation to find. In bitcoin, miners must find a numeric solution to the SHA256 algorithm that meets a network-wide target, the difficulty target. ((("proof-of-work"))) 50 | 51 | reward:: 52 | An amount included in each new block as a reward by the network to the miner who found the Proof-Of-Work solution. It is currently 25BTC per block.((("reward"))) 53 | 54 | secret key (aka private key):: 55 | The secret number that unlocks bitcoins sent to the corresponding address. A secret key looks like +5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh+.((("secret key")))((("private key", see="secret key"))) 56 | 57 | transaction:: 58 | In simple terms, a transfer of bitcoins from one address to another. More precisely, a transaction is a signed data structure expressing a transfer of value. Transactions are transmitted over the bitcoin network, collected by miners, and included into blocks, made permanent on the blockchain.((("transaction"))) 59 | 60 | wallet:: 61 | Software that holds all your bitcoin addresses and secret keys. Use it to send, receive, and store your bitcoin.((("wallet"))) -------------------------------------------------------------------------------- /selected BIPs/bip-0030.mediawiki: -------------------------------------------------------------------------------- 1 |5 | Status: Final 6 | Type: Standards Track 7 | Created: 2011-10-18 8 |
2 | BIP: 30 3 | Title: Duplicate transactions 4 | Author: Pieter Wuille9 | 10 | ==Abstract== 11 | This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them. 12 | 13 | ==Motivation== 14 | So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network. 15 | 16 | ==Specification== 17 | To counter this problem, the following network rule is introduced: 18 | *Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain. 19 | 20 | This rule initially applied to all blocks whose timestamp is after March 15, 2012, 00:00 UTC (testnet: February 20, 2012 00:00 UTC). It was later extended by Commit [https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514 Apply BIP30 checks to all blocks except the two historic violations.] to apply to all blocks except the two historic blocks at heights 91842 and 91880 on the main chain that had to be grandfathered in. 21 | 22 | ==Rationale== 23 | Whatever solution is used, the following law must be obeyed to guarantee sane behaviour: the set of usable 24 | transactions outputs must not be modified by adding blocks to the chain and removing them again. This happens during 25 | a reorganisation, and the current Bitcoin reference implementation does not obey this law in case the temporarily 26 | added blocks contain a duplicate transaction. 27 | 28 | There are several potential solutions to this problem: 29 | #Guarantee that all coinbases are unique, making duplicate transactions very hard to create. 30 | #Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is added. 31 | #Only allow duplicate transactions in case the previous instance of the transaction had no spendable outputs left. Removing a block from the chain can then safely reset the removed transaction's outputs to nothing. 32 | 33 | The first option is probably the most complete one, as it also guarantees transaction identifiers are unique. However, implementing it requires several changes that need to be accepted throughout the network. Furthermore, it does not prevent duplicate transactions based on earlier duplicate coinbases. The second option is impossible to implement in a forward-compatible way, as it potentially renders currently-invalid blocks valid. In this document we choose for the third option, because it only requires a trivial change. 34 | 35 | Fully-spent transactions are allowed to be duplicated in order not to hinder pruning at some point in the future. Not allowing any transaction to be duplicated would require evidence to be kept for each transaction ever made. 36 | 37 | ==Backward compatibility== 38 | The addition of this rule only makes some previously-valid blocks invalid. This implies that if the rule is implemented by a supermajority of miners, it is not possible to fork the block chain in a permanent way between nodes with and without the new rule. 39 | 40 | ==Implementation== 41 | A patch for the reference client can be found on https://github.com/sipa/bitcoin/tree/nooverwritetx 42 | 43 | This BIP was implemented in Commit [https://github.com/bitcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531 Do not allow overwriting unspent transactions (BIP 30)] 44 | There have been additional commits to refine the implementation of this BIP. 45 | 46 | ==Acknowledgements== 47 | Thanks to Russell O'Connor for finding and demonstrating this problem, and helping test the patch. 48 | -------------------------------------------------------------------------------- /selected BIPs/bip-0013.asciidoc: -------------------------------------------------------------------------------- 1 | -------------------------------------------------- 2 | BIP: 13 3 | Title: Address Format for pay-to-script-hash 4 | Author: Gavin Andresen5 | Status: Final 6 | Type: Standards Track 7 | Created: 2012-02-22 8 |
2 | BIP: 11 3 | Title: M-of-N Standard Transactions 4 | Author: Gavin Andresen10 | 11 | ==Abstract== 12 | 13 | This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. 14 | 15 | ==Motivation== 16 | 17 | Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. 18 | 19 | A couple of motivating use cases: 20 | 21 | * A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business. 22 | 23 | * Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).5 | Status: Accepted 6 | Type: Standards Track 7 | Created: 2011-10-18 8 | Post-History: 2011-10-02 9 |


2 | BIP: BIP-0039 3 | Title: Mnemonic code for generating deterministic keys 4 | Authors: Marek Palatinus13 | 14 | ==Abstract== 15 | 16 | This BIP describes the implementation of a mnemonic code or mnemonic sentence -- 17 | a group of easy to remember words -- for the generation of deterministic wallets. 18 | 19 | It consists of two parts: generating the mnenomic, and converting it into a 20 | binary seed. This seed can be later used to generate deterministic wallets using 21 | BIP-0032 or similar methods. 22 | 23 | ==Motivation== 24 | 25 | A mnenomic code or sentence is superior for human interaction compared to the 26 | handling of raw binary or hexidecimal representations of a wallet seed. The 27 | sentence could be written on paper or spoken over the telephone. 28 | 29 | This guide meant to be as a way to transport computer-generated randomnes over 30 | human readable transcription. It's not a way how to process user-created 31 | sentences (also known as brainwallet) to wallet seed. 32 | 33 | ==Generating the mnemonic== 34 | 35 | The mnemonic must encode entropy in any multiple of 32 bits. With larger entropy 36 | security is improved but the sentence length increases. We can refer to the 37 | initial entropy length as ENT. The recommended size of ENT is 128-256 bits. 38 | 39 | First, an initial entropy of ENT bits is generated. A checksum is generated by 40 | taking the first5 | Pavol Rusnak 6 | ThomasV 7 | Aaron Voisine 8 | Sean Bowe 9 | Status: Draft 10 | Type: Standards Track 11 | Created: 2013-09-10 12 |
ENT / 32bits of its SHA256 hash. This checksum is 41 | appended to the end of the initial entropy. Next, these concatenated bits are 42 | are split into groups of 11 bits, each encoding a number from 0-2047, serving 43 | as an index to a wordlist. Later, we will convert these numbers into words and 44 | use the joined words as a mnemonic sentence. 45 | 46 | The following table describes the relation between the initial entropy 47 | length (ENT), the checksum length (CS) and length of the generated mnemonic 48 | sentence (MS) in words. 49 | 50 |
51 | CS = ENT / 32 52 | MS = (ENT + CS) / 11 53 | 54 | | ENT | CS | ENT+CS | MS | 55 | +-------+----+--------+------+ 56 | | 128 | 4 | 132 | 12 | 57 | | 160 | 5 | 165 | 15 | 58 | | 192 | 6 | 198 | 18 | 59 | | 224 | 7 | 231 | 21 | 60 | | 256 | 8 | 264 | 24 | 61 |62 | 63 | ==Wordlist== 64 | 65 | An ideal wordlist has the following characteristics: 66 | 67 | a) smart selection of words 68 | - wordlist is created in such way that it's enough to type the first four 69 | letters to unambiguously identify the word 70 | 71 | b) similar words avoided 72 | - word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly" 73 | not only make remembering the sentence difficult, but are also more error 74 | prone and more difficult to guess 75 | 76 | c) sorted wordlists 77 | - wordlist is sorted which allows for more efficient lookup of the code words 78 | (i.e. implementation can use binary search instead of linear search) 79 | - this also allows trie (prefix tree) to be used, e.g. for better compression 80 | 81 | The wordlist can contain native characters, but they have to be encoded in UTF-8 82 | using Normalization Form Compatibility Decomposition (NFKD). 83 | 84 | ==From mnemonic to seed== 85 | 86 | A user may decide to protect their mnemonic by passphrase. If a passphrase is not 87 | present, an empty string "" is used instead. 88 | 89 | To create a binary seed from the mnemonic, we use PBKDF2 function with a mnemonic 90 | sentence (in UTF-8 NFKD) used as a password and string "mnemonic" + passphrase (again 91 | in UTF-8 NFKD) used as a salt. Iteration count is set to 2048 and HMAC-SHA512 is used as 92 | a pseudo-random function. Desired length of the derived key is 512 bits (= 64 bytes). 93 | 94 | This seed can be later used to generate deterministic wallets using BIP-0032 or 95 | similar methods. 96 | 97 | The conversion of the mnemonic sentence to binary seed is completely independent 98 | from generating the sentence. This results in rather simple code; there are no 99 | constraints on sentence structure and clients are free to implement their own 100 | wordlists or even whole sentence generators, allowing for flexibility in wordlists 101 | for typo detection or other purposes. 102 | 103 | Although using mnemonic not generated by algorithm described in "Generating the 104 | mnemonic" section is possible, this is not advised and software must compute 105 | checksum of the mnemonic sentence using wordlist and issue a warning if it is 106 | invalid. 107 | 108 | Described method also provides plausible deniability, because every passphrase 109 | generates a valid seed (and thus deterministic wallet) but only the correct one 110 | will make the desired wallet available. 111 | 112 | ==Wordlists== 113 | 114 | * [[bip-0039/english.txt|English]] 115 | 116 | ==Test vectors== 117 | 118 | See https://github.com/trezor/python-mnemonic/blob/master/vectors.json 119 | 120 | ==Reference Implementation== 121 | 122 | Reference implementation including wordlists is available from 123 | 124 | http://github.com/trezor/python-mnemonic 125 | 126 | ==Other Implementations== 127 | 128 | Objective-C - https://github.com/nybex/NYMnemonic 129 | 130 | -------------------------------------------------------------------------------- /selected BIPs/bip-0039.asciidoc: -------------------------------------------------------------------------------- 1 | ---------------------------------------------------------- 2 | BIP: BIP-0039 3 | Title: Mnemonic code for generating deterministic keys 4 | Authors: Marek Palatinus
2 | BIP: 14 3 | Title: BIP Protocol Version and User Agent 4 | Author: Amir Taaki11 | 12 | In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion. 13 | 14 | == Past Situation == 15 | 16 | Bitcoin as a protocol began life with the Satoshi client. Now that the community is diversifying, a number of alternative clients with their own codebases written in a variety of languages (Java, Python, Javascript, C++) are rapidly developing their own feature-sets. 17 | 18 | Embedded in the protocol is a version number. Primarily this version number is in the "version" and "getblocks" messages, but is also in the "block" message to indicate the software version that created that block. Currently this version number is the same version number as that of the client. This document is a proposal to separate the protocol version from the client version, together with a proposed method to do so. 19 | 20 | == Rationale == 21 | 22 | With non-separated version numbers, every release of the Satoshi client will increase its internal version number. Primarily this holds every other client hostage to a game of catch-up with Satoshi version number schemes. This plays against the decentralised nature of bitcoin, by forcing every software release to remain in step with the release schedule of one group of bitcoin developers. 23 | 24 | Version bumping can also introduce incompatibilities and fracture the network. In order that the health of the network is maintained, the development of the protocol as a shared common collaborative process requires being split off from the implementation of that protocol. Neutral third entities to guide the protocol with representatives from all groups, present the chance for bitcoin to grow in a positive manner with minimal risks. 25 | 26 | By using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network. 27 | 28 | Separation of the network protocol from the implemention, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type). 29 | 30 | User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing. 31 | 32 | In short: 33 | 34 | * Protocol version: way to distinguish between nodes and behave different accordingly. 35 | * User agent: simple informational tool. Protocol should not be modified depending on user agent. 36 | 37 | == Browser User-Agents == 38 | 39 | [http://tools.ietf.org/html/rfc1945 RFC 1945] vaguely specifies a user agent to be a string of the product with optional comments. 40 | 41 | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20100127 Gentoo Shiretoko/3.5.6 42 | 43 | User agents are most often parsed by computers more than humans. The space delimited format, does not provide an easy, fast or efficient way for parsing. The data contains no structure indicating hierarchy in this placement. 44 | 45 | The most immediate pieces of information there are the browser product, rendering engine and the build (Gentoo Shiretoko) together with version number. Various other pieces of information as included as comments such as desktop environment, platform, language and revision number of the build. 46 | 47 | == Proposal == 48 | 49 | The version field in "version" and "getblocks" packets will become the protocol version number. The version number in the "blocks" reflects the protocol version from when that block was created. 50 | 51 | The currently unused sub_version_num field in "version" packets will become the new user-agent string. 52 | 53 | Bitcoin user agents are a modified browser user agent with more structure to aid parsers and provide some coherence. In bitcoin, the software usually works like a stack starting from the core code-base up to the end graphical interface. Therefore the user agent strings codify this relationship. 54 | 55 | Basic format: 56 | 57 | /Name:Version/Name:Version/.../ 58 | 59 | Example: 60 | 61 | /Satoshi:5.64/bitcoin-qt:0.4/ 62 | /Satoshi:5.12/Spesmilo:0.8/ 63 | 64 | Here bitcoin-qt and Spesmilo may use protocol version 5.0, however the internal codebase they use are different versions of the same software. The version numbers are not defined to any strict format, although this guide recommends: 65 | 66 | * Version numbers in the form of Major.Minor.Revision (2.6.41) 67 | * Repository builds using a date in the format of YYYYMMDD (20110128) 68 | 69 | For git repository builds, implementations are free to use the git commitish. However the issue lies in that it is not immediately obvious without the repository which version precedes another. For this reason, we lightly recommend dates in the format specified above, although this is by no means a requirement. 70 | 71 | Optional -r1, -r2, ... can be appended to user agent version numbers. This is another light recommendation, but not a requirement. Implementations are free to specify version numbers in whatever format needed insofar as it does not include (, ), : or / to interfere with the user agent syntax. 72 | 73 | An optional comments field after the version number is also allowed. Comments should be delimited by brackets (...). The contents of comments is entirely implementation defined although this BIP recommends the use of semi-colons ; as a delimiter between pieces of information. 74 | 75 | Example: 76 | 77 | /BitcoinJ:0.2(iPad; U; CPU OS 3_2_1)/AndroidBuild:0.8/ 78 | 79 | Reserved symbols are therefore: / : ( ) 80 | 81 | They should not be misused beyond what is specified in this section. 82 | 83 | * / separates the code-stack 84 | * : specifies the implementation version of the particular stack 85 | * ( and ) delimits a comment which optionally separates data using ; 86 | 87 | == Timeline == 88 | 89 | When this document was published, the bitcoin protocol and Satoshi client versions were currently at 0.5 and undergoing changes. In order to minimise disruption and allow the undergoing changes to be completed, the next protocol version at 0.6 became peeled from the client version (also at 0.6). As of that time (January 2012), protocol and implementation version numbers are distinct from each other. 90 | -------------------------------------------------------------------------------- /selected BIPs/bip-0021.mediawiki: -------------------------------------------------------------------------------- 1 |5 | Patrick Strateman 6 | Status: Accepted 7 | Type: Standards Track 8 | Created: 2011-11-10 9 | Post-History: 2011-11-02 10 |
2 | BIP: 21 3 | Title: URI Scheme 4 | Author: Nils Schneider10 | 11 | This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed. 12 | 13 | ==Abstract== 14 | This BIP proposes a URI scheme for making Bitcoin payments. 15 | 16 | ==Motivation== 17 | The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. 18 | 19 | ==Specification== 20 | 21 | === General rules for handling (important!) === 22 | 23 | Bitcoin clients MUST NOT act on URIs without getting the user's authorization. 24 | They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision. 25 | 26 | === Operating system integration === 27 | Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client. 28 | 29 | === General Format === 30 | 31 | Bitcoin URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a bitcoin address, and the query component provides additional payment options. 32 | 33 | Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. 34 | 35 | === ABNF grammar === 36 | 37 | (See also [[#Simpler syntax|a simpler representation of syntax]]) 38 | 39 | bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ] 40 | bitcoinaddress = *base58 41 | bitcoinparams = bitcoinparam [ "&" bitcoinparams ] 42 | bitcoinparam = [ amountparam / labelparam / messageparam / otherparam / reqparam ] 43 | amountparam = "amount=" *digit [ "." *digit ] 44 | labelparam = "label=" *qchar 45 | messageparam = "message=" *qchar 46 | otherparam = qchar *qchar [ "=" *qchar ] 47 | reqparam = "req-" qchar *qchar [ "=" *qchar ] 48 | 49 | Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this BIP takes as separators. 50 | 51 | The scheme component ("bitcoin:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys. 52 | 53 | === Query Keys === 54 | 55 | *label: Label for that address (e.g. name of receiver) 56 | *address: bitcoin address 57 | *message: message that describes the transaction to the user ([[#Examples|see examples below]]) 58 | *size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) 59 | *(others): optional, for future extensions 60 | 61 | ==== Transfer amount/size ==== 62 | 63 | If an amount is provided, it MUST be specified in decimal BTC. 64 | All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions. 65 | I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is invalid. 66 | 67 | Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. 68 | They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. 69 | For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount. 70 | == Rationale == 71 | 72 | ===Payment identifiers, not person identifiers=== 73 | Current best practices are that a unique address should be used for every transaction. 74 | Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment. 75 | 76 | ===Accessibility (URI scheme name)=== 77 | Should someone from the outside happen to see such a URI, the URI scheme name already gives a description. 78 | A quick search should then do the rest to help them find the resources needed to make their payment. 79 | Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer. 80 | Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin. 81 | 82 | ==Forward compatibility== 83 | Variables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored. 84 | 85 | ==Backward compatibility== 86 | As this BIP is written, several clients already implement a bitcoin: URI scheme similar to this one, however usually without the additional "req-" prefix requirement. Thus, it is recommended that additional variables prefixed with req- not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade. 87 | 88 | == Appendix == 89 | 90 | === Simpler syntax === 91 | 92 | This section is non-normative and does not cover all possible syntax. 93 | Please see the BNF grammar above for the normative syntax. 94 | 95 | [foo] means optional, <bar> are placeholders 96 | 97 |5 | Matt Corallo 6 | Status: Accepted 7 | Type: Standards Track 8 | Created: 2012-01-29 9 |
2 | BIP: BIP-0044 3 | Title: Multi-Account Hierarchy for Deterministic Wallets 4 | Authors: Marek Palatinus10 | 11 | ==Abstract== 12 | 13 | This BIP defines a logical hierarchy for deterministic wallets based on an algorithm 14 | described in BIP-0032 (BIP32 from now on) and purpose scheme described in 15 | BIP-0043 (BIP43 from now on). 16 | 17 | This BIP is a particular application of BIP43. 18 | 19 | ==Motivation== 20 | 21 | The hierarchy proposed in this paper is quite comprehensive. It allows the handling of 22 | multiple coins, multiple accounts, external and internal chains per account and 23 | millions of addresses per chain. 24 | 25 | ==Path levels== 26 | 27 | We define the following 5 levels in BIP32 path: 28 | 29 |5 | Pavol Rusnak 6 | Status: Draft 7 | Type: Standards Track 8 | Created: 2014-04-24 9 |
30 | m / purpose' / coin_type' / account' / change / address_index 31 |32 | 33 | Apostrophe in the path indicates that BIP32 hardened derivation is used. 34 | 35 | Each level has a special meaning, described in the chapters below. 36 | 37 | ===Purpose=== 38 | 39 | Purpose is a constant set to 44' (or 0x8000002C) following the BIP43 recommendation. 40 | It indicates that the subtree of this node is used according to this specification. 41 | 42 | Hardened derivation is used at this level. 43 | 44 | ===Coin type=== 45 | 46 | One master node (seed) can be used for unlimited number of independent 47 | cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same 48 | space for various cryptocoins has some disadvantages. 49 | 50 | This level creates a separate subtree for every cryptocoin, avoiding 51 | reusing addresses across cryptocoins and improving privacy issues. 52 | 53 | Coin type is a constant, set for each cryptocoin. Cryptocoin developers may ask 54 | for registering unused number for their project. 55 | 56 | The list of already allocated coin types is in the chapter 57 | "Registered coin types" below. 58 | 59 | Hardened derivation is used at this level. 60 | 61 | ===Account=== 62 | 63 | This level splits the key space into independent user identities, 64 | so the wallet never mixes the coins across different accounts. 65 | 66 | Users can use these accounts to organize the funds in the same 67 | fashion as bank accounts; for donation purposes (where all 68 | addresses are considered public), for saving purposes, 69 | for common expenses etc. 70 | 71 | Accounts are numbered from index 0 in sequentially increasing manner. 72 | This number is used as child index in BIP32 derivation. 73 | 74 | Hardened derivation is used at this level. 75 | 76 | Software should prevent a creation of an account if a previous account does not 77 | have a transaction history (meaning none of its addresses have been used before). 78 | 79 | Software needs to discover all used accounts after importing the seed from 80 | an external source. Such an algorithm is described in "Account discovery" chapter. 81 | 82 | ===Change=== 83 | 84 | Constant 0 is used for external chain and constant 1 for internal chain (also 85 | known as change addresses). External chain is used for addresses that are meant 86 | to be visible outside of the wallet (e.g. for receiving payments). Internal 87 | chain is used for addresses which are not meant to be visible outside of the 88 | wallet and is used for return transaction change. 89 | 90 | Public derivation is used at this level. 91 | 92 | ===Index=== 93 | 94 | Addresses are numbered from index 0 in sequentially increasing manner. 95 | This number is used as child index in BIP32 derivation. 96 | 97 | Public derivation is used at this level. 98 | 99 | ==Account discovery== 100 | 101 | When the master seed is imported from an external source the software should 102 | start to discover the accounts in the following manner: 103 | 104 | # derive the first account's node (index = 0) 105 | # derive the external chain node of this account 106 | # scan addresses of the external chain; respect the gap limit described below 107 | # if no transactions are found on the external chain, stop discovery 108 | # if there are some transactions, increase the account index and go to step 1 109 | 110 | This algorithm is successful because software should disallow creation of new 111 | accounts if previous one has no transaction history, as described in chapter 112 | "Account" above. 113 | 114 | Please note that the algorithm works with the transaction history, not account 115 | balances, so you can have an account with 0 total coins and the algorithm will 116 | still continue with discovery. 117 | 118 | ===Address gap limit=== 119 | 120 | Address gap limit is currently set to 20. If the software hits 20 unused 121 | addresses in a row, it expects there are no used addresses beyond this point 122 | and stops searching the address chain. 123 | 124 | Wallet software should warn when the user is trying to exceed the gap limit on 125 | an external chain by generating a new address. 126 | 127 | ==Registered coin types== 128 | 129 | These are the registered coin types for usage in level 2 of BIP44 described in 130 | chapter "Coin type" above. 131 | 132 | All these constants are used as hardened derivation. 133 | 134 | {| 135 | !index 136 | !hexa 137 | !coin 138 | |- 139 | |0 140 | |0x80000000 141 | |Bitcoin 142 | |- 143 | |1 144 | |0x80000001 145 | |Bitcoin Testnet 146 | |} 147 | 148 | ==Examples== 149 | 150 | {| 151 | !coin 152 | !account 153 | !chain 154 | !address 155 | !path 156 | |- 157 | |Bitcoin 158 | |first 159 | |external 160 | |first 161 | |m / 44' / 0' / 0' / 0 / 0 162 | |- 163 | |Bitcoin 164 | |first 165 | |external 166 | |second 167 | |m / 44' / 0' / 0' / 0 / 1 168 | |- 169 | |Bitcoin 170 | |first 171 | |change 172 | |first 173 | |m / 44' / 0' / 0' / 1 / 0 174 | |- 175 | |Bitcoin 176 | |first 177 | |change 178 | |second 179 | |m / 44' / 0' / 0' / 1 / 1 180 | |- 181 | |Bitcoin 182 | |second 183 | |external 184 | |first 185 | |m / 44' / 0' / 1' / 0 / 0 186 | |- 187 | |Bitcoin 188 | |second 189 | |external 190 | |second 191 | |m / 44' / 0' / 1' / 0 / 1 192 | |- 193 | |Bitcoin 194 | |second 195 | |change 196 | |first 197 | |m / 44' / 0' / 1' / 1 / 0 198 | |- 199 | |Bitcoin 200 | |second 201 | |change 202 | |second 203 | |m / 44' / 0' / 1' / 1 / 1 204 | |- 205 | |Bitcoin Testnet 206 | |first 207 | |external 208 | |first 209 | |m / 44' / 1' / 0' / 0 / 0 210 | |- 211 | |Bitcoin Testnet 212 | |first 213 | |external 214 | |second 215 | |m / 44' / 1' / 0' / 0 / 1 216 | |- 217 | |Bitcoin Testnet 218 | |first 219 | |change 220 | |first 221 | |m / 44' / 1' / 0' / 1 / 0 222 | |- 223 | |Bitcoin Testnet 224 | |first 225 | |change 226 | |second 227 | |m / 44' / 1' / 0' / 1 / 1 228 | |- 229 | |Bitcoin Testnet 230 | |second 231 | |external 232 | |first 233 | |m / 44' / 1' / 1' / 0 / 0 234 | |- 235 | |Bitcoin Testnet 236 | |second 237 | |external 238 | |second 239 | |m / 44' / 1' / 1' / 0 / 1 240 | |- 241 | |Bitcoin Testnet 242 | |second 243 | |change 244 | |first 245 | |m / 44' / 1' / 1' / 1 / 0 246 | |- 247 | |Bitcoin Testnet 248 | |second 249 | |change 250 | |second 251 | |m / 44' / 1' / 1' / 1 / 1 252 | |} 253 | 254 | ==Compatible wallets== 255 | 256 | * [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]]) 257 | 258 | ==Reference== 259 | 260 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 261 | * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] 262 | -------------------------------------------------------------------------------- /selected BIPs/bip-0044.asciidoc: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------ 2 | BIP: BIP-0044 3 | Title: Multi-Account Hierarchy for Deterministic Wallets 4 | Authors: Marek Palatinus