@ 🇵🇸 whoever loves Digit

I am submitting another Monero dev bounty on bounties.monero.social for a much more ambitious project than my last one (which is still in progress, for nostr wallet bot setup tooling). It all started with the Nintedo 64. It's a 64-bit desktop computer that can run modern-day 64-bit Linux, but most owners do not have a keyboard and mouse for it - only a controller. On the bright side, it has no ethernet port or wireless card to introduce internet-connected backdoors. There are also other, older systems with no internet connectivity; the 64 is just special for its Linux compatibility. Importantly, many old game systems like this have been mass-produced, sold worldwide, and maintained by collectors, ensuring continued availability will outlast today's empires. Despite the difficulty of inputting text using gamepad controls, this category of system is ideal for air-gapped wallets; however, this bounty is starting smaller and more general-purpose than that. The point is to generate seed phrases and associated public and private keys, while providing good safety advice, and helping people learn. # The development bounty Link to the bounty page at bounties.monero.social - https://bounties.monero.social/posts/168/gamepad-controlled-cryptographic-multitool-with-offline-wallet-address-generator Since this project is nostr-related, I am also making this thread on nostr, so that nostr users can have their input included. Here are the details of the bounty, which can also be viewed at the link I've provided. # Bounty details ## Native platform requirements * The app must be tested to work on a common vintage game system (mainline Nintendo or equivalent popularity), using its standard controller or handheld controls (this makes this bounty stupidly difficult, I'm sorry) * The newest consoles you can target are "5th generation" (N64 or equivalent) or, if you want to do a handheld, GBA or lesser is fine (the point is equivalence of capabilities, not actual release year) * Optionally, the app can work with any keyboard attachment available for the selected system, but it still has to also be usable with the standard controls * The app must also be tested to work on Linux or Android (either one is fine) * If your solution does not run natively on Linux or Android, then it just needs to work in at least one open source Nintendo emulator for Linux or Android (either one is fine) * If your solution involves running Linux on a Nintendo 64, you do have to confirm it works on typical Linux or Android devices without the emulator (again, either one is fine) I do not want to lend indirect support to a specific corporate brand, and I strongly respect that others in this community might be suspicious that looks like what I'm doing by mentioning Nintendo products. Thus, non-Nintendo systems with similar limitations, anywhere from a Commodore 64 to a PlayStation, could be accepted as alternatives. However, I am not mentioning Nintendo to support Nintendo - their systems simply seem to be the only ones that have all of the following benefits: * Competed significantly with the sales numbers for a mainline Nintendo system in the US and worldwide * Complicated wording because it's a very particular thing: these systems were sold at a time when the US surveillance state might have accepted a more limited level of invasiveness for the backdoor vulnerabilities required in electronic products marketed to American consumers, if the products were understood by Americans to be toys for running games, and not used by adults to run code for serious purposes * These products were indeed understood by Americans to be toys for running games, and not used by adults to run code for serious purposes * Ostensibly no built-in networking, wireless functionality, cameras, microphones, speakers * Continuing to be sold and bought very actively by a large number of gamers, for gaming purposes; this makes it somewhat ineffficient to target the entire market with [random shipment interceptions, to plant backdoors blindly](https://web.archive.org/web/20240529000526/https://www.theguardian.com/books/2014/may/12/glenn-greenwald-nsa-tampers-us-internet-routers-snowden), hoping to catch things other than gameplay * Already wide support for loading unlicensed games; even if a mod chip or custom loadable cartridge is needed, gamers buy these things to run games, so it can't be assumed that these mod chips or custom cartridges are being used for cryptography purposes every time they're purchased * Last but not least, these systems have open-source emulators readily available for all major platforms (or, in the case of N64 Linux, a convenient way to bypass any emulator for cross-compatibility) Many systems meet parts of these criteria, and would be useful even if they don't hit every point on the list. The examples I gave before - a Commodore 64 and a PlayStation - miss many of these points, yet they would still be awesome. Nonetheless, these criteria seem to make a Nintendo 64 or similar ideal to start with, before extending the functionality onto other systems, to increase overall availability even further. On the other hand, some of these factors are vital criteria, such as the lack of built-in surveillance equipment (even speakers are just inverse microphones). I've provided this information to help an informed choice be made, so I'll leave the final selection in the community's hands. Just keep it equivalent to these old systems, or ideally, pick one of them. Additional note: I'm also not sure mentioning Nintendo here actually benefits them as a corporation. The brand should benefit, in that it becomes a more useful name and logo for a stronger corporation to potentially own; but that doesn't mean the current corporation benefits from so-called ownership of a name and logo they might not even be allowed to trade for a few Monero, let alone fully utilize. ## Simplified list of functions * Promote the development of knowledge and experience for users working with cryptographic tools (including but not limited to Monero and other cryptocurrency) * Mine for "vanity keys" (wallet addresses and nostr pubkeys matching given text strings) * Handle UTF-8 text input somehow, probably an on-screen keyboard navigated using the controller * Guide users through generating more well-randomized seed phrases by hand * Convert text to and from binary using text encoding schemes such as Unicode (might seem like a silly toy thing to include, but this helps familiarize people with the general concept of converting chunks of digital data between different formats) * Convert data to QR codes (inverse not required because most old Nintendos do not have cameras) * Convert text and binary from plain to encrypted form, and vice versa, in accordance with well-regarded encryption algorithms * Convert random input to seed phrase * Convert seed phrases to nostr keypairs and BIP-39 wallet addresses * Configure these conversions as preset settings, editable by the user to configure custom wallet address derivation paths, seed phrase standards, encryption algorithms, etc * Include presets for generating wallet addresses for at least the following cryptocurrencies: Monero (XMR), doggie coin (DOGE), Bitcoin (BTC), Ethereum (ETH), Ethereum Classic (ETC) * Include UTF-8 and ASCII as presets for binary text encoding ## Detailed information All of the information listed in this section must be provided to users where specified, but you can rephrase it or expand on it as long as your changes strengthen the informational value. Copying and pasting from me, or asking me to revise or expand what I've written for your use, is also fine. ### Main menu splash At the main menu, display a random security tip from a list of tips like "did you compile this from the source code yourself?" and "have you considered using an off-grid power source to make sure you're disconnected from any grid-based backdoors?" Actually make sure those 2 are in the list. Other than that, you can use some existing list of tips you find online, or make a list yourself, or ask me or others for help, or whatever you want. This is kind of like Minecraft's main menu splash text, which also gets randomly selected from a list of possible strings. ### Encrypting and decrypting text When encrypting and decrypting text, convey to the user that the term "end to end encryption" has become a marketing term widely used to gaslight the public in the age of security theatre, and what the user is doing only counts as "end to end encryption" if they have good reason to be sure their game system has no leakpoints/backdoors, and neither does the device of anyone the user is exchanging messages with. ### Keygen Points to convey at the beginning of the process of generating a key: * When a process requires some randomized data, that piece of data is called a "seed;" * for example, a "seed phrase" is a sequence of words that translate to a random binary sequence, often used to calculate wallet addresses; * random number generation is hard for computers or humans alone, so the most secure software generates random numbers by mixing user input with electronic algorithms, which means a wallet's final seed is generated from a precursor seed of user input * the precursor seed is often invisible to the user, collected from something like mouse movements which they might not notice, but more transparently involving the user can help teach them more about security and user safety * old-fashioned random number generators, such as dice, can be far more reliable and secure than contemporary electronic mechanisms, so it's also a good idea for secure software to allow users to turn to these outside sources of randomness When generating a key, offer these 3 options, where the tradeoffs are made clear to the user: * the user can ignore security to automatically mine for a "vanity seed" matching a special wallet address and/or npub; * middle ground, the user can use their device to manually generate user input for a random seed; * maximum user control, the user can be guided through the process of generating their seed phrase using an antique technology such as dice When manually generating a key using dice or similar, the user can enter a binary sequence to have it converted to a seed phrase. At this stage, convey these points: * the user can instead print out a list of seed words and keep this step independent if they want; * although there are many entries in the list of seed words, it takes surprisingly little paper to print a list with that many single-word entries at a readable font size; * the checksum would be the hardest part without electronics When a seed phrase is generated, don't offer the user any option for what to do with it except delete it and return to the main menu. Make these points available for the user to read about: * the user should save the seed using a non-electronic method such as paper; * if the seed is or might become essential to avoid losing, backing it up would be ideal; * backing it up might be too risky for individuals facing unusually high levels of surveillance or unusual risk of theft; * this risk might be addressed using miltisig, or simply split-up segments of a seed, or memorizing a seed phrase without keeping it written down; * random word sequences this long are much harder to remember than actual sentences, and relying on memory has a very high rate of failure; * when using memory to store crypto wallet keys, it's called a "brain wallet," and it's known for being very dangerous and a bad idea in most cases; * only long seed phrases can be partly exposed and still have enough randomness remaining for protection, it's probably not a good idea to split up a 12-word seed into multiple segments for security; * your keys are yours to protect - users should look for more information beyond what any app explains, and take time to think about how they personally want to secure any important seed When manually adding derivation paths for wallet addresses, stress to the user that it's dangerous af and they better get it exactly right and actually just still not even use it because it's too risky to be worth it. When generating wallet addresses, convey to the user that this app does not yet have actual wallet functionality and cannot connect to the blockchain to verify a test transaction, so if the user is planning to just blindly deposit large amounts to wallet addresses generated here without any testing, that's so metal and hardcore af ### QR codes When generating QR codes for any purpose, wallet address or otherwise, always convey to the user that pointing one device's camera at another device's screen, or even the light cast by it, could allow hidden backdoors to transfer data beyond what the user intends to transfer. For example, a screen could encode data in microscopic changes of brightness, detectable by a camera, but not noticeable to the human eye. Thus, for the most high-security level of air-gapping, one should consider using pen and paper (copied multiple times and triple-checked) for data transfer, while keeping sensitive electronics as isolated as possible from camera phones, or ideally as isolated as possible from other electronics in general. ## Text encoding support requirements * Confirm all ASCII characters convert to and from binary successfully (UTF-8 would probably be impossible to hit 100% on) * Confirm UTF-8 braille characters render successfully (because these characters are inadvertently functional as an image encoding method) ⣴⡿⠶⠀⠀⠀⣦⣀⣴⠀⠀⠀⠀ ⣿⡄⠀⠀⣠⣾⠛⣿⠛⣷⠀⠿⣦ ⠙⣷⣦⣾⣿⣿⣿⣿⣿⠟⠀⣴⣿ ⠀⣸⣿⣿⣿⣿⣿⣿⣿⣾⠿⠋⠁ ⠀⣿⣿⣿⠿⡿⣿⣿⡿⠀⠀⠀⠀ ⢸⣿⡋⠀⠀⠀⢹⣿⡇⠀⠀⠀⠀ ⣿⡟⠀⠀⠀⠀⠀⢿⡇⠀⠀⠀⠀ ⠉⠁⠀⠀⠀⠀⠀⠸⠇ When using the text encoding functionality, which converts text between encoding standards like ASCII and UTF-8, it would also be good to include a reminder that the user's keyboard and other system components are encoded in UTF-8. ## A suggestion This isn't a firm requirement, but if possible, please allow the user's choice from at least the following 2 color schemes: black background with green text, and pale yellow background with black/gray text. For some idea of what "pale yellow" means, something like HTML color code feffb2 would be good. ## Roadmap of future plans to avoid for now Devs on bounties.monero.social sometimes go above and beyond what's requested in a bounty. That's truly awesome, but in this case, the limits of this project are intentional; please do not skip past the scope of the bounty too widely. You can go beyond the scope if you wish, but along the way, it would still be ideal to do a minimalist release to suit this bounty's requirements specifically. I hope this bounty is more than challenging enough to begin with - as a non-coder, it seems to me like it should already be extremely difficult. I intend to do (smaller) future bounties for expansion of this project. Ideally these expansions should take the form of patches, all compatible with each other, and the minimalist original version. Thus, different versions of the app, with different capabilities, could be configured - and their security analyzed separately. Here are some specific bounties and ideas I would want to see added later, but not in the minimalist version, to save on lines of code in the minimalist security analysis. * Bounty for a patch that adds air-gapped wallet functionality, where the app can actually interface with the blockchain to do transactions, by using pen and paper to transfer data between the Nintendo and a different machine with an internet connection * Bounty for a patch that adds air-gapped nostr functionality, where the app can generate signed nostr events and encrypt/decrypt direct messages, and a "sister app" handles the exchange of data on an internet-connected system * Bounty for a patch to enhance text handling by adding clipboard functions (highlight/cut/copy/paste) * Include a clipboard history view (clearly warning the user that the Nintendo has no storage, and this is only a temporary history, lasting until the system is reset) * Bounty for a patch that expands data transfer methods by adding support for some kind of peripheral data interface such as a memory card slot * Allow encryption and decryption of heavier data formats than text, such as images, if some kind of peripheral provides a better data interface than pen-and-paper / on-screen keyboard * If the selected device ever had a camera attachment available, a bounty for a patch that adds support for the camera (QR code scanning, image capturing, maybe converting images to Unicode braille art) * Bounty for a patch that hides this entire app inside of whatever game had the most copies produced for the selected Nintendo system (not against copyright to release as a patch) * Bounties for identical functionality on other systems In addition to all these goals, it would also be good to have a large number of native cartridges produced someday, containing this software, after some time for the open-source community to review and revise first.