However, in that case, the interpretation of the data is up to the wallet you use to access the EOA. Source: https://en.wikipedia.org/wiki/Digital_signature. But it is still possible. While this is the actual transaction structure transmitted, most internal representations and user interface visualizations embellish this with additional information, derived from the transaction or from the blockchain. There are two points because the elliptic curve is symmetric across the x-axis, so that for any value x there are two possible values that fit the curve, one on each side of the x-axis. If these two functions are on one computer, then you have private keys on an online system, which is quite dangerous. However, in a decentralized system like Ethereum, nodes may receive the transactions in either order; there is no guarantee that a particular node will have one transaction propagated to it before the other. This demonstrates the functions that would normally be used inside a wallet, or an application that signs transactions on behalf of a user. Given the values r and s that were computed in ECDSA Math, we can compute two possible public keys. If you are familiar with Bitcoins scripting capabilities, you know that it is possible to create a Bitcoin multisig account which can only spend funds when multiple parties sign the transaction (e.g., 2 of 2 or 3 of 4 signatures). This means that anyone who sees your transaction on the Ethereum network (which means everyone, including the recipient or your enemies) can "replay" the transaction again and again and again until all your ether is gone simply by copying and pasting your original transaction and resending it to the network. We can look at the receipt of the transaction to get information about the contract: This includes the address of the contract, which we can use to send funds to and receive funds from the contract as shown in the previous section: After a while, both transactions are visible on Etherscan, as shown in Etherscan showing the transactions for sending and receiving funds. However, if you want to do an intentional ether burn, you should make your intention clear to the network and use the specially designated burn address instead: Any ether sent to the designated burn address will become unspendable and be lost forever. The minimum value that gasPrice can be set to is zero, which means a fee-free transaction. What this means is that if you create several transactions in sequence and one of them does not get officially included in any blocks, all the subsequent transactions will be "stuck," waiting for the missing nonce. However, lets cover some basics about the role of the gasPrice and gasLimit components of a transaction. But the amount is not actually deducted from your account until the transaction finishes executing. k is the signing (EOA owners) private key. All four combinations are valid. This basic definition conceals a lot of surprising and fascinating details. These can be in the same program (e.g., multithreading), on the same CPU (e.g., multiprocessing), or on different computers (i.e., distributed systems). EIP-155 adds three fields to the main six fields of the transaction data structure, namely the chain identifier, 0, and 0. The computer that signs a transaction must have unlocked private keys loaded in memory. Next, we will work with smart contracts in a lot more detail and learn how to program in the Solidity contract-oriented language. While the zero address is intended only for contract creation, it sometimes receives payments from various addresses. The analogy to a fuel tank is somewhat misleading, however. Now, imagine that you have multiple independent wallet applications that are generating transactions from the same address or addresses. For example: If your transactions destination address is a contract, then the amount of gas needed can be estimated but cannot be determined with accuracy. Anything beyond the defined length belongs to the next field in the structure. The resulting transaction structure is RLP-encoded, hashed, and signed. We will discuss this in more detail in [consensus]. When you build an application that constructs transactions, it cannot rely on getTransactionCount for pending transactions. A transaction is a serialized binary message that contains the following data: A sequence number, issued by the originating EOA, used to prevent message replay, The price of gas (in wei) the originator is willing to pay, The maximum amount of gas the originator is willing to buy for this transaction, The amount of ether to send to the destination, The three components of an ECDSA digital signature of the originating EOA. A valid digital signature gives a recipient reason to believe that the message was created by a known sender (authentication), that the sender cannot deny having sent the message (non-repudiation), and that the message was not altered in transit (integrity). One special case that we should mention is a transaction that creates a new contract on the blockchain, deploying it for future use. In an air-gapped system there is no network connectivity at allthe computer is separated from the online environment by a gap of "air." In this section, we look at how digital signatures work and how they can be used to present proof of ownership of a private key without revealing that private key. The next transaction includes a data payload but specifies a value of zero: Our wallet shows a confirmation screen indicating the zero value and the data payload, as shown in Parity wallet showing a transaction with no value, only data. The source code for this example is in the file raw_tx_demo.js in the books GitHub repository: Running the example code produces the following results: The EIP-155 "Simple Replay Attack Protection" standard specifies a replay-attack-protected transaction encoding, which includes a chain identifier inside the transaction data, prior to signing. Parity wallet showing a transaction with value and data, Figure 3. This change affects the form of the transaction and its signature, so attention must be paid to the first of the three signature variables (i.e., v), which takes one of two forms and indicates the data fields included in the transaction message being hashed. 
In the end, these concurrency problems, on top of the difficulty of tracking account balances and transaction confirmations in independent processes, force most implementations toward avoiding concurrency and creating bottlenecks such as a single process handling all withdrawal transactions in an exchange, or setting up multiple hot wallets that can work completely independently for withdrawals and only need to be intermittently rebalanced. K is the signers (EOA owners) public key. These three fields are added to the transaction data before it is encoded and hashed. The next example specifies both a value and a data payload: Our wallet shows a confirmation screen indicating the value to send as well as the data payload, as shown in Parity wallet showing a transaction with value and data. For EOA addresses, or rather for any address that isnt flagged as a contract on the blockchain, Ethereum will record a state change, adding the value you sent to the balance of the address. These contracts can also be designed to require multiple signatures before executing local code or to trigger other contracts. You would have some concurrency, but it would be lacking in a critical part of the process. So far, we have not delved into any detail about digital signatures. Validation should be done at the user interface level. You should also specify a gasPrice and gasLimit.
Etherscan showing the contract successfully mined, Figure 6. As a result, the transaction ripples outwards from the originating node, flooding across the network, until all nodes in the network have a copy of the transaction. When your transaction contains data, it is most likely addressed to a contract address. To demonstrate this, lets look at an example: we can write a smart contract that increments a counter each time it is called and executes a particular loop a number of times equal to the call count. The most common reason is security. Another approach would be to generate the transactions, but not assign a nonce to them (and therefore leave them unsignedremember that the nonce is an integral part of the transaction data and therefore needs to be included in the digital signature that authenticates the transaction). Contract creation transactions are sent to a special destination address called the zero address; the to field in a contract registration transaction contains the address 0x0. Once mined into a block, transactions also modify the state of the Ethereum singleton, either by modifying the balance of an account (in the case of a simple payment) or by invoking contracts that change their internal state. As you can see, keeping track of nonces is necessary, and if your application doesnt manage that process correctly you will run into problems. First, we compute two elliptic curve points, R and R', from the x coordinate r value that is in the signature.
A transaction that has completed its journey from creation through signing by an EOA, propagation, and finally mining has changed the state of the singleton and left an indelible mark on the blockchain. Parity wallet showing a transaction with no value, only data, Figure 4. Produce an RLP-encoded serialized message of the transaction data structure. The computer that does the transmitting must be connected to the internet (and be running an Ethereum client). It is assumed that validation of the address happens at the user interface level (see [EIP55]). Worse, if several nonces are assigned and one of them never gets used (because of a failure in the computer processing the transaction with that nonce), all subsequent transactions get stuck. Transactions are signed messages originated by an externally owned account, transmitted by the Ethereum network, and recorded on the Ethereum blockchain. That means that if you transmit a transaction with nonce 0 and then transmit a transaction with nonce 2, the second transaction will not be included in any blocks. For more information on the chain ID, see Raw Transaction Creation with EIP-155. Thats because the originators public key can be computed directly from the ECDSA signature. Gas is separate from ether in order to protect the system from the volatility that might arise along with rapid changes in the value of ether, and also as a way to manage the important and sensitive ratios between the costs of the various resources that gas pays for (namely, computation, memory, and storage). Again, this data is derived from the transaction, and does not form part of the transaction message itself. However, with the nonce value included in the transaction data, every single transaction is unique, even when sending the same amount of ether to the same recipient address multiple times. Ethereum uses gas to control the amount of resources that a transaction can use, since it will be processed on thousands of computers around the world.
The open-ended (Turing-complete) computation model requires some form of metering in order to avoid denial-of-service attacks or inadvertently resource-devouring transactions. However, this quickly becomes problematic, as having more than one computer producing withdrawals will result in some thorny concurrency problems, not least of which is the selection of nonces. The three steps of creating, signing, and broadcasting a transaction normally happen as a single operation, for example using web3.eth.sendTransaction. How do multiple computers generating, signing, and broadcasting transactions from the same hot wallet account coordinate? Note that in verifying the signature, the private key is neither known nor revealed. To get things moving again, you have to transmit a valid transaction with the missing nonce. There are two explanations for this: either it is by accident, resulting in the loss of ether, or it is an intentional ether burn (deliberately destroying ether by sending it to an address from which it can never be spent). From there, the algorithm calculates the s value of the signature, such that: r is the x coordinate of the ephemeral public key. The signing computer reads the serialized transactions from the queue (carefully), applies a signature with the appropriate key, and places them on an outgoing queue. Other metadata frequently added to the transaction by client software includes the block number (once it is mined and included in the blockchain) and a transaction ID (calculated hash). The neighbor that sent it to the node may be the originator of the transaction or may have received it from one of its neighbors. Your wallet will keep track of nonces for each address it manages. Another way to look at transactions is that they are the only things that can trigger a change of state, or cause a contract to execute in the EVM. Thats because a contract can evaluate different conditions that lead to different execution paths, with different total gas costs. For now, lets assume your transaction is delivering data to a contract address. m is the transaction data that was signed. Thus, by having the incrementing nonce as part of the transaction, it is simply not possible for anyone to "duplicate" a payment you have made. The first part is an algorithm for creating a signature, using a private key (the signing key), from a message (which in our case is the transaction). They therefore change the transactions hash, to which the signature is later applied. Now imagine you have an account with 100 ether. Each Ethereum client acts as a node in a peer-to-peer (P2P) network, which (ideally) forms a mesh network. The contract may execute only a simple computation or a more complex one, depending on conditions that are outside of your control and cannot be predicted. Transfer the unsigned transaction to an "air-gapped" offline device for transaction signing, e.g., via a QR code or USB flash drive. However, this computer is now a single point of failure. This new signing scheme is specified in EIP-155. Any 20-byte value is considered valid. The recipient of a transaction is specified in the to field. Transactions are the "inputs" that cause the Ethereum Virtual Machine to evaluate contracts, update balances, and more generally modify the state of the Ethereum blockchain. It is only used as a destination, with the special meaning "create this contract.". If they agree that it is valid, they store a copy and propagate it to all their neighbors (except the one it came from). In Ethereums implementation of ECDSA, the "message" being signed is the transaction, or more accurately, the Keccak-256 hash of the RLP-encoded data from the transaction. Thereafter, keep track of the nonce in your application until each transaction confirms.
Sadly, you have overlooked the fact that your account contains only 10 ether, so the network cant accept both transactions: one of them will fail. A transaction can create an inadvertent "gap" in the nonce sequence because it is invalid or has insufficient gas. A digital signature is a mathematical scheme that consists of two parts. In this chapter, we will dissect transactions, show how they work, and examine the details. At block #2,675,000 Ethereum implemented the "Spurious Dragon" hard fork, which, among other changes, introduced a new signing scheme that includes transaction replay protection (preventing transactions meant for one network being replayed on others). A digital signature is a mathematical scheme for presenting the authenticity of digital messages or documents. Each neighbor node validates the transaction as soon as they receive it. If we wait a few seconds to allow for network communications to settle down, the getTransactionCount call will return the expected number. This temporary key is used in the calculation of the r and s values to ensure that the senders actual private key cant be calculated by attackers watching signed transactions on the Ethereum network. Secondly, it guarantees non-repudiation: the proof of authorization is undeniable.
Ethereum is a global singleton state machine, and transactions are what make that state machine "tick," changing its state. For example, you may notice there is no from data in the address identifying the originator EOA. The Ethereum network uses a "flood routing" protocol. You fill the tank with as much gas as you think it will need for the journey (the computation needed to validate your transaction). Transactions can have both value and data, only value, only data, or neither value nor data. Therefore, transactions broadcast on one network cannot be replayed on another, hence the name of the standard. Why would you want to separate the signing and transmission of transactions?
In that case, the data will be interpreted by the EVM as a contract invocation. Append the ECDSA signatures computed v, r, and s values to the transaction. Because you sent the more important 6-ether one first, you understandably expect that one to go through and the 8-ether one to be rejected. Verification is the inverse of the signature generation function, using the r and s values and the senders public key to calculate a value Q, which is a point on the elliptic curve (the ephemeral public key used in signature creation). The wallet contract then sends the funds when prompted by an authorized EOA once the spending conditions have been satisfied. From the perspective of each node, it is not possible to discern the origin of the transaction. Maybe on the 100th call it gives out a special prize, like a lottery, but needs to do additional computation to calculate the prize. How do you track nonces? The contract needs to be compiled into a bytecode representation.
For example, in the sample transaction in [intro_chapter] your wallet set the gasPrice to 3 gwei (3 gigawei or 3 billion wei). A number of great guides online take you through it step by step: search for "ECDSA explained" or try this one: http://bit.ly/2r0HhGB. Sending a transaction to the wrong address will probably burn the ether sent, rendering it forever inaccessible (unspendable), since most addresses do not have a known private key and therefore no signature can be generated to spend it. During periods of low demand for space in a block, such transactions might very well get mined. Thats our "function selector" value, which will tell the contract which function we want to call. On average, each Ethereum node maintains connections to at least 13 other nodes, called its neighbors. Once you fill the gap, the network can mine the out-of-sequence transaction that it held in the mempool. We will examine all this in much more detail in [evm_chapter]. The amount of gas you would pay for that depends on how many other transactions have called that function before your transaction is included in a block. That doesnt mean you cannot send a data payload to an EOAthat is completely valid in the Ethereum protocol. Lets say you are writing your own wallet software or some other application that originates transactions. Therefore, EIP-155 makes it impossible for a transaction to be replayed on another chain, because the signatures validity depends on the chain identifier.
In the end, these concurrency problems, on top of the difficulty of tracking account balances and transaction confirmations in independent processes, force most implementations toward avoiding concurrency and creating bottlenecks such as a single process handling all withdrawal transactions in an exchange, or setting up multiple hot wallets that can work completely independently for withdrawals and only need to be intermittently rebalanced. K is the signers (EOA owners) public key. These three fields are added to the transaction data before it is encoded and hashed. The next example specifies both a value and a data payload: Our wallet shows a confirmation screen indicating the value to send as well as the data payload, as shown in Parity wallet showing a transaction with value and data. For EOA addresses, or rather for any address that isnt flagged as a contract on the blockchain, Ethereum will record a state change, adding the value you sent to the balance of the address. These contracts can also be designed to require multiple signatures before executing local code or to trigger other contracts. You would have some concurrency, but it would be lacking in a critical part of the process. So far, we have not delved into any detail about digital signatures. Validation should be done at the user interface level. You should also specify a gasPrice and gasLimit. Etherscan showing the contract successfully mined, Figure 6. As a result, the transaction ripples outwards from the originating node, flooding across the network, until all nodes in the network have a copy of the transaction. When your transaction contains data, it is most likely addressed to a contract address. To demonstrate this, lets look at an example: we can write a smart contract that increments a counter each time it is called and executes a particular loop a number of times equal to the call count. The most common reason is security. Another approach would be to generate the transactions, but not assign a nonce to them (and therefore leave them unsignedremember that the nonce is an integral part of the transaction data and therefore needs to be included in the digital signature that authenticates the transaction). Contract creation transactions are sent to a special destination address called the zero address; the to field in a contract registration transaction contains the address 0x0. Once mined into a block, transactions also modify the state of the Ethereum singleton, either by modifying the balance of an account (in the case of a simple payment) or by invoking contracts that change their internal state. As you can see, keeping track of nonces is necessary, and if your application doesnt manage that process correctly you will run into problems. First, we compute two elliptic curve points, R and R', from the x coordinate r value that is in the signature.
A transaction that has completed its journey from creation through signing by an EOA, propagation, and finally mining has changed the state of the singleton and left an indelible mark on the blockchain. Parity wallet showing a transaction with no value, only data, Figure 4. Produce an RLP-encoded serialized message of the transaction data structure. The computer that does the transmitting must be connected to the internet (and be running an Ethereum client). It is assumed that validation of the address happens at the user interface level (see [EIP55]). Worse, if several nonces are assigned and one of them never gets used (because of a failure in the computer processing the transaction with that nonce), all subsequent transactions get stuck. Transactions are signed messages originated by an externally owned account, transmitted by the Ethereum network, and recorded on the Ethereum blockchain. That means that if you transmit a transaction with nonce 0 and then transmit a transaction with nonce 2, the second transaction will not be included in any blocks. For more information on the chain ID, see Raw Transaction Creation with EIP-155. Thats because the originators public key can be computed directly from the ECDSA signature. Gas is separate from ether in order to protect the system from the volatility that might arise along with rapid changes in the value of ether, and also as a way to manage the important and sensitive ratios between the costs of the various resources that gas pays for (namely, computation, memory, and storage). Again, this data is derived from the transaction, and does not form part of the transaction message itself. However, with the nonce value included in the transaction data, every single transaction is unique, even when sending the same amount of ether to the same recipient address multiple times. Ethereum uses gas to control the amount of resources that a transaction can use, since it will be processed on thousands of computers around the world.
The open-ended (Turing-complete) computation model requires some form of metering in order to avoid denial-of-service attacks or inadvertently resource-devouring transactions. However, this quickly becomes problematic, as having more than one computer producing withdrawals will result in some thorny concurrency problems, not least of which is the selection of nonces. The three steps of creating, signing, and broadcasting a transaction normally happen as a single operation, for example using web3.eth.sendTransaction. How do multiple computers generating, signing, and broadcasting transactions from the same hot wallet account coordinate? Note that in verifying the signature, the private key is neither known nor revealed. To get things moving again, you have to transmit a valid transaction with the missing nonce. There are two explanations for this: either it is by accident, resulting in the loss of ether, or it is an intentional ether burn (deliberately destroying ether by sending it to an address from which it can never be spent). From there, the algorithm calculates the s value of the signature, such that: r is the x coordinate of the ephemeral public key. The signing computer reads the serialized transactions from the queue (carefully), applies a signature with the appropriate key, and places them on an outgoing queue. Other metadata frequently added to the transaction by client software includes the block number (once it is mined and included in the blockchain) and a transaction ID (calculated hash). The neighbor that sent it to the node may be the originator of the transaction or may have received it from one of its neighbors. Your wallet will keep track of nonces for each address it manages. Another way to look at transactions is that they are the only things that can trigger a change of state, or cause a contract to execute in the EVM. Thats because a contract can evaluate different conditions that lead to different execution paths, with different total gas costs. For now, lets assume your transaction is delivering data to a contract address. m is the transaction data that was signed. Thus, by having the incrementing nonce as part of the transaction, it is simply not possible for anyone to "duplicate" a payment you have made. The first part is an algorithm for creating a signature, using a private key (the signing key), from a message (which in our case is the transaction). They therefore change the transactions hash, to which the signature is later applied. Now imagine you have an account with 100 ether. Each Ethereum client acts as a node in a peer-to-peer (P2P) network, which (ideally) forms a mesh network. The contract may execute only a simple computation or a more complex one, depending on conditions that are outside of your control and cannot be predicted. Transfer the unsigned transaction to an "air-gapped" offline device for transaction signing, e.g., via a QR code or USB flash drive. However, this computer is now a single point of failure. This new signing scheme is specified in EIP-155. Any 20-byte value is considered valid. The recipient of a transaction is specified in the to field. Transactions are the "inputs" that cause the Ethereum Virtual Machine to evaluate contracts, update balances, and more generally modify the state of the Ethereum blockchain. It is only used as a destination, with the special meaning "create this contract.". If they agree that it is valid, they store a copy and propagate it to all their neighbors (except the one it came from). In Ethereums implementation of ECDSA, the "message" being signed is the transaction, or more accurately, the Keccak-256 hash of the RLP-encoded data from the transaction. Thereafter, keep track of the nonce in your application until each transaction confirms. Sadly, you have overlooked the fact that your account contains only 10 ether, so the network cant accept both transactions: one of them will fail. A transaction can create an inadvertent "gap" in the nonce sequence because it is invalid or has insufficient gas. A digital signature is a mathematical scheme that consists of two parts. In this chapter, we will dissect transactions, show how they work, and examine the details. At block #2,675,000 Ethereum implemented the "Spurious Dragon" hard fork, which, among other changes, introduced a new signing scheme that includes transaction replay protection (preventing transactions meant for one network being replayed on others). A digital signature is a mathematical scheme for presenting the authenticity of digital messages or documents. Each neighbor node validates the transaction as soon as they receive it. If we wait a few seconds to allow for network communications to settle down, the getTransactionCount call will return the expected number. This temporary key is used in the calculation of the r and s values to ensure that the senders actual private key cant be calculated by attackers watching signed transactions on the Ethereum network. Secondly, it guarantees non-repudiation: the proof of authorization is undeniable.
Ethereum is a global singleton state machine, and transactions are what make that state machine "tick," changing its state. For example, you may notice there is no from data in the address identifying the originator EOA. The Ethereum network uses a "flood routing" protocol. You fill the tank with as much gas as you think it will need for the journey (the computation needed to validate your transaction). Transactions can have both value and data, only value, only data, or neither value nor data. Therefore, transactions broadcast on one network cannot be replayed on another, hence the name of the standard. Why would you want to separate the signing and transmission of transactions?
In that case, the data will be interpreted by the EVM as a contract invocation. Append the ECDSA signatures computed v, r, and s values to the transaction. Because you sent the more important 6-ether one first, you understandably expect that one to go through and the 8-ether one to be rejected. Verification is the inverse of the signature generation function, using the r and s values and the senders public key to calculate a value Q, which is a point on the elliptic curve (the ephemeral public key used in signature creation). The wallet contract then sends the funds when prompted by an authorized EOA once the spending conditions have been satisfied. From the perspective of each node, it is not possible to discern the origin of the transaction. Maybe on the 100th call it gives out a special prize, like a lottery, but needs to do additional computation to calculate the prize. How do you track nonces? The contract needs to be compiled into a bytecode representation.
For example, in the sample transaction in [intro_chapter] your wallet set the gasPrice to 3 gwei (3 gigawei or 3 billion wei). A number of great guides online take you through it step by step: search for "ECDSA explained" or try this one: http://bit.ly/2r0HhGB. Sending a transaction to the wrong address will probably burn the ether sent, rendering it forever inaccessible (unspendable), since most addresses do not have a known private key and therefore no signature can be generated to spend it. During periods of low demand for space in a block, such transactions might very well get mined. Thats our "function selector" value, which will tell the contract which function we want to call. On average, each Ethereum node maintains connections to at least 13 other nodes, called its neighbors. Once you fill the gap, the network can mine the out-of-sequence transaction that it held in the mempool. We will examine all this in much more detail in [evm_chapter]. The amount of gas you would pay for that depends on how many other transactions have called that function before your transaction is included in a block. That doesnt mean you cannot send a data payload to an EOAthat is completely valid in the Ethereum protocol. Lets say you are writing your own wallet software or some other application that originates transactions. Therefore, EIP-155 makes it impossible for a transaction to be replayed on another chain, because the signatures validity depends on the chain identifier.