ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 19:55:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #404 from mDuo13/flag-ranges

Browse Source 
Clarify flag ranges
This commit is contained in:
Rome Reginelli
2018-05-23 16:09:41 -07:00
committed by GitHub
parent 89d340bd44 616ee9c2e6
commit f7d1d56d57
1 changed files with 18 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
content/references/rippled-api/transaction-formats/transaction-common-fields.md
View File

@@ -52,8 +52,14 @@ The [`Paths` field](payment.html#paths) of the [Payment transaction][] type can
The `Flags` field can contain various options that affect how a transaction should behave. The options are represented as binary values that can be combined with bitwise-or operations to set multiple flags at once.
To check whether a transaction has a given flag enabled, use the bitwise-and operator on the flag's value and the `Flags` field. A result of zero indicates the flag is disabled, and a result equal to the flag value indicates the flag is enabled. (Any other result indicates you performed the wrong operation.)
Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the `TransactionType` field when setting and reading flags.
Bits that are not defined as flags MUST be 0. (The [fix1543 amendment](known-amendments.html#fix1543) enforces this rule on some transaction types. Most transaction types enforce this rule by default.)
### Global Flags
The only flag that applies globally to all transactions is as follows:
| Flag Name | Hex Value | Decimal Value | Description |
@@ -64,6 +70,18 @@ When using the [sign method][] (or [submit method][] in "sign-and-submit" mode),
**Warning:** If you do not enable `tfFullyCanonicalSig`, it is theoretically possible for a malicious actor to modify your transaction signature so that the transaction may succeed with a different hash than expected. In the worst case, this could trick your integration into submitting the same payment multiple times. To avoid this problem, enable the `tfFullyCanonicalSig` flag on all transactions you sign.
### Flag Ranges
A transaction's `Flags` field can contain flags that apply at different levels or contexts. Flags for each context are limited to the following ranges:
| Range Name | Bit Mask | Description |
|:-----------------|:-------------|:-------------------------------------------|
| Universal Flags | `0xff000000` | Flags that apply equally to all transaction types. |
| Type-based Flags | `0x00ff0000` | Flags with different meanings depending on the [transaction type](transaction-types.html) that uses them. |
| Reserved Flags | `0x0000ffff` | Flags that are not currently defined. A transaction is only valid if these flags are disabled. |
**Note:** The [AccountSet transaction][] type has [its own non-bitwise flags](accountset.html#accountset-flags), which serve a similar purpose to type-based flags. [Ledger objects](ledger-object-types.html) also have a `Flags` field with different bitwise flag definitions.
## Memos Field