Blockchain Engineering - class of 2022 - Team FROST

[synctext]

Focus: multi-signature transactions using FROST algorithm for creating a true decentralised DAO.

Re-use the existing source code, as inside this WIP PR. See work by Martijn. How functional is this Kotlin code? Missing parts? Could Trustchain+IPv8 help with overlay topology for 1+ million users scalability?
We have Taproot somewhat integrated in Superapp. Taproot.tribler.org documentation const val REG_TEST_FAUCET_IP = "131.180.27.224", the call itself and documentation here

Application: the Internet-deployed MusicDAO by Delft students enables music streaming and Bitcoin donations. Future step is to integrate FROST for enabling collective music investment decisions

Grading and outcome: a merged pull request on the Superapp, readme addition to the repo, and some operational code. We do not ask you to solve hard scientific problems within this course, but that you spend 5 x 5 ECTS wisely.

[dandreescu]

Update: We were able to compile and produce Schnorr signatures with the FROST pull request code. Next step is to compile the FROST library for JNI and call it in BitcoinJ. The issue is the unrecognized config flag '--enable-jni'.

[synctext]

Solid progress! Lesson learned: 5 developers stuck on 1 flag for a whole sprint, that is blockchain engineering for you.

First Taproot transactions in the wild Transaction fee: $284.86! Goal is to reproduce this type of transactions with multiple smartphones and no servers or PCs in general:

Documentation: code used from Github, taproot workshop has really great examples and in-depth technical documentation. Idea: Pull Request for 4.1 DAO skeleton.ipynb on Colab?
It seems quite complete, see this code point in ``test_framework``` # Calculate the merkle root given a vector of transaction hashes

To my understanding the state-of-the-art is that only central prepackaged Taproot transactions have been achieved. No distributed taproot transaction between people in different countries has been achieved. First step forward would be a Trustchain-based protocol with a central transaction coordinator which requests and collected signatures from dozen participants on smartphones (interactively co-sign MuSig aggregate signatures). We would really like to do Twitter campaign if you successfully achieve this.

Final target is to realize k-of-n threshold signatures, see k-of-n as specified within BIP 340

btw another team also encountered JNI problems in 2017 within superapp. They @mitchellolsthoorn solved it. What I vaguely recall is that JNI support usually needs to be compiled in from the source.

[OrestisKan]

Together with @dandreescu we traced when JNI was removed from secp256k1-zkp, brought it back and set up the frost in it.
Succesful compilation and generation of the .so file.

The existing frost module is implementation is not in a distributed fashion, so we are re-implementing it. Currently implemented commit generation and aggregation; that is the first of 2 rounds for key generation.

We also created the JNI methods to call the creation and aggregation from java.

The key generation is successful but the aggregation is flakey.
Currently trying to figure out why the aggregation sometimes work and sometimes doesn't.

[synctext]

• targeting getting everything inside a single APK, JNI fixing!
• 90%-ish sure that something will be working in week-10
• next sprinting target is design and coding of Trustchain-based FROST
• Kotlin IPv8 has its own identity and keys. Just assume everybody is online and reachable within the FROSTDAOCcommunity. Use message payload for key distribution. Just store this for now as plain-text locally storage and use just IPv8 message content. Lot of code to re-use or get inspiration from

[ioanasv]

Finished implementing all JNI methods and now PR 138 can be called from java (we have FROST in the BitcoinJ library)!

Designed all methods such that they would be compatible with Trustchain - currently working on compiling it for Android and adding it into the superapp.

[synctext]

👏 it seems to be coming together! please think about the final benchmark. Testing and demonstrating with 10M would obviously be awsome (see museg benchmark):

$ musig-bench keygen 10000000 # ten million
pubkey: F137781B753B22F8CA5450A64104072DAC55A0CCE2B67B3797ED8131E1194D23
# total: 159.30s, gen: 91s, aggregation: 70s

[synctext]

Seg Fault. 🛑
Status: stuck on detailed engineering. Compiler without a breaking warning, lots of warnings, never tested running for Android. Pull request is autoconf, difficult with Superapp integration. No breakpoints, no emulator running, no print statement for fault isolation. Is it a path issue? Created a cmake "Hello World" toy example with native code for the superapp, works 👍 . No .so loading in a toy example operational.

Request: animated cmdline .GIF for scaring representatives of the global financial system, your monopoly is breaking; countless warnings and engineering details, 16:9 readable font at full-screen, below 10MByte. 💻 🟢 on ⚫ font for bonus. Deadline: tomorrow, 29 March.

[ioanasv]

@synctext Here's the animated gif - only 81 warnings 👍 💯

[iiacoban42]

Update: we got unstuck. 📈

Fixed our emulators and managed to debug the problem with the .so file.

secp256k1.so with FROST can be loaded from Android now.📱

[synctext]

• it works! 🥇 but segmentation fault when increasing the Schnorr signatures to 1000-ish.
• Ambitious target of wrapping up by next week.
• ToDo: documentation, pull request accepted, and an animated .GIF please to demonstrate everything in main Readme.md
• Very promising!!!

[AndrewStefan]

Update: the integration of FROST into the superapp is working*
The first step of an end to end test works - two users can generate a signer object which is needed to generate the public and private keys through a C function call. Then, ipv8 is used to share this object (including the associated public key) to the other peer.
The next step in the test is sending the shares, for which the FROST function call in C seems to not crash, but there is still an issue when trying to broadcast the shares via ipv8
Link to the apk: https://github.com/iiacoban42/trustchain-superapp/blob/final-version/frost/app-debug.apk

[synctext]

• Sadly the .APK did not yet install
• Draft PR not yet ready: Tribler/trustchain-superapp@master...iiacoban42:final-version
• Readme: please add
  • Title: fully decentralised DAO
  • The superapp contains the foundation for a new type of DAO: fully serverless, no central point at all, no governnance token needed
  • uses the FROST algorithm to enable joint ownership of unlimited amounts of Bitcoin by group of unlimited size. Democratic control of money and means of production. K-of-n Schnorr signs working.
  • then more tech details.

[AndrewStefan]

New apk which hopefully works: https://drive.google.com/file/d/1hi29s_x26iSZZb0Ty5MKvUF2oP_jC7G1/view?usp=sharing

[AndrewStefan]

Final apk: https://drive.google.com/file/d/1smkjPhfFnST2gwJVdMipRJ1xjstMkn5E/view?usp=sharing

[synctext]

Impressive achievement!!

• Worked with 3 people 🎊 🥳 🪙
• Please do a Pull Request. This code was never reviewed now. Code: Tribler/trustchain-superapp@master...iiacoban42:final-version
• unclear things in Readme
  • Frost algorithm link to .pdf and mention Prof. Ian@University of Waterloo. Also mention IETF draft.
  • Be clearer, like: this proof-of-principle does not implement the shared key part. It works only until the key share distribution phase. Locally we have successfully created a shared key inside 1 phone, something with dissemination goes wrong. Please include "array out of bound error" details in readme. Link to line 628
  • Be clearer and dont keep secrets: Does not work on Android emulators. We tried to compile with ARM and x86, but our FROST app only works currently on real Android phones.
  • Consider spitting the readme into two parts, as other teams have done. "More details about a fully decentralized DAO using FROST". Another readme in your frost directory. This one then contains more developer details and scientific comments, see example.
• Code comments:
  • frost/app-debug.apk. Correct .APK or old outdated binary in your branch / PR?
  • Correct? frost/src/test/java/nl/tudelft/trustchain/frost/SmokeTest.kt
  • Fix the common key sharing issue!?! If it works locally, might be a UDP packet size overflow. Silent drop of an IPv8 packet with over 1480 Bytes of total UDP payload.
  • What is the status and purpose of submodule in de superapp https://github.com/OrestisKan/bitcoinj-frost ?
  • Please document status and purpose of https://github.com/OrestisKan/secp256k1-zkp-jni

[InvictusRMC]

Hi team, I am wondering what flags you used for compilation.

[iiacoban42]

Hi! You should be able to compile the frost code with ./configure --enable-module-ecdh --enable-module-schnorrsig -enable-jni --enable-experimental --enable-module-musig --enable-module-frost.

[synctext]

😲 😲 re-written everything in Java ??? (hearing this on a video call, no details)

[synctext]

The grade has been given, contributed to the main discussion at:
https://github.com/ElementsProject/secp256k1-zkp/pull/138#issuecomment-1125963587
Great running code !