Skip to content
Snippets Groups Projects

[Monero Aligned] Proposal for 1M5 Integration as Proxy

1 unresolved thread

layout: en
title: Proposal for 1M5 Integration as Proxy
author: ObjectOrange
date: March 2020
amount: 150
milestones: 
  - name: Reverse-Engineer/Design/Document API
    funds: 50
    done:
    status: unfinished
  - name: Implementation
    funds: 50
    done:
    status: unfinished
  - name: Testnet/Document Setup/Configuration
    funds: 50
    done:
    status: unfinished
payouts:
  - date:
    amount:
  - date:
    amount:
  - date:
    amount:

Proposal for 1M5 Integration as Proxy

Proposal to integrate 1M5 1M5 with Monero Network's communication stack, inter-node and when accessing public nodes.

Issue

Censorship is the suppression of speech, public communication, or other information, on the basis that such material is considered objectionable, harmful, sensitive, politically incorrect or "inconvenient" as determined by government authorities or by community consensus. Monero, by providing a private decentralized crypto-currency not registered in any jurisdiction, is likely to come under attack by jurisdictions that consider it illegal.

Monero currently uses the clearnet to communicate internode although there have been attempts to integrate I2P and some do set it up to use TOR. TOR can be censored, as is done in China, by discovering entry nodes and blocking them by IP. To block 2000 entry nodes is easy work as they are provided publicly and it's not a large list. Bridges do help, but have still remained an unreliable option. VPNs themselves are also targeted and blocked. But TOR is the ideal method to connect to public nodes (e.g. for pricing) as they normally are ran in the clear via the internet.

The latest support in Monero for both TOR and I2P is discussed in this file: https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md. It claims that it's still experimental and requires much manual setup of TOR hidden services and I2P. It requires manual TOR hidden service setup and port selection and manual selection of TOR and I2P peers instead of random TOR ports and building up a network of peers through discovery. It does nothing regarding the ability to relay broadcasts through alternative networks when TOR and/or I2P is getting blocked in the local node. The lack of some intelligent routing mechanism between anonymity internet overlay networks, alternative radio networks, and LiFi is the reason for interest in integrating 1M5 into the communication stack. Having a team on this full-time focused solely on censorship-resistance is a necessity if not immediate, it will be with no doubt.

Opportunities

The Invisible Internet Project (I2P) is much less known and thus less targeted. It works somewhat similarly to TOR with a few differences. Where TOR shines when accessing clearnet sites privately, I2P shines accessing other nodes running I2P, e.g. peer-to-peer networking apps like messaging. I2P doesn't have entry nodes, every node is a potential entry node and there are roughly 65,000 I2P peers (all I2P peers by default are contributors to the network). I2P, like any application, has its vulnerabilities, but they are an active team working to constantly improve it. There is no known attempts to block the I2P network globally although when cellular towers are turned off or the user is behind a severely restrictive firewall (e.g. corporate), even I2P will not work as it requires internet access. This is where Bluetooth and WiFi Direct have become helpful.

Bluetooth and WiFi Direct support sending messages to nearby peers to share information. This has been used successfully in demonstrations in Hong Kong among others. But what they do not do is propagate out until a peer with internet access is available and use that peer to complete a request for an internet resource. Bluetooth and WiFi Direct are implemented using low-powered radios in phones and PCs and they're easily jammed (WiFi more so than Bluetooth). When in this position, shortwave communications is necessary.

Using the full radio spectrum is the next major advancement in commercial radio communications and 1M5 is working with radio engineers globally to make this a reality. Adding anti-jamming capabilities additionally will enhance censorship resistance further. But what happens when you're under serious jamming? LiFi is the next battlefield.

LiFi is short for Light Fidelity. It is basically wireless light communications. A dongle with a LiFi transceiver can send/receive light as data to/from another LiFi transceiver and the only method for blocking it is to physically block the light. Line-of-sight is required although some bouncing can be supported with degraded bandwidth and range and the frequency can be changed so that it is invisible to the human eye - it can be used in the dark without seeing any visible light.

Proposal

Routing around blocks using TOR, I2P, Bluetooth, WiFi Direct, Full Spectrum Radio, and LiFi to ensure censorship resistance is the primary mission behind 1M5 - Invisible Matrix Services. It's designed to support additional future networks like Nym if/when they prove to be helpful. When integrated with Monero, 1M5 would ensure each node can find each other and maintain communications regardless how attacked, even with a national or global internet shutdown. It would also ensure the same level of censorship-resistance when accessing remote public nodes like price nodes...any public node.

Development would require integration with 1M5 as a proxy, testing the integration on testnet, then documenting it. In addition, a 1M5 Operator/Admin Role would be recommended to monitor and report on 1M5 effectiveness fixing any bugs that come up while providing an expected level of support.

1M5 is open source under the Unlicense 'license' and free to use.

1M5 currently uses TOR, I2P, and Bluetooth. WiFi-Direct, Full Spectrum Radio (including Locha Mesh if it works out), and LiFi will be integrated in the future.

Considering TOR and I2P is currently supported by following the directions in this file: https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md, it is believed by the author that implementation could be used to change the proxy to 1M5 so that the networks are setup automatically as much as possible, networks are chosen based on their status, while also allowing the end user to constrain which networks are to be used based on their current situation, e.g. a new laws comes out threatening prison time if using Monero yet TOR/I2P are not being physically blocked. Implementation should be as easy as replacing the proxy configuration to this: --proxy 1m5,127.0.0.1:2020,10 and ensuring all communications are able to use the proxy vs just transactions. This will require work in 1M5 to support running its platform daemon as a proxy which hasn't been implemented yet. Initial work will be to just replace the transaction proxy so that it can be a third option for testing out the router. Future work on testing success of tx proxy integration could be to move all comms to the proxy and add options to a Monero GUI for enabling the manual overriding of what networks to use/not use by the end user based on their perceived situational awareness (threats).

The exact amount of work is not known although 75 XMR appeared steep to a member of the community for two weeks work. So I think it might be a good idea too to follow a monthly minimal payout based on progress to show engagement and progress to reduce risk.

March, April, May 2020: 50 XMR (~$4,000) each Total: 150 XMR

Milestones:

  1. EOM March 2020 - Reverse-engineer current TOR/I2P proxies to determine API required to support as a proxy, document, and setup 1M5 project for implementation
  2. EOM April 2020 - Implement 1M5 API to support Monero transactions and document
  3. EOM May 2020 - Develop and use Test framework to ensure transactions validate correctly using testnet and demo

Likely Future Proposals

  • An Admin Role at minimal monthly expense to maintain and improve on 1M5 for Monero
  • Full support of all communications through 1M5 to ensure censorship-resistance of all comms
  • Additional sensor testing with Monero as new sensors come on-line
  • Addition of manual control over the 1M5 router sensor selection through GUIs

Progress updates

Updates will be shared as tasks are finished in GitHub (https://github.com/1m5/1m5). Our website (https://1m5.io) will be updated to reflect the work with and support by Monero. Upon successful testing of Monero with 1M5 resisting manual censorship attempts, we will promote the relationship if desired by our main speaker Amin Rafie (https://arafiee.com/) during events.

Notes

  • The best timing for this integration is now.
  • Censorship of TOR is growing and I2P will be next. Automatic dynamic selection of networks routing around blocks while ensuring manual selection is needed.
  • Monero is known for its privacy. Let's make it know for censorship-resistance too.

Resources

Edited by Brian Taylor

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Brian Taylor mentioned in merge request !115 (merged)

    mentioned in merge request !115 (merged)

  • Brian Taylor changed title from Proposal for evaluating censorship resistance with 1M5 integration. to [Monero Aligned] Proposal for evaluating censorship resistance with 1M5 integration.

    changed title from Proposal for evaluating censorship resistance with 1M5 integration. to [Monero Aligned] Proposal for evaluating censorship resistance with 1M5 integration.

  • Brian Taylor changed the description

    changed the description

  • You made a similar proposal to Bisq: https://github.com/bisq-network/proposals/issues/168 (the proposal was refused)

    but in their case you proposed an actual integration. Here you are asking for funding (and a good amount of $) only for a preliminary analysis.

    I say no.

  • It was not refused. They agreed it was needed but did not have the funds yet - they are experiencing issues within their DAO of inflating their coins driving its price down and they need to get control of that first. I shouldn't have did a full proposal with them yet until further investigation - it was changed today also to reflect that. That's why I'm only asking for an evaluation with Monero to determine a more concrete proposal. Could you explain why you're against this? What is not a 'good amount'?

    Edited by Brian Taylor
  • Could you explain why you're against this?

    I think the community shouldn't spend more than $6000 to fund somebody to evaluate an integration in these circumstances. If there is the will to integrate this technology with Monero, the evaluation (even just partial) should be done as a free contribute. It would show this person actually care of integrating the technology into Monero and not only to find a source of funds. This is especially necessary when the person asking for funds doesn't have a reputation inside the community. Which is your case.

  • $6k for an evaluation is cheap, but I definitely understand the hesitation and yes there's some risk. I do have a good reputation which you can see on LinkedIn and you can see my work with 1M5 on GitHub. It's also risky for me to engage in this without some feedback from the Monero community that they're interested, same for Bisq. That's what these proposals really are...an introduction and a beginning to determine level of interest and support. If there is some level of support, I can meet in the middle and will provide a preliminary evaluation with a few options.

    Edited by Brian Taylor
    • Well, I think we're in far more luck than I anticipated. I discovered this file in the repo: https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md. Apparently TOR and I2P are supported currently just require manual setup and are both just broadcasted over each, but only transactions and a couple other requests. I'm going to propose adding 1M5 as a third proxy option to use for testing it out. The benefit would be that it would automatically setup the TOR hidden services, use seeds to bootstrap the network, perform network discovery so manual peers would not need to be selected, and provide automatic routing based on the environment (situational awareness). I will update the proposal. I don't see this being too much work, mainly creating the RPC for Monero to call as a tx proxy and perhaps some work on the Monero side.

      I also spoke with the Locha Mesh team and will be working to integrate their radio network into 1M5 as part of the full spectrum radio sensor and will also include discovery. Monero could support integrating with Locha through only 1M5 or it could include both so that Locha could be used as a proxy on its own.

      Edited by Brian Taylor
    • I'm going to propose adding 1M5 as a third proxy option

      That sounds like a good start :) I suggest you to come chat in the dev channel (#monero-dev on Freenode, Matrix and MatterMost), so to talk directly with the devs and have their opinions on the integration. That would help to give a better shape to your improved CCS proposal.

    • Please register or sign in to reply
  • Brian Taylor changed the description

    changed the description

  • Brian Taylor changed title from [Monero Aligned] Proposal for evaluating censorship resistance with 1M5 integration. to [Monero Aligned] Proposal for 1M5 Integration as Proxy

    changed title from [Monero Aligned] Proposal for evaluating censorship resistance with 1M5 integration. to [Monero Aligned] Proposal for 1M5 Integration as Proxy

  • Brian Taylor changed the description

    changed the description

  • Brian Taylor changed the description

    changed the description

  • Anyone know the status of this?

  • Closing for staleness. Feel free to open a new CCS if desired.

  • closed

Please register or sign in to reply
Loading