Mwixnet community TEST

Community testing is crucial to preserving open-source software’s dependability, security, and quality. It fosters a cooperative atmosphere where users and developers may contribute to ongoing progress in addition to aiding in the early identification of problems.
In the end, this results in a Grin blockchain that is more secure, resilient, and reliable.
Grin is an open-source, decentralized blockchain run by a grassroots community, thus gather around to test ツ !
We welcome any and all contributions!

‘‘We’d like to see people from the community focus on getting a mwixnet up, think that would be more useful to the core experience.’’

Mwixnet Testing

Also for help and feedback contact keybase

3 Likes

For those on Debian/Ubuntu the required packages are:

pkg-config
libssl-dev
curl

You will also need to run the following:

sudo apt autoremove rustc
curl --proto ‘=https’ --tlsv1.2 -sSf https://sh.rustup.rs | sh
. “$HOME/.cargo/env”

This will update Rust past V1. 63

And to make things easier once compiled:

sudo install ~/mwixnet/target/release/mwixnet /usr/local/bin/

4 Likes

Sorry for noob questions, what is the ‘right’ procedure to test? What is the expected result that it should be? how to know if something goes wrong?.. etc

(on Linux) You just download and compile, then run mwixnet init-config, grin-wallet owner_api, and finally mwixnet and it’ll tell you it’s starting mwixnet.

I was able to get it running pretty easily on the 2 public Grinminer.net testnet nodes.

The post compilation instructions can be found at GitHub - mimblewimble/mwixnet: Implementation of the Mimblewimble CoinSwap proposal..

And check my posts above if running on Linux for tips.

1 Like

I wrote an Ansible playbook for automated deploying of node+wallet+mwixnet hosts on Debian/Ubuntu. Before running make sure there are no new releases on Github & replace [sha-512 hash] with the desired password for the ‘grin’ user, then set your [target]. Once it’s run mwixnet is compiled and ready to run once you’ve set up the TOML configuration files of each.

I highly recommend using screen (for console detaching) & tmux (for console viewing) to run both wallet listeners + node + mwixnet.

2 Likes

I can work on getting it installed, but I have this same question. it’s still not clear to me what testing looks like. Can we make transactions? What is success. What is failure?

Mwixnet is an automatic coinswap so there are no transactions to make. We just need more nodes running so testing at meaningful scale with mining attacks and other tests can occur.

This is what success looks like:
Screenshot from 2024-12-12 23-00-43

My understanding from the posts on Mwixnet is that a specific loop of Mwixnodes will be defined of which only one has to be honest for us to mathematically know that the mix is valid (not quite trust-less but pretty close). However, doesn’t that mean that when I send coins to a Mwixnet, I need to agree to a specific sequence of Mwixnodes?

I will get a mix node running all the same… just trying to understand it better.

1 Like

hello, I would like to run a mwixnet node but my fear is it will be found to be criminal like tornadoe cash. what assurance can you give that it will not be traceable?

3 Likes

For testing its not relevant, test Grin has no value.
Not sure if it is possible to run a mwixnode via tor, for now we need to test basic functionality.

The case of Tornado cash is profoundly disturbing. If I am not mistaken, Pertsev did earn fees with theTornado cash smart contract, mwixnodes do not earn a mixing fee but they can be said to “facilitate” the process of decentralised anonimization of transactions. Also, mwixnets are part of a network, it can be argued that no single node holds responsibility since if only one node is true and honest, the output linkability could not be determined even if all others are not honest. Still, for now I would not advice running a mwixnode on mainnet if you do not trust the regulators in your country from overstepping. As the Tornado cash example shows, the right rugalations and boundaries for regulators not to overstep are not yet in place.

3 Likes

Ok thank you for the time. I will run a grin regular node now and revisit mwixnet in the future time.

They do. Quoting from https://forum.grin.mw/t/mimblewimble-coinswap-proposal :

The contributed fees should then match the coinswap relay fee plus n mixfees. In Grin this gives the identity (with FB being the fee base of half a millicent):

|Out| * fee = (|Out| + n) * (1 + 21) * FB + n * 3 * FB + n * mixfee, or
mixfee = |Out| * (fee - 22 * FB) / n - 25 * FB.

For simplicity, we could require a fee of (22 + n) * FB, resulting in a mixfee of (|Out| - 25) * FB. In that case, for a mixnode to earn 10 grin-cents a day requires 225 daily self spends.

1 Like

Thx, I learned something new today. Do I understand correctly one cannot forfeit this mixing fees since its inherent to the mixing process?

I also pondered the Tornado cash and running a mwixnote. I am not feeling confident that regulators will not overstep in the country where I live, especially if I would be receiving an economic insentive.

2 Likes

Mixfees are not seen by the users; they just pay their regular fees required for self-spends. Rather, mixfees are something left over from the combined user fees since the aggregation saves on kernel fees. So the mixnodes have to take the mixfees to balance the equation.

3 Likes

Wow, that is a very ellegant way to share fees/insentives. Nice to understand MWixnet a bit better💛

I have successfully set up mwixnet. Are there any special tests or tools I can use?

1 Like

I have rebuilt the Docker-Compose example so that:

  1. Dockerfile node adapted so that the current version 5.3.3 is used as the node

  2. Dockerfile Wallet
    Conversion to current git master status.
    I have also installed nginx in the Docker image.
    #nginx reverse proxy from outside => 0.0.0.0:13416 nginx => 127.0.0.1:13415
    This means that the wallet can also be addressed in a container for the master.
    Why is localhost/127.0.0.1 always static here?

I switched to the master because I noticed that the master has the new API endpoint (owner) create_mwixnet_req.

  1. mwixnet-first-run-script.sh
    I have also passed 0.0.0.0:3000 for the execution of the mwixnet as binding
    RUST_BACKTRACE=full mwixnet --testnet --wallet_pass=$WALLET_PASSWORD --bind_addr="0.0.0.0:3000”

  2. mwixnet/test/docker-compose
    Adaptation of the wallet port 13416

Now my nodes (main&test), the wallet with owner&foreign api and the mwixnet are running. The endpoint mentioned above (create_mwixnet_req) returns a SWAPReq object after an init_secure_api:

Parameter

  • server_keys The public keys of the servers participating in the mixnet (each encoded internally as a SecretKey)
  • fee_per_hop The fee to be paid to each server for each hop in the mixnet
  • commitment The commitment of the output to be mixed
  • lock_output Whether to lock the referenced output after creating the request

Example:
Map params = {
‘token’: _token,
‘commitment’:
“0873492adc10c74af23bc6ee7ebab3fec0ce39379b22f39e4b30106dac62bf1e20”,
‘fee_per_hop’: “5000”,
‘lock_output’: true,
‘server_keys’: [
“89cd052dd2ef096bb197ad95d8c9bb47327c7151a3381c8da8ea053c1138221a”
]
};

dynamic resp = await postEncrypted('create_mwixnet_req', params);

Example response:
cosmig + onion,

The response can be used to trigger the mwixnet SwapApi accordingly?
Example see:

I have a small web tool with which I process the secure-api. There’s probably not much left to test the mwixnet!
Currently I still get the following incorrect response:
{
“jsonrpc": ‘2.0’,
“error": {
“code": -32602,
“message": ”Failed to peel onion layer: DeserializationError(UnsupportedProtocolVersion)”
},
“id": 1
}

Can anyone help me here?

ideas:

  1. Deployment of the containers in a Docker registry?
  2. Is it possible to create a branch of the grin-docker repo?
  3. A tool should be developed with which the mwixnet api can be probed, or can the grin-gui already do this?
2 Likes

I create an issue:

2 Likes