Blockchain Engineering - class of 2022 - Team Digital Euro I

[devos50]

Project description: Your task is to {partly} realize 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 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.

[devos50]

Meeting notes 21-02-21:

Possible directions:

• Scalability -> analyse the thoughput of the EuroToken, what are the bottlenecks?
• Security -> try to hack it? (High-risk, high reward, probably unsuitable for incremental progress).
• Cryptobacked EuroTokens, go beyond support for Euro-based currencies. Bitcoin-backed stable coins?
• Proof-of-Burn: burn crytocurrencies.
• Improve support for merchants. Connected to usability.
• Recurring payments?

Tasks for this week:

• Compile the Superapp from source, setup development environment.
• Explore the EuroToken source code, get it up and running.
• Look at the value transfer app.
• Describe a project proposal that we can discuss during the next meeting. Focus on something that can be implemented incrementally (weekly progress).

[deepweeb]

Dear Martijn, we have researched the EuroToken and has come with the following topic, would you kindly take a look at it and discuss it with us tomorrow?
Feedbacks from you are appreciated!

Topic 1:
Implement NFC payment peer-2-peer and most importantly, at retailers. i.e., make it possible to pay with EuroToken at shops that accept NFC payments.
Useful sources:
https://nfc-forum.org/
https://github.com/nmssalman/kotlin-nfc-sample
https://developer.android.com/guide/topics/connectivity/nfc/advanced-nfc
Planning:
Week 1:

• Design structure of EuroToken NFC payment
• Research if offline NFC payments are possible for EuroToken
• Identify data/resources needed to perform an NFC payment peer-2-peer
• Identify data/resources needed to perform an NFC payment to retailer
  Week 2:
• Implement NFC payment peer-2-peer
• Add option/UI in EuroToken app for NFC requests and sending
• Identify data/resources needed to perform an NFC payment to retailer
  Week 3:
• Implement NFC payment peer-2-peer
• Implement NFC payment in retail
  Week 4:
• Implement NFC payment in retail
  Week 5:
• Implement NFC payment in retail
• Implement offline NFC payments
  Week 6:
• Convert all euros to EuroTokens and close bank account

Topic 2:
The payment request system (betaalverzoek) has been increasingly popular among the population due to its simplicity in payment request and management. Implement payment request with instant payment validation feature would potentially enhance the usability of the EuroToken among the consumers. This feature is widely implemented, however it has not been developed into the SuperApp yet.

Additional extra would be to develop a payment request system where the requester can choose to receive the payment in current Euros (IBAN) or the EuroToken. The same feature should also be enabled for the payer, enabling payment in both EuroToken or Bank.

Useful sources:
https://www.quotenet.nl/financien/cryptocurrency/a38471685/nooit-meer-een-tikkie-whatsapp-begint-pilot-met-crypto-betalingen/
https://www.w3.org/TR/payment-request/

Planning:
Week 1:

• Design structure of the payment request system of EuroToken
• Research if offline payment request are possible for EuroToken
• Identify data/resources needed to perform a payment request
  Week 2:
• Implement payment request system of EuroToken
• Add option/UI in EuroToken app for payment requests and sending
• Identify data/resources needed to validate the payment request
  Week 3:
• Implement payment request system of EuroToken
• Implement validator to verify payment request transactions
  Week 4:
• Extra feature
  Week 5:
• Extra feature
  Week 6:
• Convert all euros to EuroTokens and close bank account

Deze plan is best wel meer simpel dan die van NFC (dus kan afgewezen worden), maar aangezien dit feature heel erg populair is (bijv. Tikkie) krijgen wij misschien wel de kans dit te implementeren.

Topic 3:
Description: For any transaction to be valid, the payer has to prove that they received these funds in the past. In order to solve this problem all transactions received in the past are digitally signed by the sender. The signature of the sender on the transaction is included in each block which can be verified and compared with the block contents. But in order to do this verification the receiver needs to access the block content (e.g., amount and balance) which can be sensitive.
Task: Implement Homomorphic encryption to enable validating the block history of a peer without revealing the actual data in the block (amount and balance). Some helpful resources:

• M. van Dijk, C. Gentry, S. Halevi, and V. Vaikuntanathan, “Fully Homomorphic Encryption over the Integers”
• F. Armknecht, C. Boyd, C. Carr, A. Jaschke, and C. A. Reuter, “A Guide to Fully Homomorphic Encryption”

Topic 4:
Description: The sender must not have already spent the money (e.g, by creating a fork of their chain). Example: An adversary, lets call her Eve, will perform a legitimate transaction with Alice. This transaction will get recorded in the chain of Alice, as well as in the chain of Eve. If Eve now wants to spend this balance again with Bob, she cannot simply add the new transaction to her chain. Before Bob accepts a transaction he will request all required blocks to validate that Eve received this money in the past. Eve now has to hide the transaction with Alice in order to make Bob believe the balance is still available. When Eve and Bob then create a new transaction, the proposal block of Eve, will be in the same place as the block with Alice would be. They will both refer to the same “previous” transaction, thus creating a fork in her chain.
Current Solution: Put the receiver at risk while a transaction is not finalized (finalizing a transaction requires network access). Further do not allow non-finalised transactions to be sent again.
Task: Doing research and risk analysis about support for indefinite offline re-spending and implementing a protocol to support the idea (challenging). Some helpful resources:

Unspent transaction output (UTXO): https://en.wikipedia.org/wiki/Unspent_transaction_output

Planning:
2 or 3 people can work on the first problem. The others can work on the second problem.

Breaking down of tasks example:
Problem1:
Research Homomorphic encryption methods and see which one is suitable for our problem.
Implement the Fully Homomorphism.
Integrate FH into EuroToken.
Problem2:
Research the possible solution to the problem
Research if UTXO model can reduce the risk
Is the model compatible with EuroToken?
Implement the model in the EuroToken

[devos50]

Meeting notes 02-03-2022:

• Discussed various directions of the projects.
• Topics II (Betaalverzoek with multiple currencies) and IV (double-spend detection/prevention) seem the most promising.
• Requires diving into the technical specifications of the EuroToken, and finding out if double-spending is a viable direction for the remainder of this project (6 weeks left).
• Recommended to have a look at the thesis of Wessel.
• If you’re going to work on the Betaalverzoek, please integrate it in the value transfer app.
• Hybrid approach? Put some trust in the P2P part of the EuroToken network.
• Put the final proposal of the project on your ticket.

[deepweeb]

Hi, we have some unexpected delays in writing the combined proposal of topics II and IV (Since we also diving into the technical specifications), so it's basically also a feasibility study for the project as well (since you have approved the direction we are going). We are working hard on it and will send in the proposal latest Sunday night. Have a nice weekend!

[deepweeb]

Final Proposal (Topic 2)
The payment request system (betaalverzoek) has been increasingly popular among the population due to its simplicity in payment request and management. Implementing payment requests with an instant payment validation feature would potentially enhance the usability of the EuroToken among the consumers. This feature is widely implemented, however, it has not been developed into the SuperApp yet.

Additional extra would be to develop a payment request system where the requester can choose to receive the payment in current Euros (IBAN) or the EuroToken. The same feature should also be enabled for the payer, enabling payment in both EuroToken and Euros.

Implementation Flow:

Apart from the payment request creation/ paying interface, the process of paying through a payment request can be simplified with the following example:

Both Alice & Bob have the SuperApp installed on their smartphones and their wallets initialized. Alice wants to ask Bob to pay a certain amount of money, she creates a payment request (link) and shares it with Bob through a popular communication app (Whatsapp, Telegram, SMS).

Bob clicks on the payment request link to pay and there are 4 main scenarios:

(1)Alice wants EuroToken - Bob has EuroToken
(2)Alice wants EuroToken - Bob has Euros
(3)Alice wants Euros - Bob has EuroToken
(4)Alive wants Euros - Bob has Euros (Will not be done)

Scenario (1) requires:
(a) Payment request creation/ payment interface for Alice to create request and Bob to pay with his EuroToken wallet (unimplemented in SuperApp)
(b) Existing EuroToken wallet to wallet transfer mechanism as back-end (implemented)

Scenario (2) requires:
(a) Payment request interface for Bob to pay to the EuroToken Gateway's bank account (unimplemented)
(b) Modified Tokenization flow where Bob creates a new transaction with the Exchange not with his wallet as a receiver but WITH Alice's wallet as receiver (unimplemented, requires modifying of exchange behavior to send to extra "receiver field" in the message and not to sender public key)
(c) Interface verifies deposit and mark payment request as paid and notifies Alice (unimplemented & extra)

Scenario (3) requires:
(a) Payment request interface for Bob to send a transaction (payment) to the EuroToken Gateway exchange's wallet with that transaction including IBAN of Alice, which is to be extracted from the request payment (unimplemented)

Scenario (4) (Will not be done) requires:
(a) Existing Bank to Bank Euros transfer mechanism (implemented)

In addition to above-mentioned feature, we will also implement:

Multi-payer Payment Request
In addition, like Tikkie, Alice can request multiple people to pay at the same time. These features require the SuperApp to verifies and list all the participants which received the payment request and assign a green checkmark to those who have paid in one user-friendly overview on the requester's side of the app. This should be done for all scenarios (1), (2), and (3)

Above mentioned multi-currency payment features will massively contribute to the adoption of EuroToken, enabling interoperability between crypto users and non-crypto users. Imagine Alice needed the crypto for decentralized projects and wants to get paid in EuroToken while Bob is not interested in having the EuroToken.

Planning:

Week 1: Preparation & Tasks Division 
- Research the exact implementation requirements
- Define programming tasks on GitLab
	
Week 2:  Basic Interface
- Implement basic interface for payment to fulfill Scenario (1) (with SuperApp installed)

Week 3: Implementation of EUR -> EURT (Tokenisation)
-Implementation for Scenario (2)

Week 4: Implementation of EURT -> EUR (Detokenization)
-Implementation for Scenario (3) 
-Testing Scenario (2) and (3)

Week 5: Multi-payer Payment Request
-Implementing Multi-payer payment request feature

Week 6: Finalization
- Finalizing our work, merge
- Prepare for the final presentation

We will implement the payment request into the value transfer app.

Note for topic IV:
We decided not to choose topic IV because it requires a lot more research than implementation. Since we are required to implement something to get a grade we could end up with no implementation. Furthermore, it is not straightforward how to have incremental progress. With the final proposal, you can expect a fully done implementation and merged, of course ;-)

Thanks,
The Team

[devos50]

Thanks for your extensive proposal. Overall, it looks good! Considering topic IV out of scope is fine by me. Seems that there is substantial work required to get topic II implemented.

Please focus on getting one feature done before moving to the other one (e.g., tested, and possibly even merged). Given that there are only six weeks left, please do not spend too much time in the conceptual phase and start implementing something.

With the final proposal, you can expect a fully done implementation and merged, of course ;-)

Looking forward to that!

[devos50]

Meeting notes 09-03-2022:

• Proposal has been made - direction has been fixed.
• Trello board has been made, although on Gitlab. Please move this to Github so we have everything in one place.
• Value transfer app has been merged, so you can build upon it.
• Please read the paper on the value transfer app.
• Think about how to test your implementation. Unit tests? Integration test?
• Scenario 2 will be implemented next, Alice wants to be paid in EuroToken, Bob has Euros.
• Installation instructions to setup a gateway can be found here.

Milestones for next sprint:

• Explore the value transfer app logic.
• Start implementing scenario I and II. Aim for a demo of scenario II.

[devos50]

Meeting notes 16-03-2022:

• Scenario I has been implemented 👏
• The payment request is encoded in an App URL - clicking this URL opens the Superapp and allows the receiver of the request to pay. There is a separate screen for that. 🎉
• Javascript issues regarding running the gateway frontend.
• Try to connect your gateway backend to the superapp.
• Looked a bit into testing. There are several platforms suitable for higher level test.
• Get in touch with Blockchain Engineering - class of 2022 - Team Digital Euro III #6785 to ask for assistance with getting the gateway up and running?

Goals for next week:

• Get the gateway up and running. Demo scenario II: Pay Euro to EuroToken.

[devos50]

@venetheo @mkhattat @deepweeb @WhyW0rry @Nieuwlaar Team digital Euro II got the gateway up and running: #6784 (comment). Please consider contacting them to get some assistance in building the front-end 👍

[deepweeb]

@devos50 We got the gateway running this weekend (by ourselves). As you can see here, we are profiting from the government.

And here's a picture regarding the progress last time (Someone forgot to click submit):

We are working on putting everything together and finalizing scenario 2. We are looking forward to implementing (scenario 3) and merging right after the demo.

After that we would like to discuss extra feature and potentially other way to improve the Eurotoken Usability/ Safety

[devos50]

Meeting notes 23-03-2022:

• Demo of scenario I (EuroToken <-> EuroTOoken) successful! 🎉 👏.
• Demo of Scenario II also works!! 🎉 👏.
• Challenges:
  • There is a critical dependency on IP/port combination that can cause the process to fail if the network interface of a user changes during operation.
  • Should the gateway do bookkeeping of the IP/ports of users?
  • The amount of money sent in the money request is encoded in the link being shared. Is there a better way to handle this?
• Code is not ready yet for PR + review.
• Next step: work on Scenario III. Money request for Euro, pay with EuroToken.
• Think about quality assurance. How will you test your code? Unit test? Integration tests? Combinations of them?
• Biggest challenge: working with undocumented code, big project organisation.
• How close is this project to actual blockchain?
• How can one commit fraud with this scheme? Sending around fake/spoofed links? Please include this in your README.md.

For the next sprint:

• Start cleaning up/organising the code so you can open a PR and get things reviewed.
  • This includes quality assurance.
• Start working on Scenario III. Demo it next week?

[devos50]

Meeting notes 31-03-2022:

• Link that is shared is enhanced with a digital signature + public key of the signer. The recipient of the link verifies the authenticity of the link.
• There is no guarantee that the person behind the public key is the intended beneficiary. How can we address that? Maybe link to the strong identity of the public key in the app?
• Demo of scenario III 🎉 👏 EuroToken-based part seems to work. The last part (ensuring that the Euros arrive in the bank account of the beneficiary).

Goals for the next (last) sprint:

• Get the final part of the demo up and running.
• Finish the testing infrastructure (unit tests/integration test).
• Link validation at the receiver side (shouldn’t be too much work).
• Open a PR for review, both to the Superapp repository and the Stablecoin repository.

[deepweeb]

Hi Martijn,

What we did this week:

• Finalized all 3 scenarios (all scenarios works)
• Changed the way we include information in the link in scenario 2
• Finished the link signing and validation
• Added various unit tests
• Started working on integration tests
• Updated the Readme.md
• Opened the Pull Requests

We are (almost )ready for the final demo ;)

[devos50]

Meeting notes 07-04-22:

• Currently wrapping up.
• Made a modification to the generation of the payment request link - it now contains a payment ID that is generated by the gateway.
• Please do not replace the master README.md, put your README.md in the directory where your source code is located. Suggestion for name: “README-eurotoken-payment-request.md”.
• Please make sure that the tests are passing - the current androidManifest.xml is broken, see here.
• Clean up your commit history into one or two logical commits (e.g., one with the source code and another one that adds the README.md).
• Having E2E integration tests that are executed automatically is quite challenging. Suggestion: split the testing responsibilities, e.g., add some tests in the superapp test mock the exchange, and add some tests in the exchange code that mock the application.
• !!! avoid copying figures from other people’s work without citations! Suggestion: re-do the figure in your README.md and highlight on your changes.
• README.md should answer the question: why were particular design decisions made, e.g., including the payment ID in the payment request link.
• Would be great to get your hands on a working API key so you can give the full E2E demo!
• No logical changes were required to the gateway source code. REST API of the gateway was sufficient enough to get things done. 👏 - Also open a PR to the gateway with your (minor) change regarding transaction validation.

[deepweeb]

Hi Martijn,
This week we were finalizing our implementation and working on the various points you have mentioned previously. However, everyone has been having exams this week (And I have to resit Biometric exam at 14:00), hence I decided to propose not meet today but rather show you the end demo next week Wednesday. Would that be alright with you?

[devos50]

@deepweeb fine by me!

[deepweeb]

Hi Martijn,

• Demo Ready
• Readme.md done (https://github.com/Nieuwlaar/trustchain-superapp/blob/payment-request-interface/app/src/README-eurotoken-payment-request.md)
• PR ready (EuroToken I: Tokkie (EuroToken's Tikkie) trustchain-superapp#108). Will squash commit after demo.
  See you soon at CountlessCeremoniesCompareTwice

[devos50]

Final demo has been given 🎉 . The Superapp has been extended with support for EuroToken <-> Euro and Euro <-> EuroToken payments.

To make the conditional grade that I gave official, please address the comments I left on your PR so it can be merged. 👍

[devos50]

Tribler/trustchain-superapp#106 has been merged, completing this issue and course 🎉