fix merge conflict

EIPS/eip-5883.md

@@ -78,25 +78,13 @@ $n_i^{t}$ is the last timestamp (where a reward was booked on that account) of n
 
 The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
 
-## Reference Implementation
-
-No reference implementation provided. We suggest to use as approximation for $tanh()$ a list of approximation values of tanh between -100 and 100.
-
-We suggest to use as approximation for $log()$ (base of 10):
-
-```solidity
-function log(uint256 z) public pure returns (uint256) {
-    if (z == 0) return 0;
-    return (z - 1) / (z + 1);
-}
-```
 
 ## Security Considerations
 
 
 1) We currently do not see any mechanism of preventing a user of getting a lot of rewards. Sure, a high reward is bound to a lot of investment but the person who wants to get that reward amount and has a enough money will reach it. The only thing which could be improved is that we somehow find a mechanism really identify users bound to an address. We thought about having a kind of a hashing mechanism which hashes a real world object which could be fuzzy (for sure!) and generates a hash out of it which is the same based on the fuzzy set.
 
-2) We implemented a threshold of the minimum amount of approvals which must be reached to make a social token transfer possible. Currently there is no experience which defines a "good" or "bad" threshold hence we tried to find a first value. This can or must be adjusted based on the experience the world has with such an proposal and implementation we are poposing here.
+2) We implemented a threshold which must be reached to make a social token transfer possible. Currently there is no experience which defines a "good" or "bad" threshold hence we tried to find a first value. This can or must be adjusted based on future experience.
 
 3) Another problem we see is that the network of the neighbours is not active anymore to reach the necessary minimum threshold. Which means that due to not being able to reach the minimum amount of approvals a user gets stuck with the e.g. social token transfer he/she wants to perform. Hence the contract lives from its usage and if it tends to be not used anymore it will get useless.