Thesis: Artist Investment Token

[synctext]

Thesis: replace music industry with open source code, including the investment part.

Wealth has accumulated with a select few: the investing class. The rest of the world belongs to the worker class. Digital technology is breaking the monopoly on investing. We prove the viability of our ideas with an Internet-deployment focused on an industry that operates purely digitally and has deep rooted monopolistic culture: the music industry.

Prior work: Tribler/trustchain-superapp#45

We automated the music experience. Previously we build the code to directly link artists with their fans (e.g. open source Spotify app). This thesis is focused on the discovery and growth of new talent. This thesis aims to bootstrap a sustainable music ecosystem without any music industry. Any citizen is able to invest in upcoming artists. Investors support artist and enable them to create new music. Investments ensure that rent gets paid, day jobs can be quit, and professional equipment can be procured. Investments pay back when the artist releases new material and income is generated. The zero-server technology stack of Delft University is used, see MusicDAO. The Android-to-Android networking stack is able to communicate music, money, and trust without relying on any central server.

In technical terms the investor simply send Bitcoins to the artist wallet. New Creative Commons music is released. Fans reward the artist and the investor can be paid back. Enforcement of honesty by the artist is out of scope of this thesis. We assume reputational mechanisms are sufficient and no crypto magic needs to be attempted. The usability of the MusicDAO needs further improvement. Discovery of new music is too slow. Connect to main Tribler network: IPv8 Tag Community. Performance results could be obtained during a 2 week observation period after release on forums such as Tweakers.nl and TorrentFreak.com. Thesis format will be an 8-page IEEE formatted scientific article, with additional Delft blue mandatory covers. See zero-server stack IEEE article example.

First print goal: compile musicDAO, inject music, no dumping of code please. Just build upon existing code, fix what needs fixing. Discover music on a 2nd phone. Make a new .APK

[Dmole]

Existing solutions https://blockonomi.com/youtube-alternative appear to lack popular creator adoption required for average people to leave the convenience of patreon/youtube/etc.

[synctext]

Background info. New music seems a failing market. Music industry has declining new artistic output. Record label policy is now to never listen to new stuff or read here.

[Dmole]

They say those conclusions are from this data
https://www.billboard.com/charts/year-end/hot-100-songs/
but the data seems to disagree; it's new music (released in the year).

Billboard has some data that excludes online content so maybe they looked in the wrong place.

The billboard data seems to be OK; I checked a few youtube videos with a 1B+ views and they showed up in the year end data.

[brian2509]

Sprint Update

• Got more familiar with code and concepts; serverless-infrastructure, BitTorrent protocol IEPs, code-setup
• Compiled trustchain superapp with musicdao
  • Intermediate goal was to get the minimum completely decentralized version working i.e. 2 participants on network should be able to use it successfully (making use of DHT instead of trackers and open port needed to enable accepting connections/not be firewalled, added a settings page for this)
  • Fixed numerous bugs to achieve this, but still flaky behavior
  • Worked on separating code such that UI separate from logic/algorithms, currently very intertwined -> hard to fix bugs, test and evaluate, can for example not be called from a CLI

Small demo; music hosted on other phone & screenshots other version


app-debug.apk
app-debug.apk (more stable)

[synctext]

• very impressive fast start 😲
  1. inheritance of 12 months of prior MusicDAO effort
  2. traced and fixed critical bugs {off-by-1 gossip never worked for 2 phones in small IPv8 network sizes}
  3. working .APK
  4. New UI!
  5. For bonus even a demo video
  6. https://github.com/brian2509/trustchain-superapp/tree/music_dao_new
• new shape of music industry
  • Everybody can start music composition https://en.wikipedia.org/wiki/Ableton_Live
  • soundcloud music artist discovery
  • broader talent pool, higher quality level for starting music artists and self-improvement Internet tutorials
• Critical that the code is of high quality, for "a library to replace Big Tech"
  • docs
  • code coverage
  • tutorials
• Web3 discussed:
  • what is the societal economic infrastructure by 2050?
  • no intermediaries
  • forced to pay fee currently
  • powerful monopolies block Web3 uptake
  • Utopia, user are unaware that they use decentralised technology: It-Simply-Works
  • Facebook is far from dead, its even a profit beast

Next sprints: perfect low-level network connectivity, code quality, artist tokens, etc.

[brian2509]

Sprint update

• Moved to the different codebase described in previous sprint update and further worked on making the base functionality work
  • Main focus was on getting the infrastructure more robust i.e. pushing the project closer to where it can be used without using Android, also some user interface work to get it to a minimum viable state at least
  • Re-wrote a lot of torrenting logic
    • Discovered a lot of unexplained behavior due to finding out libtorrent is very sophisticated; queueing logic and auto-managing torrents is default and have lots of default limitations.
    • Had a problem for a long time of info-hashes seemingly not being created deterministically which is fixed now
• Minimum peer to peer (2 phones) situation is now working ~reliably with use of DHT discovery only (no trackers) and Trustchain gossiping
• Small demo again; music hosted on another phone and going through some of the functions (search is local still)

app-debug.apk
app-debug.apk-new

[synctext]

• yet again, impressive engineering progress!
• Business ideas: 'the music industry should have frictionless movement between record labels and hosters. Similar to the telecom industry, you can seamlessly switch and SIM-card based customer lock-in is a thing of the past.'
• read several master thesis reports in-depth for a clear understanding of "master thesis level".
• You need 8 pages of text with 5-ish figures, see Joost example
• At a later stage, find, list, and read scientific literature on Scholar.google or the term tokenomics
  • scientific observation for thesis content: 'Section 4.3 Zero-token approach. . . Many speculative projects use a token for governance. This thesis shows no native token is needed. Bitcoin cybercurrency can be used for everything. Trustchain is the ledger that makes it scale. etc.'
  • We dont need anything like this.
    
• At a later stage, scientific 1-page write-up: your thesis is more generic than the music industry. No need to show that other then in writing. like: working class... break the monopoly of the financial world, 'Digital technology is breaking the monopoly on investing.', we aim to reduce the barriers to entry, everybody can become an investor, robot economy is about sharing equally hopefully and eternal vacation for all humanity 😆 , etc
• Lean and mean code: zero over-engineering please
• This is what you are experiencing at a smaller scale, working with merely a vague end-goal. its the inefficient science and innovation process
• Coming sprints: 'fix the app' ⛑️

[brian2509]

Sprint update

• Design work on DAO/artist investment token and good meeting with AFM supervisor about different DAO models and their requirements/enforcement, but no conclusions yet. Some interesting points.
  • Legal enforcement should not be a requirement or in scope, not interesting here
  • Model that shows some similarities are a “jury/witness model” such as BisqDAO which works with a P2P network and hash commitments to Bitcoin in combination with a a chosen jury of contributors that solve conflicts and are paid in fees
• Implementation
  • Add and integrate local cache using Room (SQLite) for non-trust chain data; this removed almost all file system crashes
  • Add and integrate Dagger Hilt for dependency injection and move app to this, will make codebase more robust
  • Peers can now publish and update meta-data on themselves (profile) which others can see in the app as profiles
  • Attempted getting Bitcoin working with a regtest
    • Set-up a Ubuntu VPS, tried to set-up regtest manually and tried some docker images which do work but bitcoinj does not sync up yet
    • Wallet now implemented in app, connects to peer but does not sync
  • Having a lot of difficulty with gradle in super-app; hard to add dependencies or bump versions
  • Further bug fixing
• Design work on meta-data infrastructure for information not-related to tracks i.e. artist information, future token information, income, expenses, etc.
  • Ideal requirements: fully p2p, equal responsibilities, no “service” providers
  • Current approach: close to default Trustchain approach, but active periodic gossiping included for higher availability. Information is self-published in chain. Information is requested from peers or crawled when not available locally.
  • Problem: some meta-data should be updatable i.e. payment public keys. This is similar to revocation problem (hard). Current approach is re-publishing and marking latest known information as valid.
  • Different interesting (but complex approach) would be something like BTDHT but with public keys of users as keys in the table. This way a section of the DHT is responsible for keeping someone's chain (and thus meta-data) available.
    • Might provide some other guarantees; presumably less messaging / more throughput and more reliability
• Reading
  • Read few master thesis to get idea of master thesis level
  • Read papers covering some of the problems in music industry
  • Read up on IPv8 and Trustchain documentation and TrustchainCommunity implementation

open

app-debug.apk (will override current debug apk)
app-debug.apk (no google services, but seperate apk)

[synctext]

• Yet again again, impressive engineering progress!
• PR! First priority: push to main!! (available to all msc students in course)
• System of strangers:
  • First-class citizens: dealing with untrusted strangers
  • Spam, abuse, fraud, and freeriding
  • Everything else is secondary; performance and even features.
• Uncompromising requirements: fully p2p, equal responsibilities, no “service” providers
• Minimal Viable Investment Token ("MVIT")
  • rely solely on the good will of the artist.
  • No witnesses or other fragile mechanisms
  • Possibly the default platform behaviour is to bias the search results. Artists which give back are promoted, artist which are not giving back investment plus have positive income; those are demoted. Social contract. Or is this a step towards "Cancel Culture" and should be avoided?
  • Science breakthrough is a real DAO, thus an DAO-like "artist investment collective" is cardinal milestone
  • Overlap with class 2022 Blockchain Engineering (nobody selected that one 😲): You will repair the core flaw of Bitcoin: the lack of scalability. You will create Schnorr Threshold Signatures compatible with the live Bitcoin network and Android. Goal: to unlock the collective ownership of money for groups of millions of people; the core of any DAO. Nobody has ever been able to realise this cryptographic primitive. Nobody. You might be the first to crack it 1st_place_medal (or learn lots of "Blockchain Engineering"). Reading: the FROST algorithm, some details on Taproot upgrade our non-scaling DAO, and partial FROST.
  • Current legal rules, today's investment rules and enforcement issues are all out of scope for this scientific proof-of-principle. we uncompromisingly focus on tomorrow.
  • Just take 100 albums from here, for instance. That is enough for scientific proof-of-principle. They promote their BTC wallet!
  • MusicDAO general operation
    • Donations to artist are verifiable and auditable
    • We exclusively rely on donation tracking, audience tracking is for another master thesis
    • Artist profile: wallet, albums, investments, and donations
    • The single "artist investment collective" is central to the MusicDAO, they vote on investment proposals by artists
    • every artist can make proposals via signed Trustchain records (for instance)
    • First focus on Taproot n-of-n signatures. Thereby first avoiding the complexity of Merkle tree explosion for n-of-m voting.
    • Thesis focus is then the enabling investment application and the world-first realisation of DAO investment mechanism (zero-server architecture and no governance token needed)
    • Royalty token idea? (thesis is 45 ECTS, 9 months only)
• Possible end-game: publish on Torrentfreak "Get free Bitcoins to give them away to artists" for live trail and Taproot 1Euro transactions.
• An operational Bitcoin Regtest already exists in Superapp
  • Taproot.tribler.org documentation const val REG_TEST_FAUCET_IP = "131.180.27.224", the call itself and documentation here
• re-implementation of Joost his work on binary EVA protocol for UDP transfer of social profile picture, etc.
• Quality of life improvements. Polish. No fresh music in 20 seconds during first usage;
  • refresh works! 3 albums in latest version music discovery experiment.
  • event when background downloading is complete
  • automagically play music
  • automagically goto next song

[synctext]

Related: https://royal.io/editions/verite-hes-not-you
https://polygonscan.com/address/0x7c885c4bFd179fb59f1056FBea319D579A278075/advanced#code

[brian2509]

Sprint Update

• Main things I am working on: bitcoin integration and adding arbitrary torrents / mass seeding of torrents. Some early design decisions are popping up now and making things a bit difficult.
• Initially I opted to only use magnet links for simplicity, but due to some limitations in jlibtorrent (requirement of .torrent metadata when seeding with N = 1) .torrent files will have to be cached and downloaded. Currently working on this and is almost ready (bug-free).
• Regtests networks for Bitcoin do connect but do not synchronize blockchain, other than the currently live regtest of Tribler. Tried different regtests setups (1 2 3 4) and investigated different causes but no luck. The currently online regtest does seem to work and synchronize, but faucet seems to be broken. Will probably need access to (http://faucet.tribler.org/) (185.199.108.153) or 131.180.27.224 to enable/fix it or find a fix for my own regtest network. After this will be able to work further on donation tracking.
• First visit to the AFM office and some meetings with the supervisor. Crystallized some further thoughts on this DAO:
  • Currently not a lot of legislation for DAOs if official institutions (i.e. banks/brokers) are not handling the assets: all transactions could be considered as just P2P transactions. However, this will mainly depend on 2 parameters: level of enforcement through the code in DAO and what a artist giving out tokens promises (i.e. music, ROI, nothing, etc.).
• Created scripts for automatically "collecting" music on some Creative Commons sites and create .csv's of collection of music of EP's/albums, some of which are being seeded off a phone currently.

apk-debug.apk

[synctext]

• related work: https://scholar.google.com/scholar?q=web3
• Brian review of State-of-the-Web3 lab:
  • IPv8 excells at P2P communication
  • However, everybody needs "data storage"; no 1st class citizen support
  • Difficult to do a uniform primitive (EVA protocol is slow on Kotlin, some business use-cases require cheap bulk storage; low-latency {like 8x8 thumbnails serving after a Youtube query}, etc.)
  • decouple the MusicDAO from single monolith (investment,data,ID,Bitcoin,recommender, federated machine learning)
  • Unexplained lag for jlibtorrent. Audio streaming should be instantaneous with a dedicated tracker. Great for master thesis experimental work: graph with MusicDAO original and MusicDAO Brian edition time-to-first-play.
• MusicDAO is becoming usable for real music listening 👏 🎊 👏
  • ToDo for future sprint: get some Creative Commons classical music, to help a distinct audience
  • Upcoming sprint: BTC faucet and donations

[leonardusjoannes]

How to circumvent another Nobel prize winning theory: https://en.wikipedia.org/wiki/Incomplete_contracts

[synctext]

Related work to artist investment DAO

Type	Dao	name
centralised	Molochdao
centralised	Gitcoin round 12
centralised	Optimism funding
centralised "Biometric Financial"	GovernorDAO Proof of Existence - Solved Sybil Resistance using no-KYC biometrics 🤣 😆 🤣
centralised	traditional VC investment of Billions. The DAO model only needs to grow a million times 😲

[brian2509]

Sprint Update

• Got access to tribler domain node for regest and fixed the server and faucet. Now working and online.
• Scraped more CC albums and added UI to auto publish large amounts of album meta-data from a formatted .csv
• More bug fixing; mainly in torrent logic/seeding
• Work on wallet functionality: syncing works, transactions viewable, faucet is working from UI
• Ability to send donations to other users through their (update-able) published bitcoin public key on the regtest. Also laid groundwork for proper book-keeping of these transactions on trustchain.
• Went to AFM a few times (intro-dag too); will set-up some appointments with people. Already met someone who is an expert and working on new crowdfunding laws on EU-level by ESMA.

apk-debug.apk

[synctext]

• Testing your app
• legal rules for crowdsourcing on 1 of my slides: https://github.com/Tribler/tribler/files/8369503/future_of_banking_v9.pdf
• Currently no testing, no code coverage, no quality assurance process: https://github.com/Tribler/trustchain-superapp/actions/workflows/build.yml
• Discussion of UUID purpose, beyond SHA1 as identity. Pollution,spam, duplicates is not in scope of thesis.
• Brian philosophy: user unaware of tech. No awareness of Bitcoin and or Bittorrent. Needs to move to background or completely disappear; because ☑️ works! 👷
• Thesis completion roadmap ???
  • MusicDAO: skeleton of Creative Commons Music Playsback (Tim thesis repair and improve)
  • FROST integration, but first stand-alone stability and feature "Minimal Viable DAO" system.
  • Before 13 April reproduce FROST and conduct review of their code
  • User enrolment - artist investor, FROST k-of-n wallets
  • Performance measurement, essential thesis graphs and scale to 1 million
  • repeating The single "artist investment collective" is central to the MusicDAO, they vote on investment proposals by artists
  • Document and DONE with THESIS 👏
  • December 2022

[brian2509]

• Getting familiar with crypto primitives to understand taproot/schnorr signatures/threshhold-signature schemes / FROST more, lots of reading
• New laws are incoming on EU level (ESMA) (site) (report 2) for the crowdfunding model
• Slowly starting to get into scope what minimum-viable crowdfund DAO, contribution, and realistic scope could mean. In short 3 basic functionalities: enrollment, leaving and collective spending of funds. Here is one model that could be used using threshold-schemes.
  • (the following is from what I understand right now; details need to be worked out and checked)
  • Challenges are:
    • Ownership of financial assets rely on the security model of Bitcoin which has been extended by Taproot, but is still limited
    • Needs to scale to a large amount of users N; thresh-hold checks / voting should not be done "on-chain" (with non-participating nodes running a computation)
  • Collective funds will always be locked by shared private keys
  • Creation of a shared private key (distributed key generation) can be done off-chain through ipv8/trustchain (could be seen as layer 2) using FROST
    • Some parts are interactive process, however trust-chain can possibly be used to make interactiveness less strict of a requirement by storing messages for users
    • Message complexity needs to be investigated for large N
  • Spending collective funds requires signing procedure (done on ipv8/trustchain)
  • There is an implicit governance model. The control of 50% of public keys decide what happens with funds (given 50% thresh-hold scheme)
  • Choice needs to be made what a public key entails in this scheme, every choice has disadvantages and attacks however:
    • = user (1 person)-> most likely need use of SSI and most likely need some sort of minimum funding amount to avoid free-loading
    • = some amount of bitcoin (i.e. 0.01) -> we get a governance model where voting power is proportional to amount of funds someone deposited
    • = something else
  • There is a difference between an closed fund vs. open fund -> one-time batch creation of a shared key vs. the joining of users 1 by 1 (or possibly batched) and continuous creation of shared keys with accompanying re-locking of funds with new keys

Another route that I read about quite a bit is some sort of BisqDAO model with off-chain storage and execution of "smart-contracts" on ipv8/trust-chain with commitments of the smart-contract state to Bitcoin to prevent double-spending. Difficulty is that ownership model of Bitcoin is still limited.

[synctext]

• Focus: Minimal Viable DAO
  • Join model: n = m + 1. Only single operand is supported: 1 new user joins (or leaves, but that is optional non-MVP).
  • Each public key equals a single vote (governance keys)
  • Fixed voting threshold or fixed function (20 people, 2000, and 20 million WallStreetBets level of mass usage)
  • Fixed amount of Bitcoin to join
  • Single Artist Investment Fund
  • Not a Crowdsourcing Funding Provider, everything peer-to-peer. No platform. Nobody has any control or managerial authority or privileges.
  • Each join and leave equals a transaction. 1 Million real Bitcoin transactions to grow to 1 million users.
  • Ignore the scalability problem. We will create a Bitcoin2DAO for that. Sole purpose is to create Bitcoin2 network, new wallets, 10000x transaction rate and at intervals settle to Bitcoin1.
• Enhancements brainstorm:
  • Dynamic Digital Democracy. Problem is that the DAO could become dead when voter participation turns out to be low. Will only 30% of token holder vote or 51%? Bitcoin Script can track progression of time. If the MusicDAO is idle for over 6 months and nothing gets past the threshold its possible to trigger a correction. Possibly we need to pre-configure these keys and switch (1 vote after waiting 10 years, 10% after waiting for 3 years, 20% 2 years, 40% after 6 months, 51% wallet keys instant usable). Voting threshold gets lowered steadily and continiously down to a single voter to pass changes. We dont want to lock up Bitcoins indefinitely. Or do something smarter? We specifically will never implement a treasurer role which gets full access after 10 years, its should always remain P2P.
  • Dynamic participation. Alternative to a fixed amount of Bitcoin to participate. Any fraction possible.
  • Leave the DAO and return a fraction of the unspent coins. Actually hard. Could be implemented as a transaction which only requires your signature for funds below you current unspent coin threshold.
• usability??: infinite scroll of cover art, play next song when swiping?

[leonardusjoannes]

Leaving of the DOA or longer period of inactiveness: return funds to the initial investors. (at least as ambition), can the investors decide to "collectively" (t<n) leave the artist.
Also investors might prefer to not use their voting right (cause they reley on the others, reputation from earlier investments)?

ps is there a "working definition of a DAO"?

[leonardusjoannes]

definition from coin desk (https://www.coindesk.com/learn/what-is-a-dao/)
A decentralized autonomous organization, or DAO, is a blockchain-based form of organization or company that is often governed by a native crypto token. Anyone who purchases and holds these tokens gains the ability to vote on important matters directly related to the DAO. They typically use smart contracts in place of traditional corporate structures to coordinate the efforts and resources of many towards common aims. These are self-executing computer programs that carry out a particular function when certain conditions are met.

questions:
Is a DLT/blockchain a prerequisite for a DAO? (or is it without just an autonomous piece of software?), read in the article the thought experiment on a driverless car) --> is the DLT only there for the onstopable aspect?
Is voting a prerequisite? (can you have a DAO without voting? think so)
I think a DAO is driven by "horizontal governance", where a traditional firm is by "vertical governance".
The voting may lead to more vertical governance?(voting may help to circumvent/mitigate "contract incompleteness")

[leonardusjoannes]

Suppose you model the music, the proposals etc as an "NFT" alike tokens....how generic does the Music DAO get?

[brian2509]

• Had an absent week (sickness) so not as much progress as I would like to have
• Good questions above and we discussed them in person now as well
• Worked on reproducing FROST code of FROST team; basics seem to compile and work
  • Preferably want to work with newest code additions (https://github.com/jesseposner/secp256k1-zkp/tree/frost) due to current repo not being a proper fork of this repository above
• Currently reading through FROST paper but have not finished yet, reading up on again on crypto primitives as well (https://cryptobook.nakov.com/)
• Will work in kotlin-ipv8: extend library such that it can be used on top of ipv8-overlay network that can be used for peers to generate shared public/private keys and sign messages together with said keys. Can be used by other applications in the future and also for the current DAO protocol on Bitcoin. The rest of the DAO protocol essentially is enforced through collectively deciding what bitcoins transactions are created and what transactions to sign.
  • Work needs to be done in kotlin-ipv8
  • Qualitative tests (e2e-like) required in order to get confidence about workings
  • Quantitative tests/performance evaluation can be done by running ipv-8 nodes locally
• Have some notes about protocol on paper but rather messy due to still not understanding some parts, aiming to make document this week

[synctext]

Nice research idea! Generic "share key management" within IPv8, solid idea.

• Enable maintenance updates of smart contracts, instead of static Ethereum approach
• Blockchain height as a global clock and dynamic threshold voting. should work...
• Trustchain multi-party agreements, how to enrich with n-of-m Schnorr signatures? majority group agreement
• dataset which is great for collaborative AI inside your DAO, specifically your learn-to-rank dataset

[synctext]

intro suggestion:
This thesis present technology for radically altering the business landscape of music. Other work is progressing on the creative side of music. For instance, music generated by AI is now approaching the level that it is refreshing to hear. Citation: "Jukebox: A Generative Model for Music" by OpenAI.

[brian2509]

• Some notes I've written down: https://brian2509.github.io/test-123213/.
• Currently working on getting this https://github.com/taurusgroup/multi-party-sig running in kotlin-ipv8 using https://github.com/golang/mobile. Most complete implementation of the protocol and working with Go gives much less difficulty compiling opposed to some other set-ups, am making progress, but having type conversion issuess. If this proves to be too difficult I will return back to the secp256k1-zkp version (which I had difficulties compiling with). List of other references can also be found in above notes site.

[synctext]

Copyright-free image, free to (re-)use. Workshop of the first true decentralised DAO deployment. Comment on your latest master thesis draft:

• introduction; easy to digest as a blog post would be. Then switch to dense and more exact scientific language. Explained fake decentralisation already sufficiently in intro?
  • To date, all DAOs are still centralised to some extend add 6-12 sentences with centrality in ??MakerDAO, Uniswap, BitDAO.
  • Limit your scope in intro {suggestion}: 1) DAO==Cool, 2) fake decentralisation only, 3) proof-of-work limit with few mega miners + proof-of-stake centrality with a new elite. 4) we present the DAO breakthrough that humanity always needed, but never had /sarcasm. Nothing more; keep simple.
  • DAO == Cool: Billion of users already work together and consumer knowledge on Wikipedia. We imagine DAO technology to mature one day to empower alternatives for Big Tech. etc.
• "problem description"
  • put something more clear and scientific in definition with italics.
  • We define a DAO as a mechanism for economic activity by an unbounded group of people within an adversarial environment without any centrality in infrastructure, leadership or legality."
• "V. MUSIC DAO PROTOTYPE"
  • if it works with REAL Bitcoin, its not a prototype
  • Real Bitcoin transaction between 2 people, record in thesis
  • Thesis experiment with Bitcoins on real ledger with Taproot keys
  • Reference to Blockchain explorer as footnote?
• performance analysis {ideas}
  • real code, real emulation on a single server
  • cmdline mode DAO !!
  • focus on graphs there
  • Join time for 2,3, 10k sizes DAO
  • Multi-Sig algorithm profiling 2,3, 10k ?
• Future work: Fix scalability
  • Bitcoin becomes a candidate to empower the global financial system 😲 🎉 😲
  • Adress the main challenge: transactions per second
  • A Bitcoin DAO with multi-Sig + clearance and settlement engine
  • Magic solution:
    • Single Shared Bitcoin wallet
    • Potentially billions of people own this collective wallet money
    • Offer unlimited transaction speed inside this shared wallet
    • Avoid global consensus and UTXO with Trustchain
    • Single valid signature to transfer funds within collective wallet (block hiding attack, reputation against double spending, 51%, etc needed)
    • Special purpose DAO to manage this single collective wallet, a DAO-Bank. Offer free bank transfers, a traditional core banking service
    • Conduct clearance and settlement of transactions inside The-First-DAO-Bank
  • Not a Layer II, not a side-chain; no smart contract; no governance token; its a full blown unstoppable DAO Bank.
  • thousands of real-time transactions, every 10 minutes the The-First-DAO-Bank conducts clearance and settlement to Bitcoin.

[leonardusjoannes]

DAO bank is almost alike a shadow admin of the bitcoin blockchain, leaving the DAO bank and conversion of DAO-bank-bitcoin to other value the moment of "truth" (where all your txn's honest txn's).
Sanity check (sum of all wallets) instead of consensus to avoid double spending ;).

[brian2509]

main.pdf

[synctext]

Reading your 6-page master thesis draft:

• Decentralization USA-spelling; Common to do Decentralisation == UK English
• "Proof-of-work and proof-of-stake blockchains, on which most DAOs run, suffer from centralisation problems.". More scientific: the root cause of the failure of contemporary DAOs to decentralise lies in the underlying blockchain. Proof-of-work and proof-of-stake have failed to scale, despite a full decade of attempts to boost transaction rates, without the loss of decentralisation.
• Factual inaccurate: "Prior to this, decentralized protocols such as BitTorrent and Wikipedia have enabled millions of individuals to collaborate in file sharing and information accumulation. " partly decentraliSed systems. Wikipedia is not a protocol, just a big website. You could include centralisation, group think, capture, and Wikipedia going rogue with 100+ million $ in donations.
• Easy sections: problem description, related work, DAO architecture, DAO implementation {with screenshots}, and experiments {or performance evaluation}.
• Sections are not yet master-thesis ready. Suggestion: make a single "A simple DAO architecture". We present a generic and as simple as possible architecture for a DAO. We deliberately remove all unnecessary feature and complexity in order to provide a flexible and strong building block. Our building block represents a milestone within the evolution of actual DAO realisations: it is the first to achieve hyper decentralisation. {or other buzz word: extreme decentralisation, radical decentralisation; something with a positive connotation}.
  • "Digital Democracy Problem" replace all these mixed problems and principles with a list of components. Component: "voting mechanism using threshold signatures". text suggestion: Our minimal functional decomposition leads to the following five minimal components required.
  • "Decentralized data storage solution", local-first data storage. We deliberately avoid a global file system, storage master, and rely instead on local stored with zero external dependancies. Fully self-sovereign.
  • Figure 2 Architectural components of the Music DAO: these are all specific implementation technologies of a generic architecture. First generic, then Bittorrent and Bitcoin realisation figure.
  • No governance token needed.
• "VII. performance EVALUATION". Please add 2-4 measurement graphs as the core of your master thesis.
• Code fixes: it should all work smoothly.
  • quick DAO discovery, quick DAO join, voting proposals.
  • just mention explicitly what is "future work".
  • see above experimentation comments, Taproot details.

[brian2509]

main.pdf

[synctext]

• "[scharnowski2021bitcoin?]" citation in standard "[9]" format please.
• "this however brings us back to square one to VISA-like central systems"
• "In this paper, we present a new architecture for DAOs which is as decentralized as possible and scalable"
• "Academically pure decentralisation of a DAO represents a key milestone in Web3 evolution."
• Repeated in Problem Description: Academic decentralization within a viable and sustainable DAO represents a
  key milestone in Web3 evolution.
• "The objective of this work is to design, implement" unsolved problem in problem description, remove word_objective_. Use unsolved problem etc etc
• "A SIMPLE DAO ARCHITECTURE", use positive wording: generic or minimal
• "VII. MUSIC DAO", expand to: "MusicDAO: a true decentralised DAO"
• To architecture?!? Architectural Principles then components?
  1. Zero-server infrastructure
  2. no inferior re-invention of Bitcoin
  • No governance token; 1-person 1-vote [cite paper]
  • No platform specific token for financial value transfer
  • No new treasury, re-use of reliable Bitcoin multisig tech.
  4. Permission-less
  5. Every peer in network equal (ideally no federation)
• {repeating} "VII. performance EVALUATION". Please add 2-4 measurement graphs as the core of your master thesis.
  • ideas: multiple phones, measure, join time, plot
  • Tweakers lauch and count comments for Master thesis table "user eval" positive/negative?

[synctext]

• Lets go for faster path towards official green light!
  • "based on: (select all that apply)" "other: " Internet-deployed prototype of Decentralised Autonomous Organisation
  • "The student is able to present and defend the research project." thesis work presented to ECB and AFM.
• with hard work, your thesis can be finished writing in 1 sprint. Leave detailed experiment for later.
• Discussed: browser-based P2P with socket puncturing rendezvous servers and JavaScript hosting servers.
  • opens the pathway towards mature FROST browser libraries
  • kills the idea: browser will never reach the TikTok usability and community reach. With TikTok its impossible to "get stuck", so no need to call a helpdesk 😸
• Note that with 37 minutes of waiting time you can do FROST

[brian2509]

main.pdf

[synctext]

On Monday 6 Feb everything needs to be ready for the new Blockchain Engineering class. Sandip is away soon for 4 weeks, so things need to start now. Could you please create a draft PR to push your changes to the main Superapp branch?
FROST is the next thing that needs to goto main branch (JNI route).

[brian2509]

main.pdf

[synctext]

• Solid progress towards master thesis graduation
• Related work is a bit void of related work (leaderless organisation, first smart contract Nick Szabo 1994, first Etereum realisation, first DAO, first DAO that does an ERC20 token issue, etc)
• Fig. 2. Architectural components of the Music DAO, move as Figure 1 and to page 3. Rename to: generic DAO architecture. Transparent is not a functional component, but a system requirement you used as input.
• Sprint focus: PR of your DAO and polish thesis

[brian2509]

The new .apk which is based on the final PR which should now be finished.

[synctext]

• 🚀 the code now works and can serve as foundation for your master thesis 🚀
• solid content discovery speed! (no UX refresh (initially upon first minute bootstrap) unfortunately)
• Ideas for final chapter: performance analysis
  • content discovery speed (follow customer journey)
  • discovery of DAOs to join
  • donation to artist number of messages and latency
  • Real-life deployment test + App store screenshot
  • Copyright-free image, free to (re-)use. Workshop of the first true decentralised DAO deployment.
  • Latency breakdown of joining a DAO
    • the grand experiment of this thesis
    • specially prepared with auto-approve phones/emulators running
    • instantly approve any incoming request
    • present all message traffic, crypto cost, the latency and bottlenecks.
  • graduation committee possible help
• btw thesis does not mention your dApp approach versus the mainstream approach of smart contracts. (smart contracts with finite run-time are not Turing complete and they only facilitate a single thread of execution globally. Without Turing-completeness and without parallelism it is therefore not acceptable for our usage.)

[brian2509]

This sprint after some final changes the PR is now finally merged in 🚀 . Some work on the draft has been done in performance sections & diagrams. main.pdf. Furthermore working on benchmarking using multiple phones, currently have some benchmarks working with a single phone.

[synctext]

• 5) Application Layer: Kotlin, JVM and Jetpack Compose this is all too much engineering. Whole list could be dropped. Do you have a more scientific "architecture" picture or implementation view?
• Fig. 6. Performance of our voting mechanism Solid step forward! {if it was non-mocked data}
• [cong2021decentralized], please use standard IEEE citation: [1].
• Run multiple emulators on our machine(s) with 128 cores and 256 GByte memory?
• Current simple methodology: select benchmark inside MusicDAO, view result, copy from screen (ToDo:get from app logs)
• Please get results and text improved that we can pick a graduation date

[added] https://mtg.github.io/mtg-jamendo-dataset/ The dataset contains over 55,000 full audio tracks with 195 tags categories (87 genre tags, 40 instrument tags, and 56 mood/theme tags).

[brian2509]

main.pdf
Mainly worked on paper and experiments this sprint.

[synctext]

• How far are you from unbounded scalability to billions of humans?
• Thresh-hold signature inclusion: this transaction adds a new members to the DAO, Hotel California? 3) leave DAO
• we do not rely on advanced turing-complete smart contract capabilities. any smart contract language with a finite wallet size, finite gas, and finite run-time is NOT turing complete.
• We have created an implementation of a DAO centered around music using our proposed architecture. Lack the Tim Wissel thesis vision: automate the entire music industry
• Figure 5, make clearer those are 2 screens.
• ToDo: theshold voting inside a IPv8 community. Run till 100 nodes even
• ???CPU usage, segwit, and transaction size for Bitcoin?

[brian2509]

main.pdf

• Got a test-setup working for multiple of ipv8 nodes in the super-app after multiple attempts of integrating projects
• (Any code in super-app is hard (to impossible) to integrate and run in a JVM app and vice-versa. Consequence -> all benchmarks with multiple ipv8 nodes run on emulator/phone. Not necessarily a problem for me, but perhaps others.)
• Will work on re-designing a simplified protocol in such a way it works w/ events instead of polling peers -> otherwise benchmarks are dependent on polling which is too slow.

[synctext]

• Hopefully we can soon give you your diploma
• work on re-designing a simplified protocol in such a way it works w/ events instead of polling peers is this making the MusicDAO better? Or just for making graphs with superior performance?
• Please check in your private code for DAO profiling
• Also, check out flamegraph for master thesis usage as Figure (task?? Vote on DAO)
• plan: 1 JVM emulator, 1 process, numerous threads for individual IPv8 nodes
  • note: this is ambitious task at final stretch of thesis
  • Programming like its 1999: 1 integration test if the response and signature is valid. Nothing else 🙄
  • Think of master thesis experimental results which are 'cheaper' in terms of development time
• Discussed Kotlin Android versus x86 native compiled Kotlin.
  • essential for scalability experiment on 16GByte laptops or 512 GByte memory servers
  • Common modularization patterns
  • big code change solution: move all Android specific code of superapp inside 1 architecture module/directory. All future project would then make 2 modules: non-android native and Android code

[brian2509]

This sprint was mostly focused on working on the performance evaluation done in order of the multi-sig implementation stand-alone and the implementation in a peer-to-peer setting using ipv8. To do this several steps had (and still have) to be taken.

• A modified implementation of MuSig which is BIP0340 compatible and verified (tested) is added to the project. [1] [2] [3]
  • The current implementation/port was not compatible (incorrect key tweaking, incorrect key encodings, etc). This means that its signatures will not be accepted by (up-to-date) bitcoin-core nodes. There were very few implementations of the MuSig paper available which are BIP0340. Those which are available are either incomplete, not implemented in Java/Kotlin or not suitable to be used in p2p settings.
  • Found two implementations of BIP0340 compatible Schnorr verify functions in order to test the signatures. One was already in JVM and another was ported from Python, both included in project now.
• For the performance evaluation I've worked on a separate community for MuSig signing of an arbitrary message between ipv8 nodes. This seems to be working, but implementing p2p protocols is more difficult than I expected (especially without reliable communication).
  • Using this some performance evaluations have been done in two settings: a local setting where only MuSig is evaluated and the p2p setting. The p2p evaluation is still limited due to factors I have not worked out yet (UDP size limit, re-tries), but still does show insight into performance.
  • Need to work on the p2p setting and make sure I can do tests on larger number of nodes.
• There have been some edits made to the last thesis pdf: new diagrams, general cleanup, changes text from suggestions.
  main.pdf

[synctext]

• Thesis is getting readable ! 🎖️
• Fig. 3. The voting mechanism of the Simple DAO \columnwidth violation
• Fig. 4. A visual representation of the Music DAO based on the simple DAO.
  • feels like a weird architecture when 'governance' is at the bottom and Bitcoin is on top. Sideways?
  • architectural picture which mixes three views: functionality, components, implementation
  • Not an architectural concern that certain blocks are already implemented and running smoothly for a decade (Bitcoin) or two (Bittorrent).
  • same comment for Fig. 1. A visual representation of the architecture of the simple DAO.
  • architectural components: publish music, trustworthy pinning of artists public keys, collecting votes, making collective decisions, cybercurrency transactions, trustworthy DAO membership discovery, etc.
• Fig. 8. Performance of our voting mechanism Great result! Just 1.2 second for 1 collective signature with 1000 participants (1ms/key ????). unbelievable 🤡
• Using the Rahim EVA TFTP re-try mechanism in IPv8? nope.
• Problem Description. with While such organizations are autonomous to an extent, they will still rely on human individuals to perform certain tasks. Translated: has human task execution, free of other human interference. More of a tutorial and related work, not really focused clearly defining your direction.
• Polish please The need for pure academic decentralisation arises from the fact that any deviation from this leads to the mechanism inheriting the problems associated with centralized traditional organizations.
• Fig. 9. Time to first discovery music
  • first screens refresh (first paint)
  • first IPv8 node discovered
  • first music discovered
  • 10 music pieces
  • 100 music pieces
  • etc
  • {make 2-column}

[brian2509]

Generic_DAO_primitives_for_Full_Academic_Decentralization_and_Scalability.pdf

[synctext]

• Main point: polished thesis text
• Title
  • "First Deployed DAO with true full decentralisation and leaderless governance"
  • "First Deployed DAO with full decentralisation and voting"
  • "First DAO with extreme decentralisation"
• Figure 1, architecture. more traditional protocol stack architecture: https://docs.wemix.com/v/en/design/architecture
• "III. RELATED WORK" bit short
• Table 1: "COMPARISON OF SIZE REQUIRED ON BLOCKCHAINS FOR DIFFERENT VOTING SCHEMES" please make pretty, add year, and add citation{s} per line.
• "A. Architectual Primitives" more 'extreme decentralisation requirements'?
• Governance is selected to be the contested concept of democracy (one person == one vote)
• Section6, more high level. We have created MusicDAO to re-shape the music industry. We meticulously designed MusicDAO to replace any existing intermediary with open source code. Various roles such as talent scouting remain, but no longer require any human labour. A music curator is no longer required if real-time viral music statistics exist. Current cloud-based architecture restrict such vital business information. {more business and science stuff}
• Move all engineering to implementation and deployment?
• Figure 4 also requires polish. "A visual representation of the Music DAO based on our architecture."
• bad marketing, "Fig. 8. Performance of implemented voting mechanism" Figure 8, cryptographic cost of democratic voting using signature aggregation
• this works now nicely, THRESHOLD is FUTURE work
• cut and pixelated flame graph
• "Performance of implemented voting mechanism in the Peer to Peer setting" ➡️ performance analysis of multiple signatures with real networking
• "node amounts 2.5"
• "Fig. 10. Time to first discovery music" more a pretty probability distribution function of 1st music discovery time ? PDF of IPv8 neighbor discovery, app startup PDF, etc.

[brian2509]

Did most of above todos and todos by my supervisor and rewrote parts of thesis, in particular related work, architecture, performance evaluation and voting protocol. Polished a lot of text and redid most diagrams/tables (higher quality, pdf, more data/information). Biggest task to do is finish implementation section.

main.pdf

Above list:

• Main point: polished thesis text
•  Title
  • "First Deployed DAO with true full decentralisation and leaderless governance"
  • "First Deployed DAO with full decentralisation and voting"
  • "First DAO with extreme decentralisation"
•  Figure 1, architecture. more traditional protocol stack architecture: https://docs.wemix.com/v/en/design/architecture
  • > Different Solution
•  "III. RELATED WORK" bit short
•  Table 1: "COMPARISON OF SIZE REQUIRED ON BLOCKCHAINS FOR DIFFERENT VOTING SCHEMES" please make pretty, add year, and add citation{s} per line.
•  "A. Architectual Primitives" more 'extreme decentralisation requirements'?
  • > Named architectual requirements
•  Governance is selected to be the contested concept of democracy (one person == one vote)
• Section6, more high level. We have created MusicDAO to re-shape the music industry. We meticulously designed MusicDAO to replace any existing intermediary with open source code. Various roles such as talent scouting remain, but no longer require any human labour. A music curator is no longer required if real-time viral music statistics exist. Current cloud-based architecture restrict such vital business information. {more business and science stuff}
•  Move all engineering to implementation and deployment?
  • WIP section
•  Figure 4 also requires polish. "A visual representation of the Music DAO based on our architecture."
  • Replaced
•  bad marketing, "Fig. 8. Performance of implemented voting mechanism" Figure 8, cryptographic cost of democratic voting using signature aggregation
  • Renamed to peer to peer implementation
•  this works now nicely, THRESHOLD is FUTURE work
•  cut and pixelated flame graph
•  "Performance of implemented voting mechanism in the Peer to Peer setting" ➡️ performance analysis of multiple signatures with real networking
•  "node amounts 2.5"
•  "Fig. 10. Time to first discovery music" more a pretty probability distribution function of 1st music discovery time ? PDF of IPv8 neighbor discovery, app startup PDF, etc.

[synctext]

• Congrats with Green Light moment today 👏
• Thesis Chapters ready for graduation
  • missing name of your work MusicDAO
  • Introduction
  • Problem Description
    • "The myth of digital democracy" please add like: 'the open problems with governance is summerised by the booktitle "The myth of digital democracy"'
    • While there is no consensus on how to define a DAO, ... why define as an afterthought? Use as opening lines?
    • 150 million USD from why new paragraph?
  • "MusicDAO: most simple architecture"?
    • "flexible and strong building block" perhaps more future-proof, generic, and principled
    • "local-first storage", citation needed!
  • "V. MULTI-SIGNATURE dao VOTING PROTOCOL", insert DAO there. it's tailor-made I assume.
    • "We now introduce a novel protocol which combines multisignature and blockchain technology in order to make governance possible". bad opening. What are you solving here? like: In this section we address the DAO!! governance problem by using democratic voting processes.
    • 2nd line already: "We visualize our protocol in Figure 2. " no context. no intro. no why. no what. no who. no how.
    • Any relation to IV.E. Governance Processes
    • No style consistency at all! White-on-black boxes, black-on-yellow boxes, Dave versus DAO Member 3, three arrow types, etc.
    • B. Managing Shared Assets use equal terms in section 4 and 5. But now it's not simply voting: it is a whole DAO detailed design
    • Figure 2 very detailed and lots of engineering for this chapter. MusicDAO implementation content? Removed Figure 3, just related work right?
    • Fig. 5. A visual representation of the Music DAO based on our architecture. only now we see how everything fits together.
  • VI. MUSIC DAO: A TRULY DECENTRALISED DAO
    • One figure with (a) several (b) screen of your implementation 100% pagewidth (discovery, album-play, dao-discovery, DAO-vote) Never a 0 BTC artist in your ecosystem 🐱
  • VII. PERFORMANCE ANALYSIS
    • Fig. 8. Flame graph of the cryptographic operations in the voting mechanism for 10.000 keys. ugly low res
    • 1) Flamegraph of Local MuSig: sub-subsection "2)" is missing
    • Fig. 11. Time to first discovery music too simplistic (first screen refresh, first incoming UDP packet, first new music album)
    • B. Usability Experiment more scientific: end-to-end performance evaluation?

[brian2509]

Completed contents of above comment, can be found in details below. Had a number of meetings with supervisor and some help from PhDer to improve paper text and structure over this sprint. Finished all the text. Improved most figures and display of figures in the paper for style consistency / polish. Very last item on the list (end-to-end-performance of music loading) needs two more bar plots which I am working on.

MSC_THESIS_First_Deployed_DAO_with_True_Full_Decentralisation.pdf

•   Thesis Chapters ready for graduation
  •  missing name of your work MusicDAO
  •  Introduction
  •  Problem Description
    - "The myth of digital democracy" please add like: 'the open problems with governance is summerised by the booktitle "The myth of digital democracy"'
    - While there is no consensus on how to define a DAO, ... why define as an afterthought? Use as opening lines?
    - 150 million USD from why new paragraph?
    •  "MusicDAO: most simple architecture"?
      • "flexible and strong building block" perhaps more future-proof, generic, and principled
      • "local-first storage", citation needed!
    •  - [x] “V. MULTI-SIGNATURE DAO VOTING PROTOCOL”, insert DAO there. it’s tailor-made I assume.
    • “We now introduce a novel protocol which combines multisignature and blockchain technology in order to make governance possible”. bad opening. What are you solving here? like: In this section we address the DAO governance problem by using democratic voting processes.
    • 2nd line already: "We visualize our protocol in Figure 2. " no context. no intro. no why. no what. no who. no how.
    • Any relation to IV.E. Governance Processes
    • No style consistency at all! White-on-black boxes, black-on-yellow boxes, Dave versus DAO Member 3, three arrow types, etc.
    • B. Managing Shared Assets use equal terms in section 4 and 5. But now it’s not simply voting: it is a whole DAO detailed design
    • Figure 2 very detailed and lots of engineering for this chapter. MusicDAO implementation content? Removed Figure 3, just related work right?
      • Made simpler.
    • Fig. 5. A visual representation of the Music DAO based on our architecture. only now we see how everything fits together.
  • VI. MUSIC DAO: A TRULY DECENTRALISED DAO
    • One figure with (a) several (b) screen of your implementation 100% pagewidth (discovery, album-play, dao-discovery, DAO-vote) Never a 0 BTC artist in your ecosystem 🐱
  •  VII. PERFORMANCE ANALYSIS
    • Fig. 8. Flame graph of the cryptographic operations in the voting mechanism for 10.000 keys. ugly low res
      • Increased resolution / better text rendering
    •  1) Flamegraph of Local MuSig: sub-subsection “2)” is missing
    •  Fig. 11. Time to first discovery music too simplistic (first screen refresh, first incoming UDP packet, first new music album)
    •  B. Usability Experiment more scientific: end-to-end performance evaluation?

[synctext]

Solid polish! 👏

• In addition, implementing and deploying a DAO is a difficult in practice due to the many engineering challenges.
• Currently every technology claiming to be a DAO has central points of control and critically rely on central servers. Real decentralized DAOs only exist in theory. , Fully agree. Citations needed! {for instance, reference to 10 DAOs, no further details needed}
• There is no consensus on how to define a DAO. We define it as a mechanism for economic activity by an unbounded group... Please move to opening line of Related Work or start of Problem Description. not really something to hide there
• Consistency: Figure 1: "Distributed Ledger Technology (DLT)", Figure 2: "Blockchain"
• "Sequence diagram of our voting protocol for a transaction proposal", Sequence diagram of our online democratic governance?
• "We do however argue that in the most ideal case a one-human-one-vote model is ideal for organizations concerning themselves with the common good.", stronger. We deviate from this mainstream model by deploying the one-human-one-vote model of democratic governance.
• "The design we describe adheres to our architectural requirements which we deem necessary for decentralization.", stronger. Recall that all prior DAOs lack full decentralisation. Our design doctrine dictates true full decentralisation.
• our architecture.Our approach
• Our design builds upon established multi-signature schemes, stronger and clearer. Our design builds upon established multi-signature schemes and carefully avoid the need for costly smart contracts. Explain dAPP?
• Both of these processes can require multiple full rounds of communication in which every participant sends a message to each other. Remove all tutorial stuff please, replace with citations. Remove 50% of text in "5.A. Governance".
• Figure 3 "Transaction which adds a member to the shared assets of the DAO", consistency. re-use colour schema of Figure 1.
• Fig. 5: Screenshots of the Music DAO greatly improved! 💟
• To implement our governance protocol, we have developed a Kotlin implementation of the MuSig [17] scheme. vague text. FROST out of scope, significant engineering effort. Offers ability for missing votes. Limitation of our operational MusicDAO is the requirement for 100% voting participation. A single missing vote blocks any proposal.

[InvictusRMC]

thesis_notes.pdf

Some minor comments. Good luck with wrapping up!