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

Merge pull request #800 from mDuo13/ka_150

Browse Source 
new amendments in v1.5.0
This commit is contained in:
Rome Reginelli
2020-03-27 14:09:33 -07:00
committed by GitHub
parent 3bac6ecc2c 508e34a0e5
commit be57cf1ec8
4 changed files with 43 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
content/_snippets/rippled-api-links.md
View File

@@ -137,6 +137,7 @@
"Checks",
"CryptoConditions",
"CryptoConditionsSuite",
"DeletableAccounts",
"DepositAuth",
"DepositPreauth",
"EnforceInvariants",
@@ -154,7 +155,10 @@
"fix1571",
"fix1578",
"fix1623",
"fixCheckThreading",
"fixMasterKeyAsRegularKey",
"fixPayChanRecipientOwnerDir",
"fixQualityUpperBound",
"fixTakerDryOfferRemoval",
"Flow",
"FlowCross",
@@ -163,6 +167,7 @@
"MultiSignReserve",
"OwnerPaysFee",
"PayChan",
"RequireFullyCanonicalSig",
"SHAMapV2",
"SortedDirectories",
"SusPay",

38
content/concepts/consensus-network/amendments/known-amendments.md
View File

@@ -7,11 +7,12 @@ The following is a comprehensive list of all known amendments and their status o
|:--------------------------------|:-----------|:------------------------------------|
| [CryptoConditionsSuite][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [SHAMapV2][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [Tickets][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fixQualityUpperBound][] | v1.5.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [RequireFullyCanonicalSig][] | v1.5.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [DeletableAccounts][] | v1.4.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [fixCheckThreading][] | v1.4.0 | [Expected: 2020-01-18](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html "BADGE_BLUE") |
| [fixPayChanRecipientOwnerDir][] | v1.4.0 | [Expected: 2020-01-18](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html "BADGE_BLUE") |
| [fixCheckThreading][] | v1.4.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [fixPayChanRecipientOwnerDir][] | v1.4.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [Checks][] | v0.90.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [FlowCross][] | v0.70.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [fixMasterKeyAsRegularKey][] | v1.3.1 | [Enabled: 2019-10-02](https://xrpcharts.ripple.com/#/transactions/61096F8B5AFDD8F5BAF7FC7221BA4D1849C4E21B1BA79733E44B12FC8DA6EA20 "BADGE_GREEN") |
@@ -41,6 +42,7 @@ The following is a comprehensive list of all known amendments and their status o
| [TrustSetAuth][] | v0.30.0 | [Enabled: 2016-07-19](https://xrpcharts.ripple.com/#/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") |
| [MultiSign][] | v0.31.0 | [Enabled: 2016-06-27](https://xrpcharts.ripple.com/#/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") |
| [FeeEscalation][] | v0.31.0 | [Enabled: 2016-05-19](https://xrpcharts.ripple.com/#/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") |
| [SHAMapV2][] | v0.32.1 | [Vetoed: Removed in v1.4.0](https://xrpl.org/blog/2019/rippled-1.4.0.html "BADGE_RED") |
| [FlowV2][] | v0.32.1 | [Vetoed: Removed in v0.33.0](https://xrpl.org/blog/2016/flowv2-vetoed.html "BADGE_RED") |
| [SusPay][] | v0.31.0 | [Vetoed: Removed in v0.60.0](https://xrpl.org/blog/2017/ticksize-voting.html#upcoming-features "BADGE_RED") |
@@ -372,7 +374,19 @@ With this amendment enabled, a SetRegularKey transaction cannot set the regular
Changes the [PaymentChannelCreate transaction][] type so that it adds new [payment channels](payment-channels.html) to the recipient's [owner directory](directorynode.html). Without this amendment, new payment channels are added only to the sender's owner directory; with this amendment enabled, newly-created payment channels are added to both owner directories. Existing payment channels are unchanged.
This change makes it easier to look up payment channels by their recipient and prevents accounts from being deleted if they are the recipient for open payment channels (except those channels created before this amendment).
This change prevents accounts from being deleted if they are the recipient for open payment channels, except for channels created before this amendment.
## fixQualityUpperBound
[fixQualityUpperBound]: #fixqualityupperbound
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953 | Planned |
Fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments.
This amendment has no known impact on transaction processing.
## fixTakerDryOfferRemoval
@@ -491,6 +505,22 @@ Creates three new transaction types: [PaymentChannelCreate][], [PaymentChannelCl
For more information, see the [Payment Channels Tutorial](use-payment-channels.html).
## RequireFullyCanonicalSig
[RequireFullyCanonicalSig]: #requirefullycanonicalsig
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC | Planned |
Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](transaction-malleability.html) on _all_ transactions, instead of just transactions with the [tfFullyCanonicalSig flag](transaction-common-fields.html#global-flags) enabled.
Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions.
With this amendment, no single-signed transactions are malleable. ([Multi-signed transactions may still be malleable](transaction-malleability.html#malleability-with-multi-signatures) if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014.
For more information, see [`rippled` issue #3042](https://github.com/ripple/rippled/issues/3042).
## SHAMapV2
[SHAMapV2]: #shamapv2

4
content/concepts/consensus-network/transaction-malleability.md
View File

@@ -10,6 +10,8 @@ There are two circumstances that could lead to transaction malleability:
**Use the [tfFullyCanonicalSig flag](transaction-common-fields.html#global-flags)** to guarantee that a transaction is not malleable in this way. Although transactions [signed with Ed25519 keys](cryptographic-keys.html#signing-algorithms) are not vulnerable to this problem, **there is no downside** to using this flag on _all_ transactions.
If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions are protected against malleability regardless of the tfFullyCanonicalSig flag.
2. The transaction is [multi-signed](multi-signing.html) and has more signatures than necessary. Even if the transaction originally did not have more signatures than necessary, it could be malleable if an authorized signer provides an additional signature.
Good operational security can protect against these problems. See [Mitigations for Multi-Signature Malleability](#mitigations-for-multi-signature-malleability) for guidelines.
@@ -41,7 +43,7 @@ An ECDSA signature consists of two integers, called R and S. The secp256k1 _grou
Thus, to have _fully_ canonical signatures, one must choose which of the two possibilities is preferred and declare the other to be invalid. The creators of the XRP Ledger decided arbitrarily to prefer the _smaller_ of the two possible values, `S` or `N-S`. A transaction is considered _fully canonical_ if it uses the preferred (smaller) value of `S`, and follows all the normal rules for being canonical.
To maintain compatibility with older software that did not always generate fully canonical signatures, the XRP Ledger accepts transactions that are not fully canonical. To protect new users from exploits, the XRP Ledger has a flag on transactions called [**tfFullyCanonicalSig**](transaction-common-fields.html#global-flags), which requires that the transaction use a _fully-canonical_ signature to be valid.
To maintain compatibility with older software that did not always generate fully canonical signatures, the XRP Ledger accepts transactions that are not fully canonical. To protect new users from exploits, the XRP Ledger has a flag on transactions called [**tfFullyCanonicalSig**](transaction-common-fields.html#global-flags), which requires that the transaction use a _fully-canonical_ signature to be valid. If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions require fully-canonical signatures regardless of the tfFullyCanonicalSig flag, and legacy software that makes non-fully-canonical signatures is no longer compatible.
To calculate a fully-canonical ECDSA signature, one must compare S and N-S to determine which is smaller, then use that value in the `Signature` field of the transaction.

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

@@ -72,7 +72,7 @@ The only flag that applies globally to all transactions is as follows:
When using the [sign method][] (or [submit method][] in "sign-and-submit" mode), `rippled` adds a `Flags` field with `tfFullyCanonicalSig` enabled unless the `Flags` field is already present. The `tfFullyCanonicalSig` flag ***is not*** automatically enabled if `Flags` is explicitly specified. The flag ***is not*** automatically enabled when using the [sign_for method][] to add a signature to a multi-signed transaction.
**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.
**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](transaction-malleability.html#exploit-with-malleable-transactions). To avoid this problem, enable the `tfFullyCanonicalSig` flag on all transactions you sign. If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all single-signed transactions are protected regardless of the tfFullyCanonicalSig flag.
### Flag Ranges