MASQ combines the benefits of VPN and Tor technology to create a superior next-generation privacy software, where users are rewarded for supporting an uncensored global web. Users gain privacy and anonymity online, while helping promote Internet Freedom.





The MASQ project was forked from Substratum's Node project in order to carry on development after Substratum ceased operations in October of 2019. All credit for the original idea, the original design, and the first two years of MASQ's development belongs to Substratum.


The MASQ Network is an open-source network that allows anyone to allocate spare computing resources to make the internet a free and fair place for the entire world. It is a worldwide collection of nodes that securely delivers content without the need of a VPN or Tor.

Because there's no single authority delivering or monitoring content, censorship and geo-restricted sites won't be an issue on the MASQ Network. It doesn't matter where you live or what content you're accessing, everyone in the world sees the exact same content.

MASQ Node is the foundation of the MASQ Network.

It is what the average user runs to earn MASQ and dedicate some of their computers' resources towards the network. People who run a MASQ Node can be rewarded with cryptocurrency for each time they serve content.

MASQ Nodes work together to relay CORES packages and content on the network. When a user requests a site, nodes use artificial intelligence to find the most expedient and secure way to get the information to that user. Multiple nodes work to fulfill a single request in order to maintain a necessary level of anonymity.

Tools / Environment Setup

MASQ Node software is written in Rust. We use rustup to install what we need (e.g. rustc, cargo, etc). If you don't already have it, you can get it from the rustup installation page.

To keep our source code consistently formatted, we use rustfmt, which is a plugin for cargo. If you want to use our build scripts to build the code, you'll need to install this plugin in your Rust environment. (We use the stable version, not the nightly version.)

Some Linux distributions (notably Ubuntu ≥16.04 Desktop) have an incompatibility with MASQ Node. If you think you might be affected, see The Port 53 Problem for more information.

If you're using Windows, you'll need to run the build scripts using git-bash. If you've cloned this repository, you probably already have git-bash; but if you don't, look at How To Install git-bash On Windows.

Also, you will need an Internet connection when you build so that cargo can pull down dependencies.

How To

We build and run tests for MASQ Node using bash scripts located in the ci directory of each sub-project. To clean, build, and run tests for all sub-projects in one step, start at the top level of the project (the directory is probably called Node).

If you're using Linux or macOS

First, please note that at a few points during the process, the build will stop and ask you for your password. This is because some of the integration tests need to run with root privilege, to change DNS settings, open low-numbered ports, etc. (It is possible but not easy to build without giving root privilege or running integration tests; if this turns out to be something people want to do, we'll make it easier.)

Open a standard terminal window and type:

$ ci/

If you're using Windows

MASQ Node utilizes a Web3 crate to facilitate Blockchain communications. The Web3 crate depends on OpenSSL for TLS when connecting over HTTPS. Some setup for a proper Windows build environment may be needed. You have two choices: a) install OpenSSL and allow it to be dynamically linked at compile time b) download an OpenSSL binary and set OPENSSL_STATIC and allow it to be statically linked at compile time. See the Rust OpenSSL Documentation for more information on configuring this environment variable. If it is not set, dynamic linking is assumed. The binaries we distribute are statically linked.

Open a git-bash window as administrator and type:

$ ci/

Wondering where all our tests are? The convention in Rust is to write unit tests in same file as the source, in a module at the end.

Run MASQ Node locally

Once you've successfully built the node executable, you can run MASQ Node from the command line.

Currently, your DNS must be set to in order to route traffic through MASQ Node; then it must be set back to whatever it was before when you're done with MASQ Node and you want to get back on the normal Internet.

The MASQ Node software includes a multi-platform DNS utility that you can use to subvert your DNS settings to, like this:

$ cd 
$ sudo Node/dns_utility/target/release/dns_utility subvert

If you have trouble with dns_utility or you'd rather make your DNS configuration changes manually, look for instructions for your platform.

Once your DNS is successfully subverted, you can start the MASQ Node itself. Currently, there are two major ways the MASQ Node can run: zero-hop and decentralized.

A zero-hop MASQ Node is very easy to start, and it's self-contained: every zero-hop MASQ Node has an entire MASQ Network inside it. However, it doesn't communicate with any other MASQ Nodes. Every network transaction is zero-hop: your MASQ Node is the Client node, the Originating node, and the Exit node all at once. A zero-hop MASQ Node is good for exploring the system and verifying its compatibility with your hardware, but it doesn't relay traffic through any other MASQ Nodes.

A decentralized MASQ Node is considerably more difficult to start, because you have to give it much more information to get it running; however, it can route your traffic through other MASQ Nodes running elsewhere in the world to get it to and from your destination.

Important Note: Please remember that at the moment neither zero-hop MASQ Nodes nor decentralized MASQ Nodes are secure or private in any sense of the word. Please don't use them for any kind of sensitive traffic at this stage.

Supplying Configuration To MASQ Node

There are three ways to get configuration information into a MASQ Node on startup. In decreasing level of priority, these are:

  1. the command line
  2. the shell environment
  3. the configuration file

Any piece of configuration information can be provided through any of these channels, with one exception: the path to the configuration file cannot be taken from the configuration file. (It can be provided there, but it will never be taken from there.) Configuration information provided in the environment will supersede conflicting information provided in the configuration file, and information provided on the command line will supersede conflicting information from both of the other sources.

Command line

This is the easiest. In this file, all our documentation of the configuration options shows you how to provide them on the command line. Keep in mind, though, that command lines tend to be preserved by the operating system for display to users who want to see process lists. Therefore, the command line may not be the best place to specify sensitive or secret configuration information. (Nothing prevents you from doing this, though, so be careful.)

Shell Environment

If you see that the command line accepts a parameter such as --clandestine-port 1234, then you can supply that same parameter in the environment by setting the MASQ_CLANDESTINE_PORT environment variable to 1234. Note that you need to remove the initial -- prefix, convert the name to all uppercase, and add a MASQ_ prefix to namespace the parameter against other applications that might look for a similar variable.

Configuration File

The configuration file, by default, resides in the data directory (see the --data-directory parameter for further information) and is named config.toml. If you leave the configuration file unspecified, this is where MASQ Node will look for it. If it's found, it will be used; if it's not, MASQ Node will act as though it had been found but empty. But if you want to use a different file, specify it either as --config-file on the command line or as MASQ_CONFIG_FILE in the environment. If you specify a relative filename, MASQ Node will look for the configuration file in the data directory; if you specify an absolute filename, MASQ Node will not use the data directory to find the configuration file.

The configuration file should be in TOML format. TOML is a competitor to other formats like JSON and YAML, but the MASQ Node uses only scalar settings, not arrays or tables. If you see that the command line accepts a parameter such as --clandestine-port 1234, then you can supply that same parameter in the configuration file by adding the following line to it:

clandestine-port = "1234"

Note that you need to remove the initial -- prefix. All the configuration parameters will work if you supply their values as double-quoted strings, but if they're numeric values, you can supply them numerically as well--for example,

clandestine-port = 1234

Keep in mind that a configuration file is persistent information: anyone who has or can gain read access to the file can read whatever's in it, whether MASQ Node is running or not. Therefore, the configuration file may not be the best place to specify sensitive or secret configuration information. (Nothing prevents you from doing this, though, so be careful.)

Running a Zero-Hop MASQ Node locally

Here's all you need to start your zero-hop MASQ Node:

$ sudo Node/node/target/release/MASQNode --dns-servers

In the above example, we're using Cloudflare's DNS,, but you can use your preferred DNS. If you can't choose just one favorite DNS, you can also specify multiple ones, separated by a comma but no space (,).

Why do we specify --dns-servers? MASQ Nodes still need to talk to the greater Internet. See the ProxyClient README for more information.

Running a Decentralized MASQ Node locally

Decentralized operation is much more complex than zero-hop operation, so there are many more options that are available.

In order to run decentralized, MASQ Node needs at least an earning wallet (an Ethereum wallet into which other nodes will make payments for the services your node provides). If you plan to use your node to consume data with a browser or other network application, it will also need to be configured with a funded consuming wallet (an Ethereum wallet from which it will make payments for the services other nodes provide).

Service Mode

When started in Service mode, MASQ Node will come up, join the MASQ Network, and start serving and consuming clandestine data until you stop it. Since Service mode requires listening on low-numbered restricted ports, starting MASQ Node in Service mode requires administrative privilege (sudo on Linux and macOS, a command window started as Administrator in Windows).

  • --help Displays command help and stops. Does not require administrative privilege. Cannot be specified in the environment or config file.

  • --version Displays the currently-running version of MASQ Node and stops. Does not require administrative privilege. Cannot be specified in the environment or config file.

  • --blockchain-service-url A required URL that should point to an Infura, Geth, or Parity HTTP endpoint. Eventually, MASQ Node will direct blockchain traffic through the MASQ Network when the parameter is not specified, allowing other nodes to talk to the blockchain on your behalf.

  • --chain The blockchain network MASQ Node will configure itself to use. You must ensure the Ethereum client specified by --blockchain-service-url communicates with the same blockchain network.

  • --ip This is the public IP address of your MASQ Node: that is, the IP address at which other MASQ Nodes can contact yours. If you're in a fairly standard residential situation, then this will be the IP address issued to your router by your ISP, and in order to receive data you'll need to create holes in your router's firewall to enable incoming data to reach you on your clandestine ports (see below). In the future, this will be taken care of for you (if you haven't turned off UPnP on your router), but right now it's manual.

  • --dns-servers ,... This is the same list of DNS servers needed for zero-hop operation. Whenever your MASQ Node is used as an exit node, it will contact these DNS servers to find the host the client is trying to reach.

  • --neighbors ::[;;...][,::[;;...],... This is how you tell MASQ Node about its initial neighbors. You can specify as many neighbors as you like, with the descriptors separated by commas but no spaces. The in a descriptor is the Base64-encoded public key of the neighbor in question. The is the public IP address of that neighbor, and the numbers are the clandestine ports on which the neighbor is listening. If the neighbor node is one you're running yourself, you'll see it print this information to the console when it comes up. If it's somewhere else on the Internet, you'll probably receive this information in an email or chat message to copy/paste onto your command line.

  • --clandestine-port This is an optional parameter. If you don't specify a clandestine port, your node will use the same clandestine port it used last time it ran, if that port is still available. If the port is no longer available, MASQ Node will refuse to start until either it is available or until you specify a --clandestine-port, whereupon it will use the new port every time it starts. If it's a new installation, it will select a random unused clandestine port between 1025 and 9999, and use that every time. Whenever you specify --clandestine-port, the port you specify will keep being used until you reinstall or specify a different one. You can specify any port between 1025 and 65535. Whatever the clandestine port is, it will be printed in the log and to the console as part of the node descriptor when MASQ Node starts up. Note: This is a temporary parameter; the concept of a special clandestine port will go away someday, and node descriptors will look different.

  • --log-level MASQ Node has the potential to log a lot of data. (A lot of data: a busy node can fill your disk in a few minutes.) This parameter allows you to specify how much of that potential will be realized. trace will encourage MASQ Node to reach its full potential, and should probably only be used when you're going to run MASQ Node for a few seconds to try one thing that's been giving you problems, and then shut it off to look at the logs. error logs only the most serious of errors, and the other values are in-between compromise points. Default is warn.

  • --ui-port This is how you tell MASQ Node which port it should listen on for local WebSocket connections to the UI gateway. This allows MASQ Node to be controlled and inspected by other programs, such as the MASQ Node UI. The default port is 5333; in most cases, this will not need to be changed.

  • --data-directory This is the directory in which MASQ Node will keep the state that needs to persist from run to run. If it's not specified, the default is $XDG_DATA_HOME/MASQ/ or $HOME/.local/share/MASQ/ on Linux, %APPDATA%\MASQ\ on Windows, and $HOME/Library/Application Support/MASQ/ on macOS where chain-name is either ropsten or mainnet (see --chain parameter for more information). If it is specified but doesn't exist, MASQ Node will try to create the directory and abort if it fails. If persistent state exists in the directory, but it was created by a version of MASQ Node that is incompatible with the version you're trying to start, MASQ Node will abort. If this is the case, either remove the existing state and restart MASQ Node, or specify a different --data-directory directory.

  • --config-file Rather than specifying the same parameter values over and over when you start MASQ Node in Service mode, you can put parameters that rarely or never change in a TOML file as strings or numeric values. The entries in the config file should have exactly the same names they would have on the command line, without the -- prefix. For example, instead of specifying


    on the command line, you could put

    dns-servers = ","

    in the config file.

    If you name the file config.toml and put it in either the default data directory or the directory specified by --data-directory (see above), MASQ Node will find and employ it automatically. If it has a different name or location, specify that with --config-file. If the path you specify is relative, it will be interpreted starting with the active data directory. If it's absolute, it will be evaluated without reference to the data directory. If you specify a --config-file and MASQ Node can't find it, it will abort its startup with an error.

  • --consuming-private-key <64-CHARACTER HEX KEY> This allows you to specify the private key of your consuming wallet without having it related to your earning wallet by derivation path. While this method is fully functional, it should be used only for automated testing. It cannot be used if the database already contains a wallet pair. If you do use it, keep in mind that your consuming wallet private key is sensitive information: anyone who gets hold of it can drain all your funds. It's best to specify it in the environment (as MASQ_CONSUMING_PRIVATE_KEY) rather than on the command line or in the config file. You won't be allowed to use this parameter if you've already specified a consuming wallet derivation path in Generate or Recover mode; and if you do use this parameter, you must specify exactly the same private key every time you run your MASQ Node. If you always use --consuming-private-key and --earning-wallet with an address, you can use MASQ Node in Service mode without having to go through Generate or Recover mode first, and without supplying a wallet password.

  • --earning-wallet This is an Ethereum address ("0x" followed by 40 hexadecimal digits) which MASQ Node will use to identify your earning wallet. While this method is fully functional, it should be used only for automated testing. It cannot be used if the database already contains a wallet pair.

  • --gas-price The gas price is the amount of Gwei you will pay per unit of gas used in a transaction.

If you don't have an earning wallet set up at all, and you don't specify this either, a default earning wallet will be used, in which case the funds you earn will go to MASQ instead of to you: so unless you're in a philanthropic mood, you should be sure to set up or specify your earning wallet.

In order to run decentralized, the MASQ Node must know the IP address others can use to contact it. Therefore, you must supply --ip. If you don't supply --ip, your node will come up in zero-hop mode and never route through any other nodes.

If you're starting the very first MASQ Node in your MASQ network, then you don't have to tell your node about any preexisting network; but otherwise, you'll need to specify --neighbors so that your node will know how to join the network that is already in place.

Your home network is behind your internet provider's router and a public IP address. Other nodes in the MASQ Network will contact your node through your public IP address, requiring at least one port to be forwarded on your router. The MASQ Node Gossip protocol "gossips" to other nodes the clandestine port you are listening on, and it is that port you will need to open. When your node is started it will write its descriptor to the console and the log, giving the clandestine port it is using; you will need to forward that port from your router to your computer's IP address.

Forwarding ports on your router is somewhat technical. At a minimum, you should know how to log in to your router in order to make changes to its configuration. The process is interchangeably called forwarding a port, opening a port, or mapping a port, and may be labeled as such in the router's interface. Assigning a static IP address for your computer will make this process easier, as otherwise your IP address can change each time your computer restarts or you restart the network interface. There are many guides that you can find on the Internet by searching for "Port Forwarding" or "How to Port Forwarding". Here is an example:

More information on the operation, care, and feeding of the Neighborhood is available in the neighborhood_subproject.

Terminating a MASQ Node (Zero-Hop or Decentralized)

To terminate the MASQ Node, just press Ctrl-C in the terminal window. Then you'll still need to revert your machine's DNS settings:

$ sudo Node/dns_utility/target/release/dns_utility revert

This should have you using the Internet normally again.

However, if you've been running decentralized, you'll probably want to close the holes in your router's firewall. Don't leave them open against the next time you run: your node will pick different clandestine ports the next time.


MASQ Node, like any other piece of software, can encounter obstacles it cannot overcome in the process of trying to do what you ask it to do. It needs to be able to tell you about these insurmountable obstacles, but it lives in a place that makes this difficult. If it were a Web browser, it would have a window on which to display error messages. If it were a Web server it could send data describing the errors to your browser to display. But it's neither of these things; instead, it's crowded into a place in the protocol stack where neither the browser nor the server expects it to exist.

Therefore, certain error messages are a bit awkward to display, especially if they involve TLS connections. Let's look at how MASQ Node deals with certain kinds of errors.


An insecure HTTP connection is one that is based on a URL that begins with http:// (as opposed to https://). The fact that it is insecure means that MASQ Node (and every other process that handles the data) can intrude on the data stream and make your browser display whatever they want it to, which may or may not be related to what the server on the other end of the connection intended.

When errors occur, this is very useful for MASQ Node. If you request something from an HTTP server, and for some reason MASQ Node cannot relay your request to that server, or cannot relay the response from the server back to you, it will instead impersonate the server and create a counterfeit response describing the error, and display that to you instead of the server response it can't give you. (Don't worry: MASQ Node's impersonation of the server is deliberately very bad, so you can easily tell that the error is not coming from the server. You won't be misled). The error message will describe the problem and suggest ways it might be alleviated.


TLS (spoken over connections based on URLs that begin with https://) is a much more difficult beast. Once a TLS connection is set up between your browser and a server, MASQ Node cannot understand a single bit of the dataflow, and it cannot modify a single bit of it without your browser throwing red alerts and refusing to show you the modified data. This is good for you and your privacy, but it doesn't make it easy for MASQ Node to communicate with you via the browser.

There is a small exception.

Once a TLS connection is set up, it's completely secure. But while it's being set up, before the encrypted tunnel has been established, there's a little MASQ Node can do. Specifically, it can inject what's called a TLS Alert into the stream of data, as long as it is injected very early. This TLS Alert has a single byte that MASQ Node can use to tell you about problems it has relaying your data. There are a number of predefined values this byte can take on, and MASQ Node has to pick one of these values: it can't make up its own.

If your browser is trying to load a page when the error occurs, you'll see a cryptic message in its window telling you that you're not going to get what you're after. The exact wording of the error depends on the exact type of the TLS Alert. If your browser is trying to communicate in the background when the error occurs, you probably won't see it on the screen; but if the browser stops responding, you can open its developer tools and check the JavaScript console; if MASQ Node sent a TLS Alert, you'll see it there.

Since the concerns of the MASQ Node aren't precisely the same as the concerns of a TLS endpoint, the correspondence can't always be made exact, so here are some specific TLS Alert values that MASQ Node produces in specific situations.

  • Routing Failure - internal_error: If your node is not yet "warmed up" enough in the MASQ Network to see a large enough neighborhood to be able to create a clandestine route that meets your specifications, it will raise a TLS internal_error Alert. This will probably be displayed by your browser as some sort of protocol error--which, strictly speaking, it is. If this happens, just wait awhile for your node and the MASQ Network to Gossip with each other and spread around the necessary information. Then try reloading the page.

  • DNS Resolution Failure - unrecognized_name: Even though you contact websites at names like and, the real Internet operates on the basis of IP addresses (like and Before it's useful for retrieving data, your server name has to be translated into an IP address. This is the job of a DNS server. Much of Internet censorship consists of crippling the DNS servers you have available to you so that they can't give you the correct IP address for the server name you're seeking. MASQ Node captures the DNS queries your browser makes and forwards them across the MASQ Network to some other node that hopefully has access to a non-censored DNS server that does know the IP address you want. But this is a complex task and it may fail. For example, perhaps you typed the server name wrong, and nobody knows an IP address it matches. Or perhaps your MASQ Node guessed wrong, and the exit node to which it forwarded your DNS query is also handicapped by a censored DNS and can't find it either. In either case, MASQ Node will send your browser a TLS unrecognized_name alert, which your browser will probably present to you as some form of can't-find-host error. If you reload the page, MASQ Node will try to select a different exit node, if available--one that hasn't failed to resolve a DNS query--for the next attempt, which might bring you better fortune. Of course, if you have typed the name wrong, just reloading the page will take another innocent exit node out of circulation and make it even harder for you to get where you want to go.


We run tests on every push to master on these platforms:

  • Ubuntu 16.04 Desktop 64-bit
  • MacOS High Sierra
  • Windows 10 64-bit

MASQ Node doesn't reliably build on 32-bit Windows due to issues with the build tools for that platform. We recommend using a 64-bit version to build.

We do plan to release binaries that will run on 32-bit Windows, but they will likely be built on 64-bit Windows.

Copyright (c) 2019-2020, MASQ Network

Copyright (c) 2017-2019, Substratum LLC and/or its affiliates. All rights reserved.

  • Contact the authors of linefeed

    Contact the authors of linefeed

    There is nice chance, I think, that we could ask authors of linefeed library for some corrections that could reflect certain minor bugs we're gonna have to deal with otherwise. There is danger that people will blame us for we haven't fixed bugs in our code.

    At this point, I think we have enough information to say that we're dealing with a ghost cursor on Windows, in the simplest cmd in particular. What does it do or when? From my observation, because the cursor is blinking while it's waiting for the input if you enter what you typed just at the moment when the cursor is shown on the screen it will persist there, or in other words that immediate state of him freezes in place although we've already gotten a new blinking cursor on a new line.

    You can see more of such frozen cursors in the same time in the terminal, all depends on the timing in which you're executing your supplied strings.

    If you scroll far away so that the incriminated place becomes covered behind the boarders of the terminal and when you get back then ghosts of those cursors are gone.

    Secondly. This is just an assumption though. I think that handling of the signal Ctrl + c doesn't work. (Maybe of others too - now it's in the phase of testing) I haven't been in a situation where it would; still I think I miss nothing regarding how it's intended to get working in the code thought it isn't.

    opened by bertllll 4
  • GH-496: Update dependencies

    GH-496: Update dependencies

    Updated the following dependencies to the indicated stable versions.

    backtrace = "0.3.62" base58 = "0.2.0" base64 = "0.13.0" chrono = "0.4.19" clap = "2.33.3" core-foundation = "0.7.0" crossbeam-channel = "0.5.1" ctrlc = "3.2.1" dirs = "4.0.0" ethsign = "0.7.3" ethsign-crypto = "0.2.1" fdlimit = "0.2.1" flexi_logger = "0.15.12" futures = "0.1.31" heck = "0.3.3" http = "0.2.5" indoc = "1.0.3" ipconfig = "0.2.2" itertools = "0.10.1" libc = "0.2.107" libsecp256k1 = "0.7.0" log = "0.4.14" native-tls = "0.2.8" nix = "0.23.0" openssl = "0.10.38" pretty-hex = "0.2.1" rand = "0.8.4" regex = "1.5.4" reqwest = "0.11.6" rlp = "0.4.6" rpassword = "5.0.1" rusqlite = "0.26.1" rustc-hex = "2.1.0" serde = "1.0.130" serde_derive = "1.0.130" serde_json = "1.0.69" serde_cbor = "0.11.2" serial_test_derive = "0.5.1" serial_test = "0.5.1" sysinfo = "0.21.1" system-configuration = "0.4.0" tiny-bip39 = "0.8.2" tiny-hderive = "0.3.0" tokio-core = "0.1.18" toml = "0.5.8" unindent = "0.1.7" websocket = "0.26.2" winreg = "0.10.1"

    opened by FinsaasGH 2
  • Rate Test 1A

    Rate Test 1A


    Had two attempts at making a PR to kickoff GH Actions - both failed Both failed: image

    Doing PR to referential_branch to see if Actions runs the build pipelines

    opened by kauri-hero 1
  • Delete


    Moving the Greypaper to its own repo, so not to disrupt Node repo Simply moving this md file to its own repo

    @dnwiebe I don't think this will affect any other PRs or branches in progress, but can you please review and approve the merge.

    opened by kauri-hero 1
  • v0.7.0: GH-497 (#211)

    v0.7.0: GH-497 (#211)

    • GH-497: first stamp; roughly moved the core shared dao utils

    • GH-497: small refactoring; thinking about nicer facade

    • GH-497: probably finely usable now; next I will have to analyze the places where to use the shared method, possibly also to start adjusting the number data types which will be a chaos

    • GH-497: added some marks of where dao methods will be replaced and etc; also found quite a lot of dead code

    • GH-497: savepoint; starting to experimentally implement the new boundholder

    • GH-497: changing by small steps; added the special primitive type (but may not be used); now before adjusting PayableAccount

    • GH-497: a small convinient method added; now stuck thinking of a way out of this

    • GH-497: pretty dug up - big changes in progress; now finished some types replacement and want to try to integrate the shared methods for dealing with the DB

    • GH-497: shared methods roughly integrated; now I will probs need to change threshold time params to take u64

    • GH-497: compiling but many failing tests; I screwed a few things I guess :)

    • GH-497: new direction of the architecture; key params and obvious sign attribute

    • GH-497: interim commit

    • GH-497: a few more tests and features hooked up

    • GH-497: interim commit

    • GH-497: finally in a working state where I can start to think of changing data types in table declarations.

    • GH-497: interim commit

    • GH-497: DB migration deployed + reorganization in some db utils for testing

    • GH-497: advanced migration with realistic converting i64 to blobs almost implemented

    • GH-497: migration practically complete now

    • GH-497: db-migration satisfactory

    • GH-497: a few more tests made pass

    • GH-497: a few insignificant tests fulfilled; elaborating the concept of paymnet thresholds - and correction of the given code as it probably had not worked as intended

    • GH-497: paid delinquencies tests fixed

    • GH-497: backup after a long day; stabilized exact computations upon the sloped part of the payment thresholds, corner limits at the same place, etc.

    • GH-497: new delinquency model seems working at the fundamental level

    • GH-497: metadata collection optimized

    • GH-497: fixed totals for payable and receivable and some small defects elsewhere

    • GH-497: fixing tests for blockchain_interface and little cleaning

    • GH-497: completed tests for upsert in blob utils

    • GH-497: a lot of minor improvements, refactoring

    • GH-497: clean-up before I make step toward designing views into payable and receivable tables

    • GH-497: first portion of work for masq financials command, advanced

    • GH-497: financials command constructor tested

    • GH-497: top payable rendering works

    • GH-497: works on rendring records continue

    • GH-497: setting with all information to be printed works fine

    • GH-497: financial command finished at masq

    • GH-497: moved dao_utils over under accountent; financials backend fundamental structure is finished

    • GH-497: backend: payable top and range query work

    • GH-497: receivable work too now, though certain niches are yet to be worked out

    • GH-497: top records and custom query mostly finished in the backend, some minor todos are still left out there"

    • GH-497: knocked out two more todos in the backend and also repaired masq console output from rowid to hash

    • GH-497: maybe last three todos, they were db errors in row queries; also little renaming and testing top records not using usize anymore but u16

    • GH-497: taking care of forced changes in integration tests

    • GH-497: documentation added; changed imperfections in rather marginal names and structures

    • GH-497: late fixes; mainly Clippy

    • GH-497: multinode tests repaired

    • GH-574: fix clippy warnings

    • GH-574: add more rpc urls for polygon mainnet

    • GH-497: lint for multinode tests

    • GH-497: defaults in rate pack adjusted; making help messages better; slight refactoring

    • GH-497: fixing new delinquencies for a corner case with a fully empty db

    • GH-497: verify bill payment a little fix in numeric orders

    • GH-497: some window dressing

    • GH-497: adding safe migration for rate_pack

    • GH-497: verify_bill_payments enriched by the 'financials' call

    • GH-497: fixing display tools to show just Gwei-pregnant accounts; payable fixed

    • GH-497: receivable gwei-wei custom query fixed; engine for this type of query enhanced; accountant mod tests modified accordingly

    • GH-497: backend fixed(Accountant/mod, dao_utils)

    • GH-497: financials command fixed to work in gwei - if demanded

    • GH-497: close to beating the monster; tests failing, errors left over but illustrative so they will lead me

    • GH-497: better treatment of decimal numbers

    • GH-497: refactoring - new macro added

    • GH-497: refactoring...better arrangement and readability

    • GH-497: urgent todos are gone

    • GH-497: shorthand args implemented

    • GH-497: savepoint before implementing regex

    • GH-497: temp and masq num params validation rock on, a few todos are left

    • GH-497: quite complicated checks and neatening of the users inputs for costum queries

    • GH-497: all existing tests in FinancialsCommand repaired

    • GH-497: financials command finished

    • GH-497: last sweeping in node and masq with allowence of Clippy

    • GH-497: fixing bad assumption with an overflow catch; this is moment before documentation check and then auto review

    • GH-497: I revised MASQ-UI-v2 docs and help output for the financials command, also enhanced one confusing log in accountant/

    • GH-497: state after auto review

    • GH-497: fix within

    • GH-497: I set up new possible configuration of arguments for the command; also begun implementing new format for displaying the output -- at least top records works in this regard.

    • GH-497: new formatting for financials command completed

    • GH-497: tuning the commands features; all tests except one passing

    • GH-497: help message and planning to eliminate complicated fn with using regex instead

    • GH-497-review-two: financialscommand tests are passing after refactoring a lot of code

    • GH-497-review-two: details, but savepoint before trying to collect strings first and compute widths out of them

    • GH-497: fair simplification; some duplications and repeated computation

    • GH-497: deleting unnecessary code and tests in the financials command

    • 497-review-two: ordering by balance and age is defined in the backend too...

    • GH-497-review-two: custom_query and all its possible suboptions thoroughly tested; code refactored

    • GH-497-review-two: custom_query and all its possible suboptions thoroughly tested

    • GH-497-review-two: starting minor refactoring to address individual, less important points from the first review, but just few are behind me

    • GH-497-review-two: code refactoring in blob utils

    • GH-497-review-two: a bit more refactoring + test on no rows returned

    • GH-497-TwoInt: I've got a first set of methods or dealing with two integers

    • GH-497-TwoInt: db migration things finished

    • GH-497-TwoInt: basic structure stands

    • GH-497-TwoInt: continuing designing the SQLParamsBuilder and the product

    • GH-497: TwoInt: insert part of upsert mostly implemented

    • GH-497-TwoInt: first successful pass on the variant of update with overflow

    • GH-497-TwoInt: deleting some commented out code left over from the previous version

    • GH-497-TwoInt: parametrizing tests and trying to cover or far mainly for plain updates

    • GH-497-TwoInt: big int processor completed and cleaned up

    • GH-497-TwoInt: started making tests of payable_dao running; added 'strict' kw assertions

    • GH-497-TwoInt: first success on top records with devided big int, yeahoo!

    • GH-497-TwoInt: payable tests checked and passing (except one, which to be removed maybe); refactoring of compute_financials()

    • GH-497-TwoInt: small refactoring in

    • GH-497-TwoInt: paid delinquencies repaired + some bringing tests back to life

    • GH-497-TwoInt: interim commit

    • GH-497-TwoInt: repaired more_money_received and some related stuff

    • GH-497-TwoInt: our own sqlite scalar functions added to decompose big intigers at speed

    • GH-497-TwoInt: added the complicated test for new sqlite fns hook up; cleaning some stuff from the i128 version in receivable dao

    • GH-497-TwoInt: reworking mig config into something with more general purpose - InitConfig; interim commit

    • GH-497-TwoInt: transformation from migrator config tu superior init_config is done; most of the process of hooking up sqlite functions as well

    • GH-497-TwoInt: all prepared for the start of fixing the new_delinquncies() functionality

    • GH-497-TwoInt: all about conn_special_setup thoroughly tested since now

    • GH-497-TwoInt: receivables finally also fixed, yahooo

    • GH-497-TwoInt: finishing at various places; awaiting work at big_int_db_processor...prepared

    • GH-497-TwoInt: all checks done in big_int_db_procesor

    • GH-497-TwoInt: tore out the mockable code being unnecessary

    • GH-497-TwoInt: Clippy + multinode tests clean-up...still a failing test there though

    • GH-497-TwoInt: added more entry checks for financials

    • GH-497-TwoInt: more refactoring in the financials command

    • GH-497-TwoInt: a bit more of refactoring for the financials command

    • GH-497-TwoInt: FinancilsCommand response reworked to return a common set of records for both modes, now on the masq side

    • GH-497-TwoInt: the backend side also taken care of

    • GH-497-TwoInt: continuing refactoring and hardening--but hit a perplexing issue; want to look at previous commits

    • GH-497-TwoInt: finally fixed last problems and cleaned up after me

    • GH-497-TwoInt: added integration test for the financials command

    • GH-497-TwoInt: multinode test adjustment, changes in documentation

    • GH-497-TwoInt: auto review

    • GH-497-TwoInt: tests for CLI failing for colors in terminal fixed

    • GH-497: sort- exchanged for better order-; changes in wording in docs

    • GH-497-TwoInt: an anused import in multinodes

    • GH-497-from-sec-review: first portion of repairs

    • GH-497-from-sec-review: savepoint before big change...trying to unify column formatted writting of accounts and headings

    • GH-497-from-sec-review: simplification with one function covering all types of pretty printed lines

    • GH-497-from-sec-review: another portion of minor fixes for FinancialsCommand

    • GH-497-from-sec-review: rearranging by meaning group

    • GH-497-from-sec-review: fixing financials command

    • GH-497-from-sec-review: another small portion of fixes, still operating in financials command

    • GH-497-from-second-review: after partial refactoring in big_int_db_processor

    • GH-497-from-second-review: still fixes in big_int_db_processor

    • GH-497-from-second-review: some more stuff, but at the end moment when deciding if BigIntDivider should return Result (I cannot make my mind up now)

    • GH-497-from-second-review: finally progressed on better arragement of tests in the damn challenging file

    • GH-497-from-second-review: save point when I realized that relative subtracting at the overflow section won't work this way, I need to specify absolute values

    • GH-497-from-second-review: main functionality in big_int_db_processor repaired and new tests written; will have to fix some more things though

    • GH-497-from-second-review: more tests running fine; one remaining actually - but I kind of hit the wall here, will see

    • GH-497-from-second-review: some more improvement, also still following the suggestions

    • GH-497-from-second-review: another big portion of repaired things

    • GH-497-from-second-review: more fixes, this time Accountant... a lot about PaymentThresholds

    • GH-497-from-second-review: fixed last issues...waiting for another portion from the ongoing review

    • GH-497-from-second-review: a fex mixed issue corrections and whole payable_dao fixed

    • GH-497-from-second-review: all remaining fixes of the recent batch; gonna wait up more of it

    • GH-497-from-sec-review: minor fixes...which tried my will in a day that all just sucked

    • GH-497-from-sec-review: various fixes: some of those found in db_mig, and rest...; refactoring in persistent configuration

    • GH-497: finished enhancement of the design of Migration configuration etc.; going to attempt to remove the unnecessary create_if_necessary flag

    • GH-497-from-second-review: the rest of issues taken care of; stuff around db a lot

    • GH-497-from-second-review: this is the commit; I didn't add in all the code, now I do-- the rest of issues taken care of; stuff around db a lot

    • GH-497-from-second-review: corrections, all good now, upcoming merge of master

    • GH-497-from-third-review: first portion of fixes

    • GH-497-from-third-review: another small portion of fixes

    • GH-497-from-third-review: another fixes: this time big_int_processor...update with overflow tests

    • GH-497-from-third-review: half work done regarding elimination of the heavy floating numbers usage; changing it to use big integers for the slope parameter instead; next will have to fix our defined SQL functions

    • GH-497-from-third-review: fixed the slope to be computed as integer, avoiding more expensive translations to f64

    • GH-497-from-third-review: few more testing user defined sql functions, big_int_db_processor interface and testing user values range limits

    • GH-497-from-third-review: nearing the finish line...before the rework of payable_exceeded_threshold

    • GH-497-from-third-review: payable_exceeded_threshold got proper test coverage; late but better than never

    • GH-497-from-third-review: refactoring macros and arranging less important functions for financials into a smart module

    • GH-497-from-third-review: formatting

    • GH-497-from-third-review: last changes; clean run

    • GH-497-from-fourth-review: fixing the interpretting proces about gwei into MASQ operation; added total supply constant and wrote an integ test to fasten it to the true contract; other optimizations in financials in UI

    • GH-497-from-fourth-review: corrected Wei to wei and Gwei to gwei

    • GH-497-from-fourth-review: a few more fixes from the review

    • GH-497-from-fourth-review: last changes as response to the found issues

    • GH-497-from-fourth-review: formatting

    • GH-497-from-fourth-review: previous review fully answered

    • GH-497-from-fifth-review: previous review fully answered

    • GH-497: elevating the code version to 0.7.0

    • GH-497-from-fifth-rev: last editor work of the text

    • GH-497-sixth-review: fixes from previous reviews

    • GH-497: version bump

    • GH-497-seventh-review: financials command arranged better into separate files

    • GH-497-seventh-review: rearrangement for big int utils in accountant/mod

    • GH-497-seventh-review: clippy and fixing an integration test in masq

    • GH-497-seventh-review: juss a few details after the review

    • v0.7.0_GH-497: last fiddling...passing locally

    Co-authored-by: Bert [email protected] Co-authored-by: utkarshg6 [email protected]

    opened by FinsaasGH 0
  • GH-600: Add get_block_number

    GH-600: Add get_block_number

    • Introduce the ability to get the current block number of a chain.
    • Utilize batch transport to request block number and transaction logs within the same blockchain service provider API batch request.
    • Incrementally scan the blockchain for payments and use the upper block number bound as required.
    • Handle block number range errors reported by blockchain service providers to allow recovery and catch up to the current block if the node falls behind.
    opened by masqrauder 0
  • GH-633 (adolescent): Optimise routing to reduce DNS resolution 'mark'

    GH-633 (adolescent): Optimise routing to reduce DNS resolution 'mark'

    This PR is a child of original PR GH-633 except it excludes the multinode test. The multinode test will get integrated to master under a different card.

    opened by utkarshg6 0
  • v0.6.3(Dec 16, 2022)

    What's Changed

    • Workflow changes by @FinsaasGH in
    • fix: updated workflows with correct syntax and os-specific paths by @FinsaasGH in
    • Rust version hotfix by @FinsaasGH in
    • fix: updated s3-release workflow with a matrix execution by @FinsaasGH in
    • GH-631: Gossip Storm Avoidance by @utkarshg6 in
    • Change version from 0.6.2 to 0.6.3 by @utkarshg6 in

    Full Changelog:

    Source code(tar.gz)
    Source code(zip) MB) MB) MB)
  • v0.6.2(Sep 5, 2022)

    What's Changed

    • GH-627: Some care to the scrupulous Clippy by @bertllll in
    • GH-625: Log message enhancements, plus clippy appeasement by @dnwiebe in
    • GH-574: Overall Connection Status of a Node with the MASQ Network by @utkarshg6 in
    • GH 624 - Simplify ConfigDao to reduce or eliminate SQLITE_BLOCKED errors by @dnwiebe in
    • GH-613: cutting back on too many report consume messages jamming Accountant...version 2 with a fix by @bertllll in

    Full Changelog:

    Source code(tar.gz)
    Source code(zip) MB) MB) MB)
  • v0.6.1(Aug 23, 2022)

    What's Changed

    • GH-597: correct AutomapProtocol db storage by @bertllll in
    • 588 Removing big logfile errors and (hopefully) UiGateway crashes by @dnwiebe in
    • GH 526 Multinode Test by @dnwiebe in
    • 617 Optimize Routing Engine by @dnwiebe in
    • FINAL 617 optimize router w/ Version bumps by @kauri-hero in

    Full Changelog:

    Source code(tar.gz)
    Source code(zip) MB) MB) MB)
  • v0.6.0(May 24, 2022)

    What's Changed

    • Gh 396 - Remove gas price upper limit by @dnwiebe in
    • Gh-386: formerly panics at double-used "shutdown" ; ended with broad redesign of some structures in masq by @bertllll in
    • GH-244: Live Database Version Migration + adding one row for Automap by @bertllll in
    • GH-379: 'go' in the Node hangs and a Clap's error message's doubled + and then, more than cosmetic reconstruction of the foundation of MASQNode modes by @bertllll in
    • GH-449: Removal of BroadcastTrigger by @bertllll in
    • GH-446: Replaced mpsc with crossbeam_channel by @FinsaasGH in
    • Gh-451: signal handling for linefeed + solving broadcast thread speaking from beyond grave when masq's terminating by @bertllll in
    • Delete by @kauri-hero in
    • GH-401: Make database picky about chain by @bertllll in
    • Gh 382 - README updates by @dnwiebe in
    • GH-457: Remove dead parameter processing by @FinsaasGH in
    • GH-414: Change default mnemonic phrase to 12 by @FinsaasGH in
    • GH-418: Update copyright tags by @FinsaasGH in
    • GH-500: Accept the proposal of enhanced logging and safer sending http requests to the blockchain service by @bertllll in
    • GH-473: New system of employing chains, internally (for developers) and externally (for users), not only for the expansion to L2 networks by @bertllll in
    • GH-305: Partial panic and actors hold together until one crashes and then all of them. by @bertllll in
    • Gh-478: Addition of config values written to database + updating db initialization and migration + better tooling in ntegration tests for Node by @bertllll in
    • GH-525: Update rust to 1.57.0 and modify clippy related code by @FinsaasGH in
    • GH-503: reengineeiring blockchain transacting to work for all chains by @bertllll in
    • GH-496: Updated dependencies to latest available by @FinsaasGH in
    • GH-492: Update accountant to not use futures in scanning for payables/receivables by @FinsaasGH in
    • GH-372: Automap by @dnwiebe in
    • zero-hop-hotfix: making past-neighbors configurable specially for zer… by @bertllll in
    • Gh 477 - Store consuming wallet private key in database by @dnwiebe in
    • GH-563: HOT-FIX - update Mumbai test token contract by @utkarshg6 in
    • GH-523: pending payment confirmation or cancellation by @bertllll in
    • GH-571: db-password ineffectively distributed to the componnents needing it by @bertllll in
    • GH-569: Write Tests for Constants by @utkarshg6 in
    • GH-485: adding advanced configurable parameters by @bertllll in
    • GH-236: financials by @bertllll in
    • GH-537: Corrected usage of serde::__private by @FinsaasGH in
    • GH-595: better design of NotifyLaterHandle and NotifyHandle by @bertllll in
    • Finsaas gh cimatrix by @FinsaasGH in
    • feat: update ci-matrix.yml and s3-release.yml to new pipeline by @FinsaasGH in
    • GH-349: broadcasting to UIs about events through logs by @bertllll in
    • DRAFT: Update docs/branch by @kauri-hero in
    • GH 526 Stop Crediting Debtors Multiple Times by @dnwiebe in
    • Docs/contributing plus cleanup by @FinsaasGH in

    New Contributors

    • @dnwiebe made their first contribution in
    • @FinsaasGH made their first contribution in

    Full Changelog:

    Source code(tar.gz)
    Source code(zip)
MASQ Network
MASQ Node software provides a decentralized mesh-network of nodes for global users to access normal internet content - next evolution of tech beyond Tor & VPN
MASQ Network
Cover is an open internet service for canister code verification on the Internet Computer

Cover Cover (short for Code Verification) is an open internet service that helps verify the code of canisters on the Internet Computer. Visit our webs

Psychedelic 14 Oct 31, 2022
Privaxy Next generation tracker and advertisement blocker

Privaxy is a MITM HTTP(s) proxy that sits in between HTTP(s) talking applications, such as a web browser and HTTP servers, such as those serving websites.

Pierre Barre 752 Jan 7, 2023
Simple VPN implemented using rust

fubuki Simple VPN implemented using rust fubuki是类似与tincVPN的简单组网工具 不支持对等NAT 支持的平台: Windows Linux 工作机制 它由一台拥有公网IP的服务器来维持各个内网客户端的实际地址映射,在客户端和客户端之间实现P2P通信

XTY 84 Dec 31, 2022
A WireGuard UWP VPN plugin.

WireGuard UWP A Universal Windows Platform (UWP) VPN Plug-in for WireGuard® written in Rust. Windows provides a plug-in based model for adding 3rd-par

Luqman Aden 92 Dec 13, 2022
A super naive, (possibly unreliable), VPN implementation.

Poor Man's VPN A super naive, (possibly unreliable), VPN implementation. Try on Docker Containers You can test the VPN on docker containers. scr

algon 2 Sep 7, 2022
Final Project for "Computer Networking Security": A Layer-3 VPN implementation over TLS

Final Project for "Computer Networking Security": A Layer-3 VPN implementation over TLS

Siger Yang 2 Jun 7, 2022
A virtual network tool (or VPN)

switch A virtual network tool (VPN) 将不同网络下的多个设备虚拟到一个局域网下 示例: 在一台mac设备上运行,获取到ip 在另一台windows上运行,获取到ip 此时这两个设备之间就能用ip相互访问了 输入"list"

null 49 Jan 21, 2023
Rosenpass is a formally verified, post-quantum secure VPN that uses WireGuard to transport the actual data.

Rosenpass README This repository contains A description of the Rosenpass protocol The reference implementation of the protocol – the rosenpass tool A

Rosenpass 597 Mar 19, 2023
A rust-based command line tool to serve as a gateway for a Internet Computer replica.

icx-proxy A command line tool to serve as a gateway for a Internet Computer replica. Contributing Please follow the guidelines in the

DFINITY 25 Sep 6, 2022
Simple DHCP client for the Wiznet W5500 internet offload chip.

w5500-dhcp Simple DHCP client for the Wiznet W5500 SPI internet offload chip. Warning Please proceed with caution, and review the code before use in a

Alex 0 Mar 20, 2022
An online version of the popular game four in a row, written in Rust on the server side and Flutter + Dart on the client.

Four in a Row - Server An online version of the popular game four in a row, written in Rust on the server side and Flutter + Dart on the client. Downl

Filippo Orrù 8 Sep 16, 2022
The true next-gen L7 minecraft proxy and load balancer. Built in Rust.

Lure The true next-gen L7 minecraft proxy and load balancer. Built in Rust, Tokio and Valence. Why? Rust is a powerful programming language and a grea

Sammwy 67 Apr 16, 2023
A skyline mod that enables manual choosing of desired input latency in Smash Ultimate, compatible with every online mode.

Latency Slider (Definitive Edition) This is a fork of - and an improvement upon - the original "Arena Latency Slider". Unfortunately, upon SSBU updati

null 8 Mar 5, 2024
Cloud Native high performance security and privacy SQL proxy.

Fern proxy With the advent of Cloud Native applications, architecture patterns evolved and emerged to take advantage of cloud computing, and build mor

Fern 12 Nov 7, 2022
Private swaps for Secret Network using a private entropy pool & differential privacy.

WIP SecretSwap: Anon Edition Private swaps for Secret Network! Uses private entropy pool for differential privacy when reporting pools sizes. Swap amo

SCRT Labs 5 Apr 5, 2022
An End-to-End Privacy Computing Protocol on Layer 2

Eigen Network Eigen Network is an end-to-end privacy computation network for a better digital economy based on hybrid privacy computation protocols an

Eigen Lab 24 Oct 13, 2022
Shade Protocol is an array of connected privacy-preserving dApps built on Secret Network

Shade Protocol Core Contracts Contract Reference Description mint doc Handles asset burning and silk minting oracle doc Handles asset price queries tr

Secure Secrets 58 Nov 15, 2022
The best open source remote desktop software

The best open-source remote desktop software, written in Rust. Works out of the box, no configuration required. Great alternative to TeamViewer and AnyDesk! You have full control of your data, with no concerns about security. You can use our rendezvous/relay server, set up your own, or write your own rendezvous/relay server.

RustDesk 35.4k Jan 4, 2023
IDP2P is a peer-to-peer identity protocol which enables a controller to create, manage and share its own proofs as well as did documents

IDP2P Experimental, inspired by ipfs, did:peer and keri Background See also (related topics): Decentralized Identifiers (DIDs) Verifiable Credentials

null 5 Oct 31, 2022