├── doc ├── README.md ├── README_osx.txt ├── REST-interface.md ├── dnsseed-policy.md ├── files.md ├── gitian-building.md ├── gitian-building │ ├── create_new_vm.png │ ├── create_vm_file_location_size.png │ ├── create_vm_hard_disk.png │ ├── create_vm_hard_disk_file_type.png │ ├── create_vm_memsize.png │ ├── create_vm_storage_physical_hard_disk.png │ ├── debian_install_10_configure_clock.png │ ├── debian_install_11_partition_disks.png │ ├── debian_install_12_choose_disk.png │ ├── debian_install_14_finish.png │ ├── debian_install_15_write_changes.png │ ├── debian_install_16_choose_a_mirror.png │ ├── debian_install_18_proxy_settings.png │ ├── debian_install_19_software_selection.png │ ├── debian_install_1_boot_menu.png │ ├── debian_install_20_install_grub.png │ ├── debian_install_21_install_grub_bootloader.png │ ├── debian_install_22_finish_installation.png │ ├── debian_install_2_select_a_language.png │ ├── debian_install_3_select_location.png │ ├── debian_install_4_configure_keyboard.png │ ├── debian_install_5_configure_the_network.png │ ├── debian_install_6_domain_name.png │ ├── debian_install_6a_set_up_root_password.png │ ├── debian_install_7_set_up_user_fullname.png │ ├── debian_install_8_set_up_username.png │ ├── debian_install_9_user_password.png │ ├── debian_root_login.png │ ├── network_settings.png │ ├── port_forwarding_rules.png │ └── select_startup_disk.png ├── init.md ├── logging.md ├── reduce-traffic.md ├── release-process.md ├── shared-libraries.md ├── tor.md ├── travis-ci.txt ├── unit-tests.md └── zmq.md ├── howto └── installing_bitcoin_classic.md ├── roadmap ├── old │ ├── roadmap2016.md │ └── technical2016.md └── roadmap2016-2017.md └── spec ├── compactmessageformat.md └── transactionv4.md /doc/README.md: -------------------------------------------------------------------------------- 1 | Bitcoin Classic 2 | 3 | Setup 4 | --------------------- 5 | [Bitcoin Classic](https://bitcoinclassic.com/) is a Bitcoin client and it builds the backbone of the network. However, it downloads and stores the entire history of Bitcoin transactions (which is currently several GBs); depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more. 6 | 7 | ### Need Help? 8 | 9 | * See the documentation at the [Bitcoin Wiki](https://bitcoinfactswiki.github.io/) 10 | for help and more information. 11 | * Ask for help on [#bitcoin](http://webchat.freenode.net?channels=bitcoin) on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net?channels=bitcoin). 12 | 13 | Building 14 | --------------------- 15 | The following are developer notes on how to build Bitcoin on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc. 16 | 17 | - [Gitian Building Guide](gitian-building.md) 18 | 19 | Development 20 | --------------------- 21 | The Bitcoin repo's [root README](/README.md) contains relevant information on the development process and automated testing. 22 | 23 | - [Release Process](release-process.md) 24 | - [Source Code Documentation (External Link)](https://dev.visucore.com/bitcoin/doxygen/) 25 | - [Unit Tests](unit-tests.md) 26 | - [Unauthenticated REST Interface](REST-interface.md) 27 | - [Shared Libraries](shared-libraries.md) 28 | - [Dnsseed Policy](dnsseed-policy.md) 29 | 30 | ### Miscellaneous 31 | - [Files](files.md) 32 | - [Tor Support](tor.md) 33 | - [Init Scripts (systemd/upstart/openrc)](init.md) 34 | -------------------------------------------------------------------------------- /doc/README_osx.txt: -------------------------------------------------------------------------------- 1 | Deterministic OS X Dmg Notes. 2 | 3 | Working OS X DMGs are created in Linux by combining a recent clang, 4 | the Apple's binutils (ld, ar, etc), and DMG authoring tools. 5 | 6 | Apple uses clang extensively for development and has upstreamed the necessary 7 | functionality so that a vanilla clang can take advantage. It supports the use 8 | of -F, -target, -mmacosx-version-min, and --sysroot, which are all necessary 9 | when building for OS X. A pre-compiled version of 3.2 is used because it was not 10 | available in the Precise repositories at the time this work was started. In the 11 | future, it can be switched to use system packages instead. 12 | 13 | Apple's version of binutils (called cctools) contains lots of functionality 14 | missing in the FSF's binutils. In addition to extra linker options for 15 | frameworks and sysroots, several other tools are needed as well such as 16 | install_name_tool, lipo, and nmedit. These do not build under linux, so they 17 | have been patched to do so. The work here was used as a starting point: 18 | https://github.com/mingwandroid/toolchain4 19 | 20 | In order to build a working toolchain, the following source packages are needed 21 | from Apple: cctools, dyld, and ld64. 22 | 23 | These tools inject timestamps by default, which produce non-deterministic 24 | binaries. The ZERO_AR_DATE environment variable is used to disable that. 25 | 26 | This version of cctools has been patched to use the current version of clang's 27 | headers and and its libLTO.so rather than those from llvmgcc, as it was 28 | originally done in toolchain4. 29 | 30 | To complicate things further, all builds must target an Apple SDK. These SDKs 31 | are free to download, but not redistributable. 32 | To obtain it, register for a developer account, then download the Xcode 6.1.1 dmg: 33 | https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_6.1.1/xcode_6.1.1.dmg 34 | 35 | This file is several gigabytes in size, but only a single directory inside is 36 | needed: Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk 37 | 38 | Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file. 39 | To create a tarball suitable for Gitian input, mount the dmg in OS X, then create it with: 40 | $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk 41 | 42 | 43 | The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries 44 | which are created using these tools. The build process has been designed to 45 | avoid including the SDK's files in Gitian's outputs. All interim tarballs are 46 | fully deterministic and may be freely redistributed. 47 | 48 | genisoimage is used to create the initial DMG. It is not deterministic as-is, 49 | so it has been patched. A system genisoimage will work fine, but it will not 50 | be deterministic because the file-order will change between invocations. 51 | The patch can be seen here: 52 | https://raw.githubusercontent.com/theuni/osx-cross-depends/master/patches/cdrtools/genisoimage.diff 53 | No effort was made to fix this cleanly, so it likely leaks memory badly. But 54 | it's only used for a single invocation, so that's no real concern. 55 | 56 | genisoimage cannot compress DMGs, so afterwards, the 'dmg' tool from the 57 | libdmg-hfsplus project is used to compress it. There are several bugs in this 58 | tool and its maintainer has seemingly abandoned the project. It has been forked 59 | and is available (with fixes) here: https://github.com/theuni/libdmg-hfsplus . 60 | 61 | The 'dmg' tool has the ability to create DMGs from scratch as well, but this 62 | functionality is broken. Only the compression feature is currently used. 63 | Ideally, the creation could be fixed and genisoimage would no longer be necessary. 64 | 65 | Background images and other features can be added to DMG files by inserting a 66 | .DS_Store before creation. The easiest way to create this file is to build a 67 | DMG without one, move it to a device running OS X, customize the layout, then 68 | grab the .DS_Store file for later use. That is the approach taken here. 69 | 70 | As of OS X Mavericks (10.9), using an Apple-blessed key to sign binaries is a 71 | requirement in order to satisfy the new Gatekeeper requirements. Because this 72 | private key cannot be shared, we'll have to be a bit creative in order for the 73 | build process to remain somewhat deterministic. Here's how it works: 74 | 75 | - Builders use Gitian to create an unsigned release. This outputs an unsigned 76 | dmg which users may choose to bless and run. It also outputs an unsigned app 77 | structure in the form of a tarball, which also contains all of the tools 78 | that have been previously (deterministically) built in order to create a 79 | final dmg. 80 | - The Apple keyholder uses this unsigned app to create a detached signature, 81 | using the script that is also included there. 82 | - Builders feed the unsigned app + detached signature back into Gitian. It 83 | uses the pre-built tools to recombine the pieces into a deterministic dmg. 84 | -------------------------------------------------------------------------------- /doc/REST-interface.md: -------------------------------------------------------------------------------- 1 | Unauthenticated REST Interface 2 | ============================== 3 | 4 | The REST API can be enabled with the `-rest` option. 5 | 6 | Supported API 7 | ------------- 8 | 9 | ####Transactions 10 | `GET /rest/tx/.` 11 | 12 | Given a transaction hash: returns a transaction in binary, hex-encoded binary, or JSON formats. 13 | 14 | For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option. 15 | 16 | ####Blocks 17 | `GET /rest/block/.` 18 | `GET /rest/block/notxdetails/.` 19 | 20 | Given a block hash: returns a block, in binary, hex-encoded binary or JSON formats. 21 | 22 | The HTTP request and response are both handled entirely in-memory, thus making maximum memory usage at least 2.66MB (1 MB max block, plus hex encoding) per request. 23 | 24 | With the /notxdetails/ option JSON response will only contain the transaction hash instead of the complete transaction details. The option only affects the JSON response. 25 | 26 | ####Blockheaders 27 | `GET /rest/headers//.` 28 | 29 | Given a block hash: returns amount of blockheaders in upward direction. 30 | 31 | ####Chaininfos 32 | `GET /rest/chaininfo.json` 33 | 34 | Returns various state info regarding block chain processing. 35 | Only supports JSON as output format. 36 | * chain : (string) current network name as defined in BIP70 (main, test, regtest) 37 | * blocks : (numeric) the current number of blocks processed in the server 38 | * headers : (numeric) the current number of headers we have validated 39 | * bestblockhash : (string) the hash of the currently best block 40 | * difficulty : (numeric) the current difficulty 41 | * verificationprogress : (numeric) estimate of verification progress [0..1] 42 | * chainwork : (string) total amount of work in active chain, in hexadecimal 43 | * pruned : (boolean) if the blocks are subject to pruning 44 | * pruneheight : (numeric) heighest block available 45 | * softforks : (array) status of softforks in progress 46 | 47 | ####Query UTXO set 48 | `GET /rest/getutxos//-/-/.../-.` 49 | 50 | The getutxo command allows querying of the UTXO set given a set of outpoints. 51 | See BIP64 for input and output serialisation: 52 | https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki 53 | 54 | Example: 55 | ``` 56 | $ curl localhost:18332/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff7627ff72e5e8b0f71210f92ea7a4000c5d75-0.json 2>/dev/null | json_pp 57 | { 58 | "chaintipHash" : "00000000fb01a7f3745a717f8caebee056c484e6e0bfe4a9591c235bb70506fb", 59 | "chainHeight" : 325347, 60 | "utxos" : [ 61 | { 62 | "scriptPubKey" : { 63 | "addresses" : [ 64 | "mi7as51dvLJsizWnTMurtRmrP8hG2m1XvD" 65 | ], 66 | "type" : "pubkeyhash", 67 | "hex" : "76a9141c7cebb529b86a04c683dfa87be49de35bcf589e88ac", 68 | "reqSigs" : 1, 69 | "asm" : "OP_DUP OP_HASH160 1c7cebb529b86a04c683dfa87be49de35bcf589e OP_EQUALVERIFY OP_CHECKSIG" 70 | }, 71 | "value" : 8.8687, 72 | "height" : 2147483647, 73 | "txvers" : 1 74 | } 75 | ], 76 | "bitmap" : "1" 77 | } 78 | ``` 79 | 80 | ####Memory pool 81 | `GET /rest/mempool/info.json` 82 | 83 | Returns various information about the TX mempool. 84 | Only supports JSON as output format. 85 | * size : (numeric) the number of transactions in the TX mempool 86 | * bytes : (numeric) size of the TX mempool in bytes 87 | * usage : (numeric) total TX mempool memory usage 88 | 89 | `GET /rest/mempool/contents.json` 90 | 91 | Returns transactions in the TX mempool. 92 | Only supports JSON as output format. 93 | 94 | Risks 95 | ------------- 96 | Running a web browser on the same node with a REST enabled bitcoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `