gaspersic/go-ethereum
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

[DOCS] Link checker (#20086)

Browse Source
This commit is contained in:
Adam Schmideg
2019-10-28 16:45:19 +01:00
committed by Felix Lange
parent 8e49d1571d
commit d0eea91981
26 changed files with 87 additions and 638 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/_legacy/Creating-your-own-Ethereum-apps-using-Eth-go.md
View File

@ -4,11 +4,11 @@ title: Creating your own Ethereum apps using Eth go
**This page is heavily outdated**
The modular nature of Go and the Ethereum Go implementation, [eth-go](https://github.com/ethereum/eth-go), make it very easy to build your own Ethereum native applications.
The modular nature of Go and the Ethereum Go implementation make it very easy to build your own Ethereum native applications.
This post will cover the minimal steps required to build an native Ethereum application.
Ethereum comes with a global config found in the [ethutil](https://github.com/ethereum/eth-go/tree/master/ethutil) package. The global config requires you to set a base path to store it's files (database, settings, etc).
Ethereum comes with a global config found in the ethutil package. The global config requires you to set a base path to store it's files (database, settings, etc).
```go
func main() {
@ -19,7 +19,7 @@ func main() {
ReadConfig takes four arguments. The data folder to use, a log flag, a globalConf instance and an id string to identify your app to other nodes in the network.
Once you've configured the global config you can set up and create your Ethereum node. The Ethereum Object, or Node, will handle all trafic from and to the Ethereum network as well as handle all incoming block and transactions. A new node can be created through the `new` method found in [eth-go](https://github.com/ethereum/eth-go).
Once you've configured the global config you can set up and create your Ethereum node. The Ethereum Object, or Node, will handle all trafic from and to the Ethereum network as well as handle all incoming block and transactions. A new node can be created through the `new` method found in eth-go.
```go
func main() {

17
docs/_legacy/Mining.md
View File

@ -9,7 +9,7 @@ title: Mining
At Frontier, the first release of Ethereum, you'll just need a) a GPU and b) an Ethereum client, Geth. CPU mining will be possible but too inefficient to hold any value.
At the moment, Geth only includes a CPU miner, and the team is testing a [GPU miner branch](https://github.com/ethereum/go-ethereum/tree/gpu_miner), but this won't be part of Frontier.
At the moment, Geth only includes a CPU miner, and the team is testing a GPU miner branch, but this won't be part of Frontier.
The C++ implementation of Ethereum also offers a GPU miner, both as part of Eth (its CLI), AlethZero (its GUI) and EthMiner (the standalone miner).
@ -19,7 +19,7 @@ When you start up your ethereum node with `geth` it is not mining by default. To
`geth --mine --minerthreads=4`
You can also start and stop CPU mining at runtime using the [console](../interface/javascript-console#adminminerstart). `miner.start` takes an optional parameter for the number of miner threads.
You can also start and stop CPU mining at runtime using the [console](../interface/javascript-console). `miner.start` takes an optional parameter for the number of miner threads.
```
> miner.start(8)
@ -46,7 +46,7 @@ miner.setEtherbase(eth.accounts[2])
Note that your etherbase does not need to be an address of a local account, just an existing one.
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.
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.
```
miner.setExtra("ΞTHΞЯSPHΞЯΞ")
@ -66,7 +66,7 @@ Header:
See also [this proposal](https://github.com/ethereum/wiki/wiki/Extra-Data)
You can check your hashrate with [miner.hashrate](../interface/javascript-console#adminminerhashrate), 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).
```
> miner.hashrate
@ -139,14 +139,13 @@ The GPU miner is implemented in OpenCL, so AMD GPUs will be 'faster' than same-c
ASICs and FPGAs are relatively inefficient and therefore discouraged.
To get openCL for your chipset and platform, try:
* [AMD SDK openCL](http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk)
* [AMD SDK openCL](http://developer.amd.com/tools-and-sdks)
* [NVIDIA CUDA openCL](https://developer.nvidia.com/cuda-downloads)
## On Ubuntu
### AMD
* http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing
* http://developer.amd.com/tools-and-sdks/graphics-development/display-library-adl-sdk/
* http://developer.amd.com/tools-and-sdks
download: `ADL_SDK8.zip ` and `AMD-APP-SDK-v2.9-1.599.381-GA-linux64.sh`
@ -189,7 +188,7 @@ You check your cooling status:
## Mining Software
The official Frontier release of `geth` only supports a CPU miner natively. We are working on a [GPU miner](https://github.com/ethereum/go-ethereum/tree/gpuminer), but it may not be available for the Frontier release. Geth however can be used in conjunction with `ethminer`, using the standalone miner as workers and `geth` as scheduler communicating via [JSON-RPC](https://github.com/ethereum/wiki/JSON-RPC).
The official Frontier release of `geth` only supports a CPU miner natively. We are working on a GPU miner, but it may not be available for the Frontier release. Geth however can be used in conjunction with `ethminer`, using the standalone miner as workers and `geth` as scheduler communicating via [JSON-RPC](https://github.com/ethereum/wiki/wiki/JSON-RPC).
The [C++ implementation of Ethereum](https://github.com/ethereum/cpp-ethereum/) (not officially released) however has a GPU miner. It can be used from `eth`, `AlethZero` (GUI) and `ethMiner` (the standalone miner).
@ -292,5 +291,5 @@ eth -m on -G -a <coinbase> -i -v 8 //
* https://github.com/ethereum/wiki/wiki/Ethash
* [Benchmarking results for GPU mining](https://forum.ethereum.org/discussion/2134/gpu-mining-is-out-come-and-let-us-know-of-your-bench-scores)
* [historic moment](https://twitter.com/gavofyork/status/586623875577937922)
* [live mining statistic](https://etherapps.info/stats/mining)
* [live mining statistic](https://ethstats.net/)
* [netstat ethereum network monitor](https://stats.ethdev.com)

2
docs/_legacy/Swarm---distributed-preimage-archive.md
View File

@ -14,7 +14,7 @@ title: Swarm - distributed preimage archive
- 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)
- The swarm smart 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)

166
docs/_legacy/Swarm-Channels,-Namereg-resolution-draft.md
View File

@ -1,166 +0,0 @@
---
title: Swarm channels, namereg-resolution draft
---
# Channels and streams
a *swarm chain* is an ordered list of content that are linked as a forkless chain.
.
This is simply modeled as linked manifests.
a *channel* is a sequence of manifests (_S_) and a relative path _P_ with a starting manifest _M_ and a streamsize _n_ (can be infinite). A channel is well-formed or regular if in every manifest in the stream _P_ resolves to a consistent mime type _T_ . For instance , if _T_ is `application/bzz-manifest+json`, we say the channel is a _manifest channel_, if the mime-type is `mpeg`, its a video channel.
A *primary channel* is a channel that actually respect chronological order of creation.
A *live channel* is a primary channel that keeps updating (adding episodes to the end of the chain) can have a (semi)-persistent mime-type for path _P_
A *blockstream channel* is a primary channel provable linked in time via hashes.
A *signed channel* is a primary channel provably linked by signatures (sequence position index signed by the publisher)
*Trackers* are a manifest channel which tracks updates to a primary channel and provides forward linking .
## Example channels:
- name histories, e.g updates of a domain, temporal snapshots of content
- blockchain: blockchain is a special case of blockstream
- git graph, versioning
- modeling a source of information: provable communication with hash chain, not allowed to fork, numbered.
#### content trackers
reverse index of a stream
- contains `next` links to following state
- published after next state
- publish provable quality metrics:
- age: starting date of tracker vs date of orig content
- neg exp forgetting(track date vs primary date of next episode) ~ alertness, puncuality (tracker
- git version control
every named host defines a timeline,
- create a manifest stream tracking a site
## Ways to link manifests
#### examples
``` json
{ "entries":
[
{
"host": "fefe.eth",
"number": 9067,
"previous": "ffca34987",
"next": "aefbc4569ab",
"this": "90daefaaabbc",
}
],
"auth": "3628aeefbc7689523aebc2489",
}
```
# Name resolution
The host part in a bzz webaddress should be resolved with our version of DNS, ie. using both `NameReg` (name registration contract on ethereum) and a simple mutable storage in swarm.
## signed version store
The point of channels (Swarm---Channels
) is to have a total order over a set of manifests.
The typical usecase is that it should be enough to know the name of a site or document to always see the latest version of a software or get the current episode of your favourite series or the consensus state of a blockchain. It should also be possible to deterministically derive the key to future content...
One possibility is to modify the NameReg entry in the blockchain to point to a swarm hash. Recording each change on the blockchain results in an implicit live channel linking. This scheme is simple inasmuch as it puts authentication completely on the chain. However, it is expensive and not viable given the number of publishers and typical rate of update.
Alternatively, swarm provides the protocol for associating a channel and a position with a swarm hash. The versioning can be authenticated since a message containing host name, sequence position index and swarm hash is signed by the public key registered in ethereum NameReg for the host.
Publishers, fans or paid bookkeepers track updates of a channel and wrap accumulated messages into a tracker manifest.
Most probably publishers would broadcast updates of a channel manifest in the first place.
This special key-value store can be implemented as a mutable store: the value with a higher index will simply override the previous one.
There can be various standards to derive lookup key deterministically
the simplest one is `HASH(host:version)` for a specific version and `HASH(host)` for the latest version.
The content has the following structure:
```
sign[<host>, <version>, <timestamp>, <hash>]
```
Retrieve request for a signed version is the same as a request for a hash.
[RetrieveMsg, HASH(host:version), id, timeout, MUTABLE]
[RetrieveMsg, HASH(host:0), id, timeout, MUTABLE]
Store request for a signed version is the same as for a hash:
[StoreMsg, key, id, MUTABLE, Sign[host, version, time.Unix(), hash]]
## Format
It is up to debate how we distinguish names to be resolved.
An early idea was to use a top level domain, such as `.eth` (<source> == `<host>.eth`)
this might limit the possibilities
Another idea was to have it as or part of the protocol: `eth://my-website.home` or `eth+bzz://my-website.home`. This are semantically incorrect, however.
Third, put an _eth_ inside the host somehow.
Ad-hoc constructs like `bzz://eth:my-website.home` will be rejected by host pattern matchers.
Abusing subdomains `bzz://eth.my-website.home` would cause ambiguity and potential collision.
Abusing auth `user:pass@my-website.home` would disable basic auth.
A suggestion that most aligns with the *signed versioning* and very simple is that we look up everything that is not a 32 byte hash format for a public key. The version of the site is looked up using the port part of the host. A specific version is given after the `:`.
The generic pattern then:
```
(<version_chain>.)<host>(:<number>)(/<path>)
```
### example 0
```
bzz://breaking.bad.tv/s4/e2/video
```
- _breaking.bad.tv_ is looked up in NameReg to yield public key _P_
- _breaking.bad.tv_ is looked up in the immutable store to yield a message `[_breaking.bad.tv_,0,3,aebf45fbf6ae6aaaafedcbcb467]`
- `aebf45fbf6ae6aaaafedcbcb467` is looked up in swarm to yield the manifest
- manifest entry for path `/s4/e2/video` results in the actual document's root key
### example 1
```
bzz://breaking.bad.tv/video
```
resolves the following way:
- _breaking.bad.tv_ is looked up in NameReg to yield public key _P_
- _breaking.bad.tv_ is looked up in the immutable store to yield - by `H(cookie)` - a message `[_breaking.bad.tv_,s5:e12,3,aebf45fbf6ae6aaaafedcbcb467]` signed by `P`
- `aebf45fbf6ae6aaaafedcbcb467` is looked up in swarm to yield the manifest
- manifest entry for path `video` results in the actual document's root key
### example 2
```
bzz://current.breaking.bad.tv:s4:e10/video
```
- _breaking.bad.tv_ is looked up in NameReg to yield public key _P_
- current.breaking.bad.tv:s4:e10 is looked up in the immutable store to yield a message `[current.breaking.bad.tv,s4:e10,3,45fbf6ae6aaaafedcbcb467ccc]`
- `45fbf6ae6aaaafedcbcb467ccc` is looked up in swarm to yield the manifest
- manifest entry for path `video` results in the actual document's root key
### example 3
```
bzz://breaking.bad.tv/playlist
```
- same as ex 2...
- manifest entry for path `playlist` results in a playlist manifest
### example 4
```
bzz://stable.ethereum.org:8.1/download/go/mac-os
```
- _stable.ethereum.org_ is looked up in NameReg to yield public key _P_
- stable.ethereum.org:s4:e10 is looked up in the immutable store to yield a message `[stable.ethereum.org,s4:e10,3,45fbf6ae6aaaafedcbcb467ccc]`
- `45fbf6ae6aaaafedcbcb467ccc` is looked up in swarm to yield the manifest
- manifest entry for path `video` results in the actual document's root key
Generalised content streaming, subscriptions.

40
docs/_legacy/Swarm-Contract.md
View File

@ -1,40 +0,0 @@
---
title: Swarm contract
---
This one contract regulates the incentive structure of Swarm.
The corresponding solidity code can be browsed [here](https://github.com/ethersphere/go-ethereum/blob/bzz/bzz/bzzcontract/swarm.sol).
# Methods
## Sign up as a node
Pay a deposit in Ether and register public key. Comes with an accessor for checking that a node is signed up.
## Demand penalty for loss of chunk
Present a signed receipt by a signed up node and a deposit covering the upload of a chunk. After a given deadline, the signer node's deposit is taken and the presenting node's deposit refunded, unless the chunk is presented. Comes with an accessor for checking that a given chunk has been reported lost, so that holders of receipts by other swarm nodes can punish them as well for losing the chunk, which, in turn, incentivizes whoever holds the chunk to present it.
## Present chunk to avoid penalty
No penalty is paid for lost chunks, if chunk is presented within the deadline. The cost of uploading the chunk is compensated exactly from the demand's deposit, with the remainder refunded. Comes with an accessor for checking that a given node is liable for penalty, so the node is notified to present the chunk in a timely fashion.
# Price considerations
For the price of accepting a chunk for storing, see [Incentives](https://github.com/ethersphere/swarm/blob/master/doc/incentives.md)
This price should be proportional to the sign-up deposit of the swarm node.
The deposit for compensating the swarm node for uploading the chunk into the block chain should be substantially higher (e.g. a small integer multiple) of the corresponding upload measured with the gas price used to upload the demand to prevent DoS attacks.
# Termination
Users of Swarm should be able to count on the loss of deposit as a disincentive, so it should not be refunded before the term of Swarm membership expires. If penalites were paid out as compensation to holders of receipts of lost chunks, it would provide an avenue of early exit for a Swarm member by "losing" chunks deposited by colluding users. Since users of Swarm are interested in their information being reliably stored, their primary incentive for keeping the receipts is to keep the Swarm motivated, not the potential compensation.
# Receipt circulation
End-users of Swarm keeping important information in it are obviously interested in keeping as many receipts of it as possible available for "litigation". The storage space required for storing a receipt is a sizable fraction of that used for storing the information itself, so end users can reduce their storage requirement further by storing the receipts in Swarm as well. Doing this recursively would result in end users only having to store a single receipt, yet being
able to penalize quite a few Swarm nodes, in case only a small part of their stored information
is lost.
Swarm nodes that use the rest of Swarm as a backup may want to propagate the receipts in the opposite direction of storage requests, so that the cost of storing receipts is eventually paid by the end user either in the form of allocated storage space or as a direct payment to Swarm.

12
docs/_legacy/geth.md
View File

@ -25,7 +25,7 @@ Developers and community enthusiast are advised to read the [Developers' Guide](
## Interfaces
* Javascript Console: `geth` can be launched with an interactive console, that provides a javascript runtime environment exposing a javascript API to interact with your node. [Javascript Console API](../interface/javascript-console) includes the `web3` javascript Ðapp API as well as an additional admin API.
* JSON-RPC server: `geth` can be launched with a json-rpc server that exposes the [JSON-RPC API](https://github.com/ethereum/wiki/JSON-RPC)
* JSON-RPC server: `geth` can be launched with a server that exposes the [JSON-RPC API](https://github.com/ethereum/wiki/wiki/JSON-RPC)
* [Command line options](../interface/command-line-options) documents command line parameters as well as subcommands.
## Basic Use Case Documentation
@ -37,7 +37,7 @@ Developers and community enthusiast are advised to read the [Developers' Guide](
## License
The Ethereum Core Protocol licensed under the [GNU Lesser General Public License](https://www.gnu.org/licenses/lgpl.html). All frontend client software (under [cmd](https://github.com/ethereum/go-ethereum/tree/develop/cmd)) is licensed under the [GNU General Public License](https://www.gnu.org/copyleft/gpl.html).
The Ethereum Core Protocol licensed under the [GNU Lesser General Public License](https://www.gnu.org/licenses/lgpl.html). All frontend client software (under [cmd](https://github.com/ethereum/go-ethereum/tree/master/cmd)) is licensed under the [GNU General Public License](https://www.gnu.org/copyleft/gpl.html).
## Reporting
@ -85,8 +85,6 @@ IRC Freenode channels:
* `#dappdevs`: Dapp developers channel
* `#ethdev`: buildserver etc
[IRC Logs by ZeroGox](https://zerogox.com/bot/log)
### Gitter
* [go-ethereum Gitter](https://gitter.im/ethereum/go-ethereum)
@ -96,11 +94,7 @@ IRC Freenode channels:
### Forum
- [Forum](https://forum.ethereum.org/categories/go-implementation)
### The ZeroGox Bot
[ZeroGox Bot](https://zerogox.com/bot)
- [Forum](https://forum.ethereum.org/categories/geth)
### Dapp developers' mailing list

60
docs/_legacy/swarm---POC-series.md
View File

@ -1,60 +0,0 @@
---
title: Swarm POC series
---
now project features and POC milestones are managed under
https://github.com/ethereum/go-ethereum/projects/6
## POC 0.1: plan bee
* [x] underground dev testnet launched on BZZ day (3.22 is l33t for BZZ)
* [x] create ansible and docker for node deployment
* [x] a few public gateways
## POC 0.2 sworm
* [x] rebase on geth 1.5 edge
* [x] small toynet deployed, see [network monitor](http://146.185.130.117/)
* [x] support for separate url schemes for dns enabled, immutable and raw manifest - feature [#2279](https://github.com/ethereum/go-ethereum/issues/2279)
* [x] Ethereum name service integration
* [x] scripted network tests, cluster control framework
* [x] algorithmic improvements on chunker split/join
* [x] algorithmic improvements on upload/download
* [x] algorithmic improvements in kademlia and hive peers manager
* [x] calibrating kademlia connectivity parameters to toynet scale
* [x] orange paper series released hosted on [swarm toynet](http://swarm-gateways.net/bzz:/swarm#the-thsphr-orange-papers)
* [x] minimalistic [swarm homepage](http://swarm-gateways.net/bzz:/swarm)
* [x] adapt to felix's rpc-client-as-eth-backend scheme to run swarm as a separate daemon
* [x] merge into main repo develop branch
## POC 0.3
Priorities are not finalised, this is just a tentative plan.
The following features are prioritised for POC 3 (subject to change)
* [ ] docker on azure: complete test cluster deployment and remote node control framework
* [ ] comprehensive suite of typical network scenarios
* [ ] syncer rewrite - syncdb refactor to storage
* [ ] mist integration
* [ ] storage monitoring and parameter setting API for Mist swarm dashboard
* [ ] bzz protocol should implement info for reporting - feature [#2042](https://github.com/ethereum/go-ethereum/issues/2042)
* [x] improved peer propagation [#2044](https://github.com/ethereum/go-ethereum/issues/2044)
* [x] abstract network simulation framework
* [x] protocol stack abstraction, pluggable subprotocol components - (swap, hive/protocol, syncer, peers) for pss
* [ ] new p2p API integration - feature [#2060](https://github.com/ethereum/go-ethereum/issues/2060)
* [ ] pss - unicast
* [ ] swap rewrite
* [ ] obfuscation for plausible deniability
## POC 0.4
* [ ] enhanced network monitoring, structured logging and stats aggregation
* [ ] unicast/multicast messaging over swarm - pss
* [ ] swear and swindle http://swarm-gateways.net/bzz:/swarm/ethersphere/orange-papers/1/sw%5E3.pdf
* [ ] smash/crash proof of custody http://swarm-gateways.net/bzz:/swarm/ethersphere/orange-papers/2/smash.pdf
* [ ] swarm DB support phase 0 - compact manifest trie and proof requests
* [ ] [SWarm On-demand Retrieval Daemon](https://gist.github.com/zelig/aa6eb43615e12d834d9f) - feature [#2049](https://github.com/ethereum/go-ethereum/issues/2049) = sword. ethereum state, contract storage, receipts, blocks on swarm
* [x] ~implement (a reviewed version of) [EIP-26](https://github.com/ethereum/EIPs/issues/26)~ obsoleted by ENS and the vickrey auction
* [ ] swarm namereg/natspec rewrite - enhancement [#2048](https://github.com/ethereum/go-ethereum/issues/2048)
* [x] ~solidity [contractInfo standard](https://github.com/ethereum/solidity/pull/645) and contract source verification support~ https://www.reddit.com/r/ethereum/comments/5d5lyd/first_contract_to_contain_swarm_hash_to_its/
## POC 0.5

1
docs/_legacy/swarm-dev-progress.md
View File

@ -1 +0,0 @@
See [Swarm Roadmap](https://github.com/orgs/ethersphere/projects/5)

1
docs/_legacy/swarm-roadmap.md
View File

@ -1 +0,0 @@
See [Swarm Roadmap](https://github.com/orgs/ethersphere/projects/5)