├── .gitignore ├── .travis.yml ├── LICENSE-CC-BY-SA-4-POINT-0 ├── Makefile ├── README.rst ├── make.bat ├── old-docs-for-reference ├── go-ethereum-wiki.rst │ ├── ABI-dream-API.rst │ ├── Accounts---key-storage-specification.rst │ ├── Assembler.rst │ ├── Backup-&-restore.rst │ ├── Blockpool.rst │ ├── Building-Edge.rst │ ├── Building-Ethereum.rst │ ├── Building-Qt.rst │ ├── Command-Line-Options.rst │ ├── Connecting-to-the-network.rst │ ├── Contract-Tutorial.rst │ ├── Contracts-and-Transactions.rst │ ├── Creating-your-own-Ethereum-apps-using-Eth-go.rst │ ├── Cross-compiling-Ethereum.rst │ ├── Database.rst │ ├── Developers'-Guide.rst │ ├── Disclaimer.rst │ ├── Ethereum-Specification.rst │ ├── Ethereum-on-Android.rst │ ├── FAQ.rst │ ├── Frontier.rst │ ├── Gas-Price-Oracle.rst │ ├── Geth.rst │ ├── Getting-Geth.rst │ ├── Go-ethereum-management-API's.rst │ ├── Home.rst │ ├── How-to-Whisper.rst │ ├── Installation-Instructions-for-ARM.rst │ ├── Installation-Instructions-for-Arch.rst │ ├── Installation-Instructions-for-FreeBSD.rst │ ├── Installation-Instructions-for-Mac.rst │ ├── Installation-Instructions-for-Ubuntu.rst │ ├── Installation-instructions-for-Windows.rst │ ├── Installing-Go.rst │ ├── JavaScript-Console.rst │ ├── Legacy.rst │ ├── Managing-your-accounts.rst │ ├── Metrics-and-Monitoring.rst │ ├── Mining.rst │ ├── Mist-build-instructions-for-Mac.rst │ ├── Multi-protocol-peer-selection.rst │ ├── Mutan-0.2-Example.rst │ ├── Mutan-0.2.rst │ ├── Mutan-0.4-Examples.rst │ ├── Mutan-0.4.rst │ ├── Mutan-0.5-Examples.rst │ ├── Mutan-0.5.rst │ ├── Mutan-0.6-Examples.rst │ ├── Mutan-0.6.rst │ ├── Mutan.rst │ ├── Passphrase-protected-key-store-spec.rst │ ├── Peer-to-Peer.rst │ ├── Private-network.rst │ ├── Provisional-JS-API.rst │ ├── RLPx-----Node-Discovery-Protocol.rst │ ├── RLPx-Encryption.rst │ ├── RLPx-Peer-Selection-Proposal.rst │ ├── Running-in-Docker.rst │ ├── Sending-ether.rst │ ├── Setting-up-Ethereum-(Native).rst │ ├── Setting-up-monitoring-on-local-cluster.rst │ ├── Setting-up-private-network-or-local-cluster.rst │ ├── Swarm---TODO.rst │ ├── Swarm---distributed-preimage-archive.rst │ ├── Swarm-Channels,-Namereg-resolution-draft.rst │ ├── Swarm-Contract.rst │ ├── Testing.rst │ ├── Troubleshooting.rst │ ├── URL-Scheme.rst │ ├── Wire-protocol-Extended-(Child-processes).rst │ ├── XEth.rst │ ├── _Footer.rst │ ├── _Sidebar.rst │ ├── bitchin-tricks.rst │ └── iceCREAM-(debugger).rst └── main-wiki.rst │ ├── Adaptive-Message-IDs.rst │ ├── Adaptive-Peer-Time.rst │ ├── Bad-Block-Reporting.rst │ ├── Bad-Chain-Canary.rst │ ├── Benchmarks.rst │ ├── Block-Protocol-2.0.rst │ ├── Blockchain-import-and-export-instructions.rst │ ├── Brain-Wallet.rst │ ├── Chain-Fibers-Redux.rst │ ├── Client-Version-Strings.rst │ ├── Contract-Metadata-Docs-(NatSpec,-ABI).rst │ ├── Dapp-Developer-Resources.rst │ ├── Dapp-using-Meteor.rst │ ├── Default-Extra-Data-Standard.rst │ ├── Design-Rationale.rst │ ├── Deterministic_Wallet_Spec.rst │ ├── Distributed-Preimage-Archive.rst │ ├── Ethash-C-API.rst │ ├── Ethash-DAG-Disk-Storage-Format.rst │ ├── Ethash-DAG.rst │ ├── Ethash-Design-Rationale.rst │ ├── Ethash.rst │ ├── Ethereum-Contract-ABI.rst │ ├── Ethereum-Development-Tutorial.rst │ ├── Ethereum-Natural-Specification-Format.rst │ ├── Ethereum-Wire-Protocol.rst │ ├── FAQ.rst │ ├── Geth-Dapp-loading-proposal.rst │ ├── Gitter-Channels.rst │ ├── Glossary.rst │ ├── HPOC_2015.rst │ ├── Home.rst │ ├── ICAP-Inter-exchange-Client-Address-Protocol.rst │ ├── IPv6.rst │ ├── JSON-RPC-Error-Codes-Improvement-Proposal.rst │ ├── JSON-RPC.rst │ ├── JavaScript-API.rst │ ├── Kademlia-Peer-Selection.rst │ ├── Licensing.rst │ ├── Light-client-protocol.rst │ ├── Middleware-and-Dapp-Project-Ideas.rst │ ├── Mining.rst │ ├── Mix-Features.rst │ ├── Mix-The-DApp-IDE.rst │ ├── Mix-improvement-proposal.rst │ ├── Morden.rst │ ├── NatSpec-Determination.rst │ ├── Natspec-Example.rst │ ├── Network-Status.rst │ ├── Node-discovery-protocol.rst │ ├── Open-positions-&-Schemes.rst │ ├── Parallel-Block-Downloads.rst │ ├── Patricia-Tree.rst │ ├── Poll-for-token-proposal-EIP-20.rst │ ├── Problems.rst │ ├── Proposal-Extend-GetBlockHashes-with-target-hash.rst │ ├── Proposal-NewBlockHashes.rst │ ├── Proposal-Reversion-Notification.rst │ ├── Proposal-Transaction-Proxy-Hooks.rst │ ├── RLP.rst │ ├── RPC-Testing.rst │ ├── Raspberry-Pi-instructions.rst │ ├── Registrar-ABI.rst │ ├── Security-Categorization.rst │ ├── Security-Issue-Process.rst │ ├── Serenity_Wishlist.rst │ ├── Serpent.rst │ ├── Serpent_3.0.rst │ ├── Solidity,-Docs-and-ABI.rst │ ├── Solidity-Changelog.rst │ ├── Solidity-Features.rst │ ├── Solidity-Tutorial.rst │ ├── Solidity-standard-library.rst │ ├── Standardized_Contract_APIs.rst │ ├── Subtleties.rst │ ├── Swarm-Hash.rst │ ├── The-Solidity-Programming-Language.rst │ ├── URL-Hint-Protocol.rst │ ├── Useful-Ðapp-Patterns.rst │ ├── Web3-Secret-Storage-Definition.rst │ ├── What-is-Ethereum.rst │ ├── Whisper-Overview.rst │ ├── Whisper-PoC-2-Protocol-Spec.rst │ ├── Whisper-PoC-2-Wire-Protocol.rst │ ├── Whisper-Wire-Protocol.rst │ ├── Whisper.rst │ ├── White-Paper.rst │ ├── _Footer.rst │ ├── _Sidebar.rst │ ├── enode-url-format.rst │ ├── eπ-Programme.rst │ ├── libp2p-Whitepaper.rst │ ├── newBlockFilter-Improvement-Proposal.rst │ ├── web.js-0.9.rst │ └── ÐΞVp2p-Wire-Protocol.rst ├── requirements.txt ├── rst_lint.py ├── source ├── about.rst ├── account-management.rst ├── conf.py ├── connecting-to-clients │ ├── ethereum-ruby │ │ └── index.rst │ ├── index.rst │ ├── nethereum │ │ └── index.rst │ ├── web3.js │ │ └── index.rst │ ├── web3.py │ │ └── index.rst │ └── web3j │ │ └── index.rst ├── contracts-and-transactions │ ├── accessing-contracts-and-transactions.rst │ ├── account-types-gas-and-transactions.rst │ ├── contracts.rst │ ├── developer-tools.rst │ ├── ethereum-tests │ │ └── index.rst │ ├── index.rst │ ├── mix.rst │ ├── mix │ │ ├── codeeditor.rst │ │ ├── dapp-deployment.rst │ │ ├── dapp-deployment.rst~ │ │ ├── javascript-console.rst │ │ ├── mix_bc.png │ │ ├── project-editor.rst │ │ ├── scenario-editor.rst │ │ ├── state-viewer.rst │ │ ├── state_mix.png │ │ ├── transaction-debugger.rst │ │ └── transaction-explorer.rst │ └── web3-base-layer-services.rst ├── ether.rst ├── ethereum-clients │ ├── choosing-a-client.rst │ ├── cpp-ethereum │ │ ├── architecture.rst │ │ ├── building-from-source │ │ │ ├── android.rst │ │ │ ├── beaglebone.rst │ │ │ ├── freebsd.rst │ │ │ ├── index.rst │ │ │ ├── ios.rst │ │ │ ├── linux-arch.rst │ │ │ ├── linux-arm.rst │ │ │ ├── linux-fedora.rst │ │ │ ├── linux-opensuse.rst │ │ │ ├── linux.rst │ │ │ ├── macos.rst │ │ │ ├── odroid.rst │ │ │ ├── rpi.rst │ │ │ ├── wandboard.rst │ │ │ └── windows.rst │ │ ├── contributing.rst │ │ ├── current-status.rst │ │ ├── index.rst │ │ ├── installing-binaries │ │ │ ├── docker.rst │ │ │ ├── index.rst │ │ │ ├── linux-arch-aur.rst │ │ │ ├── linux-cross-builds.rst │ │ │ ├── linux-mageia.rst │ │ │ ├── linux-sbcs.rst │ │ │ ├── linux-ubuntu-ppa.rst │ │ │ ├── linux-ubuntu-snap.rst │ │ │ ├── osx-homebrew.rst │ │ │ └── windows-chocolatey.rst │ │ ├── portability.rst │ │ └── running.rst │ ├── ethereumh │ │ └── index.rst │ ├── ethereumj │ │ └── index.rst │ ├── ethereumjs-lib │ │ └── index.rst │ ├── go-ethereum │ │ └── index.rst │ ├── index.rst │ ├── parity │ │ └── index.rst │ ├── pyethapp │ │ └── index.rst │ └── ruby-ethereum │ │ └── index.rst ├── frequently-asked-questions │ └── frequently-asked-questions.rst ├── glossary.rst ├── img │ ├── 51Downloading.png │ ├── 51OpeningScreen.png │ ├── 51PresaleImportInstall.png │ ├── ETHEREUM-ICON_Black.png │ ├── Feels-Good-Man-Frog-02.png │ ├── contract_relationship.png │ ├── contract_relationship2.png │ ├── cpp_35k9.png │ ├── dependency_graph.svg │ ├── eth_miner_setup.png │ ├── ethereum-homestead-documentation-logo.png │ ├── ethereum-protocols.png │ ├── homestead-guide.svg │ ├── jenkins.png │ └── target_dependency_graph.svg ├── index.rst ├── introduction │ ├── community.rst │ ├── contributors.rst │ ├── foundation.rst │ ├── history-of-ethereum.rst │ ├── how-to-use-this-guide.rst │ ├── index.rst │ ├── the-homestead-release.rst │ ├── web3.rst │ └── what-is-ethereum.rst ├── mining.rst └── network │ ├── connecting-to-the-network.rst │ ├── index.rst │ └── test-networks.rst └── tox.ini /.gitignore: -------------------------------------------------------------------------------- 1 | build 2 | 3 | # emacs Backup files 4 | *~ 5 | 6 | # MacOS Development 7 | .DS_Store 8 | 9 | # Python virtual environment 10 | .venv 11 | 12 | # IntelliJ project files 13 | *.iml 14 | .idea 15 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | sudo: false 2 | cache: pypi 3 | language: python 4 | python: 5 | - "2.7" 6 | env: 7 | matrix: 8 | - TOX_ENV=rst_lint 9 | install: 10 | - 'travis_retry pip install setuptools --upgrade' 11 | - 'travis_retry pip install tox' 12 | script: 13 | - tox -e $TOX_ENV 14 | after_script: 15 | - cat .tox/$TOX_ENV/log/*.log 16 | -------------------------------------------------------------------------------- /LICENSE-CC-BY-SA-4-POINT-0: -------------------------------------------------------------------------------- 1 | The license for this repository is CC BY-SA 4.0. 2 | 3 | A human-readable summary (and not a substitute) of the license is [here](https://creativecommons.org/licenses/by-sa/4.0/). 4 | 5 | The license is [here](https://creativecommons.org/licenses/by-sa/4.0/legalcode). 6 | -------------------------------------------------------------------------------- /README.rst: -------------------------------------------------------------------------------- 1 | ***************************** 2 | Homestead-Guide 3 | ***************************** 4 | |License| |Gitter| 5 | 6 | .. |License| image:: https://img.shields.io/badge/License-CC%20BY--SA%204.0-lightgrey.svg 7 | :target: https://creativecommons.org/licenses/by-sa/4.0/ 8 | 9 | .. |Gitter| image:: https://badges.gitter.im/ethereum/homestead-guide.svg 10 | :target: https://gitter.im/ethereum/homestead-guide?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge 11 | 12 | 13 | DEPRECATION NOTICE 14 | ================== 15 | 16 | The Ethereum Homestead Guide is the reference documentation accompanying the **Homestead release** of the Ethereum project. 17 | The information in this repository is largely out of date. Relevant material has been migrated to https://ethereum.org. 18 | and this repository is **due to be archived shortly**. For current information on Ethereum, please visit https://ethereum.org instead. 19 | This repository is for historical reference only! 20 | 21 | 22 | HOW YOU CAN HELP 23 | ================================================================================ 24 | 25 | Looking to contribute to Ethereum documentation? Check out the ethereum.org repo: https://github.com/ethereum/ethereum-org-website 26 | 27 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/ABI-dream-API.rst: -------------------------------------------------------------------------------- 1 | .. code:: go 2 | 3 | package main 4 | 5 | import "fmt" 6 | 7 | type Type byte 8 | 9 | const ( 10 | AddressTy Type = iota 11 | Int32Ty 12 | Int64Ty 13 | Int256Ty 14 | // .... 15 | ) 16 | 17 | func main() { 18 | // ABI. 19 | abi := ABI{ 20 | Methods: []Method{ 21 | Method{ 22 | Name: "balance", 23 | Const: true, 24 | }, 25 | 26 | Method{ 27 | Name: "send", 28 | Const: false, 29 | Arguments: []Argument{ 30 | Argument{ 31 | Name: "to", 32 | Type: AddressTy, 33 | }, 34 | Argument{ 35 | Name: "amount", 36 | Type: Int256Ty, 37 | }, 38 | }, 39 | }, 40 | }, 41 | } 42 | // The above should be returned by = ParseABI(json) 43 | 44 | account := state.GetAccount(address) 45 | account.SetABI(abi) 46 | 47 | // Hot wallet (to supply transactor) 48 | hot := state.GetAccount(hotAddress) 49 | // "idea" to specify the transactor 50 | state.SetTransactor(hot) 51 | // OR specify it through call 52 | account.Call(hot /* .... see params below */) 53 | 54 | // This will do a local call (const = true) 55 | balance, err := account.Call("balance") 56 | if err != nil { 57 | exit(err) 58 | } 59 | fmt.Println("balance =", balance) 60 | 61 | // This will do an actual transaction (const = false) 62 | ret, err := account.Call("send", Address([]byte("my_address")), Int256("111111111111111111")) 63 | if err != nil { 64 | exit(err) 65 | } 66 | fmt.Println("ret =", ret) 67 | 68 | // "low" level transaction method w/ private key 69 | to := state.GetAccount(toAddress) 70 | tx, err := state.Transact(hot, to, Int256("123"), Int256("123"), Int256("123"), []byte("data")) 71 | if err != nil { 72 | exit(err) 73 | } 74 | fmt.Println("tx =", tx) 75 | 76 | // This should return an error (no private key) 77 | tx, err = state.Transact(to, hot, Int256("123"), Int256("123"), Int256("123"), []byte("data")) 78 | if err != nil { 79 | exit(err) 80 | } 81 | fmt.Println("tx =", tx) 82 | } 83 | 84 | // JSON 85 | /* 86 | [ 87 | { "name" : "balance", "const" : true }, 88 | { "name" : "send", "const" : false, "input" : [ { "name" : "to", "type" : "int256" } ] }, 89 | ] 90 | */ 91 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Accounts---key-storage-specification.rst: -------------------------------------------------------------------------------- 1 | **THIS PAGE IS PARTLY OUTDATED! TODO: REFACTOR OR DELETE** 2 | 3 | Accounts / key storage specification 4 | ==================================== 5 | 6 | This is an attempt to compile a single, written specification from the 7 | multiple sources which have so far been used for accounts / key storage 8 | specs: 9 | 10 | - Skype calls 11 | - Skype chats 12 | - Email conversations 13 | - Github issues 14 | - Github pull request comments 15 | - Github commits 16 | - Lively in-person discussions in the Amsterdam office. 17 | - Several past instances of the Amsterdam office whiteboard contents. 18 | 19 | Background 20 | ========== 21 | 22 | Up until Ethereum PoC 8, the Go client has used a single, default key in 23 | plaintext on disk for use as wallet and for signing all txs. We want to 24 | extend this to have a more generic key storage supporting multiple keys. 25 | We also want an "accounts" abstraction over these keys where an account 26 | corresponds to a key, and a user can have multiple accounts and be able 27 | to send / receive to any of them. 28 | 29 | The goal of this is to support better wallet / account functionality 30 | both in Mist as well as in dapps. 31 | 32 | Specification 33 | ============= 34 | 35 | Key Storage 36 | ----------- 37 | 38 | The key storage must support: 39 | 40 | 1. Generation of new keys 41 | 2. Deletion of keys. 42 | 3. Multiple, uniquely identifiable keys. 43 | 4. Password protection of keys. 44 | 5. Persistence of keys (e.g. on disk) 45 | 6. Export & Import of keys. 46 | 7. Import of pre-sale keys (generated by 47 | https://github.com/ethereum/pyethsaletool) NOTE: this is a different 48 | import functionality than general import (6) 49 | 8. Proper use of secure cryptography for key generation, password 50 | protection, key persistence and export format of keys. 51 | 9. Mechanism for Backing the keys up – maybe automatically 52 | 53 | Account Manager 54 | --------------- 55 | 56 | 0. Account == address of an Ethereum account == address of EC public key 57 | of EC private key the user controls. 58 | 59 | The account manager must support: 60 | 61 | 1. Account creation & deletion 62 | 2. Multiple, unique accounts. 63 | 3. Persistence of accounts (e.g. on disk) 64 | 4. An account is mapped to a single key. 65 | 5. The account is identifiable by some public, non-sensitive data. E.g. 66 | the Ethereum address of a EC keypair can be used as account 67 | identifier / address. 68 | 69 | Mist 70 | ---- 71 | 72 | The Mist UI must support: 73 | 74 | 1. Creation of a new account. 75 | 2. Display a list of all available accounts (addresses) 76 | 3. Copy-paste of account addresses to easily use when receiving funds. 77 | 4. Choosing one of the available accounts when sending a tx. 78 | 5. Typing password when accessing one of the hot wallet keys 79 | 6. Showing the possible ways to temporarily input wallet keys when 80 | needed 81 | 82 | RPC API 83 | ------- 84 | 85 | The RPC API must support: 86 | 87 | 1. The list of accounts is exposed through the eth\_accounts API: 88 | https://github.com/ethereum/wiki/wiki/JSON-RPC#eth\_accounts 89 | 2. Using any of the available accounts as from/sender with the 90 | eth\_transact API: 91 | https://github.com/ethereum/wiki/wiki/JSON-RPC#eth\_transact (NOTE: 92 | the current API definition on that wiki page does not include a 93 | from/sender field!) 94 | 95 | Wallet dapp 96 | ----------- 97 | 98 | TODO: 99 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Assembler.rst: -------------------------------------------------------------------------------- 1 | This is the assembler code emitted by the Mutan compiler and which can 2 | be used directly in the ``asm`` expression followed by the asm opcodes. 3 | 4 | Comments can be made using ";" 5 | 6 | .. code:: d 7 | 8 | asm { 9 | push1 10 ; Push 10 to stack 10 | push1 20 ; Push 20 to stack 11 | add ; Add 10 and 20 together 12 | } 13 | 14 | Arithmetic operations 15 | ^^^^^^^^^^^^^^^^^^^^^ 16 | 17 | :: 18 | 19 | stop 20 | add 21 | mul 22 | sub 23 | div 24 | sdiv 25 | mod 26 | smod 27 | exp 28 | neg 29 | lt 30 | gt 31 | eq 32 | not 33 | 34 | Bit operations 35 | ^^^^^^^^^^^^^^ 36 | 37 | :: 38 | 39 | and 40 | or 41 | xor 42 | byte 43 | 44 | Crypto operations 45 | ^^^^^^^^^^^^^^^^^ 46 | 47 | :: 48 | 49 | sha3 50 | 51 | Context operations 52 | ^^^^^^^^^^^^^^^^^^ 53 | 54 | :: 55 | 56 | address 57 | balance 58 | origin 59 | caller 60 | callvalue 61 | calldataload 62 | calldatasize 63 | gasprice 64 | 65 | Block operations 66 | ^^^^^^^^^^^^^^^^ 67 | 68 | :: 69 | 70 | prevhash 71 | coinbase 72 | timestamp 73 | number 74 | difficulty 75 | gaslimit 76 | 77 | Storage and execution operations 78 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 79 | 80 | :: 81 | 82 | pop 83 | dup 84 | swap 85 | mload 86 | mstore 87 | mstore8 88 | sload 89 | sstore 90 | jump 91 | jumpi 92 | pc 93 | msize 94 | 95 | Call / Create operations 96 | ^^^^^^^^^^^^^^^^^^^^^^^^ 97 | 98 | :: 99 | 100 | create 101 | call 102 | return 103 | suicide 104 | 105 | Push operations 106 | ^^^^^^^^^^^^^^^ 107 | 108 | :: 109 | 110 | push1 111 | push2 112 | push3 113 | push4 114 | push5 115 | push6 116 | push7 117 | push8 118 | push9 119 | push10 120 | push11 121 | push12 122 | push13 123 | push14 124 | push15 125 | push16 126 | push17 127 | push18 128 | push19 129 | push20 130 | push21 131 | push22 132 | push23 133 | push24 134 | push25 135 | push26 136 | push27 137 | push28 138 | push29 139 | push30 140 | push31 141 | push32 142 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Backup-&-restore.rst: -------------------------------------------------------------------------------- 1 | **DO NOT FORGET YOUR PASSWORD** and **BACKUP YOUR KEYSTORE** 2 | 3 | Backup & restore 4 | ================ 5 | 6 | Data directory 7 | -------------- 8 | 9 | Everything ``geth`` persists gets written inside its data directory 10 | (except for the PoW Ethash DAG, see note below). The default data 11 | directory locations are platform specific: 12 | 13 | - Mac: ``~/Library/Ethereum`` 14 | - Linux: ``~/.ethereum`` 15 | - Windows: ``%APPDATA%/Ethereum`` 16 | 17 | Accounts are stored in the ``keystore`` subdirectory. The contents of 18 | this directories should be transportable between nodes, platforms, 19 | implementations (C++, Go, Python). 20 | 21 | To configure the location of the data directory, the ``--datadir`` 22 | parameter can be specified. See `CLI 23 | Options `__ 24 | for more details. 25 | 26 | ***Note:** The `Ethash 27 | DAG `__ 28 | is stored at ``~/.ethash`` (Mac/Linux) or ``~/AppData/Ethash`` (Windows) 29 | so that it can be reused by all clients. You can store this in a 30 | different location by using a symbolic link.* 31 | 32 | Upgrades 33 | -------- 34 | 35 | Sometimes the internal database formats need updating (for example, when 36 | upgrade from before 0.9.20). This can be run with the following command 37 | (geth should not be otherwise running): 38 | 39 | :: 40 | 41 | geth upgradedb 42 | 43 | Cleanup 44 | ------- 45 | 46 | Geth's blockchain and state databases can be removed with: 47 | 48 | :: 49 | 50 | geth removedb 51 | 52 | This is useful for deleting an old chain and sync'ing to a new one. It 53 | only affects data directories that can be re-created on synchronisation 54 | and does not touch the keystore. 55 | 56 | Blockchain import/export 57 | ------------------------ 58 | 59 | Export the blockchain in binary format with: 60 | 61 | :: 62 | 63 | geth export 64 | 65 | Or if you want to back up portions of the chain over time, a first and 66 | last block can be specified. For example, to back up the first epoch: 67 | 68 | :: 69 | 70 | geth export 0 29999 71 | 72 | Note that when backing up a partial chain, the file will be appended 73 | rather than truncated. 74 | 75 | Import binary-format blockchain exports with: 76 | 77 | :: 78 | 79 | geth import 80 | 81 | *See https://github.com/ethereum/wiki/wiki/Blockchain-import-export for 82 | more info* 83 | 84 | And finally: **DO NOT FORGET YOUR PASSWORD** and **BACKUP YOUR 85 | KEYSTORE** -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Building-Edge.rst: -------------------------------------------------------------------------------- 1 | We assume you have a GOPATH set up appropriately. If not, you can read 2 | about setting it up here: http://golang.org/doc/code.html#GOPATH. 3 | 4 | In order to 'build edge', we need to switch 3 repos to their 'develop' 5 | branch 6 | 7 | - Begin by getting the newest version of the go client source and their 8 | dependencies: 9 | 10 | :: 11 | 12 | go get -u -d github.com/obscuren/serpent-go 13 | go get -u -d github.com/ethereum/go-ethereum/ethereum 14 | go get -u -d github.com/ethereum/go-ethereum/mist 15 | 16 | - Init the serpent submodule 17 | 18 | :: 19 | 20 | cd $GOPATH/src/github.com/obscuren/serpent-go 21 | git submodule init 22 | git submodule update 23 | 24 | - Switch to the ``develop`` branch the necessary repos: 25 | 26 | :: 27 | 28 | cd $GOPATH/src/github.com/ethereum/go-ethereum 29 | git checkout develop 30 | 31 | cd $GOPATH/src/github.com/ethereum/eth-go 32 | git checkout develop 33 | 34 | cd $GOPATH/src/github.com/obscuren/mutan 35 | git checkout develop 36 | 37 | - Go forth and build away: 38 | 39 | :: 40 | 41 | cd $GOPATH/src/github.com/ethereum/go-ethereum/ethereum 42 | go install -v 43 | 44 | cd $GOPATH/src/github.com/ethereum/go-ethereum/mist 45 | go install -v 46 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Building-Ethereum.rst: -------------------------------------------------------------------------------- 1 | Installation Instructions 2 | ------------------------- 3 | 4 | Follow the appropriate link below to find installation instructions for 5 | your platform. 6 | 7 | - `Installation Instructions for Mac OS 8 | X `__ 9 | - `Installation Instructions for 10 | Windows `__ 11 | - Installation Instructions for Linux/Unix 12 | - `Ubuntu `__ 13 | - `Arch `__ 14 | - `FreeBSD `__ 15 | - `Setup for Raspberry 16 | Pi `__ 17 | - `ARM `__ 18 | - `Usage instructions for 19 | Docker `__ 20 | 21 | You can also use a one-line script install Geth. Open a command line or 22 | terminal tool (if you are unsure how to do this, consider waiting for a 23 | more user friendly release) and paste the command below: 24 | 25 | :: 26 | 27 | bash <(curl -L https://install-geth.ethereum.org) 28 | 29 | This script will detect your OS and will attempt to install the Ethereum 30 | CLI. For more options including package managers, check the OS-specific 31 | subsections. 32 | 33 | Further links \* `Compiled binaries on launchpad.net buildbot 34 | listings `__ \* `Ethereum 35 | buildbot `__ 36 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Building-Qt.rst: -------------------------------------------------------------------------------- 1 | Ethereum(Go) Requires QML 5.4+ 2 | 3 | Mac OS X 4 | -------- 5 | 6 | Please see `build instruction for 7 | OSX `__ 8 | 9 | Linux 10 | ----- 11 | 12 | Ubuntu 14.04 13 | ~~~~~~~~~~~~ 14 | 15 | :: 16 | 17 | sudo apt-get install pkg-config 18 | sudo add-apt-repository ppa:ethereum/ethereum-qt 19 | sudo apt-get update 20 | sudo apt-get install -y qtbase5-dev qtbase5-private-dev libqt5opengl5-dev qtdeclarative5-dev qml-module-qtquick-controls qml-module-qtquick-dialogs libqt5webengine5-dev 21 | 22 | Now it's time to build Qt: 23 | 24 | :: 25 | 26 | go get -u github.com/obscuren/qml 27 | cd $GOPATH/src/github.com/obscuren/qml && git checkout v1 28 | go build 29 | 30 | If you receive an error about not being able to find Qt\* items, check 31 | that PKG\_CONFIG\_PATH and LD\_LIBRARY\_PATH have been set 32 | (``echo $PKG_CONFIG_PATH`` and ``echo $LD_LIBRARY_PATH``) and if not, 33 | running ``source /opt/qt54/bin/qt54-env.sh`` will set the variables for 34 | the current session. 35 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Database.rst: -------------------------------------------------------------------------------- 1 | Go Ethereum database 2 | 3 | :: 4 | 5 | "PV" : Number // The protocol version this database is compatible with. 6 | "LTD" : Number // The highest known total difficulty 7 | 8 | **Please note, all entries are arbitrary length byte arrays.** 9 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Ethereum-Specification.rst: -------------------------------------------------------------------------------- 1 | Specifications of all Ethereum technologies, languages, protocols, etc. 2 | 3 | Whitepapers and design rationale 4 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5 | 6 | - `Ethereum 7 | Whitepaper `__ 8 | - `Design 9 | Rationale `__ 10 | - `Ethereum Yellow Paper `__ 11 | - `ÐΞVp2p 12 | Whitepaper `__ 13 | (WiP) 14 | - `Ethash `__ 15 | 16 | Specs 17 | ~~~~~ 18 | 19 | - `JavaScript 20 | API `__ 21 | - `Generic JSON RPC `__ 22 | - [JSRE admin 23 | API](https://github.com/ethereum/go-ethereum/wiki/JavaScript-Console#console-api 24 | - `RLP `__ 25 | - `ÐΞVp2p Wire 26 | Protocol `__ 27 | - `Web3 Secret 28 | Storage `__ 29 | - `Patricia 30 | Tree `__ 31 | - `Wire 32 | protocol `__ 33 | - `Light client 34 | protocol `__ 35 | - `Solidity, Docs & 36 | ABI `__ 37 | - `NatSpec `__ 38 | - `Contract 39 | ABI `__ 40 | - `Ethash `__ 41 | - `Ethash C API `__ 42 | - `Ethash DAG `__ 43 | - `ICAP: Inter-exchange Client Address 44 | Protocol `__ 45 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/FAQ.rst: -------------------------------------------------------------------------------- 1 | -------------- 2 | 3 | **Q.** I noticed my peercount slowly decrease, and now it is at 0. 4 | Restarting doesn't get any peers. 5 | 6 | **A.** Check and sync your clock with ntp. 7 | `Example `__ 8 | ``sudo ntpdate -s time.nist.gov`` 9 | 10 | -------------- 11 | 12 | **Q.** I would like to run multiple geth instances but got the error 13 | "Fatal: blockchain db err: resource temporarily unavailable". 14 | 15 | **A.** Geth uses a datadir to store the blockchain, accounts and some 16 | additional information. This directory cannot be shared between running 17 | instances. If you would like to run multiple instances follow 18 | `these `__ 19 | instructions. 20 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Gas-Price-Oracle.rst: -------------------------------------------------------------------------------- 1 | The gas price oracle is a helper function of the Geth client that tries 2 | to find an appropriate default gas price when sending transactions. It 3 | can be parametrized with the following command line options: 4 | 5 | - gpomin: lower limit of suggested gas price. This should be set at 6 | least as high as the "gasprice" setting usually used by miners so 7 | that your transactions will not be rejected automatically because of 8 | a too low price. 9 | 10 | - gpomax: higher limit of suggested gas price. During load peaks when 11 | there is a competition between transactions to get into the blocks, 12 | the price needs to be limited, otherwise the oracle would eventually 13 | try to overbid everyone else at any price. 14 | 15 | - gpofull: a block is considered "full" when a certain percentage of 16 | the block gas limit (specified in percents) is used up by 17 | transactions. If a block is not "full", that means that a transaction 18 | could have been accepted even with a minimal price offered. 19 | 20 | - gpobasedown: an exponential ratio (specified in 1/1000ths) by which 21 | the base price decreases when the lowest acceptable price of the last 22 | block is below the last base price. 23 | 24 | - gpobaseup: an exponential ratio (specified in 1/1000ths) by which the 25 | base price increases when the lowest acceptable price of the last 26 | block is over the last base price. 27 | 28 | - gpobasecf: a correction factor (specified in percents) of the base 29 | price. The suggested price is the corrected base price, limited by 30 | gpomin and gpomax. 31 | 32 | The lowest acceptable price is defined as a price that could have been 33 | enough to insert a transaction into a certain block. Although this value 34 | varies slightly with the gas used by the particular transaction, it is 35 | aproximated as follows: if the block is full, it is the lowest 36 | transaction gas price found in that block. If the block is not full, it 37 | equals to gpomin. 38 | 39 | The base price is a moving value that is adjusted from block to block, 40 | up if if was lower than the lowest acceptable price, down otherwise. 41 | Note that there is a slight amount of randomness added to the correction 42 | factors so that your client will not behave absolutely predictable on 43 | the market. 44 | 45 | If you want to specify a constant for the default gas price and not use 46 | the oracle, set both gpomin and gpomax to the same value. 47 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Getting-Geth.rst: -------------------------------------------------------------------------------- 1 | Getting Geth 2 | ============ 3 | 4 | The Frontier tool is called Geth (the old english third person singular 5 | conjugation of "to go". Quite appropriate given geth is written in 6 | `Go `__. Geth is a multipurpose command line tool 7 | that runs a full Ethereum node implemented in Go. It offers three 8 | interfaces: the `command line subcommands and 9 | options <./Command-Line-Options>`__, a Json-rpc server and an 10 | interactive console. 11 | 12 | In order to install Geth, open a command line or terminal tool (if you 13 | are unsure how to do this, consider waiting for a more user friendly 14 | release) and paste the command below: 15 | 16 | :: 17 | 18 | bash <(curl https://install-geth.ethereum.org) 19 | 20 | This script will detect your OS and will attempt to install the Ethereum 21 | CLI. For more options including package managers, check the OS-specific 22 | subsections. 23 | 24 | First run 25 | --------- 26 | 27 | For the purposes of this guide, we will focus on the interactive 28 | console, a JavaScript environment. The history of the console is 29 | persisted between sessions, providing for a powerful and flexible way of 30 | using the client. You can navigate your command history by using the up 31 | and down arrow keys, like a standard command line. To get started Type 32 | the code below on your terminal 33 | 34 | :: 35 | 36 | geth console 37 | 38 | Once geth is fully started, you should see a ``>`` prompt, letting you 39 | know the console is ready. To exit, type ``exit`` at the prompt and hit 40 | ``[enter]``. 41 | 42 | Using stderr 43 | ~~~~~~~~~~~~ 44 | 45 | Output from the console can be logged or redirected: 46 | 47 | ``geth console 2>>geth.log`` 48 | 49 | Using standard tools, the log can be monitored in a separate window: 50 | 51 | ``tail -f geth.log`` 52 | 53 | Alternatively, you can also run one terminal with the interactive 54 | console and a second one with the logging output directly. 55 | 56 | 1. Open two terminals 57 | 2. In the **second** terminal type ``tty``. The output will be something 58 | like ``/dev/pts/13`` 59 | 3. In your main terminal, type: ``geth console 2>> /dev/pts/13`` 60 | 61 | This will allow you to monitor your node without cluttering the 62 | interactive console. 63 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Home.rst: -------------------------------------------------------------------------------- 1 | - User documentation can be found at our `Ethereum User Guide and 2 | reference 3 | manual `__. 4 | - For the API reference and developer documentation head over to the 5 | auto generated 6 | `GoDoc `__ 7 | documentation. 8 | 9 | This is the Wiki for the official Ethereum golang implementation. For 10 | generic Ethereum-related information (whitepaper, yellow paper, protocol 11 | and interface specs, APIs, dapp development guides, etc) see the 12 | `Ethereum main wiki `__. 13 | 14 | Main entry points: 15 | 16 | - `Bitchin' 17 | Tricks `__ 18 | - `Ethereum Frontier 19 | Release `__ 20 | - `Installation 21 | Instructions `__ 22 | - `Managing 23 | Accounts `__ 24 | - `Command Line 25 | Options `__ 26 | - `JavaScript 27 | Console `__ 28 | - `Setting up private network or local 29 | cluster `__ 30 | - `Developers' 31 | Guide `__ 32 | 33 | Sidebar lists all pages. 34 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Installation-Instructions-for-ARM.rst: -------------------------------------------------------------------------------- 1 | Installation Instructions for ARM 2 | ================================= 3 | 4 | Geth is built for ARM using cross-compilation. See `Cross compiling 5 | Ethereum `__ 6 | for more details. 7 | 8 | RasPi 2 9 | ------- 10 | 11 | 1. Download the `precompiled binary from master 12 | branch `__ 13 | 2. Copy it to a location in $PATH (i.e. /usr/bin/local) 14 | 3. Run ``geth`` 15 | 16 | Further details: 17 | https://github.com/ethereum/wiki/wiki/Raspberry-Pi-instructions 18 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Installation-Instructions-for-Arch.rst: -------------------------------------------------------------------------------- 1 | Installing from source 2 | ---------------------- 3 | 4 | Install dependencies 5 | 6 | .. code:: shell 7 | 8 | pacman -S git go gcc gmp 9 | 10 | Download and build geth 11 | 12 | .. code:: shell 13 | 14 | git clone https://github.com/ethereum/go-ethereum 15 | cd go-ethereum 16 | make geth 17 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Installation-Instructions-for-FreeBSD.rst: -------------------------------------------------------------------------------- 1 | Building from source 2 | -------------------- 3 | 4 | Building Geth (command line client) 5 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 | 7 | Clone the repository to a directory of your choosing: 8 | 9 | .. code:: shell 10 | 11 | git clone https://github.com/ethereum/go-ethereum 12 | 13 | Building ``geth`` requires some external libraries to be installed: 14 | 15 | - `GMP `__ 16 | - `Go `__ 17 | 18 | .. code:: shell 19 | 20 | pkg install gmp go 21 | 22 | If your golang version is >= 1.5, build the ``geth`` program using the 23 | following command. 24 | 25 | .. code:: shell 26 | 27 | cd go-ethereum 28 | make geth 29 | 30 | If your golang version is < 1.5 (quarterly packages, for example), use 31 | the following command instead. 32 | 33 | .. code:: shell 34 | 35 | cd go-ethereum 36 | CC=clang make geth 37 | 38 | You can now run ``build/bin/geth`` to start your node. 39 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Installation-Instructions-for-Mac.rst: -------------------------------------------------------------------------------- 1 | Installing with Homebrew 2 | ------------------------ 3 | 4 | By far the easiest way to install go-ethereum is to use our Homebrew 5 | tap. If you don't have Homebrew, `install it first `__. 6 | 7 | Then run the following commands to add the tap and install ``geth``: 8 | 9 | .. code:: shell 10 | 11 | brew tap ethereum/ethereum 12 | brew install ethereum 13 | 14 | You can install the develop branch by running ``--devel``: 15 | 16 | .. code:: shell 17 | 18 | brew install ethereum --devel 19 | 20 | After installing, run ``geth account new`` to create an account on your 21 | node. 22 | 23 | You should now be able to run ``geth`` and connect to the network. 24 | 25 | Make sure to check the different options and commands with 26 | ``geth --help`` 27 | 28 | For options and patches, see: 29 | https://github.com/ethereum/homebrew-ethereum 30 | 31 | Building from source 32 | -------------------- 33 | 34 | Building Geth (command line client) 35 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36 | 37 | Clone the repository to a directory of your choosing: 38 | 39 | .. code:: shell 40 | 41 | git clone https://github.com/ethereum/go-ethereum 42 | 43 | Building ``geth`` requires some external libraries to be installed: 44 | 45 | - `GMP `__ 46 | - `Go `__ 47 | 48 | .. code:: shell 49 | 50 | brew install gmp go 51 | 52 | Finally, build the ``geth`` program using the following command. 53 | 54 | .. code:: shell 55 | 56 | cd go-ethereum 57 | make geth 58 | 59 | You can now run ``build/bin/geth`` to start your node. 60 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Installation-Instructions-for-Ubuntu.rst: -------------------------------------------------------------------------------- 1 | Installing from PPA 2 | ------------------- 3 | 4 | For the latest development snapshot, both ``ppa:ethereum/ethereum`` and 5 | ``ppa:ethereum/ethereum-dev`` are needed. If you want the stable version 6 | from the last PoC release, add only the first one. 7 | 8 | .. code:: shell 9 | 10 | sudo apt-get install software-properties-common 11 | sudo add-apt-repository -y ppa:ethereum/ethereum 12 | sudo add-apt-repository -y ppa:ethereum/ethereum-dev 13 | sudo apt-get update 14 | sudo apt-get install ethereum 15 | 16 | After installing, run ``geth account new`` to create an account on your 17 | node. 18 | 19 | You should now be able to run ``geth`` and connect to the network. 20 | 21 | Make sure to check the different options and commands with 22 | ``geth --help`` 23 | 24 | You can alternatively install only the ``geth`` CLI with 25 | ``apt-get install geth`` if you don't want to install the other 26 | utilities (``bootnode``, ``evm``, ``disasm``, ``rlpdump``, ``ethtest``). 27 | 28 | Building from source 29 | -------------------- 30 | 31 | Building Geth (command line client) 32 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 33 | 34 | Clone the repository to a directory of your choosing: 35 | 36 | .. code:: shell 37 | 38 | git clone https://github.com/ethereum/go-ethereum 39 | 40 | Install latest distribution of Go (v1.4) if you don't have it already: 41 | 42 | `See 43 | instructions `__ 44 | 45 | Building ``geth`` requires some external libraries to be installed: 46 | 47 | .. code:: shell 48 | 49 | sudo apt-get install -y build-essential libgmp3-dev golang 50 | 51 | Finally, build the ``geth`` program using the following command. 52 | 53 | .. code:: shell 54 | 55 | cd go-ethereum 56 | make geth 57 | 58 | You can now run ``build/bin/geth`` to start your node. 59 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Installation-instructions-for-Windows.rst: -------------------------------------------------------------------------------- 1 | Binaries 2 | ======== 3 | 4 | Download stable binaries 5 | ------------------------ 6 | 7 | All versions of Geth are built and available for download at 8 | https://build.ethereum.org/builds/Windows%20Go%20master%20branch/. The 9 | latest version is always available as 10 | `Geth-Win64-latest.zip `__ 11 | 12 | 1. Download zip file 13 | 2. Extract geth.exe from zip 14 | 3. Open a command terminal 15 | 4. chdir 16 | 5. open geth.exe 17 | 18 | [STRIKEOUT:Installing from Chocolatey] 19 | -------------------------------------- 20 | 21 | ***Note: Chocolatey is stuck at 1.2.2 and deprecated. Consider using 22 | another method*** 23 | 24 | For master branch: 25 | 26 | :: 27 | 28 | choco install geth-stable 29 | 30 | *For more information see https://chocolatey.org/packages/geth-stable* 31 | 32 | For develop branch: 33 | 34 | :: 35 | 36 | choco install geth-latest 37 | 38 | *For more information see https://chocolatey.org/packages/geth-latest* 39 | 40 | Source 41 | ====== 42 | 43 | Powershell script for building with Cygwin 44 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45 | 46 | geth < 1.4.0 (MSYS2/GMP dependency): 47 | https://gist.github.com/tgerring/b93057e06960d906574c 48 | 49 | geth >= 1.4.0 (Cygwin/MingW): 50 | https://gist.github.com/tgerring/79f018954aadfb3f406e 51 | 52 | Building from source with winbuilds 53 | ----------------------------------- 54 | 55 | 1. Install Git from http://git-scm.com/downloads 56 | 2. Install Golang from 57 | https://storage.googleapis.com/golang/go1.4.2.windows-amd64.msi 58 | 3. Install winbuilds from 59 | http://win-builds.org/1.5.0/win-builds-1.5.0.exe to ``c:\winbuilds`` 60 | 4. Run win builds here. It's safe to remove big dependencies like QT 61 | and GTK which aren't needed. *An exact list of dependencies should 62 | be determined* 63 | 5. Setup environment paths 64 | 6. Add ``GOROOT`` pointed to ``c:\go`` and ``GOPATH`` to ``c:\godev`` 65 | (you are free to pick these paths). 66 | 7. Set ``PATH`` to 67 | ``%PATH%;%GOROOT%\bin;%GOPATH%\bin;c:\winbuilds\bin`` 68 | 8. Open a terminal and install godep first: 69 | ``go get -u github.com/tools/godep`` 70 | 9. Open a terminal and download go-ethereum 71 | ``go get -d -u github.com/ethereum/go-ethereum`` 72 | 10. Try building ethereum with go dep, navigate to 73 | ``c:\godev\src\github.com\ethereum\go-ethereum\cmd\geth`` and run 74 | ``git checkout develop && godep go install`` 75 | 76 | If you want to build from an other branch bypass ``godep go install`` 77 | for ``go install`` and checkout the dependencies manually. 78 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Installing-Go.rst: -------------------------------------------------------------------------------- 1 | Windows 2 | ~~~~~~~ 3 | 4 | Download and run the installer found at http://golang.org/doc/install 5 | 6 | OS X 7 | ~~~~ 8 | 9 | Download an install the darwin binary from https://golang.org/dl/ 10 | 11 | Linux 12 | ~~~~~ 13 | 14 | Ubuntu 14.04 15 | ^^^^^^^^^^^^ 16 | 17 | The apt-get repositories for 14.04 contain golang 1.2.1. Version 1.4.2 18 | is required, so you can download directly (as above). Alternatively, you 19 | can `add the ethereum apt 20 | repository `__, 21 | which hosts golang 1.4.2. Then you can use 22 | ``sudo apt-get install golang`` to install. You will still have to set 23 | the $GOPATH and $PATH variables as specified below. 24 | 25 | If you are getting 'error 2' when building Geth or 'expected target' 26 | errors, it's because you compiled geth while using Go 1.3.x. Run 'make 27 | clean' in the go-ethereum folder then run 'make geth' again to solve the 28 | issue. 29 | 30 | Other distros 31 | ^^^^^^^^^^^^^ 32 | 33 | Download the latest distribution 34 | 35 | ``curl -O https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz`` 36 | 37 | Unpack it to the ``/usr/local`` (might require sudo) 38 | 39 | ``tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz`` 40 | 41 | Set GOPATH and PATH 42 | ^^^^^^^^^^^^^^^^^^^ 43 | 44 | For Go to work properly, you need to set the following two environment 45 | variables: 46 | 47 | - Setup a go folder 48 | ``mkdir -p ~/go; echo "export GOPATH=$HOME/go" >> ~/.bashrc`` 49 | - Update your path 50 | ``echo "export PATH=$PATH:$HOME/go/bin:/usr/local/go/bin" >> ~/.bashrc`` 51 | - Read the environment variables into current session: 52 | ``source ~/.bashrc`` 53 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Legacy.rst: -------------------------------------------------------------------------------- 1 | Legacy 2 | ------ 3 | 4 | - `iceCREAM `__ 5 | 6 | - `eth-go `__: 7 | An introduction which will help you bootstrap your own, native, Go 8 | Ethereum application. 9 | 10 | Mutan 11 | ~~~~~ 12 | 13 | `Mutan 0.5 14 | Examples `__ 15 | 16 | `Mutan 0.4 17 | Examples `__ 18 | 19 | `Mutan 0.4 `__ 20 | 21 | `Mutan 0.2 `__ 22 | 23 | `Mutan 0.2 24 | Example `__ 25 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Mist-build-instructions-for-Mac.rst: -------------------------------------------------------------------------------- 1 | Building Mist (GUI) 2 | ~~~~~~~~~~~~~~~~~~~ 3 | 4 | **Note: Mist is currently a work in progress and might not always 5 | work.** 6 | 7 | Clone the repository to a directory of your choosing: 8 | 9 | .. code:: shell 10 | 11 | git clone https://github.com/ethereum/go-ethereum 12 | 13 | Building ``mist`` requires some external libraries to be installed: 14 | 15 | - `GMP `__ 16 | - `Qt 5 `__ 17 | - `Qt 5 WebEngine `__ 18 | - `Go `__ 19 | 20 | Install these first: 21 | 22 | .. code:: shell 23 | 24 | brew install gmp go qt5 25 | brew link -f qt5 # This is required, sorry. 26 | 27 | Finally, build the ``mist`` program using the following commands: 28 | 29 | .. code:: shell 30 | 31 | cd go-ethereum 32 | make mist 33 | 34 | Mist does not automatically look in the right location for its GUI 35 | assets. You can set the asset path on the command line. 36 | 37 | .. code:: shell 38 | 39 | build/bin/mist --asset_path cmd/mist/assets 40 | 41 | Or launch it from its source directory instead: 42 | 43 | .. code:: shell 44 | 45 | cd cmd/mist 46 | ../../build/bin/mist 47 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Multi-protocol-peer-selection.rst: -------------------------------------------------------------------------------- 1 | In order for the network emerging from the peer selection algorithm in 2 | p2p package to support multiple protocols that might require routing, 3 | such as Swarm, the known node set must satisfy the following properties: 4 | \* Peers should make it known which protocols they support (as a list of 5 | identifiers) \* In each row of the Kademlia table, there should be a 6 | sufficient number (as defined by the redundancy requirement *k*, which 7 | might be distinct for each protocol) of node supporting *each* of the 8 | protocols which the host itself supports. 9 | 10 | The second requirement is achieved by maintaining distinct redundancy 11 | limits *k*\ \ *p*\ for each protocol *p*, with nodes supporting 12 | multiple protocols counting towards the corresponding limits for each of 13 | them. 14 | 15 | Thus, even nodes that do not support a specific protocol can help other 16 | nodes in search of peers that do support it. 17 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Mutan-0.2-Example.rst: -------------------------------------------------------------------------------- 1 | Currency 2 | -------- 3 | 4 | .. code:: go 5 | 6 | this.store[this.origin()] = 10**20 7 | 8 | exit compile { 9 | var to = this.data[0] 10 | var from = this.origin() 11 | var value = this.data[1] 12 | 13 | if this.store[from] > value { 14 | this.store[from] = this.store[from] - value 15 | this.store[to] = this.store[to] + value 16 | } 17 | } 18 | 19 | Life Insurance 20 | -------------- 21 | 22 | \`\`\`go #define CLAIMER 0xd766c288f24b91ae9781fe2b155d3260b8674c62 23 | this.store[1000] = this.origin() 24 | 25 | func heartbeat() var { if this.store[1000] == this.origin() { 26 | this.store[1002] = this.time() return true } else { if this.time() > 27 | this.store[1002] - 2592000 { return false } else { return true } } } 28 | 29 | func claim() var { if this.origin() == CLAIMER { h := heartbeat() if h 30 | == false { transact(CLAIMER, this.balance(), nil) return true } else { 31 | return false } } } 32 | 33 | func withdraw(var amount, var address) var { if this.store[1000] == 34 | this.origin() { h := heartbeat() if h == true { return transact(address, 35 | amount, nil) } else { return false } } } 36 | 37 | func run() { if this.store[1000] == this.origin() { if this.data[0] == 38 | "heartbeat" { h := heartbeat() return h } else { address := this.data[1] 39 | amount := this.data[2] return withdraw(address, amount) } } 40 | 41 | :: 42 | 43 | if this.origin() == CLAIMER { 44 | if this.data[0] == "claim" { 45 | c := claim() 46 | return c 47 | } else { 48 | return false 49 | } 50 | } 51 | 52 | } run() 53 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Private-network.rst: -------------------------------------------------------------------------------- 1 | Setting up a private network using Geth is relatively easy and 2 | straightforward. Geth allows you to operate on multiple chains, although 3 | not at the same time. It does so by allowing different genesis block to 4 | be inserted in to the database. The only thing you need to do when 5 | switching between chains is give up the path to the genesis block file 6 | (in a later version of Geth a hash will suffice when it has previously 7 | been imported). 8 | 9 | To set up and import a new genesis block please fetch an 10 | `example `__ genesis block. You are 11 | free to add any accounts to this block by inserting it within the 12 | ``alloc`` object: 13 | 14 | :: 15 | 16 | "alloc": { 17 | "0xaddress": { "balance": "amount denoted in Wei" } 18 | } 19 | 20 | Now start Geth with the genesis flag pointing to the genesis file 21 | ``geth --genesis /path/to/file``. This will import and set the canonical 22 | genesis block for your chain or switches to a different previous imports 23 | chain. 24 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Provisional-JS-API.rst: -------------------------------------------------------------------------------- 1 | The *provisional* JavaScript API is a purposed API for all things 2 | JavaScript. JavaScript technologies can be embedded within Qt(QML) 3 | technologies, local web and remote web and therefor the purposed API is 4 | written in a ASYNC fashion so that it may be used across all 5 | implementations. Hereby it should be known that all functions, unless 6 | explicitly specified, take a callback as last function argument which 7 | will be called when the operation has been completed. 8 | 9 | Please note that the provisional JavaScript API tries to leverage 10 | existing JS idioms as much as possible. 11 | 12 | General API 13 | ----------- 14 | 15 | - ``getBlock (number or string)`` Retrieves a block by either the 16 | address or the number. If supplied with a string it will assume 17 | address, number otherwise. 18 | - ``transact (sec, recipient, value, gas, gas price, data)`` Creates a 19 | new transaction using your current key. 20 | - ``create (sec, value, gas, gas price, init, body)`` Creates a new 21 | contract using your current key. 22 | - ``getKey (none)`` Retrieves your current key in hex format. 23 | - ``getStorage (object address, storage address)`` Retrieves the 24 | storage address of the given object. 25 | - ``getBalance (object address)`` Retrieves the balance at the current 26 | address 27 | - ``watch (string [, string])`` Watches for changes on a specific 28 | address' state object such as state root changes or value changes. 29 | - ``disconnect (string [, string])`` Disconnects from a previous 30 | ``watched`` address. 31 | 32 | Events 33 | ------ 34 | 35 | The provisional JavaScript API exposes certain events through a basic 36 | eventing mechanism inspired by jQuery. 37 | 38 | - ``on (event)`` Subscribe to event which will be called whenever an 39 | event of type is received. 40 | - ``off (event)`` Unsubscribe to the given event 41 | - ``trigger (event, data)`` Trigger event of type with the given data. 42 | **note:** This function does not take a callback function. 43 | 44 | Event Types 45 | ~~~~~~~~~~~ 46 | 47 | All events are written in camel cased style beginning with a lowercase 48 | letter. Subevents are denoted by a colon ``:``. 49 | 50 | - ``block:new`` Fired when a new valid block has been found on the 51 | wire. The attached value of this call is a block. 52 | - ``object:changed`` Fired when a watched address, specified through 53 | ``watch``, changes in value. 54 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/RLPx-----Node-Discovery-Protocol.rst: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/old-docs-for-reference/go-ethereum-wiki.rst/RLPx-----Node-Discovery-Protocol.rst -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/RLPx-Peer-Selection-Proposal.rst: -------------------------------------------------------------------------------- 1 | **This is a proposal about how we to select peers using the discovery 2 | protocol. It is not implemented yet.** 3 | 4 | In this strategy the maximum number of active peers is ``N * 2``, where 5 | ``N`` is configurable and should typically be ``5 <= N <= 8``. 6 | 7 | Finding peers to dial 8 | --------------------- 9 | 10 | The 512 bit (256 bit) space is divided into ``N`` ranges. The dialer 11 | maintains ``N`` slots, one for each range. 12 | 13 | In order to find peers, it performs a node lookup with a random target 14 | in reach range corresponding to an empty slot. The results of the lookup 15 | are then dialed. If dialing does not succeed for any node, another 16 | random lookup is performed in that range. Dialed addresses should be 17 | cached for some amount of time to avoid re-dialing unreachable nodes 18 | pointlessly. 19 | 20 | Handling incoming connections 21 | ----------------------------- 22 | 23 | Again, the 512 bit (256 bit) space is divided into ``N`` ranges. The 24 | listener maintains ``N`` buckets, one for each range. 25 | 26 | For an incoming connection, after the remote identity has been verified 27 | in the handshake, the listener should keep the new peer if the 28 | corresponding bucket is empty or if the total number of inbound peers is 29 | less than ``N``. 30 | 31 | When the number of inbound peers reaches ``N``, the new connection 32 | replaces a random existing connection from any bucket with more than one 33 | entry. 34 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Running-in-Docker.rst: -------------------------------------------------------------------------------- 1 | Running in Docker 2 | ================= 3 | 4 | We keep a Docker image with recent snapshot builds from the ``develop`` 5 | branch `on 6 | DockerHub `__. Run 7 | this first: 8 | 9 | .. code:: shell 10 | 11 | docker pull ethereum/client-go 12 | 13 | Start a node with: 14 | 15 | .. code:: shell 16 | 17 | docker run -it -p 30303:30303 ethereum/client-go 18 | 19 | To start a node that runs the JSON-RPC interface on port **8545**, run: 20 | 21 | .. code:: shell 22 | 23 | docker run -it -p 8545:8545 -p 30303:30303 ethereum/client-go --rpc --rpcaddr "0.0.0.0" 24 | 25 | **WARNING: This opens your container to external calls. "0.0.0.0" should 26 | *not* be used when exposed to public networks** 27 | 28 | To use the interactive JavaScript console, run: 29 | 30 | .. code:: shell 31 | 32 | docker run -it -p 30303:30303 ethereum/client-go console 33 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Sending-ether.rst: -------------------------------------------------------------------------------- 1 | Sending ether 2 | ============= 3 | 4 | The basic way of sending a simple transaction of ether using the console 5 | is as follows: 6 | 7 | .. code:: javascript 8 | 9 | > eth.sendTransaction({from:sender, to:receiver, value: amount}) 10 | 11 | Using the built-in JavaScript, you can easily set variables to hold 12 | these values. For example: 13 | 14 | .. code:: javascript 15 | 16 | > var sender = eth.accounts[0]; 17 | > var receiver = eth.accounts[1]; 18 | > var amount = web3.toWei(0.01, "ether") 19 | 20 | Alternatively, you can compose a transaction in a single line with: 21 | 22 | .. code:: javascript 23 | 24 | > eth.sendTransaction({from:eth.coinbase, to:eth.accounts[1], value: web3.toWei(0.05, "ether")}) 25 | Please unlock account d1ade25ccd3d550a7eb532ac759cac7be09c2719. 26 | Passphrase: 27 | Account is now unlocked for this session. 28 | '0xeeb66b211e7d9be55232ed70c2ebb1bcc5d5fd9ed01d876fac5cff45b5bf8bf4' 29 | 30 | The resulting transaction is 31 | ``0xeeb66b211e7d9be55232ed70c2ebb1bcc5d5fd9ed01d876fac5cff45b5bf8bf4`` 32 | 33 | If the password was incorrect you will instead receive an error: 34 | 35 | .. code:: javascript 36 | 37 | error: could not unlock sender account 38 | 39 | TODO: Do these console commands work in both geth and eth? What about other client commands? 40 | TODO: Explain unlocking account or cross reference to section that highlights risks -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Setting-up-Ethereum-(Native).rst: -------------------------------------------------------------------------------- 1 | Dream API 2 | --------- 3 | 4 | i.e., something I'm envisioning for *soon*\ (tm) 5 | 6 | .. code:: go 7 | 8 | eth, err := eth.New(/*config*/) 9 | if err != nil { 10 | logger.Fatalln(err) 11 | } 12 | 13 | // State holds accounts without matching private keys 14 | state := eth.State() 15 | // wallet holds accounts with matching private keys 16 | wallet := eth.Wallet() 17 | wallet.NewAccount() // create a new account (return Account) 18 | wallet.Accounts() // return []Account 19 | 20 | acc := wallet.GetAcccount(0) // Get first account (return Account) 21 | to := state.GetAccount(toAddr) 22 | // Transact from the account 23 | err := acc.Transact(to, big(100), big(10000), big(500), big(util.DefaultGasPrice), nil) 24 | if err != nil { 25 | logger.Fatalln(err) 26 | } 27 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Setting-up-monitoring-on-local-cluster.rst: -------------------------------------------------------------------------------- 1 | This page describes how to set up a monitoring site, `like this 2 | one `__, for your private network. 3 | It builds upon `this wiki 4 | article `__ 5 | and assumes you've created a local cluster using `this script 6 | (gethcluster.sh) `__. 7 | 8 | The monitoring system consists of two components: 9 | 10 | 1. **eth-netstats** - the monitoring site which lists the nodes. 11 | 2. **eth-net-intelligence-api** - these are processes that communicate 12 | with the Ethereum client using RPC and push the data to the 13 | monitoring site via websockets. 14 | 15 | Monitoring site 16 | =============== 17 | 18 | Clone the repo and install dependencies: 19 | 20 | :: 21 | 22 | git clone https://github.com/cubedro/eth-netstats 23 | cd eth-netstats 24 | npm install 25 | 26 | Then choose a secret and start the app: 27 | 28 | :: 29 | 30 | WS_SECRET= npm start 31 | 32 | You can now access the (empty) monitoring site at 33 | ``http://localhost:3000``. 34 | 35 | You can also choose a different port: 36 | 37 | :: 38 | 39 | PORT= WS_SECRET= npm start 40 | 41 | Client-side information relays 42 | ============================== 43 | 44 | These processes will relay the information from each of your cluster 45 | nodes to the monitoring site using websockets. 46 | 47 | Clone the repo, install dependencies and make sure you have pm2 48 | installed: 49 | 50 | :: 51 | 52 | git clone https://github.com/cubedro/eth-net-intelligence-api 53 | cd eth-net-intelligence-api 54 | npm install 55 | sudo npm install -g pm2 56 | 57 | Now, use `this script 58 | (netstatconf.sh) `__ to create 59 | an ``app.json`` suitable for pm2. 60 | 61 | Usage: 62 | 63 | :: 64 | 65 | bash netstatconf.sh 66 | 67 | - ``number_of_clusters`` is the number of nodes in the cluster. 68 | - ``name_prefix`` is a prefix for the node names as will appear in the 69 | listing. 70 | - ``ws_server`` is the eth-netstats server. Make sure you write the 71 | full URL, for example: http://localhost:3000. 72 | - ``ws_secret`` is the eth-netstats secret. 73 | 74 | For example: 75 | 76 | :: 77 | 78 | bash netstatconf.sh 5 mynode http://localhost:3000 big-secret > app.json 79 | 80 | Run the script and copy the resulting ``app.json`` into the 81 | ``eth-net-intelligence-api`` directory. Afterwards, ``cd`` into 82 | ``eth-net-intelligence-api`` and run the relays using 83 | ``pm2 start app.json``. To stop the relays, you can use 84 | ``pm2 delete app.json``. 85 | 86 | **NOTE**: The script assumes the nodes have RPC ports 8101, 8102, ... . 87 | If that's not the case, edit app.json and change it accordingly for each 88 | peer. 89 | 90 | At this point, open ``http://localhost:3000`` and your monitoring site 91 | should monitor all your nodes! 92 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Swarm-Contract.rst: -------------------------------------------------------------------------------- 1 | This one contract regulates the incentive structure of Swarm. 2 | 3 | The corresponding solidity code can be browsed 4 | `here `__. 5 | 6 | Methods 7 | ======= 8 | 9 | Sign up as a node 10 | ----------------- 11 | 12 | Pay a deposit in Ether and register public key. Comes with an accessor 13 | for checking that a node is signed up. 14 | 15 | Demand penalty for loss of chunk 16 | -------------------------------- 17 | 18 | Present a signed receipt by a signed up node and a deposit covering the 19 | upload of a chunk. After a given deadline, the signer node's deposit is 20 | taken and the presenting node's deposit refunded, unless the chunk is 21 | presented. Comes with an accessor for checking that a given chunk has 22 | been reported lost, so that holders of receipts by other swarm nodes can 23 | punish them as well for losing the chunk, which, in turn, incentivizes 24 | whoever holds the chunk to present it. 25 | 26 | Present chunk to avoid penalty 27 | ------------------------------ 28 | 29 | No penalty is paid for lost chunks, if chunk is presented within the 30 | deadline. The cost of uploading the chunk is compensated exactly from 31 | the demand's deposit, with the remainder refunded. Comes with an 32 | accessor for checking that a given node is liable for penalty, so the 33 | node is notified to present the chunk in a timely fashion. 34 | 35 | Price considerations 36 | ==================== 37 | 38 | For the price of accepting a chunk for storing, see 39 | `Incentives `__ 40 | 41 | This price should be proportional to the sign-up deposit of the swarm 42 | node. 43 | 44 | The deposit for compensating the swarm node for uploading the chunk into 45 | the block chain should be substantially higher (e.g. a small integer 46 | multiple) of the corresponding upload measured with the gas price used 47 | to upload the demand to prevent DoS attacks. 48 | 49 | Termination 50 | =========== 51 | 52 | Users of Swarm should be able to count on the loss of deposit as a 53 | disincentive, so it should not be refunded before the term of Swarm 54 | membership expires. If penalites were paid out as compensation to 55 | holders of receipts of lost chunks, it would provide an avenue of early 56 | exit for a Swarm member by "losing" chunks deposited by colluding users. 57 | Since users of Swarm are interested in their information being reliably 58 | stored, their primary incentive for keeping the receipts is to keep the 59 | Swarm motivated, not the potential compensation. 60 | 61 | Receipt circulation 62 | =================== 63 | 64 | End-users of Swarm keeping important information in it are obviously 65 | interested in keeping as many receipts of it as possible available for 66 | "litigation". The storage space required for storing a receipt is a 67 | sizable fraction of that used for storing the information itself, so end 68 | users can reduce their storage requirement further by storing the 69 | receipts in Swarm as well. Doing this recursively would result in end 70 | users only having to store a single receipt, yet being able to penalize 71 | quite a few Swarm nodes, in case only a small part of their stored 72 | information is lost. 73 | 74 | Swarm nodes that use the rest of Swarm as a backup may want to propagate 75 | the receipts in the opposite direction of storage requests, so that the 76 | cost of storing receipts is eventually paid by the end user either in 77 | the form of allocated storage space or as a direct payment to Swarm. 78 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Testing.rst: -------------------------------------------------------------------------------- 1 | Running tests on go-ethereum 2 | ============================ 3 | 4 | This page assumes go-ethereum has been configured according to the 5 | `Developers 6 | Guide `__. 7 | All commands (unless stated otherwise) are assumed to be run from 8 | ``$GOPATH/src/github.com/ethereum/go-ethereum`` 9 | 10 | Unit tests 11 | ---------- 12 | 13 | See `Travis `__ or 14 | `Coveralls `__ for status. 15 | 16 | Test the full codebase locally by changing to the repository directory 17 | and running 18 | 19 | :: 20 | 21 | test ./... 22 | 23 | Integration tests 24 | ----------------- 25 | 26 | Integration tests for Go are included in the ``tests`` directory and can 27 | be run with standard go testing (i.e. ``go test``). To run all the 28 | integration tests simply run: 29 | 30 | :: 31 | 32 | go test ./tests/ 33 | 34 | Ethtest 35 | ~~~~~~~ 36 | 37 | Alternatively, there is a CLI application, ``ethtest`` who can be used 38 | to run these tests without Go. The binary can be built from 39 | ``./cmd/ethtest`` and then run from anywhere (such as the root directory 40 | of the test files). Some examples: 41 | 42 | Run all tests from current directory, looking in their respective sub 43 | directories for json files: ``ethtest`` 44 | 45 | Run all VM json tests from ./VMTests/ directory 46 | ``ethtest --test "vm" --file "./VMTests/"`` 47 | 48 | Run all tests in a cousin directory supplied by environment variable 49 | ``ETHEREUM_TEST_PATH="../../tests/files" ethtest --test "all"`` 50 | 51 | Run a single transaction test 52 | ``ethtest --test "tx" --file "./TransactionTests/ttTransactionTest.json"`` 53 | 54 | Flags: 55 | 56 | :: 57 | 58 | --test "all" Test type (string): VMTests, TransactionTests, StateTests, BlockTests 59 | --file "." Test file or directory. Directories are searched for .json files 1 level deep [$ETHEREUM_TEST_PATH] 60 | --continue Continue running tests on error (true) or exit immediately (false) 61 | 62 | VM 63 | ^^ 64 | 65 | `VM Test wiki `__ 66 | 67 | :: 68 | 69 | go test ./tests/vm_test.go 70 | 71 | State 72 | ^^^^^ 73 | 74 | `State Test wiki `__ 75 | 76 | :: 77 | 78 | go test ./tests/state_test.go 79 | 80 | Transaction 81 | ^^^^^^^^^^^ 82 | 83 | `Transaction Test 84 | wiki `__ 85 | 86 | :: 87 | 88 | go test ./tests/transaction_test.go 89 | 90 | Blockchain 91 | ^^^^^^^^^^ 92 | 93 | `Blockchain Test 94 | wiki `__ 95 | 96 | :: 97 | 98 | go test ./tests/block_test.go 99 | 100 | RPC 101 | ~~~ 102 | 103 | `RPC Tests repo `__ 104 | 105 | 1. Load test JSON with 106 | 107 | :: 108 | 109 | geth blocktest /BlockTests/bcRPC_API_Test.json RPC_API_Test rpc 110 | 111 | 2. Run rpc-tests (https://github.com/ethereum/rpc-tests#usage) 112 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Troubleshooting.rst: -------------------------------------------------------------------------------- 1 | 1603 sync.go:100] Synchronisation failed: peer's unknown or unhealthy 2 | what does it mean? 3 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/Wire-protocol-Extended-(Child-processes).rst: -------------------------------------------------------------------------------- 1 | Ethereum Child processes allow any node to connect to an existing node 2 | and share its parent process to handle all network communication and 3 | data persisting. This will allow for multiple Ethereum light nodes on 4 | the same host with full access to the block chain through the parent 5 | process. 6 | 7 | Message Type 8 | ~~~~~~~~~~~~ 9 | 10 | Intercom messages range from 0x30 - X all messages are specified as 11 | 12 | Get block 13 | ^^^^^^^^^ 14 | 15 | - ``[0x30, [block hash]]`` 16 | - Retrieve the block by hash or empty if block couldn't be found 17 | 18 | Block 19 | ^^^^^ 20 | 21 | - ``[0x31, [block]]`` 22 | - Returns the given block as a reply on ``get block``. 23 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/_Footer.rst: -------------------------------------------------------------------------------- 1 | ``golang <3`` 2 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/_Sidebar.rst: -------------------------------------------------------------------------------- 1 | `Main Ethereum Wiki `__ 2 | 3 | `Frontier 4 | Release `__ 5 | 6 | Install and build 7 | ~~~~~~~~~~~~~~~~~ 8 | 9 | `Installing 10 | Ethereum `__ 11 | 12 | `Developers' 13 | Guide `__ 14 | 15 | Usage 16 | ~~~~~ 17 | 18 | `Managing 19 | Accounts `__ 20 | 21 | `Mining `__ 22 | 23 | `Contracts and 24 | transactions `__ 25 | 26 | `Contract 27 | Tutorial `__ 28 | 29 | Interface Documentation 30 | ~~~~~~~~~~~~~~~~~~~~~~~ 31 | 32 | `Command Line 33 | Options `__ 34 | 35 | `JavaScript 36 | Console `__ 37 | 38 | `Management 39 | API `__ 40 | 41 | `JSON-RPC server `__ 42 | 43 | Issues 44 | ~~~~~~ 45 | 46 | `Troubleshooting `__ 47 | 48 | `FAQ `__ 49 | 50 | `Reporting 51 | issues `__ 52 | 53 | `Community and 54 | support `__ 55 | 56 | Legacy 57 | ~~~~~~ 58 | 59 | `Legacy pages `__ 60 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/bitchin-tricks.rst: -------------------------------------------------------------------------------- 1 | Bitchin' tricks 2 | =============== 3 | 4 | Geth 5 | ~~~~ 6 | 7 | General 8 | ^^^^^^^ 9 | 10 | - My [STRIKEOUT:shit] client doesn't work! :fu: 11 | 12 | :: 13 | 14 | git pull 15 | 16 | Mining 17 | ^^^^^^ 18 | 19 | - I only want to mine when there are transactions! 20 | 21 | .. code:: javascript 22 | 23 | var mining_threads = 1 24 | 25 | function checkWork() { 26 | if (eth.getBlock("pending").transactions.length > 0) { 27 | if (eth.mining) return; 28 | console.log("== Pending transactions! Mining..."); 29 | miner.start(mining_threads); 30 | } else { 31 | miner.stop(0); // This param means nothing 32 | console.log("== No transactions! Mining stopped."); 33 | } 34 | } 35 | 36 | eth.filter("latest", function(err, block) { checkWork(); }); 37 | eth.filter("pending", function(err, block) { checkWork(); }); 38 | 39 | checkWork(); 40 | 41 | Curtesy @chfast 42 | 43 | Quick scripts 44 | ^^^^^^^^^^^^^ 45 | 46 | - I want to get some data out without running a node! 47 | 48 | :: 49 | 50 | $ geth --exec "eth.accounts" console 2>/dev/null 51 | 52 | ["0x0000000000000000000000000000000000000000"] 53 | 54 | - I want to get some data out without RPC magic! 55 | 56 | :: 57 | 58 | $ geth --exec "eth.accounts" attach 59 | 60 | ["0x0000000000000000000000000000000000000000"] 61 | -------------------------------------------------------------------------------- /old-docs-for-reference/go-ethereum-wiki.rst/iceCREAM-(debugger).rst: -------------------------------------------------------------------------------- 1 | **UPDATE** IceCream has been removed as of 0.9.0 in favour of more 2 | advanced other tools. 3 | 4 | Go Ethereum comes with a handy EVM debugger called iceCREAM (after the 5 | famous 'SoftICE' kernel debugger). This article will give you a basic 6 | understanding of debugging EVM code and operating the iceCREAM debugger. 7 | 8 | .. figure:: https://photos-5.dropbox.com/t/0/AACUFqkxJZxCr0S_K-65D8lBwFcD9g2fXj0EM6VK8cosTA/12/4270001/png/1024x768/3/1404478800/0/2/Screenshot%202014-07-04%2013.46.16.png/b0UNfgLTmovpciCPHQwXjDKVM2NEUGG4bUuKDhC3jSk 9 | :alt: 10 | 11 | The interface of the debugger is pretty straight forward and can be 12 | accessed from within 13 | `Ethereal `__ menu (⌘-D) 14 | 15 | - In the centre of the window you'll find the main editor which support 16 | `mutan `__ and `serpent <>`__. 17 | - On the left side you'll find the disassembled instruction sequence. 18 | - Right top corner are pre-made snippets 19 | - Right side you'll find the simulated data field, endowment, amount of 20 | gas & gas price. 21 | - Temp is the VM stack 22 | - Memory is the current in-use memory. Each item is one word (32 bytes) 23 | - Storage inspector 24 | - Debugger CLI 25 | - Debugger log 26 | 27 | The debugger supports ``break`` points on an instruction level (so don't 28 | try to use line numbers). Adding a breakpoint through the debugger CLI 29 | (⌘-L) can be done with ``break ``. When the EVM encounters 30 | a breakpoint it will halt the execution and displays the current state 31 | of the VM such as the current memory, storage and stack, and allows you 32 | to step through the following instructions using the ``next`` button 33 | (⌘-N). 34 | 35 | The debugger supports the following shortcut keys: - ⌘-L Debugger CLI - 36 | ⌘-R Debug run - ⌘-N Next sequence (during break) - ⌘-G Continue (during 37 | break) - ⌘-1 Focus editor - ⌘-2 Focus data 38 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Adaptive-Peer-Time.rst: -------------------------------------------------------------------------------- 1 | Goals 2 | ~~~~~ 3 | 4 | At present, a single mining peer with its clock substantially (> 25% of 5 | the expected block time) ahead of the other peers will cause problems on 6 | the network. Forks are common as peers are inconsistently forced to 7 | ignore the future blocks. 8 | 9 | A system with multiple peers should be robust to a few peers having 10 | substantially fast clocks. 11 | 12 | Basic Overview 13 | ~~~~~~~~~~~~~~ 14 | 15 | Each peer does a ping-sequence, each message timestamped with the 16 | hardware clock (H) directly after handshake to determine both the 17 | network traversal distance ("ping time") and an estimate of the peer's 18 | hardware clock (Hp). 19 | 20 | The clock-offset (D) of the peer then becomes it's hardware clock (H) 21 | corrected to become the median of the peer hardware clocks (median({H1, 22 | H2, ...}) = M). 23 | 24 | The clock offset (D) is dynamically evaluated as the peer set changes. 25 | 26 | Required Changes 27 | ~~~~~~~~~~~~~~~~ 28 | 29 | Protocol changes: \* Ping & Pong packets include a timestamp. 30 | 31 | Rest to be implemented lazily. 32 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Bad-Chain-Canary.rst: -------------------------------------------------------------------------------- 1 | There will be a canary contract to notify that a given chain is bad. 2 | It's very easy to use; check storage location 0 of contract at the given 3 | address (see below). If non-zero, client should not mine (at least 4 | without a non-default option being given to ignore the canary and mine 5 | on a known-bad chain). 6 | 7 | Specifically there are three modes it can be in: 8 | 9 | - ``0`` All fine. Carry on. 10 | - ``1`` Bad chain. Client should not mine on it. Client upgrade not yet 11 | available. 12 | - ``2`` Update required. Just as for ``1``; additionally, an update to 13 | your client is available and would be prudent. 14 | 15 | Clients implementing this protocol should display a message to the user 16 | to make any non-zero status clear. For a status of 2, the user should be 17 | notified than an immediate upgrade is required, regardless of whether 18 | mining is enabled. 19 | 20 | Addresses 21 | ^^^^^^^^^ 22 | 23 | - For Olympic: ``0x6879392ee114f8a4e133f0ff3dc4bc1717fe9344`` 24 | - For Frontier: TBC 25 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Blockchain-import-and-export-instructions.rst: -------------------------------------------------------------------------------- 1 | ***Note:** Binary format is concatenated RLP-encoded blocks* 2 | 3 | C++ 4 | --- 5 | 6 | Import: 7 | ~~~~~~~ 8 | 9 | :: 10 | 11 | eth --import 12 | 13 | *Formats supported: binary* 14 | 15 | Export: 16 | ~~~~~~~ 17 | 18 | :: 19 | 20 | eth --export Myfile --format binary --from 45 --to latest 21 | 22 | *Formats supported: hex (newlines separating), binary or JSON* 23 | ``--from`` and ``--to`` also support blockhashes 24 | 25 | Go 26 | -- 27 | 28 | Import 29 | ~~~~~~ 30 | 31 | :: 32 | 33 | geth import 34 | 35 | *Formats supported: binary* 36 | 37 | Genesis block: 38 | ~~~~~~~~~~~~~~ 39 | 40 | :: 41 | 42 | geth --genesis --genesisnonce 43 | 44 | *Formats supported: json* ### Export 45 | 46 | :: 47 | 48 | geth export 49 | 50 | *Formats supported: binary* ## Python 51 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Brain-Wallet.rst: -------------------------------------------------------------------------------- 1 | Ethereum brain wallets are formed through applying the SHA3 to a seed to 2 | get a result ``R``, then using ``R`` as an accumulator for 16384 repeat 3 | SHA3 operations. This process is continued until the result, when used 4 | as a private key, forms a valid Direct ICAP (34 digit) address, defined 5 | as the first byte of the address being 0. 6 | 7 | :: 8 | 9 | FUNCTION toBrain(STRING seed) RETURNS SECRET 10 | A = SHA3(seed) 11 | REPEAT 16384 TIMES 12 | A = SHA3(A) 13 | END REPEAT 14 | WHILE SECRET_TO_ADDRESS(A)[0] != 0 DO 15 | A = SHA3(A) 16 | END WHILE 17 | RETURN A 18 | END FUNCTION 19 | 20 | See `C++ 21 | implementation `__ 22 | for an example. 23 | 24 | **Comments (Gustav):** 25 | ~~~~~~~~~~~~~~~~~~~~~~ 26 | 27 | Recent advancement in brain wallet cracking [1] show how vulnerable 28 | brain wallets are to weak passwords. Applying a KDF hardens brain 29 | wallets by reducing number of passwords an attacker can generate per 30 | second. 31 | 32 | Even though the seed in AZ is generated for people and can thus be 33 | designed to have enough entropy, it is desirable to configure a KDF to 34 | be as strong as possible without impacting usability. 35 | 36 | Benchmarking SHA3 in Go [2] on a i5-4278U CPU @ 2.60GHz gives 16384 37 | hashes in 30ms. A C implementation on a high-end CPU would be 38 | significantly faster. 39 | 40 | I would recommend we configure a KDF that is much harder (even up to 41 | 1-2s CPU time) and also has a memory cost. Scrypt comes to mind, which 42 | we already specify in for the key storage [3]. 43 | 44 | This would make our brainwallets much harder to crack, and perhaps even 45 | allowing the seed to be shorter, improving usability. 46 | 47 | 1. https://rya.nc/cracking\_cryptocurrency\_brainwallets.pdf 48 | 2. https://github.com/ethereum/go-ethereum/blob/master/crypto/crypto\_test.go#L65 49 | 3. https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition 50 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Client-Version-Strings.rst: -------------------------------------------------------------------------------- 1 | Every client implementation of the Ethereum protocol – along with every 2 | version of it – has a *human readable* string identifier. Although this 3 | ID is exchanged in the `P2P 4 | protocol `__, 5 | it itself isn't used by the protocol for anything, rather it enables 6 | easily localizing issues with a particular client, or a particular 7 | version of a client. 8 | 9 | Still, there tools popping up that analyze and create various statistics 10 | about the network topology itself, which have a hard time conforming to 11 | the identifier/versioning schema employed by each implementation. To 12 | avoid requiring each such tool to implement a full ID parsing for every 13 | type of node in the network, this document outlines a **suggested** 14 | schema, part of which would be common among all implementations, and 15 | some would be specific to one or the other. This would allow simple 16 | tools to properly parse the common information out of each client's ID 17 | string, whereas more complex tools might also further inspect the client 18 | specific metadata. 19 | 20 | *Please note, this document should be perceived as a guideline at most, 21 | and definitely not a golden standard to be enforced by any 22 | implementation or tool. The goal is to aid the ecosystem relying on it, 23 | but it is not something set in stone.* 24 | 25 | Suggested identifier schema 26 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 27 | 28 | All identifier strings should be a slash separated list of metadata 29 | fields: ``metadata-1/metadata-2/.../metadata-n``, where the first few 30 | fields are fixed among all clients, whereas the latter ones (both in 31 | meaning and in count) are up to each implementation to use as seen fit. 32 | 33 | The fixed fields are: 1. Display name of the client, without any version 34 | numbering \* E.g. ``Geth``, ``++eth``, ``Ethereum(J)`` 2. Semantic 35 | version, prefixed with ``v``, *optionally* suffixed by ``-`` 36 | \* E.g. ``v1.3.3``, ``v0.9.41-ed7a8a35``, ``v1.4.0-unstable`` 3. Name of 37 | the operating system the client is running on \* E.g. ``Linux``, 38 | ``Windows``, ``Darwin``, ``Android`` 39 | 40 | As there might be differences in implementation as to how one language 41 | or another retrieves the name of the operating system – among others – 42 | we recommend tools using the IDs to convert the strings internally to 43 | lowercase before making aggregations. 44 | 45 | A few examples conforming to the above schema spec: 46 | 47 | :: 48 | 49 | Geth/v1.3.3/darwin 50 | ++eth/v0.9.41-ed7a8a35/Windows 51 | Ethereum(J)/v1.0.0/Linux 52 | 53 | Optional extensions 54 | ~~~~~~~~~~~~~~~~~~~ 55 | 56 | Beside the above defined fixed metadata fields, an identifier string may 57 | contain arbitrarily many implementation specific metadata entries (the 58 | order and index of which should desirably be maintained by the 59 | developers of said client implementations). To help developers working 60 | on analysis tools have a central repository of the metadata semantics, 61 | the rest of this document describes the extra fields used by each 62 | implementation. Feel free to add your own implementation to the below 63 | list, but please maintain alphabetical ordering and please be concise. 64 | 65 | - **Geth**: ```` / ```` / ```` 66 | - ``Geth/v1.3.3-c541b38/linux/go1.5.5`` 67 | - ``Geth/v1.4.0-unstable/android/go1.6beta2/jit/gopher-power`` 68 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Dapp-Developer-Resources.rst: -------------------------------------------------------------------------------- 1 | As a Ðapp developer you have three main resources which allow Ðapp 2 | development. 3 | 4 | Main Resources 5 | ~~~~~~~~~~~~~~ 6 | 7 | - `Web3 JavaScript 8 | API `__ - This 9 | is the main JavaScript SDK to use when you want to interact with a 10 | nodes API 11 | - `JSON RPC API `__ - 12 | This is the low level JSON RPC 2.0 interface to interface with a 13 | node. This API is used by the `Web3 JavaScript 14 | API `__. 15 | - `Solidity 16 | Documentation `__ - 17 | Solidity is the Ethereum developed Smart Contract language, which 18 | compiles to EVM (Ethereum Virtual Machine) opcodes. 19 | 20 | Other Resources: 21 | ~~~~~~~~~~~~~~~~ 22 | 23 | - `Standardized Contract 24 | APIs `__ 25 | - Standard contract API, which should be used to make some contract 26 | types accessible by other Ðapps. (Not yet finalised) 27 | - `Useful Ðapp 28 | Patterns `__ 29 | - Code snippets which are useful for Ðapp development. 30 | - `Dapp using 31 | Meteor `__ - 32 | This short tutorial gives an intro on how to start building a dapp 33 | using `Meteor `__, and also why Meteor is a 34 | good fit for dapps. 35 | 36 | Useful read 37 | ~~~~~~~~~~~ 38 | 39 | - `FAQ `__ - Collection of 40 | links, useful for understanding the Ethereum eco system. 41 | - `Glossary `__ - Great 42 | explanation of Blockchain related terms. 43 | 44 | Gitter Chats 45 | ~~~~~~~~~~~~ 46 | 47 | - web3.js |Gitter| 48 | - Mist |Gitter| 49 | - GO Ethereum |Gitter| 50 | - C++ Ethereum |Gitter| 51 | - `Swarm `__ 52 | - `Whisper `__ 53 | 54 | .. |Gitter| image:: https://badges.gitter.im/Join%20Chat.svg 55 | :target: https://gitter.im/ethereum/web3.js?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge 56 | .. |Gitter| image:: https://badges.gitter.im/Join%20Chat.svg 57 | :target: https://gitter.im/ethereum/mist?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge 58 | .. |Gitter| image:: https://badges.gitter.im/Join%20Chat.svg 59 | :target: https://gitter.im/ethereum/go-ethereum?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge 60 | .. |Gitter| image:: https://badges.gitter.im/Join%20Chat.svg 61 | :target: https://gitter.im/ethereum/cpp-ethereum?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge 62 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Default-Extra-Data-Standard.rst: -------------------------------------------------------------------------------- 1 | Implementations are encouraged to follow this protocol for populating 2 | the ``extraData`` field of mined blocks. 3 | 4 | ``extraData`` should be an RLP list whose first element is a version 5 | identifier encoded as a canonical RLP positive integer. All other items 6 | in the list are determined by the version ID. 7 | 8 | ``[`` version: ``P``, ... ``]`` 9 | 10 | Version 0 11 | ~~~~~~~~~ 12 | 13 | ``[`` version: ``P``, clientIdentity: ``B`` ``]`` 14 | 15 | One further argument, a raw representation of a string to identify the 16 | client (this would usually be a shortened form of the client identifier 17 | as returned by the JSON RPC's ``web3_clientVersion``). 18 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Deterministic_Wallet_Spec.rst: -------------------------------------------------------------------------------- 1 | Address/key generation 2 | 3 | The following is a proposed deterministic wallet specification. 4 | 5 | Let ``S`` be the secret. We define 6 | ``key(i) = sha3(S + zpad(int_to_big_endian(i), 32))``, where ``i`` is an 7 | incrementing index starting at 0 8 | 9 | Assuming ``S = "123dog"``, we thus have: 10 | 11 | :: 12 | 13 | key(0) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00") 14 | 15 | Note that the big endian representation of 0 is the empty string. 16 | 17 | :: 18 | 19 | key(1) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01") 20 | key(2) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02") 21 | key(255) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff") 22 | key(256) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00") 23 | key(4294967297) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x01") 24 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Ethash-C-API.rst: -------------------------------------------------------------------------------- 1 | This is just a documentation of the request of the C API described in 2 | `this PR `__. 3 | 4 | .. code:: c 5 | 6 | typedef int(*Callback)(unsigned); 7 | typedef /*...*/ ethash_light_t; 8 | typedef /*...*/ ethash_full_t; 9 | typedef struct ethash_h256 { uint8_t b[32]; } ethash_h256_t; 10 | typedef struct ethash_result { ethash_h256_t value; ethash_h256_t hixhash; } ethash_result_t; 11 | 12 | ethash_light_t ethash_light_new(unsigned number); 13 | ethash_result_t ethash_light_compute(ethash_light_t light, ethash_h256_t header_hash, uint64_t nonce); 14 | void ethash_light_delete(ethash_light_t light); 15 | 16 | ethash_full_t ethash_full_new(ethash_light_t light, CallBack c); 17 | uint64_t ethash_full_dag_size(ethash_full_t full); 18 | void const* ethash_full_dag(ethash_full_t full); 19 | ethash_result_t ethash_full_compute(ethash_full_t full, ethash_h256_t header_hash, uint64_t nonce); 20 | void ethash_full_delete(ethash_full_t full); 21 | 22 | non-zero return from Callback means "cancel DAG creation" - this should 23 | cause an immediate return of ``ethash_full_new`` with 0. 24 | 25 | an object of type ``ethash_full_t`` may be tested for validity with != 0 26 | 27 | Example usage: 28 | ~~~~~~~~~~~~~~ 29 | 30 | .. code:: c 31 | 32 | int callback(unsigned _progress) 33 | { 34 | printf("\rGenerating DAG. %d%% done...", _progress); 35 | return 0; 36 | } 37 | void main() 38 | { 39 | ethash_light_t light; 40 | ethash_h256_t seed; 41 | // TODO: populate p, seed, light 42 | ethash_full_t dag = ethash_full_new(light, seed, &callback); 43 | if (!dag) 44 | { 45 | printf("Failed generating DAG :-(\n"); 46 | exit(-1); 47 | } 48 | printf("DAG Generated OK!\n"); 49 | 50 | ethash_h256_t headerHash; 51 | // TODO: populate headerHash 52 | uint64_t nonce = time(0); 53 | ethash_result ret; 54 | for (; !isWinner(ret); nonce++) 55 | ret = ethash_full_compute(dag, headerHash, nonce); 56 | printf("Got winner! nonce is %d\n", nonce); 57 | ethash_full_delete(dag); 58 | } 59 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Ethash-DAG-Disk-Storage-Format.rst: -------------------------------------------------------------------------------- 1 | Ethash is the PoW system. It requires a great huge dataset known as the 2 | DAG (name refers to `Dagger 3 | Hashimoto `__). 4 | This takes a good long while to generate which is a pain. As such we 5 | tend to memoise it. Clients wishing to store the DAG in a cache should 6 | conform to this spec in order to share the cache with other clients: 7 | 8 | Location 9 | ^^^^^^^^ 10 | 11 | The DAG should be stored in a 1GB dump (for the initial epoch, anyway), 12 | in a file: 13 | 14 | - Mac/Linux: ``$(HOME)/.ethash/full-R-`` 15 | - Windows: ``$(HOME)/Appdata/Local/Ethash/full-R-`` 16 | 17 | Where: 18 | 19 | - ```` is a decimal integer, given as the C-constant 20 | ``REVISION`` in ``libethash/ethash.h``; 21 | - ```` is 16 lowercase hex digits specifying the first 8 22 | bytes of the epoch's seed hash. 23 | 24 | There may be many such DAGs stored in this directory; it is up to the 25 | client and/or user to remove out of date ones. 26 | 27 | Format 28 | ^^^^^^ 29 | 30 | Each file should begin with an 8-byte magic number, 31 | ``0xfee1deadbaddcafe``, written in little-endian format (i.e., bytes 32 | ``fe ca dd ba ad de e1 fe``). 33 | 34 | The Ethash algorithm expects the DAG as a two-dimensional array of 35 | uint32s (4-byte unsigned ints), with dimension (n × 16) where n is a 36 | large number. (n starts at 16777186 and grows from there.) Following the 37 | magic number, the rows of the DAG should be written sequentially into 38 | the file, with no delimiter between rows and each unint32 encoded in 39 | little-endian format. 40 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Ethash-DAG.rst: -------------------------------------------------------------------------------- 1 | assasallah 2 | 3 | hu 4 | 5 | akbar 6 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Geth-Dapp-loading-proposal.rst: -------------------------------------------------------------------------------- 1 | To have a simple way to load and start dapps vinay and I came up with a 2 | great idea: 3 | 4 | 1. Dapp packages can be downloaded as .zip/.rlp/.dapp 5 | 6 | - they will contain a ``dapp.json`` with author info and a dapp name 7 | and version. 8 | - and a ``swarm.json``, with all the file paths and hashes, `see 9 | here `__) 10 | 11 | 2. | run ``$ geth install mydapp.zip``, which will verify, extract and 12 | copy the dapp locally somewhere. 13 | | **Note** This could also get a name reg domain and looks up the 14 | hash an content online, fetches it and installs it. 15 | 16 | 3. run ``$ geth start mydapp`` will start a node, with the correct 17 | options (rpc, corsdomain etc) and start a local server which points 18 | with its root into the dapps folder and resolves path and files 19 | through the ``swarm.json`` 20 | 21 | 4. goto ``http://localhost:5555`` to see you dapp running (needs to be 22 | thought of, as dapps would share localstorage, maybe use a different 23 | and reusable port per dapp) 24 | 25 | Update 26 | ------ 27 | 28 | - run ``$ geth update mydapp.zip``, which will extract, and overwrites 29 | the old dapp files 30 | 31 | Bundle dapp 32 | ----------- 33 | 34 | - run ``$ geth bundle myDappFolder/dist/``, which will create a dapp 35 | bundle from a folder, to share with others. 36 | 37 | - run ``$ geth deploy myDappFolder/dist/`` could save it to pastebin 38 | and register it in namereg. 39 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Gitter-Channels.rst: -------------------------------------------------------------------------------- 1 | https://gitter.im/ethereum 2 | 3 | Node Software ("Clients") 4 | ========================= 5 | 6 | Go 7 | -- 8 | 9 | https://gitter.im/ethereum/go-ethereum 10 | 11 | CPP 12 | --- 13 | 14 | https://gitter.im/ethereum/cpp-ethereum 15 | 16 | Python 17 | ------ 18 | 19 | https://gitter.im/ethereum/pyethapp - the client 20 | 21 | https://gitter.im/ethereum/pyethereum - the core library (evm, blocks, 22 | txs, ...) 23 | 24 | https://gitter.im/ethereum/pydevp2p - p2p network 25 | 26 | Dapp Development 27 | ================ 28 | 29 | https://gitter.im/ethereum/web3.js 30 | 31 | https://gitter.im/ethereum/mist 32 | 33 | https://gitter.im/ethereum/solidity 34 | 35 | https://gitter.im/ethereum/serpent 36 | 37 | Other 38 | ===== 39 | 40 | https://gitter.im/ethereum/porting 41 | 42 | https://gitter.im/ethereum/research 43 | 44 | Protocol 45 | ======== 46 | 47 | https://gitter.im/ethereum/devp2p 48 | 49 | https://gitter.im/ethereum/light-client 50 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Home.rst: -------------------------------------------------------------------------------- 1 | Welcome to the Ethereum Wiki 2 | ============================ 3 | 4 | This is the community-maintained wiki covering all sorts of information 5 | on the next-generation peer-to-peer technology platform built by ÐΞV 6 | including **Ethereum**, *the generalized blockchain for smart contract 7 | development*, and **Whisper**, *the private low-level datagram 8 | communication platform*. 9 | 10 | Users signed in with GitHub can edit and add pages using the 11 | `browser `__ 12 | or 13 | `locally `__. 14 | 15 | Status 16 | ------ 17 | 18 | Frontier 19 | ~~~~~~~~ 20 | 21 | Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! 22 | Development continues towards the versions named Homestead, Metropolis 23 | and Serenity (v1.1). Frontier is aimed at exchangers and 24 | `miners `__. Homestead is 25 | aiming for `Ðapps 26 | developers `__, 27 | while Metropolis is aiming for end users with the release of the Mist 28 | browser. Serenity is meant to move from consensus through 29 | `Proof-of-Work `__ to 30 | `Proof-of-Stake `__. 31 | 32 | Getting started 33 | --------------- 34 | 35 | To get the basic concepts of Ethereum visit the Ethereum homepage over 36 | at `http://ethereum.org `__. If you want to get a 37 | deeper understanding, start by read the 38 | `whitepaper `__ and 39 | the `design 40 | rationale `__. 41 | For a more formal review, read the `yellow 42 | paper `__. See the `development 43 | tutorial `__ 44 | for quick start to developing smart contracts. 45 | 46 | Don't get lost 47 | -------------- 48 | 49 | Check the `Glossary `__ 50 | and our `FAQ `__. There are 51 | separate wikis for information relevant to the 52 | `C++ `__ and 53 | `Go `__ implementations 54 | (Python and Javascript coming soon), 55 | 56 | Downloads 57 | --------- 58 | 59 | Bleeding edge code can be cloned from the develop branch of their git 60 | repositories: - https://github.com/ethereum/go-ethereum (Go) - 61 | https://github.com/ethereum/webthree-umbrella (C++) - 62 | https://github.com/ethereum/pyethapp (Python) 63 | 64 | To see the state of the latest Ethereum builds, see the `Buildbot 65 | instance `__ for Go and Python and the 66 | `Jenkins instance `__ for C++. 67 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/IPv6.rst: -------------------------------------------------------------------------------- 1 | Goals 2 | ~~~~~ 3 | 4 | Allow IPv6 to be used over the ethereum peer network 5 | 6 | Basic Design 7 | ~~~~~~~~~~~~ 8 | 9 | Allow IP addresses to be specified either as a 4-byte array (IPv4) or a 10 | 16-byte array (IPv6). 11 | 12 | Needed Changes 13 | ~~~~~~~~~~~~~~ 14 | 15 | **Peers** [``0x05``, [``ip1``: ``B_4`` OR ``B_16``, ``port1``: ``P``, 16 | ``id1``: ``B_64``], [``ip2``: ``B_4`` OR ``B_16``, ``port2``: ``P``, 17 | ``id2``: ``B_64``], ... ] Specifies a number of known peers. \* ``ip`` 18 | is either a 4-byte array 'ABCD' that should be interpreted as the IPv4 19 | address A.B.C.D or a 8-byte array 'ABCDEFGHIJKLMNOP' that should be 20 | interpreted as the IPv6 address AB:CD:EF:GH:IJ:KL:MN:OP. \* ``port`` is 21 | a 2-byte array that should be interpreted as a 16-bit big-endian 22 | integer. \* ``id`` is the 512-bit hash that acts as the unique 23 | identifier of the node. 24 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Licensing.rst: -------------------------------------------------------------------------------- 1 | Overview 2 | 3 | The Ethereum Foundation ensures three principles concerning the funds it 4 | uses to develop Ethereum: 5 | 6 | - it is both open source software and Free software after the 7 | definition of the Free Software Foundation (so-called FOSS); 8 | - no special treatment is given to any single entity concerning the 9 | copyright of the software, the Foundation included; 10 | - source-code will not be distributed ahead of binaries. 11 | 12 | However, this is not where the story ends; there are many different 13 | licenses available that conform to these rules. After considerable 14 | discussion, both internal and external together with The Ethereum 15 | software collection is distributed under several licenses, partly to 16 | reflect the different thinking of the minds behind different pieces of 17 | software and partly to reflect the need to adapt to real-world issues 18 | and opportunities and lay out a strategy to provide the best possible 19 | future for the Ethereum community. 20 | 21 | The Core 22 | ~~~~~~~~ 23 | 24 | The core of Ethereum includes the consensus engine, the networking code 25 | and any supporting libraries. For C++, this includes libethereum, 26 | libp2p, libdevcore, libdevcrypto, libethcore, libevm and libevmface. 27 | 28 | The core of Ethereum will be released under the most liberal of 29 | licenses. This reflects our desire to have Ethereum used in as many 30 | diverse environments as possible, even those which, for various reasons 31 | can require modifications or augmentations to the software which cannot 32 | be released to the public. 33 | 34 | In this way, while we have not arrived at a final license, we expect to 35 | select one of the MIT license, the MPL license or the LGPL license. If 36 | the latter is chosen, it will come with an amendment allowing it to be 37 | linked to be statically linked to software for which source code is not 38 | available. 39 | 40 | In this way, the core of Ethereum, be it C++ or Go, will be available 41 | for use in any commercial environment, closed or open source. 42 | 43 | The Applications 44 | ~~~~~~~~~~~~~~~~ 45 | 46 | The applications of Ethereum, including the Solidity compiler 47 | (libsolidity, solc), AlethZero and Mix will be distributed under the GNU 48 | General Public License. This is to reflect the fact that these pieces of 49 | software tend to not, by nature, need to be amalgamated or augmented 50 | into a larger, closed-source, whole. There is however, much to be gained 51 | through many different members of the Ethereum-community being 52 | incentivised to develop on and build out such software. 53 | 54 | In this way we hope our initial version of Solidity and Mix lay down the 55 | foundation for others to build upon and improve in the true 56 | Free/open-source software manner. 57 | 58 | The Middleware 59 | ~~~~~~~~~~~~~~ 60 | 61 | The middleware of Ethereum, including the Javascript-based ethereum.js, 62 | the webthree libraries and eth (the command line client) will be 63 | distributed under an Affero license, likely the LGPL variant of it. We 64 | wish to allow free development of technologies by allowing linking to 65 | arbitrary software, but again would like to incentivise feeding of 66 | back-end integration work back into the community, especially regarding 67 | the interoperability with legacy systems. 68 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Mix-improvement-proposal.rst: -------------------------------------------------------------------------------- 1 | how it currently looks, its working well for very simple scripts, but 2 | its hard to impossible to use for any advanced javascript application, 3 | using require.js, common.js, bower, npm, angualr.js, ember, canjs, 4 | meteor or any more advanced js framework. As the current deploy method 5 | forces you to do things in a simplistic way (linking ethereum.js, 6 | contracts files and add the contract variable) 7 | 8 | This also makes it hard to test your application as the deploy process 9 | is the one, which uploads the contracts as well and nobody want to 10 | deploy its app and contracts without being able to thoroughly test them 11 | on the main/test net beforehand. 12 | 13 | Additionally not all dapps use one or more contracts, but might want to 14 | deploy contracts on the fly (like the wallet dapp) and need a simple way 15 | to get the compiled contract code. 16 | 17 | So here a re my suggestions: 18 | 19 | - Deploy should only deploy the app files (with the possibility to 20 | choose a to-deploy-folder), and can include the automated name reg 21 | stuff as well 22 | 23 | - contracts should be deployed by right clicking them -> deploy 24 | contract, which then asks where to deploy (testnet, mainnet) and 25 | gives back the ABI and address (maybe in a 26 | ``myContract-deployed.js``) 27 | 28 | - contracts should also be compiled with right click -> compile 29 | contract, giving the compiled HEX string and ABI in an 30 | ``myContract-compiled.js`` (or just use one ``myContract-mix.js``) 31 | 32 | - the files in the sidebar should show the folder structure and not 33 | sort by type, as any advanced js application needs more than just an 34 | index.html and js file. (folders are good ;) 35 | 36 | - the deployable file should be zip, not rlp so people can unpack it 37 | easily and discover the content which will be deployed. This also 38 | allows to understand it and write separate bundle scripts for them. 39 | **(But, might anyway become obsolete with swarm)** 40 | 41 | I think this improvements, will allow for greater flexibility without 42 | compromising the use of mix. 43 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Morden.rst: -------------------------------------------------------------------------------- 1 | Morden is the first Ethereum alternative testnet. It is expected to 2 | continue throughout the Frontier and Homestead era. 3 | 4 | Usage 5 | ~~~~~ 6 | 7 | TurboEthereum (C++) 8 | ^^^^^^^^^^^^^^^^^^^ 9 | 10 | This is supported natively on 0.9.93 and above. Pass the ``--morden`` 11 | argument in when starting any of the clients. e.g.: 12 | 13 | :: 14 | 15 | > eth --morden 16 | 17 | Or, for AlethZero 18 | 19 | :: 20 | 21 | > alethzero --morden 22 | 23 | PyEthApp (Python client) 24 | ^^^^^^^^^^^^^^^^^^^^^^^^ 25 | 26 | PyEthApp supports the morden network from v1.0.5 onwards: 27 | 28 | :: 29 | 30 | > pyethapp --profile morden run 31 | 32 | geth (Go client) 33 | ^^^^^^^^^^^^^^^^ 34 | 35 | :: 36 | 37 | > geth --testnet 38 | 39 | Details 40 | ~~~~~~~ 41 | 42 | - Network Identity: **2** 43 | - All parameters same as Frontier except: 44 | - genesis.json (given below); 45 | - Initial Account Nonce (``IAN``) is 2^20 (instead of 0 in all previous 46 | networks). 47 | 48 | - All accounts in the state trie have nonce >= ``IAN``. 49 | - Whenever an account is inserted into the state trie it is 50 | initialised with nonce = ``IAN``. 51 | 52 | - Genesis block hash: 53 | ``0cd786a2425d16f152c658316c423e6ce1181e15c3295826d7c9904cba9ce303`` 54 | - Genesis state root: 55 | ``f3f4696bbf3b3b07775128eb7a3763279a394e382130f27c21e70233e04946a9`` 56 | 57 | Seed Nodes 58 | ~~~~~~~~~~ 59 | 60 | - ``enode://e58d5e26b3b630496ec640f2530f3e7fa8a8c7dfe79d9e9c4aac80e3730132b869c852d3125204ab35bb1b1951f6f2d40996c1034fd8c5a69b383ee337f02ddc@92.51.165.126:30303`` 61 | 62 | genesis.json 63 | ~~~~~~~~~~~~ 64 | 65 | .. code:: json 66 | 67 | { 68 | "nonce": "0x00006d6f7264656e", 69 | "difficulty": "0x20000", 70 | "mixhash": "0x00000000000000000000000000000000000000647572616c65787365646c6578", 71 | "coinbase": "0x0000000000000000000000000000000000000000", 72 | "timestamp": "0x00", 73 | "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000", 74 | "extraData": "0x", 75 | "gasLimit": "0x2FEFD8", 76 | "alloc": { 77 | "0000000000000000000000000000000000000001": { "balance": "1" }, 78 | "0000000000000000000000000000000000000002": { "balance": "1" }, 79 | "0000000000000000000000000000000000000003": { "balance": "1" }, 80 | "0000000000000000000000000000000000000004": { "balance": "1" }, 81 | "102e61f5d8f9bc71d0ad4a084df4e65e05ce0e1c": { "balance": "1606938044258990275541962092341162602522202993782792835301376" } 82 | } 83 | } 84 | 85 | Getting Ether 86 | ~~~~~~~~~~~~~ 87 | 88 | One way to get Ether is by using the `Ethereum wei 89 | faucet `__. Just type in your 90 | account address and enjoy some free ether. 91 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/NatSpec-Determination.rst: -------------------------------------------------------------------------------- 1 | Publishing and finding the [NatSpec] 2 | (https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format) 3 | documentation for a contract is an important part of the Ethereum 4 | system. There are two pieces to this puzzle: the first is for a given 5 | client to be able to determine, given a call to a contract, what a 6 | **trustworthy** NatSpec documentation hash for the contract is; the 7 | second is to find the actual NatSpec documentation body given its 8 | content hash. 9 | 10 | Trusted Content Determination 11 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12 | 13 | The former, trusted content determination, will ultimately be 14 | accomplished through a sophisticated reputation system. In the meantime, 15 | we (the Ethereum foundation) will maintain our own curated repository of 16 | trusted NatSpec documentation hashes in a contract. The contract is 17 | trivial, just providing a mapping from contract code hash to NatSpec 18 | JSON file hash. It can be found 19 | `here `__. 20 | We, alone, will retain the key updating and adding entries to this 21 | contract. 22 | 23 | This contract will have a specific address on the PoC-9 & Frontier 24 | testnet, probably referenced from the Ethereum services contract. 25 | 26 | Content Publishing and Distribution 27 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 28 | 29 | The latter, content publishing and distribution, will ultimately be 30 | accomplished through the "Swarm" subsystem or IPFS. Until then, we will 31 | piggy back on the existing workaround for content-based publication and 32 | distribution; the `URL 33 | Hint `__ 34 | system. 35 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Natspec-Example.rst: -------------------------------------------------------------------------------- 1 | Introduction 2 | ============ 3 | 4 | This is intended as an example of proof of concept of the natspec 5 | evaluation in Alethzero, the CPP client and as a showcase of the 6 | functionality of Natspec comments. 7 | 8 | Steps 9 | ===== 10 | 11 | Create the natspec documentation 12 | -------------------------------- 13 | 14 | Open up alethzero client and type in the following contract that we will 15 | use as an example 16 | 17 | :: 18 | 19 | contract test { 20 | /// @notice Will multiply `a` by 7. 21 | function multiply(uint a) returns(uint d) { 22 | return a * 7; 23 | } 24 | } 25 | 26 | .. figure:: images/natspec1.png 27 | :alt: Creating natspec in AZ 28 | 29 | Creating natspec in AZ 30 | 31 | Then press the ``Execute`` button in order to generate the contract 32 | creation transaction. We can do that from the JSON Api too but we are 33 | using AlethZero in order to create the natspec documentation from the 34 | contract. Pressing the execute button will create a local database entry 35 | (LevelDB) of a mapping of the contract's hash to the natspec 36 | documentation. 37 | 38 | This is just a temporary solution to showcase the functionality of 39 | natspec. The idea is for people to be able to retrieve natspec 40 | documentations of contracts from a trusted authority which most users 41 | can trust. 42 | 43 | Open up the example contract 44 | ---------------------------- 45 | 46 | |Opening up example contract| We will be using the JSON Api to try and 47 | perform the only transaction that our example contract has defined in 48 | its interface. Open up Alethzero's internal browser and type in the 49 | following path to get to our example 50 | ``/path/to/cpp-ethereum/libjsqrc/ethereumjs/example/natspec_contract.html``. 51 | 52 | You should see a page similar to below. Press the button to start the 53 | example. |Starting natspec example| ## Performing the transaction 54 | 55 | This is the interface our *application* has for the contract. Using the 56 | textbox we can provide the input to the transaction and then execute it. 57 | 58 | Authentication 59 | -------------- 60 | 61 | At this final stage is where natspec actually comes into place. Each and 62 | every transaction has an authentication stage. The natspec documentation 63 | is what is provided to the user in order to notify him of the 64 | transaction and query whether or not to go ahead with it. 65 | |Authenticating natspec| 66 | 67 | As you can see from the picture below even if a contract's transaction 68 | does not have any specific documentation we will still get a generic 69 | popup message asking us whether or not we want to authenticate the 70 | transaction. |Authenticating unknown transaction| 71 | 72 | .. |Opening up example contract| image:: images/natspec2.png 73 | .. |Starting natspec example| image:: images/natspec3.png 74 | .. |Authenticating natspec| image:: images/natspec4.png 75 | .. |Authenticating unknown transaction| image:: images/natspec5.png 76 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Node-discovery-protocol.rst: -------------------------------------------------------------------------------- 1 | In a nutshell: \* Aimed at discovering *RLPx nodes* to connect to \* 2 | UDP-based RPC protocol 3 | (`kademlia `__-like) \* Defines 4 | 4 packet types: *ping*, *pong*, *findnode* and *neighbors* 5 | 6 | See details at either: \* 7 | `devp2p `__ repository's `node 8 | discovery 9 | protocol `__ 10 | page \* `go-ethereum `__ 11 | repository's `node discovery 12 | protocol `__ 13 | page 14 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Parallel-Block-Downloads.rst: -------------------------------------------------------------------------------- 1 | New network protocol & strategy. 2 | 3 | Goals 4 | ~~~~~ 5 | 6 | - Achieve parallel downloads of chain 7 | - Introduce framework that can form basis of Swarm 8 | - Minimise unnecessary block transfers 9 | 10 | Basic Overview 11 | ~~~~~~~~~~~~~~ 12 | 13 | - Two peers connect & say Hello. Hello includes the TD & hash of their 14 | best block. 15 | - The client with the worst TD asks peer for full chain of just block 16 | hashes. 17 | - Chain of hashes is stored in space shared by all peer connections, 18 | and used as a "work pool". 19 | - While there are hashes in the chain of hashes that we don't have in 20 | our chain: 21 | - Ask for N blocks from our peer using the hashes. Mark them as on 22 | their way so we don't get them from another peer. 23 | 24 | Required Changes 25 | ~~~~~~~~~~~~~~~~ 26 | 27 | Network protocol: 33 28 | 29 | Additional parameters to Hello: - ``TD``: Total Difficulty of the best 30 | chain. Integer. - ``BestHash``: The hash of the best (i.e. highest TD) 31 | known block. - ``GenesisHash``: The hash of the Genesis block. 32 | 33 | Additional Message types: - ``0x17``: ``GetBlockHashes`` [ ``hash`` : 34 | ``B_32``, ``maxBlocks``: ``P`` ]: Requests a ``BlockHashes`` message of 35 | at most ``maxBlocks`` entries, of block hashes from the blockchain, 36 | starting at the parent of block ``hash``. Does not *require* the peer to 37 | give ``maxBlocks`` hashes - they could give somewhat fewer. - 38 | ``0x18``:``BlockHashes`` [ ``hash_0``: ``B_32``, ``hash_1``: ``B_32``, 39 | .... ]: Gives a series of hashes of blocks (each the child of the next). 40 | This implies that the blocks are ordered from youngest to oldest. - 41 | ``0x19``:``GetBlocks`` [ ``hash_0``: ``B_32``, ``hash_1``: ``B_32``, 42 | .... ]: Requests a ``Blocks`` message detailing a number of blocks to be 43 | sent, each referred to by a hash. Note: Don't expect that the peer 44 | necessarily give you all these blocks in a single message - you might 45 | have to re-request them. 46 | 47 | Remove Message types: - ``GetChain`` - ``NotInChain`` 48 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Poll-for-token-proposal-EIP-20.rst: -------------------------------------------------------------------------------- 1 | Poll for https://github.com/ethereum/EIPs/issues/20 2 | 3 | github username \| IN \| OUT \| NextEIP\*? \| Comments 4 | ----------------\|----------------\|---------------\|-----------------------------------\|--------- 5 | example \| Set1, identifier \| decimals, approve, unapprove, allowance 6 | \| YES \| christianlundkvist\| Set1 \| decimals \| YES \| nmushegian \| 7 | Set1 \| decimals \| YES \| joeykrug \| Set1, identifier \| ? \| ? \| 8 | koeppelmann \| Set1, identifier \| ? \| ? \| Georgi87 \| Set1, 9 | identifier \| decimals \| Yes \| niran \| Set1 \| decimals \| YES?\| 10 | ethers \| Set1, identifier \| decimals \| YES \| simondlr \| Set1 \| 11 | decimals \| YES \| frozeman \| Set1, decimals \| \| NO \| alexvandesande 12 | \| Set1, decimals \| \| \| caktux \| Set1, decimals \| \| \| firecar96 13 | \| Set1 \| decimals, identifier \| YES \| 14 | 15 | - Set1 = balanceOf, transfer, transferFrom, totalSupply, approve, 16 | unapprove, allowance 17 | - "identifier" = 18 | https://github.com/ethereum/EIPs/issues/20#issuecomment-158436720 and 19 | the discussion 20 | - NextEIP means should the OUT items be in separate EIP/s or be in 21 | EIP20 itself but marked Optional. YES means separate EIP/s, NO means 22 | keep in EIP20 and mark it Optional. 23 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Proposal-NewBlockHashes.rst: -------------------------------------------------------------------------------- 1 | Problem 2 | ======= 3 | 4 | Block propagation is slow. This is partly due to the problematic 5 | strategy decision of either sending out a new block to all peers (costly 6 | in terms of bandwidth, especially when considered at the network level 7 | where most nodes will receive a block from most of their peers) or send 8 | a new block to a randomly selected subset of peers (making worst-case 9 | propagation times substantial). 10 | 11 | Solution 12 | ======== 13 | 14 | Much better would be a low-bandwidth full propagation of the hash. All 15 | nodes would receive a hash for each new block from most of their peers 16 | (peers who have demonstrated knowledge of the hash would not be 17 | notified). However, the block itself would need only be transferred once 18 | per node. 19 | 20 | Specification 21 | ============= 22 | 23 | Introduce a new packet: ``NewBlockHashes``, into the slot ``+0x01`` 24 | (original taken by ``GetTransactions``, which is not defunct). 25 | 26 | **NewBlockHashes** [``+0x01``: ``P``, ``hash1``: ``B_32``, ``hash2``: 27 | ``B_32``, ``...``] Specify one or more new blocks which have appeared on 28 | the network. Including hashes that the sending peer could reasonable be 29 | considered to know that the receiving node is aware of is considered Bad 30 | Form, and may reduce the reputation of the sending node. Including 31 | hashes that the sending node later refuses to honour with a proceeding 32 | ``GetBlocks`` message is considered Bad Form, and may reduce the 33 | reputation of the sending node. 34 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/RPC-Testing.rst: -------------------------------------------------------------------------------- 1 | :: 2 | 3 | { 4 | blockchain: [ 5 | { 6 | difficulty: 1024, 7 | transactions: [ 8 | ... 9 | ] 10 | }, 11 | ] 12 | } 13 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Security-Issue-Process.rst: -------------------------------------------------------------------------------- 1 | Draft of steps that should be taken when finding a security issue in 2 | Ethereum. Security issue is defined as a problem in scope of 3 | `Security-Categorization `__. 4 | 5 | Partly inspired by `OWASP Risk 6 | Rating `__ 7 | 8 | Documentation 9 | ~~~~~~~~~~~~~ 10 | 11 | - Add a entry describing the issue at (TODO: github link). 12 | - Estimate likelihood, impact and complexity of fix. 13 | - Affected software version(s). 14 | 15 | Estimate Likelihood 16 | ~~~~~~~~~~~~~~~~~~~ 17 | 18 | - How likely is it to be uncovered and exploited by an attacker? 19 | - Ease of discovery? 20 | - Ease of exploit? 21 | - Likelihood of detection? 22 | 23 | Estimate Impact 24 | ~~~~~~~~~~~~~~~ 25 | 26 | - Blockchain consensus. Potential of blockchain fork? 27 | - Financial damage. Loss of ether? 28 | - Privacy. E.g. revealing who sent a tx or who owns an address. 29 | - Availability. Can it impact availablity of node(s)? 30 | 31 | Technical description 32 | ~~~~~~~~~~~~~~~~~~~~~ 33 | 34 | - Protocol version. 35 | - Client version(s). Single or multiple implementations? 36 | - OS / external library version(s). 37 | - Link to relevant source code. 38 | - How to fix. 39 | - How to test. 40 | 41 | Ownership / Responsibility 42 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 43 | 44 | - Who is assigned to fix the issue? 45 | - Who will test / review a fix? 46 | - Who takes responsibility for preparing new builds of client software? 47 | 48 | Disclosure 49 | ~~~~~~~~~~ 50 | 51 | - Who takes on to disclose the issue? 52 | - Communication channels (mail lists, twitter, github). 53 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Serpent_3.0.rst: -------------------------------------------------------------------------------- 1 | The following is a suggested spec for Serpent 3.0. 2 | 3 | 1. Everything is strongly typed, but types are inferred, so there is no 4 | need to specify types explicitly. 5 | 6 | For example, consider the code: 7 | 8 | :: 9 | 10 | data bar[6] 11 | 12 | def foo(): 13 | x = 5 14 | y = [1,2,3,4,5,6] 15 | z = "123123124" 16 | w1 = y[1] 17 | w2 = z[2] 18 | self.bar = y 19 | return(x) 20 | 21 | A script would run through the code and assign types: 22 | 23 | :: 24 | 25 | x: int 26 | y: arr[int] 27 | z: string 28 | w1: int 29 | w2: int 30 | self.bar: arr[int] :: storage 31 | 32 | When checking the type for w1, the script would see the line 33 | ``w1 = y[1]``, note that ``y`` is already known as an ``arr[int]`` so 34 | ``y[1]`` will be recognized as ``int``. Meanwhile, ``z`` will be known 35 | as ``string``, and so ``z[1]`` will be recognized as a character, ie. 36 | ``int``. Note that this means that ``y[1]`` will be compiled as 37 | ``(mload (add y 32))`` whereas ``z[2]`` will be compiled as 38 | ``(byte (mload (add z 2)) 0)``. ``self.bar = y`` will be processed 39 | recursively so as to copy the entire contents of ``y`` into 40 | ``self.bar``. 41 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Solidity-Tutorial.rst: -------------------------------------------------------------------------------- 1 | See also `Russian version (русский 2 | перевод) `__ 3 | 4 | -------------- 5 | 6 | English version moved to a new 7 | `site `__. 8 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/URL-Hint-Protocol.rst: -------------------------------------------------------------------------------- 1 | There exists a root ``Registry`` contract at address 0x42 (this is the 2 | auctioning thing). There exists a contract interface, ``register``, 3 | which ``Registry`` implements. 4 | 5 | Entries in ``register``, when looked up (indexed by a string32 name) 6 | have several value fields, including ``content`` and ``register``. 7 | 8 | ``content`` is the content hash which gets loaded when you enter this 9 | name into Mist/AZ. 10 | 11 | ``register`` is the address of a subregistry contract (some contract 12 | implementing ``register``) which gets queried recursively. 13 | 14 | Example 15 | ~~~~~~~ 16 | 17 | - ``eth://gavofyork`` results in the main Registry (at 0x42) being 18 | queried for the entry ``gavofyork``. The content field of this entry 19 | (a SHA3 hash of a zip file OR manifest) is used to display content 20 | (see Content section for more info). 21 | 22 | URL Composition 23 | --------------- 24 | 25 | All URLs canonically begin ``eth://`` and are a number of components, 26 | each separated by a ``/``. The field ``register`` is used to do a 27 | recursive lookup. 28 | 29 | So the components of ``gavofyork/tools/site/contact`` would comprise 30 | four components, in order: ``gavofyork``, ``tools``, ``site``, 31 | ``contact``. 32 | 33 | Any periods ``.`` before the left-most slash ``/`` delineate components 34 | which are specified in reverse order. 35 | 36 | So non-canonical forms of the above address are: 37 | 38 | - ``tools.gavofyork/site/contact`` 39 | - ``site.tools.gavofyork/contact`` 40 | - ``contact.site.tools.gavofyork`` 41 | 42 | NOTE: any periods after the leftmost ``/`` are treated no differently 43 | than other alphanumeric characters. 44 | 45 | Example 46 | ~~~~~~~ 47 | 48 | - ``eth://gavofyork/site`` results in the main Registry (at 0x42) being 49 | queried for the entry ``gavofyork``. The register field of this entry 50 | (an address of a ``register``-implementing contract) is then queried 51 | for the entry ``site``. The ``content`` field of this entry is used 52 | to display content. 53 | 54 | Content 55 | ======= 56 | 57 | Normally Swarm would be used to determine the content from the content 58 | hash. 59 | 60 | For 1.0, this will not be possible, so we will fall back to using HTTP 61 | distribution. To enable this we will include one or many URLHint 62 | contracts, which provide hints of URLs that allow downloading of 63 | particular content hashes. Find the contract in dapp-bin. 64 | 65 | The content downloaded should be treated in many ways (and hashed) to 66 | discover what the content is. Possible ways include base 64 encoding, 67 | hex encoding and raw, and any content-cropping needed (e.g. a HTML page 68 | should have everything up to body tags removed). 69 | 70 | It will be up to the dapp/content uploader to keep URLHint entries 71 | updated. 72 | 73 | The address of the URLHint contract will be specified on an ad-hoc basis 74 | and users will be able to enter additional ones into their browser. 75 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Useful-Ðapp-Patterns.rst: -------------------------------------------------------------------------------- 1 | The following page is a collection of useful patterns, Ðapps can use, 2 | such as talking to the blockchain reliably. 3 | 4 | The example patterns can possibly change, so don't rely fully on them as 5 | of yet. 6 | 7 | Examples 8 | -------- 9 | 10 | - | 3 ways of instantiating web3: 11 | | https://gist.github.com/frozeman/fbc7465d0b0e6c1c4c23 12 | 13 | - | Contract deployment by code: 14 | | (Outdated, use 15 | ``web3.contract(abiArray).new({}, function(e, res){...})``) 16 | https://gist.github.com/frozeman/655a9325a93ac198416e 17 | 18 | - Test a contract transaction with a ``call`` before actually sending: 19 | https://gist.github.com/ethers/2d8dfaaf7f7a2a9e4eaa 20 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/Whisper-Wire-Protocol.rst: -------------------------------------------------------------------------------- 1 | Peer-to-peer communications between nodes running Whisper clients run 2 | using the underlying `ÐΞVp2p Wire 3 | Protocol `__. 4 | 5 | This is a preliminary wire protocol for the Whisper subsystem. It will 6 | change. 7 | 8 | Whisper Sub-protocol 9 | ~~~~~~~~~~~~~~~~~~~~ 10 | 11 | **Status** [``+0x00``: ``P``, ``protocolVersion``: ``P``] Inform a peer 12 | of the **whisper** status. This message should be send *after* the 13 | initial handshake and *prior* to any **whisper** related messages. \* 14 | ``protocolVersion`` is one of: \* ``0x02`` for PoC-7. 15 | 16 | **Messages** [``+0x01``: ``P``, [``expiry1``: ``P``, ``ttl1``: ``P``, 17 | [``topic1x1``: ``B_4``, ``topic1x2``: ``B_4``, ...], ``data1``: ``B``, 18 | ``nonce1``: ``P``], [``expiry2``: ``P``, ...], ...] Specify one or more 19 | messages. Nodes should not resend the same message to a peer in the same 20 | session, nor send a message back to a peer from which it received. This 21 | packet may be empty. The packet must be sent at least once per second, 22 | and only after receiving a **Messages** message from the peer. 23 | 24 | Session Management 25 | ~~~~~~~~~~~~~~~~~~ 26 | 27 | For the Whisper sub-protocol, upon an active session, a ``Status`` 28 | message must be sent. Following the reception of the peer's ``Status`` 29 | message, the Whisper session is active. The peer with the greatest Node 30 | Id should send a **Messages** message to begin the message rally. From 31 | that point, peers take it in turns to send (possibly empty) Messages 32 | packets. 33 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/_Footer.rst: -------------------------------------------------------------------------------- 1 | [ `English `__ \| [Japanese] 2 | (https://github.com/ethereum/wiki/wiki/日本語版) \| 3 | `Romanian `__ 4 | \| 5 | `German `__ 6 | \| 7 | `Chinese `__ 8 | \| 9 | `Italian `__ 10 | \| 11 | `Spanish `__ 12 | \| 13 | `French `__ 14 | \| `فارسی 15 | (Persian) `__ 16 | \| [한글 (Korean)] 17 | (https://github.com/ethereum/wiki/wiki/%5BKorean%5D-White-Paper) ] 18 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/enode-url-format.rst: -------------------------------------------------------------------------------- 1 | An Ethereum node can be described with a URL scheme "enode". 2 | 3 | The hexadecimal node ID is encoded in the username portion of the URL, 4 | separated from the host by an @ sign. The hostname can only be given as 5 | an IP address, DNS domain names are not allowed. The port in the host 6 | name section is the TCP listening port. If the TCP and UDP (discovery) 7 | ports differ, the UDP port is specified as query parameter "discport". 8 | 9 | In the following example, the node URL describes a node with IP address 10 | ``10.3.58.6``, TCP listening port ``30303`` and UDP discovery port 11 | ``30301``. 12 | 13 | :: 14 | 15 | enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301 16 | 17 | The enode url scheme is used by the Node discovery protocol and can be 18 | used in the ``bootnodes`` command line option of the client or as the 19 | argument to ``suggestPeer(nodeURL)`` function in the JSRE. 20 | 21 | See also - 22 | https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options - 23 | https://github.com/ethereum/go-ethereum/wiki/JavaScript-Console 24 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/eπ-Programme.rst: -------------------------------------------------------------------------------- 1 | The Ethereum Raspberry Pi (eπ) Programme 2 | ======================================== 3 | 4 | The eπ programme is aimed to get as many nodes distributed around the 5 | world as possible. Any existing Ethereum meetup group is eligible to 6 | apply. 7 | 8 | We will offer to loan the group a set of equipment to run an Ethereum 9 | node. This will include: 10 | 11 | - Raspberry Pi 2 Model B; 12 | - 64 GB fast memory card; 13 | - PSU. 14 | 15 | We expect you guys to be the ones to run the install 16 | (https://github.com/ethereum/wiki/wiki/Raspberry-Pi-instructions). 17 | 18 | Your node will be placed on both our public and curated node lists, and 19 | aside from allowing us to show dots all over the world, will help us 20 | better understand network dynamics and emergent effects stemming from 21 | our propagation strategies. 22 | 23 | To apply for the programme, send an application including your name, 24 | meetup group name/town and an address for shipment to epi@ethereum.org. 25 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/newBlockFilter-Improvement-Proposal.rst: -------------------------------------------------------------------------------- 1 | Currently a filter created with ``eth_newBlockFilter`` and call 2 | ``eth_getFilterLogs``, or ``get_filterChanges`` should return ``[null]`` 3 | or ``[null, null,...]`` If multiple blocks came in since the last poll. 4 | 5 | Thats fine as you can check for the current block e.g. using: 6 | 7 | .. code:: js 8 | 9 | web3.eth.filter('latest').watch(function(err, res){ 10 | // i can get the current block here 11 | web3.eth.getBlock('latest'); 12 | }); 13 | 14 | The problem is that when a lot of blocks came in since the last time you 15 | polled with a return of ``[null, null, null, ...]``, your callback will 16 | fire multiple times accordingly, but using ``eth.getBlock`` inside will 17 | always give me the latest block, which is actually wrong. 18 | 19 | New Proposal 20 | ============ 21 | 22 | After discussing with Gavin we came up with the following improvement: 23 | 24 | .. code:: js 25 | 26 | // eth_newBlockFilter will receive no parameter 27 | {"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":529} 28 | 29 | // poll 30 | {"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0xb"],"id":530} // we assume the filter ID is "0xb" 31 | 32 | // should return one or more blocks, 33 | // depending on how much arrived since the last poll 34 | { 35 | "id": 530, 36 | "jsonrpc": "2.0", 37 | "result": ['0x234234234..','0x342342342..'] // block hashes of the incoming blocks 38 | } 39 | 40 | .. code:: js 41 | 42 | // eth_newPendingTransactionFilter will receive no parameter 43 | {"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":529} 44 | 45 | // poll 46 | {"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0xb"],"id":530} // we assume the filter ID is "0xb" 47 | 48 | // should return one or more pending transactions, 49 | // which were added to the pending state since the last poll 50 | { 51 | "id": 530, 52 | "jsonrpc": "2.0", 53 | "result": ['0x234234234..','0x342342342..'] // tx hashes of new pending transactions 54 | } 55 | 56 | **Note** This requires that ``eth_getTransactionByHash`` also return 57 | pending transactions! 58 | -------------------------------------------------------------------------------- /old-docs-for-reference/main-wiki.rst/web.js-0.9.rst: -------------------------------------------------------------------------------- 1 | Web3.js 0.9 changes 2 | 3 | I would like to apply KISS principle to web3.js. I used the library 4 | recently much more and I realised that we are doing to many things 5 | implicitly. eg: 6 | 7 | 1, newFilter it should either get all logs or poll for new logs. It's 8 | shouldn't do both in the same time. In my story, I don't want to poll 9 | for filter changes, but I want to get all logs between block X and Y. 10 | Same as caktux here: https://github.com/ethereum/web3.js/issues/250 11 | 12 | examples of new solution 13 | 14 | 1st. 15 | 16 | \`\`\` var x = web3.eth.filter(...); // sync: eth\_newFilter 17 | x.watch(function (err, log) { // async poll: eth\_getFilterChanges 18 | 19 | }) \`\`\` 20 | 21 | 2nd. 22 | 23 | \`\`\` web3.eth.filter(..., function (err, x) { // async: eth\_newFilter 24 | x.watch(function (err, log) { // async poll: eth\_getFilterChanges 25 | 26 | :: 27 | 28 | }) 29 | 30 | }) 31 | 32 | \`\`\` 33 | 34 | 3rd. 35 | 36 | ``var x = web3.eth.filter(...) // sync: eth_newFilter var logs = x.logs(); // sync: eth_getFilterLogs`` 37 | 38 | 4th. \`\`\` var x = web3.eth.filter(...) // sync: eth\_newFilter var 39 | logs = x.logs(function (err, logs) { // sync: eth\_getFilterLogs 40 | 41 | } \`\`\` 42 | -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | restructuredtext-lint==1.1.3 2 | Pigments==1.6 3 | sphinx-rtd-theme==0.2.4 4 | Sphinx==1.7.1 5 | -------------------------------------------------------------------------------- /source/connecting-to-clients/ethereum-ruby/index.rst: -------------------------------------------------------------------------------- 1 | .. _ethereum-ruby: 2 | 3 | ################################################################################ 4 | ethereum-ruby 5 | ################################################################################ 6 | 7 | **ethereum-ruby** is a pure-Ruby JSON-RPC wrapper for communicating with an 8 | Ethereum node. To use this library you will need to have a running Ethereum 9 | node with IPC support enabled (default). Currently, the :ref:`go-ethereum` 10 | client is supported. 11 | 12 | 13 | Links: 14 | 15 | * GitHub: https://github.com/DigixGlobal/ethereum-ruby 16 | -------------------------------------------------------------------------------- /source/connecting-to-clients/index.rst: -------------------------------------------------------------------------------- 1 | .. _Connecting to Clients: 2 | 3 | ################################################################################ 4 | Connecting to Ethereum Clients 5 | ################################################################################ 6 | 7 | Ethereum clients expose a number of methods over `JSON-RPC `_ for interacting with them from within an application. However, interacting directly over JSON-RPC passes on a number of burdens to the application developers, such as: 8 | 9 | - JSON-RPC protocol implementation 10 | - Binary format encoding/decoding for creating and interacting with smart contracts 11 | - 256 bit numeric types 12 | - Admin command support - e.g. create/manage addresses, sign transactions 13 | 14 | A number of libraries have been written to help address these issues, allowing application developers to focus on their applications, instead of the underlying plumbing to interact with Ethereum clients and the wider ecosystem. 15 | 16 | +----------------------+------------+-----------------------------------------------+ 17 | | Library | Language | Project Page | 18 | +======================+============+===============================================+ 19 | | :ref:`web3.js` | JavaScript | https://github.com/ethereum/web3.js | 20 | +----------------------+------------+-----------------------------------------------+ 21 | | :ref:`web3j` | Java | https://github.com/web3j/web3j | 22 | +----------------------+------------+-----------------------------------------------+ 23 | | :ref:`Nethereum` | C# .NET | https://github.com/Nethereum/Nethereum | 24 | +----------------------+------------+-----------------------------------------------+ 25 | | :ref:`ethereum-ruby` | Ruby | https://github.com/DigixGlobal/ethereum-ruby | 26 | +----------------------+------------+-----------------------------------------------+ 27 | | :ref:`web3.py` | Python | https://github.com/ethereum/web3.py | 28 | +----------------------+------------+-----------------------------------------------+ 29 | 30 | Information on each library is provided in the following sections: 31 | 32 | .. toctree:: 33 | :maxdepth: 2 34 | 35 | web3.js/index.rst 36 | web3j/index.rst 37 | nethereum/index.rst 38 | ethereum-ruby/index.rst 39 | web3.py/index.rst 40 | 41 | For an overview of creating and interacting with smart contracts and transactions via the web3.js library, please refer to the section :ref:`Accessing Contracts and Transactions`. 42 | -------------------------------------------------------------------------------- /source/connecting-to-clients/nethereum/index.rst: -------------------------------------------------------------------------------- 1 | .. _Nethereum: 2 | 3 | ################################################################################ 4 | Nethereum 5 | ################################################################################ 6 | 7 | **Nethereum** 8 | 9 | Nethereum is the .Net integration library for Ethereum, it allows you to interact with Ethereum clients like :ref:`go-ethereum`, :ref:`cpp-ethereum` or :ref:`Parity` using RPC. 10 | 11 | The library has very similar functionality as the Javascript Etherum Web3 RPC Client Library. 12 | 13 | All the JSON RPC/IPC methods are implemented as they appear in new versions of the clients. 14 | 15 | The geth client is the one that is closely supported and tested, including its management extensions for admin, personal, debugging, miner. 16 | 17 | Interaction with contracts has been simplified for deployment, function calling, transaction and event filtering and decoding of topics. 18 | 19 | The library has been tested in all the platforms .Net Core, Mono, Linux, iOS, Android, Raspberry PI, Xbox and of course Windows. 20 | 21 | 22 | Links: 23 | 24 | * GitHub: https://github.com/Nethereum/Nethereum 25 | * Website: http://nethereum.com 26 | * Documentation: https://nethereum.readthedocs.io/en/latest/ 27 | * Gitter: https://gitter.im/Nethereum/Nethereum 28 | -------------------------------------------------------------------------------- /source/connecting-to-clients/web3.js/index.rst: -------------------------------------------------------------------------------- 1 | .. _web3.js: 2 | 3 | ################################################################################ 4 | web3.js 5 | ################################################################################ 6 | 7 | **web3.js** 8 | 9 | This is the Ethereum compatible `JavaScript API `_ which implements the `Generic JSON RPC `_ spec. It's available on npm as a node module, for bower and component as an embeddable js and as a meteor.js package. 10 | 11 | Links: 12 | 13 | * GitHub: https://github.com/ethereum/web3.js/ 14 | * Wiki: https://github.com/ethereum/wiki/wiki/JavaScript-API 15 | * Gitter: https://gitter.im/ethereum/web3.js 16 | * NPM module: https://www.npmjs.com/package/web3 17 | -------------------------------------------------------------------------------- /source/connecting-to-clients/web3.py/index.rst: -------------------------------------------------------------------------------- 1 | .. _web3.py: 2 | 3 | ################################################################################ 4 | web3.py 5 | ################################################################################ 6 | 7 | **web3.py** is a pure-Python JSON-RPC wrapper for communicating with an 8 | Ethereum node. To use this library you will need to have a running Ethereum 9 | node with HTTP or IPC enabled. 10 | 11 | 12 | Links: 13 | 14 | * Docs: http://web3py.readthedocs.io/en/stable/ 15 | * GitHub: https://github.com/ethereum/web3.py 16 | -------------------------------------------------------------------------------- /source/connecting-to-clients/web3j/index.rst: -------------------------------------------------------------------------------- 1 | .. _web3j: 2 | 3 | ################################################################################ 4 | web3j 5 | ################################################################################ 6 | 7 | **web3j** 8 | 9 | web3j is a lightweight Java library for integrating with clients (nodes) on the Ethereum network. 10 | 11 | Core features: 12 | - Interaction with Ethereum clients over JSON-RPC via Java types 13 | - Supports all JSON-RPC method types 14 | - Supports all Geth and Parity methods for managing accounts and signing transactions 15 | - Sending of client requests both asynchronously and synchronously 16 | - Auto-generation of Java smart contract function wrappers from Solidity ABI files 17 | 18 | Currently, the :ref:`go-ethereum` and :ref:`Parity` clients are supported. 19 | 20 | 21 | Links: 22 | 23 | * GitHub: https://github.com/web3j/web3j 24 | * Website: http://web3j.io 25 | * Wiki: https://github.com/web3j/web3j/wiki 26 | * Gitter: https://gitter.im/web3j/web3j 27 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/ethereum-tests/index.rst: -------------------------------------------------------------------------------- 1 | .. _Ethereum Tests: 2 | 3 | ################################################################################ 4 | Ethereum Tests 5 | ################################################################################ 6 | 7 | Ethereum Testing Docs have been moved to http://ethereum-tests.readthedocs.io/. 8 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/index.rst: -------------------------------------------------------------------------------- 1 | ################################################################################ 2 | Contracts and Transactions 3 | ################################################################################ 4 | 5 | .. toctree:: 6 | :maxdepth: 2 7 | 8 | account-types-gas-and-transactions.rst 9 | contracts.rst 10 | accessing-contracts-and-transactions.rst 11 | mix.rst 12 | developer-tools.rst 13 | ethereum-tests/index.rst 14 | web3-base-layer-services.rst 15 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix.rst: -------------------------------------------------------------------------------- 1 | .. _sec:mix: 2 | 3 | ################################################################################ 4 | Mix 5 | ################################################################################ 6 | 7 | 8 | The IDE Mix is intended to help you as a developer to create, debug and 9 | deploy contracts and dapps (both contracts backend and frontend). 10 | 11 | **WARNING - There are numerous reports of crash-at-boot issues for Mix on 12 | OS X. The issue is a** `Heisenbug `_ 13 | **which we have been chasing for a month or two. The best workaround we have 14 | for right now is to use the Debug configuration, like so:** :: 15 | 16 | cmake -DCMAKE_BUILD_TYPE=Debug .. 17 | 18 | **WARNING - A replacement for Mix called** `Remix `_ 19 | **is being worked on, so if you are experiencing issues with Mix, you might be better 20 | to look for alternatives until Remix is more mature.** 21 | 22 | Start by creating a new project that consists of 23 | 24 | - contracts 25 | - html files 26 | - JavaScript files 27 | - style files 28 | - image files 29 | 30 | .. toctree:: 31 | :maxdepth: 2 32 | 33 | mix/project-editor.rst 34 | mix/scenario-editor.rst 35 | mix/state-viewer.rst 36 | mix/transaction-explorer.rst 37 | mix/javascript-console.rst 38 | mix/transaction-debugger.rst 39 | mix/dapp-deployment.rst 40 | mix/codeeditor.rst 41 | 42 | 43 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/codeeditor.rst: -------------------------------------------------------------------------------- 1 | .. _sec:codeeditor: 2 | 3 | Code Editor 4 | =========== 5 | 6 | This editor provides basic functionalities of a code editor. 7 | 8 | - In Solidity or JavaScript mode, an autocompletion plugin is available 9 | (Ctrl + Space). 10 | 11 | - Increasing/decreasing the font size (Ctrl +, Ctrl -) 12 | 13 | - In Solidity mode, you can display the gas estimation (Tools -> 14 | Display Gas Estimation). This will highlight all statements which 15 | requires a minimum amount of gas. Color turns to red if the gas 16 | required becomes important. 17 | It will also display the max execution cost of a transaction (for 18 | each function). 19 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/dapp-deployment.rst: -------------------------------------------------------------------------------- 1 | .. _sec:dapp-deployment: 2 | 3 | Dapps deployment 4 | ================ 5 | 6 | | This feature allows users to deploy the current project as a Dapp in 7 | the main blockchain. 8 | | This will deploy contracts and register frontend resources. 9 | 10 | The deployment process includes three steps: 11 | 12 | - | **Deploy contract**: 13 | | This step will deploy contracts in the main blockchain. 14 | 15 | - | **Package dapp**: 16 | | This step is used to package and upload frontend resources. 17 | 18 | - | **Register**: 19 | | To render the Dapp, the Ethereum browser (Mist or AlethZero) needs 20 | to access this package. This step will register the URL where the 21 | resources are stored. 22 | 23 | To Deploy your Dapp, Please follow these instructions: 24 | 25 | | Click on ``Deploy``, ``Deploy to Network``. 26 | | This modal dialog displays three parts (see above): 27 | 28 | - **Deploy contract** 29 | 30 | - *Select Scenario* 31 | 32 | “Ethereum node URL” is the location where a node is running, there must 33 | be a node running in order to initiate deployment. 34 | 35 | “Pick Scenario to deploy” is a mandatory step. Mix will execute 36 | transactions that are in the selected scenario (all transactions except 37 | transactions that are not related to contract creation or contract 38 | call). Mix will display all the transactions in the panel below with all 39 | associated input parameters. 40 | 41 | “Gas Used”: depending on the selected scenario, Mix will display the 42 | total gas used. 43 | 44 | - *Deploy Scenario* 45 | 46 | “Deployment account” allow selecting the account that Mix will use to 47 | execute transactions. 48 | 49 | “Gas Price” shows the default gas price of the network. You can also 50 | specify a different value. 51 | 52 | “Deployment cost”: depending on the value of the gas price that you want 53 | to use and the selected scenario. this will display the amount ether 54 | that the deployment need. 55 | 56 | “Deployed Contract”: before any deployment this part is empty. This will 57 | be filled once the deployment is finished by all contract addresses that 58 | have been created. 59 | 60 | “Verifications”. This will shows the number of verifications (number of 61 | blocks generated on top of the last block which contains the last 62 | deployed transactions). Mix keep track of all the transactions. If one 63 | is missing (unvalidated) it will be displayed in this panel. 64 | 65 | - *Package dapp* 66 | 67 | The action “Generate Package” will create a new folder named 'www', this 68 | folder will contain all the resources and scripts will be mapped 69 | to the current deployed contract. 70 | In order to publish your dapp, you need to host the www folder in a webserver (to 71 | be replace soon by IPFS and SWARM). by default the library web3.js is not included. 72 | If you want to be able to use the dapp in a standard web browser, you wiil need to 73 | include this library. 74 | 75 | 76 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/dapp-deployment.rst~: -------------------------------------------------------------------------------- 1 | .. _sec:dapp-deployment: 2 | 3 | Dapps deployment 4 | ================ 5 | 6 | | This feature allows users to deploy the current project as a Dapp in 7 | the main blockchain. 8 | | This will deploy contracts and register frontend resources. 9 | 10 | The deployment process includes three steps: 11 | 12 | - | **Deploy contract**: 13 | | This step will deploy contracts in the main blockchain. 14 | 15 | - | **Package dapp**: 16 | | This step is used to package and upload frontend resources. 17 | 18 | - | **Register**: 19 | | To render the Dapp, the Ethereum browser (Mist or AlethZero) needs 20 | to access this package. This step will register the URL where the 21 | resources are stored. 22 | 23 | To Deploy your Dapp, Please follow these instructions: 24 | 25 | | Click on ``Deploy``, ``Deploy to Network``. 26 | | This modal dialog displays three parts (see above): 27 | 28 | - **Deploy contract** 29 | 30 | - *Select Scenario* 31 | 32 | “Ethereum node URL” is the location where a node is running, there must 33 | be a node running in order to initiate deployment. 34 | 35 | “Pick Scenario to deploy” is a mandatory step. Mix will execute 36 | transactions that are in the selected scenario (all transactions except 37 | transactions that are not related to contract creation or contract 38 | call). Mix will display all the transactions in the panel below with all 39 | associated input parameters. 40 | 41 | “Gas Used”: depending on the selected scenario, Mix will display the 42 | total gas used. 43 | 44 | - *Deploy Scenario* 45 | 46 | “Deployment account” allow selecting the account that Mix will use to 47 | execute transactions. 48 | 49 | “Gas Price” shows the default gas price of the network. You can also 50 | specify a different value. 51 | 52 | “Deployment cost”: depending on the value of the gas price that you want 53 | to use and the selected scenario. this will display the amount ether 54 | that the deployment need. 55 | 56 | “Deployed Contract”: before any deployment this part is empty. This will 57 | be filled once the deployment is finished by all contract addresses that 58 | have been created. 59 | 60 | “Verifications”. This will shows the number of verifications (number of 61 | blocks generated on top of the last block which contains the last 62 | deployed transactions). Mix keep track of all the transactions. If one 63 | is missing (unvalidated) it will be displayed in this panel. 64 | 65 | - **Package dapp** 66 | 67 | - *Generate local package* 68 | 69 | The action “Generate Package” will create a new folder named 'www', this 70 | folder will contain all the resources and scripts will be mapped 71 | to the current deployed contract. 72 | In order to publish your dapp, you need to host the www folder in a webserver (to 73 | be replace soon by IPFS and SWARM). by default the library web3.js is not included. 74 | If you want to be able to use the dapp in a standard web browser, you wiil need to 75 | include this library. 76 | 77 | 78 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/javascript-console.rst: -------------------------------------------------------------------------------- 1 | .. _sec:javascript-console: 2 | 3 | JavaScript console 4 | ================== 5 | 6 | Mix exposes the following objects into the global window context 7 | 8 | web3 - Ethereum JavaScript API 9 | 10 | contracts: A collection of contract objects. keys represents contracts name. values are is an objects containing the following properties: 11 | 12 | * contract: contract object instance (created as in web3.eth.contract) 13 | 14 | * address: contract address from the last deployed state (see below) 15 | 16 | * interface: contract ABI 17 | 18 | Check the JavaScript API Reference for further information. 19 | 20 | Using the JS console to add transactions and local calls 21 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22 | 23 | In case the name of the contract is “Sample” with a function named 24 | “set”, it is possible to make a transaction to call “set” by writing: 25 | 26 | :: 27 | 28 | contracts["Sample"].contract.set(14) 29 | 30 | If a call can be made this will be done by writing: 31 | 32 | :: 33 | 34 | contracts["Sample"].contract.get.call() 35 | 36 | | It is also possible to use all properties and functions of the web3 37 | object: 38 | | https://github.com/ethereum/wiki/wiki/JavaScript-API 39 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/mix_bc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/contracts-and-transactions/mix/mix_bc.png -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/project-editor.rst: -------------------------------------------------------------------------------- 1 | .. _sec:project-editor: 2 | 3 | Project Editor 4 | ============== 5 | 6 | You can use projects to manage the creation and testing of a dapp. The 7 | project will contain data related to both backend and frontend as well 8 | as the data related to your scenarios (blockchain interaction) for 9 | debugging and testing. The related files will be created and saved 10 | automatically in the project directory. 11 | 12 | Creating a new project 13 | ---------------------- 14 | 15 | The development of a dapp start with the creation of a new project. 16 | Create a new project in the “edit” menu. Enter the project name, e.g. 17 | “Ratings” and select a path for the project file. 18 | 19 | Editing backend contract file 20 | ----------------------------- 21 | 22 | By default, a new project contains a contract “Contract” for backend 23 | development on the blockchain using the Solidity language and the 24 | “index.html” for the frontend. Check the Solidity tutorial for 25 | references. 26 | 27 | Edit the empty default contract “Contract”, e.g. 28 | 29 | :: 30 | 31 | contract Rating { 32 | function setRating(bytes32 _key, uint256 _value) { 33 | ratings[_key] = _value; 34 | } 35 | mapping (bytes32 => uint256) public ratings; 36 | } 37 | 38 | Check the Solidity tutorial for help getting started with the solidity 39 | programming language. 40 | 41 | Save changes 42 | 43 | Editing frontend html files 44 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45 | 46 | Select default index.html file and enter the following code 47 | 48 | :: 49 | 50 | .... 65 | 66 | 67 |

Ratings

68 |
69 | Store: 70 | 71 | 72 | 73 |
74 |
75 | Query: 76 | 77 |
78 |
79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | Then it is possible to add many contract files as well as many HTML, 88 | JavaScript, css files 89 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/scenario-editor.rst: -------------------------------------------------------------------------------- 1 | .. _sec:scenario-editor: 2 | 3 | Scenarios Editor 4 | ================ 5 | 6 | Scenarios can be used to test and debug contracts. 7 | 8 | A scenario is effectively a local blockchain where blocks can be mined 9 | without PoW – otherwise testing would be quite slow ;). 10 | 11 | A scenario consists of a sequence of transactions. Usually, a scenario 12 | would start with the contract creation scenarios of the dapp. In 13 | addition, further transactions can be added to test and debug the dapp. 14 | Scenarios can be modified, i.e. transactions can be removed. Note that a 15 | scenario needs to be rebuilt for modifications to become effective. 16 | Further testing can be done using local JS calls via the JS API. 17 | 18 | In case it’s not open, access the scenario and debugger pane by pressing 19 | F7 or Windows > Show right or the debug button in the upper right corner 20 | of the main window. 21 | 22 | 23 | Creating and setting up a new scenario 24 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 25 | 26 | When you launch Mix for the first time, an empty scenario, i.e. not 27 | containing any transactions, will be created. 28 | Add an account named “MyAccount” and set it’s initial balance to 1 29 | ether. Click OK. 30 | Rename the scenario to “Deploy”. 31 | 32 | 33 | Modifying initial ether balance of an account 34 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 35 | 36 | Actually, we want to do a lot of tests 37 | Edit the Genesis block parameters and set your initial account balance 38 | to 1000 ether. 39 | Rebuild the scenario for the change to become effective. 40 | 41 | 42 | Rebuilding a scenario 43 | ~~~~~~~~~~~~~~~~~~~~~ 44 | 45 | Each time a transaction is modified or an account added, the scenario 46 | has to be rebuilt for modifications to become effective. 47 | Note that if a scenario is rebuilt the web frontend (local storage) 48 | may also need to be reset (this is not done automatically be Mix). 49 | 50 | 51 | Creating a transaction 52 | ~~~~~~~~~~~~~~~~~~~~~~ 53 | 54 | Let’s get some ether sent to Bob. 55 | Create another account named “Bob” with zero ether balance. 56 | Create a new transaction in the scenario pane. Click “Add Tx…” and 57 | send 300 ether to Bob. 58 | Add a block. 59 | 60 | 61 | Altering and reusing scenarios 62 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 63 | 64 | Create a new scenario or start from a scenario with several transactions 65 | that you duplicate first 66 | 67 | Rename the scenario 68 | 69 | Modify scenario by specifying transactions that shall be removed 70 | 71 | Rebuild the scenario 72 | 73 | Display calls 74 | ~~~~~~~~~~~~~ 75 | 76 | A contract call is a function invokation. This is not a transaction as 77 | a contract call cannot change the state. 78 | A contract call is not part of the blockchain but for practical and ux 79 | design reason, it is convenient to display calls at the same 80 | functional level as a transaction. The JS icon warn you that this is 81 | not a transaction but a call. 82 | To show/hide call, click on the menu Scenario -> Display calls. 83 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/state-viewer.rst: -------------------------------------------------------------------------------- 1 | .. _sec:state-viewer: 2 | 3 | State Viewer 4 | ============ 5 | 6 | This panel is located below the block chain panel, in the scenario 7 | view. 8 | Once the blockchain has been run, this panel shows the state of the 9 | blockchain. 10 | 11 | By state we mean all accounts balance (including contract and normal 12 | account), and the storage (global variable of all deployed contract). 13 | The content of this panel is not static, it depends on the selected 14 | transaction on the blockchain panel. 15 | The state shown here is the state resulting of the execution of the 16 | selected transaction. 17 | 18 | 19 | |image0| 20 | 21 | In that case, 2 contracts are deployed, the selected transaction 22 | (deployment of testCtr) is the last one. so the state view shows the 23 | storage of both TestCtr and BasicContract. 24 | 25 | .. |image0| image:: state_mix.png 26 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/state_mix.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/contracts-and-transactions/mix/state_mix.png -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/transaction-debugger.rst: -------------------------------------------------------------------------------- 1 | .. _sec:transaction-debugger: 2 | 3 | Transaction debugger 4 | ==================== 5 | 6 | Mix supports both Solidity and assembly level contract code debugging. 7 | You can toggle between the two modes to retrieve the relevant 8 | information you need. 9 | 10 | At any execution point the following information is available: 11 | 12 | VM stack – See Yellow Paper for VM instruction description 13 | 14 | Call stack – Grows when contract is calling into another contract. 15 | Double click a stack frame to view the machine state in that frame 16 | 17 | Storage – Storage data associated with the contract 18 | 19 | Memory – Machine memory allocated up to this execution point 20 | 21 | Call data – Transaction or call parameters 22 | 23 | Accessing the debug mode 24 | ------------------------ 25 | 26 | When transaction details are expanded, you can switch to the debugger 27 | view by clicking on the “Debug Transaction” button 28 | 29 | Toggling between debug modes and stepping through transactions 30 | -------------------------------------------------------------- 31 | 32 | This opens the Solidity debugging mode. Switch between Solidity and EVM 33 | debugging mode using the Menu button (Debug -> Show VM code) 34 | 35 | - Step through a transaction in solidity debugging mode 36 | 37 | - Step through a transaction in EVM debugging mode 38 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/mix/transaction-explorer.rst: -------------------------------------------------------------------------------- 1 | .. _sec:transaction-explorer: 2 | 3 | Transaction Explorer 4 | ==================== 5 | 6 | Using the transaction pane 7 | 8 | The transaction pane enables you to explore transactions receipts, 9 | including 10 | 11 | * Input parameters 12 | 13 | * Return parameters 14 | 15 | * Event logs 16 | 17 | To display the transaction explorer, click on the down triangle icon 18 | which is on the right of each transaction, this will expand 19 | transaction details: 20 | 21 | 22 | |image0| 23 | 24 | Then you can either copy the content of this transaction in the 25 | clipboard, Edit the current transaction (you will have to rerun the 26 | blockchain then), or debug the transaction. 27 | 28 | .. |image0| image:: mix_bc.png 29 | -------------------------------------------------------------------------------- /source/contracts-and-transactions/web3-base-layer-services.rst: -------------------------------------------------------------------------------- 1 | ******************************************************************************** 2 | Web3 Base Layer Services 3 | ******************************************************************************** 4 | 5 | In addition to the Ethereum blockchain, more components are being developed that decentralise other important aspects of web applications. 6 | 7 | .. image:: ../img/ethereum-protocols.png 8 | 9 | Swarm - Decentralised data storage and distribution 10 | ================================================================================ 11 | 12 | Swarm is a peer to peer data sharing network in which files are addressed by the hash of their content. Similar to Bittorrent, it is possible to fetch the data from many nodes at once and as long as a single node hosts a piece of data, it will remain accessible everywhere. This approach makes it possible to distribute data without having to host any kind of server - data accessibility is location independent. 13 | 14 | Other nodes in the network can be incentivised to replicate and store the data themselves, obviating the need for hosting services when the original nodes are not connected to the network. 15 | 16 | 17 | Whisper - Decentralised messaging 18 | ================================================================================ 19 | 20 | A protocol for private, secure communication directly between nodes. 21 | 22 | -------- 23 | 24 | Furthermore, standard contracts are being created to make the development and usage of distributed applications easier: 25 | 26 | Name registry 27 | ================================================================================ 28 | 29 | Because dapps can be stored anywhere, including the Swarm network, the name registry maps names to their content or location. This is a decentralised alternative to the Domain Name System (DNS). 30 | 31 | See https://github.com/ethereum/EIPs/issues/26 32 | 33 | Contract registry 34 | ================================================================================ 35 | 36 | To publish the source code of a specific contract, its address has to be mapped to it. The contract registry stores this mapping. Users can then look up this mapping and verify the contract byte code. 37 | 38 | See 39 | 40 | * global registrar code 41 | 42 | * namereg API 43 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/architecture.rst: -------------------------------------------------------------------------------- 1 | .. _Architecture: 2 | 3 | ################################################################################ 4 | Architecture 5 | ################################################################################ 6 | 7 | .. image:: ../../img/dependency_graph.svg 8 | 9 | - bench: trie benchmarking 10 | - cmake: cmake files for build system, contains specification of inter-dependencies 11 | - eth: A command-line Ethereum full-node that can be controlled via RPC. 12 | - ethkey: stand-alone key management 13 | - ethminer: stand-alone ethash miner 14 | - ethvm: stand-alone EVM execution utility 15 | - evmjit: library for the EVM just-in-time compiler 16 | - libdevcore: data structures, utilities, rlp, trie, memory db 17 | - libdevcrypto: crypto primitives. Depends on libsecp256k1 and libcrypto++. 18 | - libp2p: core peer to peer networking implementation (excluding specific sub-protocols) 19 | - libethash: ethash mining POW algorithm implementation 20 | - libethash-cl: ethash mining code for GPU mining (OpenCL) 21 | - libethashseal: generic wrapper around the POW block seal engine. Also contains the genesis states for all ethash-based chains. 22 | - libethcore: collection of core data structures and concepts 23 | - libethereum: main consensus engine (minus EVM). Includes the State and BlockChain classes. 24 | - libevm: Ethereum Virtual Machine implementation (interpreter). 25 | - libevmasm: EVM assembly tools, also contains the optimizer. 26 | - libevmcore: elementary data structures of the EVM, opcodes, gas costs, ... 27 | - libweb3jsonrpc: json-rpc server-side endpoint, provides http and IPC (unix socket, windows pipe) connectors 28 | - libwebthree: service connectors for ethereum, swarm/ipfs and whisper. 29 | - libwhisper: whisper implementation 30 | - rlp: stand-alone rlp en-/decoder 31 | - testeth: tests for the modules formerly within the **libethereum** repo 32 | - testweb3core: tests for the modules formerly within the **libweb3core** repo 33 | - testweb3: tests for the modules formerly within the **webthree** repo 34 | - utils/json_spirit: JSON parser written for Boost's Spirit library. 35 | - utils/libscrypt: scrypt implementation 36 | - utils/secp256k1: implementation of the SECP 256k1 ECDSA signing algorithm. 37 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/android.rst: -------------------------------------------------------------------------------- 1 | 2 | Building for Android 3 | -------------------------------------------------------------------------------- 4 | 5 | We don't currently have a working Android build, though that is 6 | `on the roadmap `_ 7 | for `doublethinkco `_. Android uses the Linux kernel, 8 | but has a `different API `_ 9 | than the ARM Linux cross-builds, meaning that specific binaries will be required. 10 | 11 | ARM Linux distros use the GLIBC runtime library, where Android uses bionic. -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/beaglebone.rst: -------------------------------------------------------------------------------- 1 | 2 | Building for BeagleBone Black 3 | -------------------------------------------------------------------------------- 4 | `EthEmbedded `_ 5 | maintain build scripts for BBB on Github in the 6 | `BBB-Eth-Install `_ repository. 7 | It is also possible to cross-build for this platform. 8 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/freebsd.rst: -------------------------------------------------------------------------------- 1 | 2 | ################################################################################ 3 | Building for FreeBSD 4 | ################################################################################ 5 | 6 | NOTE - Once the packages are in the FreeBSD main ports this guide should be 7 | changed to something much more simple 8 | 9 | Install the ports manually 10 | ================================================================================ 11 | For some of this steps you must require a root access to modify the ports directory. 12 | 13 | The webthree-umbrella depends on [libjson-rpc-cpp.shar](https://raw.githubusercontent.com/enriquefynn/webthree-umbrella-port/master/libjson-rpc-cpp.shar) that is also not in the ports system. 14 | 15 | First you need to download the shar file and place it on your ports directory under the "devel" session, usually 16 | /usr/ports/devel :: 17 | 18 | curl https://raw.githubusercontent.com/enriquefynn/webthree-umbrella-port/master/libjson-rpc-cpp.shar > /usr/ports/devel/libjson-rpc-cpp.shar 19 | 20 | Now we execute the script with: :: 21 | 22 | cd /usr/ports/devel 23 | sh libjson-rpc-cpp.shar 24 | 25 | This will create the libjson-rpc-cpp port. Now you should do the same for the webthree-umbrella port, we should get the [webthree-umbrella](https://raw.githubusercontent.com/enriquefynn/webthree-umbrella-port/master/webthree-umbrella.shar) file and create the port under "net-p2p" directory. :: 26 | 27 | curl https://raw.githubusercontent.com/enriquefynn/webthree-umbrella-port/master/webthree-umbrella.shar> /usr/ports/net-p2p/webthree-umbrella.shar 28 | cd /usr/ports/net-p2p 29 | sh webthree-umbrella.shar 30 | 31 | 32 | Build and Install 33 | ================================================================================ 34 | 35 | Now you can navigate to the webthree-umbrella directory and install the port: :: 36 | 37 | cd /usr/ports/net-p2p/webthree-umbrella 38 | make install clean 39 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/index.rst: -------------------------------------------------------------------------------- 1 | .. _Building from source: 2 | 3 | Building from source 4 | ================================================================================ 5 | 6 | Overview 7 | -------------------------------------------------------------------------------- 8 | 9 | The **cpp-ethereum** codebase lives on Github.com in the 10 | `cpp-ethereum `_ repository. 11 | 12 | Between October 2015 and August 2016 it was split into various repositories 13 | which were grouped as sub-modules under the 14 | `webthree-umbrella `_ repository, 15 | and you will likely see many references to **webthree-umbrella** online. Those 16 | all refer to the **cpp-ethereum** codebase during that period of its development. 17 | 18 | We use a common `CMake `_ build system to generate 19 | platform-specific build files, meaning that the workflow is very similar 20 | whatever operating system you use: 21 | 22 | * Install build tools and external packages (these are platform dependent) 23 | * Clone the source code from the **webthree-umbrella** git repository 24 | * Run CMake to generate a build file (makefile, Visual Studio solution, etc) 25 | * Build it 26 | 27 | 28 | Platform-specific instructions 29 | -------------------------------------------------------------------------------- 30 | 31 | .. toctree:: 32 | :maxdepth: 2 33 | 34 | linux.rst 35 | windows.rst 36 | macos.rst 37 | freebsd.rst 38 | android.rst 39 | ios.rst 40 | rpi.rst 41 | odroid.rst 42 | beaglebone.rst 43 | wandboard.rst 44 | linux-arm.rst 45 | 46 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/ios.rst: -------------------------------------------------------------------------------- 1 | 2 | Building for iOS 3 | -------------------------------------------------------------------------------- 4 | 5 | We don't currently have a working iOS build, though that is 6 | `on the roadmap `_ 7 | for `doublethinkco `_. iOS is a UNIX-like operating 8 | system based on Darwin (BSD) using ARM chips. This is a 9 | `different API `_ 10 | than the ARM Linux cross-builds, meaning that specific binaries will be required. 11 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/linux-arch.rst: -------------------------------------------------------------------------------- 1 | 2 | ################################################################################ 3 | Installing dependencies for Arch Linux 4 | ################################################################################ 5 | 6 | Compiling webthree-umbrella on Arch Linux requires dependencies from both the `official repositories `_ 7 | and the `Arch User Repository (AUR) `_. To install packages from the official repositories `pacman `_ is used. 8 | For installation of packages from the AUR, a number of AUR helpers is `available `_. For this guide, `yaourt `_ AUR helper is used. 9 | 10 | Installing dependencies 11 | ================================================================================ 12 | 13 | # from official repositories 14 | sudo pacman -Sy git base-devel cmake boost crypto++ leveldb llvm miniupnpc libcl opencl-headers libmicrohttpd qt5-base qt5-webengine 15 | 16 | # from AUR 17 | yaourt -Sy libjson-rpc-cpp 18 | 19 | 20 | Compiling the source code 21 | ================================================================================ 22 | 23 | During this step, an installation folder for the Ethereum can be specified. 24 | Specification of the folder is optional though. If not given, the 25 | binary files will be located in the build folder. However, for this guide, 26 | it is assumed that the Ethereum files will be installed under `/opt/eth`. The reason for 27 | using `/opt` is that it makes much easier to delete the Ethereum files later on, 28 | as compared to having them installed under, e.g., `/usr`. Also `/opt` is commonly used 29 | to install software that is not managed by packaging systems, such as manually 30 | compiled programs. :: 31 | 32 | # enter webthree-umbrella folder after cloning its github repository 33 | cd webthree-umbrella 34 | 35 | # make a build folder and enter into it 36 | mkdir -p build && cd build 37 | 38 | # create build files and specify Ethereum installation folder 39 | cmake .. -DCMAKE_INSTALL_PREFIX=/opt/eth 40 | 41 | # compile the source code 42 | make 43 | 44 | # alternatively it is possible to specify number of compilation threads 45 | # for example to use 4 threads execute make as follows: 46 | # make -j 4 47 | 48 | # install the resulting binaries, shared libraries and header files into /opt 49 | sudo make install 50 | 51 | 52 | After successful compilation and installation, Ethereum binaries can be found in `/opt/eth/bin`, 53 | shared libraries in `/opt/eth/lib`, and header files in `/opt/eth/include`. 54 | 55 | 56 | Specifying Ethereum libraries path 57 | ================================================================================ 58 | 59 | Since Ethereum was installed in `/opt/eth`, executing its binaries can result in linker error due to not being 60 | able to find the Ethereum shared libraries. To rectify this issue, it is needed to add the folder containing 61 | Ethereum shared libraries into `LD_LIBRARY_PATH` environmental variable: :: 62 | 63 | # update ~/.bashrc 64 | echo "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/eth/lib" >> ~/.bashrc 65 | 66 | # reload ~/.bashrc 67 | source ~/.bashrc 68 | 69 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/linux-arm.rst: -------------------------------------------------------------------------------- 1 | 2 | Building for Linux for ARM (cross builds) 3 | -------------------------------------------------------------------------------- 4 | `doublethinkco `_ 5 | maintain a Docker-based cross-build infrastructure which is 6 | hosted on Github in the 7 | `cpp-ethereum-cross 8 | `_ 9 | repository. 10 | 11 | At the time of writing, these cross-built binaries have been successfully used 12 | on the following devices: 13 | 14 | - Jolla Phone (Sailfish OS) 15 | - Nexus 5 (Sailfish OS) 16 | - Meizu MX4 Ubuntu Edition (Ubuntu Phone) 17 | - Raspberry Pi Model B+, Rpi2 (Raspbian) 18 | - Odroid XU3 (Ubuntu MATE) 19 | - BeagleBone Black (Debian) 20 | - Wandboard Quad (Debian) 21 | - C.H.I.P. (Debian) 22 | 23 | Still TODO: 24 | 25 | - Tizen 26 | - Android 27 | - iOS -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/linux-fedora.rst: -------------------------------------------------------------------------------- 1 | 2 | ################################################################################ 3 | Installing dependencies for Fedora 4 | ################################################################################ 5 | 6 | Fedora 24 7 | -------------------------------------------------------------------------------- 8 | Steps: :: 9 | 10 | dnf install git automake autoconf libtool cmake gcc gcc-c++ xkeyboard-config \ 11 | leveldb-devel boost-devel gmp-devel cryptopp-devel miniupnpc-devel \ 12 | qt5-qtbase-devel qt5-qtdeclarative-devel qt5-qtquick1-devel qt5-qtwebkit-devel \ 13 | mesa-dri-drivers snappy-devel ncurses-devel readline-devel curl-devel \ 14 | python-devel jsoncpp-devel argtable-devel libmicrohttpd-devel 15 | 16 | 17 | Make sure you have cloned the repository recursively. If not please clone the submodules of the respository as well. 18 | It may happen that after `# make install`, you might not be able to run eth because of linking errors. In that case you have to add the shared objects of eth into your load path for shared objects. 19 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/linux-opensuse.rst: -------------------------------------------------------------------------------- 1 | 2 | ################################################################################ 3 | Installing dependencies for openSUSE 4 | ################################################################################ 5 | 6 | Here is how to get the dependencies needed to build the latest 7 | webthree-umbrella on OpenSUSE. This was done on Leap 42.1 and 42.2, but there should be equivalent packages available for Tumbleweed and 13.x. 8 | 9 | First install dependencies provided by the main repos: :: 10 | 11 | zypper in git automake autoconf libtool cmake gcc gcc-c++ \ 12 | xkeyboard-config leveldb-devel boost-devel gmp-devel \ 13 | libcryptopp-devel libminiupnpc-devel libqt5-qtbase-common-devel \ 14 | libqt5-qtdeclarative-devel libQtWebKit-devel libqt5-qtwebengine-devel \ 15 | libQt5Concurrent-devel Mesa ncurses-devel readline-devel libcurl-devel \ 16 | llvm llvm-clang llvm-clang-devel llvm-devel libLLVM binutils \ 17 | libmicrohttpd-devel jsoncpp-devel opencl-headers-1.2 zlib-devel 18 | 19 | If Opencl-headers-1.2 is not found, you can install it manually from the CLI: 20 | zypper addrepo http://download.opensuse.org/repositories/home:valmar73:crystfel-releases/openSUSE_13.1/home:valmar73:crystfel-releases.repo 21 | zypper refresh 22 | zypper install opencl-headers-1.2 23 | 24 | 25 | It may be possible to use the generic `libOpenCL1`, but I have only tested with the 26 | AMD proprietary package from the AMD drivers repo `fglrx64_opencl_SUSE421` 27 | 28 | These packages are not in the standard repos but can be found using the OpenSUSE 29 | build service package search and YaST 1-Click Install: 30 | 31 | - libargtable2-devel 32 | - libv8-3 33 | - v8-devel 34 | 35 | If you also have v8 from the chromium repo installed the devel package will 36 | default to the 4.x branch which will not work. Use YaST or zypper to downgrade 37 | this package to 3.x 38 | 39 | Note that Opencl-headers is used to mine the chain with GPU. If this is not a requirement, you can bypass it when creating the makefile (cmake -DETHASHCL=0 .. ) instead of (cmake ..) 40 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/odroid.rst: -------------------------------------------------------------------------------- 1 | 2 | Building for Odroid XU3/XU4 3 | -------------------------------------------------------------------------------- 4 | `EthEmbedded `_ 5 | maintain build scripts for both of these Odroid models. Support 6 | for a broader range of Odroid devices is likely in the future. 7 | They are on Github in the 8 | `OdroidXU3-Eth-Install `_ repository. 9 | It is also possible to cross-build for these platforms. 10 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/rpi.rst: -------------------------------------------------------------------------------- 1 | 2 | Building for Raspberry Pi Model A, B+, Zero, 2 and 3 3 | -------------------------------------------------------------------------------- 4 | `EthEmbedded `_ 5 | maintain build scripts for all Raspberry Mi models. 6 | They are on Github in the 7 | `Raspi-Eth-Install `_ repository. 8 | It is also possible to cross-build for these platforms. 9 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/building-from-source/wandboard.rst: -------------------------------------------------------------------------------- 1 | 2 | Building for WandBoard 3 | -------------------------------------------------------------------------------- 4 | `EthEmbedded `_ 5 | maintain build scripts for the WandBoard on Github in the 6 | `WandBoard-Eth-Install `_ repository. 7 | It is also possible to cross-build for this platform. 8 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/contributing.rst: -------------------------------------------------------------------------------- 1 | ################################################################################ 2 | Contributing 3 | ################################################################################ 4 | 5 | Help in whatever form is always more than welcome. 6 | 7 | You can just start by :ref:`Building from source` and familiarizing yourself 8 | with the :ref:`Architecture`. If something strange happens, please report an 9 | issue (see below). 10 | 11 | Once you get to know the technology, you can try to answer questions from 12 | other users (we do not always have time for that) either on 13 | `cpp-ethereum gitter `_, 14 | `stackexchange `_ or just comment on issues. 15 | 16 | If you are a C++ developer, you can help by submitting pull requests (see below). 17 | 18 | We try to keep a list of `good tasks to start with `_. 19 | Please get in contact on gitter if you have any questions or suggestions. 20 | 21 | The backlog is kept in github issues with an overview in our 22 | `waffle board `_. 23 | 24 | The waffle board is also useful to keep track of pull requests pending reviews 25 | (if you switch the filter on the top right to "pull requests only"). 26 | 27 | 28 | How to Report Issues 29 | -------------------- 30 | 31 | Please report issues against the specific projects using GitHub Issues: 32 | 33 | - `cpp-ethereum issues `_ 34 | - `cpp-dependencies issues `_ 35 | - `evmjit issues `_ 36 | 37 | Try to mention which version of the software you used and on which platform (Windows, MacOS, Linux, ...), 38 | how you got into the situation (what did you do), what did you expect to happen 39 | and what actually happened. 40 | 41 | How to Submit Pull Requests / Workflow 42 | -------------------------------------- 43 | 44 | Set up your workspace using the :ref:`Building from source` instructions. 45 | To contribute you will need to fork/clone the repositories. 46 | 47 | Please also respect the `Coding Standards `_. 48 | 49 | If you encounter any problems, please ask on gitter. 50 | 51 | Create pull requests against the `develop` branch of the repository you 52 | made changes in. Try not to include any merges with the pull request and rebase 53 | if necessary. If you can set labels on a pull request, set it to `please review` 54 | and also ask for a review in `gitter `_. 55 | 56 | You can also do reviews on others' pull requests. In this case either comment 57 | with "looks good" or set the label if you can. If at least one core developer 58 | apart from the author is confident about the change, it can be merged. 59 | If the reviewer thinks that corrections are necessary, they put he label `got issues`. 60 | If the author addressed all comments, they again put `please review` or comment 61 | appropriately. 62 | 63 | Automation runs on `Appveyor `_ 64 | and `TravisCI `_. 65 | 66 | Thanks for helping and have fun! 67 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/current-status.rst: -------------------------------------------------------------------------------- 1 | 2 | ################################################################################ 3 | Current status 4 | ################################################################################ 5 | 6 | We blog about the codebase periodically on the 7 | `Official Ethereum blog `_ and elsewhere. Here are 8 | some recent articles from the development team: 9 | 10 | * `Ethereum DEV Update: C++ Roadmap `_ (February 2016) 11 | * `C++ DEV Update: Announcing Remix `_ (May 2016) 12 | * `C++ DEV Update – July edition `_ (July 2016) 13 | * `Ethereum Everywhere `_ (July 2016) 14 | * `C++ re-licensing plan `_ (July 2016) 15 | 16 | We `simplified the project naming 17 | `_ at Homestead 18 | (March 2016), although some naming shadows of the past still linger. With the 19 | homecoming we have another name to retire - **webthree-umbrella**. 20 | 21 | At the time of writing (August 2016), we are just completing our "Homecoming", 22 | where the code has been reconsolidated into the 23 | `ethereum/cpp-ethereum `_ 24 | repository. From October 2015 until August 2016 25 | it was split across multiple repositories under 26 | `ethereum/webthree-umbrella `_ 27 | 28 | The re-licensing plan is the culmination of a very long-term plan to 29 | `liberalize the core `_. An 30 | effort was begun in 2015 to re-license the cpp-ethereum core as MIT, but it was 31 | never completed. 32 | 33 | This is a revival of that effort, especially with a view 34 | towards the potential for collaboration with the 35 | `Linux Foundation `_'s 36 | `Hyperledger `_ project, and with other corporations 37 | outside of Hyperledger who wish to build Ethereum private/consortium chain 38 | solutions similar to `HydraChain `_. 39 | The `Rubix by Deloitte `_ project is an example 40 | of that approach. 41 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/index.rst: -------------------------------------------------------------------------------- 1 | .. _cpp-ethereum: 2 | 3 | ################################################################################ 4 | cpp-ethereum 5 | ################################################################################ 6 | 7 | .. image:: ../../img/cpp_35k9.png 8 | :height: 200px 9 | :width: 200px 10 | 11 | .. image:: ../../img/ETHEREUM-ICON_Black.png 12 | :height: 200px 13 | :width: 200px 14 | 15 | 16 | Quick Start 17 | ================================================================================ 18 | 19 | - Welcome to the Ethereum C++ project :-) 20 | - The GitHub repository for this project is `ethereum/cpp-ethereum `_ 21 | - Automation runs on `Appveyor `_ and `TravisCI `_. 22 | - We have instructions for :ref:`Installing binaries` and :ref:`Building from source`. 23 | - Most project communication happens in our `User `_ and `Developer `_ Gitter channels. 24 | - Issues are tracked in our `Github issue tracker `_. 25 | - cpp-ethereum is extremely portable and is used on a :ref:`very broad range of platforms `. 26 | 27 | 28 | Details 29 | ================================================================================ 30 | 31 | .. toctree:: 32 | :maxdepth: 2 33 | 34 | current-status.rst 35 | building-from-source/index.rst 36 | installing-binaries/index.rst 37 | contributing.rst 38 | architecture.rst 39 | portability.rst 40 | running.rst -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/docker.rst: -------------------------------------------------------------------------------- 1 | Docker 2 | ====== 3 | 4 | We are hosting latest development snapshots (and in the future also 5 | releases) at docker hub. You can run these images as follows: 6 | 7 | Preparation 8 | ----------- 9 | Before running the image, you should pull the latest version and prepare 10 | the data directories:: 11 | 12 | # get the lastest version from dockerhub (redo for updates). 13 | docker pull ethereum/client-cpp 14 | # create mountable datadirs; blockchain/account data will be stored there 15 | mkdir -p ~/.ethereum ~/.web3 16 | 17 | These steps need to be done only once. For upgrading to a new version do 18 | the ``docker pull ...`` again. 19 | 20 | Execution 21 | --------- 22 | The simplest version is to run:: 23 | 24 | docker run --rm -it \ 25 | -p 127.0.0.1:8545:8545 \ 26 | -p 0.0.0.0:30303:30303 \ 27 | -v ~/.ethereum:/.ethereum \ 28 | -v ~/.web3:/.web3 \ 29 | -e HOME=/ \ 30 | --user $(id -u):$(id -g) \ 31 | ethereum/client-cpp 32 | 33 | This will write data to ``~/.ethereum`` and ``~/.web3/`` on your host and run 34 | the client with your user's permissions. For most cases this should be 35 | sufficient and the client should behave exactly as if run from a local build. 36 | 37 | If you want the rpc port reachable from the network (not recommended, never do this 38 | if you have valuable data or private keys on your machine), replace 39 | ``-p 127.0.0.1:8545:8545`` with ``-p 0.0.0.0:8545:8545``. 40 | 41 | For convenience, you can create the file ``/usr/local/bin/docker-eth`` with the 42 | following content:: 43 | 44 | #!/usr/bin/env sh 45 | mkdir -p ~/.ethereum ~/.web3 46 | if ! id -nG $(whoami)|grep -qw "docker"; then SUDO='sudo'; else SUDO=''; fi 47 | $SUDO docker run --rm -it \ 48 | -p 127.0.0.1:8545:8545 \ 49 | -p 0.0.0.0:30303:30303 \ 50 | -v ~/.ethereum:/.ethereum \ 51 | -v ~/.web3:/.web3 \ 52 | -e HOME=/ \ 53 | --user $(id -u):$(id -g) \ 54 | ethereum/client-cpp $@ 55 | 56 | And make it executable with ``chmod +x /usr/local/bin/docker-eth``. Now you can 57 | start the client with:: 58 | 59 | docker-eth 60 | 61 | **Note:** The ``docker-eth`` command will accept the same flags as the raw ``eth`` 62 | command. 63 | 64 | If you want to attach to the node, you can either just use mist (it will 65 | detect the node automatically), use ``geth attach ipc:/$HOME/.ethereum/geth.ipc`` 66 | or ethereum-console as described in :ref:`Running cpp-ethereum`. 67 | 68 | Advanced usage: 69 | --------------- 70 | 71 | Due to https://github.com/docker/libnetwork/issues/552 multicast is not working 72 | yet without ``--net=host``. You can still run the client with network isolation 73 | and use ``-p 127.0.0.1:8545:8545 -p 30303:30303 -p 30303:30303/udp`` for 74 | publishing the rpc, discovery and p2p ports. If you want to be discoverable 75 | from the outside, you will need to 76 | 77 | - add your public ip address with the ``--public-ip`` flag, 78 | - create a port forwarding with your NAT 79 | 80 | (syncing will still work without it). 81 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/index.rst: -------------------------------------------------------------------------------- 1 | 2 | .. _Installing binaries: 3 | 4 | Installing binaries 5 | ================================================================================ 6 | 7 | The cpp-ethereum development team and the broader Ethereum community publish 8 | binary releases in many different forms for a variety of platforms. This 9 | aims to be a complete list of those releases. 10 | 11 | If you are aware of other third-party packaging efforts, please let us know on 12 | the `cpp-ethereum gitter channel `_, 13 | and we will add them to this list. 14 | 15 | .. toctree:: 16 | :maxdepth: 2 17 | 18 | docker.rst 19 | linux-ubuntu-snap.rst 20 | linux-ubuntu-ppa.rst 21 | windows-chocolatey.rst 22 | osx-homebrew.rst 23 | linux-sbcs.rst 24 | linux-cross-builds.rst 25 | linux-arch-aur.rst 26 | linux-mageia.rst 27 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/linux-arch-aur.rst: -------------------------------------------------------------------------------- 1 | 2 | ArchLinux User Repository (AUR) 3 | -------------------------------------------------------------------------------- 4 | 5 | Arch Linux packages are community maintained by 6 | `Afri Schoedon `_. 7 | 8 | Check out the following packages 9 | on `aur.archlinux.org `_. 10 | 11 | - `ethereum `_ (stable, latest release) 12 | - `ethereum-git `_ (unstable, latest develop) 13 | 14 | To build and install the package, follow the `AUR installing package `_ instructions: 15 | 16 | - Acquire the tarball which contains the PKGBUILD 17 | - Extract the tarball 18 | - Run :code:`makepkg -sri` as simple user in the directory where the files are saved 19 | - Install the resulting package with :code:`pacman -U` as superuser 20 | 21 | You can also use `AUR helpers `_ 22 | like :code:`yaourt` or :code:`pacaur` to install the packages directly on your system. 23 | 24 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/linux-cross-builds.rst: -------------------------------------------------------------------------------- 1 | 2 | Linux ARM cross-builds for mobile, wearables, SBCs 3 | -------------------------------------------------------------------------------- 4 | 5 | `Bob Summerwill `_, of 6 | `doublethinkco `_ cross-builds 7 | `ARM binaries `_ 8 | which work on a very broad variety of hardware, from mobile and wearables 9 | Linux distros (Sailfish OS, Tizen OS, Ubuntu Touch) to the same SBCs which 10 | `EthEmbedded `_ target - and more. 11 | doublethinkco was a 12 | `BlockGrantX recipient 13 | `_ in Feb 2016. 14 | 15 | See the 16 | `cpp-ethereum-cross README 17 | `_ 18 | for a full matrix of platforms and known status. 19 | 20 | Here are the cross-build binaries from doublethinkco: 21 | `RELEASED – Cross-build eth binaries for Homestead 22 | `_. 23 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/linux-mageia.rst: -------------------------------------------------------------------------------- 1 | 2 | Mageia Cauldron (6) RPMs 3 | -------------------------------------------------------------------------------- 4 | 5 | `Luis Daniel Lucio Quiroz `_ has created 6 | `RPMs for Mageia Cauldron (6) `_. 7 | 8 | cpp-ethereum is available in the non-free repository of Mageia 6. You will need to enable it. Once this is done, to install you just need to run the URPMI command (or RPMDRAKE if you are using GUI): :: 9 | 10 | urpmi cpp-ethereum 11 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/linux-sbcs.rst: -------------------------------------------------------------------------------- 1 | 2 | Raspberry Pi, Odroid, BeagleBone Black, Wandboard 3 | -------------------------------------------------------------------------------- 4 | 5 | `John Gerryts `_ of 6 | `EthEmbedded `_ builds binary images for a variety of 7 | SBCs at major milestones, in addition to testing and maintaining build scripts 8 | for these devices. EthEmbedded was a `devgrant recipient 9 | `_ in May 2015. 10 | He builds binaries for both eth and geth. 11 | 12 | Here are the `Homestead binaries `_ 13 | from `EthEmbedded `_ 14 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/linux-ubuntu-ppa.rst: -------------------------------------------------------------------------------- 1 | 2 | Ubuntu PPA (Personal Package Archive) 3 | ================================================================================ 4 | 5 | **NOTE - At the time of writing (31st August 2016), the PPAs are broken, 6 | following significant repository reorganizations and a change of automation 7 | process. We have not hooked the PPA generation steps back together 8 | yet, though this will happen in the very near future. In the meantime, 9 | please follow the** :ref:`Building Linux from source` **instructions**, or 10 | install :ref:`linux-ubuntu-snap` (currently in testing). 11 | 12 | We have set up PPA instances for the following Ubuntu versions: 13 | 14 | - `Ubuntu Trusty Tahr (14.04) `_ 15 | - `Ubuntu Utopic Unicorn (14.10) `_ 16 | - `Ubuntu Vivid Vervet (15.04) `_ 17 | - `Ubuntu Wily Werewolf (15.10) `_ 18 | - `Ubuntu Xenial Xerus (16.04) `_ 19 | 20 | **We only support 64-bit builds.** It may be possible to get the 21 | client working for Ubuntu 32-bit, by building from source and disabling 22 | EVMJIT and maybe other features too. We might accept pull-requests to 23 | add such support, but we will not put any of our development time into 24 | supporting Ubuntu 32-bit builds. 25 | 26 | For the latest stable version: :: 27 | 28 | sudo apt-get install software-properties-common 29 | sudo add-apt-repository ppa:ethereum/ethereum 30 | sudo apt-get update 31 | sudo apt-get install cpp-ethereum 32 | 33 | If you want to use the cutting edge developer version: :: 34 | 35 | sudo apt-get install software-properties-common 36 | sudo add-apt-repository ppa:ethereum/ethereum 37 | sudo add-apt-repository ppa:ethereum/ethereum-dev 38 | sudo apt-get update 39 | sudo apt-get install cpp-ethereum 40 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/linux-ubuntu-snap.rst: -------------------------------------------------------------------------------- 1 | .. _linux-ubuntu-snap: 2 | 3 | Ubuntu snap 4 | ================================================================================ 5 | 6 | In any of the `supported Linux distros `_: :: 7 | 8 | sudo snap install cpp-ethereum --edge --devmode 9 | cpp-ethereum.eth 10 | 11 | (Note that this is an experimental and unstable release, at the moment) 12 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/osx-homebrew.rst: -------------------------------------------------------------------------------- 1 | 2 | OS X Homebrew packages 3 | -------------------------------------------------------------------------------- 4 | 5 | We generate Homebrew packages within our automated build system for the 6 | following OS X / Mac versions: 7 | 8 | - `OS X Mavericks (10.9) `_ 9 | - `OS X Yosemite (10.10) `_ 10 | - `OS X El Capitan (10.11) `_ 11 | 12 | **We only support 64-bit builds.** 13 | 14 | If your system does not support these OS X versions then you 15 | are out of luck. Sorry! 16 | 17 | All OS X builds require you to `install the Homebrew `_ 18 | package manager before doing anything else. Here's how to `uninstall Homebrew 19 | `_, 20 | if you ever want to start again from scratch. 21 | 22 | To install the Ethereum C++ components from Homebrew, execute these commands: :: 23 | 24 | brew update 25 | brew upgrade 26 | brew tap ethereum/ethereum 27 | brew install cpp-ethereum 28 | brew linkapps cpp-ethereum 29 | 30 | Here is the `Homebrew Formula 31 | `_ 32 | which details all the supported command-line options. 33 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/installing-binaries/windows-chocolatey.rst: -------------------------------------------------------------------------------- 1 | 2 | Windows Chocolatey NuGet packages 3 | -------------------------------------------------------------------------------- 4 | 5 | We aren't generating `Chocolatey `_ packages at 6 | the time of writing, though we have done so in the past. 7 | 8 | For anybody who isn't already familiar with the technology, this is essentially 9 | `apt-get for Windows` - a global silent installer for tools. 10 | 11 | We would like to 12 | `support Chocolatey `_ 13 | again in the near future for all the same reasons we support Homebrew on OS X 14 | and have PPAs for Ubuntu. For technically competent users, doing 15 | command-line operations like so would be very convenient: :: 16 | 17 | choco install cpp-ethereum 18 | choco update cpp-ethereum 19 | -------------------------------------------------------------------------------- /source/ethereum-clients/cpp-ethereum/portability.rst: -------------------------------------------------------------------------------- 1 | .. _cpp-ethereum-portability: 2 | 3 | ################################################################################ 4 | Portability 5 | ################################################################################ 6 | 7 | The Ethereum C++ client code is exceedingly portable, and is being successfully 8 | used on a huge range of different operating systems and devices. 9 | 10 | We continue to expand our range and are very open to pull-requests which add 11 | support for additional operating systems, compilers or devices. 12 | 13 | 14 | Operating systems verified as working 15 | -------------------------------------------------------------------------------- 16 | 17 | - Linux 18 | - Alpine Linux 19 | - Arch Linux 20 | - Debian 8 (Jessie and Stretch) 21 | - Fedora 20 22 | - Fedora 21 23 | - Fedora 22 24 | - openSUSE Leap 42.1 25 | - PureOS 2.1 26 | - Raspbian 27 | - Sailfish OS 2.0 28 | - Ubuntu 14.04 (Trusty) 29 | - Ubuntu 14.10 (Utopic) 30 | - Ubuntu 15.04 (Vivid) 31 | - Ubuntu 15.10 (Wily) 32 | - Ubuntu 16.04 (Xenial) 33 | - Ubuntu Touch 34 | - Ubuntu 15.04 MATE 35 | - BSD 36 | - FreeBSD 37 | - OS X 38 | - OS X Yosemite (10.10) 39 | - OS X El Capitan (10.11) 40 | - OS X 10.10 (Yosemite Server 4.0) 41 | - OS X 10.11 (Yosemite Server 5.0) 42 | - OS X 10.11 (Yosemite Server 5.1) 43 | - Windows 44 | - Windows 7 45 | - Windows 8 46 | - Windows 8.1 47 | - Windows 10 48 | - Windows Server 2012 R2 49 | 50 | 51 | Operating systems - work in progress 52 | -------------------------------------------------------------------------------- 53 | 54 | - Linux 55 | - Maemo 56 | - MeeGo 57 | - Tizen 58 | - BSD 59 | - iOS 60 | - tvOS 61 | - WatchOS 62 | - Android 63 | 64 | 65 | Devices verified as working 66 | -------------------------------------------------------------------------------- 67 | 68 | - All varieties of desktop and laptop devices (Windows, OS X, Desktop Linux) 69 | - 64-bit (with rebuilt binaries) 70 | - 32-bit (not official supported, but they work) 71 | - Smartphones 72 | - Linux 73 | - Jolla Phone 74 | - Meizu MX4 Ubuntu Edition 75 | - Nexus 5 (SailfishOS 2.0) 76 | - SBCs 77 | - Linux 78 | - BeagleBone Black 79 | - Odroid XU3 80 | - Project C.H.I.P. 81 | - Raspberry Pi Model A 82 | - Raspberry Pi Model B+ 83 | - Raspberry Pi Zero 84 | - Raspberry Pi 2 85 | - Raspberry Pi 3 86 | - Wandboard Quad 87 | 88 | 89 | Devices - work in progress 90 | -------------------------------------------------------------------------------- 91 | - Smartwatches 92 | - Linux 93 | - Samsung Gear S2 94 | - BSD 95 | - Apple Watch 96 | - Smartphones 97 | - Linux 98 | - Nokia N9 (MeeGo) 99 | - Nokia N900 (Meemo) 100 | - Samsung Z1 101 | - Samsung Z3 102 | - Android 103 | - Samsung Galaxy S3 104 | - Samsung Galaxy S4 105 | - BSD 106 | - iPhone 3GS 107 | - iPhone 5 108 | - Developer phones 109 | - Linux 110 | - Samsung RD-210 111 | - Samsung RD-PQ 112 | - Samsung TM1 113 | - Tablets 114 | - Android 115 | - Samsung Galaxy Tab S 10.5 116 | - Nexus 7 117 | - BSD 118 | - iPad Air 2 119 | - SBCs 120 | - Linux 121 | - DragonBoard 410c 122 | - Intel Curie 123 | - Intel Edison 124 | - Intel NUC 125 | - Minnowboard Max 126 | - Odroid XU4 127 | -------------------------------------------------------------------------------- /source/ethereum-clients/ethereumh/index.rst: -------------------------------------------------------------------------------- 1 | .. _ethereumH: 2 | 3 | ################################################################################ 4 | ethereumH 5 | ################################################################################ 6 | 7 | This package provides a tool written in Haskell to allow you to connect to 8 | the Ethereum blockchain 9 | 10 | Links: 11 | 12 | * GitHub: https://github.com/blockapps/ethereumH 13 | * BlockApps: http://www.blockapps.net/ -------------------------------------------------------------------------------- /source/ethereum-clients/ethereumj/index.rst: -------------------------------------------------------------------------------- 1 | .. _Ethereum\(J\): 2 | 3 | ################################################################################ 4 | Ethereum(J) 5 | ################################################################################ 6 | 7 | **Ethereum(J)** is a pure-Java implementation of the Ethereum protocol. 8 | It is provided as a library that can be embedded in any Java/Scala project and 9 | to provide full support for Ethereum protocol and sub-services. 10 | Ethereum(J) was first developed by 11 | `Roman Mandeleil `_ and is now sponsored 12 | by ` `_. 13 | 14 | Ethereum(J) supports CPU mining. It is currently implemented in pure Java 15 | and can be used in private and test networks. You may even mine on the 16 | live Ethereum network, even though it is not economically feasible. 17 | 18 | Links: 19 | 20 | * Blog: http://ethereumj.io/ 21 | * GitHub: https://github.com/ethereum/ethereumj 22 | * Gitter chat: https://gitter.im/ethereum/ethereumj 23 | -------------------------------------------------------------------------------- /source/ethereum-clients/ethereumjs-lib/index.rst: -------------------------------------------------------------------------------- 1 | .. _ethereumjs-lib: 2 | 3 | ################################################################################ 4 | ethereumjs-lib 5 | ################################################################################ 6 | 7 | **ethereumjs-lib** is the javascript library of core `Ethereum `_ functions as described in the `Yellow Paper `_. This is a simple meta-module that provides the following modules. Most JS modules are tracked in `ethereumjs `_ 8 | 9 | * `VM `_ - The Ethereum virtual machine and state processing functions 10 | * `Blockchain `_ - Blockchain managment 11 | * `Block `_ - Block Schema definition and validation 12 | * `Transaction `_ - Transaction Schema definition and validation 13 | * `Account `_ - Account Schema definition and validation 14 | * `rlp `_ - Recursive Length Prefix serialization 15 | * `Trie `_ - Modified Merkle Patricia Tree 16 | * `Ethash `_ - Ethereum's Proof of Work algorithm 17 | * `utils `_ - Miscellaneous helper functions 18 | * `devp2p `_ - The networking protocol 19 | * `devp2p-dpt `_ - The disputed peer table 20 | 21 | Links: 22 | 23 | * GitHub: https://github.com/ethereumjs/ethereumjs-lib 24 | * Join the Gitter chat: https://gitter.im/ethereum/ethereumjs-lib 25 | 26 | -------------------------------------------------------------------------------- /source/ethereum-clients/go-ethereum/index.rst: -------------------------------------------------------------------------------- 1 | .. _go-ethereum: 2 | 3 | ################################################################################ 4 | go-ethereum 5 | ################################################################################ 6 | 7 | The go-ethereum client is commonly referred to as **geth**, which is the the command line interface for running a full ethereum node implemented in Go. By installing and running geth, you can take part in the ethereum frontier live network and: 8 | 9 | * mine real ether 10 | * transfer funds between addresses 11 | * create contracts and send transactions 12 | * explore block history 13 | * and much much more 14 | 15 | Links: 16 | 17 | * Website: http://ethereum.github.io/go-ethereum/ 18 | * GitHub: https://github.com/ethereum/go-ethereum 19 | * Wiki: https://github.com/ethereum/go-ethereum/wiki/geth 20 | * Gitter: https://gitter.im/ethereum/go-ethereum -------------------------------------------------------------------------------- /source/ethereum-clients/index.rst: -------------------------------------------------------------------------------- 1 | .. _Ethereum Clients: 2 | 3 | ################################################################################ 4 | Ethereum Clients 5 | ################################################################################ 6 | 7 | .. toctree:: 8 | :maxdepth: 2 9 | 10 | choosing-a-client.rst 11 | cpp-ethereum/index.rst 12 | go-ethereum/index.rst 13 | pyethapp/index.rst 14 | ethereumjs-lib/index.rst 15 | ethereumj/index.rst 16 | ethereumh/index.rst 17 | parity/index.rst 18 | ruby-ethereum/index.rst 19 | -------------------------------------------------------------------------------- /source/ethereum-clients/parity/index.rst: -------------------------------------------------------------------------------- 1 | .. _Parity: 2 | 3 | ################################################################################ 4 | Parity 5 | ################################################################################ 6 | 7 | **Parity** claims to be the world's fastest and lightest Ethereum client. It is written in the Rust language, which offers improved reliability, performance, and code clarity. Parity is being developed by `Parity Technologies (f.k.a. Ethcore) `_, which was founded by several members of the Ethereum Foundation. 8 | 9 | * Website: https://parity.io/ 10 | * GitHub: https://github.com/paritytech/parity 11 | * Gitter chat: https://gitter.im/paritytech/parity 12 | 13 | Arch Linux packages are maintained by `Afri Schoedon `_. 14 | 15 | * https://www.archlinux.org/packages/community/x86_64/parity/ 16 | 17 | Some people have reported success with Parity on Raspberry Pi 2. 18 | -------------------------------------------------------------------------------- /source/ethereum-clients/pyethapp/index.rst: -------------------------------------------------------------------------------- 1 | .. _pyethapp: 2 | 3 | ################################################################################ 4 | pyethapp 5 | ################################################################################ 6 | 7 | **pyethapp** is the python-based client implementing the Ethereum cryptoeconomic state machine. The python implementation aims to provide an easily hackable and extendable codebase. 8 | 9 | pyethapp leverages two ethereum core components to implement the client: 10 | 11 | * `pyethereum `_ - the core library, featuring the blockchain, the ethereum virtual machine, mining 12 | * `pydevp2p `_ - the p2p networking library, featuring node discovery for and transport of multiple services over multiplexed and encrypted connections 13 | 14 | Links: 15 | 16 | * GitHub: https://github.com/ethereum/pyethapp 17 | * Wiki: https://github.com/ethereum/pyethapp/wiki/Getting-Started 18 | * Gitter chat: https://gitter.im/ethereum/pyethapp 19 | 20 | -------------------------------------------------------------------------------- /source/ethereum-clients/ruby-ethereum/index.rst: -------------------------------------------------------------------------------- 1 | .. _ruby-ethereum: 2 | 3 | ################################################################################ 4 | ruby-ethereum 5 | ################################################################################ 6 | 7 | **ruby-ethereum** is an implementation of the :ref:`Ethereum Virtual Machine ` written in Ruby. 8 | 9 | 10 | Links: 11 | 12 | * GitHub: https://github.com/janx/ruby-ethereum 13 | * Gem: https://rubygems.org/gems/ruby-ethereum 14 | 15 | 16 | Related: 17 | 18 | * `ruby-serpent `_: Ruby binding to the `Ethereum Serpent `_ compiler. 19 | * :ref:`ethereum-ruby`: a pure-Ruby JSON-RPC wrapper for communicating with an Ethereum node. 20 | 21 | -------------------------------------------------------------------------------- /source/img/51Downloading.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/51Downloading.png -------------------------------------------------------------------------------- /source/img/51OpeningScreen.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/51OpeningScreen.png -------------------------------------------------------------------------------- /source/img/51PresaleImportInstall.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/51PresaleImportInstall.png -------------------------------------------------------------------------------- /source/img/ETHEREUM-ICON_Black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/ETHEREUM-ICON_Black.png -------------------------------------------------------------------------------- /source/img/Feels-Good-Man-Frog-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/Feels-Good-Man-Frog-02.png -------------------------------------------------------------------------------- /source/img/contract_relationship.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/contract_relationship.png -------------------------------------------------------------------------------- /source/img/contract_relationship2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/contract_relationship2.png -------------------------------------------------------------------------------- /source/img/cpp_35k9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/cpp_35k9.png -------------------------------------------------------------------------------- /source/img/eth_miner_setup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/eth_miner_setup.png -------------------------------------------------------------------------------- /source/img/ethereum-homestead-documentation-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/ethereum-homestead-documentation-logo.png -------------------------------------------------------------------------------- /source/img/ethereum-protocols.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/ethereum-protocols.png -------------------------------------------------------------------------------- /source/img/homestead-guide.svg: -------------------------------------------------------------------------------- 1 | chatchaton gitteron gitter -------------------------------------------------------------------------------- /source/img/jenkins.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereum/homestead-guide/841a5a90b6ec29dcad72b4599bd2641f48bf8169/source/img/jenkins.png -------------------------------------------------------------------------------- /source/index.rst: -------------------------------------------------------------------------------- 1 | .. homestead guide documentation master file, created by 2 | sphinx-quickstart on Tue Jan 5 17:30:05 2016. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | Ethereum Homestead Documentation 7 | =============================================================================== 8 | 9 | .. image:: img/ethereum-homestead-documentation-logo.png 10 | .. :height: 500px 11 | .. :width: 394 px 12 | :scale: 50 % 13 | :alt: ethereum-logo 14 | :align: center 15 | 16 | This documentation is the result of an ongoing collaborative effort by 17 | volunteers from the Ethereum :ref:`community`. Although it has not been 18 | authorized by the :ref:`foundation`, we hope you will find it useful. 19 | We welcome new :ref:`contributors`. Note that sections of this guide 20 | may be outdated. The Guide may be considered to be a historic reference 21 | since Ethereum had the Metropolis phase 1 fork, `Constantinople `_. 22 | An alternative documentation base may be used at https://github.com/ethereum/wiki/wiki 23 | ("the Wiki"), which is being actively maintained, and is also freely 24 | editable by anyone with a GitHub account (while editing this repo requires 25 | making a PR and being merged by a collaborator, or accepting an invitation 26 | as a collaborator). Note that documentation in this guide that is still 27 | relevant could be moved to the Wiki. 28 | 29 | 30 | Contents 31 | =============================================================================== 32 | 33 | .. toctree:: 34 | :maxdepth: 4 35 | 36 | introduction/index.rst 37 | ethereum-clients/index.rst 38 | connecting-to-clients/index.rst 39 | account-management.rst 40 | ether.rst 41 | network/index.rst 42 | mining.rst 43 | contracts-and-transactions/index.rst 44 | frequently-asked-questions/frequently-asked-questions.rst 45 | glossary.rst 46 | about.rst 47 | 48 | 49 | Improve the Documentation 50 | =============================================================================== 51 | 52 | See `this page `__ to help us improve the documentation. 53 | -------------------------------------------------------------------------------- /source/introduction/foundation.rst: -------------------------------------------------------------------------------- 1 | .. _foundation: 2 | 3 | *************************************************** 4 | The Ethereum Foundation 5 | *************************************************** 6 | The Ethereum Foundation is a non-profit organization registered in Switzerland, and has the purpose of managing the funds that were raised from the ether Sale in order to best serve the Ethereum and decentralized technology ecosystem. 7 | 8 | Founded July 2014 in Switzerland, Stiftung Ethereum’s mission is the promotion of developments of new technologies and applications, especially in the fields of new open and decentralized software architectures. 9 | 10 | It is the aim that decentralized and open technologies will be developed, nurtured, promoted and maintained. A dominating, but not exclusive, focus is set on the promotion of the development of the Ethereum Protocol and the relevant technology to it as well as the promotion and support of applications using the Ethereum technology or protocol. Stiftung Ethereum will additionally support and advocate for a decentralized Internet in a variety of forms. 11 | 12 | Find out about more about the `Foundation Management Team on the website `_ 13 | 14 | Ethereum Foundation's faces to the community 15 | --------------------------------------------------- 16 | * `Official Homestead website `_ - main entrypoint 17 | * `Reddit `_ - see :ref:`community` 18 | * `Blog `_ 19 | * `Twitter `_ 20 | * `Youtube `_ 21 | * `Facebook `_ - largely unused 22 | * `Email `_ - use if you must 23 | 24 | Official communication from the Ethereum foundation most often comes in the form of a comprehensive blogpost on the `Ethereum blog `_. Some of the posts there are technical, some organisational, some personal. All blog posts are announced on 25 | `Twitter `_ and 26 | `Reddit `_. 27 | 28 | The foundation `Youtube channel `_ hosts our videos, including all talks of the developers conferences DEVCON0 and DEVCON1. 29 | 30 | For community discussion forums, see :ref:`community`. 31 | -------------------------------------------------------------------------------- /source/introduction/how-to-use-this-guide.rst: -------------------------------------------------------------------------------- 1 | .. _how-to-use-this-guide: 2 | 3 | ******************************************************************************** 4 | How to use this guide? 5 | ******************************************************************************** 6 | 7 | Using Ethereum: The Basics 8 | ======================================================================================== 9 | 10 | This section captures the basic ways in which a user would want to participate 11 | in the Ethereum project. First of all, to become a node in the network, you need 12 | to run an Ethereum client. Multiple implementations are listed in the section 13 | :ref:`sec:clients` which also gives you advice as to which clients to choose in various 14 | setups. :ref:`sec:connecting-to-the-network` gives you basic information 15 | about networks, connectivity troubleshooting and blockchain synchronization. 16 | Advanced network topics like setting up private chains is found in 17 | :ref:`test-networks`. 18 | -------------------------------------------------------------------------------- /source/introduction/index.rst: -------------------------------------------------------------------------------- 1 | ################################################################################ 2 | Introduction 3 | ################################################################################ 4 | 5 | .. toctree:: 6 | :maxdepth: 2 7 | 8 | what-is-ethereum.rst 9 | how-to-use-this-guide.rst 10 | the-homestead-release.rst 11 | 12 | web3.rst 13 | history-of-ethereum.rst 14 | community.rst 15 | foundation.rst 16 | contributors.rst -------------------------------------------------------------------------------- /source/network/index.rst: -------------------------------------------------------------------------------- 1 | ################################################################################ 2 | The Ethereum network 3 | ################################################################################ 4 | 5 | Network info. 6 | 7 | .. toctree:: 8 | connecting-to-the-network.rst 9 | test-networks.rst -------------------------------------------------------------------------------- /tox.ini: -------------------------------------------------------------------------------- 1 | [tox] 2 | skipsdist=true 3 | envlist= 4 | rst_lint 5 | 6 | [testenv] 7 | commands=py.test --tb native {posargs:tests} 8 | deps = 9 | -r{toxinidir}/requirements.txt 10 | 11 | [testenv:rst_lint] 12 | basepython=python 13 | commands=python {toxinidir}/rst_lint.py 14 | --------------------------------------------------------------------------------