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]

Thesis_Euro_14_10_22.pdf

[synctext]

You discovered that your thesis field has 30 years of history - 77 page overview Year	System of cybercurrency
1983	Blind signatures by Chaum - 6-page basic idea
1989	digicash http://iwai-k.com/HowToCirculateECash.pdf
1996	e-Gold - real gold bars with ownership tokens
2002	HashCash http://www.hashcash.org/hashcash.pdf
2005	decentralized digital currency by Nick Szabo
2007	bandwidth as a currency by Tribler lab
2008	Bitcoin initial idea https://satoshi.nakamotoinstitute.org/emails/cryptography/1/

• Propose to freeze Cash is Not King storyline in introduction
• Problem description: "Trivial as it may seem, for digital systems this is difficult to realize". This is difficult to understand for readers. You attempt to explain double spending entirely in 1 sentence before. Now you state its hard, but without any explanation. Clearer: a digital coin can be transferred to a new owner by simply duplicating the bytes. A critical difference is that a "move" operation of physical cash does not exist in the digital domain. After duplication we must ensure the original is erased or invalidated.
• Where to explain "double spending"? Intro or problem description. Tutorial style writing in problem description is not desired.
• Problem description: Why have we failed to realise 1983 ideas? After 39 years of research we still do not have digital legal tender. Why has it consistently failed to reach mass uptake? While scientists are obsessive about the system architecture, it seems usability, robustness, privacy, and legal standing are just as important. Focus on offline context, IoT use-cases of solar panels and driving cars which own money, and programmable money. A self-driving car with a real Euro wallet.
• Thesis format for arXiv : https://arxiv.org/pdf/2204.06831.pdf ; Pouwelse (thesis supervisor) plus ~~ master thesis ~~
• "3.A Eurotoken" is too short title (especially compared to next one). subsection with consistency: "Digital Euro deployment trail".
• "The paper describes a novel cryptographic primitive, the ‘blind signature’, which allows parties to sign messages without knowing their contents, thereby being unable to relate their signature to the original message." for easier readability and removal of a 3-comma sentence: 'The paper describes a novel cryptographic primitive, the ‘blind signature’. It allows'...
• "Blind signatures for untraceable payments" you can be more explicit and clear by using the word privacy. You leave it to the reader to deduce this "allows parties to sign messages without knowing their contents". Not clear for readers.
• Section 4. "This research implements a centralized CBDC that allows offline transactions with fixed-value tokens and guarantees retroactive fraud detection." This is the first mentioning of guaranteed retroactive fraud detection, discuss earlier and define.
• Please read more master thesis reports. https://arxiv.org/pdf/2110.11006 Single URL for all similar final reports of the lab

[synctext]

Path to completion of master thesis {eternal shrinking ToDo list}:

• [X] All code is complete, offline clean-slate coin
• [X] Scope is clearly defined as: Implementing Offline Digital Currency on IPv8. Nothing else needs to be included, finished or in the way of graduation. Only minor polish: put the magic word EURO in there, as you graduated with Central Bank backing.
• [ ] Additional measurements, insight in transaction rate, "Section called EVA mystery" {that means you do not bear the reposonsibility of fixing this} , and performance breakdown {IPC, huge cost of crypto}
• [ ] Polish writing and expand from current 6-pages to 8 or 10 pages.
• [ ] DONE, really DONE {pick date, find committee member, make slides, hold talk}

[synctext]

Detailed ToDo list for sections:

• [x] Lets freeze the thesis title ("Implementing Offline Digital Currency on IPv8", IPv8 has to be dropped):
  • "Performance analysis of an offline digital Euro prototype".
• [ ] "Nevertheless, there is demand for this reliability, especially in times of crisis". Essential concluding point is missing that: "CBDC in the form of a digital Euro fix the systemic risk that numerous commercial banks can go bankrupt in a large-scale financial crisis." By design, the digital Euro can't go bankrupt or will be the last to default.
• [ ] {repeating} 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.
• [x] ‘currency substitution’ can be made much clearer. Dramatic opening line: Facebook money, Bitcoin, and other cryptos are threatening to entirely eliminate the role of central banks. Central bank are impacted if Bitcoin became the leading currency for our economy and only taxes are paid in Euro.
• [ ] Problem description clarity: "Double spending is the cardinal problem to solve for a disaster-proof offline Euro. The double spending problem is defined as" ...
• [ ] "thereby ensuring that they are unable to spend it again." see above remark. 5min fix.
• [ ] You should explain double spending once and only once. Remove entire duplicate section "For an illustrative example, we envision a malicious party A who transacts their digital currency to an honest party B.".
• [x] Problem description: offline coins have existed in theory since the publication of the seminal "Chaim blind signatures"[] paper. (1-2 lines only) However: non-transferable! Beyond useless :roll_eyes:
• [x] Problem Description: Part II: "Another problem is that robust realisations are lacking for the numerous theoretical proposal made within the past 39 years. Not only the design is difficult, also the realisation is an extremely difficult engineering challenge."
• [ ] "There have been numerous attempts at solving or mitigating the double spending problem. " suggestion: The double spending problem has never been solved within the offline setting, only within an online context". keep remainder of existing text.
• [ ] Related work: "An early prototype solution from 2005 to the double spending problem relied on trusted computing. This experimental work critically relied on a centralised high-quality secure processor, the IBM 4758 PCI Cryptographic Coprocessor. ref"
• [ ] Related work: numerous theoretical proposals have been made for transferable coins, fungible coins, anonymous coins, and coins with conditional privacy. Many of these historical proposals are not relevant directly for our digital Euro, as we assume some institutional trust.
• [x] {repeating} thesis field has 30 years of history - 77 page overview add Table 1 with 7+ entries
• [x] Related work: move order, first Caum ,etc. then Euro.
• [ ] Performance analysis ideas:
  • We re-visit the mechanism presented in Duplicate Figure 5 of the Bambacht thesis around digital identity. Our digital Euro context differs from this related work.
  • Bambacht: two parameter changed (block,window) and analysed
  • "TABLE III: Parameters that are being tested for optimal execution. The number of iterations have only been used for consistency. In total 56 combinations of parameters have been executed 5 times. Parameter Values Block size (B) 600, 700, 800, 900, 1000, 1100, 1200 [bytes] Window size (W) 16, 32, 48, 64, 80, 96, 112, 128 [blocks]
  • Bambacht: "Fig. 14: Evaluation of the performance of a transfer of 250MB using the optimal window size of 96kB, executed 10 times." Use relative performance numbers instead of absolute number of packets lost.
  • Bambacht: "total loss of about 50 packets in a transfer of over 200.000 packets"
  • Your addition: deeper analysis, also (Bambacht: 600 Bytes was lowest) 201 Byte blocks, and _more optimal_ parameter setting.
  • Try to have a figure to discuss, just repeat Bambacht first.

[synctext]

Outside thesis scope: Strong negative comment reactions to current MinFIN framing of digital Euro (Dutch). https://www.ad.nl/politiek/kaag-belooft-dat-contant-geld-blijft-naast-digitale-euro-maar-er-is-nog-geeneens-een-voorstel~a9d22340/ NRC: https://www.nrc.nl/nieuws/2022/11/24/de-digitale-euro-kan-tot-hele-foute-beslissingen-leiden-2-a4149432 Telegraaf: https://www.telegraaf.nl/nieuws/2117270374/moeten-we-vrezen-voor-de-digitale-euro-straks-bepaalt-de-overheid-waar-jij-je-geld-aan-mag-uitgeven Baudet: https://www.imago-images.com/st/0194864027 TUDelft politician: https://twitter.com/mahiralkaya/status/1424675846065950721

@KoningR predicts it will only get more intense debate:

The Commission expects to publish a proposal for a regulation to establish
and govern essential aspects of the digital euro in the first quarter of 2023.

[KoningR]

Thesis_Eurotoken_25_11_22.pdf

• Which related works are related/important 'enough'? ○ Currently discussed in Related Work section: § First digital cash (Chaum) § First transferable and divisible cash § First 'fair' digital cash (i.e. judicial powers have the possibility of inspection) § Bitcoin § Eurotoken

  ○ Discussed in mentioned presentation (though I do not consider these particularly relevant for my thesis, mostly historically): § E-Gold, Liberty Reserve § B-Cash, HashCash § Zcash, Ethereum, Cardano, Iota

  ○ Ideas for additional related work: § Digital cash with the strongest notion of privacy. § An (algorithmic) stablecoin

• Text-related TODO items not done (yet): ○ Trusted cryptographic coprocessor in Related Work. ○ 7+ related entries from presentation

[KoningR]

• Modified thesis text (see previous post).
• Performed a parameter search over window and block sizes of EVA.
  • Larger block sizes could not be used because EVA would crash.
  • EVA failed so often that this couldn't be automated. Perhaps worth mentioning in thesis text?
  • Performed all measurements again with encryption disabled to measure its impact on performance: encryption does very little.

[synctext]

• [x] Introduction almost finished. Just a few ToDo's
  • [x] "They cannot safeguard a reliability comparable to that of ECB-backed cash.", please make stronger. Just mention 1989 and 2008 events: Every few decades a severe financial crisis erupts which leads to bankruptcy, multiple bank collapses, and risk of a financial system crash.
  • [x] "Meta, which initiated Diem" Mention Facebook (now named Meta)
  • [x] "CBDC to be usable in an offline environment", citation needed.
  • [x] {Add citation} As we both agree: Our offline-first architecture is resilient against failing central servers. The work presented here has a more robust architecture when compared to current commercially deployed systems. Consumers experience regular failings with Internet banking and payments. A consumer watchdog TV program concluded that: "bank systems are unreliable"REF.
• [x] Problem Description
  • [x] {clarity} "Double-spending is defined as the process of making two payments with the same currency or funds in order to deceive the recipient of those funds. "
  • [x] Two approaches are possible, a balanced-based design and a coin-based design. move all details here: "Eurotoken is a balance-based system where individual units of currency are unnamed"
• [x] Related work. Nearly thesis ready! Just a few ToDos
  • [x] Move to the correct subsection: "Up until then, electronic cash had been non-transferable. Nontransferable e-cash can be spent only once, after which it must be redeemed by a trusted authority."
  • [x] Subsections are too small, each section has a nice italics topic , remove headings: "B. Transferable and divisible electronic cash"
  • [x] Bitcoin == 2009
  • [x] "We consider the main prior work for this thesis to be Eurotoken [16], another digital currency implemented on IPv8", more concrete like: 'We consider the main prior work for this thesis to be the first deployed Eurotoken prototype by Delft University of Technology [16], this digital currency is also implemented on IPv8. This first prototype is balance-based, instead of our second coin-based prototype.
  • [x] Wessel,Robbert, Wessel storyline. "Eurotoken is a balance-based system where individual units of currency are unnamed", avoid 1 context switch.
• [ ] Architecture
  • [ ] Figure 1 with explanation of the 5 fields: picture of banknote serial number, picture of "20 Euro", picture of bank director signature.
• [ ] Experiments, this is showing great progress! :1st_place_medal:
  • [ ] Single machine implementation with no networking latency!!!
  • [ ] "Larger block sizes could not be used because EVA would crash."
  • [ ] Missing packets numbers are serialised inside a single UDP packet. This missing packet control traffic grown unbounded. This field is not truncated, a severe programming bug.
  • [ ] {Repeating} Additional measurements, insight in transaction rate, "Section called EVA mystery" {that means you do not bear the responsibility of fixing this} , and performance breakdown {IPC, huge cost of crypto}
  • [ ] No crypto IPv8 70 MByte/s, Crypto IPv8 4 MByte/s, EVA: 1.84 MByte/s
  • [ ] Experiment with plotting of packet losses (10MByte, 50 and 100 MByte files???)
  • [x] is the root cause of failure the BLIND write() of 256 UDP packets into the socket at full rate?
  • [ ] {idea} EVA reliability experiment. The following experiment determines how reliable the EVA protocol implementation is currently. We conducted 10.000 transfers using EVA of a small 4 KByte file. Just 4 UDP payload packets, fixed parameters, window size of 256 Packets (should be enough :smile: )

[KoningR]

List of completed TODOs (previous iteration and current)

• ""Nevertheless, there is demand for this reliability, especially in times of crisis". Essential concluding point is missing that: "CBDC in the form of a digital Euro fix the systemic risk that numerous commercial banks can go bankrupt in a large-scale financial crisis." By design, the digital Euro can't go bankrupt or will be the last to default."

  • CHECK Wrote: "Euro cash is the only public form of money that is directly backed by the ECB. Digital payments are not; they are backed by private parties such as commercial banks. These parties cannot safeguard reliability comparable to that of ECB-backed cash. Nevertheless, there is demand for reliability, especially in times of crisis \cite{ecb_2021_banknotes}. CBDCs can provide this reliability and safeguard consumers against the effects of large-scale bankruptcy of commercial payment providers."

• "{repeating} 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."

  • UNCHECK As discussed previously, the need for a digital Euro is not only due to commercial banks. Moreover, central banks do not intend to replace commercial banks. Therefore, this is not a suited opening argument.
  • Instead, I wrote: "Euro cash is the only public form of money that is directly backed by the ECB . Digital payments are not; they are backed by private parties such as commercial banks. A critical dependence on these parties is eroding the sovereignty of the Euro. They cannot safeguard reliability comparable to that of ECB-backed cash. Nevertheless, there is demand for reliability, especially in times of crisis. In recent history, there have been several financial crises that caused large-scale bankruptcies which consequently impacted consumer's savings (e.g. in 2008). CBDCs can provide reliability and safeguard consumers against the effects of large-scale bankruptcy of commercial payment providers."

• "There have been numerous attempts at solving or mitigating the double spending problem. " suggestion: The double spending problem has never been solved within the offline setting, only within an online context". keep remainder of existing text."

  • CHECK Wrote: "The double spending problem has never been solved in an offline setting, only in an online setting."

• "Related work: "An early prototype solution from 2005 to the double spending problem relied on trusted computing. This experimental work critically relied on a centralised high-quality secure processor, the IBM 4758 PCI Cryptographic Coprocessor. ref""

  • UNCHECK Wrote about different related work.

• "Related work: numerous theoretical proposals have been made for transferable coins, fungible coins, anonymous coins, and coins with conditional privacy. Many of these historical proposals are not relevant directly for our digital Euro, as we assume some institutional trust."

  • CHECK Wrote about different types of e-cash

• ""They cannot safeguard a reliability comparable to that of ECB-backed cash.", please make stronger. Just mention 1989 and 2008 events: Every few decades a severe financial crisis erupts which leads to bankruptcy, multiple bank collapses, and risk of a financial system crash."

  • CHECK Wrote "In recent history, there have been several financial crises that caused large-scale bankruptcies which consequently impacted consumer's savings (e.g. in 2008)."

• ""Meta, which initiated Diem" Mention Facebook (now named Meta)"

  • CHECK Wrote: "An interested commercial party is for instance Meta (formerly Facebook)"

• ""CBDC to be usable in an offline environment", citation needed.

  • CHECK Added a source.

• "{Add citation} As we both agree: Our offline-first architecture is resilient against failing central servers. The work presented here has a more robust architecture when compared to current commercially deployed systems. Consumers experience regular failings with Internet banking and payments. A consumer watchdog TV program concluded that: "bank systems are unreliable"REF."

  • CHECK Wrote: "The currency can be spent offline and guarantees retroactive fraud detection. It is therefore resilient against temporary failure of central servers, unlike many currently deployed systems."
    • UNCHECK I could not find a proper source about regular failings of internet banking and payments. The provided source is Dutch and 10 years old.

• "{clarity} "Double-spending is defined as the process of making two payments with the same currency or funds in order to deceive the recipient of those funds. ""

  • CHECK Wrote: "The main difficulty with implementing offline digital currency is the double spending problem. Double spending is the action of spending a digital unit of value more than once, illegitimately. In a digital environment this is possible because currency is easily duplicated."

• "Two approaches are possible, a balanced-based design and a coin-based design. move all details here: "Eurotoken is a balance-based system where individual units of currency are unnamed""

  • CHECK See Problem Description.

• "Move to the correct subsection: "Up until then, electronic cash had been non-transferable. Nontransferable e-cash can be spent only once, after which it must be redeemed by a trusted authority.""

  • CHECK

• "Subsections are too small, each section has a nice italics topic , remove headings: "B. Transferable and divisible electronic cash""

  • CHECK

• "Bitcoin == 2009"

  • CHECK But 2008*.

• ""We consider the main prior work for this thesis to be Eurotoken [16], another digital currency implemented on IPv8", more concrete like: 'We consider the main prior work for this thesis to be the first deployed Eurotoken prototype by Delft University of Technology [16], this digital currency is also implemented on IPv8. This first prototype is balance-based, instead of our second coin-based prototype."

  • CHECK Wrote: "We consider the main prior work for this thesis to be the first Eurotoken prototype by Delft University of Technology. This digital currency is also implemented on IPv8.". However, moved the comparison between balance- and coin-based to the end of the section to avoid unnecessary context switches.

• "Wessel,Robbert, Wessel storyline. "Eurotoken is a balance-based system where individual units of currency are unnamed", avoid 1 context switch."

  • CHECK

[KoningR]

Thesis_Eurotoken_15_12_22.pdf

[KoningR]

[synctext]

• [ ] interesting discussion Add the current societal debate. This is nothing new: see debate on too big to fail and remove the consumer involvement, make it a normal industry. However, a critique on the current approach is that nothing essential might change. It's still the commercial bank who will operate the digital Euro, just now with the backing of the central bank. Central banks do not have the desired expertise, willingness, and infrastructure to support consumers with digital Euro usage.
• [X] Problem Description: "Double spending is the action of spending a digital unit of value more than once, illegitimately." :+1: .
• [ ] Overspending storyline (perhaps after the token paragraph). The key problem is that any such token can easily be duplicated, leading to double spending. The central bank of Sweden has even explored using quantum computing for its no-cloning theorem. On possible direction to address this problem is transposing it into an overspending problem. If all spending is irrefutable it is possible for people to have a negative balance. This is similar to well documented credit card usage amongst young adults and easy debt buildup. Numerous researchers have attempted to prevent double spending with technical means. This might even be impossible in the offline case. Therefore the problem can be reformulated as a legal problem, thus problem becomes creating a system which guarantees that overspending is irrefutable. Double spending is re-defined as overspending.
• [ ] Problem description: around the 39 years content; "public support is another essential element, but out of scope for our efforts presented here."
• [ ] Please use more precise term: "monetary authority", not merely authority.
• [x] Performance analysis "The core idea is that by stripping the implementation of all other factors". No intro that you build it. First line should be: we prototyped our design and present a detailed analysis of the performance characteristics.
• [x] "All experiments were performed 10 times", the variance of results in depicted in figures
• [x] "E. Price Stability", "It is fundamental for a European CBDC to be tethered in value to the Euro". Explicitly mention, price stability is out of scope. Move to earlier section; design?
• [ ] "VI. Conclusion and future work", please cut in half or more. Short and dense.
• [ ] Sending Socket Size experiment
  • [X] With a 256 packet window size, the sending immediately does a write write() of 1200 Byte x 256 = 307.2 kilobytes into the OS outgoing socket buffer. This is likely to overflow and lead to packet loss (e.g. the 7.61% in above figure???)
  • "Linux provides the files /proc/net/udp and /proc/net/udp6, which lists all open UDP sockets (for IPv4 and IPv6, respectively). In both of them, the columns tx_queue and rx_queue show the outgoing and incoming queues in bytes."
  • [ ] Radical experiment: wait() until their is no pending data in the UDP socket using the only available Linux system call for that. You can't get the waiting queue. Busy Polling() wait().
  • [ ] Fix at 16 UDP packets of 1k (e.g. 16k socket buffer) (8,16,32,64,128,256) short experiment, see impact
  • [ ] Try to maximize or double within your OS
  • [ ] Do a hacky repair. Current implementation is blind to the socket overflow. Just wait() for the buffer to have space for 1 UDP packet to fit.

Upcoming sprint: please process all my comments. Then switch to writing new text or new measurements.

[KoningR]

List of completed TODOs

• Solved the 'EVA mystery'. Loss of performance is due to buffer overflows.

  • The following plots show a steep decline in throughput for large window sizes and a corresponding increase in packet loss. When the buffers are increased, throughput increases and packet loss diminishes.
  • Regarding parameters: More than ~1200 bytes per block is not supported by EVA and Kotlin-IPv8. More than 256 blocks per window or buffer sizes smaller than 100k bytes caused EVA to crash too often to perform proper measurements.
  • 
  • 
  • 

• Fixed a race condition that caused EVA to fail frequently; it is now stable enough to perform N repetitions subsequently without human intervention (restarts etc.).

  • Can I write about this in my thesis?
  • The protocol would execute its send function sendScheduled() both from its internal scheduler as well as when a transfer was finished. It would occur that sendScheduled() executed from multiple threads simultaneously and thereby start multiple simultaneous transfers. The receiving client would then throw an error, as it can only handle a single transfer at a time. Usually, this error would go unnoticed because the internal scheduler would have a frequency that is low, such that the chances of the problem occurring are low. When doing a performance analysis however, this frequency needs to be increased massively to stabilize results.

• Regarding thesis text (Thesis_Eurotoken_09_01_22.pdf)
  • Offline First
    • Mentioned 'Offline First' at the end of the introduction. However, could not find a proper source discussing the paradigm. Opting to remove it if no proper source can be found.
  • Overspending storyline
    • Discussing the transposition of the double spending problem into an overspending problem is not relevant for my thesis because current implementation raises a warning when double spending occurs and does not properly support 'overspending' i.e. spending with future funds.
  • Public support
    • Mentioned public support at the end of the problem description.
  • (Monetary) authority
    • Changed 'authority' to 'monetary authority' in the introduction, problem description, and related work sections. In the design and evaluation sections we still refer to 'authority' for brevity but we have included a small disclaimer in the opening paragraph.
  • Performance analysis
    • Described that we built a prototype.
  • Price stability
    • Moved to Related Work and mentioned out of scope.
  • Conclusion and Future Work
    • Wrote a new conclusion and discussed future work briefly.
  • Figure 1
    • Recreated Figure 1 with less technical detail but more clarity.

[synctext]

Thesis review remarks:

• [ ] "An additional lesson from the literature is that robust realisations are lacking for numerous theoretical proposals made over the last 39 years." mention actual topic (coins, digital currency , balance, OR accounts, etc.)
• [ ] "additional lesson from the literature". rewriting in a problem description style: The problem is not only devising theoretical algorithms for digital currency, implementing them is also known to be just as hard.
• [ ] Magic find: encryption slows down data transfer and is an unintentional flow control measure :smile_cat:
• [ ] experiments with EVA are with OS system-wide increased socket sizes, 425KiB!
• [ ] "We prototyped the design described in Section IV on the IPv8 protocol stack".
  • you could write 1 page on implementation details and all field which add up to 201 Bytes, lines of code for 8-12 main features in a table.
  • you could mention: our design is deliberately simple to make it robust and well understood. Our digital Euro work is designed to be a research prototype for informing political decisions. An implementation suitable for deployment is out of scope of this master thesis.
• [ ] ToDo: contact TUDelft professors for thesis grading committee. For instance, low-level protocol experts like Marco

[KoningR]

Log

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_26_01_23.pdf

List of completed TODOs

• Finished most of what we discussed last sprint.
• Wrote an Implementation section and LoC table.
• Wrote EVA section.
• Did new experiments and plots; token crypto throughput for increasing offline recipients; end-to-end token throughput.
• Redid all measurements for greater accuracy.
• Included EVA in data transfer plot.
• Modified Introduction.
• Determined thesis grading committee.

Not completed

• ""An additional lesson from the literature is that robust realisations are lacking for numerous theoretical proposals made over the last 39 years." mention actual topic (coins, digital currency , balance, OR accounts, etc.)"
• ""additional lesson from the literature". rewriting in a problem description style: The problem is not only devising theoretical algorithms for digital currency, implementing them is also known to be just as hard."
• Wrap up code and make PR.

[synctext]

• Making solid thesis progress. Good to read!
• Good idea. Like: Evaluated three cryptographic libraries within this thesis. This section shows the vast performance superiority of the Libsodium, compared to others. We believe the singleton programming pattern is responsible for the lower performance within Bouncycastle and I2P (invisible Internet project, home made crypto).
• Try to get multiple people to provide feedback on structure and writing.
• Implementation section a bit short. NAT-box, tripple IPv8 explain, talk about TCP and FTP, why we need to do user-space file transfers, and complexity of solving this
• B. Data Transfer reader needs to understand what you did. pip, kotlin, etc. Tripple this section.
• we expect per-packet encryption to also be a bottleneck. Clear message that its about crypto of each UDP packet individually.
• We performed our measurements on a single machine to eliminate external noise. between two processes on single machine.
• EVA: mention actual MBytes throughputs in text, explain issues.
• Sprint goal: thesis draft

[KoningR]

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_13_02_23.pdf

[synctext]

• D. Tokens, more descriptive titles versus token and EVA.
• Fig. 7. Throughput (left) and packet loss (right) for various configurations of EVA. try making this into a readable figure. For instance, just with 5 lines for each of the block-sizes.
• Insight into why its not feeling polished
  • Fig. 2. The authority’s double spending detection mechanism boxplot style
  • TABLE I FACETS OF PROTOTYPE AND ANALYSIS Table style
  • Fig. 3. The benefits of parallelism diminish quickly Organge blue style figure
  • Fig. 4. Throughput of cryptographic signing and verification collapses for small data sizes. purple lines without certainty intervals
  • Fig. 6. Throughput of various data transfer methods. interval plot, now sideways
  • Fig. 8. Throughput of EVA for various UDP buffer sizes. heatmap style
• Buffer overflow loss versus packet loss.
• Repeating 106496 bytes inside Figure 8.
• The 307 KByte burst at the start (256 blocks) is not fixed (no flow control, no rate control). With 425KByte buffer setting we expect 0% loss, not 0.01% (re-transmitted?).
• Not a fan of tables, Figure says more. Fig. 9. End-to-end throughput in an online setting promising experiment. First plot an architecture and measurement points of this experiment? Coin minting, 1st client, etc. (1st hop?) (de-clutter?). Token destruction: complete life-cycle?

[InvictusRMC]

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_20_02_23.pdf

Hi Robbert,

I think you're well on your way. I've written some of my thoughts down and highlighted some typos. I think your work could benefit from something like a system & threat model section, as it is not clear what kind of network topology is used or what (malicious) actors are capable of. Good luck!

[KoningR]

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_06_03_23.pdf

• Also made two PRs for improvements to Kotlin-IPv8 here and here.

[synctext]

• Getting ready for wrapping up thesis, getting polished :clap:
• Kotlin-IPv8 was unmaintained for a year. Instead of Quick or uTP we first need to get a 42 years old TFTP protocol dubbed EVA operational {with sliding window extension}.
• Fig. 3. The benefits of parallelism diminish quickly You have 1.2 CPU's ?
• prototype is deliberately minimalist Explain {more} why?
• Add: We selected one of the standard networking overlays available on Android. For instance, the libp2p overlay forms the foundation for the IPFS network [https://doi.org/10.1145/3493426.3493822] See Kotlin-IPv8 overview and tutorial [REFs].
• Fig. 1. Graphical representation of a token. Please add minting stage. Add the word receiver, easier to understand? Public key of receiver is missing?

[KoningR]

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_13_03_23.pdf

[synctext]

• :1st_place_medal: Your thesis draft is getting ready to defend.
  • Authority signs and sends in Table 1. Explain each row with at least one sentence.
  • reduce the negativity of the infinite growing signatures
  • average lifespan of Euro banknotes are: 5.5 years for the €10 note.
  • Replacing bits is much less cost versus fraud-resiliant banknotes.
  • like "As noted within the design section, each change of ownership adds 138 bytes to an offline Euro."
• Political traction of CBDC, digital Euro, and helicopter money. EU Commissioner level, Speech by Commissioner McGuinness at the European Parliamentary Financial Services Forum on a digital euro She said: "With the digital euro, we could have an easy-to-use option that could work offline." -8 March 2023, Brussels, EU Commissioner McGuinness
• Kotlin cmdline foundational code
  • 2 weeks for an ugly, quick prototype
  • needs to be Android Kotlin
  • replace the existing core in the Bambacht, Wessel,Matt code and existing user interface, QR code linkage
  • Already fully based on IPv8
  • ready for wallet-to-wallet communication
  • No EBSI identity linkage
• please test for breakage and compatibility https://github.com/Tribler/kotlin-ipv8/pull/63
• :rocket: you fixed stuff :rocket: 97% faster ACK serialisation
  • Example performance analysis using flame graphs. Work from my glory days with Netflix co-author.
  • Grand final figure; example, interactive: https://queue.acm.org/downloads/2016/Gregg4.svg (Figure 8 in https://github.com/Tribler/tribler/files/10930457/MSc_final.27.pdf)

[KoningR]

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_20_03_23.pdf

[synctext]

• Brief chat with ECB in Amsterdam about our offline Euro work (+10 students in the msc course).
  • Program Director Digital Euro, European Central Bank
  • Event: https://toekomstbetalingsverkeer.nl/sprekers/
• Made flame graph, but not yet included because it duplicates the 'IPv8 dominates' messages.
• Please include a flame graph, it strengthens the message. Add thesis depth
• D. End-to-end Token Throughput, then "E. Flame graph analysis". Prior analysis of transactions per second indicates 'Kotlin-IPv8' dominates performance. We conducted a flame graph analysis which confirms this observation.
• Problem description. Methodology: Investigate, implement and evaluate architectural approaches for the offline digital Euro until it works. Double spending is difficult to solve for account-based approaches, we thoroughly investigate token-based approaches for as-secure-as-possible offline Euro architectures.
• thesis presentation storytelling: experimental approach

[KoningR]

Very brief minimal content of presentation:

• Short introduction
  • ECB to Kotlin offline
  • Skip most of problem description & related work
    • Elaborate on token formatting (section 3)
    • Figure 1, token format
    • Emphasize double spending prevention
    • Elaborate on performance analysis
    • Figure 2 Loss of performance in Kotlin, EVA (figure 7)

[KoningR]

Performance Analysis of an Offline Digital Euro Prototype.pptx

[synctext]

Comments on slides:

• Does not meet the minimal requirement for graduation, needs work :warning:
• unattractive, no illustrations, messy bullet points, "introduction (1/2)"
• prior example of thesis presentation
• No clean "scientific problem" and lacks definition
  • offline digital Euro
  • We want to build an offline digital currency. == engineering == not scientific
  • Prerequisite: Kotlin-IPv8. == engineering == not scientific; reformulate: "maximise public support and usage"
  • Offline e-cash literature says: explore suitable architectures (token vs. account)
  • money is mission-critical infrastructure
  • deep understanding of digital Euro performance
  • no experimentation with money is allowed
• Design & Architecture (2/3) that slides contains 2 'lonely bullets' and 3 other bullets. re-structure
• EVA Acknowledgement Protocol Throughput small font suddenly
• "experimental results": overview slide, goal, why, what, how
• Performance Analysis of Kotlin-IPv8 "key learnings" slide?

[synctext]

Latest ECB wallet report Latest report by Dutch minister to parliament May 2023

[milahu]

how is CBDC related to tribler?

towards proven technology, ready for large-scale deployment

CBDC is orthogonal to tribler's goal of censorship-resistance. CBDC is a tool for totalitarian control and censorship, similar to china's social credit score system. CBDC is NOT a blockchain-based cryptocurrency like bitcoin/monero/zerocoin/..., but just a different version of fiat money.

they are trying to impose CBDC by force, but at least in africa (nigeria), people are waking up.