csw [2:42 AM]
Not test the model, test the system against the model

zbingledack [2:45 AM]
Still thinking. The block race as a Poisson process is very strange to start with. I don't think I have _fully_ wrapped my head around even the basic design, let alone additional issues. We don't even ever really know a miner's hashpower except for statistics over a given time interval.

[2:47]
I am one who likes to solidify the basics to ridiculous degree before moving to advanced topics. So I will be slow to get these higher-level arguments.

csw [2:50 AM]
Yes.

[2:52]
Assuming the uniform distribution as is done in independent events...

[2:53]
What is probability of one poisson process occuring after another given that the first occured?

[2:55]
What is the probability of the HM discovering 30 seconds after the SM?
What is the probability that the SM will have a block mined given that they have seen the HM release a block?

[2:55]
These ARE missing parts of the model.

[2:59]
@zbingledack
Let us start now with the FIRST block event.

A SM finds a block. They Hide it.
If they release, they have a reward of 1 (close to 100% chance)

If they hide it, they have 0 reward but a later possibility.

Chances are (and I will go over the distributions after) that the HM will find a block before the SM gets a second (I will cover this later).

So, they have 100% getting paid as an HM or a CHANCE to risk it. What is the Probability that the SM will lose when the HM discovers a competing block?

[3:00]
P(SS | Not.H) vs P(S|H) = reward.
P(H|S) = they lose....

[3:02]
@zbingledack
Without needing to go into the actual distributions....

Starting to see why this is a conditional probability calculation...

[3:05]
I am not running the SM state system, I am running Bitcoin. Who cares what SMCoin does...
If you miss the conditionals in the probability calculations you have a value greater than the base and an error.

mwilcox [3:57 AM]
hmm - surely not 100% as HM if SMs have chance to overtake?

csw [4:36 AM]
SM is slower - always under 50% remember

[4:40]
It is not the chance of finding a block, it is for the HM a chance to find a block after the SM has found one...

joeldalais [4:47 AM]
the sm only has a chance to overtake if they're competing vs another sm

csw [4:57 AM]
And did anyone model 2 or more SMs?

joeldalais [5:00 AM]
for some reason this popped into my head - https://en.wikipedia.org/wiki/Go_(game) :slightly_smiling_face: (edited)

karasako [6:41 AM]
joined selfish-mining by invitation from @klee. Also, @phoenix joined, @linzheming joined.


----- Yesterday May 18th, 2017 -----
phoenix [6:28 AM]
thanks man
 4 replies Last reply about 20 hours ago View thread

frankross [6:29 AM]
joined selfish-mining by invitation from @zillionaire, along with @xspdr. Also, @dgenr8 joined, @vatten joined, @hostfat joined, @jonald_fyookball joined.


----- Today May 19th, 2017 -----
csw [2:29 AM]
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?

[2:29]
So, here is a REAL experiment

[2:29]
Run up 100 virtual machines

csw [2:38 AM]
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:
1. 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.

2. Create a mining pool. This is the SM test.
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.

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

[2:38]
Next, configure the pool for SM

csw [2:45 AM]
Have the pool act through a single head.
Configure the system to only release when it sees another miner release.

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.

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.

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

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.

[2:46]
https://www.nrl.navy.mil/itd/ncs/products/core

[2:47]
Just to be a dick, my CORE configuration is constructed with up to 100,000 nodes and 5,000 routers. It has the mappings for the global BGP tables and all the real world link data...

But as I said, for the purposes of this exercise, we just need a simple LAN with 100 small VMs

[2:48]
Configuring the pool can be achieved in many ways.

csw [2:54 AM]
You can change the code and have the code react differently, but there are simpler methods if this is too difficult.

Run an IPTables instance.
Run Snort or some other packet sniffing IDS/IPS.

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

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....

If we see a block on the A network, we respond using the IDS rules as we would for the SM paper. There are various thresholds. 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. (edited)

[2:55]
I can help with TCPDump and Snort. I used to teach the use of these products, they are both free

new messages
[2:57]
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.

[2:59]
These thresholds CAN be as granular as to have a rule such as:

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

[3:00]
If (Block-Height-A) = (Block-Height-B +1) Do xxx
If (Block-Height-A) >= (Block-Height-B +2) Do xxx