Selfish Mining debate - how to test it - funded research opportunity!

Here is a thing to start you thinking. The Selfish Mining paper is not science. It is a theory, a quantifiable testable theory. One that can be validated.Now, here is the secure with experimental tests. This is what we see wrong all the time in the world today. You test the model AGAINST the real world. You DO NOT just run a simulation of the model and confirm the numbers from the untested model. Do we all understand this distinction?

So, here is a REAL experiment:

1. Run up 100 virtual machines

2. Have each of them independent and on a LAN so that there are no delay assumptions (as the paper states)Set two classes of machines:

   a) General miners that represent the HM system. These are unmanaged and not connected as a pool. These just run.
   This group is the base test and we can run a control at 100% this way to ensure that the system is correctly configured.

   b) Create a mining pool. This is the SM test.

   c) We can start with 30 of the 70 hosts in the pool and work up to 50 of the 100. See how the percentages are nice and simple to calculate. I know few people have done PhD level Maths (as I did do). Set a value such as 40 SM hosts and 60 remaining as the first one tested to get the flavor of whether this is working and you need to model all 20 runs. Do the test with the pool running normally first. This is the control test and it will be a standard mining return if the system is correctly configured.

   d) Again, remember to Run the pool system as a control first.

3. Next, configure the pool for SM.

4. Have the pool act through a single head.

5. Configure the system to only release when it sees another miner release.

   a) The easy way to do this is to have two LAN Sections. VMWare and Xen both allow for the creation of switch and VLAN segments.

   b) One of the SM hosts is the "head", this will be a dual homed system. It talks to both SM and honest systems. All SM miners receive the Honest miner block from this "head" server. This server is the only one that needs to be altered. The others are all pool members. You can also run up pool mining software, but this is more difficult and does not change the results.

6. All the VMs need to be spec'd the same.

7. Do not think about the difficulty as this is not part of the live network.

I have a configuration in CORE (Common Open Research Emulator) from the US Navy.

Configuring the pool can be achieved in many ways. You can change the code and have the code react differently, but there are simpler methods if this is too difficult.

1. Run an IPTables instance.

2. Run Snort or some other packet sniffing IDS/IPS.

3. Create a rule. We will set two sides to the network. A - Honest, B - Selfish.

4. Setup a rule in the IDS to see and determine a Block. This is easy if you know how to script in Snort. Create a threshold rule. This is where you can specify event thresholds and make the state table response that is listed in the SM paper....

   a) If we see a block on the A network, we respond using the IDS rules as we would for the SM paper.
   b) There are various thresholds.
   c) All need to match the SM paper.

After creating these, you need to test them. I like TCPDump, but Wireshark is also good. When we know that the system works as it is purported to do, then and only then can we start the test. Please note, it is important to record the data for this stage as well as we need to have the data to validate the results!

On the B side, all blocks are sent to all systems and the "head" collects and responds. The IDS stops any block getting to the systems at the wrong time or leaving the "head" to the B group at the wrong time.

Note: you CAN create threshold rules in Snort that allow you to set conditions as granular as the block height from a Bitcoin block.

If (Block-Height-A) >= (Block-Height-B) Do xxx
If (Block-Height-A) < (Block-Height-B) Do xxx
If (Block-Height-A) = (Block-Height-B +1) Do xxx
If (Block-Height-A) >= (Block-Height-B +2) Do xxx