Test of fluffyblocks via monero mainnet sub-network

20170625 - New Experiment to test stability - see below in participate header section. no more exhaustive exclusive node lists. Binaries updated 20170625 - new bins and updated branches. Binaries deny regular nodes and modifed restricted RPC behavior

Binaries updated 20170604 - new bins and branch that deny regular nodes from poisoining our subnetwork

Bug found. Patched by moneromooo. Binaries updated 20170601 10:00 PM US Eastern


What is fluffyblocks

TL;DR: bandwidth reduction for Monero network


Its compact blocks. Basically, in all cryptocurrency networks, the transactions are broadcast and relayed. Then, when a block gets solved, the block gets relayed with all the transactions - even though all of the nodes probably have all of the transactions because they were relayed throughout the network
So what fluffyblocks does is transmit a fluffyblock - basically, a block with an index of which transactions should be in it. When a fblock arrives at a node, the node sees if it has everything from the index, and then adds it to rebuild the block. Its like an fblock is an instruction set. If the node doesn't have all of the transactions, it asks its peers for transactions.
This ultimately results in a decrease in bandwidth used by nodes... almost a cut by half. And in Monero, this is great because our transactions, and therefore blocks, are gonna get huuuuuge

Right now, this is live on testnet, but testnet sucks for testing this because there's 1.) no nodes on testnet and 2) no transactions being broadcast.

In fact, this has been sitting in a "we should test this" state forever, because if it goes live on mainnnet, and its broken, then mainnet is broken - because block relay is sort of what makes a blockchain happen.

The Subnetwork


So, i have node A connected to main net. Node B is connected to node A only.
Node A is running the standard release. Node B is running release with 1 line modified to enable fluffyblocks.
So I figured it will work like this. Will have the main bridge node 104.168.99.235:18090

A bunch of people will connect to that via add-exclusive-node. So that will be tier 1.

Then I'll publish that list of IPs. The tier one nodes can then modify their conf files to add more exlcusive nodes, to create a mesh in teir 1.
And then new people joining can then connect directly to one of them, to create tier 2.
Eventually, at tier 3, I'll setup a block explorer so we can monitor how blocks and transactions propagate through the subnetwork

Check out this stats file for fluffynet stats

Explorer is up here

We have a friggin mining pool on the subnet thanks to another community member!

See available logs from my probe node crashes. If you have any core dumps, please send to me (somehow)

We found a bug! Moneromooo patched it here.

We mined some blocks! Thanks all who participated

This doesn't mean the experiment is over. We gotta see how stable things are! This takes time!

How to participate

If you participate, the IP addresses of your nodes will be made public on this page so others can connect.

NEW EXPERIMENT - Please run the even node bin if your IP has an even last digit, and the odd binary if your IP has an odd last digit

NOTE - all binaries have a modified restricted-rpc behavior, so PLEASE open up your ports and feel free to use the restricted-rpc flag! Your node is protected, but I can get all the info needed now

Linux Binaries

################ NEW LINUX BINARIES
For even nodes Contains a threading patch fix that might be important
For odd nodes Doesn't contain the fix, for confirmation
#####################

Compiling instructions

I finally made a fork & branch on github.
git clone https://github.com/Gingeropolous/monero.git
git checkout vJ4-fluff-head-even
CFLAGS="-fsanitize=thread -g -pthread" CXXFLAGS=$CFLAGS make debug-static
For odd nodes
git clone https://github.com/Gingeropolous/monero.git
git checkout vJ4-fluff-head-odd2
CFLAGS="-fsanitize=thread -g -pthread" CXXFLAGS=$CFLAGS make debug-static

Other binaries and solutions

Tier Configuration Instructions

Once you have that, check the tiers to see where a new node is needed. use the example conf files for the specific tiers, but I highly recommend making a custom log file by checkout of the instructions at the bottom of this page.

NOTE: Use logrotate to keep your system happy. reminder - monerod does its own log rotation in 100 MB files that have timestamps. This can screw up your logrotate script!!


Now, go ahead and block the standard p2p ports via firewall and open up the p2p port for whatever tier you are on. We want to keep regular main net nodes out of the subnet.
It would also be great for you to open your RPC ports, but you don't have to. It produces some level of exposure, especially without restricted-rpc... if you know enough to care, do what you will

sudo ufw deny 18080
sudo ufw allow 18090
sudo ufw allow 18091
If you are in tier 2
sudo ufw allow 18092
sudo ufw allow 18093
etc etc for the other tiers

then start the daemon with the config file. You need the full path for the config file for your tier!!!! Or you can use flags like below
./monerod --config-file /absolute/path/to/tier*.conf


You can either just use your node normally, or open up your RPC ports so we can monitor and connect to each other and stuff

Tier config example for tier 1

--add-exclusive-node 104.168.99.235:18090 --p2p-bind-port 18090 --rpc-bind-port 18091 --rpc-bind-ip 0.0.0.0 --confirm-external-bind --log-level=1,net.p2p.msg:INFO --restricted-rpc
NOTE!!! Each tier has its own add-exclusive-node - these are the probe nodes as listed below
Hopefully someone will make a monitoring thing. Thats why the RPC ports are open.

Super fancy participation

Set up a cron job to download a copy of the .conf file from moneroworld.com every 5 hours or so. This way I can kinda remote control your node if anything needs changing. Or you can just keep checking back here to see if anything has changed, although I'm not really timestamping anything... so....

Tier 1 nodes

tier1.conf

Tier 1 info
Main bridge node for reference 104.168.99.235:18090

Tier 2 nodes

tier2.conf

Tier 3 Nodes

tier3.conf

Tier 4 Nodes

tier4.conf

HOW TO MANUALLY ADJUST YOUR CONFIG FILE

You can check out my recommendations above, but in reality, what you want to do is check out this list. If you see that tier 1 is loaded, then make your node a tier 2 node. We are aiming for 5 - 10 peers in each tier. To make your node a tier 2 node, just use the tier2 probe node in your exclusive node setting.

Probe Nodes

Tier 1: This is the bridge node. At this point you shouldn't add this to your exclusive-node list 104.168.99.235:18090
Tier 2: 99.150.228.240:18092
Tier 3: 99.150.228.240:18094
Tier 4: 99.150.228.240:18096