Update transaction malleability docs for RFCS #931
Conversation
mDuo13
commented
Nov 17, 2020
mDuo13
commented
- Update mentions of RequireFullyCanonicalSig to reflect that it's enabled now
- De-emphasizes tfFullyCanonicalSig now that it has no effect
- Rework the Transaction Malleability Exploit to reflect the multi-signing scenario, which is the only possible one now.
- Update mentions of RequireFullyCanonicalSig to reflect that it's enabled now - De-emphasizes tfFullyCanonicalSig now that it has no effect - Rework the Transaction Malleability Exploit to reflect the multi-signing scenario, which is the only possible one now.
| @@ -66,11 +66,11 @@ The only flag that applies globally to all transactions is as follows: | |||
|
|
|||
| | Flag Name | Hex Value | Decimal Value | Description | | |||
| |:----------------------|:-----------|:--------------|:--------------------------| | |||
| | `tfFullyCanonicalSig` | `0x80000000` | 2147483648 | _(Strongly recommended)_ Require a fully-canonical signature. | | |||
| | `tfFullyCanonicalSig` | `0x80000000` | 2147483648 | **DEPRECATED** No effect. Require a fully-canonical signature. | | |||
There was a problem hiding this comment.
@mDuo13 , should this be "requires"?
There was a problem hiding this comment.
No, it's an imperative. As in, "The instructions to the server are, if this flag is enabled: require a fully canonical signature for this transaction." (But now, no effect, because that's required regardless. I should probably reword to make that last part more clear.)
|
|
||
| 2. The system notes the identifying hash of the vulnerable transaction, submits it to the XRP Ledger network, then begins monitoring for that hash to be included in a validated ledger version. | ||
|
|
||
| 3. A malicious actor sees the transaction propagating through the network before it becomes confirmed. | ||
|
|
||
| 4. The malicious actor calculates the alternate signature for the vulnerable transaction. | ||
| 4. The malicious actor calculates removes an extra signature from the vulnerable transaction. |
There was a problem hiding this comment.
@mDuo13 , just curious why this bullet is "The x actor" and the one above is "A x actor".
There was a problem hiding this comment.
Step 3 is the first time a malicious actor is (definitely) part of the process, so it's "a" malicious actor. In step 4, I'm referring to the same malicious actor, so it's "the" malicious actor.
There was a problem hiding this comment.
Awkward phrasing: "calculates removes".
Makes more sense as "The malicious actor removes an extra signature..."
|
|
||
| 5. The malicious actor submits the modified (likely non-fully-canonical) transaction to the network. | ||
| 5. The malicious actor submits the modified transaction to the network. |
There was a problem hiding this comment.
@mDuo13 , another "The x actor".
There was a problem hiding this comment.
In this case, too, same malicious actor, thus, "the"
