Merge pull request #1 from eoscanada/master

Merging changes from Alex

README.join-cn.md

@@ -21,7 +21,7 @@
 * `target_p2p_address`, 对外提供的P2P地址
 * `target_account_name`, `target_appointed_block_producer_signing_key`, `target_initial_authority`: 这三个都需要改成你的值
 * `target_contents`, 我们达成一致可以写入区块链中的内容，包含系统合约，EOS映射快照
-## 5. 更新`privkeys.keys`
+## 5. 更新`seed_network.keys`
 这个文件中需要包含你的公钥地址对应的私钥
 
 ## 6. 发布你的配置文件

README.join.md

@@ -23,7 +23,7 @@ Copy the `sample_config` folder to a folder named `stageX` where X is the stage
 * `target_p2p_address` is a publicly reachable address advertised to mesh the network
 * `target_account_name`, `target_appointed_block_producer_signing_key`, `target_initial_authority`: the values you want to use on the target network
 * `target_contents` are all the pieces of content we need to agree on that will make it into the chain, like system contracts, ERC-20 snapshots, etc.. You will see consensus achieved with the members on your first orchestration. Use the sample_config values for now.
-## 5. Update `privkeys.keys`
+## 5. Update `seed_network.keys`
 This file should contain the private key(s) to control your seed network account
 ## 6. Publish your discovery file
 

README.md

@@ -158,22 +158,28 @@ network.
 How to weight your peers
 ------------------------
 
-1. Do they fully understand the boot sequence ? Do they understand all
+1. Are they competent and capable persons? Can they fix the network
+   if it goes awry?
+
+2. Are they providing a solid and tested infrastructure? Can be stay
+   on schedule and produce blocks until we reach the 15% threshold ?
+
+3. Do they fully understand the boot sequence ? Do they understand all
    actions that need to be processed in order to have a chain that
    qualifies as mainnet. (they decide on boot_sequence.yaml)
 
-2. Can they compile system contracts and compare their source code,
+4. Can they compile system contracts and compare their source code,
    making sure that the proposed contracts are legit, do not contain
    rogue code, etc.. (they decide on target_contents)
 
-3. Do they understand how to make sure the snapshot.csv is valid,
+5. Do they understand how to make sure the snapshot.csv is valid,
    up-to-date and reflect the last Ethereum snapshot ? (they decide on
    snapshot.csv)
 
-4. Can they properly boot the network and have they practiced being
+6. Can they properly boot the network and have they practiced being
    the BIOS Boot node.
 
-5. Can they properly boot a node and mesh into the network, have they
+7. Can they properly boot a node and mesh into the network, have they
    practiced `join` ?
 
 
@@ -192,17 +198,6 @@ https://stages.eoscanada.com
 
 
 
-Example flow and interventions in the orchestrated launch
----------------------------------------------------------
-
-1. Everyone runs `eos-bios orchestrate`.
-1. `eos-bios` downloads the network topology pointed to by your `my_discovery_file.yaml`, as does everyone.
-1. The network topology is sorted by weight according to how people voted in their `peers` section.
-1. The `launch_ethereum_block` is taken from the top 20% in the topology: if they all agree, with continue with that number. Otherwise, we wait until they do (and periodically retraverse the network graph)
-
-
-
-
 Install / Download
 ------------------
 
@@ -218,6 +213,8 @@ Alternatively, you can build from source with:
 This will install the binary in `~/go/bin` provided you have the Go
 tool installed (quick install at https://golang.org/dl)
 
+Add `-u` to `go get` to pull updates.
+
 
 
 Join the discussion
@@ -240,7 +237,6 @@ Readiness checklist
 
 * Did I update my `target_p2p_address` to reflect the IP of the NEW network we're booting ?
 * Did I update my `target_http_address` to point to my node, reachable from `eos-bios`'s machine ?
-*
 
 
 Troubleshooting
@@ -250,117 +246,5 @@ Troubleshooting
   you published in your discovery file under
   `target_initial_authority` and `target_initial_block_signing_key` ?
 
-* Forked ? Did someone point to an old p2p address ? If so, removed
+* Forked ? Did someone point to an old p2p address ? If so, remove
   them from the network.
-
-
-
-TODO
-----
-
-* In Orchestrate, compute the LaunchData by the most votes, weighted by the highest Weight
-
-  * Find out what we do for the chain_id.. do we vote for it too ?
-    Top 20%, max 5 must agree on the chain_id ?
-    Top 20%, max 5 must agree on the constitution ?
-
-* boot_connect_mesh: Make sure we don't mesh with the first BIOS
-  boot..  it's most probably not running.. but perhaps it's neat if it
-  connects when it is up.. at least to get the blocks.
-
-* Dedupe the p2p-address in join and mesh..
-
-* Display time of the launch block (or delta)
-
-* Implement contents disagreement
-
-* Upgrade to dawn4.1, docker hub, pub eosio.unregd, maintain `eos`
-  with CORE_SYMBOL_NAME=EOS applied, publish Docker image, with disco
-  and unregd contracts.
-
-* Destroy `eosio`'s signing key also. What happens is someone votes
-  for `eosio` enough that he's able to produce ? Then the original
-  launcher would have that key.. well it would have been
-  published.. so anyone really would have access to that (!!).
-
-* Only download the IPFS refs from the top X that can take the
-  decision.. so we're not slowed down by some who never push their
-  files.
-
-* p2p chain validation.. should wait until the `target_p2p_address` is
-  reachable..  not fail right away.. and retry.
-
-* eos-bios publish: should display the number of seconds left until launch block
-
-* try to get blocks again.. now that ABI things are fixed.. ABI won't
-  change during the schebang
-
-* solve the p2p connection error, when doing validation (!!!)
-  network-version-match mismatch connection closed because of that..
-
-  * don't use the p2p, rather use the http endpoint for validation..
-  * poke until it answers..
-
-* sample_config: Docker image should use dawn 4.1 instead of 4.0.0
-
-* readiness loop:
-  * wait for launch block
-  * wait for consensus on contents, launch block, chain_id / constitution hash ?
-    * sleep 5 seconds
-  * wait for participation levels ? publish participation ?
-
-* ipfs: attempt to download from many ipfs gateways, first being `--ipfs`
-
-* do direct meshing (outgoing) from bios boot to other nodes.. don't boot_connect_mesh.sh
-  instead the bios boot has a firewalled entrypoint or something..
-  connect_mesh could unlock firewall perhaps..
-
-* implement a sort of `--json` output for those wanting to use the tool to do other things..
-  * export the `genesis` for a given name, export the disco file for a given name.
-  * perhaps simply give example `cleos` calls to do the same..
-
-* Replace `b1` in the contract, or relace `b1b1b1b1b1b1` by `b1` in here.
-  * Create the `b1` account before setting the `eosio.system` contract ?
-
-* How will we call `setprods` if it's not in `eosio.bios` anymore ? (!!)
-  * Added to eosio.system
-
-* Don't download IPFS refs, unless it was voted on by the top X..
-  * Anyone can block the flow right now, otherwise..
-
-* Add a "participate" contract publishing.. so we consider for meshing only those who are
-  actively running "orchestrate".
-
-* FIX THE REVERSE target block launch number thing..
-
-* Duplicate target account, fails at account creation.  We should ignore the nodes that
-  have multiple KEYS and multiple TARGET ACCOUNTS..
-  * Which one we choose ? The first updated at ? we don't want someone to be able to
-    take you out merely because they publish a similar `target_account_name`.
-  * Let the social graph fix it up?
-
-
-Desired output for network:
-
-```
-Role       Seed Account  Target Acct   Weight  Contents          Launch block (local time)
-----       ------------  -----------   ------  ----------------  ------------
-BIOS NODE  eosmama       eoscanadacom  10      1112211           500 (Fri Nov 7th 23:36, local time)
-ABP 01     eosmarc       eosmarc       5       1111112           572 (Fri Nov 8th 00:25, local time)
-ABP 02     eosrita       eosrita       2       1111111           572 (Fri Nov 8th 00:25, local time)
-ABP 03     eosguy        eosguy        1       1111111           572 (Fri Nov 8th 00:25, local time)
-ABP 04     eosbob        eosbob        1
-
-Contents disagreements:
-* About column 4: `boot_sequence.yaml`
-  * eosmarc, eoscanadacom, eospouet says 1: /ipfs/Qmakjdsflakjdslfkjaldsfk
-  * eosmama says 2: /ipfs/Qmhellkajdlakjdsflkj
-```
-
-
-Things that need testing upon launch
-------------------------------------
-
-* Test the eosio.msig machinery, a bunch of BPs need to be able to pass in a proposed
-  transaction.
-* Cross validae the b1 vesting schedule.

README.nobios.md

@@ -0,0 +1,50 @@
+How to participate in an `eos-bios` launch without using `eos-bios`
+-------------------------------------------------------------------
+
+This means participating in ithe `eos-bios` consensus mechanism through the `eosio.disco` contract, yet not running `eos-bios` to either `boot` or `join`.
+
+The `boot` of the network requires a participating to run `eos-bios`,
+since all other participants are expecting injection of content based
+on its computed consensus content.
+
+The `join` operation can be done manually by simply getting the
+genesis.json from the advertised, randomly chosen boot node, finding a
+few p2p peers, and booting your node with that configuration in.
+
+
+Publishing your participation
+=============================
+
+To participate, simply take a copy of `sample_config/my_discovery_file.yaml`, convert it to `.json`,
+make the appropriate tweaks and inject it in the SEED network this way:
+
+Enclose the resulting `json` in this struct:
+
+```
+{
+ "account": "youraccountname",
+ "disco": CONTENTS OF CONVERTED YAML
+}
+```
+
+Then
+
+    cleos push action -u http://a-seed-network-node eosio.disco updtdisco "`cat mydisco.json`" -p yourname
+
+
+Accessing the consensus data
+============================
+
+You can also access the genesis from the boot node through this command:
+
+    cleos get table -u ... eosio.disco eosio.disco genesis --limit 1000
+
+You can fetch the other participants' discovery file with:
+
+    cleos get table -u ... eosio.disco eosio.disco discovery --limit 1000
+
+From there, you can pluck out `target_p2p_address` from *active*
+participants (those who have an `updated_at` more recent than 30
+minutes).
+
+That's !