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

reliable tx - fix nested lists

Browse Source
This commit is contained in:
mDuo13
2016-10-14 15:43:09 -07:00
parent cc582731f8
commit ca16e81cff
2 changed files with 22 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
content/tutorial-reliable-transaction-submission.md
View File

@@ -32,13 +32,13 @@ Ripple provides several APIs for submitting transactions, including [`rippled`](
1. An account owner creates and signs a transaction.
2. The owner submits the transaction to the network as a candidate transaction.
- Malformed or nonsensical transactions are rejected immediately.
- Well-formed transactions may provisionally succeed, then later fail.
- Well-formed transactions may provisionally fail, then later succeed.
- Well-formed transactions may provisionally succeed, and then later succeed in a slightly different way. (For example, by consuming a different offer and achieving a better or worse exchange rate than the provisional execution.)
- Malformed or nonsensical transactions are rejected immediately.
- Well-formed transactions may provisionally succeed, then later fail.
- Well-formed transactions may provisionally fail, then later succeed.
- Well-formed transactions may provisionally succeed, and then later succeed in a slightly different way. (For example, by consuming a different offer and achieving a better or worse exchange rate than the provisional execution.)
3. Through consensus and validation, the transaction is applied to the ledger. Even some failed transactions are applied, to enforce a cost for being propagated through the network.
4. The validated ledger includes the transaction, and its effects are reflected in the ledger state.
- Transaction results are no longer provisional, success or failure is now final and immutable.
- Transaction results are no longer provisional, success or failure is now final and immutable.
**Note:** When submitting a transaction via `rippled`, a successful status code returned from a submit command indicates the `rippled` server has received the candidate transaction. The transaction may or may not be applied to a validated ledger.
@@ -82,12 +82,12 @@ Submission and verification are two separate procedures which may be implemented
The submission process:
1. Construct and sign the transaction
- Include `LastLedgerSequence` parameter
- Include `LastLedgerSequence` parameter
2. Persist the transaction details, saving:
- Transaction hash
- `LastLedgerSequence`
- Sender address and sequence number
- Application-specific data, as needed
- Transaction hash
- `LastLedgerSequence`
- Sender address and sequence number
- Application-specific data, as needed
3. Submit the transaction