|author||Christian Grothoff <firstname.lastname@example.org>||2021-04-20 00:16:35 +0200|
|committer||Christian Grothoff <email@example.com>||2021-04-20 00:16:35 +0200|
specify account deletion
1 files changed, 22 insertions, 0 deletions
diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst
index 9b1f263..df0fc51 100644
@@ -55,6 +55,8 @@ Requirements
high-performance in terms of CPU, bandwidth, latency, storage
requirements, and the ability to levy fees on every operation that
is costly for the exchange) need to be preserved.
+* The system must handle the case where a customer no longer intends to
+ use the KYCed account (due to disuse, death, or key compromise).
@@ -125,6 +127,26 @@ Account creation and withdrawal
from long polling acceleration.
+1. The account owner can delete an account by signing a deletion message
+ with the account private key.
+2. This basically resets the KYC data at the exchange, preventing further use of
+ the account. This is helpful in case a user is concerned about having
+ accidentally disclosed the account private key to a third party.
+3. If funds remain in the account, an error message is generated instead. The
+ user can pass an extra override parameter to delete accounts even if
+ they still contain funds.
+4. A related endpoint should exist for the exchange operator, possibly
+ using messages signed with the exchange offline key. This could be
+ useful in case customers died or are otherwise in need for manual
+ intervention that requires an account to be deleted. In this case,
+ remaining funds in the account should be wired to a bank account
+ designated in the message with the offline signature. The audit
+ report should contain a special note for all of these account deletions.
Payment into an unknown account