Blockchain Engineering 2023 - Offline Token Money

[synctext]

Team issue for 10 weeks of blockchain engineering course at Delft University of Technology

Offline token money. Your task is to create easy payments using tokens, without Internet. Giving and receiving tokens should be easy and effortless. Special requirement is that it should also work in an emergency: when the Internet is down. Probably you need to use QR-codes scanning to move Tiktok Tokens between devices. The hard scientific task is to address the double spending risk. Required background reading from Delft: Double spending prevention of digital Euros using a web-of-trust.

• Discussed: 20 and 21 April (week 10) final meeting.
• {tentative} final project goal. Create token. Transfer token to another device. Some measure for double spending mitigation.
• Prior work around Euro token transactions:
  • digital Euro engine {thesis work, nearly finished, https://github.com/KoningR/eurotoken }
  • Another digital Euro in trustchain-superapp
  • Github details of previous team: code, links, context, and comments
• You can assume a central authority in the form of a "ECB Digital Euro Public Key", hardcoded public key. Not a central trusted server.
• First sprint goal: Show QR code, scan QR code (all this is already operational inside Superapp), copy inside trustchain data structure.

[TimG-NL]

Until 27/02/2023

Done:

• Compiled the app
• Got QR code via eurotoken app to run
• Created a fork for the project: https://github.com/Robert-ML/superapp
• Some ideas to solve double spending problem

Ideas to solve double spending problem:

• Geo location restrictions

Important terms to look into:

• irrefutable proof of double spending
• Security deposit to have as collateral

[synctext]

• commercial actor: Euro tokens from Iceland: https://monerium.com/#iban (Commercial bank digital currency)
  • DEV docs: https://monerium.dev/docs/welcome
  • How is this legal and compliant with AML plsu KYC regulations, https://monerium.dev/docs/tokens#eth-eur
  • Try their example
  • @gerbentimmerman can this be linked to Trustchain?
• Another team attempt at building the app with CI enabled
• Some background work we did. This double signature scheme acts as a nuclear backdoor for enforcing honest participation and preventing users from committing frauds as they essentially risk leaking their own private keys upon double spending.
  • Does this solve the double spending or is it possible to move your fraudulent funds into a backup wallet with really private keys?
• not the first on the idea of collateral with double spending
• Next Sprint goal for upcoming week(s).
  • Decide on either Tribler-like bandwidth utility token; minted by each user. OR central authority Euro ECB token.
  • understand prior work and the problem as a whole better (Outcome: list of related work, taxonomy of solution)
  • Show QR code, scan QR code (all this is already operational inside Superapp), copy inside trustchain data structure. Live network with Bittorrent seeding bandwidth token for a while.
    • show the keys to a "Tx wallet". has the money been transferred, eternal pending offline transaction in theory
  • On-chain tokens as money (at some point, created by a widely known authority such as European Central Bank)
  • Discovery screen of online peers: possible people to pay with a single click, ipv8 community

[Robert-ML]

• investigate the icelandic bank with money transfer between bank account and blockchain address -> @gerbentimmerman
• nuclear backdoor -> @Robert-ML
• double spending colateral other's work, look into other approaches and ideeas that we might implement/steal/improve -> @naklecha
• set up a demo network to check how to send money, so in the end we have a token to work with. One looks in other apps in Tribler how they set up their network, one looks into Euro Token ECB. -> EuroToken @AdiDumi, @gerbentimmerman | other tokens (music app for example) @vick0088
• use the halfblock structure for transactions, also how to populate the transaction structure later when we are back online, how to give information that is needed for the future transcations -> @naklecha, @Robert-ML
• A TASK FOR EVERYBODY -> how Android development works, how stuff is drawn on the display, how stuff is updated on the display: https://duckduckgo.com/?q=android+lifecycle+fragment&t=vivaldi&ia=web . Practically get some basic android development experience.

[naklecha]

Team Update

• Explored Monerium and concluded that it is not applicable to our use case, but it might be interesting for trust chain in the future.
• Started with android studio and kotlin tutorials and courses to start building the final application.
• Explored the transaction code of euro token and looked at the fields that need to be set for offline money (we can sign a transaction and send it to the user offline to be redeemed later (the only question to test is the block number))
• Started building the application with a wallet and QR codes
• Looked at past research for collateral but they were mainly for online money, but we found a recent paper on offline double spending problem for digital currencies but its not accessible for free (https://link.springer.com/chapter/10.1007/978-3-031-17551-0_30)

[synctext]

• Lets do a deliberately simple approach, fixed coin denomination: .1 Euro .5 Euro, 1 Euro, 2 Euro, 5 Euro, and 10 Euro.
• Focus on double spending to the max.
• Discovered that an offline transaction is actually difficult: what to include in the QR code? intermediate one-time usage wallet with disclosure of private key? alternatives? any finality?
• Non fungible by design. We assume users continuously watch their wallet and split money to ensure maximum ability to transact any amount.
• Discussed:
  • Monerium could work, if they alter their server code with Trustchain-based digital Euro.
  • offline peer can lie about their latest block. Not just double spend, also block hiding.
  • Collateral could work! How to implement? Ideas, approaches, architectures?
  • fork detection and double spending detection with Trustchain when coming online???
  • KYC is done, genesis block is created: "double spending" is detected, but is translated into debt building and negative balance. Double spending is translated into a accumulation of debt. Can you give any ordering to the debt? First-Debt-Goes-First policy 🤑
  • put cap on exposure client side/receiver. offline money transfers can be limited to 1000 Euro. So the potential loss is: X x 1000 :-)
  • everything could be an I Owe You type of transaction, but possibly broadens the fraud potential.
• Lets try to do an end-to-end prototype. Offline transactions, simple offline Tx risk estimators (improve prior student work == send last 50 people Tx's), double spending discovery, double spending translation into negative balance.
• ToDo: trustchain or not? Skeleton- data structure or add block numbers, hashing, etc.
• ??? Use any highly reputable node as a witness for offline transaction validation ??? (Antarctica scenario)
• Next week goal: .APK on your issue which does magic 🪄 (Monday, week 5 milestone)

[AdiDumi]

• Currently the app has one wallet, see if we can make multiple
• There is a shared public key option, can we make this private key as well
• Redeem private key money (does not need 2-3 but needs 1 so we can redeem money from a random private key)
• QR code to share private key
• UI Changes to it shows person sending their money

[synctext]

• Please have somewhat working .APK on your issue next meeting! {week6}
• Adrian: tried to debug wallet. Add genesis block, print-your-own money button for testing. in progress
• Just use this? https://github.com/KoningR/eurotoken/blob/main/src/main/kotlin/Token.kt#L27
  • Signature form central authority makes it money: European Central Bank
  • EURO 000001 <signature> most simple design.
  • Last week political speech from EU on offline Euro
• Nishant: thinking about the global design. {difficult for me to understand}
  • Why list of wallets? {Privacy, leakage of amount of money. ignore privacy}
  • Idea of using 10-ish wallets with certain amounts of money in them.
  • magic algorithm: well known public keys with confirmed amounts of coins in them
• Cardinal design decision: keep it as simple as possible. You don't know the receiver. one-shot primitive. no bi-directional communication.
  • known problem: you can read it, you can steal it.
• Gerben: QR-code encoding, decoding. in progress dived into old EuroToken code. Getting used to Kotlin.
• Zhang: private key money.
  • Usability: you need to get you phone out, stat the app, do the QR code thing.
  • Shop scans your QR code. Use your phone to pay / collect. Shop takes the money, no confirm or OK/Cancel button.
  • Easier to swipe plastic {US convenience}
• Decide remain focus (decide, make it really working):
  • Antarctica scenario, witnesses
  • detect double spending, add debt
  • web-of-trust approach (last 50 people).

[Robert-ML]

Promises Approach: devised a signature scheme so that a recipient can hold a sender accountable in case of not fulfilling its promise to send funds (completing the transaction) when he returns back online.

The app: we have a working app where the sender creates a promise which can be scanned and is verifiable proof that the sender has to transfer money to the recipient when they get back online, the balance shown is not valid and is just as a placeholder.

TODOs:

• make the storage of promises persistent after app restart;
• keep track of the balance and unconfirmed balance;
• as a sender: see transactions which you have to publish to the network (promises the sender did not yet fulfill);
• as a receiver: see transactions which were not yet published to the network (unfulfilled promises) and have the time since when the promise was created;
• make the offline money exchange more generic to be able to be easily integrated in other blockchains / communities / apps in the supper-app;
• start doing the web of trust approach so that a recipient can measure the risk when getting a promise from a sender;

[synctext]

• MUST Have coins in wallet, working QR code, working offline transfer, and some double spending ideas/code.
  • for debug purposes you have a coin minting button, simulate the central bank feature.
• Please do an issue update for each of the developers (2-3line)
• Brief chat with European Central Bank in Amsterdam about our offline Euro work/offline token research
  • Program Director Digital Euro, European Central Bank
  • Event: https://toekomstbetalingsverkeer.nl/sprekers/
• Readme.Markdown documentation
  • example: https://github.com/Tribler/trustchain-superapp/blob/master/eurotoken/README.MD
  • Explain basic design, attack, and your solution: case of not fulfilling its promise to send funds
  • Please not a huge 120 page babbling report, sharp, short, efficient, and effective technical documentation
  • More depth than Euro Token example
• Real world scenario
  • City with millions of user in China has severe floods
  • subways are flooded
  • people are hungry, shops are still having food
  • Your focus: How to pay at the semi-flooded supermarket?
• Requirement:
  • instant settlement
  • one-shot, no bi-directional communication
  • offline received money can also be spend offline (no talking to server needed)
  • Allowed to "cheat", redefine double spending as debt buildup.
    • However, how to deal with stolen smartphone, bad actor does double spend (document or even solve).
    • Offline biometrics (e.g. passport-level photo, compare face with actual person holding smartphone)
      • This could be a new scientific direction: offline biometric to protect money.
      • Open source and transparent, share hashes of biometrics
    • Or lock the wallet locally with biometric unlock {make that mandatory, to prevent the theft scenario largely}
      • encrypted storage. unlock with you fingerprint or facial features.
      • No recovery upon loss of fingerprints.
• Week 6: decide if you will call it offline Euro or Decentral Tiktok token. Replace all existing Euro code in the superapp?
• "One-time identity" idea. For each offline transaction you share the private key of a wallet with tokens in it. So a single QR has: public key, private key, and numerous coins (2 Euro x 40, 1 Euro x 3 and .5 x 7 = 86.50 Euro)
  • eternal growing chain of past owners and present owner
• Please use standard Euro coin denominations in an initial GUI (.05, .1 Euro, .5 Euro, 1, and 2 Euro)

[Robert-ML]

@AdiDumi: I've made all the fragments with their UI (the print money and the coin picker most notably) and the navigation between fragments.

@gerbentimmerman: Last week, I mainly focused on data persistance research and created the initial database with some simple backend functionality. Next week, we will add more interactions with the database and connect it with the UI elements.

@naklecha: Last week I worked on the QR code integration, private key generation and passing those values to the QR code.

@Robert-ML: I've made the button interaction logic. Also I integrated the offline money app as a library inside the big super-app.

@vick0088: I work on the private & public key pair together with nishant.

[tudelftstudent]

@vick0088 I work on the private & public key pair together with nishant.

[AdiDumi]

Screen_Recording_20230327-102543_Trustchain.Superapp.mp4

We made a short demo of how the app looks until now, there are still some links to be done between pages and QR code but this is the reference

GIF:

[synctext]

• Great demo video!
• You did a nice productivity sprint!
• How do you protect against double spending in the online case? "Race-to-bank": you own the coins if you are the first to register at the central bank.
• Please post an .APK!
  • running code for passing grade
  • Make a PR!!! ❗
  • Transfer Euros between us

[Robert-ML]

PR into Trust chain super app.
About the app:

• APK at this link
• transfer tokens through QR code
• data persistency present
• printing money active
• BUG when deleating tokens from data persistency

About the team contribution:

• @AdiDumi: The prin money interface and incorporating data persistency with the minting of tokens.
• @gerbentimmerman: Implemented the data persistency for the tokens.
• @naklecha: The logic for transactioning tokens through QRs and moving data through the different fragments in the app.
• @Robert-ML: The logic for transactioning tokens through QRs and moving data through the different fragments in the app.
• @vick0088: The minting of tokens. (printing money for demo purposes)

[AdiDumi]

Demo with the printing money functionality working and balance update

[synctext]

• Working .APK on your issue
• Seems I reproduced an async bug: printing money didn't work as expected
• Trying to send 22 digital Euro coins into a single QR. still waiting.. 💤 😴 💤
• Coin transfer! 🎉 Trying to see this coin in transaction history 🤕
• Scanning QR code 4 times. No double spending detection
• A lot of big PRs are expected near the end of this course. The Week 6 V1 merging didn't happen sadly
• Likely: 1 giant PR for this team
• Week 10/Monday week 4.1: final grade or selectively try bonus.
• no more silent crashes please, check UDP sizes, QR max. sizes, etc. (stability over features)
• Document your double spending solution
  • your URL: https://github.com/Tribler/trustchain-superapp#offline-digital-euro
  • please rename offlinedigitaleuro offlinemoney/src/main/java/nl/tudelft/trustchain/offlinemoney/db/UserData.kt
• Required: add 1-section of documentation in readme.md format as with all Superapp PR projects by students:
  • https://github.com/Tribler/trustchain-superapp#peerchat
  • https://github.com/Tribler/trustchain-superapp#digital-euro
  • https://github.com/Tribler/trustchain-superapp#ai-trading-bot
  • https://github.com/Tribler/trustchain-superapp#luxury-socialism
  • https://github.com/Tribler/trustchain-superapp#freedom-of-computing-app
  • Optional very detailed documentation example (linked from main readme, located in subdirectory): https://github.com/Tribler/trustchain-superapp/blob/master/trustchain-voter/README.md
• Add animated .GIF to your readme.md documentation (with a visible QR code)

[Robert-ML]

Assignments:
When anything is done, mention it in Whatsapp so we might test it.

@gerbentimmerman :

• start on the documentation
• start on the DB function for transaction history

@naklecha :

• token signing when transferring ownership

@Robert-ML :

• verifying signatures when receiving money and for now print something tot he log if the validation fails
• • validation: is checking who minted the token (the government) and if the transaction history is valid inside the token
• a private-public key static key pair to act as the central bank (such a key is in the Token's GitHub repo in the validator/validation file) (5 minute job, 10 minute compile)
• change name of the app from offlinemoney to offlinedigitaleuro and the folder and everything

@vick0088 :

• the printing of money needs to have the first recipient when it is minted, not be left empty (maybe the central authority, but not sure, needs to be checked). Then the coin needs to be transferred to the owner that is printing the money.

@AdiDumi :

• UI for transaction history and navigation to that page and from that page (sorry Adi)

[synctext]

• As asked At the moment we don't plan on implementing ideas like web of trust or debt collection in our application
• please try to at least detect double spending when coming online again. Only implementing a token transfer app is a bit small-ish for this course. Especially, given prior student work within this course. By talking with random Ipv8 peers you should after a while stumble upon any cheaters.

[Robert-ML]

Implemented transacting tokens through QR and do all the security verifications. Because of limitations to the QR method, we can not put too much data into the QR so for high scanning success rate we recommend making transactions with only one token.

We do double spending token detection and find the culprit through the recipients history of a token. We insert it in our web of trust as a double spender (low trust score). Because of QR size limitation we do not send known users and their trust when doing a transaction, but it can be easily added just that QRs would start failing to generate or high likelihood to fail to be scanned.

New PR, APK and README

[Robert-ML]

2 euro from Robert & 10 euro from Robert

[synctext]

• APK works smoothly! 👏
• Nice interface with the coins and notes
• Web-of-trust does not display double spenders or -1 distrust people.
• Demo demonstrated the infinite growth of prior owner list of tokens
• BONUS:
  • all the work required for getting the PR through
  • max-size of QR
  • max-size of Euro coins and Euro notes
  • Display also distrusted people?
  • Single .GIF to illustrate all screens (also untrusted in RED) in Readme
• re-used no code of the prior team on web-of-trust (e.g. last 50 transactions)
  • New code https://github.com/AdiDumi/trustchain-superapp/blob/master/README.md#web-of-trust
  • undocumented magic 100 trust score formula, increment mechanism, and demotion in Readme

[Robert-ML]

PR, APK, README, DEMO

[TimG-NL]

Offline Digital Euro - DEMO GIF