ethereum / yellowpaper

The "Yellow Paper": Ethereum's formal specification

Ethereum Yellow Paper

The Yellow Paper is a formal definition of the Ethereum protocol, originally by Gavin Wood, currently maintained by Nick Savers and with contributions from many people around the world.

It is a free culture work, licensed under Creative Commons Attribution Share-Alike (CC-BY-SA) Version 4.0.

Repository Currently Outdated

The Yellow Paper is out of date. It reflects the Ethereum specification up to the Paris network upgrade ("the merge"), activated on the Ethereum mainnet at block 15_537_394 (September 2022).

It does not contain changes introduced in any post-merge upgrade.

An alternative Python Execution Layer specification is actively maintained and up to date.

Usage

If you just want to read the paper, the latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf. If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text.

However, if you want to edit the paper, then read on. The paper comes as a single latex file Paper.tex.

It is recommended to use an IDE such as Visual Studio Code with the LaTeX Workshop extension, to edit the tex file, and show the PDF.

Another option is to separately edit the tex file and build as follows (you'll still need to clone the repo then open the yellowpaper folder):

git clone https://github.com/ethereum/yellowpaper.git
cd yellowpaper
./build.sh

This will create a PDF version of the Yellow Paper. Following building, you can also use standard pdflatex tools for compiling/preview, like http://latex.informatik.uni-halle.de/latex-online/latex.php.

Tips on editing

You can use TeX Stack Exchange; https://en.wikibooks.org/wiki/LaTeX/ (e.g. Bibliography Management and Hyperlinks); and BibTeX editor.

Versions

The previous protocol versions are listed in BRANCHES.md.

Other language versions

• Chinese translated by YuanGe and GaoTianlu.
• French translated by Asseth (checkout to branch 'french' ).
• Vietnamese translated by KodyFanz (checkout to branch 'vietnamese').

yellowpaper's Issues

tiny typo fix

http://i.imgur.com/bW6BbfF.png

The number of stack params
should be on the left column
as params to be removed.

Confusion about y function definition in Appendix E: What set is k_0` in?

The latex source has:

Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus:
\begin{eqnarray}
y(\mathfrak{I}) & = & \{ (\mathbf{k}_0' \in \mathbb{Y}, \mathbf{v}_0 \in \mathbb{B}), (\mathbf{k}_1' \in \mathbb{Y}, \mathbf{v}_1 \in \mathbb{B}), ... \} \\
\forall_n \quad \forall_{i: i < 2\lVert\mathbf{k}_n\rVert} \quad \mathbf{k}_n'[i] & \equiv &
\begin{cases}
\lfloor \mathbf{k}_n[\lfloor i \div 2 \rfloor] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\
\mathbf{k}_n[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise}
\end{cases}
\end{eqnarray}

Doesn't \mathbb{Y} in the first equation here (equation (131)) represent the set of byte values (ie 2^256 possible values)? This is given as the set which contains \mathbf{k}_0' but the following equation, (132) presents \mathbf{k}_n' as a sequence of nibbles.

I'm following the definition of \mathbb{Y} given in Appendix C:

Where $\mathbb{Y}$ is the set of bytes.

So should equation (131) be changed to rely on a new set defined as "all possible nibble sequences"?

genesis block difficulty not matching poc6 clients

Appendix H. Genesis Block has
2^22 refers to the difficulty

The clients (cpp, py, JS) are using:
INITIAL_DIFFICULTY = 2 ** 17

Parent issue for all updates of uncle logic / validation

@vbuterin @gavofyork Please review / edit the below as necessary.

• Change uncle reward from 15/16 to X/Y ?
• Change maximum number of uncles allowed per block to 2?
• Change uncle reward logic to depend on Nth generation? I.e., miner only receives full uncle reward after uncle header inclusion in N consecutive blocks.
• While the uncle uniqueness is technically defined as the uncles are defined as a set, this could be clarified with a short explicit mention.

Question on total gas used euation

https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L589

Here the total used gas is defined to g_0 plus g', but g' is defined to 'gas remaining', is this a typo?

uncles list order

Is it important to define the order of the uncle list? Right now the unclesHash in the block header is defined as "The Keccak 256-bit hash of the uncles list portion of this block; formally H_u.". Later int Eq. 27 it is stated: "H_u ≡ KEC(RLP(L*_H(B_U)))" But the order in B_U is not defined.

minGasPrice vs minGasLimit

There is no mention of minGasPrice anywhere else in the document besides the block-definition.

minGasPrice: A scalar value equal to the minimum price of gas a transaction must have provided in order to be sufficient for inclusion by this miner in this block; formally Hm

Although later on page 10, 11.2 minGasLimit appears with reference to the same scalar value BHm, there is no mention about the rationale behind this value nor how this should be calculated.

As specified in that same paragraph, the code calculates whether the lowest gasPrice of all processed transactions isn't smaller than minGasPrice (See BlockInfo.cpp) and in the clients (cpp, go, java) currently this is hardcoded to 10000000000000 (except for genesis block where it is 0).

Lacking opening bracket

Below there is a closing bracket, but no opening bracket.

Each receipt, denoted BR[i] for the ith transaction) 

Extending RLP Coding from 128 to 256

Markdown version??

Latex??

Inconsistent usage of account subscript b

https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L188

It says sigma[a]_b is account balance.

https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L628

Here sigma[a]_b represents body code of account b.

Update # words in memory for CODECOPY, etc.?

The definitions for instructions such as MSTORE have an explicit annotation specifying how \boldsymbol{\mu}_i (# words in memory) should change. However, for instructions such as CODECOPY, no such annotation exists. Is this an error?

Also, in the definition for SHA3, \boldsymbol{\mu}_i is changed, but there is no annotation specifying a write to memory. Why is this? Is this an error?

order of fields of transactions

The paper show the order of the fields of transactions as

nonce gasPrice gasLimit to value data vrs

But I think the cpp orders them as

nonce value gasPrice gasLimit to data vrs

Typo in exceptions regarding state changes

"Like the out-of-gas (OOG) exception, they not leave state changes intact."

Shouldn't it be ?
"Like the out-of-gas (OOG) exception, they leave the state intact"

Formalise proof-of-work

For the release series, we use a more complex proof-of-work. This has yet to be formally defined

It might be time to formally define it.

Typo in is-kin definition

https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L973

Here should be k(U, P(H), n-1) to form recursion?

genesis: sha3 on nonce ?

BlockInfo.cpp
-----------------

sha3(bytes(1, 42));

In the YP appendix I , you don't do sha3 on nonce ?
which one is the right one ?

RLP Encoding when no-ASCII are used

RLP Encoding, specially when no-ASCII are used, let's say an Ethereum application used the following string, "cafés", the RLP of this simple string will depend how it was edited first time:

cafés has this number of bytes: 7

Its hex is 63 61 66 65 CC 81 73

cafés has this number of bytes: 6

Its hex is 63 61 66 C3 A9 73

The coding is in https://github.com/efaysal/RLP_Encoding_Discussion_Ethereum.

I dont know if this can be exploited in any Ethereum application, however using only ASCII characters seems to be the most reasonable way or safe way to go.

Reducing storage for empty blocks

When mining for Ethereum, even if there are no transactions, blocks and even more uncles are created roughly every minute. . Once people start using Ethereum not all blocks will be empty, but (especially in the start) many of them will be... Although empty blocks aren't very big (~200 bytes) the total of 60_24_365 adds up per year to ~100MB and that is without uncles.

For empty blocks only the following contain new unique information:

• parentHash
• unclesHash (can be empty string in case there are no uncles)
• coinbase
• timestamp
• nonce
• hash

The rest can all either be derived or retrieved from parent

• number (parent+1)
• difficulty (calculated based on parent + timestamp)
• minGasLimit (hardcoded to 10000000000000)
• gasLimit (calculated based on parent & no gasUsed)
• gasUsed (because 0 transactions)
• stateRoot (same as parent)
• transactionsTrie (same as parent)
• extraData (currently not used and not defined)

A reduction in storage and network traffic could be implemented for these empty blocks by replacing these items with a single isEmpty flag.

BYTE instruction definition

BYTE instruction definition defines only 8 bit of the output. What are the values of the rest?

A malicious miner can consume resources "for free".

With the current way transaction fees are awarded, a miner can include spam transactions in the blockchain at no cost (since all that he spends to create them is rewarded back to himself right away).

This is a separate issue from #15: #15 exacerbates this problem by making it possible even for a "poor" miner to spam the blockchain. Even if that were solved, a rich enough miner (or a collusion of miners) can spam the blockchain.

As a possible solution, we could "delay" the mining rewards.
For example:

• Add a new information in the block header (let's call it reward) which starts with a value of 0 in the genesis block
• When mining, compute the amount of ether that has been spent in gas fees in this block (let's call it fee)
• Reward the miner with a * reward + b * fee ether (where a and b are predetermined numbers between 0 and 1)
• Recalculate reward: reward = reward + fee - (a * reward + b * fee)

This way the transaction rewards get partially "diluted" in future blocks, making it more taxing for an evil miner to include spam transactions in the block he is mining.

Question on exceptional halting

https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L855

In the paragraph below definition 110, it says 'if a CALL, CALLCODE or CREATE instruction is executed when the call stack limit of 1024 is reached'. Which part of definition 110 does it correspond?

And it's also hard to understand 'The astute reader will realise that this implies that no instruction can, through its execution, cause an exceptional halt.' Will JUMP to invalid destination cause an exceptional halt?

Disambiguate "c" function for PUSH2-32 instructions when used on ranges

https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L1816

When a push operation requires more bytes than exists in the code, the "c" function ensures bytes default to zero. The function is defined as applied to an index, but then it's used on an index range in definitions of PUSH2-32 instructions.

If the meaning is to map c over the range, then the program
0x7f010203 would be equal to 0x7f0102030000000000000000000000000000000000000000000000000000000000

The Go client does not implement the above behavior; rather it considers
0x7f010203 equal to
0x7f0000000000000000000000000000000000000000000000000000000000010203

The behavior of the "c' function on index ranges should be formalized.

Need to define Gas Reward Order.

In cases where where the coinbase is suiciding, the order in which the gas is rewarded to the coinbase and the suicide refund is given needs to specified.

SEC-3 Discrepancies Between CPP-Ethereum and the Ethereum Yellow Paper

time sync

What if a malicious miner puts a very high timestamp in his block header. The block should still be valid, since the only condition in the YP is timestamp > timestamp of parent block. Now he can continue to mine with his wrong clock and all the other miners will always fail on this condition. What is the current solution to this problem? Is it enough to specifiy something in the network protocol for time syncing between peers, or do we need to have something in the YP?

Homestead block still showing as TBA

With the homestead block being announced, shouldn't all instances of TBA be changed to 1.150.000?

ambiguous formulation

You denote σ[a]_s to be the hash of the root node of the storage trie of an account (page 3). After defining a conveniant function which gives a new meaning to that variable you say "It shall be understood that σ[a]_s is not a ‘physical’ member of the account and does not contribute to its later
serialisation." You now have two meanings for the same variables, I think one should have two different names for it.

Equation: 120, when w=JUMPI, outcome of JUMPI depends on µs[1] too, so the exception Z and its coding

In Exceptional Halting: Equation: 120,

(w ∈ {JUMP, JUMPI} ∧ µs[0] not in D(Ib)) --^^--

should be separated as the outcome of JUMPI is also depending on the value of µs[1]. Better to use the following:

(w =JUMP ∧ µs[0] not in D(Ib)) V (w =JUMPI ∧ µs[1] != 0 ∧ µs[0] not in D(Ib)) ... if µs[1] = 0, JUMPI is just shifting the pc by one, and it should be an opcode not data assuming that pc+1 is less than the total number of opdodes in Ib.

--^^-- comes to:

(w =JUMP ∧ µs[0] not in D(Ib)) V (w =JUMPI ∧ µs[1] != 0 ∧ µs[0] not in D(Ib)) V (w =JUMPI ∧ µs[1] = 0 ∧ pc+1 > Ic|)

Also is the coding of JUMPI used µs[1]?

Implicitly the condition related to µs[1] is tested in "if (m_stack[m_stack.size() - 2])", is this robust?

case Instruction::JUMPI:
if (m_stack[m_stack.size() - 2])
nextPC = verifyJumpDest(m_stack.back(), m_jumpDests);
m_stack.pop_back();
m_stack.pop_back();
break;

Block reward calculation typo

(112) describes (1+Bu/8)*Rb but the text descibes (Bu*1/8)*Rb
It seems like the latter is true for poc5

Online version

Hi Gav,

Here's an online version for people to more quickly read: https://github.com/Latrasis/yellowpaper/tree/gh-pages
Using Mathjax to render the Latex and Gh-pages for hosting.

A Gh-Pages branch on the master is needed to start a pull request.

Thanks

Need to properly define total difficulty.

Typo in EVM description

There seems to be a typo in 9.1. Basics (page 8)

".... it is stored in a separately in a virtual ROM"

https://github.com/ethereum/latexpaper/blob/master/Paper.tex#L606

m should mean {B_H}_c?

This equation: https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L578

The right side should be coinbase addr?

Please add build instructions or a build system.

I would like to generate a pdf with the same toolchain as the releases at: http://gavwood.com/Paper.pdf

I'd especially appreciate a Makefile and a README that explains which tools to install (and for my case specifically, apt-get packages to install).

Request for clarification about "acceptable precision" in ``\subsection{Trie Database}``.

The Appendix E.1: Trie Database subsection has this quote:

we simply define the identity function mapping the key-value set $\mathfrak{I}$ to a 32-byte hash and assert that only a single such hash exists for any $\mathfrak{I}$, which though not strictly true is accurate within acceptable precision.

The assertion that this is not strictly true puzzles me, because I currently believe that \texttt{\small TRIE}(\mathfrak{I}) is defined deterministically in terms of the input and all of its building blocks: n, c, HP, RLP, and SHA3.

If that assumption is true, then only a single such hash exists for any \mathfrak(I) without qualifiers, correct?

My guess is that the statement's logic is switched, or I am misreading it, and it is alluding to the fact that for a given a 256-bit hash value there are an infinite number of \mathfrak(I) inputs for which \texttt{\small TRIE}(\mathfrak{I}) evaluates to that 256-bit value, but that practically this is not a problem due to SHA3 collision resistance.

Maybe the paper would benefit from another sentence clarifying what is meant by "acceptable precision" - if it's alluding to collision resistance, then it could explicitly state so. If there is some non-determinism in \texttt{\small TRIE}(\mathfrak{I}) it should definitely make that clear.

Log fires, but contract is not stored at address

When creating a contract with not providing enough gas, it happened in my case that the contract was executed and the log was fired and stored, but the contract code was never stored at the address.

This might have happened as the gas was enough to process the contract, but not enough to store the contract. In this case we shouldn't send/store the logs, as you otherwise can't rely on them.

From my perspective the logs should always represent the state and in this case it wouldn't, as the address never has that code.

To reproduce, create this contract, which gets an identifier (0xed73a407a655e3a66316d615d648fdd58a79dbd34cc243d6bf1218654df710d8) passed to its constructor:

{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"from":"0x343c98e2b6e49bc0fed722c2a269f3814ddd1533","data":"60206116046004396004805190602001505b5b5b600160006000508190555060016001600050819055503373ffffffffffffffffffffffffffffffffffffffff166002600050600160005054610100811061005657005b9090016000508190555060016000505461010260005060003373ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600050819055505b6100a3610100565b610107600050819055505b3073ffffffffffffffffffffffffffffffffffffffff16817f6e765c1505df7edb32788588e8f625dd368914ea995e3d429094152b826977a76040604090036040a35b506114f1806101136000396000f35b6000620151804204905061010f565b9056006000357c010000000000000000000000000000000000000000000000000000000090048063173825d9146100fe5780632f54bf6e146101155780635c52c2f5146101305780637065cb4814610141578063797af62714610158578063b20d30a914610173578063b61d27f61461018a578063b75c7dc6146101bc578063ba51a6df146101d3578063cbf0b0c0146101ea578063f00d4b5d14610201576100f85b60003411156100f5577fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c60403373ffffffffffffffffffffffffffffffffffffffff168152602001348152602001604090036040a15b5b565b60006000f35b61010f6004803590602001506105e9565b60006000f35b61012660048035906020015061079a565b8060005260206000f35b61013b600450610810565b60006000f35b6101526004803590602001506104ab565b60006000f35b610169600480359060200150610b6f565b8060005260206000f35b6101846004803590602001506107dc565b60006000f35b6101b26004803590602001803590602001803590602001906004018035906020019150610885565b8060005260206000f35b6101cd60048035906020015061021e565b60006000f35b6101e460048035906020015061071c565b60006000f35b6101fb600480359060200150610844565b60006000f35b610218600480359060200180359060200150610321565b60006000f35b600060006000600061010260005060003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060005054935060008414156102675761031a565b8360020a925061010360005060008681526020019081526020016000206000915091506000838383506001016000505416111561031957818150600001600081815054809291906001019190505550828282506001016000828282505403925050819055507fc7fb647e59b18047309aa15aad418e5d7ca96d173ad704f1031a2c3d7591734b60403373ffffffffffffffffffffffffffffffffffffffff168152602001868152602001604090036040a15b5b5050505050565b600060406000368082843782019150506040900360402061034181610e78565b156104a45761034f8361079a565b1561035a57506104a6565b61010260005060008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600050549150600082141561039c57506104a6565b6103a4611315565b8273ffffffffffffffffffffffffffffffffffffffff1660026000508361010081106103cc57005b90900160005081905550600061010260005060008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600050819055508161010260005060008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600050819055507fb532073b38c83145e3e5135377a08bf9aab55bc0fd7c1179cd4fb995d2a5159c60408573ffffffffffffffffffffffffffffffffffffffff1681526020018473ffffffffffffffffffffffffffffffffffffffff168152602001604090036040a15b505b505050565b6040600036808284378201915050604090036040206104c981610e78565b156105e4576104d78261079a565b156104e257506105e6565b6104ea611315565b60fa600160005054101515610503576105016110db565b505b60fa60016000505410151561051857506105e6565b60016000818150548092919060010191905055508173ffffffffffffffffffffffffffffffffffffffff166002600050600160005054610100811061055957005b9090016000508190555060016000505461010260005060008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600050819055507f994a936646fe87ffe4f1e469d3d6aa417d6b855598397f323de5b449f765f0c360408373ffffffffffffffffffffffffffffffffffffffff168152602001604090036040a15b505b50565b600060406000368082843782019150506040900360402061060981610e78565b156107165761010260005060008473ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060005054915060008214156106505750610718565b600160016000505403600060005054111561066b5750610718565b6000600260005083610100811061067e57005b90900160005081905550600061010260005060008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600050819055506106c6611315565b6106ce6110db565b507f58619076adf5bb0943d100ef88d52d7c3fd691b19d3a9071b555b651fbf418da60408473ffffffffffffffffffffffffffffffffffffffff168152602001604090036040a15b505b5050565b60406000368082843782019150506040900360402061073a81610e78565b15610795576001600050548211156107525750610797565b81600060005081905550610764611315565b7facbdb084c721332ac59f9b8e392196c9eb0e4932862da8eb9beaf0dad4f550da6040838152602001604090036040a15b505b50565b6000600061010260005060008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600050541190506107d7565b919050565b6040600036808284378201915050604090036040206107fa81610e78565b1561080b5781610106600050819055505b505b50565b60406000368082843782019150506040900360402061082e81610e78565b15610840576000610105600050819055505b505b565b60406000368082843782019150506040900360402061086281610e78565b15610880578173ffffffffffffffffffffffffffffffffffffffff16ff5b505b50565b600061089084611275565b1561095c577f92ca3a80853e6663fa31fa10b99225f18d4902939b4c53a9caae9043f6efd00460403373ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018673ffffffffffffffffffffffffffffffffffffffff168152602001848490918181526020018282808284378201915050915050604090036040a18473ffffffffffffffffffffffffffffffffffffffff16846000600060008787808284378201915050600084866185025a03f161094e57005b505060006001029050610b67565b6040600036808284378201915050438152602001604090036040209050805061098481610b6f565b1580156109e457506000610108600050600083815260200190815260200160002060005060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16145b15610b665784610108600050600083815260200190815260200160002060005060000160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908302179055508361010860005060008381526020019081526020016000206000506001016000508190555082826101086000506000848152602001908152602001600020600050600201600050919082805482825590600052602060002090601f01602090048101928215610abb579182015b82811115610aba578235826000505591602001919060010190610a9c565b5b5090505b80821115610ad95760008181506000905550600101610abf565b5050600050507f1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf3260408281526020013373ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018673ffffffffffffffffffffffffffffffffffffffff168152602001848490918181526020018282808284378201915050915050604090036040a15b5b949350505050565b600081610b7b81610e78565b15610e71576000610108600050600085815260200190815260200160002060005060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16141515610e7057610108600050600084815260200190815260200160002060005060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16610108600050600085815260200190815260200160002060005060010160005054600060006000610108600050600089815260200190815260200160002060005060020160005080548015610ca257820191906000526020600020905b815481529060010190602001808311610c8e575b5050600084866185025a03f1610cb457005b50507fe7c957c06e9a662c1a6c77366179f5b702b97651dc28eee7d5bf1dff6e40bb4a60403373ffffffffffffffffffffffffffffffffffffffff1681526020018481526020016101086000506000868152602001908152602001600020600050600101600050548152602001610108600050600086815260200190815260200160002060005060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020016101086000506000868152602001908152602001600020600050600201600090918254815260200182825080548015610dcf57820191906000526020600020905b815481529060010190602001808311610dbb575b5050915050604090036040a1610108600050600084815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff0219169055600182016000506000905560028201600050805460008255601f0160209004906000526020600020908101905b80821115610e625760008181506000905550600101610e48565b505050506001915050610e73565b5b505b919050565b6000600060006000600061010260005060003373ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000505493506000841415610ec3576110d2565b61010360005060008781526020019081526020016000206000925092506000838350600001600050541415610f9b576000600050548383506000016000508190555060008383506001016000508190555061010460005080548091906001019090815481835581811511610f5d578183600052602060002091820191015b80821115610f5b5760008181506000905550600101610f41565b505b50505083835060020160005081905550856101046000508484506002016000505481548110610f8857005b9060005260206000209001600050819055505b8360020a9050600081848450600101600050541614156110d1577fe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda60403373ffffffffffffffffffffffffffffffffffffffff168152602001878152602001604090036040a16001838350600001600050541115156110a0576101046000506101036000506000888152602001908152602001600020600050600201600050548154811061104557005b906000526020600020900160005060009055610103600050600087815260200190815260200160002060006000820160005060009055600182016000506000905560028201600050600090555050600194506110d2566110d0565b82825060000160008181505480929190600190039190505550808383506001016000828282505417925050819055505b5b5b50505050919050565b60006000600190505b600160005054811015611270575b6001600050548110801561111e57506000600260005082610100811061111457005b9090016000505414155b156111305780806001019150506110f2565b5b6001600160005054118015611162575060006002600050600160005054610100811061115957005b90900160005054145b1561118157600160008181505480929190600190039190505550611131565b600160005054811080156111b257506000600260005060016000505461010081106111a857005b9090016000505414155b80156111d55750600060026000508261010081106111cc57005b90900160005054145b1561126b57600260005060016000505461010081106111f057005b90900160005054600260005082610100811061120857005b90900160005081905550806101026000506000600260005084610100811061122c57005b9090016000505481526020019081526020016000206000508190555060006002600050600160005054610100811061126057005b909001600050819055505b6110e4565b5b5090565b60006112803361079a565b1561130f57610107600050546112946114df565b11156112b9576000610105600050819055506112ae6114df565b610107600050819055505b61010560005054826101056000505401101580156112e557506101066000505482610105600050540111155b15611306578161010560008282825054019250508190555060019050611310565b60009050611310565b5b919050565b60006000610104600050549150600090505b818110156113e7576101086000506000610104600050838154811061134857005b906000526020600020900160005054815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff0219169055600182016000506000905560028201600050805460008255601f0160209004906000526020600020908101905b808211156113d557600081815060009055506001016113bb565b505050505b8060010190508050611327565b6113ef6113f4565b5b5050565b60006000610104600050549150600090505b818110156114a4576000600102610104600050828154811061142457005b906000526020600020900160005054141515611496576101036000506000610104600050838154811061145357005b9060005260206000209001600050548152602001908152602001600020600060008201600050600090556001820160005060009055600282016000506000905550505b5b8060010190508050611406565b610104600050805460008255906000526020600020908101905b808211156114d857600081815060009055506001016114be565b50505b5050565b600062015180420490506114ee565b9056ed73a407a655e3a66316d615d648fdd58a79dbd34cc243d6bf1218654df710d8","gas":"0x16e360","gasPrice":"0x9184e72a000"}],"id":1576}

Create filter:

{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":[null,"0xed73a407a655e3a66316d615d648fdd58a79dbd34cc243d6bf1218654df710d8",null],"fromBlock":"0x1102","toBlock":"latest"}],"id":1577}

Use get logs later, or use getFilterChanges:

{jsonrpc: "2.0", method: "eth_getFilterLogs", params: [<myID>], id: 1578}

You will get a log, fired from the constructor, but when checking with eth_getCode, the contract is not there:

{"jsonrpc":"2.0","method":"eth_getCode","params":["0xdb9b9acc69859efe708d41b99e192954682f86bf","latest"],"id":6038}

Result:

{
    "id": 6038,
    "jsonrpc": "2.0",
    "result": "0x"
}

Behavior if a coinbase does not exist in provisional state?

Sorry if I'm missing something!

Equation (68) tells us we must add the price of the used gas to the coinbase account when transitioning from the provisional to the prefinal state, but AFAICT nowhere requires that the coinbase account pre-exist nor indicates what should be done if it does not exist.

I think that the intended behavior is to add a new account with the incoming ether, but it's also plausible that specifying a nonexistent coinbase would raise some kind of error or that the operation would be skipped and the incoming ether simply lost.

Extraneous comma

The comma below is terribly out of place.

 Invalid state changes might, e.g. be things such as reducing and account balance without an equal and opposite increase elsewhere.

Add timestamp and a link to this GitHub repo

Please add "last modified XXX" somewhere, and a link to this GitHub repo.

http://www.reddit.com/r/ethereum/comments/2x62jn/how_up_to_date_is_the_yellow_paper/

PoC6 changes

• Network Protocol Changes
  https://github.com/ethereum/cpp-ethereum/wiki/PoC-6-Network-Protocol
• new/changed opcodes
  • POST
  • DUP
  • SWAP
• creation address is 0x00 instead of 0x0000000000000000000000000000000000000000
• genesis difficulty is 0x020000
• the blank codeHash for accounts is 0x00instead of sha3(null)

H_u variable is overloaded

In Section 4.3 ("The Block"), both unclesHash and gasUsed are defined as H_u.

A miner can include in a block multiple transactions with a total gas cost way beyond his current ether balance.

How to reproduce (with AlethZero):

• Disconnect from network
• Kill the blockchain
• Mine one single block then stop: your ether is now 1500 finney.
• Send this contract: { (for [i]:0 (< @i 654) [i]:(+ @i 1) [[@i]]:1) (return 0 (lll stop 0)) } and give it 150000 gas at the default price of 10 szabo per gas.
• Send that same contract a few other times (AlethZero lets you do that 5 times)
• Resume mining
• You will end up creating 5 contracts that would "normally" cost you 7500 finney total.

This can possibly mean that a specially crafted client could be able to spam the blockchain with a lot of resource-consuming contracts (up to the block gas limit) even if said miner has little ether to begin with.

This happens because the mining rewards for transaction inclusion are awarded at the end of each transaction (and, so, before the beginning of the next).

A possible solution might be to delay all those rewards to block finalisation (when the block creation reward is applied).

hash for genesis

Hey that is my genesis block RLP before I sha3 it ,
I fail to get the precious ab6b9a5613970faa771b12d449b2e9bb925ab7a369f0a4b86b286e9d540099cf
any idea what am I missing ?

f8c8
f8c4
a00000000000000000000000000000000000000000000000000000000000000000
a01dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347
940000000000000000000000000000000000000000
a00000000000000000000000000000000000000000000000000000000000000000
a01dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347
83400000
8400000000
80
a004994f67dc55b09e814ab7ffc8df3686b4afb2bb53e60eae97ef043fe03fb829
c0
c0

license

what is it and can a license file be added?

Typo - four exceptions listed above

https://github.com/ethereum/yellowpaper/blob/master/Paper.tex#L727

Inconsistent voice

Part of the yellow paper uses "we", and part of it uses "I". Can we be consistent?

discrepancy between YP and cpp code concerning uncle rewards

the yellow paper says
"We raise the block’s coinbase account by R_b , the block reward, and the coinbase of each uncle by 7/8 of that."

The cpp code says
"raise the coinbase account of each uncle by 3/4 and add to the block's coinbase 1/8 of R_b for each uncle"

RLP Strictness Questions

While working on improving the strictness of the RLP decoder in
go-ethereum (ethereum/go-ethereum#711), a few questions have popped up:

Minimal Size

In any context (also for non-scalars), the following encodings
are invalid because their size is not minimal:

non-canonical encoding	should be
8102	02
B800	80
B90000	80
BA0002FFFF...	B902FFFF...

The paper doesn't seem to resolve this ambiguity. Should it?

Encoding of fixed-size values

Some ethereum values (such as addresses) have a fixed bit width.
go-ethereum currently accepts byte arrays of smaller size and pads the
resulting value with zero bytes.

Example: when decoding into [20]byte, the input 8101 would be accepted and
would produce {1, 0, 0, 0, ...} as the result.

Should the encoding of fixed size types be restricted so the full number
of bytes must be encoded?

Reference glossary

Reference glossary in the introduction to improve reading experience