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

I2P SAMv3

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

jeffro256-full-time-2024Q3.md

@@ -0,0 +1,67 @@
+---
+layout: fr
+title: jeffro256 full-time development 2024Q3
+author: jeffro256
+date: June 14, 2024
+amount: 146
+milestones:
+  - name: Month 1
+    funds: 33% (48.0)
+    done:
+    status: unfinished
+  - name: Month 2
+    funds: 33% (49.0)
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 33% (49.0)
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+
+In the last three months, the likely direction of the future of the Monero protocol changed
+drastically with all the work done to bring FCMPs to RingCT. At my last CCS proposal, I
+proposed that I would be working on the Seraphis wallet and consensus integrations. Then
+I shifted gears to implementing [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96#).
+I propose to refine this codebase and produce and LWS-client demo, in order to have these
+set of features complete before the FCMP++ upgrade, assuming all goes well. This codebase
+can currently construct `cryptonote::transaction`s with Jamtis info encode in the `extra` field,
+and then successfully scan that data. Here is a non-exhaustive list of points that need
+work with this library:
+
+- Legacy address integration and testing
+- Optimization: post-primary-view-tag scanning is about 20% slower than expected
+- Testing against actual FCMP++ composition proofs
+- Multi-threaded compute
+- A live, over-the-wire LWS demo for evaluating the filter-assist/hidden enote trade-offs
+
+I would also like to work on replacing `wallet2` internals with the Seraphis library 'legacy handling'
+code, as discussed at this Github issue: https://github.com/seraphis-migration/wallet3/issues/64. A few people
+are already working on it, but it will need a lot of manpower to bring it to fruition.
+
+
+## Who
+
+I have been contributing to the Monero core repository for [over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [68 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Some more notable contributions from this last quarter:
+
+- Implemented [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96#) into the Seraphis library [here](https://github.com/jeffro256/monero/tree/jamtis_rct). This branch provides support for storing Jamtis scanning data into `tx_extra`, and performs a unit test where a pruned transaction is constructed addressed to Jamtis payment proposals, and then successfully scanned for both plain and self-send enote types. The way this branch was written merges the code paths for doing Jamtis on RingCT and Seraphis together. It could use some cleaning up, and the Seraphis multisig tests need to be updated, but otherwise all Seraphis tests are passing.
+- Some other Seraphis stuff including a unified transaction format for Cryptonote, RingCT, and Squashed-Seraphis transactions.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so `40 (hours/week) * 3 (months) * weeks_per_month = 40 (hours/week) * 3 (months) * (365 / 12 / 7) (weeks/month) = 521` hours total on-paper, though I usually work more than that. The proposal is broken into 3 milestones, one for each month. I am setting my hourly rate at 46 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 163.97 USD/XMR, that makes for a total of 146.2 XMR. Price was calculated as 14-day simple average of opening prices on [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-06-01 to 2024-06-14 (day of writing), same as last quarter.

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

plowsof-ccs-coordinator-4.md

@@ -7,20 +7,20 @@ amount: 80.07
 milestones:
   - name: 2 meetings + hours worked
     funds: 26.69 XMR
-    done:
-    status: unfinished
+    done: 2 June 2024
+    status: finished
   - name: 2 meetings + hours worked
     funds: 26.69 XMR
-    done:
-    status: unfinished
+    done: 2 June 2024
+    status: finished
   - name: 2 meetings + hours worked
     funds: 26.69 XMR
     done:
     status: unfinished
 payouts:
-  - date:
+  - date: 24 June 2024
     amount: 26.69
-  - date:
+  - date: 24 June 2024
     amount: 26.69
   - date:
     amount: 26.69

revuo-monero-maintenance-2024-q3.md

@@ -0,0 +1,55 @@
+---
+layout: fr
+title: Revuo Monero maintenance (2024 Q3)
+author: rottenwheel
+date: June 3, 2024
+amount: 8
+milestones:
+  - name: July
+    funds: 3
+    done:
+    status: unfinished
+  - name: August
+    funds: 3
+    done:
+    status: unfinished
+  - name: September
+    funds: 2
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+# What
+
+I will maintain Revuo Monero (https://www.revuo-xmr.com/) for the next 3 months (2024 Q3): July, August and September. There is a chance I may skip one week to tend to real life issues, in such case, next issue will just cover 2 weeks instead of 1.
+
+Tasks:
+
+- Daily/weekly: search, curate, structure and post new reports/stories.
+- As Needed: outreach (engage with the community on Matrix, XMPP, emails).
+- As Needed: make sure the website is live and working as expected (server maintenance, billing, etc.)
+
+# Who
+
+rottenwheel, I joined the Monero community some time in 2017 by jumping into IRC, attending some Workgroup meetings, volunteering at the Monero village at DEFCON 28 in 2019 (https://redlib.zaggy.nl/r/Monero/comments/cqegma/monero_village_defcon_2019_report/), participating in community events and being involved with other community-driven, smaller projects.
+
+As a proof of work for this specific proposal, I have, since January 2022 until now, written almost 200 issues, 195 of which were published in current Revuo's self-hosted website. That does not take into account the following enhancements.
+
+Up to this point, all efforts behind Revuo Monero's comeback after Diego "rehrar" Salazar was let go and Revuo Monero's publication was paused for a few months, include but are not limited to:
+
+- Light/dark theme with a toggle button (mostly in CSS/HTML, minimizing the reliance in JavaScript as much as possible; site loads everything just fine in Tor browser with strict security mode on.)
+- Support and Source Code sections added.
+- RSS and Support icons.
+- Google fonts removed.
+- Twitter and Nostr profiles set up and posting new issues every week automatically. Twitter: https://nitter.poast.org/revuoxmr; Nostr: https://primal.net/p/npub1tn8spk9zhxrctg2qym3gj8r7eq2wk6z3phrl8304wc54vt9qam4qvzw6jx
+
+# Proposal
+
+I will publish weekly issues (4 per month) at a rate of $100 / issue. At $157.5 / XMR this makes 8 XMR (~7.6++) (100 * 4 * 3 = $1200) to be split in 3 monthly milestones. Rounding current 7.6++ XMR to 8 XMR to cover for price votatility between Work In Progress phase and progressive milestone(s) payouts.