forks/go-ethereum
1
0
Fork 1
mirror of https://github.com/ethereum/go-ethereum.git synced 2026-08-20 10:52:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

resolve merge conflicts

Browse source
This commit is contained in:
Adam Schmideg 2019-10-22 12:41:14 +02:00
commit 782e97ed21
5 changed files with 158 additions and 304 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
_config.yml
View file

@ -15,7 +15,7 @@ defaults:
- scope: - scope:
path: "*" path: "*"
values: values:
root: "." root: "../.."
- scope: - scope:
path: "*/*" path: "*/*"
values: values:

303
docs/_clef/Overview.md
View file

@ -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)

8
docs/_legacy/Mining.md
View file

@ -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. 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) (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ΞЯΞ") miner.setExtra("ΞTHΞЯSPHΞЯΞ")
@ -66,7 +70,11 @@ Header:
See also [this proposal](https://github.com/ethereum/wiki/wiki/Extra-Data) 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), 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 > miner.hashrate

80
docs/_legacy/Swarm---TODO.md Normal file
View file

@ -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

69
docs/_legacy/Swarm---distributed-preimage-archive.md Normal file
View file

@ -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/