From 899d622badaeff77591134fe153765c10308edee Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Mon, 12 Nov 2018 12:22:49 -0800 Subject: [PATCH] Edited 06transactions.asciidoc with Atlas code editor --- 06transactions.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/06transactions.asciidoc b/06transactions.asciidoc index 48bcfe2ce..102db1f4d 100644 --- a/06transactions.asciidoc +++ b/06transactions.asciidoc @@ -132,7 +132,7 @@ Parity has a web console for accessing the JSON RPC interface, but here we are u [[gaps_nonce]] ==== Gaps in Nonces, Duplicate Nonces, and Confirmation -((("nonces","gaps in sequence of")))It is important to keep track of nonces if you are creating transactions programmatically, especially if you are doing so from multiple independent processes simultaneously. +((("nonces","gaps in sequence of")))It is important to keep track of nonces if you are creating transactions programmatically, especially if you are doing so from multiple independent processes pass:[simultaneously]. The Ethereum network processes transactions sequentially, based on the nonce. 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. It will be stored in the mempool, while the Ethereum network waits for the missing nonce to appear. All nodes will assume that the missing nonce has simply been delayed and that the transaction with nonce 2 was received out of sequence. @@ -780,7 +780,7 @@ A transaction that has completed its journey from creation through signing by an ((("multiple-signature (multisig) transactions")))((("transactions","multiple-signature")))If you are familiar with Bitcoin's 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). Ethereum's basic EOA value transactions have no provisions for multiple signatures; however, arbitrary signing restrictions can be enforced by smart contracts with any conditions you can think of, to handle the transfer of ether and tokens alike. -To take advantage of this capability, ether has to be transferred to a "wallet contract" that is programmed with the spending rules desired, such as multisignature requirements or spending limits (or combinations of the two). The wallet contract then sends the funds when prompted by an authorized EOA once the spending conditions have been satisfied. For example, to protect your ether under a multisig condition, transfer the ether to a multisig contract. Whenever you want to send funds to another account, all the required users will need to send transactions to the contract using a regular wallet app, effectively authorizing the contract to perform the final transaction. +To take advantage of this capability, ether has to be transferred to a "wallet contract" that is programmed with the spending rules desired, such as multisignature requirements or spending limits (or combinations of the two). The wallet contract then sends the funds when prompted by an authorized EOA once the spending conditions have been satisfied. For example, to protect your ether under a multisig condition, transfer the ether to a multisig contract. Whenever you want to send funds to another account, all the required users will need to send transactions to the contract using a regular wallet app, effectively authorizing the contract to perform the final pass:[transaction]. These contracts can also be designed to require multiple signatures before executing local code or to trigger other contracts. The security of the scheme is ultimately determined by the multisig contract code.