diff --git a/_config.yml b/_config.yml index 2d87f54698..a90ab5b6dc 100644 --- a/_config.yml +++ b/_config.yml @@ -15,7 +15,7 @@ defaults: - scope: path: "*" values: - root: "." + root: "../.." - scope: path: "*/*" values: diff --git a/docs/_clef/Overview.md b/docs/_clef/Overview.md deleted file mode 100644 index 7e7b4bef91..0000000000 --- a/docs/_clef/Overview.md +++ /dev/null @@ -1,303 +0,0 @@ ---- -title: Clef overview ---- - - -_A reasonably secure wallet_ - -Goal: Accommodate arbitrary high requirements for security (through _isolation_ and _separation_), while still providing _usability_. - -Clef can be used to sign transactions and data and is meant as a replacement for geth's account management. -This allows DApps not to depend on geth's account management. When a DApp wants to sign data it can send the data to -the signer, the signer will then provide the user with context and asks the user for permission to sign the data. If -the users grants the signing request the signer will send the signature back to the DApp. - -This setup allows a DApp to connect to a remote Ethereum node and send transactions that are locally signed. This can -help in situations when a DApp is connected to a remote node because a local Ethereum node is not available, not -synchronised with the chain or a particular Ethereum node that has no built-in (or limited) account management. - -Clef can run as a daemon on the same machine, or off a usb-stick like [usb armory](https://inversepath.com/usbarmory), -or a separate VM in a [QubesOS](https://www.qubes-os.org/) type os setup. - - -## More info - -Check out - -* the [tutorial](tutorial) for some concrete examples on how the signer works. -* the [setup docs](setup) for some information on how to configure it to work on QubesOS or USBArmory. -* more info about [rules](rules) -* the [data types](datatypes) for detailed information on the json types used in the communication between - clef and an external UI - -## Security model - -The security model of the signer is as follows: - -* One critical binary is responsible for all cryptographic ops. -* The signer has a well-defined 'external' API - **UNTRUSTED**. -* The signer also has bidirectional APIs with whoever invoked it, via stdin/stdout -- considered **TRUSTED**. - * `clef` exposes API for the UI to consume, - * `ui` exposes API for `clef` to consume - - -The basic premise being, - -* A small(ish) binary without dependencies, -* that is deployed on a trusted (secure) machine, -* which serves untrusted requests, -* in a hostile (network) environment - - -The general flow for signing a transaction using e.g. geth is as follows: - -![Sign flow](sign_flow.png) - - -Clef relies on __sign-what-you-see__. To provide as much context as possible, - -- It parses calldata against 4byte database of method signatures. -- It alerts the user about the origin of the request (ip, `user-agent`,`transport`, `Origin`) - - -# Setup scenarios - -One setup scenario is to use virtualization, e.g. within QubesOS, where to -Clef is deployed on a non-networked machine (`ethvault` below) - -![Qubes](clef_qubes_qrexec.png) - - -Another option is to deploy Clef on a separate physical device, e.g. USB Armory, -and access the CLI-UI via SSH on the interface provided by the USB ethernet -adapter, and expose HTTP interface via tunneling. - -![USB armory from Inverse Path](https://inversepath.com/images/usbarmory_mark-one/usbarmory_coin_web.jpg) - - -## Multi-user setup - -Clef can also be used in a situation where several people need to make transactions, -and some other person (finance) does approval. - - -## Architecture - -Clef is divided into two parts - -- Clef -- UI - -Clef has a CLI natively, but a more refined UI can start `clef` in _standard-input-output-IO mode_. - ---- - -Clef _native_ CLI user interface example: -``` ---------- Transaction request------------- -to: 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 -from: 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 [chksum ok] -value: 1 wei -gas: 0x1 (1) -gasprice: 1 wei -nonce: 0x1 (1) - -Request context: - 127.0.0.1:59870 -> HTTP/1.1 -> localhost:8550 - -Additional HTTP header data, provided by the external caller: - User-Agent: Go-http-client/1.1 - Origin: -------------------------------------------- -Approve? [y/N]: -> y -Enter password to approve: -``` - -`clef` will invoke API-methods on the UI whenever an action is required. - -- `ui_ApproveTx` -- `ui_ApproveListing` -- ... - -This is called the `internal api`, or `ui-api`. - -![Clef architecture 1](clef_architecture_pt1.png) - -![Clef architecture 2](clef_architecture_pt2.png) - -### Rules - -Historically, a user who wanted an easy way to sign transactions repeatedly, would -use some variant of `personal.unlock`. That is a very insecure way of managing -accounts, and is not present in Clef. Clef instead implements Rules, which can -be customized to provide the same type of ease of use, but with much higher -security-guarantees. - -Examples of rules: - -* "I want to allow transactions with contract `CasinoDapp`, with up to `0.05 ether` in value to maximum `1 ether` per 24h period" -* "I want to allow transaction to contract `EthAlarmClock` with `data`=`0xdeadbeef`, if `value=0`, `gas < 44k` and `gasPrice < 40Gwei`" - -Clef comes with a Javascript VM which can evaluate a ruleset file. The ruleset -file has access to the same interface that an external UI would have. - -#### Example 1: Allow listing - -```javascript - function ApproveListing(){ - return "Approve" - } -``` - ---- - -#### Example 2: Allow destination - -```javascript -function ApproveTx(r){ - var ok = "0x0000000000000000000000000000000000001337"; - var nope = "0x000000000000000000000000000000000000dead"; - if(r.transaction.from.toLowerCase()== ok){ - return "Approve" - } - if(r.transaction.from.toLowerCase()==nope){ - return "Reject" - } - // Otherwise goes to manual processing -} -``` - ---- - -#### Example 3: a rate-limited window - - -```javascript - function big(str){ - if(str.slice(0,2) == "0x"){ return new BigNumber(str.slice(2),16)} - return new BigNumber(str) - } - - // Time window: 1 week - var window = 1000* 3600*24*7; - // Limit : 1 ether - var limit = new BigNumber("1e18"); - - function isLimitOk(transaction){ - var value = big(transaction.value) - // Start of our window function - var windowstart = new Date().getTime() - window; - - var txs = []; - var stored = storage.Get('txs'); - - if(stored != ""){ - txs = JSON.parse(stored) - } - // First, remove all that have passed out of the time-window - var newtxs = txs.filter(function(tx){return tx.tstamp > windowstart}); - console.log(txs, newtxs.length); - // Secondly, aggregate the current sum - sum = new BigNumber(0) - sum = newtxs.reduce(function(agg, tx){ return big(tx.value).plus(agg)}, sum); - // Would we exceed weekly limit ? - return sum.plus(value).lt(limit) - - } - function ApproveTx(r){ - if (isLimitOk(r.transaction)){ - return "Approve" - } - return "Nope" - } - - /** - * OnApprovedTx(str) is called when a transaction has been approved and signed. - */ - function OnApprovedTx(resp){ - var value = big(resp.tx.value) - var txs = [] - // Load stored transactions - var stored = storage.Get('txs'); - if(stored != ""){ - txs = JSON.parse(stored) - } - // Add this to the storage - txs.push({tstamp: new Date().getTime(), value: value}); - storage.Put("txs", JSON.stringify(txs)); - } - -``` - -### A note about passwords... - -In normal mode, passwords are supplied via UI. -In order to use rules, keystore passwords must be stored in `clef`. Clef uses an encrypted container to store - -- Keystore passwords -- SHA256 hash of ruleset file -- Key/value pairs accessible to the Javascript ruleset implementation - - This, in turn, enables the ruleset files to save data and thus implement - things like the rate-limited window. - ---- -## External UIs - -The `clef` daemon can be wrapped by an external process, which can then take -the part of a UI. - -![Clef architecture 3](clef_architecture_pt3.png) -QT UI on Ubuntu -![QT UI on Ubuntu](https://raw.githubusercontent.com/holiman/qtsigner/master/screenshot.png) - -GTK UI on Qubes - -![GTK UI on Qubes](https://raw.githubusercontent.com/ethereum/go-ethereum/master/cmd/clef/docs/qubes/qubes_newaccount-2.png) - -### Rules for UI apis - -A UI should conform to the following rules. - -* A UI MUST NOT load any external resources that were not embedded/part of the UI package. - * For example, not load icons, stylesheets from the internet - * Not load files from the filesystem, unless they reside in the same local directory (e.g. config files) -* A Graphical UI MUST show the blocky-identicon for ethereum addresses. -* A UI MUST warn display approproate warning if the destination-account is formatted with invalid checksum. -* A UI MUST NOT open any ports or services - * The signer opens the public port -* A UI SHOULD verify the permissions on the signer binary, and refuse to execute or warn if permissions allow non-user write. -* A UI SHOULD inform the user about the `SHA256` or `MD5` hash of the binary being executed -* A UI SHOULD NOT maintain a secondary storage of data, e.g. list of accounts - * The signer provides accounts -* A UI SHOULD, to the best extent possible, use static linking / bundling, so that required libraries are bundled -along with the UI. - - -### UI Implementations - -There are a couple of implementation for a UI. We'll try to keep this list up to date. Currently, none of these are finished. - -| Name | Repo | UI type| No external resources| Blocky support| Verifies permissions | Hash information | No secondary storage | Statically linked| Can modify parameters| -| ---- | ---- | -------| ---- | ---- | ---- |---- | ---- | ---- | ---- | -| QtSigner| https://github.com/holiman/qtsigner/| Python3/QT-based| :+1:| :+1:| :+1:| :+1:| :+1:| :x: | :+1: (partially)| -| GtkSigner| https://github.com/holiman/gtksigner| Python3/GTK-based| :+1:| :x:| :x:| :+1:| :+1:| :x: | :x: | -| Frame | https://github.com/floating/frame/commits/go-signer| Electron-based| :x:| :x:| :x:| :x:| ?| :x: | :x: | -| Clef UI| https://github.com/ethereum/clef-ui| Golang/QT-based| :+1:| :+1:| :x:| :+1:| :+1:| :x: | :+1: (approve tx only)| - - -## Geth integration - -The `--signer` CLI option for `geth` means that `geth` can use `clef` as a -backend signer. - -Although some things, like `personal.unlock` disappears, `clef` has otherwise -a corresponding (or exceeding) feature set: - -* Full set of options for hardware interaction (derivation etc) via UI -* EIP 191/712 - signing typed data - -Clef can even sign Clique headers in a private network -![Clef architecture 4](clef_architecture_pt4.png) - - diff --git a/docs/_legacy/Mining.md b/docs/_legacy/Mining.md index fe0977751a..30784d683b 100644 --- a/docs/_legacy/Mining.md +++ b/docs/_legacy/Mining.md @@ -46,7 +46,11 @@ miner.setEtherbase(eth.accounts[2]) Note that your etherbase does not need to be an address of a local account, just an existing one. +<<<<<<< HEAD There is an option [to add extra Data](../interface/javascript-console) (32 bytes only) to your mined blocks. By convention this is interpreted as a unicode string, so you can set your short vanity tag. +======= +There is an option [to add extra Data](../interface/javascript-console#adminminersetextra) (32 bytes only) to your mined blocks. By convention this is interpreted as a unicode string, so you can set your short vanity tag. +>>>>>>> 8e49d1571d52da8555847b9901f9d52d5c20ddb1 ``` miner.setExtra("ΞTHΞЯSPHΞЯΞ") @@ -66,7 +70,11 @@ Header: See also [this proposal](https://github.com/ethereum/wiki/wiki/Extra-Data) +<<<<<<< HEAD You can check your hashrate with [miner.hashrate](../interface/javascript-console), the result is in H/s (Hash operations per second). +======= +You can check your hashrate with [miner.hashrate](../interface/javascript-console#adminminerhashrate), the result is in H/s (Hash operations per second). +>>>>>>> 8e49d1571d52da8555847b9901f9d52d5c20ddb1 ``` > miner.hashrate diff --git a/docs/_legacy/Swarm---TODO.md b/docs/_legacy/Swarm---TODO.md new file mode 100644 index 0000000000..9ce1d0301b --- /dev/null +++ b/docs/_legacy/Swarm---TODO.md @@ -0,0 +1,80 @@ +--- +title: Swarm TODO +--- +# Sprint plan + +# scope +- forwarding only (no recursive lookup and no connecting to new nodes, only working with active peers) + +## TODO + +- integrate new p2p +- write unit tests for protocol and netstore (without protocol) +- rework protocol errors using errs after PR merged +- integrate new p2p or develop branch after p2p merge +- integrate cademlia into hive / peer pool with new p2p +- work out timeouts and timeout encoding +- cli tools +- url bar and proxy + +## CLI +- hooking into DPA local API +- running as a daemon accepting request via socket? + +### - +## Encryption +- encryption gateway to incentivise encryption of public content +- xor encryption with random chunks +- in-memory encryption keys +- originator encryption for private content + + +## APIs +- DAPP API - js integration (Fabian, Alex) +- mist dapp storage scheme, url->hash mapping (Fabian, Alex) [URL scheme](../doc/url-scheme) + +# Discuss alternatives + +I suggest we each pick 2/3 and read up on their project status, features, useability, objectives, etc +- Is it even worth it to reinvent/reimplement the wheel? +- what features do we want now and in future +- roadmap + +# Brainstorming + +- storage economy, incentivisation, examples: +-- content owner pays recurring ether fee for storage. +-- scheme to reward content owner each time content is accessed. i.e accessing content would requires fee. this would reward popular content. should be optional though. +- dht - chain interaction +- proof of custody https://docs.google.com/document/d/1F81ulKEZFPIGNEVRsx0H1gl2YRtf0mUMsX011BzSjnY/edit +- proof of resources http://systemdocs.maidsafe.net/content/system_components/proof_of_resources.html +- nonoutsourceable proofs of storage as mining criteria +- proof of storage capacity directly rewarded by contract +- streaming, hash chains +- routing and learning graph traversal +- minimising hops +- forwarding strategies, optimising dispersion of requests +- lifetime of requests, renewals (repeated retrieval requests), expiry, reposting (repeated storage request) +- redundancy - store same data in multiple nodes (e.g 4x) +- the more accessed a content is, the more available it should be, should increase performance for popular content. + +# Simulations + +- full table homogeneous nodes network size vs density vs table size expected row-sizes +- forwarding strategy vs latency vs traffic +- stable table, dropout rate vs routing optimisation by precalculating subtables for all peers. expected distance change (proximity delta) per hop + + +## Swarm + +How far does the analogy go? + +swarm of bees | a decentralised network of peers +-------|------------ +living in a hive | form a distributed preimage archive +where they | where they +gather pollen | gather data chunks which they +to produce honey | transform into a longer data stream (document) +they consume and store | they serve and store +buzzing bzz | using bzz as their communications protocol + diff --git a/docs/_legacy/Swarm---distributed-preimage-archive.md b/docs/_legacy/Swarm---distributed-preimage-archive.md new file mode 100644 index 0000000000..4bd685f63f --- /dev/null +++ b/docs/_legacy/Swarm---distributed-preimage-archive.md @@ -0,0 +1,69 @@ +--- +title: Swarm - distributed preimage archive +--- +# Resources + +## Swarm, the name +- https://www.facebook.com/swarmcorp, http://swarm.fund/ +- https://bitcointalk.org/index.php?topic=650143.0 +- https://bitcoinmagazine.com/17956/swarm-1-rick-falkvinges-swarmops-project/ +- http://www.amazon.co.uk/Swarmwise-Tactical-Manual-Changing-World/dp/1463533152/ + +## Docs & specs +- [Swarm TODO](./swarm-todo) +- Dani & Viktor on public wiki: https://github.com/ethereum/wiki/wiki/Distributed-Preimage-Archive +- Dani on swarm hash: https://github.com/ethereum/wiki/wiki/Swarm-Hash +- Dani on incentive system: https://github.com/ethersphere/swarm/blob/master/doc/incentives.md +- [The swarm smart contract](./swarm-contract) +- gav on url-hint https://github.com/ethereum/wiki/wiki/URL-Hint-Protocol +- Gav on public wiki: https://github.com/ethereum/cpp-ethereum/wiki/Swarm +- network (DEVp2p) + - [Peer-to-Peer](../developers/peer-to-peer) + - on kademlia: https://github.com/ethereum/wiki/wiki/Cademlia-Peer-Selection + +## Talks +- https://twitter.com/ethereumproject/status/538030376858693633 +- Dr. Daniel Nagy: Ethereum ÐΞVcon-0: Keeping the Public Record Safe and Accessible - https://www.youtube.com/watch?v=QzYZQ03ON2o&list=PLJqWcTqh_zKEjpSej3ddtDOKPRGl_7MhS&index=7&spfreload=10 + +## Forum +- empty as of 01/2015: https://forum.ethereum.org/categories/swarm +- + +## Mentions, discussions +- http://www.reddit.com/r/ethereum/comments/2d4uyw/swarm_and_whisper/ +- http://www.reddit.com/r/ethereum/comments/2ityfz/ethereum_swarm/ +- https://www.maidsafe.org/t/ethereums-swarm-p2p-storage-and-whisper-p2p-messaging/1528 +- Vitalik's blogpost of 08/2014 - https://blog.ethereum.org/2014/08/16/secret-sharing-erasure-coding-guide-aspiring-dropbox-decentralizer/ +- Vitalik: 'Swarm is out-of-scope': https://www.reddit.com/r/ethereum/comments/2phvml/constructive_criticism_of_ethereum_project_not/cmwtfqq +- Vitalik on eth components, swarm at 4:00 http://www.naation.com/2015/02/02/ethereum-explained-with-vitalik-buterin-inventor-and-leader-of-the-ethereum-project/5764/ +- https://www.youtube.com/watch?v=zgkmQ-jQJHk&feature=youtu.be + +## Media +- https://twitter.com/jeffehh/status/565927366271467521 +- https://twitter.com/avsa/status/566255260713627648 +- https://twitter.com/zeligf/status/566042020909973504 +- https://www.reddit.com/r/ethereum/comments/2wryru/eli5_how_is_ethereum_supposed_to_be_a_dropbox +- https://forum.ethereum.org/discussion/comment/7593/#Comment_7593 + +## Code +- bzz PR: https://github.com/ethereum/go-ethereum/pull/255, +- repo https://github.com/ethersphere/go-ethereum/tree/bzz/ +- ethereum p2p: https://github.com/ethereum/go-ethereum/p2p +- peer selection, peer pool: https://github.com/ethereum/go-ethereum/pull/253 +- p2p cademlia branch (discontinued): https://github.com/ethersphere/go-ethereum/tree/kademlia +- Felix's node discovery code: https://github.com/ethereum/go-ethereum/tree/develop/p2p/discover + +# Alternatives + +- storj - http://storj.io/ +- maidsafe - http://maidsafe.net/ +- ipfs - http://ipfs.io/, https://www.youtube.com/watch?v=Fa4pckodM9g, http://static.benet.ai/t/ipfs.pdf, https://github.com/jbenet/go-ipfs, https://www.youtube.com/watch?v=8CMxDNuuAiQ, https://www.reddit.com/r/ethereum/comments/2wot2i/ipfs_alpha_demo/ +- filecoin - http://filecoin.io/ +- permacoin - https://www.cs.umd.edu/~elaine/docs/permacoin.pdf, https://bitcointalk.org/index.php?topic=640410.0, http://blog.dshr.org/2014/06/permacoin.html +- siacoin - http://www.siacoin.com/ +- riak - http://basho.com/riak/ +- BitTorrent http://www.bittorrent.com/ maelstrom http://blog.bittorrent.com/2014/12/10/project-maelstrom-the-internet-we-build-next/ +- Tahoe-LAFS https://www.tahoe-lafs.org/trac/tahoe-lafs +- retroshare http://retroshare.sourceforge.net/ + +