CAP-0021 updates

core/cap-0021.md

@@ -67,7 +67,8 @@ in two situations:
 2. `BumpSequenceOp` operation: For the `sourceAccount` of every
 successfully executed `BumpSequenceOp` operation, regardless of whether
 the `BumpSequenceOp` actually increased or modified the sequence number
-of the account.
+of the account. This allows an account to update it's `seqLedger`
+or `seqTime` without using an additional sequence number.
 
 If an account does not have an `AccountEntryExtensionV3` because it
 hasn't been upgraded yet, then it behaves as if `seqLedger` and
@@ -190,9 +191,7 @@ union Preconditions switch (PreconditionType type) {
 };
 ```
 
-Note we add a signed `Duration` type.  `Duration` and the existing
-(unsigned) `TimePoint` type should also be adopted by
-`ClaimPredicate`.
+Note we add an unsigned `Duration` type, used by `minSeqAge`.
 
 We make use of the new `Preconditions` type by replacing `timeBounds`
 in the `Transaction` structure as follows:
@@ -242,7 +241,9 @@ and no preconditions is valid (and should be forwarded) only if there
 is also a pending valid transaction with sequence number 11.  The
 `minSeqNum` field in this proposal relaxes validity to allow a valid
 series of transactions on the same `sourceAccount` with discontinuous
-`seqNum` fields.  Regardless of these gaps, all transactions on the
+`seqNum` fields. The gaps, however, cannot be filled in (if the queue
+already had `seqNum` 10 and 12 with a valid gap, 11 should not be
+accepted and forwarded). Regardless of these gaps, all transactions on the
 same `sourceAccount` in the same block must be executed in order of
 increasing `seqNum`.  Hence, the presence of the `minSeqNum` field may
 make transactions valid that would not otherwise be valid, but cannot
@@ -297,29 +298,33 @@ fail the second validation, for instance if a `BUMP_SEQUENCE`
 operation made the sequence number invalid.  Whenever a transaction
 fails validation during execution, the `sourceAccount` loses the fee.
 
-Because `PreconditionsV2` specifies multiple pre-conditions, there may
-be multiple reasons why a transaction is invalid.  If any of the
-reasons is permanent---namely the `maxTime` or `maxLedger` has been
-exceeded--then the transaction is rejected with
-`TransactionResultCode` `txTOO_LATE`.  Otherwise, if all the
-unsatisfied preconditions are based on values that could later be
-valid, then the transaction is rejected with `txTOO_EARLY`.  If
-neither of the above conditions holds (`txTOO_EARLY` and `txTOO_LATE`
-do not apply), but one of the `extraSigners` is unsatisfied, then the
-transaction fails with `txBAD_AUTH`.
+Because `PreconditionsV2` specifies multiple pre-conditions, there may be
+multiple reasons why a transaction is invalid. If `extraSigners` contains
+duplicate signers, the transaction is rejected with `txMALFORMED` (Note that
+signer overlap between `extraSigners` and `AccountEntry` signers is allowed). If
+the `maxTime` or `maxLedger` has been exceeded--then the transaction is rejected
+with `TransactionResultCode` `txTOO_LATE`. If `minTime` or `minLedger` have not
+been reached yet, then the transaction is rejected with `txTOO_EARLY`. If
+`minSeqNum` is set, but the relaxed sequence number validation still fails, then
+the transaction is rejected with `txBAD_SEQ`. If the failure is due to
+`minSeqAge` or `minSeqLedgerGap`, then the transaction is rejected with the new
+`txBAD_MIN_SEQ_AGE_OR_GAP` error code. If none of the above conditions holds
+(`txTOO_EARLY`, `txBAD_MIN_SEQ_AGE_OR_GAP`, `txMALFORMED`, `txBAD_SEQ`, and
+`txTOO_LATE` do not apply), but one of the `extraSigners` is unsatisfied, then
+the transaction fails with `txBAD_AUTH`.
 
 ### XDR diff
 
 ```diff mddiffcheck.base=v17.3.0
 diff --git a/src/xdr/Stellar-ledger-entries.x b/src/xdr/Stellar-ledger-entries.x
-index 3895ce9a..9b9a61cf 100644
+index c870fe09..5c772f1c 100644
 --- a/src/xdr/Stellar-ledger-entries.x
 +++ b/src/xdr/Stellar-ledger-entries.x
 @@ -13,6 +13,7 @@ typedef string string32<32>;
  typedef string string64<64>;
  typedef int64 SequenceNumber;
  typedef uint64 TimePoint;
-+typedef int64 Duration;
++typedef uint64 Duration;
  typedef opaque DataValue<64>;
  typedef Hash PoolID; // SHA256(LiquidityPoolParameters)
 
@@ -352,25 +357,11 @@ index 3895ce9a..9b9a61cf 100644
      }
      ext;
  };
-@@ -354,10 +370,10 @@ case CLAIM_PREDICATE_OR:
- case CLAIM_PREDICATE_NOT:
-     ClaimPredicate* notPredicate;
- case CLAIM_PREDICATE_BEFORE_ABSOLUTE_TIME:
--    int64 absBefore; // Predicate will be true if closeTime < absBefore
-+    TimePoint absBefore; // Predicate will be true if closeTime < absBefore
- case CLAIM_PREDICATE_BEFORE_RELATIVE_TIME:
--    int64 relBefore; // Seconds since closeTime of the ledger in which the
--                     // ClaimableBalanceEntry was created
-+    Duration relBefore; // Seconds since closeTime of the ledger in which the
-+                        // ClaimableBalanceEntry was created
- };
-
- enum ClaimantType
 diff --git a/src/xdr/Stellar-transaction.x b/src/xdr/Stellar-transaction.x
-index d97b0cb3..f67a0c55 100644
+index 1a4e491a..811e4786 100644
 --- a/src/xdr/Stellar-transaction.x
 +++ b/src/xdr/Stellar-transaction.x
-@@ -532,6 +532,58 @@ struct TimeBounds
+@@ -576,6 +576,58 @@ struct TimeBounds
      TimePoint maxTime; // 0 here means no maxTime
  };
 
@@ -429,7 +420,7 @@ index d97b0cb3..f67a0c55 100644
  // maximum number of operations per transaction
  const MAX_OPS_PER_TX = 100;
 
-@@ -583,8 +635,8 @@ struct Transaction
+@@ -627,8 +679,8 @@ struct Transaction
      // sequence number to consume in the account
      SequenceNumber seqNum;
 
@@ -440,6 +431,26 @@ index d97b0cb3..f67a0c55 100644
 
      Memo memo;
 
+@@ -1508,7 +1560,9 @@ enum TransactionResultCode
+
+     txNOT_SUPPORTED = -12,         // transaction type not supported
+     txFEE_BUMP_INNER_FAILED = -13, // fee bump inner transaction failed
+-    txBAD_SPONSORSHIP = -14        // sponsorship not confirmed
++    txBAD_SPONSORSHIP = -14,        // sponsorship not confirmed
++    txBAD_MIN_SEQ_AGE_OR_GAP = -15, //minSeqAge or minSeqLedgerGap conditions not met
++    txMALFORMED = 16                // precondition is invalid
+ };
+
+ // InnerTransactionResult must be binary compatible with TransactionResult
+@@ -1537,6 +1591,8 @@ struct InnerTransactionResult
+     case txNOT_SUPPORTED:
+     // txFEE_BUMP_INNER_FAILED is not included
+     case txBAD_SPONSORSHIP:
++    case txBAD_MIN_SEQ_AGE_OR_GAP:
++    cast txMALFORMED:
+         void;
+     }
+     result;
 diff --git a/src/xdr/Stellar-types.x b/src/xdr/Stellar-types.x
 index 8f7d5c20..caa41d7f 100644
 --- a/src/xdr/Stellar-types.x

core/cap-0040.md

@@ -161,10 +161,17 @@ Ed25519 signed payload signer signatures are verified by performing ed25519
 signature verification using the signature, the payload from the signer, and the
 ed25519 public key from the signer.
 
+#### Transaction Validity
+
+If a payload signer is used in the `extraSigners` precondition specified in
+[CAP-21], and the payload is empty, the transaction will fail with `txMALFORMED`
+(also specified in [CAP-21]).
+
 #### SetOptionsOp
 
 `SetOptionsOp` will fail validation with `SET_OPTIONS_BAD_SIGNER` if the new
-signed payload signer is used prior to the protocol upgrade.
+signed payload signer is used prior to the protocol upgrade, or if the payload
+is empty.
 
 ## Design Rationale