Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
synctext opened this issue Sep 8, 2021 · 80 comments
Closed

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

synctext opened this issue Sep 8, 2021 · 80 comments
Assignees
@KoningR
Labels
type: MSc Thesis Work

Comments

@synctext
Copy link
Member

synctext commented Sep 8, 2021 •
edited
Loading

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: #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.
@synctext synctext added this to the Backlog milestone Sep 8, 2021
@KoningR
Copy link

KoningR commented Sep 15, 2021 •
edited
Loading

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
Copy link
Member Author

synctext commented Sep 15, 2021 •
edited
Loading

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
Copy link

KoningR commented Oct 1, 2021 •
edited
Loading

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
Copy link
Member Author

synctext commented Oct 1, 2021 •
edited
Loading

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
Copy link
Member Author

synctext commented Oct 6, 2021 •
edited
Loading

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.

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:

@synctext synctext mentioned this issue Oct 7, 2021
Closed
@KoningR
Copy link

KoningR commented Oct 15, 2021 •
edited
Loading

Sprint log (until 15-10-21)

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

@synctext
Copy link
Member Author

synctext commented Oct 15, 2021 •
edited
Loading

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
Copy link

KoningR commented Nov 2, 2021

  • 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
Copy link
Member Author

synctext commented Nov 2, 2021 •
edited
Loading

  • 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
Copy link

KoningR commented Nov 22, 2021 •
edited
Loading

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
Copy link
Member Author

synctext commented Nov 23, 2021 •
edited
Loading

  • Solid progress with the infrastructure! 🏅
  • 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

@KoningR
Copy link

KoningR commented Dec 6, 2021 •
edited
Loading

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
Copy link
Member Author

synctext commented Dec 7, 2021 •
edited
Loading

Progress:

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 😄 https://github.com/Tribler/kotlin-ipv8/pulls

@KoningR
Copy link

KoningR commented Jan 4, 2022

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.
    • performance plot
  • Made a eurotoken poster to display on campus.
  • Added build instructions to Eurotoken.
  • Made a PR to improve the build instructions of IPv8.

@synctext
Copy link
Member Author

synctext commented Jan 5, 2022 •
edited
Loading

  • first experimental results 🎊 🥳 🎉
  • 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: Generic value transfer primitive - master thesis #6029 (comment)
  • Status today: no "grand design" yet

@synctext
Copy link
Member Author

synctext commented Jan 13, 2022 •
edited
Loading

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
Copy link

KoningR commented Jan 21, 2022 •
edited
Loading

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
Copy link
Member Author

synctext commented Jan 21, 2022 •
edited
Loading

  • 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
    • 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
Copy link

KoningR commented Feb 3, 2022 •
edited
Loading

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.
    - performance plot eva
  • Called with various people at DNB and attended a digital session about DLT.

@synctext
Copy link
Member Author

synctext commented Feb 3, 2022 •
edited
Loading

  • 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 😲 ; linear scalability?)
    1. 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
    1. offline mode (1 week of effort: risk assessment module to inform users)
  • correctness: 25 tx per second for 2nd prototype.

@synctext
Copy link
Member Author

synctext commented Feb 8, 2022

@KoningR
Copy link

KoningR commented Feb 16, 2022 •
edited
Loading

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.
    • eva_total_10000_batch_500
    • eva_total_10000_batch_10000

  • 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.
        • udp_to_desktop

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

  • 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
Copy link
Member Author

synctext commented Feb 17, 2022 •
edited
Loading

  • 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 😮 ? 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 😲 ; 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
Copy link
Member Author

synctext commented Mar 7, 2022 •
edited
Loading

  • 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
Copy link

KoningR commented Mar 7, 2022

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
Copy link

KoningR commented Mar 23, 2022 •
edited
Loading

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.
  • upperbounds
    • 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
Copy link
Member Author

synctext commented Nov 24, 2022 •
edited
Loading

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
Copy link

KoningR commented Nov 25, 2022

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
Copy link

KoningR commented Dec 4, 2022

  • 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
Copy link
Member Author

synctext commented Dec 5, 2022 •
edited
Loading

  • Introduction almost finished. Just a few ToDo's
    • "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.
    • "Meta, which initiated Diem" Mention Facebook (now named Meta)
    • "CBDC to be usable in an offline environment", citation needed.
    • {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.
  • Problem Description
    • {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. "
    • 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"
  • Related work. Nearly thesis ready! Just a few ToDos
    • 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."
    • Subsections are too small, each section has a nice italics topic , remove headings: "B. Transferable and divisible electronic cash"
    • Bitcoin == 2009
    • "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.
    • 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! 🥇
    • 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???)
    • 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 😄 )

@KoningR
Copy link

KoningR commented Dec 15, 2022

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
Copy link

KoningR commented Dec 15, 2022

Thesis_Eurotoken_15_12_22.pdf

@KoningR
Copy link

KoningR commented Dec 15, 2022

@synctext
Copy link
Member Author

synctext commented Dec 16, 2022 •
edited
Loading

  • 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.
  • Problem Description: "Double spending is the action of spending a digital unit of value more than once, illegitimately." 👍 .
  • 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.
  • 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.
  • "All experiments were performed 10 times", the variance of results in depicted in figures
  • "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

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

@KoningR
Copy link

KoningR commented Jan 9, 2023

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
Copy link
Member Author

synctext commented Jan 9, 2023 •
edited
Loading

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 😸
  • 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
Copy link

KoningR commented Jan 26, 2023

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
Copy link
Member Author

synctext commented Jan 27, 2023 •
edited
Loading

  • 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
Copy link

KoningR commented Feb 13, 2023

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_13_02_23.pdf

@synctext
Copy link
Member Author

synctext commented Feb 13, 2023 •
edited
Loading

  • 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
Copy link
Member

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
Copy link

KoningR commented Mar 6, 2023 •
edited
Loading

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
Copy link
Member Author

synctext commented Mar 6, 2023 •
edited
Loading

  • Getting ready for wrapping up thesis, getting polished 👏
  • 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?

This was referenced Mar 6, 2023
Closed
Open
@KoningR
Copy link

KoningR commented Mar 13, 2023

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_13_03_23.pdf

@synctext
Copy link
Member Author

synctext commented Mar 13, 2023 •
edited
Loading

@KoningR
Copy link

KoningR commented Mar 20, 2023

Performance_Analysis_of_an_Offline_Digital_Euro_Prototype_20_03_23.pdf

@synctext
Copy link
Member Author

synctext commented Mar 20, 2023 •
edited
Loading

  • Brief chat with ECB in Amsterdam about our offline Euro work (+10 students in the msc course).
  • 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
Copy link

KoningR commented Mar 20, 2023 •
edited
Loading

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
Copy link

KoningR commented Mar 29, 2023

Performance Analysis of an Offline Digital Euro Prototype.pptx

@synctext
Copy link
Member Author

synctext commented Mar 29, 2023 •
edited
Loading

Comments on slides:

  • Does not meet the minimal requirement for graduation, needs work ⚠️
  • 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
Copy link
Member Author

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

@milahu
Copy link

milahu commented Jun 16, 2023

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.

@synctext synctext mentioned this issue Aug 16, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@KoningR KoningR

Labels
type: MSc Thesis Work
Milestone
No milestone
Development

No branches or pull requests
4 participants
@synctext @milahu @InvictusRMC @KoningR