Hi guys,
I went through the forum posts and I like this project. I made the soil source code Homestead ready with all the benefit. Just for me to learn. If you are interest in my work let me know.
https://github.com/martymcfly2015/go-soilI'm happy to build binarys for you to test. Just let me know.
I accept donations soil 0xc7a8ac69835d74a7bd039ece1fc71f7cd9ea64f4
Thanks
Good job, finally there is some progress!
But doesn't it make more sense to wait until the ETH hard fork which takes place in some days and implement the changes of that?
Also, implementing Exponentially Subjective Scoring as suggested by Vitalik in order to prevent attacks upon low-hashrate ETH forks might be a very well thing to implement, like the Jumbucks developer does:
Exponentially Subjective Scoring & Entering the final phases for LaunchSo here's something I alluded to in a previous post. I wanted to take a look at eliminating the possibility of a long range re-org attack on the chain as this has been observed in other Ethereum forks. Ultimately the best security for proof of work is having "sufficient" hash rate such that such an attack reaches the point of "not being feasible." The first idea I had for this was setting a limit on re-org depth, say 1 day. This solution on the surface seemed simple.. a little too simple so I sent Vitalik an email to see if he had any thoughts.
Here is Vitalik's reply:
The problem with limiting reorg depth to 1 day is that there's an attack vector where someone does a 51% attack that some nodes will see as being 1 day - 1 second and some nodes will see as being 1 day + 1 second, leading to a permanent split. One approach that could work is what I call "exponentially subjective scoring", which is defined as follows:
* Suppose that you are on a chain with score S1 (score = total difficulty). Suppose that there appears a new longer chain.
* Compute the "common ancestor" of the two chains; say that this ancestor has a score of S_a.
* Switch to the new chain only if (S2 - S_a) / (S1 - S_a) > 1.0001 ** (number of seconds between when S1 was received and when S2 was received)
The intention here is that you have a scoring mechanism which prevents long reorgs, as a reorg from one day ago would be penalized by a factor of 5650, but at the same time is friendly to timing discrepancies between nodes as if two nodes saw some block even one minute away then the chains would need to be almost exactly the same length for nodes to disagree as to the correct head of the chain.
I'd actually be quite excited to see this kind of mechanism tried out in a chain.
Exponentially Subjective Scoring is also further mentioned in this article that Vitalik wrote November 2014 -
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/I'm pleased to say that I have coded this up and it works great. Here are some log lines which demonstrate this. ESS is basically another check which decides whether or not a re-org should take place.
