Blockchain Engineering - class of 2022 - Team Digital Euro II

[synctext]

Project description: Your task is to {partly} realise a new blockchain-based digital Euro. Delft university has obtained permission to experiment with real digital Euros and live connection to the IBAN bank account system. You can build on this existing open source code. Reading: European Central Bank report on digital Euro, digital Euro master thesis at Delft, the progress report by China Central Bank who is at least five years ahead of Europe. You are free to set your own target feature to focus on, for instance, high transaction rate, offline support, ease of use, etc.

Approach: You will either extend our EuroToken implementation with new functionality, or improve existing functionality. The target feature(s) will be chosen depending on your expertise and interests. Suggestions/ideas are very much appreciated! Please make weekly updates of your progress on this ticket (e.g., with a screenshot). The expected deliverables are:

• A working end-to-end demo of your functionality.
• A small readme.md writeup, describing your product, challenges, and design decisions.
• A merged and reviewed pull request to the superapp repository.

Possible project direction (subject to discussion next meeting): Bitcoin-backed EuroTokens. Currently, EuroTokens are backed by Euro in the central bank network. Your project involves extending support for Bitcoin-backed EuroToken. You will have to modify the Bitcoin mining parameters, set up a private Bitcoin network, and mine some Bitcoin. These Bitcoins can be sent to a validator and exchanged for EuroToken. Give each user 10 EuroToken when joining the app.

References:

• EuroToken: An offline capable Central Bank Digital Currency
• EuroToken implementation in the Superapp
• Various applications inside the superapp are using the EuroToken implementation. See for example the work by Joost on the value transfer application. Relevant issue.

ToDo:

• Compile Superapp from the sources and run in emulator
• Half of the group: investigate the fork of Bitcoin which operational is in Luxury Communism part of Superapp
• Half of group: investigate the digital Euro on Trustchain, part of the Superapp
• Milestone: each team member has 100 BTC on their phone (forked or real) call it "Euros" in the GUI

[synctext]

https://www.dnb.nl/actueel/algemeen-nieuws/dnbulletin-2018/dnb-experimenteert-met-blockchain/
related work: https://www.google.com/search?q=m+cbdc
cashless society, that is the future. Problem: what to do when Internet fails? No Internet == No money. Offline support, double spending, or unlimited debt creation. Offline amount cap?

Can the problem actually be solved. Just take the business risk for disasters? Offline Euro details brainstorm: #6785 (comment)
Also a perfect outcome, with no impact on your grade: make an offline Euro implementation, builtin some countermeasures, show that these are utterly useless and that the security problem is impossible to solve. We+you also learned something.

Problem example : Having your harvest and fishing boats destroyed by a volcano is bad enough, but not being able to access money to buy food makes it a lot worse

[dlieuwasoe]

Planning (milestones per week)

Week 5:

• Add dummy UI options
  • Offline mode alert (dialog)
  • Grey out exchange options
  • Make unconfirmed balance more clear

Week 6:

• Implement proper offline detection
• Spend/Receive cap
• Prevent respending of unconfirmed balance

Week 7:

• NFC payments

Week 8:

• Add report functionality
• Show warning when other user has an unverified ID

Week 9:

• Clone testing
• Findings (document and quantify things that do and do not work)

Week 10:

• Finishing up + presentation

[synctext]

Digital Cash

Possible decision: receiving party is in control and does most of the risk assessment; decides to accept or reject proposed transaction. Possible scope of disaster: "100.000 mensen verliezen hun huis en bezittingen". Current code conducts check at hardcoded central gateway. These are offline (for legal reasons..), so money can not be spent.
Outcome of the course: merged pull request. Prefer to extend existing work, forking an existing app within superapp needs to be motivated. The superapp has lots of technical depth, agreed ✔️ You can also spent time on code coverage and testing. Extensive design space analysis of the double spending problem, maximum 4-5 .md pages.
Use secure element computation inside SIM? https://www.thalesgroup.com/en/markets/digital-identity-and-security/mobile/secure-elements Fun SIM card information extraction. Info from stackoverflow

[leondeklerk]

[leondeklerk]

EuroToken Exchange

Made the EuroToken exchange workable and runnable again. Making sure that you can run this as before you needed undocumented documentation. Fixed various minor issues as well (crashing edge cases). Added documentation on how to run the exchange docker/manually.

[synctext]

• nice that the Tikkie gateway is operational again! (also)
• ability to re-spend unvalidated tokens (user warning)
• Drop-out of two team members.
• repeating Extensive design space analysis of the double spending problem, maximum 4-5 .md pages.
  • Have a in-memory table of public keys and their associated double spending risk (0% upto 100% {previously caught double spender})
  • One possible route to explore is: autonomous building of reputations and sharing of trustworthiness
  • Sharing of financial transaction graph (similar to social graph on Facebook, interest graph on TikTok)
  • If everybody does that, the idea is that a trust-graph emerges
  • social effect? ⚡ low-trust vs. high-trust societies become more unequal??

[leondeklerk]

Repo

Exchange

• Made checkpointing work again
• Add extra QR code containing gateway information
• Documented everything properly in the readme

App

• Removed default hardcoded gateway
• Add the ability to scan and add gateways via their info QR code
• Add to option to pay a request with unverified money
  !

[synctext]

• this work directly conflicts with existing app and Euro III approach. EuroToken App fork or replace?
• team Euro II approach requires the gateway to be online 🤔
• mixing verified and unverified digital Euros is now a goal.
• Unblock the user! This approach enables user to pay with verified Euros while offline, unverified Euros, and a mix.
• lets leave the mixing out of scope.
  • I dont thinks its very useful at this point.
  • Both an verified Euro and unverified Euro can be equally easy be double spend
  • My frame of reference is that the government offers euro.dnb.nl as official gateway
  • brainstorm: gateway in offline mode. we assume a long-term disaster without Internet. Local gateways provide limited protection against double spending. brainstorm2..Or you can only transact if the gateway co-signs the transaction or balance (lots of coding)?
  • Laptop with local wifi storyline, as offline gateway
• simple online test. ping tudelft.nl every 10 seconds or so.

[leondeklerk]

Trust score

• Added the room database objects/converters etc.
• Added a (random) trust score display to the transaction sign screen
• Transactions are no longer automatically signed but require an explicit sign to show the trust score

Offline payments

• Added an extra field in the proposal/acceptance blocks for unverified money
• Payments with unverified money are now correctly validated when there is enough balance available.
  • When there is insufficient balance, however, an error occurs which will be resolved in the upcoming week. Also, the issue of transforming verified tokens to unverified tokens will be taken care of when a transfer is done in offline mode.

[leondeklerk]

apk

[dlieuwasoe]

Paying with unverified tokens

• Now, the receiver has the possibility to specify whether unverified money is accepted.
• If unverified money is not allowed, no transfer proposal block will be created if the sender has a verified balance that is too low.
• In the case that unverified money is allowed by the receiver, there are two possibilities:
  • either the sender does have enough verified money, in which case he/she will automatically pay with verified money,
  • or the sender does not have enough verified money, which is the case where unverified money can be transferred.
• The total balance is calculated by getBalanceForBlock().
• The verified balance is calculated by getVerifiedBalanceForBlock().
• The unverified balance is calculated by subtracting the verified from the unverified balance.
• getVerifiedBalanceForBlock() is modified for this purpose.
  • A new field "unverified" is specified for each proposal block, specifying whether the transfer is done with unverified money.
• The receiver will get a warning when the transfer is performed with unverified money.

[synctext]

Feedback, just before wrapping up this 10 week course.

• this course has no formal report; everything is README.md on Github which documents your code
• report is too general and too abstract, it does not explain what you actually build.
• Easter egg for testing: ConfiD app, tap 5 times on the "2", tap ID card, tap on title "document" five times, you now should have the "Dummy Test" identity (only works in this APK)
• After trying to understand what you exactly build and what is contained inside 47B(yte?) blocks
  • single field is used to store verified and unverified balance
  • blocks are very space-efficient and small
  • What is exactly send across the wire in terms of fields?
• cool trust scores! Please specify the algorithm/architecture and blocks with 10 trust scores?
• Example for PR of readme: 1) https://github.com/Tribler/trustchain-superapp/blob/master/eurotoken/README.MD and also very detailed: 2) https://github.com/Tribler/trustchain-superapp/blob/master/currencyii/README.md
• please ensure to document every new screen and every new significant feature of fix
• APK works and is approved for this course, congrats with getting running code!!! 🎖️

[leondeklerk]

apk

[leondeklerk]

Updated ConfIDapp level README

[devos50]

This work has been completed, closing the issue 👍