Blockchain Engineering - class of 2022 - Team Digital Euro III

[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. Cashless society report by NL central bank

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.

Cardinal issues: preserve scalability, permissionless, primary function focus.

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.

idea: tooling for enabling e-commerce. How can a webserver scan Trustchain? How can a server create Trustchain transaction? Where is the identity of the store stored? The phone is the webserver?? "shooting for the moon" task

ToDo:

• [X] Compile Superapp from the sources and run in emulator (record number of participants)
• [ ] 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]

brainstorm: offline Euro -assume 10k public keys with a provided 0% to 100% double spending risk (100% score when irrefutably double spend in the past) -externalise the decision to transact to user (For instance: THIS IS 100% RISK, DON'T DO IT) -offline risk focus (locally store "counterparty risk assessment database" + updates) -focus on running code +X% design of this trust DB (decide this week on time spend coding + readme writing of design) -assume passport safe strong ID

Outcome: an merged pull request on the superapp, enhancing the offline Euro, and possibly a design for the "counterparty risk assessment database".

[Nils134]

Proposed timeline and research questions

Planning: 3 weeks research 2 weeks to implement 2 weeks UX/UI

Research questions: How to store and update the records of users, decentralized? Update between ratings Storage within phones

How to convey these risks to the user, intuitively?

Automatic block of users below a threshold?

How to prevent fraud with updating records?

(How would we update these records, given transactions)?

Milestones: Week 4: We set up a database (implementation) How to store and update? (research) Timestamp: Consensus Hash tree for information exchange / comparison Chunked update based on comparisons

Week 6: We set up exchange mechanism (implementation) How to prevent fraud (research) Only update others Prevent circular updates

Week 8: Automatic block of users below a threshold and convey risk (implementation) How to convey risk? (research) Color coding? Explanation? Double-spending?

Week 10: Do presentation Do readme

[synctext]

Offline double spending focus. Assumptions / constraints for the research part:

• assume there is a distributed ledger with all transactions, scalable ledger, too large to download for single node, searchable!
• pseudo-anonymous model, like Bitcoin, owner of wallets are unknown
• Know wallets which have conducted double spending attack while offline, irrefutable
• out-of-scope: calculation of risk of double spending attack, given the transaction graph+known attacks.
• Given: table of risk per wallet
• in-scope: disseminate risk updates.
• Bitcoin is permissionless, try to preserve this quality
• Do a double spend and learn from that?

Warning for whopping incoming code: https://github.com/Tribler/trustchain-superapp/pulls (Euro + Android 12 fixes) Read prior work: https://scholar.google.com/scholar?q=double+spending

[synctext]

• prior work https://www.dnb.nl/actueel/algemeen-nieuws/dnbulletin-2018/dnb-experimenteert-met-blockchain/
• [ ] Decide on the Docker Wessel gateway faith
• [ ] remove triple balance check, restore stability
  • [ ] non-zero balance
  • [ ] validation at central server
  • [ ] non-validated money is blocked from spending
• [ ] implemented time-warping, shift time and easily conduct replay attack (get_latest_block() bypass)
• [ ] note possibly its impossibly to prevent offline double spending. No prevention mechanism is sufficiently effective. Annoying offline witness mechanism needs to be assumed possibly (permissionless). Secure hardware? FM analog broadcast of double spenders, starlink :astonished: ad-hoc wifi local broadcasting to detect double spending :1st_place_medal: Unlimited double spending might be possible. Detection when Internet comes back might be the only mechanism. Do we have to accept amplification of disasters because our digital Euro will also fail.
• [ ] Serious issue, no known solution, serious consequences, led by a conservative entity.

[synctext]

https://github.com/KoningR/stablecoin-exchange

[synctext]

• Week 6, now the direction is at least clear to me :-)
• enhance the trust score, towards an end-to-end mechanism
  • warning, social implications, https://law.yale.edu/sites/default/files/area/center/china/document/2018-11-16_horsley_chinas_orwellian_social_credit_system_isnt_real.pdf
• by default share the last 50 public keys you transacted with
  • only send, receive, or both?
  • Emergent effect: web-of-trust
  • Its too large for a single UDP packed :grin: usage of EVA protocol or something
  • replace or simply add to the TByte storage
  • make sure to have a pull request merged at week 10 or extension
• MvP shortcut sprint
  • share last N public key which fit into a 1500 Bytes Ethernet frame - (8-byte UDP header + 20-byte IP header)
  • Each time you see a public key of a neighbour, you increase the trust with 1% point.

[Fastjur]

Added a warning label to the send money fragment in eurotoken:

https://user-images.githubusercontent.com/1493561/160100362-a934b0d9-cda3-4f5e-b4ca-0b47b1f398d2.mp4

In the above video, it cycles through (by hot reloading so I don't have to rescan the code) the following situations:

• Sending to a public key with average trust score (30/70%)
• Sending to a public key with a low trust score (<30%)
• Sending to a public key with a good trust score (>70%)
• Sending to a public key without any trust score (warns the user that no info is available)

The trust score is now loaded from an asset that is included in the source files, a json file, but it shows the feature.

[synctext]

• the app is getting feature complete :clap:
• currently the trust score is on a JSON file
• generate it on first-boot, store either in database or file
• no .APK to try yet, making solid progress.
• Emulator: connectable in IPv8 or firewalled... 10 second Google result
  • goal: UDP ports which are connectable for entire Internet. Both IPv8 port and libtorrent port.
  • please do a deep dive into this and document in your readme.md
  • document IntelliJ IDEA solution, port forwarding.
  • https://stackoverflow.com/questions/42608473/udp-forwarding-to-emulator ?
  • key here is IPv8 mechanism of NAT traversal
• Final Readme.md:
  • 4-5 pages max. general discussion, protocol exact details, drawbacks, vulnerabilities, etc.
  • Life-long digital footprint and reputation
  • Explain the paradox of security
  • Security by obscurity paradigm

[aimarinov]

Task division for the week:

• [x] Change the configuration file to include a boolean for demo mode
• [x] Generate the keys and trustscores
• [x] Setup database to store the trustscores locally
• [x] Transmit the latest 50 transactions (Our id + 49 others)
• [x] Update upon the receiving (+ 1% for each one)

  Goal:

  Demo - Showing the tasks as a whole unit

[Fastjur]

Added a simple toggle for demo mode, which will be used to generate 50 random (fake!) public keys when there are no 50 transactions available. This is purely to demonstrate the working of sending the 50 public keys over the eva protocol.

[JoepdeJong]

The generator is tested and implemented in https://github.com/pietertolsma/trustchain-superapp/pull/3. Demo mode is now enabled by default

• [x] Load demoModeEnabled from preferences.

@Fastjur can you look at this?

[Fastjur]

The generator is tested and implemented in pietertolsma/trustchain-superapp#3. Demo mode is now enabled by default

• [x] Load demoModeEnabled from preferences.

@Fastjur can you look at this?

This has been fixed in our latest master branch at https://github.com/pietertolsma/trustchain-superapp

[pietertolsma]

https://user-images.githubusercontent.com/10885710/161062927-05458ef7-f769-427e-a60c-4dae396eaabb.mov

Working demo of our contribution!

• When the user scans the QR code of the receiving party, it transmits its latest 50 transaction counterparties. When DEMO mode is on, it generates 50 random keys based on a seed.
• Upon receiving the public key list, the user updates its trust score on every key received. Note how in the video, we receive the list twice from two transactions, so you see the trust score update from 0 to 1.

[Fastjur]

@synctext Attached an APK file for you to test it out before tomorrow!

[synctext]

Discussed the radiating signs of frustration due to vagueness of assignment. The process of clarifying the assignment during the running of the course, continuous large changes, and keep changing course of the project was frustrating. Agile!

Week 8 progress: the app works now on my device :clap: This is now at the level of proof-of-concept. Its fully functional, while still needs further engineering and research. The trustscores for double spending uses simple linear additive model. ToDo: accepted pull request to wrap up course! polish, readme, spec of protocol messages

[JoepdeJong]

TODO:

• [x] Fix warning to show correct trust score (@Fastjur)
• [x] Cleanup code
• [x] Document/comment code
• [x] Limit maximum score to 100% (@JoepdeJong)
• [x] Write protocol specification (EPA protocol as binary) and readme
• [x] Add readme to main readme using read more
• [x] Make the PR

Remark:

• Be careful with updating ETH or BTC libs and dependencies.

[aimarinov]

@synctext Here is the paper draft. It's formatted like a report instead of a paper, but that could be worked on.

[synctext]

Pull request with docs. :+1: there is no detailed docs for Eurotoken, just discovered today. Please focus on the update with your specific problem focus and your contribution. To be consistent with others please do the readme at 2 levels: short main blurb and a detailed version in more than 33 lines. Discussed arvix uploading. More informative title: double spending prevention of digital Euros using a web-of-trust. If you alter the intro and start with the words "double spending", it will flow better. Level of detail needs to build up to the point of a specification. Others can reproduce your work with merely your scientific paper. "III. Requirements", more informative would be 'III. Offline Euro requirements". More informative "IV. Protocol", like transaction protocol or "offline P2P payment protocol". Difficult choice on how to deal with trust protocol versus pointing to other docs for actual payments or repeating briefly what others build. Like: coins in our system are minted by the public keys of central bank within the Eurozone. Each coin is simply a unique coin number, denomination and signature by a entity within the eIDAS legal framework ref. As authors, could mention my name as final author and use annotation "(course supervisor)". Example here and please add --- student project ---. Please arvix upload, option for adjustment and versioning later.

[aimarinov]

The updated version of the paper.

[aimarinov]

The newest version of the paper. We reflected on most of the feedback received last week but there is still some work to be done on the protocol part.

[Fastjur]

Pull request opened

https://github.com/Tribler/trustchain-superapp/pull/105

Readme

https://github.com/pietertolsma/trustchain-superapp/blob/master/eurotoken/README.MD

Debug APK

https://drive.google.com/file/d/1-qag_BBYBweuw9ENgHTe0t8p8RdR2nkX/view?usp=sharing

Research paper

https://arxiv.org/abs/2204.06831

[synctext]

Euro readme intro: EU member states of the Eurozone are considering creating a blockchain-inspired digital Eurotoken using a P2P architecture. The superapp contains a fully functional digital cash implementation, still experimental and tested within 1 retail location for 1 morning in live production usage with real financial transactions.

[devos50]

This work has been completed, closing the issue 👍