Central Bank Digital Currency (CBDC): towards proven technology, ready for large-scale deployment

[synctext]

The goal of this master thesis research is to take the necessary steps to mature Central Bank Digital Currency (CBDC). The level of maturity of CBDC targeted within this thesis is "proven technology, ready for large-scale deployment".

Stress testing and integration with the upcoming digital European identity is expected to be a significant part of this thesis work. All software will be open source and all gained technical expertise will be shared publicly. The permissionless ledger technology used will be Trustchain, this is formalised an IETF Internet Standard draft since 2018. The solution is required to be ledger agnostic.

This CBDC technology is required to be fully decentralised. Inefficient and wasteful "mining" is explicitly not allowed. No critical dependency on existing banking infrastructure may exist. No central points of failure or performance bottleneck can be present in the system architecture. Due to the critical nature of financial infrastructure, an "offline mode" must be supported. Transfer of money using QR-codes or some other mechanism must be supported together with fraud measures.

Delft University of Technology has already conducted small trails with digital Euros, supporting offline transactions. The work by Wessel Blokzijl resulted in a fully functional prototype, featuring real Euros, real retail testing, and integration with the IBAN banking system using a "Tikkie"-based gateway. Read the full master thesis here. Delft University of Technology is also a government partner for digital identity at passport-level. We have an operational open source prototype for digital identity, integrated with the European Commission EBSI infrastructure. By using EU EBSI this thesis aims for seamless integration of identity and money. See: https://github.com/Tribler/tribler/issues/6023 This existing self-sovereign identity work of Delft will be re-used.

Stress testing is also a key part of demonstrating the maturity of this technology based on open source and open standards. The requirement is horizontal scalability, feasible due to the inherent parallelism of the used Trustchain ledger. The ambitious target for experimental demonstration is 1 million transactions per second. This will provide the irrefutable proof required that a digital Euro can underpin the entire digital economy of Europe. The check-pointing mechanism used by Wessel might need replacing or improvement. Finally, a small field trail (4 people) would demonstrate the end-to-end feasibility and maturity level of this system. In the ideal case CBDC would utilise an IBAN account owned by the central bank to conduct several 1 Euro transactions in the wild. Possible joint experiments of other governments will be explored with actual money, but very low amounts. For instance, exchange of 1 actual Euro into an equivalent Singapore Dollars, e-Kroner (Sweden) or collaboration with the German Bundesbank to conduct end-to-end system testing.

[KoningR]

Progress Report

• Build and run Trustchain app
  • Interface crashed when transferring money; made issue report on Git
• Read Blokzijl thesis
• Read ValueTransfer thread
• Read interview with Fabio Panetta (Der Spiegel)
• Read EU report on digital euro (about 60%)
  • Largely answers question "why a digital euro"

[synctext]

2020 work by Jetse: https://repository.tudelft.nl/islandora/object/uuid%3Ad3d56dd8-60ee-47f7-b23a-cdc6c2650e14 Spend 50% of time understanding the Joost Code in superapp please. Sprint goal: reliable digital Euro transfers

[KoningR]

Sprint log (last week)

• Read Consensus-less Security (Brouwer).
• Inspect and (partially) understand Trustchain/Eurotoken/Superapp code.
• Attempt to set up own gateway using Blokzijl's repo.
  • Failed; instructions were mostly non-existent. Current problem: I do not have a Tikkie API key.

[synctext]

Comments. This is an important CBDC report from China

The People’s Bank of China (PBOC) attaches great importance to the research and
development of digital fiat currency. In 2014, it set up a task force to study digital fiat
currency, and its scope of research covered the issuance framework, key technologies,
issuance and circulation environment, and international experience.

ECB has started the task force and announced their "digital Euro" exploration. Still, Europe is 7 years behind.

For future direction the "stress testing" part could be the key to your results section. This towards 1 million transactions per second. Offline double spending is known open issue; no need to fix this. Tikkie API key: Joost has one @jwbambacht I believe. Is he also running a Blokzijl gateway locally? Calling it a "Stable Euro token" with gateway at AFM is possible alternative, CBDC requires central bank involvement.

For context, core banking systems on mainframes are from '70. Commercial ageing infrastructure. Replace after 50 years, trustworthy new infrastructure, uncompromising open source, no commercial banks with default risk, no single point of failure, and mobile-first.

Sprint goal: duplicate test-money infrastructure via test-Tikkie account that Joost has operational. Unit testing as next item.

[synctext]

First live digital Euro transaction?! Worldwide state-of-the-art, parties are mentioning cross-border CBDC; never actually achieved yet! Market analysis: all commercial offerings are needlessly complex, brittle, not disaster-proof (e.g. offline support), and therefore insecure.

• See Hong Kong Monetary Authority ("proof-of-concept" level only): "we are delighted to join forces with the Bank of Thailand in conducting a joint research project named “Project Inthanon-LionRock” to study the application of CBDC to cross-border payments, with a view of facilitating HKDTHB PvP amongst banks in Hong Kong and Thailand.
• JP Morgan made the first "stable coin" claims years ago, always vaporware. Now part of Consensys CBDC Ethereum. Still proof-of-concept level: "will involve the development of a POC for the issuance of a tokenized form of CBDC", https://consensys.net/blog/enterprise-blockchain/cbdc-pilots-on-ethereum/
• France: Societe Generale, live transaction “explores a more efficient process for bond issuances.” issued a €100 million covered bond as a security token on the Ethereum blockchain https://tokenist.com/societe-generale-issues-e100-million-covered-bond-as-a-security-token-on-ethereum/
• Facebook Novi stable coin, not live yet, https://finance.yahoo.com/news/facebook-prepares-launch-novi-digital-135258055.html
• China (repeating) http://www.pbc.gov.cn/en/3688110/3688172/4157443/4293696/2021071614584691871.pdf
• China lottery tickets used in live CBDC trail https://news.coincu.com/3527-chinese-banks-are-asking-their-employees-to-promote-digital-yuan-wallets-e-cny/

Disaster-proof infrastructure is investigated in this master thesis (telecom thesis, not related to CBDC). The 1994 Northridge earthquake destroyed infrastructure. It might take 30 to 90 days to fully repair. Is there no digital money when there is no Internet? Thesis illustration:

[KoningR]

Sprint log (until 15-10-21)

• Wrote an elaborate README on installing Blokzijl's Eurotoken from scratch, with and without Docker.
  • See my stablecoin fork.
• Modified Trustchain source code slightly to operate entirely within my own community and sandbox gateway.
• Made ABN developer account for fake Tikkies.

[synctext]

Possible thesis focus: make Wessel prototype ready for large-scale production usage + also fully decentralised. ideas: permissionless accounting. Everybody can undersign a transaction, remove single points of failure.

Practical next sprint demo: ability to create 4 times 1 Euro and send them to 4 contacts? (custom .APK)

Conceptual architecture: offline double spending problem is probably impossible to prevent. We assume everybody can double spend and estimate this likelihood with the counter-party risk assessment function. An offline verifier is a trustworthy node which checks and signs offline spending records. [Alternative architecture is preferred, give each minted coin a unique serial number. Then double spending is trivial to prove: fraudster signed away the same coin twice!]

No Internet is needed when using offline verifiers. What guarantees are offered by your system when two offline nodes using same trusted verifier? idea: If every counterparty of two transacting nodes inform the offline verifier we can guarantee detecting of double spending. (drawback: temporary central authority) {gateway == Kotlin == library == .apk?}

[KoningR]

• Prepared current Eurotoken code for a demo at TU Delft using a remote server on a different network.
• Unexpectedly stumbled upon a bug that prevents Trustchain from working on certain mobile data providers; this was known already and (verified) not due to Eurotoken.
• Discussed potential directions of Eurotoken at TU Delft.

[synctext]

• 2050 vision: disaster-proof financial infrastructure. The thesis focus ignores all existing legacy infrastructure and legal frameworks. Uncompromising focus on must-have core financial infrastructure for 2050 timeline. Cardinal infrastructure for possible entire digital economy. Requirements: robust, scalable and disaster-proof infrastructure. Desired property: security is improved with increased usage. Provide underpinning for the robot economy.
• towards 1 million transactions per second. Great quantitative material. Isolated Kotlin code. We achieved 1 million tx/s before. See prior stress test with Checo consensus algorithm. Scientific publication of this work
• offline gossip-based payments. Design principle: everybody is equal and helps to spread the transaction information. Everybody owns the infrastructure?!
• Counter-party risk assessment function: spend 2 weeks on this maximum! Do a simple or even trivial implementation of this. Use history to predict future reliability. With unique serial numbers, we can burn all privacy and gather the full history of each coin in your wallet {Leave Tor integration for next thesis student}. Leave also risk assessment for future work.
• Sprint target coming 3 weeks: create minimal commandline utility with Kotlin transaction code and IPv8 community code. Give IPv4:port info to each instance for manual peer discovery. Desired demo: start two instances, run a third instance and conduct a (digital Euro) transaction. re-usage of Trustchain packets format? Commands: create_coin, send_money and transaction_history.
• Next step could be numerical results, see tools used for Checo evaluation plus some of the Gumby experiment runner scripts plus multichain_client.py

[KoningR]

Sprint log

• Built kotlin-ipv8 locally (which was an unnecessarily complicated endeavour due to a lack of documentation).
• Made a pull request to update the readme with the information I would have liked to know before starting the building process.
• Found a bug that prevents Trustchain from working at all when executed from command line using kotlin-ipv8. Made an issue.
• Fixed this issue with this PR.
• Implemented a naive communication protocol to send Eurotoken using Trustchain, assuming only honest nodes.

[synctext]

• Solid progress with the infrastructure! :medal_sports:
• Take another step in the formulated scientific direction (offline; 1M tx/s) and sprint target.
• Serial number of bank coins as central to the design? Single signature ownership or dual signatures?
• demo on two laptops using openjdk 11 of create_coin, send_coin and transaction_history. Add install and cmdline instructions.
• Build a test and performance analysis infrastructure. Use text file as input for your command line script: https://github.com/KoningR/eurotoken/blob/6909e48cba1f77805185f9ca93ccdf677310fc61/src/main/kotlin/Main.kt#L12

  create_coin "1"
  create_coin "2"
  create_coin "2"
  send_coin "1" "6909e48cba1f77805"
  send_coin "2" "6909e48cba1f77805"
  send_coin "3" "6909e48cba1f77805"
  transaction_history
  quit

• Create 1000-ish transactions. First performance analysis: make a first performance graph
• Keep Trustchain. trustchainCommunity.createProposalBlock(BLOCK_TYPE, transaction, publicKey) Leave protocol engineering and tuning for later. Future step, concurrency and improve protocol, https://github.com/KoningR/eurotoken/blob/6909e48cba1f77805185f9ca93ccdf677310fc61/src/main/kotlin/Application.kt#L187

[KoningR]

Sprint log

• Modified Eurotoken database schema to support grouped transactions and query transaction history per coin or peer.
• Modified the command line application to accept text files containing instructions.
• Attempted unsuccessfully to debug why a Eurotoken peer sometimes receives the same genesis block twice.
• Attempted to measure throughput but failed due to NEXT_HASH_MISMATCH. Currently investigating which mechanisms should be used to circumvent this error.

[synctext]

Progress:

• cmdline is functional!
• Remember to guard correctness and not yet into a optimisation-focus. Don't be the student whose code gets dumped and cancelled. Code coverage!
• https://github.com/KoningR/eurotoken/blob/main/README.md no build instructions
• Key target 1M/s, would complete big chunk of thesis (network of 2-50 people)
• first graph: x-axis simply time and y-axis conducted transactions. Only then take next step of different line with various parameters and settings (or workload dataset) on X-axis and Tx/s on Y-axis.
• Poster draft! (portrait)
  • title: CBDC...
  • status: picture of the field trail by Wessel. +operational prototype
  • 14 days ago comment: use transaction script, your 3 cmdline, etc
  • offline disaster-proof: re-usage earthquake picture (6 oct comment)
  • Thesis target: 1M/s
• Future sprint: decide on HalfBlock https://github.com/Tribler/kotlin-ipv8/blob/master/ipv8/src/main/java/nl/tudelft/ipv8/attestation/trustchain/payload/HalfBlockPairPayload.kt#L7

  sh ./gradlew
  Downloading https://services.gradle.org/distributions/gradle-6.1.1-all.zip
  sh ./gradlew build
  > Task :compileKotlin FAILED
  e: /home/pouwelse/GITHUB/eurotoken/src/main/kotlin/Application.kt: (60, 20): Too many arguments for public final fun start(): Unit defined in nl.tudelft.ipv8.IPv8
  FAILURE: Build failed with an exception.

  Reason: unmerged code in IPv8 @InvictusRMC can hopefully help :smile: https://github.com/Tribler/kotlin-ipv8/pulls

[KoningR]

Sprint log

• Read Matt's thesis.
• Read De Vos's Xchange paper.
• Once again attempted to fix SQL duplicate block error without success.
• Called with Rowdy and discussed RUDP and delays.
• Implemented a simple delay mechanism to gauge the throughput of Trustchain.
• Measured Trustchain's throughput and plotted this data. The measured performance is, in many ways, not representative. Here's why:
  • Measurements were done using 2 peers, connected over LAN.
  • There is no verification mechanism in place, so 'throughput' effectively means the roundtrip speed of UDP between the clients.
  • There is no retrieval mechanism for UDP in place, so 'lost' eurotokens were never retrieved again.
  • To reduce the number of lost messages, the sending client was restricted to a waiting time that was determined using a rudimentary binary search.
  • In short, there is no fixed eurotoken protocol yet, and as such, a comparison of performance does not make much sense.
  • 
• Made a eurotoken poster to display on campus.
• Added build instructions to Eurotoken.
• Made a PR to improve the build instructions of IPv8.

[synctext]

• first experimental results :confetti_ball: :partying_face: :tada:
• Prior Wessel Python; now clean-slate Kotlin IPv8 cmdline client
• Poster: first trail March 2021 of Delft offline Euro platform. Based on Trustchain and self-sovereign identity
• "disaster-proof digital cash"
• Poster architecture components "Offline Eurotoken": offline Eurotoken, trustchain, IPv8, passport-grade ID, generic wallet, double spending detector, risk estimator and reputation?
• Exploring combined retail and wholesale banking infrastructure with
  • rudimentary offline mode supported in Superapp prototype
  • rudimentary online mode supported: central bank nodes
  • "cheat"
  • performance: multiple validators; each node gets 1 validator (1,25,50,75,100)
  • rudimentary performance mode: determine performance bound
  • trivial baseline performance
  • really "bare bones" for now
  • no positive balance verification or others
  • "sending client was restricted to a waiting time that was determined using a rudimentary binary search", improve! Check outgoing socket buffer size?
  • print upon lost packet
  • ignore occasional lost transactions
  • try to get good raw speed; network wide; exploit parallelism; multiple clients (1,25,50,75,100)
• sliding window by Joost: https://github.com/Tribler/tribler/issues/6029#issuecomment-1005190589
• Status today: no "grand design" yet

[synctext]

Related CBDC work with instant payments: https://www.bis.org/publ/othp39.htm France: https://www.banque-france.fr/sites/default/files/media/2021/11/09/821338_rapport_mnbc-04.pdf https://www.jpmorgan.com/news/jpmorgan-central-bank-digital-currency-report German digital (IoT) Euro report: https://www.fpmi.de/files/fpmi/content/downloads/en/expertopinion/Studie_programmierbarer_Euro_en.pdf Google search query anything open source? true simple solutions? passport-grade ID for wallet? Fully non-custodian?

[KoningR]

Sprint log

• Work on merging the dispatcher fix with the new EVA protocol and figure out why this breaks the trustchain superapp.
  • Contacted Joost for this.
• Visit DNB to meet my thesis supervisors and co.
  • Set up a work laptop and read a lot of mails.
  • Had small introduction meetings via Teams.
• Re-read Wessel's paper to figure out what exactly did and didn't work.

[synctext]

• Thesis format example by Joost IEEE 2-column + Delft mandatory page wrappings like Rowdy
• Contract 15jan-15july at central bank (providing intense support and bi-weekly guidance).
• define you planning and methodology: "Fully technology-driven process, with minimal of overhead. Specifically optimised to maximise software development productivity. We will use a 2-week sprint schedule.. sprint targets will be listed on the Github issue... Each week it will be documented if the target is achieved or not..."
• define scope of thesis
  • towards proven technology, ready for large-scale deployment
  • losts of prototypes, experiments, and commercial offerings of immature products
  • Build on existing Wessel prototype
  • "disaster-proof digital cash"
  • optionally contact nodes within a pool of co-signers (could be central bankers, witnesses,..)
  • after re-trying we enter a logical 'offline mode'
  • simple risk assessment function for counter-parties (max. 1 week of effort, out of scope)
  • Supporting 1 million transactions per second. (1st prototype 30 tx/sec)
  • Connecting to strong identities to deter fraud.
  • integrate with the EU digital identity infrastructure, EU EBSI.
  • non-custodian design based on self-sovereign identity at passport-grade authentication level
  • open innovation process approach
  • re-usage of existing open source identity solutions
  • re-usage of existing open source wallets, blockchains, and extend existing open source work.
  • very low-cost infrastructure. For instance Alipay. "merchant are charged 0.55% transaction fee. Comparing it with 3-4% fees applied by credit card companies"
  • We will investigate .... like Singapore?
  • go beyond prior experiment by Wessel (live IBAN gateway)

Month	activity
Jan	Define scope and read background, first prototyping; write problem description chapter and introduction
Feb	Experiment plan and first iteration of prototype
March	First round of real-world testing
April	First round of incremental improvements
May	Next rounds of real-world testing, identify issues and improvements
June	Obtain measurement results and write chapters of report
July	Finalize documantation

[KoningR]

Sprint log

• Wrote a draft version of the Eurotoken protocol to identify theoretical limitations.
  • Called with Rowdy to discuss this draft.
• Modified Eurotoken implementation to use EVA instead of Trustchain.
• Attempted to fix a dispatcher problem, unsuccessfully.
• Measured performance of EVA instead of Trustchain with manual delays. The good: no more lost packets. The bad: EVA appears to perform slower than a manual sending delay.
  • 
• Called with various people at DNB and attended a digital session about DLT.

[synctext]

• Progress in thinking, requirements, and architecture
• CBDC with disaster-proof requirement we focus on is not available as a commercial product. Still at innovation stage.
• related work. zero-trust architecture, implemented in USA. Discussed in presidential memo. a Federal zero trust architecture (ZTA) strategy, requiring agencies to meet specific cybersecurity standards and objectives by the end of Fiscal Year (FY) 2024
• Focus and scope (repeating and combining two issues above):
  1. rudimentary performance mode (its impossible to go faster :astonished: ; linear scalability?)
     • science: determine with certainty what the bottleneck is through experimental proof.
     • simply the combined speed of (NaCL or this) raw signatures? (ensure the lowest physical layer is the bottleneck?)
     • High-speed high-security cryptography on ARMs
     • Curve 25519 for the Cortex-M 4 and beyond
     • High-speed high-security signatures
     • exploit hardware acceleration to the max (show difficult crypto performance curves; Table 6 only)
     • no validation
     • in-memory only, no IPv8, no SQL; minimal message size
     • no Internet transfer of transactions in this mode. Conduct transactions between multiple processes inside a single phone.
     • Do not use UDP or TFTP/EVA protocol but: inter process communication read: https://manuawasthi.in/pubs/bench2021.pdf and https://doi.org/10.1109/ICEIEC.2016.7589742
     • linear scalability: no pool of co-signers, we assume they wont slow us down
  2. online mode (quantify the performance cost of safety features?)
     • Cost of persistence: determine if this lowers raw performance
     • Most simple possible architecture for pool of co-signers: private DNB server for each citizen.
     • Next bottleneck: Internet transfer? Bulk 100MByte of transactions (ensure bandwidth is not the bottleneck); never blocking or idle
  3. offline mode (1 week of effort: risk assessment module to inform users)
• correctness: 25 tx per second for 2nd prototype.

[synctext]

• China CBDC usage. They are distributing HK$5000 of money that expires. Economic booster instrument, helicopter money.
• USA: "This collaboration between MIT and our technologists has created a scalable CBDC research model that allows us to learn more about these technologies and the choices that should be considered when designing a CBDC."

[KoningR]

Sprint log

• Read Joost's thesis.

• Re-read this entire ticket.

• Read about colored coins.

• Made a separate repo for the plots.

• Measured the EVA protocol with various batch sizes and found a HUGE performance increase.

  • The plots also seem to indicate that data transfer speed is the bottleneck; persistence barely makes a dent.
  • 
  • 

• Created a StressCommunity and analysed ipv8's sending routines.

  • The setup: a laptop sent UDP packets using ipv8 over Wi-Fi to a desktop connected via LAN.

  • Internal discussion about token sizes and throughput led to changing the units of the graphs to UDP packets (1472 usable unencrypted bytes) instead of 'tokens'.

  • When sending UDP without ACKs:

    • Recreating a fixed, simple payload gives a throughput of ~6.5mbps.
    • Reusing the same payload is much faster but causes many lost messages (almost 90%).
      • When sent in very small batches, the throughput is more than twice as high (~15mbps).
      • This suggests that on weaker CPUs the impact of creating packets is non-negligible.
        • Interestingly, copying data into the existing reused payload has barely any impact on performance. Optimising this seems doable if necessary.
      • It might be that reusing the same payload accelerates transfer so much that somewhere a buffer fills up and many packets are dropped.
      • Drops become more prevalent with larger batches, suggesting that indeed a buffer overflows.
    • Because reusing the same payload is not realistic, I attempted to figure out what caused new payloads to be so much slower. I identified (potential) slowing causes in ipv8, modified them, and measured the results.
      • I modified IPV4Address to create an INetAddress once upon creating instead of once per packet send.
      • I removed the multithreading for each individual packet because Java's UDP send methods are synchronized blocks.
      • I modified ipv8's serialize() method to be more memory effective.
      • 

• I measured the performance of EVA with default settings, which sometimes gave okay results (~1.5mbps) but regularly faced enormous outliers (~100kbps).

  • Link to code.

• Conclusion 1: there needs to be a discussion regarding the size of a token, because it influences throughput drastically.

• Conclusion 2: ipv8's UDP and signing functionality appears fast enough to scale to Eurotoken's demands. EVA's does not seem to. However, it must be mentioned that no extensive parameter search was done in this domain.

• Conclusion 3: It appears DNB does not see the necessity of scaling to such enormous amounts of transactions as what we're aiming for. Also, I believe they would rather see a working, albeit slower prototype.

[synctext]

• Solid progress since prior sprint
• Lesson learned: IPv8 with ByteArray is designed for preventing bugs, correctness, and ease-of-usage by developers. Not UDP/second maximisation.
• Try to get Kotlin Native operational, limited to 1 sprint attempt only.
• Key reason is to eliminate magic

  • It might be that reusing the same payload accelerates transfer so much that somewhere a buffer fills up and many packets are dropped.

  • At master thesis level we require exact answers. Socket buffers should be profiled. IPC as baseline. Go beyond 100Mbps.
  • Remove black boxes in performance analysis
  • Nobody has done performance analysis of EVA or correctness test. Only black box performance analysis.
  • Did you measure the random number generator performance :open_mouth: ? Use a methodology to eliminate that: baseline IPC, cost of local UDP, cost of two machines, cost of acknowledgement, cost of persistence, cost of double spending check, etc.
  • You specific application can tolerate {some} out-of-order delivery (single atomic token transaction)
• Repeating: its impossible to go faster :astonished: ; linear scalability?
• Repeating: "ready for large-scale deployment" means quality assurance processes, well understood performance, and solid attempts at bug elimination.
• Reminder: Joost code still contains the Wessel double spending server check. ToDo: remove/disable this approach

[synctext]

• advise: try to think of a time-boxed approach, using 18 days since last meeting for IPC could be improved.
  • IPC
  • Kotlin Native
• Determine the shift of "going fast" to "going not so fast anymore".
• Ensure to have 2 graphs for next meeting (Kotlin only)
  • Determine cost-of-crypto. (here and here) Profiling of full-speed verify and sign libraries. (graph MByte / sec validated; MByte / sec signed)
  • Next step is repeatedly sending the same UDP packet (? UDP throughput graph, static content???) (inside 1 process of 1 machine)

[KoningR]

For a (slightly more) documented Wessel gateway refer to my fork. Do note that I am not maintaining this fork or the corresponding upstream repository.

[KoningR]

Sprint Log

• Measured performance of IPC, UDP (native and JVM, reusing and recreating packets, local and LAN), and signing and verifying with LazySodium (1 batch and split batches).
  • Source code
  • Set up Ubuntu twice.
  • Wrote IPC and UDP code in C using Linux pipes.
  • Wrote UDP JVM and LazySodium code in Kotlin.
  • Performed all measurements 5 times.
  • Wrote plotting code in Python.
• 
  • All measurements timed how long it took to process 100 megabytes of data.
  • The UDP measurements were performed by sending 200 megabytes of data, of which only 100 megabytes needed to be received.
    • No acknowledgement system was measured.
  • All measurements were done 5 times with 5 warmup rounds on a Lenovo Thinkpad.
  • LAN performance was measured using a 1 Gigabit connection. Measurements indicate that all LAN performance was limited around ~118 megabytes per second, close to the theoretical limit of 125.
  • Actions labeled 'reuse' indicate that the same UDP packet was used for all 100 megabytes of data. Actions labeled 'recreate' indicate that the UDP packet was recreated for each send.
  • Actions/protocols:
    • IPC: Inter-Process Communication in the form of named pipes implemented in C on Linux.
    • UDP(C-reuse): UDP implemented in C and reusing the same packet.
    • UDP (JVM-reuse): UDP implemented in Kotlin and reusing the same packet.
    • UDP (JVM-recreate): UDP implemented in Kotlin and recreating the packet each send.
    • UDP (JVM-recreate-LAN): Identical to UDP (JVM-recreate) but the sender and receiver process were different machines connected over LAN using a 1 Gigabit connection.
    • Sign: The signing performance of LazySodium (Kotlin) over 1 batch of 100 megabytes.
    • Verify: The verification performance of LazySodium (Kotlin) over 1 batch of 100 megabytes.
    • Sign (split): The signing performance of LazySodium (Kotlin) over batches of 1472 bytes, multithreaded (8 threads), for a total of 100 megabytes.
    • Verify (split): The verification performance of LazySodium (Kotlin) over batches of 1472 bytes, multithreaded (8 threads), for a total of 100 megabytes. On the measured system, this action was the slowest of the measured actions, with a throughput of ~90 megabytes per second.
  • The measurements performed are upper bounds for user performance, as it is highly unlikely that current smartphones have Gigabit peer-to-peer connections or processors fast enough to achieve comparable sign and verification performance.

[synctext]

repeating Grand storyline: we take the existing WesselEuro, dump all the code, redo stuff, and get it a step close to production usage. For that testing is essential.

Suddenly there is a wealth of interesting results. Why? (reason: IPC was the first hard task, delayed everything) We learned a lot about performance, now try to wrap up "exploratory performance mode" in 1 sprint:

• Single cool graph :exclamation: for thesis with 20-25 tasks with increasing features and decreasing performance.
• crypto is dominant for laptop {even with 8 cores}, networking is no issue, open question what about Android phone CPUs?
• Crypto performance
  • crypto parameters (keysize, curve ed25519 only?)
  • stream-based operation versus packet-wise (1472 bytes packets)
  • single-core versus multi-core
  • explore the main/a few libraries
• Explore IPv8 networking performance
  • Free and malloc of each UDP packet?
  • How deep to explore and tune?
  • Acknowledged data :boom: (EVA protocol, 8k packets, etc)
  • TFTP alternative code base
• Explore Eurotoken performance
  • serializing structured data
  • parsing of incoming UDP packet, IPv8 fields, and token verification
  • create outgoing UDP packet, IPv8 field, and serialisation of actual EuroToken struct

Focus for this sprint: single comparative performance plot for thesis :dart:

[KoningR]

Sprint log

• Drop threading merge because I don't use the superapp.
• Attempted to figure out why Kotlin-reuse is so much slower than C-reuse.
  • Recreated measurement code in Java to see if that was faster.
  • It was not.
• Before implementing performance mode, figured out how a valid minimal IPv8 packet should look like that carries tokens:
  • UDP header: 8
  • IPv8 prefix: 22
  • Recipient key: 74
  • Token: 1500 - 8 - 22 - 64 - 74 = 1332 bytes
  • Signature: 64
• Implemented measurements with Java NIO.
• While working on performance mode, took a deep dive into byte buffers.
  • Found a bug in my JVM implementation, will report soon.
• Went to the bank.
• Implemented performance mode; found too slow with ArrayList, LinkedHashSet, LinkedList.
  • With HashSet throughput of roughly 14.8 megabytes per second.
  • Currently working on optimizations.
• New measurement plot:
• 

[synctext]

• What are you measuring? 100MByte test file on an Ubuntu laptop with 16GByte should be no problem. Usage of singleton?
• Profile sign and verify of digital cash (no encryption for communication privacy in entire thesis; another thesis worry)
• Focus next sprint
  • IPv8 usage
  • Online mode: get online mode operational (performance bound)
  • as-simple-as-possible cash money architecture: 2 Euro, 1, .5 cents, .2,.10,.05,.02 and 0.01 coins only. Coins are minted by central bank and transferred as payment. Mix-and-match to reach certain value: 5 x 2 Euro and 3 x .5 = 11.5 Euro.
  • (EDIT: replay attack ignored for coming weeks, ToDo list)
  • skeleton only: unique random ID for the "Euro Cash Coin" + signature of Central Bank
  • verifications per second of a gateway
  • Laptop and PC setup
  • Linux Laptop with 3 processes: send,receive, and verifier (1 verifier only!! {assume for entire thesis that verifier are 100% reliable})
  • determine: tx/sec with check every micro-block and per 100 transactions
  • have a tx/sec graph
• Future sprints
  • robustness, reliability, and packet re-transmission cost: https://github.com/Tribler/tribler/pull/6831
  • Understand performance of offline mode.
  • most likely approach: keep each offline transaction atomic, send the history of transactions of each coin.
  • Performance mode (in thesis Figure detail, wrap up)
  • read related thesis; this is the master thesis of IPv8 creator
• Bank contracting: 15 June (soft)

[synctext]

Related work by guardtime.com

• during the test handled over 300,000 simultaneous payments a second and the money reached the payee in less than two seconds https://www.eestipank.ee/en/press/experiment-central-banks-digital-euro-illustrated-new-possibilities-blockchain-technology-26072021
• https://www.ecb.europa.eu/paym/digital_euro/investigation/profuse/shared/files/deexp/ecb.deexp211011_3.en.pdf
• https://haldus.eestipank.ee/sites/default/files/2021-12/EP-Guardtime_CBDC_Research_2021_eng.pdf
• EDIT: consumer view by Guardtime on CBDC https://m.guardtime.com/files/CBDC_research.pdf
• Patent warning (thankfully our work predates the Texas Hyper-DAG patents and these Estonia filings :sweat_smile: ): https://www.google.com/search?q=inassignee%3A%22Guardtime%22&tbm=pts
  • its just storing hashes on a server :roll_eyes: 12 patents
  • early 2011 filled patent: data that identifies at least one entity in the hash tree path used for its initial registration in the infrastructure TUDelft 2009 work invalidates: http://bittorrent.org/beps/bep_0030.html
  • their "keyless stuff" is really legacy! "System and method for generating keyless digital multi-signatures". Really silly ideas we do not use: a keyless digital signature service provider operates a top-level signature generation server that is in communication with lower level servers that may be operated by other entities, such as customers of the service provider.

[KoningR]

Sprint log

• Implemented online mode compatible with IPv8!
  • Clients and verifier are operational.
• Bad news
  • 'Only' 2700 transactions per second per client.
    • Why?
      • Tokens need to contain public keys of sender and receiver (2 * 74 bytes) and a signature (64 bytes): 221 bytes per token (of which id and value take only 9). Assuming a download speed of 10 megaBYTES per second, no packet loss, no overhead, we are limited to 4525 transactions per second per client.
      • Packet loss is immense; need for acknowledgement system is dire.
        • Measurements largely measure packet drop, not actual performance.
        • EVA might not be suitable / too slow / build my own?
      • Cryptography per token is slow, but necessary.
        • Batching signatures is not an option because a signature should refer to 1 token only.
        • Cryptography library is Java wrapped, does not support indexing and instead uses array copy. Presumably slow; not yet profiled.
      • Persistence mechanism will probably incur another performance hit.
• Optimism
  • Offline mode can potentially greatly increase the number of transactions by passing them on before having them verified.
  • Threading and coroutines should increase performance; not built in yet, first a persistence mechanism.

[synctext]

• solid performance results! All thesis-level material for master completion
• Graphs: UDP-C-reuse, UDP-Java-reuse, UDP-Kotlin-reuse, UDP-Kotlin-recreate, etc.
• Have a storyline for UDP packet loss
  • you dont mention things like rate control and congestion control. Blind UDP blasting :-) That is known for 30+ years to be insufficient.
  • Ongoing student work: https://github.com/Tribler/kotlin-ipv8/pull/63
  • Compare unconstrained UDP, EVA {with student fixes}, and spend maximum a few days on getting results from:
  • https://github.com/benhenshaw/quick_udp/tree/master/examples
  • https://bitbucket.org/pjtr/kwik/src/master/
  • https://github.com/xileteam/awesome-quic#cc
• Upcoming sprint: first draft
  • put everything in a single IEEE-format Latex paper
  • Chapters?? intro, problem description, design, experimental setup, performance analysis, related work, conclusions
  • 1-page intro of context. going cashless, CBDC, 81% of Chinese consumers used Alipay, https://hbr.org/2020/09/why-hasnt-apple-pay-replicated-alipays-success
  • 1 or 2 figures. "Performance analysis"

[KoningR]

Sprint log

• Wrote introduction and problem description.
• (Re)read various papers and articles such as parts of the Euro report and Blokzijl's thesis.
• Visited the bank and attended presentations about stable coins and crypto currencies.
• Started filling in IEEE conference template.

Introduction+ProblemDescription-24-05-22.pdf

[synctext]

• First writing of master thesis, 1 lap :checkered_flag:
• Shorter, more powerful sentences
• Avoid merging 2020 report with a 2022 speech into a single sentence
• Example: Digitisation means the European Central Bank has less control on monetary policy matters. Banknotes are 2% in Sweden. Mention counter-party risk. Argument based on stats. Report is a claim of authority argument. https://www.google.com/search?q=post+corona+cash+usage+statistics
• too indirect: Ideally, a cash-like CBDC should be fully decentralised, spendable offline, and have immediate deterministic transaction finality like cash.
• Next sprint, expand text with '1 or 2 figures. "Performance analysis"'

[KoningR]

Sprint log

• Looked into adding QUIC as acknowledgement protocol.

  ○ The verdict: plenty of libraries but only 1 for JVM; not production-ready and poorly documented. Porting one of the other libraries seems like a major struggle (languages: C, Go, Rust).

• Measured the performance of the repo's serializePacket() vs. my own 'faster' version, turned out to not be faster but comparable. Conclusion: do not switch.

  ○ For 10000 simple serializations, with sign took ~567591600ns for the old version and ~571432400 for the new version. Without sign took ~17777300ns for the old version and ~18118100ns for the new.

  Sign:         567591600    571432400
  No sign:   17777300      18118100

• Reformatted the 'practical upperbounds graph' and 'cryptography' graph.

• Wrote a short description of the setup and described the 'upperbounds' graph and the 'cryptograhy' graph.

• Rewrote the introduction and problem description.

• Added references and included them in the text. Added more 'formal' sources such as statistics from DNB.

[KoningR]

Thesis_Eurotoken_27-06-22.pdf

[synctext]

Introduction: real bank insolvency stats. happens all the time: bank got bankrupt.

An important difference is that Blokzijl’s system is balance based and this scenario is token-based.

Problem descriptions are neutral. Not a single Blokzijl reference please. Build up the problem, then discuss timeguard and Blokzijl testing at 1 retail location (with photo) in related work. You can be very direct there: our work build fully upon this prior work. We aim to advance it further on the long road towards mass adoption.

We assume the reader to be familiar with this so-called ’double spending problem’

Explain this in a few lines. Is this the main scientific challenge you work on? Then you use this as the opening sentence in your problem description. Put science at the center, not Wessel :dart:

You central creative idea: Bitcoin provides a partial solution to the double spending problem by severely constraining transaction rates and introducing a consistent global broadcast (known for their failure to scale). Our work is based on similar avoidance, based on the legal system. We believe that without any assumptions the double spending is impossible to solve. An impossibility result is outside the scope of this work, but there has been prior work in this direction. Passport-grade ID.. used to... negative balance... We re-formulate and solve the double spending problem as follows: any transaction validated with your legally-binding digital signature while being offline is guaranteed to have finality for the counter-party with successful dissemination.

If validators are unreachable, Blokzijl’s system allows transactions to be made in a peer-to-peer fashion, deferring finality until the proper validator is available again.

is this section becoming mostly a Wessel tutorial? Solution: keep problem description neutral, add related work, and use a section called: "The Delft Euro" to explain The Wessel System. Sounds more sciency... In your "Architecture and Design" section you can explain why you do 'as-simple-as-possible': serial number, value, signature.

Examples. master thesis core: 10-pages IEEE format with max. 6 figures. (14 figure example https://arxiv.org/pdf/2203.00398.pdf) (15 figure example https://arxiv.org/pdf/2110.11006.pdf). Student report (5 ECTS): "Double spending prevention of digital Euros using a web-of-trust". "industry-grade self-sovereign identity" by Rowdy. You can find the 2021-2022 teaching and exam regulations here {see "Article 3 — The thesis project", note footnote "22)". Following footnote 22 we get to this list. It says nowhere that each needs a separate page, your IEEE format should contain all this}. Please make your thesis as much as possible into the standard scientific IEEE format, reduce your "overhead" pages to 1 cover page only {title+also preface!}. Note: offer your sponsoring governmental institute to list their logo on your front page.

III. EVALUATION In an attempt to improve Blokzijl’s proof-of-concept implementation, we found that it was unsuited for major expansion and opted to rewrite our own reference implementation in Kotlin.

What is the highest level goal? Our evaluation determines to which degree our work could serve as the foundation for the digital Euro. Cardinal requirement is secure offline usage.

"Performance analysis and experiments" section? Are we doing a 10:00am - 12:00am pub-based field experiment? Go beyond cmline digital Euro; superapp?

[synctext]

https://nieuws.ing.nl/nl-NL/216305-ing-nxp-en-samsung-ontwikkelen-nieuwe-manier-van-onderling-betalen-met-mobiele-telefoon

ING is not giving any credits to TUDelft, but they are trying also P2P payments :2nd_place_medal: (deployed 2021 with live IBAN linkage). Requires special radio chip and special Samsung permissions. Good GUI and roadmap to mass deployment, positioning as alternative against ABN Tikkie. Digital Euro needs to match this market-based innovation!

[KoningR]

Sprint log

• Searched for a sensible statistic regarding counterparty risk; determined 'number of failed banks' an inadequate statistic; found little further usable material or sources.
• Debugged the EVA protocol to figure out why the throughput on 1 machine was less than 2 megabytes per second (16 mbps).
  • Attempted: reducing window ACK resend delay, removing encryption per packet, changing window size.
  • One potential reason appears to be that EVA encrypts data packets individually, which we have seen can have a large impact on performance.
  • One potential reason appears to be that EVA signs packets individually and verifying these signatures can have a large impact on performance.
  • After profiling and removing encryption and signatures, throughput was still low.
  • One of the potential reasons appears to be the long delay between resending a window acknowledgement. EVA is not a sliding window but a static window protocol; if a window ACK is lost, the system waits on average 1 second before resending. In the meantime, no packets are sent.
• Measured the throughput of ipv8 because Bambacht speculated EVA throughput was limited due to ipv8. Found that raw ipv8 throughput in the test setup was around 20 megabytes per second (160 mbps). However, throughput dropped massively with encryption enabled, to 5 megabytes per second (40 mbps).
• Learned that the EVA protocol asks for unreceived blocks in 1 packet that can get arbitrarily large. This makes increasing the window size impossible without changing the protocol code.
• From the Python version of EVA: "the protocol is slow by design".
  • Currently debating whether it is even worth the time to attempt to optimise a protocol that is deliberately slow. The result will be, however, that the Eurotoken is slow.
• Discussed with Martijn:
  • He is also looking into a faster acknowledgement system, but for Python.
  • One important factor is congestion control, which EVA does not have.
  • It seems unrealistic to improve upon or build from scratch and acknowledgement protocol with the remaining time and thesis objectives.
  • TL;DR I'm stuck with EVA and am to accept its throughput.
    • The good news: I do not have to worry about acknowledgements anymore.
    • The bad news: Throughput per-phone is low.
    • Optimism: Throughput per-phone can be low as long as the entire system can support a large number of transactions.
• Another issue: explain the choice for using tokens instead of balances.
  • Major drawback: increases required number of transactions due to fixed token value.
  • Advantages (discussed with Martijn): easy auditability.
• Tried to figure out if offline trackability can be done without using tokens. Turns out that using tokens is indeed a straightforward way of tracking offline transactions.
• Got Eurotoken to work with EVA.
  • Rewrote online transaction protocol to account for replay attacks.
• Implemented offline token transaction protocol.
• Double spending detection will be finished within a day.

[synctext]

• https://www.fdic.gov/bank/historical/bank/ Reputable source and also clearly shows exceptional events with mass bank bankruptcies. Please do not spend too much time on this, perfectionism trap.
• Android QUIC libraries are not quickly operational, one last try with something like: https://github.com/VKCOM/KNet ?
  • compare the IPv8+EVA performance
  • Show how a extremely complex implementation performs on equal hardware (phones,laptop)?
• IPv8 + Android works! Build with full feature completeness by @ MattSkala with correctness; performance tuning was always a future milestone.
• reminder: nobodies tasks to clean up the whole superapp repo (upgrade of libs, dead code) (ToDo: 1 month cleanup)
• Know your packet loss, window size, congestion, flow control fundamentals: https://networklessons.com/cisco/ccie-routing-switching-written/tcp-window-size-scaling
• Motivation of entire thesis (see above): we avoid solving the unsolvable double spending problem in offline scenario and mimic as closely as possible cash with our digital cash. (rock solid legal standing, easy to understand, robust integrity checks, solid auditability, and trivially simple due to excellent trade-off with multiple transactions)
• Implemented offline token transaction protocol. and Double spending detection will be finished within a day. Please first document this, discuss the details, process feedback for a superior design, and finally: finalise implementation!
  • both the design and performance analysis sections
  • profile your latest laptop Kotlin cmdline code
  • Large and wide performance picture for next meeting: central to your empirical master thesis work (latex 2-column)
  • no new coding please, after documentation sprint you hopefully can finish major development work
  • Open issue: no wallet! only in-memory storage of EuroCashCoins. Use European Commission EBSI wallet, build-your-own, https://developer.android.com/training/articles/keystore, and current SQLDelight ?

[KoningR]

Sprint Log

• Described the token transaction protocol in a thesis-worthy manner.
• Made diagrams of token transaction protocol.
• Discovered a double spending attack possible in the protocol.
  • ○ The current protocol allows a malicious party to spend the exact same token to the exact same person at a later time. If the receiver of this doubly spent token is unaware of this and continues spending the token, later on when the token is redeemed, they are accused of double spending.
• Discussed with self and others about the possibilities of preventing such an attack.
  • ○ Each client maintains a database of all tokens (last hashes) ever received to prevent the attack.
    • § Drawback: the database can grow near indefinitely and may never be lost.
  • ○ Before making a transaction, the sender first requests a nonce from the receiver which will be included in the token transaction such that double spending cannot be done.
    • § Drawback: The request adds a message roundtrip and the receiver must be online at the time of transacting.
  • ○ The sender includes a timestamp in their transaction. This timestamp must be somewhat synchronized with the clock of the receiving party. For a fixed duration, the receiver will not accept tokens from this specific sender if they contain the same timestamp. This option is currently preferred.
    • § Drawback: The receiver must be online at the time of transacting.
  • Wrote briefly about the choice to use tokens instead of balances.
  • Decided against using FDIC graph in thesis because the data refers to the US and does not distinguish between consumers and business, but most importantly because the ECB does not seem to consider substituting commercial banks as a goal of their CBDC. In fact, quite the opposite, they cannot allow their CBDC to replace commercial banks.
  • Would like to discuss: what do you suggest are proper sizes of token Id, Value, and Nonce? The other fields (public keys and signatures) were already decided in ipv8. Necessary to do before final experiment run.
  • Came up a with a proper setup for a performance analysis:
    • ○ A brief section measuring the performance of the low-level functionality. Do not dedicate an entire figure (even though this work was already done :() but a table. The data says very little because almost all measurements are >125mbps, which is the highest attainable speed in a practical scenario.
    • ○ Perform new measurements for the cryptography section:
      • § Redo cryptography results and differentiate between verifier (on PC) and client (on phone, when implementation works in the app).
      • § Verifier:
        • □ Measure speed of cryptography verification in chunks of the same size as the token protocol uses.
        • □ Measure signing speed in chunks of the same size.
      • § Perhaps measure another native cryptography library on PC to determine throughput loss.
    • ○ Measure IPV8 send performance with and without encryption. Also measure packet loss.
    • ○ Next, measure EVA in different configurations.
      • § Why? Do I redo Bambacht's work then?
      • § Simply copy the 'optimal' configuration used by Bambacht and measure it?
    • ○ Next, implement and perform token performance measurements:
      • § Throughput
      • § Double spending instigator detection.
  • Performed a new cryptography measurement that says more about the system than the old.

[KoningR]

Thesis_Eurotoken 05-09-22.pdf

New cryptography image:

[synctext]

• Your results are quite strong and in-depth. You explored IPC, java, UDP, etc. thus
• solid foundations for: "disaster-proof digital offline Euro - first realisation" as thesis title
  • Problem Description? {solid results, so you can be ambitious}. Can we create a digital Euro with the robustness of traditional Euro coins? We explore a system which could possibly be resilient against deep financial crises with the bankruptcy of multiple system banks and also broader societal infrastructure collapse. The problem is how to create an digital system with robustness equal to coinage. The scope of our thinking is best illustrated as an infrastructure which is inherently robust and self-healing to survive without complete failure for at least 500 years.
  • dual problem description? Bank failures and infrastructure collapse?
  • Focus purely on disaster-proof, robust, offline part?
  • Just CBDC, last bank to fail as single problem to solve?
• "A related work that was important for this thesis is Eurotoken [6]." --> We consider the main prior work to be the first open source Eurotoken prototype and deployment trail wit real money [6]. Most of our design decisions are based upon the strengths and flaws of this work. Cardinal lesson from prior work is that balance-based systems are a poor choice due to their inherent fragility. We believe that token-based architecture are inherently more resilient.
• not token generation, but try to sound scientific: coin minting.
• "token verification throughput" --> as is clearly visible within this figure, scalability is an issue. Performance improvements are possible if required in the future by exploiting additional parallelism. An unknown amount of engineering is required to improve performance beyond 4 CPU threads. With this figure we intend to demonstrate the issue of implementation excellence. To further optimise the digital Euro we require the usage scenarios, performance requirements, and exact workloads.
• "E. Verifier Verification", bad naming
• Distributed verification, federated verification, or decentralised verification? Discuss this design space and motivation your choice.
• "Discovered a double spending attack possible in the protocol", do not build a production-ready implementation. Just leave this one to mentioning in your thesis. Spend your time polishing text and doing best-possible performance analysis.
• Improve Figure 1 to explain to an economist what your designed and build
• stop improving your cmdline implementation and first finish the performance analysis and thesis writing.
• "Perhaps measure another native cryptography library ", no need, you have enough!
• For future please! EVA try to find better block size, low latency cmdline only; try to get to 2 MByte per second.
• Upcoming spint: finish the first 4 pages of your thesis, no new figures, document the 3 figures your have, and leave last 4 pages for future sprints.

[synctext]

This thesis is extremely relevant for society. Only open source and transparent technology, now full frontal competition against Amazon? https://www.ecb.europa.eu/paym/intro/news/html/ecb.mipnews220916.en.html https://worldline.com/en/home/pressroom/press-releases/2022/pr-2022_09_16_01.html

Worldline has been selected for the specific use case “peer-to-peer offline payments” of a digital euro, which focuses
on the payment between individuals.
As a leader in payment services, Worldline can rely on its expertise and assets to build a digital wallet supporting
the physical storage of funds that can be transferred without connectivity. The aim of the prototyping exercises is
to test how well the technology behind a digital euro integrates with various use-cases.
Worldline is sharing the common goal of the ECB and its partners and intends to be an active participants of
payment industry evolution, by contributing to strategic and potentially transformative projects such as the
digital euro. Its entire corporate product portfolio can be leveraged to deliver pilots and facilitate a successful
CBDC roll-out

You can use this as Figure 1 of your thesis to get the reader into a "this is really real" mode of thinking. https://www.ecb.europa.eu/paym/digital_euro/investigation/profuse/shared/files/dedocs/ecb.dedocs220428.en.pdf

[KoningR]

Sprint log

• Changed terms in figures slightly to be more finance-oriented.
• Incorporated feedback of last week.
• Combined existing results of cryptography and UDP throughput to give a more meaningful picture.
• Modified the figures to display the combined results.
• Rewrote problem description to be not-Wessel-oriented.
• Wrote about possible replay attack and possible solutions.
• Decided against leaning too heavily into politics, because I do not feel comfortable with my knowledge on the subject.
• Wrote initial discussion/future work.
• Read the articles posted on this ticket last week; incorporated two sources "to get the reader into a "this is really real" mode of thinking".

[KoningR]

Thesis_Eurotoken_09_26_22.pdf

[synctext]

• Thesis growing to 6 pages :partying_face:
• cash is king argument. Cash is dying in Sweden (leading in EU)
• Clear opening line, for example: Cash is diminishing. We also loose the stability, reliability, and trustworthiness of banknotes and coins with this decline.
• Stronger intro argument example: The decline of cash is eroding the sovereignty of the Euro. The European Central Bank is responsible for cash. Banks create money by lending. Electronic money vastly outnumbers cash in circulation. Almost all economic transaction are becoming vulnerable for bankruptcy of financial actors. The decline of cash leads to systemic system instability.
• This research focuses on exploring offline spending in CBDCs. Various other problems that trouble common CBDC design are discussed in Section VI and/or are left out of scope. ‘Offline spending’ in this context refers to the action of spending a CBDC without having a connection to its network. This is crucial in areas without a reliable internet connection or in case of network/system failure.. Please make the Problem Description about the problem. No disclaimer is first paragraph. Clean and clear description please.
• A prominent example of currency that can be spent offline is cash. Cash, however, has various other drawbacks, which is reflected in its declining usage over the last years [6]. good opening lines, except that the reader should already known this from intro.
• Make the problem the problem: Double spending is the cardinal problem to solve for a disaster-proof offline Euro. The double spending problem is defined as ... For many decades scientists have investigated this unsolved problem. Guaranteed detection of tampering versus prevention. ... ...
• With a toy example or "illustrative example", what is more scientific?
• we assume the reader to be familiar with it, unfriendly. "Addressing double spending is the core of this work".
• "There have been numerous attempts at solving or mitigating the double spending problem.", Bitcoin related work?
• add historical foundational work: "1983 paper, “Blind signatures for untraceable payments,” which led to the creation of short-lived Ecash by his company DigiCash from 1995 to 1998, as well as the invention of blind signatures, a type of digital signature used in Bitcoin and other cryptocurrencies." https://cointelegraph.com/magazine/2022/07/20/crypto-godfather-risked-jail-lifetime-lays-foundations-digital-money
• "Fig. 5. Throughput of various data transfer methods.", keep MBytes on the same axis as before.
• clearer: "Fig. 4. Collapse of cryptographic verification performance when blocks are small. Tokens are 201 Bytes.
• Its not fun, I know. Please finish your thesis upto and including Figure 5. Then you possibly can actually solve our EVA bug and do a curve: EVA bad silly parameters and My Fixes Version 2 MBytes per seconds.
• Plan B which is impossible to fail: few figures showing the impact on EVA of latency, packet loss, and magic parameters settings. Thats much more then Joost Bambacht single figure dump.

[KoningR]

https://www.ecb.europa.eu/paym/digital_euro/investigation/profuse/shared/files/dedocs/ecb.dedocs220422_keymilestones.en.pdf

Slide 2

[synctext]

Australian CBDC Pilot for Digital Finance Innovation

[KoningR]

Sprint log

• Decided to not lean on the 'cash is king' argument. Why? Because that is not the reason for a CBDC. It appears that central banks care little about the practical benefits of using cash: its usage has been in decline for well over a decade, yet a CBDC is only being discussed in the last few years. Then what is the reason? The rise of other payment services and CBDCs.
• Cleaned up thesis document and rewrote (parts of) every section.
• Added various references including Blind Signatures.
• Added reference to Bitcoin paper but did not write about it in related work because it is not really related.
• Read various papers on the developments of e-cash.

(Some) Papers Regarding Digital Cash

• Chaum, Blind signatures for untraceable payments, paper introducing digital cash and blind signatures.
• Canard, Anonymity in transferable e-cash, paper introducing strongly unlinkable e-cash and impossibility results.
• Canard, Divisible e-cash made practical, paper introducing secure divisible e-cash.