diff options
author | Florian Dold <florian@dold.me> | 2021-03-29 13:09:30 +0200 |
---|---|---|
committer | Florian Dold <florian@dold.me> | 2021-03-29 13:09:30 +0200 |
commit | 7a145f3654fcb5aeeee6c87de69bf5965d54c450 (patch) | |
tree | 74cd50898c952fc1785dc6d98d89785e9b35cb17 /2021-offline | |
parent | 89ef2ff0540bc01c11a9f74baf45db2b4483b654 (diff) | |
download | marketing-7a145f3654fcb5aeeee6c87de69bf5965d54c450.tar.gz marketing-7a145f3654fcb5aeeee6c87de69bf5965d54c450.tar.bz2 marketing-7a145f3654fcb5aeeee6c87de69bf5965d54c450.zip |
minor edits, added a FIXME
Diffstat (limited to '2021-offline')
-rw-r--r-- | 2021-offline/offline.tex | 28 |
1 files changed, 13 insertions, 15 deletions
diff --git a/2021-offline/offline.tex b/2021-offline/offline.tex index e631faf..6c20ebc 100644 --- a/2021-offline/offline.tex +++ b/2021-offline/offline.tex @@ -94,7 +94,6 @@ choices: accessing certain functions of the device.\footnote{ A good example for such a design is~\cite{christodorescu2020twotier}.} \item - % FIXME: this is a bit too technical Retroactively identifying the user after network connectivity is restored, in privacy-preserving systems using conditional deanonymization, and attempting to recoup @@ -145,28 +144,28 @@ informational self-determination. Forcing users to use hardware that they do not control is limiting their ability to control and customize their digital lives. -In privacy-friendly systems (like those based on +Even in privacy-friendly systems (like those based on Chaum~\cite{chaum1988untraceable}) where citizens can use digital cash to make purchases anonymously, adding the ability to retroactively deanonymize double-spending users implies that accidentally double-spending (say after -restoring from backup) voids the privacy assurances of the system. A key -security property of the systems would thus be weakened and becomes brittle. - +restoring from backup) voids the privacy assurances of the system. +% FIXME: Not clear what this refers to. What is the security property +% that is weakened? +A key security property of the systems would thus be weakened and becomes brittle. \subsection{Hurting availability} -A hardware-based solution not only limits availability to those -users that can afford the device, but also limits user's ability -to make backups of their digital cash. Thus, loosing the hardware -will result in citizens loosing their digital cash, something a -software-based solution can avoid. This drawback can only be -offset by revealing the user's identity which means the solution -would not offer good privacy protections. +A hardware-based solution not only limits availability to those users that can +afford the device, but also limits user's ability to make backups of their +digital cash. Thus, loosing the hardware will result in citizens loosing their +digital cash, something a software-based solution can avoid. This drawback can +only be offset by revealing the user's identity to reveal a double spending +fraud without using trusted hardware, which means the solution would not offer +good privacy protections. Similarly, in systems where double-spending is detected and later penalized, the resulting financial risks will create pressures to deny citizens with insufficient reputation or credit score -from using the system to mitigate operational risk. One argument for offline CBDC is the objective to improve availability in situations where network access is unreliable. However, today @@ -179,7 +178,7 @@ unlikely to significantly improve availability. \subsection{Hurting innovation} In a world where everything is headed towards software solutions, a -mandatory hardware security solution for a CBDC is pretty restrictive, +mandatory hardware security solution for a CBDC is restrictive, not just for customers but also for businesses who want to process payments or offer services related to payments. Furthermore, to ensure the security of the solution, the production of approved @@ -209,7 +208,6 @@ adding offline payment systems have inherent and severe risks. The exposure to these risks should be limited by only resorting to an offline fallback mode of the payment system when actually required. -% FIXME: Probably this is not explained well enough Discouraging the use of the offline fallback mode can be easily achieved by by exposing the payee to counterparty risk. In a system based on restricted hardware elements, the payee would bear the risk in case of a compromised |