mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-06 17:27:57 +00:00
Move/rename indexes and some other files
This makes no difference to how the site is built under Dactyl (other than where the "Edit Page" links go) but changes the URLs that will be used for the pages after the migration to Redocly. In addition to renaming index pages to index.md, I updated the style guide to reflect the updated conventions, and moved a couple files that were not in the correct folders for their place in the nav hierarchy.
This commit is contained in:
mDuo13
@@ -1,86 +0,0 @@
|
||||
---
|
||||
html: multi-signing.html
|
||||
parent: accounts.html
|
||||
blurb: Use multi-signing for greater security sending transactions.
|
||||
labels:
|
||||
- Smart Contracts
|
||||
- Security
|
||||
---
|
||||
# Multi-Signing
|
||||
|
||||
Multi-signing in the XRP Ledger is a method of [authorizing transactions](transactions.html#authorizing-transactions) for the XRP Ledger by using a combination of multiple secret keys. You can have any combination of authorization methods enabled for your address, including multi-signing, a [master key pair](cryptographic-keys.html#master-key-pair), and a [regular key pair](cryptographic-keys.html#regular-key-pair). (The only requirement is that _at least one_ method must be enabled.)
|
||||
|
||||
Benefits of multi-signing include:
|
||||
|
||||
- You can require keys from different devices, so that a malicious actor must compromise multiple machines to send transactions on your behalf.
|
||||
- You can share custody of an address between multiple people, each of whom only has one of several keys necessary to send transactions from that address.
|
||||
- You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally.
|
||||
|
||||
## Signer Lists
|
||||
|
||||
Before you can multi-sign, you must create a list of which addresses can sign for you.
|
||||
|
||||
The [SignerListSet transaction][] defines a _signer list_, a set of addresses that can authorize transactions from your address. You can include 1 to 32 addresses in a signer list. The list cannot include your address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the _Signer Weight_ and _Quorum_ settings in the list.
|
||||
|
||||
_(Updated by the [ExpandedSignerList amendment][].)_
|
||||
|
||||
### Signer Weight
|
||||
|
||||
You assign a weight to each signer in the list. The weight represents the authority of the signer relative to other signers on the list. The higher the value, the more authority. Individual weight values cannot exceed 2<sup>16</sup>-1.
|
||||
|
||||
### Quorum
|
||||
|
||||
The quorum value of a list is the minimum weight total required to authorize a transaction. The quorum must be greater than 0 but less than or equal to the sum of the weight values in the signer list: meaning, it must be possible to achieve a quorum with the given signer weights.
|
||||
|
||||
### Wallet Locator
|
||||
<!-- STYLE_OVERRIDE: wallet -->
|
||||
|
||||
You can also add up to 256 bits of arbitrary data to each signer's entry in the list. This data is not required or used by the network, but can be used by smart contracts or other applications to identify or confirm other data about the signers.
|
||||
|
||||
_(Added by the [ExpandedSignerList amendment][].)_
|
||||
|
||||
|
||||
### Examples Using Signer Weight and Quorum
|
||||
|
||||
The weights and quorum allow you to set an appropriate level of oversight for each transaction, based on the relative trust and authority relegated to responsible participants who manage the account.
|
||||
|
||||
For a shared account use case, you might create a list with a quorum of 1, then give all participants a weight of 1. A single approval from any one of them is all that is required to approve a transaction.
|
||||
|
||||
For a very important account, you might set the quorum to 3, with 3 participants that have a weight of 1. All of the participants must agree and approve each transaction.
|
||||
|
||||
Another account might also have a quorum of 3. You assign your CEO a weight of 3, 3 Vice Presidents a weight of 2 each, and 3 Directors a weight of 1 each. To approve a transaction for this account requires the approval of all 3 Directors (total weight of 3), 1 Vice President and 1 Director (total weight of 3), 2 Vice Presidents (total weight of 4), or the CEO (total weight of 3). <!-- STYLE_OVERRIDE: vice -->
|
||||
|
||||
In each of the previous three use cases, you would disable the master key without configuring a regular key, so that multi-signing is the only way of [authorizing transactions](transactions.html#authorizing-transactions).
|
||||
|
||||
There might be a scenario where you create a multi-signing list as a "backup plan." The account owner normally uses a regular key for their transactions (not a multi-signing key). For safety, the owner adds a signer list containing 3 friends, each with a weight of 1, and a quorum of 3. If the account owner were to lose the private key, they can ask their friends to multi-sign a transaction to replace the regular key.
|
||||
|
||||
|
||||
## Sending Multi-Signed Transactions
|
||||
|
||||
To successfully submit a multi-signed transaction, you must do all of the following:
|
||||
|
||||
* The address sending the transaction (specified in the `Account` field) must have a [`SignerList` object in the ledger](signerlist.html). For instructions on how to do this, see [Set Up Multi-Signing](set-up-multi-signing.html).
|
||||
* The transaction must include the `SigningPubKey` field as an empty string.
|
||||
* The transaction must include a [`Signers` field](transaction-common-fields.html#signers-field) containing an array of signatures.
|
||||
* The signatures present in the `Signers` array must match signers defined in the `SignerList`.
|
||||
* For the provided signatures, the total weight associated with those signers must be equal or greater than the quorum for the `SignerList`.
|
||||
* The [transaction cost](transaction-cost.html) (specified in the `Fee` field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided.
|
||||
* All fields of the transaction must be defined before collecting signatures. You cannot [auto-fill](transaction-common-fields.html#auto-fillable-fields) any fields.
|
||||
* If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the [submit_multisigned method][] handles this automatically.)
|
||||
|
||||
## See Also
|
||||
|
||||
- **Tutorials:**
|
||||
- [Set Up Multi-Signing](set-up-multi-signing.html)
|
||||
- [Send a Multi-Signed Transaction](send-a-multi-signed-transaction.html)
|
||||
- **Concepts:**
|
||||
- [Cryptographic Keys](cryptographic-keys.html)
|
||||
- [Special Transaction Cost for Multi-signed transactions](transaction-cost.html#special-transaction-costs)
|
||||
- **References:**
|
||||
- [SignerListSet transaction][]
|
||||
- [SignerList object](signerlist.html)
|
||||
- [sign_for method][]
|
||||
- [submit_multisigned method][]
|
||||
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
html: tickets.html
|
||||
parent: accounts.html
|
||||
blurb: Send transactions in non-sequential order.
|
||||
labels:
|
||||
- Accounts
|
||||
- Transaction Sending
|
||||
---
|
||||
# Tickets
|
||||
|
||||
_(Added by the [TicketBatch amendment][].)_
|
||||
|
||||
A Ticket in the XRP Ledger is a way of setting aside a [sequence number][Sequence Number] for a transaction without sending it right away. Tickets allow transactions to be sent outside of the normal sequence order. One use case for this is to allow for [multi-signed transactions](multi-signing.html) where it may take a while to collect the necessary signatures: while collecting signatures for a transaction that uses a Ticket, you can still send other transactions.
|
||||
|
||||
## Background
|
||||
|
||||
[Transactions](transactions.html) have sequence numbers so that any given transaction can execute no more than once. Sequence numbers also make sure any given transaction is unique: if you send the exact same amount of money to the same person multiple times, the Sequence Number is one detail that is guaranteed to be different each time. Finally, Sequence Numbers provide an elegant way to put transactions in a consistent order, even if some of them arrive out of order when sent throughout the network.
|
||||
|
||||
However, there are some situations where sequence numbers are too limiting. For example:
|
||||
|
||||
- Two or more users share access to an account, each with the ability to send transactions independently. If these users try to send transactions around the same time without coordinating first, they may each try to use the same Sequence number for different transactions, and only one can succeed.
|
||||
- You may want to prepare and sign a transaction in advance, then save it in some secure storage so that it can be executed at any future point if certain events occur. However, if you want to continue using your account as normal in the meantime, you don't know what Sequence number the set-aside transaction will need. <!-- STYLE_OVERRIDE: will -->
|
||||
- When [multiple people must sign a transaction](multi-signing.html) to make it valid, it can be difficult to plan more than one transaction at a time. If you number the transactions with separate sequence numbers, you can't send the later-numbered transactions until everyone has signed the previous transactions; but if you use the same sequence number for each pending transactions, only one of them can succeed.
|
||||
|
||||
Tickets provide a solution to all of these problems by setting aside sequence numbers that can be used later, outside of their usual order, but still no more than once each.
|
||||
|
||||
|
||||
## Tickets Are Reserved Sequence Numbers
|
||||
|
||||
A Ticket is a record that a sequence number has been set aside to be used later. An account first sends a [TicketCreate transaction][] to set aside one or more sequence numbers as Tickets; this puts a record in the [ledger's state data](ledgers.html), in the form of a [Ticket object][], for each sequence number reserved.
|
||||
|
||||
Tickets are numbered using the sequence numbers that were set aside to create them. For example, if your account's current sequence number is 101 and you create 3 Tickets, those Tickets have Ticket Sequence numbers 102, 103, and 104. Doing so increases your account's sequence number to 105.
|
||||
|
||||
{{ include_svg("img/ticket-creation.svg", "Diagram: Creating three Tickets") }}
|
||||
|
||||
Later, you can send a transaction using a specific Ticket instead of a sequence number; doing so removes the corresponding Ticket from the ledger's state data and does not change your account's normal sequence number. You can also still send transactions using normal sequence numbers without using Tickets. You can use any of your available Tickets in any order at any time, but each Ticket can only be used once.
|
||||
|
||||
{{ include_svg("img/ticket-usage.svg", "Diagram: Using Ticket 103.") }}
|
||||
|
||||
Continuing the above example, you can send a transaction using sequence number 105 or any of the three Tickets you created. If you send a transaction using Ticket 103, doing so deletes Ticket 103 from the ledger. Your next transaction after that can use sequence number 105, Ticket 102, or Ticket 104.
|
||||
|
||||
**Caution:** Each Ticket counts as a separate item for the [owner reserve](reserves.html), so you must set aside 2 XRP for each Ticket. (The XRP becomes available again after you use the Ticket.) This cost can add up quickly if you create a large number of Tickets at once.
|
||||
|
||||
As with sequence numbers, sending a transaction uses up the Ticket _if and only if_ the transaction is confirmed by [consensus](consensus.html). However, transactions that fail to do what they were intended to do can still be confirmed by consensus with [`tec`-class result codes](tec-codes.html).
|
||||
|
||||
To look up what Tickets an account has available, use the [account_objects method][].
|
||||
|
||||
## Limitations
|
||||
|
||||
Any account can create and use Tickets on any type of transaction. However, some restrictions apply:
|
||||
|
||||
- Each Ticket can only be used once. It is possible to have multiple different candidate transactions that would use the same Ticket Sequence, but only one of those candidates can be validated by consensus.
|
||||
- Each account cannot have more than 250 Tickets in the ledger at a time. You cannot create more than 250 Tickets at a time, either.
|
||||
- You _can_ use a Ticket to create more Tickets. If you do, the Ticket you used does not count towards the total number of Tickets you can have at once.
|
||||
- Each Ticket counts toward the [owner reserve](reserves.html), so you must set aside 2 XRP for each Ticket you have not used yet. The XRP becomes available for you to use again after the Ticket is used.
|
||||
- Within an individual ledger, transactions that use Tickets execute after other transactions from the same sender. If an account has multiple transactions using Tickets in the same ledger version, those Tickets execute in order from lowest Ticket Sequence to highest. (For more information, see the documentation on consensus's [canonical order](consensus-structure.html#calculate-and-share-validations).)
|
||||
- To "cancel" a Ticket, use the Ticket to [perform a no-op](canceling-a-transaction.html) [AccountSet transaction][]. This deletes the Ticket so that you don't have to meet its reserve requirement.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
- **Concepts:**
|
||||
- [Multi-Signing](multi-signing.html)
|
||||
- **Tutorials:**
|
||||
- [Use Tickets](use-tickets.html)
|
||||
- **References:**
|
||||
- [TicketCreate transaction][]
|
||||
- [Transaction Common Fields](transaction-common-fields.html)
|
||||
- [Ticket object](ticket.html)
|
||||
- [account_objects method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user