Skip to content

Commit

Permalink
Add info transactions (#5531)
Browse files Browse the repository at this point in the history
* added text

* moved replay attack section

minor edits

* minor edit

* implemented Bill feedback

* link fix
  • Loading branch information
filippoweb3 authored Jan 24, 2024
1 parent 13ee04c commit 5207eb5
Show file tree
Hide file tree
Showing 2 changed files with 33 additions and 17 deletions.
20 changes: 20 additions & 0 deletions docs/general/transaction-attacks.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,26 @@ This will be showed in the Signer app and a careful user will notice it. If the
Signer is already incorrect (or the Signer is corrupted) there is the risk of signing a non-intended
transaction without the possibility of verifying it.

### Replay Attack

A replay attack is where past transactions can be replayed (same [balance](#balance-transfers),
receiver account, etc.) without knowing private keys. It is an attack where publicly known data can
be "replayed" as a new extrinsic. This could happen in the context of
[reaping accounts](../learn/learn-accounts.md#existential-deposit-and-reaping) because the reaping
process resets the nonce value. If all signed transactions until the nonce before the reaping event
were immortal, all past transactions can be replayed once the account is refunded. There is no need
for the attacker to know your private key, valid signatures for those past transactions and nonces
already exist and are stored on-chain (meaning the private key was already used to generate those
signatures).

Making a [transaction mortal](../learn/learn-transactions.md#mortal-and-immortal-extrinsics) with a
relatively short mortality window will almost certainly ensure that replay attacks are not possible,
with the only exception being if the account is reaped and then re-funded shortly after submitting a
mortal transaction, and then an attacker replays that transaction within the mortality window (i.e.,
the specified block interval) and such transaction is valid (e.g. if you only have 10 DOT, and you
try to issue an extrinsic sending 20 {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }}, the
transfer will fail).

## Defense against Attacks

:::warning
Expand Down
30 changes: 13 additions & 17 deletions docs/learn/learn-transactions.md
Original file line number Diff line number Diff line change
Expand Up @@ -77,23 +77,19 @@ Here are some key differences between the different types of extrinsics:

### Mortal and Immortal Extrinsics

Extrinsics can be mortal (i.e. valid within a defined block interval) or immortal (i.e. always
valid). By default and for security reasons, all extrinsics will be mortal, but always checking
before signing is a good practice. This will avoid the chance of being a victim of a replay attack
after [reaping an account](./learn-accounts.md#existential-deposit-and-reaping).

A replay attack is where past transactions can be replayed (same [balance](#balance-transfers),
receiver account, etc.) without knowing private keys. This could happen in the context of reaping
accounts because the reaping process resets the nonce value. If all signed transactions until the
nonce before the reaping event were immortal, all past transactions can be replayed once the account
is refunded. There is no need for the attacker to know your private key, valid signatures for those
past transactions and nonces already exist and are stored on-chain (meaning the private key was
already used to generate those signatures).

Making a transaction mortal will almost certainly ensure that replay attacks are not possible, with
the only exception being if the account is reaped and then re-funded shortly after submitting a
mortal transaction, and then an attacker replays that transaction within the mortality window (i.e.,
the specified block interval).
Transactions are generally irreversible once confirmed and added to the blockchain, an immutable
ledger of all transactions. This means users must exercise caution, as mistakes such as sending
{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} to the wrong address cannot be reverted. The
permanence of transactions highlights the importance of careful verification before signing any
transaction on a blockchain network. It is usually a
[good practice not to blind sign transactions](../general/transaction-attacks.md) to avoid being
victim of an attack.

In blockchain terms, transactions can be **mortal** extrinsics (i.e. valid within a defined block
interval, usually short), or **immortal** extrinsics (i.e. always valid). It is possible to make
immortal transactions on {{ polkadot: Polkadot. :polkadot }}{{ kusama: Kusama. :kusama }} However,
[for security reasons](../general/transaction-attacks.md#replay-attack), it is highly recommended
not to do so and most wallet software will not allow you to make an immortal extrinsic.

### Balance Transfers

Expand Down

0 comments on commit 5207eb5

Please sign in to comment.