whitespace

1 files changed, 19 insertions, 19 deletions

diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst
index 3cc807e4..8a8df2e2 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -21,8 +21,8 @@ Common States
 The following states apply to multiple different transactions.  Only pending
 and aborting have transaction-specific sub-states, denoted by ``state(substate)``.
 
-``initial``: The initial state is the result a user interaction. A transaction 
-may have more than one initial state (if it is started in multiple ways) or none 
+``initial``: The initial state is the result a user interaction. A transaction
+may have more than one initial state (if it is started in multiple ways) or none
 (if it's the result of another process)
 
 ``pending``: A pending transaction waits for some external event/service.
@@ -48,9 +48,9 @@ complete the transaction, the wallet is taking active steps to abort it. The ``l
 indicates errors the wallet experienced while taking active steps to abort the transaction.
 
 ``aborted``: Similar to a ``done`` transaction, but the transaction was successfully aborted
-instead of successfully finished. It will have the information of when (timestamp) it was 
+instead of successfully finished. It will have the information of when (timestamp) it was
 aborted and in which pending sub-state the abort action was initiated. Also, we can
-include more information information relevant to the transaction in `abortReason` 
+include more information information relevant to the transaction in `abortReason`
 
 ``suspended``: Similar to a ``aborted`` transaction, but the transaction was could be
 resumed and may then still succeed.
@@ -83,12 +83,12 @@ states: ``pending(*)`` and ``aborting(*)``.
 
    Should we show the retry timeout in the UI somewhere?  Should we show it in dev mode?
 
-   SEBASJM: Since the wallet will retry anyway, maybe is better if we replace the "retry" 
+   SEBASJM: Since the wallet will retry anyway, maybe is better if we replace the "retry"
    button with a "try now" button and a side text "retrying in xxx seconds"
 
-``[action:abort]``: Aborting a transaction either directly stops processing for the 
-transaction and puts it in an ``aborted`` state or starts the necessary steps to 
-actively abort the transaction (e.g. to avoid losing money) and puts it in an 
+``[action:abort]``: Aborting a transaction either directly stops processing for the
+transaction and puts it in an ``aborted`` state or starts the necessary steps to
+actively abort the transaction (e.g. to avoid losing money) and puts it in an
 ``aborting`` state.
 
 ``[action:suspend]``: Suspends a pending transaction, stopping any associated network activities, but with a chance of trying
@@ -115,15 +115,15 @@ Common pending sub-states
 ---------------------------------
 
 During the pending state the transaction can go through several sub-states before
-reaching a final state. Some of this sub-states are shared between different 
+reaching a final state. Some of this sub-states are shared between different
 transaction types:
 
 ``kyc-required``: The transaction can't proceed because the user needs to actively
-finish a KYC process. Part of a withdrawal process or peer-to-peer push credit. 
+finish a KYC process. Part of a withdrawal process or peer-to-peer push credit.
 
 ``aml-required``: The transaction can't proceed because the user needs to wait for
-the exchange operator to conclude an AML investigation by the staff at the exchange. 
-The user is not expected to take any action and should just wait for the investigation 
+the exchange operator to conclude an AML investigation by the staff at the exchange.
+The user is not expected to take any action and should just wait for the investigation
 to conclude. Part of a withdrawal process or peer-to-peer push credit.
 
 ``aml-frozen``: The staff at the exchange decided that the account needed to be frozen.
@@ -162,7 +162,7 @@ user. So special-casing this and testing this is IMO just not worth it.
   exchange.
 
   (??) is this needed? let say that the money is wired but the signal
-  never of the bank confirmation reached the wallet, what should happen? 
+  never of the bank confirmation reached the wallet, what should happen?
 
   * ``[poll-success] => pending(exchange-wait-reserve)``
   * ``[action:abort] => aborting(wallet-to-bank)``
@@ -205,7 +205,7 @@ user. So special-casing this and testing this is IMO just not worth it.
 * ``aborted(partially-withdrawn)``:
 
   In this state, the wallet should show how much money arrived into the wallet
-  and the rest of the money will be sent back to the originating bank account 
+  and the rest of the money will be sent back to the originating bank account
   after ``$closing_delay``.
 
 * ``done``
@@ -254,7 +254,7 @@ instructedAmount, effectiveAmount and the affectedAmount (partially effective am
   of transitioning the UI into a ``pending(repurchase-session-reset)``
   on a different transaction (which before was in ``done``).
 
-  (??) should not reset another transaction? 
+  (??) should not reset another transaction?
 
 * ``pending(proposed)``
 
@@ -284,7 +284,7 @@ Submit coin by coin (or in bulk groups) until payment is complete.
 
 * ``pending(refundable)``
 
-The payment succeed but if auto-refund-check is active it will be checking for refunds 
+The payment succeed but if auto-refund-check is active it will be checking for refunds
 
   * ``[auto-refund-timeout] => done``
 
@@ -334,7 +334,7 @@ A refund is a pseudo-transaction that is always associated with a merchant payme
 
   A failed refund can technically still transition to ``done``, because the wallet
   doesn't query some refund resource, but the purchase for refunds.  Thus, a previously
-  failed refund can suddenly transition to ``done``. 
+  failed refund can suddenly transition to ``done``.
 
   (??) separate transient error vs permanent error ?
 
@@ -409,7 +409,7 @@ Submit coin by coin (or in bulk groups) until deposit is completed.
 
   * ``[action:abort] => aborting(refund)``
   * ``[processed-success] => pending(track)``
-  * ``[processed-error] => aborting(refresh)`` 
+  * ``[processed-error] => aborting(refresh)``
 
 * ``pending(track)``
 
@@ -605,7 +605,7 @@ Wallet read the taler:// URI
 
 * ``pending(refundable)``
 
-The payment succeed but if auto-refund-check is active it will be checking for refunds 
+The payment succeed but if auto-refund-check is active it will be checking for refunds
 
   * ``[auto-refund-timeout] => done``