Merge branch 'monero-i2p-samv3' into 'master'

I2P SAMv3

See merge request monero-project/ccs-proposals!454

MoneroSignerResurrection.md

@@ -7,8 +7,8 @@ amount: 55.38
 milestones:
   - name: Monero Signer basics on emulator
     funds: 5.38 XMR
-    done:
+    done: 19 June 2024
-    status: unfinished
+    status: finished
   - name: Monero Signer working with companion Application
     funds: 5 XMR
     done:
@@ -22,8 +22,8 @@ milestones:
     done:
     status: unfinished
 payouts:
-  - date:
+  - date: 20 June 2024
-    amount:
+    amount: 5.38
   - date:
     amount:
   - date:

MoneroSigner.md

@@ -1,5 +1,5 @@
 ---
-layout: wip
+layout: cp
 title: "MoneroSigner. Fork of seedsigner for Monero."
 author: Monero-HackerIndustrial
 date: June 08, 2022
@@ -35,6 +35,19 @@ payouts:
   - date:
     amount:
 ---
+
+----
+### Proposal Closure/Transferral 17th June 2024
+
+All remaining funds (55.38 XMR) have been transferred to/repurposed for: [MoneroSigner Resurrection](https://ccs.getmonero.org/proposals/%20MoneroSignerResurrection.html)
+
+Effective immediately:
+
+- HackerIndustrial is hereby terminated from this project and relinquishes any claim to the remaining CCS funds.
+- The project will now proceed under vthor, who has already achieved significant progress in a matter of weeks, demonstrating the competence and dedication required.
+
+----
+
 The Monero community could benefit from a fork of [seedsigner](https://seedsigner.com/) to supports Monero. Seedsigner uses an air-gapped Raspberry Pi Zero to sign for Bitcoin transactions. The project aims to make it easy for anybody to make a dedicated offline signing device out of low-cost commodity computer components (raspberry pi zero). This helps in reducing the need to trust hardware verndors. The most private hardware wallet, is the only only **you** know about.  
 
 Seedsigner is focused only on Bitcoin, because of this, the UI/UX and features are not very helpful to Monero users.

monero-i2p-samv3.md

@@ -0,0 +1,166 @@
+---
+layout: fr
+title: I2P SAMv3
+author: idk and zzz
+date: March 15, 2024
+amount: 127.8 XMR
+milestones:
+  - name: Finished
+    funds: 150
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+---
+
+This project redesigns and modernizes I2P support in Monero.
+It updates the GUI and docs to make I2P usage easy for users.
+By abandoning i2p-zero and encouraging users to install I2P themselves,
+Monero will be set up for flexible long-term I2P support with very little maintenance burden.
+
+The GUI part of this project overlaps with the I2P GUI bounty but
+we do not recommend doing the I2P router bundling/management task referenced in that bounty.
+
+Amount assumes that the 22.2 XMR bounty is claimed simultaneously, for 150 XMR total.
+
+Refs:
+
+- https://geti2p.net/en/docs/api/samv3
+- https://geti2p.net/en/docs/applications/embedding
+- https://bounties.monero.social/posts/32/22-199m-i2p-baked-into-the-monero-gui
+
+
+Goals:
+
+- Redesign I2P support to use SAM version 3.1 ("SAMv3")
+- Provide GUI interface to enable and configure I2P support
+- Provide GUI indication of external router status up/down
+- Add sane default I2P configuration and a way to modify the default
+- Abandon i2p-zero
+- Abandon goal of bundling a router or managing an external i2p router
+- Support external Java I2P or i2pd router
+- Support both I2P-only and "mixed" network configurations
+- Rewrite documentation on how to install Java I2P or i2pd router and set it up to work with Monero
+
+
+## Non-goals:
+
+- Bundling a router with Monero
+- Management/control of external router. The user will be responsible for installing/starting/stopping the router.
+- Connections via I2P outproxy to clearnet
+- Any mods or support of i2p-zero
+
+
+## Key Benefits:
+
+- Provide first-class I2P support for Monero
+
+### What do we mean by first-class support?
+I2P provides a network layer for obfuscating metadata about connections, "anonymizing" the connection to observers.
+It does this by providing cryptographic addresses, "Destinations," to "applications" on a garlic-routed overlay network.
+This means that you have a "pseudonym" in the form of the destination which your peers use to communicate with you.
+The last application is usually a "Proxy" of some sort, such as a SOCKS proxy in the case of Monero right now.
+This last last application receives messages and distributes them to proxies applications.
+
+### What's wrong with SOCKS?
+Most applications can be "proxied" over I2P to make them compatible with I2P.
+This can lead to a "Shared Identity" problem, where all applications who share the same SOCKS proxy also share the same return "destination" address.
+An attacker can run multiple applications and "collude" to discern whether they are operating on the same destination, leaking information about what is going on.
+In the case of "chatty" peer-to-peer applications that depend on frequently syncing information from peers, this can often be done in a mostly passive way.
+SOCKS lends itself to this type of misconfiguration.
+
+#### How does SAMv3 fix it.
+
+SAMv3 resolves the issue by providing a proxy which allows the application to configure it's own I2P connection.
+
+- SAMv3 provides far-end ID ("destination") for incoming connections; keys are generated as part of the handshake/connection setup process and can be stored or not as the application demands.
+- SAMv3 puts the application in control of the crypto keys and allows both permanent and transient destinations
+- SAMv3 allows the application to configure the tunnels rather than relying on external i2p-zero setup scripts; all tunnel options are available via SAM
+- Tunnel configuration may be changed by the application later, rather than one-shot by a setup script; this allows an application to "throw away" a pseudonym.
+
+### What's wrong with I2PTunnel?
+
+Hidden Services Manager, a.k.a. I2PTunnel is a generic suite of proxies which are designed for adapting standard applications to I2P.
+It supports several kinds of proxies, including "standard" proxies which are similar to forwarding and reverse proxies, specialized HTTP and SOCKS proxies.
+However, each of these tunnels always has different destination keys.
+For an application like Monero which must accept incoming and outgoing connections, this means that it must generate manage 2 sets of destination keys.
+Hidden Services Manager is also a "manual" process, it is vaguely "scriptable" but the flexibility is quite limited when compared to SAMv3.
+
+- SAMv3 allows both incoming and outgoing connections; no need for two sets of tunnels like with i2p-zero; cuts resource usage in half
+  and simplifies your network by using the same ID ("destination") for incoming and outgoing connections
+- Brings tunnel configuration options up to current cryptographic standards and recommendations; improves performance and allows upgrading the keys by the application
+
+## Lesser Benefits:
+
+### What's wrong with i2p-zero?
+
+i2p-zero is an interesting project in many ways, but it's utility as an I2P router is severely compromised by it's elaborate and error-prone build process.
+i2p-zero is essentially a custom launcher and a buildsystem for the I2P router.
+The launcher itself is very simple, however the buildsystem is designed in such a way that it requires considerable expertise to maintain properly.
+It depends on obscure processes in order to successfully generate a minified runtime image for Java I2P a'la jpackage **without** the need for a Windows host.
+It does this by manually(and carefully) using jlink on an existing Windows-compatible image.
+
+- Remove dependency on unmaintained i2p-zero
+- External router allows users to keep it up-to-date with standard upgrade mechanisms
+- Much simpler than bundling a router or maintaining an external router fork
+- External unmanaged router is the same architecture adopted by bitcoin and libtorrent
+
+- SAMv3 is the standard API to interface with I2P routers
+- SAMv3 is supported by both Java I2P and i2pd
+- SAMv3 is used by bitcoin and libtorrent
+
+- Proven implementation in bitcoin with thousands of users
+- Numerous SAMv3 libraries are available, or code could be adapted from bitcoin or libtorrent (license permitting)
+- SAMv3 is fairly simple and is somewhat similar to SOCKS
+
+
+Task Overview:
+
+- Become more familiar with I2P. Study the SAMv3 documentation. Run bitcoin with i2pd and/or Java I2P; become familiar with diagnostics in I2P router console
+- Experiment with SAMv3 via telnet to manually build tunnels and make connections to gain experience
+- Research available SAMv3 libraries and code; confirm license compatibility; select library or code to adapt, or decide to write from scratch
+- Maintain presence on I2P IRC for rapid answers to questions, informal progress reports, etc.
+- Decide whether to support permanent or transient destinations or both
+- Decide whether to use SAMv3 ACCEPT or FORWARD for incoming connections (probably ACCEPT)
+- Code SAM
+- Code GUI
+- Confirm best default configuration after consultation with I2P experts; ensure compliance with I2P guildelines
+- Test with both i2pd and Java I2P
+- Test Monero reaction to external router start/stop/restart
+- Add configuration to GUI
+- Implement any unit tests required by Monero code guidelines
+- Rewrite documentation; possibly adapt from bitcoin docs; ensure compliance with I2P guidelines
+- Docs to include user instructions for 1) New install of i2pd or Java I2P; 2) Migration from i2p-zero;
+  3) migration of existing (non-i2p-zero) i2pd or Java I2P install
+- Announce and recruit beta testers
+- Verify and update seed node list
+- Pass any Monero code review guidelines required for merging
+- PR, merge, include in Monero release
+- Announce and encourage Monero users to install and enable I2P
+
+
+Assumptions:
+
+- Datagrams (UDP) not required
+- I2P ports not required
+- SAM v3.2 or v3.3 not required
+
+
+Optional:
+
+- Android?
+
+
+Who:
+
+TBD, presumably somebody in the Monero dev community.
+I2P devs and community will provide consultation and support as necessary, without compensation,
+but should not be relied on for any coding or testing.
+
+Estimated effort:
+
+2-6 months depending on coder's experience
+For reference, the main bitcoin i2p code is about 500 lines (no GUI)
+
+Expiration: 2024-12-31