msc placeholder: daos, scams, FROST, message drop, something

[synctext]

• First literature survey! then msc
• this quarter 1.5 courses.
• did initial brainstorm
• interest in FROST
• cryptocurrencies, P2P in general
• Martijn chat about FROST
• Read about Gitcoin, consitutionDAO, etc.
• ToDo: read into DAO papers
• identify open search issues.
• coding skills: loves coding, hackthon level.
• Thesis idea: lots of various topics, not a single deep dive, full stack engineering (e.g. product launch)?

[rahimklaber]

This is a short draft of my idea: Are_Daos_A_Scam_draft.pdf Bassically, I want to give an overview of what DAOs are and the issues they have.

I've also read some papers, but most of the interesting things are found outside of papers on blogs or articles. Some of the stuff I found interesting:

• https://decrypt.co/38050/steem-steemit-tron-justin-sun-cryptocurrency-war
  • Someone was able to take over a blockchain by acquiring enough votes.
• https://www.cnbc.com/2021/10/03/162-million-up-for-grabs-after-bug-in-defi-protocol-compound-.html
  • A bug in Compound allowed more tokens to be claimed than was intended. The bug took a while to be fixed, since it involved passing a governance proposal.
• https://dxdocs.eth.limo/docs/Governance/REP/
  • DAO members are rewarded with reputation for contributing to the DAO. Reputation is non-transferable and decayes when member is inactive.
• Many DAOs seem to rely multisig schemes. So you end up with situation where a small amount of people control the DAO, or atleast can do some harm.

[synctext]

This angle is difficult to bring in the science. DAO now reads as engineering and financial shenanigans. More scientific example are going into these type of algorithms to generate trust or another wild angle is technology is becoming political; see Susskind book. Or especially wild: "why we never produced a global brain". Example Your survey needs more scientific citations, besides blogs. Note the DAO survey with [46] papers cited. Do something more practical: like crawl a DAO (forum) and analyse. The exhaustive list of DAOs and their exact governance rules.

[rahimklaber]

lit survey

this is what I currently have lit_survey_current.pdf. I combined what I was doing previously with researching DAOs' governance procedures. I couldn't really find a scientific angle + my writing is still not that good ☹

thesis

Do we really need to use FROST? Depending on what improvements FROST made over its predecessors, it might be worth it to use older schemes as they already have mature implementations. I found a go library that allows creating threshold signatures for ECDSA and EdDSA. Then we could use go mobile to call it from android.

[synctext]

Solid idea! Somehow I failed to read more, after seeing FROST. I just wanted it after reading. :smile:

• https://github.com/ZenGo-X/gotham-city#abstract
• https://github.com/unboundsecurity/blockchain-crypto-mpc#5-benchmarking-and-performance
• Read please: https://a16z.com/wp-content/uploads/2022/04/principles-and-models-of-decentralization_miles-jennings_a16zcrypto.pdf
• Survey scope:
  • how to manage the shared wallet, given this prior work by Brian, https://github.com/Tribler/tribler/issues/6714
  • Our "unstoppable Bank-DAO" could offer coin minting and offline money with probabilistic double spending. No money creation, it simply creates transferable withdrawal rights for Bitcoin on shared wallet. Tokenize crypto coins :exploding_head:
  • Almost classic Layer II solution, off-chain and off-line
  • Different from layer II rollups or payment channels.
• Sections are not that scientific yet. Suggestion: "2. Generic DAO architecture", core DAO components. Picture with each element to discuss.
• Nice opening illustration, like this simplistic "traditional Company versus DAO": https://dev.to/3scava1i3r/what-s-a-decentralized-autonomous-organisation-dao-6dj
• Get inspiration from "DAO tooling landscape" picture: https://www.theventure.city/blog/the-building-blocks-of-a-dao
• Another section is needed, besides explaining DAOs and listing bunch of DAOs. Taxonomy, feature comparison, state-of-the-art, scientific publications in a table. etc.
• Suggestion: a short history before the DAO
  • 1989: Collective action https://www.jstor.org/stable/2083221
  • 2009: https://doi.org/10.1111/j.1540-4560.2009.01623.x
  • 2021: WallStreetBets: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3806065
• DAO milestones table
  • June 17, 2016: The DAO Hack
  • 2018?: First DAO voting fraud, CarbonVote???
  • 2020: ??First??? DAO protocol politicians

[rahimklaber]

current version of survey I think it is a bit better now, but I think there is still a bit of work to be done. The angle I'm going with now is that It is hard to fully understand DAOs since there isn't any good documentation and you have to gather information from many different sources.

[synctext]

• 8-pages. Approaching 80% of time for completion. {wording and phrasing}
• [33] bit too low.
• Figure 1: no overlap with terminology of Figure 2. Too small, make it flatter "worker", "managers", division head, CEO graph of something
• "2.4 Voting" missing from Figure 2. Please make consistent if possible.
• "4.2 Open development" scientific wording: {transparency and} level of openness
• DAO is just the latest digital realisation of the generic concept of "leaderless organisations".
  • "The Tyranny of Structurelessness"
  • ACCOUNTS OF INTERVENTIONS: The Three Paradoxes of the "Leaderless Organisation"
  • Autonomist leadership in leaderless movements: anarchists leading the way
• List of DAOs could be expanded in your Table 1.
  • make it nicer: :heavy_check_mark: :red_circle: :ballot_box_with_check: :top: :+1: :-1: .
  • "resistance to attack", take 2 lines for headings. Add more like: "scam risk estimation"
  • Volume of documentation: 99-page white paper, 3 blog posts.. Power of top-10 members, gini
• conclusion: "In theory, DAOs should be decentralized and autonomous. However, this is often not the case." hidden on page 6 :zap:
  • Possible opening sentence: "Already 50 years ago the goal was to form radical participatory social movements without leaders. Leaderless organisations do not exist, was written down by Jo Freeman in her 1972 controversial essay. This survey demonstrates that leaderless and decentralised digital organisations are almost as utopian. Significant progress :clap: MusicDAO by TUDelft :confetti_ball: ...
• Recent:
  • Analyzing Voting Power in Decentralized Governance: Who controls DAOs?
  • When is a DAO Decentralized?
• "Top 15 rug pulls in 2021 by value (Chainalysis)"

Master thesis thinking:

• learn all you can from "The Original unstoppable DAO" author
• performance analysis of MusicDAO discover, join, vote, and transact
• Make it scale 10x ... 100x
• Write thesis report
• DONE

[rahimklaber]

Update

lit survey.pdf

• I think the lit survey should be ok now. I fixed a bunch of errors and added stuff based on your suggestions.
• Spent some time looking at the DAO code in the super app
  • Rowdy suggested I benchmark the DAO code by doing simulations on a computer
• Read a bit of the Frost paper, looked into bip340/taproot and the FROST internet-draft https://github.com/cfrg/draft-irtf-cfrg-frost/blob/master/draft-irtf-cfrg-frost.md
• Got frost working with a rust library (https://github.com/serai-dex/serai) and used jni to call it from java. Bip340 signatures are currently not officially supported, so had to do some hacks to get that to work.
  • I am currently doing this on my computer and will try to get it working on android later.

What I’m planning to do next sprint

• Figure out how to run the superapp DAO code on PC and benchmark it.
  • look at musig’s complexity and see if my results make sense
• Figure out how to use Schnorr with bitcoin and try to create a bitcoin transaction with frost.
• Improve the wrapper I wrote to be able to call FROST in JVM.

[synctext]

• [X] Survey ready for grading :tada:
  • upload to arxiv, re-format slightly
  • Would like to be on the author list. Upload to :arxiv as this author
  • add --- student project --- , see example
• [X] code Threshold signatures working which {in theory} should work on Bitcoin.
• [ ] is there somebody who has claimed a FROST transaction in the wild?
• [ ] Wild idea: Create 10 Euro wallet, do FROST magic, give away 1 key, other key is kept private, with 50% threshold its possible to create a valid transaction. Do Reddit post on WallStreetBets? Wait for anonymous stranger on The Internet to win this bounty. Simple minimal 10 Euro for honour and glory (in BTC)?
• [ ] Wild idea2: Create a TreasuryTestDAO for WallStreetBets and test with this community. Donate 100Euro (in BTC) and the 10th person gets 1000 Euro for 100 Euro input :-) Oyeah, after this test it unlocks new feature. The "winner" can create a new DAO and determine the number of rounds, and treasury capital goal :clap:
• [ ] Wild idea3: with voting
• [ ] Master thesis level: {repeating from WallStreetBets issue} jonasnick establish the computational time for a 4.4million-out-of-8.8million multi-signature wallet (simple majority voting for DAO governance)
• [ ] Using the other library? https://github.com/ElementsProject/secp256k1-zkp
• What are you most interested in: practical, treasury, MusicDAO/Spotify, scalability, deep-dive crypto, EVA mystery, maximalist on social good?
• possible focus: "Digital democracy and FROST threshold cryptography for DAO governance"

[rahimklaber]

small update

• Got signing to work in a 250-of-500 configuration. It took ~37 minutes.
• My code could probably be improved to be faster.
• the repo is here by the way: https://github.com/rahimklaber/jni_frost_test/tree/master/src/main/kotlin
  • I only compiled it for windows.
  • It is pretty ugly, but it works.
  • currently, the path to the native library is hardcoded, so that also needs to be changed.

[rahimklaber]

Update

• final_survey.pdf I submitted the survey to arxiv on saturday. It should be visible on tuesday. If I understand correctly, I will get a code to give you so it shows up on your list.
• I successfully submitted a bitcoin transaction on regtest that was signed using frost 🎊. (Or atleast bitcoin didn’t give me an error)
  • Bitcoin taproot transaction require you to sign a transaction with a modified key. It took some time figuring this out.
  • I am using this lib, which seems pretty mature as it has started to be audited (https://github.com/serai-dex/serai/issues/199). I also got some help from the author, who helped me figure out the bitcoin transactions.
  • In my testing code I construct the transaction with bitcoinj and then sign it using the native code.
• Next steps -> Compile with NDK?

possible directions

• A possible thesis direction would be to create a DAO with two tiers of members. A few hundred members ( or up untill what is realistic with FROST) would be part of the threshold scheme and the rest would be able to vote using trustchain. The threshold members would be responsible executing the proposals. This would be the same as DAOs with multisigs with few members, but this would be more safe due to the amound of theshold members.
• Another Idea is to improve the XChange paper. My idea is to apply the idea from paper to payment channels and improve the safety by allowing market makers to lock funds and therefore increasing its trustworthyness. The locked funds would be governed by a FROST DAO.
  • Maker makers would be the ones who send a payment second. So they are the ones who are able to steal.
  • Since payment channels would be used, trading can be extremely quick. Using payment channels would also make it feasible to split a trade up in many smaller trades, therefore lowering the potential profit of a market maker cheating.
  • If a market maker does cheat, the DAO would use his locked funds payback the person who was cheated.

[synctext]

• The Tribler principle of a zero-server architecture is still far from mainstream. You found a nice team which is also getting closer to this versus usual DeFi central server stuff.
• ToDo: Survey: not yet in list of arXiv papers, paper password and grading.
• From the Tribler lab perspective: just focus on 100 people case, keep everybody equal (e.g. no 2-tiers), deeply optimize, polish this, conduct performance analysis, and deploy to MusicDAO app store.
  • Took Rust code, added to app, fixed it
  • What is the "Problem Description" content of master thesis?
  • Can we do better than your first ~37 minutes attempt?
  • Analysis of cost of security measures within FROST
  • Real Bitcoin transactions with shared ownership, transparancy, and democracy :tada:
  • "The First Bitcoin Democracy"
  • Unreachable peers problem: FROST requires messages to arrive, reachability, buy few smartphones, buy 50GB pre-paid subscriptions, test connectivity and NAT puncturing.
  • Buying 5 phones with prepaid SIM?
• Goal: have "Problem Description" finalised and nicely written down in 2 months: 9 March 2023

[kayabaNerve]

While quite late, I'd like to contribute FROST is far simpler than any threshold ECDSA protocol, relying on far fewer assumptions. It also has extensive security review in:

• The original paper
• This further analysis
• This even further analysis
• This CRYPTO2022 submission

Threshold ECDSA also has review, yet provides a much larger surface taking several rounds to complete, and relying on far more assumptions to be proven. Part of this can be cited back to ECDSA being a convoluted attempt at avoiding a patent, leading itself to not have a security proof given the discrete log problem.

Practically, FROST is 2-rounds, only one requiring knowledge of the message. The lowest thresold ECDSA protocol is 4 rounds to sign, when the famed GG20 is 7. Binance's tss-lib has been forked to GG20 by THORChain, and their fork has since had several security issues with it, from Alpha-Rays to the ability to cause honest parties to be blamed to leaking key shares. Despite this, THORChain's library was prior audited (though the quality of this audit now must be called into question) and is likely the better choice than the tss-lib it comes from (as I assume it has had far more scrutiny, yet I may just be unaware of the review on Binance's lib. Their one published audit is years old, prior to Alpha-Rays).

As for Binance's EdDSA impl, they appear to use a 3-round threshold signature protocol (not FROST, yet not vulnerable to Drijver's application of Wagner's algorithm thanks to a hashed commitment round). I'm unsure what actual protocol it implements, yet I can note FROST achieves a 2-round protocol with the same raw bandwidth for their messages. It didn't include any horrendously expensive proof to achieve the reduced complexity.

I also believe, regarding performance, no threshold ECDSA is linear to amount of signers. GG20 is quadratic, which is why THORChain takes tens of seconds to sign for their 20 participants. FROST is linear, and I've benchmarked <0.7s per-signer for a 333-500 group.

I do believe this is months late, and y'all are using FROST (specifically my lib, currently under audit :D ), yet I still wanted to chime in as I can :) At least this should be helpful by providing plenty of references to refer to?

[rahimklaber]

@kayabaNerve Thanks. This is great and It'll be helpful when writing my thesis.

[rahimklaber]

Update

• The paper was put on hold by arxiv. I’m guessing it is since I’m new? 😞

• I was able to cross-compile the rust code to native code for android. I'm using this tool https://github.com/rust-mobile/xbuild. All you need to do is plugin your phone and type a command do compile the code for the phone: x build --device adb:16ee50bc. It does create an .apk or .aab, so you have to extract the native libraries yourself.

• I got a basic app working that uses frost to join and sign. It also uses ipv8 for communication.

  • I made a short clip of it: https://www.youtube.com/shorts/uW6-qZi62ts.
  • Clicking Join will attempt to join/create a new frost group.
  • clicking sign will attempt to sign some random data.

• I thought a lot about how signing and joining a frost group would work.

  • It gets very complicated due to the asynchronous nature and we might need extra messages to explicitly define who is participating in signing.
    • Signing only needs t < n participants, so you don’t want everyone to take part in it if not necessary.
  • Message ordering is also a problem. It can be tricky since a peer might start sending messages related to signing or joining a frost group, before you start listening/saving these messages.
    • In my example, there is a leader who signals the start of signing/joining the group such that other peers know that they can start sending messages.
    • Making it work consistently without a leader would be complicated I think.
    • Though having a leader-based scheme might not be a big problem. If the “leader” is the one who wants to join or proposed a transaction then others might not care that he is the leader, since making sure everything goes well is good for him.
  • There is also the problem of multiple people wanting to join.
    • Currently this must happen sequentially, but it would be better to wait some amount of time and make a new frost group with everyone who wanted to join in that period.
    • However, this also gets into the leader/leaderless problem as in this case there wouldn’t be an easy candidate for a leader.
  • It could also be nice to implement a way for peers to store message for a peer that is offline. Could be done with Trustchain, but seems a bit overkill. Though this is out of scope I think.

• I think I made it pretty testable, and I will write some tests next sprint

  • I made interfaces for functionality that I need and then I used anonymous objects when I need to implement the interfaces

  // interface for network
  interface NetworkManager{
      fun send(peer: Peer, msg: FrostMessage)
      fun broadcast(msg: FrostMessage)
      fun getMyPeer() : Peer
      fun getPeerFromMid(mid: String) : Peer
  }
  // abstract over frost community with the network manager
  FrostManager(frostCommunity.channel,
              networkManager = object : NetworkManager {
                  override fun send(peer: Peer, msg: FrostMessage) {
                      Log.d("FROST","sending: $msg")
                      frostCommunity.sendForPublic(peer, msg)
                  }
  
                  override fun broadcast(msg: FrostMessage) {
                      Log.d("FROST","broadcasting: $msg")
                      frostCommunity.broadcast(msg)
                  }
  
                  override fun getMyPeer(): Peer = frostCommunity.myPeer
  
                  override fun getPeerFromMid(mid: String): Peer =
                      frostCommunity.getPeers().find { it.mid == mid } ?: error("Could not find peer")
  
              }
          )

  plans for next sprint

  • write a problem description
  • Get example to work with 3 or more devices
  • start thinking/prototyping bitcoin integration
  • Make tests

[synctext]

Please document the possible final goals of your master thesis, brainstorm:

• Collective Bitcoin ownership

• 100 devices

• 1 new initiator joining the DAO

• Not everybody is online

• Having a selective re-try mechanism (IPv8 gossip community)

• Native re-implemenation of the 1200 lines of Rust, for lab sanity and simplicity....

• prepare the lab for next master student project: 1000 clusters with 1000 users each doing Multi-FROST?

• Golden testing scenario is that users are online once a day and will make their sign/reject decision

• Performance analysis and scalability projection

• Craft a user interface for 100-256 DAO users. Each user listed in status as: unresponsive, pending, online, rejected, and approved:

  

• Is something forgotten for democratic control of wealth in general?

• Working next week :tada: :1st_place_medal: .APK to test...

[rahimklaber]

apk demo video in case apk doesn't work

Arxiv still has the survey on hold. 🤔

• I compiled shared libs to all platforms, so the app should work on all phones.
• I made the UI nicer and changed the signing so that the others now have to accept explicitly.
  • the grid does not actually work, I was playing around with it.
  • There's a page for creating proposals.
  • And a page for accepting/viewing your proposals.
• Fixed a bunch of bugs.
• I tested it and It should work with > 2 people, though I changed some stuff afterward.

I think I will work on making these things work and then maybe add extra stuff:

• Bitcoin integration
  • a form with fields for destination and amount.
• Making the sending of messages more reliable.
• Dealing with offline users during signing.
• Assume that everyone is online at the same time when someone wants to join.
• Save information in a database so the app can be closed
• performance analysis
• scalability analysis and recommendations
  • for example, batching the preprocessing step to increase scalability and performance.

Thesis paper brainstorm:

• Title?: A framework for true collective ownership of Bitcoin.
• idea/story:
  • Introduce the problem by saying that groups of people want to work together and need to own money collectively.
  • Show how DAOs are not good, and they are not actually decentarlized, etc.
  • Instead of DAOs based on smartcontracts and tokens, Threshold signatures can be used.
  • However, threshold signatures are expensive and do not scale well.
  • Frost scales well and can be used to allow a group of users control a bitcoin/cryptocurrency wallet.
    • Maybe compare frost to other threshold schemes and also multi-sig schemes that use smartcontracts
  • Introduce the app I built and explain how it works.
  • Show some performance graphs.
  • Show some scalability graphs.
  • Discuss how performance and scalability can be improved.
  • Discuss the shortcomings of this approach.
    • security?
    • reliable messaging?

[synctext]

• Solid progress, .apk worked!
• Please no Bitcoin yet, lets make a solid primitive which is stable, reliable, and testable.
• Insight into communication and ping success/response x seconds ago?
  • external IPv4, port (when clicking or detailing, something)
  • hashes are identities
  • last message log

[rahimklaber]

I didn't do much this time.

• The review got rejected from arxiv.
• I added a database that stores the details of your frost group, and all messages you send and receive.
  • when the app closes and opens, the FROST details are loaded from the database.
  • I will use the stored messages to to deal with members that were offline when a message was sent. Once they come online, they will receive those messages from other peers.
• At first I used EVA to deal with the reliable messaging problem. When I tested it, I saw that EVA won't work since the first message it sends is not sent again on failure https://github.com/Tribler/kotlin-ipv8/pull/63 https://github.com/Tribler/trustchain-superapp/issues/101.
  • instead, I sent a message a few times to account for failure. This was mostly needed to be able to use an emulator since the emulator's networking is unreliable. I haven't had any problems sending messages to the emulator, so this seems to work.
• added the activity grid.
  • 
• Added a test for the core FROST part of the application.

For the next weeks:

• send updates to peers when we receive a ping from them.
  • So imagine if peer A pings peer B. peer B will now send peer A any requests that peer B received and details regarding those requests. So if peer B is signing, then it would send in what stage of the signing it is. peer A could then request additional information if anything received concerns itself.
  • Not sure if I'll make it this complicated.
  • This should handle the scenario when a user might not have received a msg/the user was offline.
  • The only problem is that this will result in peers spamming each other. This was partly
• start migrating app to superapp and rewrite it in a nice way.
• start writing the paper. I think I have a decent amount of stuff I can write about.

[synctext]

• Master thesis graduation
  • [ ] Understand when and why single IPv8 UDP messages get dropped
  • [ ] Reliable networking
  • [ ] FROST 100-1000 people
  • [ ] Write something
  • [X] DONE
• not the most productive sprint
• first message it sends is not sent again on failure. Please fix that and document all fixes to EVA :+1:
• instead, I sent a message a few times to account for failure. Offline for a week differs from dropped UDP messages
• emulator since the emulator's networking is unreliable Weirdness is not allowed, please figure out whats going on. Buffer overflow of 31Kb socket? No incoming connections? No bug in the emulator framework: code coverage.
• Design a robust protocol which can tolerate churn. Participants of FROST rounds can go offline for a week, come online, automagically get synced with the latest messages, and resume the FROST party :partying_face:
• Lets pause FROST for now and get everything crypto strength, robust, fully reliable! EVA, messaging, emulator, etc.
• We need SIM cards soon, please coordinate with @InvictusRMC

[rahimklaber]

apk

• I made the system more reliable
  • I don't think there are other big issues with the core of the system. Though, I suspect problems with pop up when stress testing it.
  • I use timeouts + acknowledgements
    • I send a message and wait for ack. If I don't receive it I repeat the process 5 times. If at the end no acks were received, I consider the precedure to have failed.
    • I haven't noticed any problems. Though I have to be carefull, I found some bugs that depend on network latency and are therefore hard to debug.
      • This happened because I send messages without waiting for the previous message to fail or succeed.
    • I'm not sure how many times to resend or how much time to wait before timing out.
  • I tested the reliability by adding delays in the code.
• I added my app to the superapp.
• I tried writing a bit of the start of the paper, but its hard without writing bs. FROSTDAO.pdf

For the next weeks

• How nice should the app look? Maybe I should beautify it.
• Do some simulations and check how many participants can use frost without it breaking.
• write?
• Do you have anything you want me to focus on?

Before choosing to do just acks for reliability I spend time looking into other ways. I think a future project could be adding quic to ipv8. I know you said its too heavy, but you could have quic for peers you interact with often and then have normal udp for other peers/ messages. There is a java quic lib aswell https://github.com/ptrd/kwik. I played around with it and it worked.

[synctext]

• check the engineering :point_left: 1472 bytes
• The draft text lacks a nice storyline and goes too fast. We want a fully decentralised P2P DAO. Digital democracy, collective wealth, rise of the robots that do all our work, we take eternal vacation :tropical_drink:
• Find an application to sell it
  • Disembodied Artificial intelligent systems such as stock market exchanging bots take decisions and adapt to new situations based on formal specifications provided by humans., https://doi.org/10.1007/s12369-020-00686-1
  • read: Fairness and Freedom for Artists: Towards a Robot Economy for the Music Industry
  • SoK: Decentralized Finance (DeFi)
  • collaborative decision support systems
• Software-testing!
  • no gui
  • use IPv8 community cmdline clients to scale to 100 peers
  • If that works on 1 laptop: add packet drop
  • stress testing: packet drop, packet bit flips, and packet duplication
• key graph for experimental section of master thesis
  • 0, 1, 10, .. 75% packet loss
  • what FROST speed do we still get?
• integrate Bitcoin
• {repeating}
  • Wild idea: Create 10 Euro wallet, do FROST magic, give away 1 key, other key is kept private, with 50% threshold its possible to create a valid transaction. Do Reddit post on https://github.com/Tribler/tribler/issues/5984? Wait for anonymous stranger on The Internet to win this bounty. Simple minimal 10 Euro for honour and glory (in BTC)?
  • Wild idea2: Create a TreasuryTestDAO for WallStreetBets and test with this community. Donate 100Euro (in BTC) and the 10th person gets 1000 Euro for 100 Euro input :-) Oyeah, after this test it unlocks new feature. The "winner" can create a new DAO and determine the number of rounds, and treasury capital goal clap
  • Wild idea3: with voting
  • Master thesis level: {repeating from WallStreetBets issue} jonasnick establish the computational time for a 4.4million-out-of-8.8million multi-signature wallet (simple majority voting for DAO governance)

[rahimklaber]

• The frost library im using is audited
• Got the FROST IPV8 code running on my pc.
  • It takes some time though, as I have to wait for the nodes to connect to each other.
  • I had to fix some issues but I got it working.
  • First I tried running seperate instances of the program, but it becomes a problem since the JVM has high overhead.
  • Then Brian suggested i run everything in one program. So now I launch multiple IPv8 nodes from one program.
• I got keygen working with 31 nodes, but ran into problems with 32 nodes.
  • It turns out that the size of a FROST message relies on the number of participants, which I didn't realise.
  • if(msg.serialize().size < 1000){ The size of the message with 32 nodes would be around 1300 bytes
  • This can be considered as a bug :bug:
  • I also have to add a small delay when broadcasting data, otherwise the process will ocasionally get stuck. I'm thinking there is a race condition somewhere causing it.
• I changed the code to use EVA when sending large messages.
  • This fixed the issue and keygen now worked with more nodes
• I found a potential problem with using FROST over IPV8.
  • While doing keygen or signing, a node needs to know the ip + port of all other participants. So if there are 100 participants, then they all need to know about each other. It takes time to discover everyone else.
  • I also haven't been to connect 100 peers together, even after changing configs. The max I could get was 60.

For comparison I ran FROST keygen with and without ipv8.

• The massive jump that occurs around 30 nodes is due to eva being used.
• Signing should be much faster, since eva wouldn't need to be used.

[synctext]

• Five months of master thesis progress
  • achieved milestone of thesis level experimental results Figure
• Currently: one integration test within this code.
  • tries to see if FROST works
• I'm thinking there is a race condition somewhere causing it.
  • Security and reliability are critical for your master thesis :construction:
  • You deal with actual crypto money :money_mouth_face: :money_with_wings: :money_mouth_face:
  • {repeating} Software-testing!
  • {repeating} stress testing: packet drop, packet bit flips, and packet duplication
• its hard to debug, feel free to spend significant thesis time on this and include numerous code coverage, unit testing, end-to-end system testing, mutation testing, and deployment results in your thesis. (e.g. 50%)
• future-proof software testing architecture? Github Actions? https://app.codecov.io/gh/Tribler/kotlin-ipv8 ?
• Please be nice to the next master student on DAO tech :smile_cat: Make your FROST primitive stable & documented
• Next sprint focus: code coverage, software quality Thesis Results. Include inside thesis.pdf

[rahimklaber]

thesis.pdf

• I made some integration tests and added a code coverage table to the pdf.
  • The code is separated from the UI so I could test the functionality without having to touch the UI parts.
  • I tested almost all of the functionality. The things I didn't test are related to UI.
  • Next step full application test?
• I found and fixed some bugs and I was able to run some experiments without any issues.
  • Note: The experiments are not simulated or emulated. They are using real software and real sockets.
  • I believe I fixed the race condition.
  • I madea graph for the amount of time keygen and signing takes and I have a graph showing how much data is sent during keygen and signing. I am probably undercounting the amount of data sent.
  • I will also make some graphs on how packet drop affects the duration and amount of data sent. Though, I need to think about how to do it, since packet drop happens naturally during the experiments. Especially, when eva is used.
  • Maybe I'll also make a graph that shows the influence of latency. Though I don't think this is interesting.
  • I will make the graphs nicer.
• I wrote a bit and I think that I can write the paper quite fast.
  • What are the requirements for the paper?
• I started working on adding Bitcoin and am around 70% done.
  • I got bitcoinj working with taproot addresses and was able to send funds to a taproot address. I am using Bitcoin to keep track of the DAO account.
  • Potential issue: each input needs to be signed individually. So imagine the DAO account has a bunch of small inputs. In this case spending funds will need many FROST signature rounds.
  • Another issue I ran into. Bitcoinj won't connect to a peer unless the blockchain has at least 1 block. So when working on a private network you need to make sure that at least one block is created before hand.

Can we have next meeting in two weeks?

[synctext]

• :confetti_ball: works on PC, no longer Android dependant for testing with 50 node tests (bug!, no 51 nodes yet)
• "Collective Money Using FROST"
• See most recent thesis format example from Lab: zero-trust stuff
• 3 Background not optimal solution to introduce this tutorial in your thesis (2 pages)
  • First "Problem Description", then "System Architecture"? Like: our work is build around mature Internet-deployed foundations, like Bitcoin and the IPv8 networking library. These components offer... We augment ... etc
• Keep the scientific focus central, not too much engineering. Our goal is to provide an alternative for Big Tech and Big Banks infrastructure. We aim to create a universal primitive for collective money. Any economic activity with a group of humans of unbounded size should be supported. Furthermore, the transaction size should be unconstrained, from the fractional Euro cents to beyond one billion Euro of collective investment capital. The primitive is required to support financial transactions, lending is not in scope. With much further work we this work should in principle be able to evolve into a complete alternative global financial system. {or use Leaderless organisations as storyline foundation}
• Discussed requirements for mass-market uptake (1+ million people)
  • speed for new user to join (80 second keygen time + EVA tftp)
  • user interface, inherent crypto complexity, mental user model
  • open innovation model, requires to be seriously bug-free, extremely difficult to patch bugs in shipped library
• upcoming sprint goal: public push, finish Bitcoin taproot transactions, and experiment plan

[rahimklaber]

Can start setting up a date for the defense? thesis.pdf apk

• I wrote a bit about the experiments.
• I got Bitcoin to work. A member of a DAO can make a proposal to send a certain amount of Bitcoin to an address.
• it is not user-friendly at all right now, but it works.
• To make it simpler, I only use one Input per "proposal" since each input requires a separate signature.
• There is some stuff to handle if we want this to work well, which I probably won't do.
  • When a new user joins the DAO, the old inputs need to be migrated to the newly generated key. This gets complicated fast.
  • BitcoinJ is problematic and may cause failures due to not having the latest Bitcoin state. This is because I look up transaction data from Bitcoinj when signing.

[synctext]

• Code ? ? https://github.com/Tribler/trustchain-superapp/compare/master...rahimklaber:trustchain-superapp:frost_dao
• getting closer to graduation
• Too informal. "However, how can the banks be trusted given their history?"
• ?? "Problem Description"
• 25 BTC shared wealth :astonished: :open_mouth: :star_struck:
• The FROSTDAO app works in superapp!
• crashes often, no GUI for creation of proposals, but the core is there
• You Bitcoin thesis lacks the "why is bitcoin hot again" answer
• (sub-)screen of all other peers you discovered
• (sub-)screen of all other FROST groups discovered
• Ping to neighboring peers (not requiring a click-on-green)
• key thesis content: "radical experiment around democratic control of wealth'?

[rahimklaber]

I probably won't be able to show the app while I'm in Curacao so I made a recording. https://www.youtube.com/watch?v=CVgsn-JL4g0

I still need to add/fix a bunch of stuff, but its way nicer than before. I do the following in the video:

• I create a FROST group.
• I send Bitcoin to the shared account.
• I show how you can reject proposals, which will then fail if enough people reject.
• I make a proposal to send Bitcoin to the personal account of the phone on the right. Once the proposal is accepted, you can see that the balance of the account has increased. I'm running my own network, so I used the cmdline to mine blocks.

[synctext]

• Please put all coding and other stuff on hold: dedicated to thesis writing
  • timer starts today: 5 June 2023 for serious writing sprints.
• you have voting / governance / democracy operational!?!
  • not claimed in your thesis draft stoyline
  • Good luck fixing that !! Democracy is an essentially contested concept
  • The Myth of Digital Democracy
• It is going to be very tough to polish your thesis before end of Aug
  • [ ] write Problem Description
• [ ] Next meeting: please write a thesis-ready Problem Description section (if takes 2 weeks....)
  • Define DAO! economic activity in adversarial environment...
  • Requirements: decentralised, leaderless, permissionless, zero-trust architecture (e.g. transparent, open source), shared wealth, collective investments, and democratic decision making processes
  • Web3 or not in your thesis storyline?
  • Write 3 x 1 page Problem Description with monotonic increasing quality
• Discussed idea of a "Reddit FROST capture the flag"
  • release a FROST-based superapp (example of a student fork + release .APK)
  • give away information about private keys inside a reddit post
  • requires a tiny 2 minute Youtube demo for trust? (also: build from the source code)
  • measure how long it takes for people to transact on 50 Euro of shared FROST wealth
  • WallStreetBets? (based on our joint prior hackathon experience)
  • level 1: run the app and anybody can approve a FROST transaction to any wallet
  • level 2: use the disclosed private key to hard-code this into the source code and approve any transactions
• after a few completed chapters, next steps
  • thesis committee, for instance: https://www.wis.ewi.tudelft.nl/yang
  • Green Light Form on MARE :traffic_light:

[synctext]

Harvard Kennedy School on DAO.

Hubbard, Sarah, Connor Spelliscy, Nathan Schneider and Samuel Vance-Law. “Toward Equitable Ownership and Governance in the Digital Public Sphere.” , June 8, 2023. This paper explores how newly developed DAO tooling could help co-ops compete in the online economy. Specifically, we outline how DAO tooling could provide co-ops with:

• Effective Voting—DAOs test novel and varied governance systems that appear to offer some unique benefits not available to legacy organizations. These include systems such as reputation-weighted voting, holographic consensus, conviction voting, and quadratic voting.
• Increased Member Engagement—DAO tooling allows organizations to gamify milestones for their members, autonomously tracking the progress of members toward their goals, and rewarding them based on behavior. This encourages members to stay on task both for short-term gain and to develop a strong reputation in the long term.
• Predictable Compensation/Patronage—DAO tooling can offer insight into the contributions of community members and the payment systems that are directly linked to those contributions. Co-ops could use these tools to make patronage more predictable, transparent, and equitable.
• Organizational Transparency—Traditional co-ops, especially at scale, usually become less transparent to their members as they grow. In contrast, on-chain DAO activity like token voting, treasury management, and the payment of salaries and subsidies for public goods can be recorded on an immutable public ledger viewable by anyone with an internet connection.
• Member Accountability—It is often hard to identify rule-breakers and enforce accountability as a co-op grows. In a DAO using on-chain reputation, a user’s reputation can automatically change based on the quality and quantity of contributions to a community. Reputation can be non-transferable, tied to a particular individual or organization, and recorded on an immutable public record.
• Improved Capital Formation—Co-ops are at a significant disadvantage to corporations when raising the funds necessary to scale and compete. DAOs have started experimenting with alternative forms of funding that could ultimately be relevant to co-ops.

[rahimklaber]

Is this enough to start the defense process? I got a job which starts in September, so I'd like to finish before then.

I spent this sprint writing: FROSTDAO__Collective_Ownership_of_wealth_using_FROST.pdf

The writing still isn't that good, but I think it is much better than before. The figures need to be tweaked and a bunch of them are placeholders. I'm also missing references.

What do you think of the plots? I used scatter plots because you can quickly see the variability and because the graphs have a lot of values on the x-axis, so box plots did not look nice.

You mentioned that the problem description sounds more like requirements than a problem. I tried to change it, but I'm not sure how good it is. This is the old problem description:

The internet has revolutionized the way individuals collaborate and work towards a common goal, even across borders. 
However, despite this, there remains a significant challenge when it comes to the collective management of wealth.
Establishing a company or making joint investments can be complicated and cumbersome, particularly when the individuals involved are from different countries.
Existing financial services do not address this issue, highlighting the need for a novel solution.

We aim to solve this problem by creating a peer-2-peer leaderless decentralized system.
This system will allow groups of individuals to form decentralized autonomous organizations (DAOs)~\cite{DAO} that enable them to collectively and democratically manage their wealth.
The key principle guiding our approach is decentralization, ensuring that every aspect of the system operates without reliance on any central authority or intermediary. 

To achieve this, we envision a fully open-source system and transparent system that allows participants to examine and verify every operation.
There is no central authority, therefore transparency is crucial to be able to identify potential bad actors. Building an open-source system allows anyone to contribute and ensures that the system can evolve based on the users.

Our system should be accessible to anyone, regardless of their background or technical expertise.
To ensure this, we aim to create the entire system using only mobile devices, therefore maximizing the number of potential users.
To support many users, our system should scale to millions without reducing security or performance.

By constructing this decentralized peer-to-peer leaderless system, we aim to address the existing limitations of traditional financial services and provide a robust and easy-to-use solution for decentralized collaborative wealth management. 

[synctext]

• 9 thesis pages :rocket:
• Not only 2008, also in 2023 there was excessive risk taking. A bank run was carefully orchestrated to force the government to restore 100% of funds without limits. Basically, what normal people would call extortion. :boom: As there are no "controlled bank bankruptcies", there is no functioning marketplace sadly.
• Note: this is your thesis, so you are free to write your borderline political angle here. During grading time we will only judge the strength and citations in your line of argumentation. Ideological beliefs are obviously out of scope for an engineering degree or grade.
• :clown_face: Bank form a significant concentration of money, expertise, and political influence. We invent the uncoruptable saint in crypto heaven which can be used to share wealth of unbounded size with a group of people of unconstrained size.
• suggestion: truly \enquote{be their own bank}
  • Perhaps more explicit intro opening: "We seek to create a financial system without banks. Banks consistently go bankrupt every week. The oldest bank in the world is established in 1472, but it nearly collapsed in 2022. etc etc financial utopia, etc etc
  • More "we seek an economic primitive for the future financial system" or Bitcoin tweaks, lighting, and incremental engineering?
  • more "Social media-fueled bank runs"?
  • Blockchain Technology: Transforming Libertarian Cryptocurrency Dreams to Finance and Banking Realities
• "We achieve this without any overhead to transaction size. Our system can be used by anyone and is compatible with existing Bitcoin tools and services such as the Lightning Network and various mixing services." too detailed engineering for scientific intro
• Problem Description could be more explicit: "The dream of a decentralised financial system by crypto enthusiasts remains an unsolved scientific problem".
  • double this section in size; 1 column
  • COPIED: "The Icelandic financial crisis was a major economic and political event in Iceland that involved the default of all three of the country's major privately owned commercial banks in late 2008"
  • Little true disruptive innovations have been done in finance
  • We need a collective bank which can't fail. The decentralisation movement has crowsourced the Linux Operating system, Wikipedia, and now a Bitcoin-based transaction ecosystem.
  • The problem of collective investment, democratic wealth management, and collective treasury management remains unsolved.
• Design section
  • perhaps "unstoppable DAO" and DelftDao deserve a sub-section
  • "Delft technology stack" from 2020
  • MusicDAO, years of engineering to get this all operational
  • Re-write: 'Additionally, it results in a less complex system, as otherwise, every participant would have to broadcast to every other participant that they are ready to start'.
  • "3.2 Blockchain" :arrow_right: "3.1 Bitcoin threshold signatures" the enabling technology of the work within this thesis?!? Our core innovation is devising a threshold signature schema with unbounded scalability for the largest cryptocurrency, Bitcoin. However, our system still requires sufficient participants of being online and responsive.
  • Signing support an arbitrary threshold, initial Key generation requires 100% online, and every participant during the initial setup needs to be explicitly listed. Also altering the group size (join or leave) requires 100% participation for re-keying.
  • Add a Requirement section? Then you can easily talk about the things you fixed and stuff you leave for cryptographers to invent.
• With new job starting, ambition is 29 Aug graduation. This is going to be difficult, text needs lots of polish.
  • https://www.tudelft.nl/en/student/eemcs-student-portal/education/graduation-msc/assessment/requirements-timing
  • These rules require a 20 days ahead draft.
• "At this point, the size of messages sent during key generation is no longer small enough such that the UDP packets are delivered reliably." This is the point where we want exactness and details. Upto 16 is OK. What is then the packet size? What is in a packet exactly? what is the byte format? What is the packet loss inside your laptop and UDP socket buffer? Re-transmission stats of IPV8 TFTP protocol? Initial handshake resend?
  • Read Digital Euro on EVA TFTP, by Robbert.
  • take his fixes please!
  • "Figure 6: Sequence diagram of the signing procedure. The diagram shows the procedure with two participants."
  • nice high level picture
  • also discuss the details in thesis, see protocol specs example of Tribler
  • list the exact fields and each byte also for the voting and threshold crypto message
• ToDo for this sprint: make first chapters thesis-ready.

[rahimklaber]

FROSTDAO__Collective_Ownership_of_wealth_using_FROST.pdf

Aside from the abstract, I think the writing of the first chapters is decent.

I spent a bit of time looking into EVA. The main problem is that it does not support concurrent transfers to the same peer + there seems to be a 20 second duration before this is reset. Key gen only needs to use EVA once per peer, so I don't think this is a problem in practice. But in my experiments, I do key gen from 2 to 50 members sequentially.

This is from https://arxiv.org/abs/2203.00398:

I optimized the serialized of the message, so EVA is not needed so early, and I played around with the EVA code:

[synctext]

• "Problem Description"
  • more a line of argumentation, Wikipedia, no controlling company, bank, smart contract
  • Define common wealth, leaderless, self-organisation. Then give a precise definition.
  • Example: We focus on the problem of wealth under democratic control. Our problem is to enable a leaderless group of collaborating humans of unbounded size to democratically control a Bitcoin wallet of unconstrained wealth. First our leaderless problem .... unbounded size, scalability..self-organisation...democratic control..simple majority voting...
• "System Design"
  • democratic decision making, simple majority voting is different from raw message format
  • move to implementation, "Each participant creates a signature and sends a signature share message to the proposer after receiving preprocess messages from every participant."
• "implementation"
  • "4.1 Collective wealth" after we dream about Utopia, it becomes a "4.1 Shared Bitcoins Wallet" in the implementation
  • "We have created an Android application that partially implements our design." it builds upon superapp, so more: our work expand the Web3 protocol stack under development for several years at Delft University of Technology which contains experimental support for Bitcoin Taproot, Bittorrent streaming, trust framework, self-sovereign identity, offline digital Euros, and decentralised learning.
  • Aug 2020, Technology Stack for Decentralized Mobile Services (Matt Scala)
  • Mar 2021 Towards a Robot Economy for the Music Industry (Tim Wissel)
  • Mar 2022 Web3: A Decentralized Societal Infrastructure for Identity, Trust, Money, and Data (Joost Bambacht)
  • July 2023 First Deployed DAO with True Full Decentralisation (Brian Planje)
  • July 2023 Decentralised recommendations with trust and relevance (Rohan)
  • July 2023 Towards Sybil Resilience in Decentralized Learning (Thomas)
  • "4.2 Joining an Organization" difficult problem of DAO discovery
  • "However, harder-to-test code, like the UI and Bitcoin code, is not well-tested.", look at integrating Espresso in future with UX event triggers and tests.
  • "This is not a problem in smaller networks (30 members) but becomes a problem in larger networks.", see 1995 and beyond foundations. Atomic broadcast: From simple message diffusion to Byzantine agreement
  • "Figure 9: Amount of data in Kilobytes sent during key generation and Signing", please alter smooth line into 48 measurement points.
• Thesis contains a bit too little substance currently
  • Single laptop experiment
  • What is the source of EVA packet loss/failure?
  • You got a Rust library to work on Java. "To support threshold signatures, we used an audited open-source Rust library [22]. We created a wrapper around this library and then exposed the wrapper to Android via Java’s native interface [23]. After the key generation procedure, each participant receives a key share. "
  • More substance is needed, either science, social, or engineering.
  • Warning: this is a know hard engineering problem. Also unappreciated by many. A P2P binary transport protocol. "EVA does not send the data immediately and instead schedules transfers in the future, which results in a large spike in duration." possible angle: We enhanced the EVA protocol with a very aggressive setting. In aggressive mode re-tries are done after a mere 250ms timeout and re-try check are scheduled every...etc.etc.
    • "serialized of the message" faster :medal_sports:
    • reset duration
    • re-transmission timeout
    • scheduling delayed sent (:open_mouth: let me just wait a bit and take a break :zzz:)
    • etc.
  • Science: enhance Frost? scalability? rounds?
  • Social: experiment with voting and test your prototype with the max. 18 participants.
  • :astonished: You got a fully implemented, fully automated, and fast workflow for "skeleton wealth management" (expand, invest, adjust, etc). You got the Activity grid working? Not mentioned or claimed as result within thesis.
• Finishing this for 29Aug graduation is very ambitious.

[synctext]

Delft literature survey, 20 DAO participants is the tipping point for sustainability.

[rahimklaber]

FROSTDAO__Collective_Ownership_of_wealth_using_FROST.pdf

• added EVA investigation.
• added more content about the app.
• more expirements.
• other small things.

[synctext]

• Reads like a real master thesis :rocket: :rocket: :rocket:
• Please prepare an Arxiv formatted version for uploading, my author ID, http://arxiv.org/a/pouwelse_j_1
• upload to TUDelft repo before defense and form filling: https://filelist.tudelft.nl/Studentenportal/Faculteitspecifiek/EWI/Studeren/Formulieren/MSc%20formulieren/CS/Final%20Examination%20Form%20MSc%20programmes%20EEMCS%20v21042023.docx
• Status of code is old, please publish your code!
  • https://github.com/Tribler/trustchain-superapp/compare/master...rahimklaber:trustchain-superapp:frost_dao
  • Thank you for fixing! https://github.com/Tribler/kotlin-ipv8/compare/master...rahimklaber:kotlin-ipv8:fix_dispatcher_main
  • Prior Robbert EVA fixes: https://github.com/Tribler/tribler/issues/6306#issuecomment-1455785746
• you thesis could use more exactness, such as mentioning private val maxSimultaneousTransfers: Int = 10
  • same exactness for 51 peers and IPv8 peer discovery limits?
• "We focus on the problem of wealth under democratic control. Our goal is to enable a leaderless group of collaborating humans of unbounded size to control a Bitcoin wallet of unconstrained wealth democratically" This is the perfect opening of the Problem Description. Please move the introductory text to the intro.
• minor polish. Too similar "Existing solutions suffer from various problems. They are either expensive in terms of Bitcoin fees or expensive in terms of computation [10], [14]." and just a bit later this repeats: "Existing DAOs have several problems."
• "IPv8 employs hole-punching" unclear, also mention the terms UDP and NAT briefly.
• "do not have a dedicted public IPv4 address [20]."
• "In this case, the organization could be overtaken by a Sybil attack[21]." suggestions: Secure identity is a known hard problem and a known DAO security concern. Please consider promoting our SSI work with [a citation]
• "In contrast to our design, accepting an entrance fee and migrating funds from the old account are not implemented." suggestion for reformulation: Our proof-of-principle prototype lacks features such entrance fee and migrating funds when a new user joins.
• "The DAO can make investments and spend funds by creating and accepting proposals."
• "Any members of the DAO can create a new investment proposal."
• "to create fake testing Bitcoins"
• "Figure 11: Figures depicting activity grid of a DAO with 25 24 members". Off by one error :1234:
• "We did not have enough phones; one phone was used, and the other members of the DAO were running on a computer. " Experimental setup details are not for Figure text. suggestion: For testing purposes the screenshots are obtained from a real Android phone, while others DAO members executed from common PC hardware.
• "Figure 15: Duration of the key generation running on the improved ??? IPV8 stack using our EVA and serialization improvements."

[rahimklaber]

draft_presentation.pdf

[synctext]

• [ ] arXiv upload
• [ ] thesis defense calender invite

Review of draft master thesis presentation:

• few screenshots and walk-through of app
• slide 3: "Blockchain", what does it solve? first practical solution after 30 years of crypto money theory +limited transaction rate
• slide 4: add more scope and potential impact: the future of the firm in the robot economy
• slide 4: only known theoretical paradigm for public alternative of Big Tech services
• slide 7: 1 group == single shared wallet approach
• slide 9: "this thesis: FROSTDAO"
• slide 9: first add another slide with conceptual and architectural principle that you invented in your master thesis. List of requirements?
• slide 9: real code, real money, really feasible. Beyond just a screenshot.
• slide 10: viability test of FROST in thesis process? {move earlier, available crypto magic tricks} FROST citation!
• slide 14: + "experimental setup" goal is to understand scalability
• slide 15: expand picture, more clarification text
• slide 16: vanilla libraries, before performance improvements
• slide 16: 5 measurement results for each network slides
• slide 18: more depth; 40% improvement ???
• slide 19: nobody understands now; including me. Explain.
  • limited smartphone hardware, no PC
  • Four actual devices experiment
  • real wifi networking
  • Outcome: slowest device constrained
• slide 20: much work to be done for shared wealth in Web3
  • state-of-the-art crypto primitive does not meet requirements
  • FROST fails to scale to 1-2 billion Web3 users
  • reason: Key sharing phase with cubic complexity
  • sharding into sub-groups of 50-100 people?

Collective money, FROSTDAO learnings

Approach	properties
Multisig: Bitcoin scripting	requires all public keys and signature of entire group. Bad scalability
FROST threshold signature	single shared wallet, cubic growth of complexity for key generation.
Random lottery function	loosely binding of goodness and income. Only converges to equality with infinite runtime