Added Bump Sequence documentation

MonsieurNicolas · MonsieurNicolas · commit 736821097a98 · 2018-07-05T14:45:23.000-07:00
diff --git a/guides/concepts/list-of-operations.md b/guides/concepts/list-of-operations.md
@@ -17,7 +17,7 @@ For the protocol specification, see [stellar-transactions.x](https://github.com/
 - [Account Merge](#account-merge)
 - [Inflation](#inflation)
 - [Manage Data](#manage-data)
-
+- [Bump Sequence](#bump-sequence)
 
 ## Create Account
 [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.createAccount) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/CreateAccountOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/build#CreateAccountBuilder)
@@ -313,6 +313,7 @@ Possible errors:
 |ACCOUNT_MERGE_NO_ACCOUNT| -2| The `destination` account does not exist.|
 |ACCOUNT_MERGE_IMMUTABLE_SET| -3| The source account has `AUTH_IMMUTABLE` flag set.|
 |ACCOUNT_MERGE_HAS_SUB_ENTRIES | -4| The source account has trust lines/offers.|
+|ACCOUNT_MERGE_SEQNUM_TOO_FAR | -5| Source's account sequence number is too high. It must be less than `(ledgerSeq << 32) = (ledgerSeq * 0x100000000)`. *(protocol version 10 and above)*|
 
 ## Inflation
 [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.inflation) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/InflationOperation.html) | [Go](https://godoc.org/github.com/stellar/go/build#InflationBuilder)
@@ -355,3 +356,26 @@ Possible errors:
 |MANAGE_DATA_LOW_RESERVE| -3| Not enough lumens in the account to create a new Data Entry. Each additional Data Entry increases the minimum balance of the Account.|
 |MANAGE_DATA_INVALID_NAME| -4| Name not a valid string.|
 
+## Bump Sequence
+[JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.bumpSequence) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/BumpSequenceOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/build#BumpSequenceBuilder)
+
+*Only available in protocol version 10 and above*
+
+Bump sequence allows to bump forward the sequence number of the source account of the operation, allowing to invalidate any transactions with a smaller sequence number.
+
+If the specified `bumpTo` sequence number is greater than the source account's sequence number,
+the account's sequence number is updated with that value, otherwise it's not modified.
+
+Threshold: Low
+
+Result: `BumpSequenceResult`
+
+|Parameters| Type| Description|
+| --- | --- | --- |
+|bumpTo| SequenceNumber| desired value for the operation's source account sequence number.|
+
+Possible errors:
+
+| Error | Code | Description |
+| ----- | ---- | ------|
+|BUMP_SEQUENCE_BAD_SEQ| -1| The specified `bumpTo` sequence number is not a valid sequence number. It must be between 0 and `INT64_MAX` (9223372036854775807 or 0x7fffffffffffffff).|
diff --git a/guides/concepts/multi-sig.md b/guides/concepts/multi-sig.md
@@ -25,10 +25,12 @@ Once the signature threshold is met if there are any leftover signatures then th
 Each account can set its own threshold values. By default all thresholds levels are set to 0, and the master key is set to weight 1. The [Set Options](./list-of-operations.md#set-options) operation allows you to change the weight of the master key and to add other signing keys with different weights.
 
 Low Security:
- * [Transaction processing](./transactions.md)
+  * [Transaction processing](./transactions.md)
     * Charging a fee or updating the sequence number for the source account
- * [Allow Trust](./list-of-operations.md#allow-trust) operation
-   * Used to allow people to hold credit from this account without exposing the key that enables sending payments from this account.
+  * [Allow Trust](./list-of-operations.md#allow-trust) operation
+    * Used to allow people to hold credit from this account without exposing the key that enables sending payments from this account.
+  * [Bump Sequence](./list-of-operations.md#bump-sequence)
+    * Modify the account's sequence number directly
 
 Medium Security:
  * All [other operations](./list-of-operations.md)
diff --git a/guides/concepts/operations.md b/guides/concepts/operations.md
@@ -17,6 +17,7 @@ Here are the possible operation types:
 - [Account Merge](./list-of-operations.md#account-merge)
 - [Inflation](./list-of-operations.md#inflation)
 - [Manage Data](./list-of-operations.md#manage-data)
+- [Bump Sequence](./list-of-operations.md#bump-sequence)
 
 Operations are executed on behalf of the source account specified in the
 transaction, unless there is an override defined for the operation.
@@ -28,13 +29,16 @@ Thresholds define the level of privilege an operation needs in order to succeed.
 
 * Low Security:
   * AllowTrustTx
-  * Used to allow other signers to allow people to hold credit from this
-   account but not issue credit.
+    * Used to allow other signers to allow people to hold credit from this account but not issue credit.
+  * BumpSequence
 * Medium Security:
   * All else
 * High Security:
+  * AccountMerge
+    * merge an account into another one
   * SetOptions for Signer and threshold
-  * Used to change the Set of signers and the thresholds.
+    * Used to change the Set of signers and the thresholds.
+
 
 ## Validity of an operation
 
@@ -44,7 +48,7 @@ The validity check only looks at the state of the source account. It ensures tha
 1) the outer transaction has enough signatures for the source account of the operation to meet the threshold for that operation.
 2) Operations-specific validity checks pass. These checks are ones that would stay true regardless of the ledger state—for example, are the parameters within the expected bounds? Checks that depend on ledger state don't happen until apply time—for example, a send operation won't check if you have enough balance to send until apply time.
 
-Once a transaction passes this first validity check, it is propagated to the network and eventually included in a transaction set. As part of a transaction set, the transaction is applied to the ledger. At that point a fee is taken from the source account. Operations are attempted in the order they occur in the transaction. If any operation fails, the whole transaction fails and the effects of previous operations are rolled back.
+Once a transaction passes this first validity check, it is propagated to the network and eventually included in a transaction set. As part of a transaction set, the transaction is applied to the ledger. At that point a fee is taken from the source account regardless of success/failure. Later, the transaction is processed: sequence number and signatures are verified before operations are attempted in the order they occur in the transaction. If any operation fails, the whole transaction fails and the effects of previous operations are rolled back.
 
 
 ## Result
