I would like to get a second print or second edition of the book released by Q2/Q3'2020.

Unfortunately, I cannot focus time on processing all the PRs and Issues to get it done. Many of the examples are out of date and don't compile or work properly. They all need to be updated. Many have already been "fixed" with PRs, but all need to be tested and improved.

I am looking to hire a part-time editor, someone who is willing to put in 30-40 hours of work over the next 3 months to clear out all the outstanding issues, PRs and test all the examples in the book. At the end of it, we will release a new edition or print of the book. The Github editor will be given appropriate attribution in the preface.

Please reply to this issue if you are interested and provide some supporting information as to why I should select you to do this. Also, please post your hourly rate in your reply. Payment will be made in USD, BTC or ETH. US Labor laws apply: I will need tax documentation and cannot hire people from sanctioned countries, but otherwise your location does not matter.

Auction Dapp covers:

• Auction House contracts and ERC721 compliant Token/Deed Repository
• Data storage on swarm
• Whisper messaging
• Frontend and web3 interactions with the smart contracts

Demo: http://52.59.238.144/ Available on Ropsten Or Add Cuctom RPC in metamask and insert the following address:

http://52.59.238.144:8545/

Add these test accounts:

address: 0xC1DF06368AFB95ABe7154978786213A99887aD2A
privateKey: be97a9660105da2a4e2e631b067ac4e08cabdcb2bc85b061b7ffc51d2219162a

address: 0xfFbeB6b8fc95D34535cb89c0b034595E87BE9a31
privateKey: 31013408a0776fe01f2a3cd9306c1780f4188ed577083ecda5b9d27b480808fd

Contributions and improvements are needed!

I think I need to create an architecture diagram that shows the relationship between a web-browser, a web3 .js instance (injected by MetaMask, for example, or provided by a web application), the web3 provider and the Ethereum blockchain. Clarify the role of web3 provider, full client, JSON-RPC client and web3 injector.

Go through each chapter. Anywere a term is defined, check to see if it is in the glossary. If not, copy the definition and edit it appropriately.

Compare entries to other glossaries and see if major entries are missing. If missing, add one by writing it from scratch (not using the text from the other glossary, unless the license allows it):

Homestead Guide (License does not allow us to use anything here. Compare for completeness) https://github.com/ethereum/homestead-guide/blob/master/source/glossary.rst

Yellow Paper (Definitions at the end. License does allow us to use some): https://ethereum.github.io/yellowpaper/paper.pdf

Wiki Glossary (Can use definitions from here, it's CC0) https://github.com/ethereum/wiki/wiki/Glossary

Add links to the bottom of the glossary with attribution if any entries are used from other glossaries.

Through this issue I intend to highlight the importance that it can have for a developer to know what or who governs the evolution of the Ethereum protocol.

For me it would be important to mention in the book the inherent isolation of Ethereum from the outside world and the importance of defining mechanisms, commonly called Oracles, to achieve its interaction with it.

There is already some initiative trying to cover this limitation, such as "http://www.oraclize.it". They define themselves as the "data carrier for decentralized apps".

Maybe there is something more about it out there.

I want to deploy MET to private network. I have created a separate project to deploy MET. The project is here: https://github.com/chainhead/MET that I will raise a PR for eventually.

I have edited my truffle.js to point to my private network.

module.exports = {
	networks: {
		aws: { // Private network on AWS
			network_id: "15",
			host: "public-ip-address",
			port: 8545,
			gas: 6721975
		}
	}
};

The truffle compilation goes through. However, the migration does not give any information about successful deployment. Can you please suggest what may I be missing?

truffle migrate --network aws
Using network 'aws'.

Network up to date.

Also, I noted the following and fixing them in my repository.

• Truffle configuration file points to Faucet.sol in tokens.asciidoc. Shouldn't it be one in METoken.sol?
• Import error for StandardToken.sol.
• Require error for artifacts.require("Migrations").
• Lint errors as per VSCode.

@aantonop recently mentioned that it would be good to cover some topics on Ethereum Classic in the book. I have question, to what extent? Do you want to make just simple remark of the project? Or do you want to cover ETC specific topics and software, such as Classic Geth, SputnikVM and Emerald? There're also other changes, such as different monetary policy, difficulty bomb, and so on. There many things actually to cover. I'd like to help with this part if you would be interested

When a smart contract is running, it has a very limited context (state) it can access through the EVM.

We need a diagram that shows this: A circle or box in the middle that is the EVM and within it the contract. Surrounding it are boxes representing the various parts of the context: one box for the calling transaction context, one for the contract variables, one for the blockchain etc. Each of these boxes contain a list of items that can be accessed from that context (the sender of the transaction, the startGas) and the name of each item as it exists in Solidity (eg. msg.sender).

On the intro.asciidoc, on the metamask section, the testnets are presented. But, the text explaining Kovan is the same as the one explaining Rinkeby:

Kovan Test Network:: Ethereum public test blockchain and network, using Proof-of-Authority consensus (federated signing). ETH on this network has no value.

Rinkeby Test Network:: Ethereum public test blockchain and network, using Proof-of-Authority consensus (federated signing). ETH on this network has no value.

This brings the question about why do we have two, instead of just one. So I think the text should be expanded a little, to include the difference between the two.

It's probably worth dedicating a major section on scalability. In particular,

• Why is scalability critical to Ethereum?
• Why is scalability difficult for Ethereum, probably more difficult than it is for Bitcoin?
• A description of the upcoming scalability solutions, namely, PoS, sharding, plasma, raiden, etc.

A challenge is to write something timeless. Since the R&D teams seem to move very fast with scalability solutions, it's potentially hard for the book to be up to date with the latest developments.

Fixing smart contract example for chapter 9. Current version contains patched smart contracts version and therefore does not contain the vulnerability that is described in the text. I updated the snippet to use the exploited version of smart contract and changed the URL to reference to link to this version too.

https://github.com/ethereumbook/ethereumbook/blob/develop/06transactions.asciidoc#transmitting-value-to-eoas-and-contracts

If the destination address (to) is a contract, then the EVM will execute the contract and will attempt to call the function named in the data payload of your transaction. If there is no data in your transaction, the EVM will call a fallback function ...

This simplification leads to the understanding that such contract's flow and checks are assured by EVM, while it is rather implemented by higher languages (Solidity, ...).

Minimal proxies are the examples, where such statement is not valid.