From 5e4e7747c447e4e88e7cdeebbb19c642b448560a Mon Sep 17 00:00:00 2001 From: wsdt Date: Sun, 6 Nov 2022 11:23:49 +0100 Subject: [PATCH 01/19] EIP - Social Recovery --- EIPS/eip-5807.md | 112 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 EIPS/eip-5807.md diff --git a/EIPS/eip-5807.md b/EIPS/eip-5807.md new file mode 100644 index 0000000000000..0e9edd670ebab --- /dev/null +++ b/EIPS/eip-5807.md @@ -0,0 +1,112 @@ +--- +eip: + +title: Token Transfer by Social Recovery + +description: This EIP describes a token recovery by a transfer from an identity which is not accessible anymore to another newly created identity by social interaction. + +author: Erhard Dinhobl ([@mrqc](https://github.com/mrqc)), Kevin Riedl ([@wsdt](https://github.com/wsdt)) + +discussions-to: + +status: Draft + +type: Standards Track + +category: ERC + +created: 2022-07-19 + +requires (*optional): - + +--- + + +## Abstract +Within this EIP a mechanism of a social recovery is proposed. This implies that by the approval of many identities a token transfer from the identity of the lost private key to a knew identity where the private key is known. This approval is not a technical implementation but needs an interaction of humans. These humans are - based on the Soul Bound Token proposal - called Souls. When enough Souls give their approval (which is a Yes/No decision) and a threshold is reached this transfer from an old to a new identity is performed by a smart contract. + +## Motivation +It is always the problem that the private key of an identity can be lost. The reasons for that are manifold. If that key is lost its not possible to recover the tokens. The holder loses his tokens forever. Also the implications to the ecosystem of the token itself is a problem. The more tokens are lost the less tokens are available and a natural growth and a planned evolving of the token is not possible. + +## Specification + +```solidity + +pragma solidity ^0.8.7; + +interface ISBT { + function calcScore(address identityAddr_) external view returns (int256); + + function approveTransfer(address from_, address to_) external; + + function requestTransfer(address from_, address to_) external payable; + + function addNeighbour(address neighbour_) external; + + function removeNeighbour(address neighbour_) external; +} +``` + +## Rationale +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. + +## The math behind it + +We calculate the score of a node n with the following formular: + +$$ score(n) = tanh({{{\displaystyle\sum_{i = 1}^{|N|}} {log{(n_i^{r} {1 \over t - n_i^{t} + 1})}} \over{|N| + 1}} + n^{r}}) $$ + +where: + +$t$ is the current time (whether here and in correlation with $n_i^{t}$ the current block number is stored or some other time identifying value is irrelevant) + +$n^{r}$ is the reward count of the node n + +$N$ is the list of neighbours of n + +$n_i^{r}$ is the reward count of neighbour node i from n + +$n_i^{t}$ is the last timestamp (where a reward was booked on that account) of neighbour node i from n + +## Flows + +```mermaid +%% Approval of asset movement + sequenceDiagram + AnyWallet->SmartContract: Requests transfer + SmartContract->All neighbours: Centralized notification via Websocket, EPNS, etc. + Neighbour->SmartContract: Approve Transfer + alt Threshold amount of approvers reached + alt Cumulative Score of approvers above threshold + SmartContract->NewAssetOwner: Transfer asset (e.g. identity token) + end + end + SmartContract->Neighbour: Add Reward to approver +``` + +## Test Cases +No test cases provided. + +## 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 +In this chapter we want to get into security concerns we found or which came during the implementation. There are three important things which came up. + +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 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. + +3) Another problem we see is that the network of the users is not used anymore. Which means that due to a not used contract 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. + +## Copyright +Copyright and related rights waived via [CC0](../LICENSE.md). \ No newline at end of file From edf3c2ab14621f21dadd51ffe5e220d65fe10657 Mon Sep 17 00:00:00 2001 From: wsdt Date: Sun, 6 Nov 2022 11:27:31 +0100 Subject: [PATCH 02/19] delimiter --- EIPS/eip-5807.md | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/EIPS/eip-5807.md b/EIPS/eip-5807.md index 0e9edd670ebab..d8d5bd8d15486 100644 --- a/EIPS/eip-5807.md +++ b/EIPS/eip-5807.md @@ -1,22 +1,13 @@ --- eip: - title: Token Transfer by Social Recovery - description: This EIP describes a token recovery by a transfer from an identity which is not accessible anymore to another newly created identity by social interaction. - author: Erhard Dinhobl ([@mrqc](https://github.com/mrqc)), Kevin Riedl ([@wsdt](https://github.com/wsdt)) - discussions-to: - status: Draft - type: Standards Track - category: ERC - created: 2022-07-19 - requires (*optional): - --- @@ -109,4 +100,4 @@ In this chapter we want to get into security concerns we found or which came dur 3) Another problem we see is that the network of the users is not used anymore. Which means that due to a not used contract 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. ## Copyright -Copyright and related rights waived via [CC0](../LICENSE.md). \ No newline at end of file +Copyright and related rights waived via [CC0](../LICENSE.md). From 2dbdf4e44d32ad5b3491268f3448b14e8209bc60 Mon Sep 17 00:00:00 2001 From: wsdt Date: Sun, 6 Nov 2022 11:33:08 +0100 Subject: [PATCH 03/19] Social Recovery - Validation errors fix --- EIPS/eip-5807.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-5807.md b/EIPS/eip-5807.md index d8d5bd8d15486..5522cb1404c1e 100644 --- a/EIPS/eip-5807.md +++ b/EIPS/eip-5807.md @@ -1,15 +1,14 @@ --- -eip: +eip: 5807 title: Token Transfer by Social Recovery description: This EIP describes a token recovery by a transfer from an identity which is not accessible anymore to another newly created identity by social interaction. -author: Erhard Dinhobl ([@mrqc](https://github.com/mrqc)), Kevin Riedl ([@wsdt](https://github.com/wsdt)) +author: Erhard Dinhobl (@mrqc), Kevin Riedl (@wsdt) discussions-to: status: Draft type: Standards Track category: ERC created: 2022-07-19 requires (*optional): - - --- @@ -22,7 +21,7 @@ It is always the problem that the private key of an identity can be lost. The re ## Specification ```solidity - + pragma solidity ^0.8.7; interface ISBT { From 226e8db7177447b5dabe9abbeec63b3c7070ecc1 Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Wed, 9 Nov 2022 09:43:14 +0100 Subject: [PATCH 04/19] Update EIPS/eip-5807.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5807.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5807.md b/EIPS/eip-5807.md index 5522cb1404c1e..04f0416d164a0 100644 --- a/EIPS/eip-5807.md +++ b/EIPS/eip-5807.md @@ -1,5 +1,5 @@ --- -eip: 5807 +eip: 5883 title: Token Transfer by Social Recovery description: This EIP describes a token recovery by a transfer from an identity which is not accessible anymore to another newly created identity by social interaction. author: Erhard Dinhobl (@mrqc), Kevin Riedl (@wsdt) From a90abbffcd587a4190bee22a193caed1af587f3e Mon Sep 17 00:00:00 2001 From: wsdt Date: Wed, 9 Nov 2022 09:53:03 +0100 Subject: [PATCH 05/19] EIP 5883 - fixing validation errors --- EIPS/{eip-5807.md => eip-5883.md} | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) rename EIPS/{eip-5807.md => eip-5883.md} (95%) diff --git a/EIPS/eip-5807.md b/EIPS/eip-5883.md similarity index 95% rename from EIPS/eip-5807.md rename to EIPS/eip-5883.md index 04f0416d164a0..f9130251238a8 100644 --- a/EIPS/eip-5807.md +++ b/EIPS/eip-5883.md @@ -1,23 +1,25 @@ --- eip: 5883 title: Token Transfer by Social Recovery -description: This EIP describes a token recovery by a transfer from an identity which is not accessible anymore to another newly created identity by social interaction. +description: On-Chain Social Recovery author: Erhard Dinhobl (@mrqc), Kevin Riedl (@wsdt) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-5806-delegate-transaction/11409 status: Draft type: Standards Track category: ERC created: 2022-07-19 -requires (*optional): - +requires: - --- - ## Abstract + Within this EIP a mechanism of a social recovery is proposed. This implies that by the approval of many identities a token transfer from the identity of the lost private key to a knew identity where the private key is known. This approval is not a technical implementation but needs an interaction of humans. These humans are - based on the Soul Bound Token proposal - called Souls. When enough Souls give their approval (which is a Yes/No decision) and a threshold is reached this transfer from an old to a new identity is performed by a smart contract. ## Motivation + It is always the problem that the private key of an identity can be lost. The reasons for that are manifold. If that key is lost its not possible to recover the tokens. The holder loses his tokens forever. Also the implications to the ecosystem of the token itself is a problem. The more tokens are lost the less tokens are available and a natural growth and a planned evolving of the token is not possible. + ## Specification ```solidity From 85ff6dacd61bf2076c488f7dd3ac35eebb7ea5d3 Mon Sep 17 00:00:00 2001 From: wsdt Date: Wed, 9 Nov 2022 09:55:26 +0100 Subject: [PATCH 06/19] final validation errors fixed - EIP 5883 --- EIPS/eip-5883.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index f9130251238a8..d30dde94b5deb 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -8,7 +8,6 @@ status: Draft type: Standards Track category: ERC created: 2022-07-19 -requires: - --- ## Abstract @@ -39,10 +38,7 @@ interface ISBT { } ``` -## Rationale -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. - -## The math behind it +**The math behind it**: We calculate the score of a node n with the following formular: @@ -60,7 +56,8 @@ $n_i^{r}$ is the reward count of neighbour node i from n $n_i^{t}$ is the last timestamp (where a reward was booked on that account) of neighbour node i from n -## Flows + +**Flows**: ```mermaid %% Approval of asset movement @@ -76,6 +73,10 @@ $n_i^{t}$ is the last timestamp (where a reward was booked on that account) of n SmartContract->Neighbour: Add Reward to approver ``` + +## Rationale +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. + ## Test Cases No test cases provided. From ca5d70802cc89822f242b57f0596c37dd79cba4b Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Wed, 16 Nov 2022 16:40:25 +0100 Subject: [PATCH 07/19] Update eip-5883.md --- EIPS/eip-5883.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index d30dde94b5deb..68357c16ffa07 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -42,7 +42,7 @@ interface ISBT { We calculate the score of a node n with the following formular: -$$ score(n) = tanh({{{\displaystyle\sum_{i = 1}^{|N|}} {log{(n_i^{r} {1 \over t - n_i^{t} + 1})}} \over{|N| + 1}} + n^{r}}) $$ +$$ score(n) = tanh({ { {\displaystyle\sum_{i = 1}^{|N|} } {log{(n_i^{r} {1 \over t - n_i^{t} + 1})}} \over{|N| + 1}} + n^{r}}) $$ where: From 79c9224274c3827e4607b18c73003011cc0c72d3 Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Wed, 16 Nov 2022 16:46:48 +0100 Subject: [PATCH 08/19] Fix Markdown linter --- EIPS/eip-5883.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index 68357c16ffa07..d9d248f9ba6c5 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -75,12 +75,15 @@ $n_i^{t}$ is the last timestamp (where a reward was booked on that account) of n ## Rationale + 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. ## Test Cases + No test cases provided. ## 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): @@ -93,6 +96,7 @@ function log(uint256 z) public pure returns (uint256) { ``` ## Security Considerations + In this chapter we want to get into security concerns we found or which came during the implementation. There are three important things which came up. 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. @@ -102,4 +106,5 @@ In this chapter we want to get into security concerns we found or which came dur 3) Another problem we see is that the network of the users is not used anymore. Which means that due to a not used contract 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. ## Copyright + Copyright and related rights waived via [CC0](../LICENSE.md). From e152a5fd62a9289638c7cbfae06ca328f187343e Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Wed, 16 Nov 2022 16:52:27 +0100 Subject: [PATCH 09/19] Update eip-5883.md --- EIPS/eip-5883.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index d9d248f9ba6c5..9c72884b15131 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -88,7 +88,7 @@ No reference implementation provided. We suggest to use as approximation for $ta We suggest to use as approximation for $log()$ (base of 10): -```solidity +```solidity function log(uint256 z) public pure returns (uint256) { if (z == 0) return 0; return (z - 1) / (z + 1); From 052cede34ecb25e68815ee32761ff3b2277c3ea2 Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 20 Nov 2022 21:39:50 +0100 Subject: [PATCH 10/19] Update eip-5883.md --- EIPS/eip-5883.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index 9c72884b15131..25f29d0ab53a3 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -40,7 +40,7 @@ interface ISBT { **The math behind it**: -We calculate the score of a node n with the following formular: +A compliant contract SHOULD calculate the score of a node n with the following formular: $$ score(n) = tanh({ { {\displaystyle\sum_{i = 1}^{|N|} } {log{(n_i^{r} {1 \over t - n_i^{t} + 1})}} \over{|N| + 1}} + n^{r}}) $$ From b2e54a7e6736b21f4aef55394f5c44484c8d0b2a Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 20 Nov 2022 21:41:03 +0100 Subject: [PATCH 11/19] Update eip-5883.md --- EIPS/eip-5883.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index 25f29d0ab53a3..dd0b98b78b2fd 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -40,7 +40,7 @@ interface ISBT { **The math behind it**: -A compliant contract SHOULD calculate the score of a node n with the following formular: +A compliant contract SHOULD calculate the score of a node n with the following formula: $$ score(n) = tanh({ { {\displaystyle\sum_{i = 1}^{|N|} } {log{(n_i^{r} {1 \over t - n_i^{t} + 1})}} \over{|N| + 1}} + n^{r}}) $$ From 8db3a07edbf0f048aa20e7f366bc1225d1260965 Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 27 Nov 2022 11:14:26 +0100 Subject: [PATCH 12/19] Update EIPS/eip-5883.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5883.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index dd0b98b78b2fd..dea6749aa72fb 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -97,7 +97,6 @@ function log(uint256 z) public pure returns (uint256) { ## Security Considerations -In this chapter we want to get into security concerns we found or which came during the implementation. There are three important things which came up. 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. From 21e3e74211321030fd0711899f363491112b432e Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 27 Nov 2022 11:14:33 +0100 Subject: [PATCH 13/19] Update EIPS/eip-5883.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5883.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index dea6749aa72fb..40b2044f895b3 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -78,10 +78,6 @@ $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. -## Test Cases - -No test cases provided. - ## 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. From 99ef53400a638976c58eab0b636d60f7d5759f95 Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 27 Nov 2022 11:14:49 +0100 Subject: [PATCH 14/19] Update EIPS/eip-5883.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5883.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index 40b2044f895b3..71f4563916831 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -12,7 +12,7 @@ created: 2022-07-19 ## Abstract -Within this EIP a mechanism of a social recovery is proposed. This implies that by the approval of many identities a token transfer from the identity of the lost private key to a knew identity where the private key is known. This approval is not a technical implementation but needs an interaction of humans. These humans are - based on the Soul Bound Token proposal - called Souls. When enough Souls give their approval (which is a Yes/No decision) and a threshold is reached this transfer from an old to a new identity is performed by a smart contract. +This EIP standardizes a mechanism of a social recovery where a token may be transferred from an inaccessible account to a new account, given enough approvals from other identities. This approval is not purely technical, but rather needs human intervention. These humans are - based on the Soul Bound Token proposal - called Souls. When enough Souls give their approval (which is a Yes/No decision) and a threshold is reached, a token is transferred from an old to a new identity. ## Motivation From f2254f4022ad1b7bfdec040eb5242e9ba8a5911e Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 27 Nov 2022 11:14:55 +0100 Subject: [PATCH 15/19] Update EIPS/eip-5883.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5883.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index 71f4563916831..bfe6ae35f1443 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -16,7 +16,7 @@ This EIP standardizes a mechanism of a social recovery where a token may be tran ## Motivation -It is always the problem that the private key of an identity can be lost. The reasons for that are manifold. If that key is lost its not possible to recover the tokens. The holder loses his tokens forever. Also the implications to the ecosystem of the token itself is a problem. The more tokens are lost the less tokens are available and a natural growth and a planned evolving of the token is not possible. +It is a known problem that the private key of an account can be lost. If that key is lost it's not possible to recover the tokens owned by that account. The holder loses those tokens forever. In addition to directly harming the token holder, the entire ecosystem of the token itself is affected: the more tokens that are lost the less tokens are available for the natural growth and planned evolution of that ecosystem. ## Specification From 8b0b05ae4315e6b2f4e56838ba1225f225f82f2f Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 27 Nov 2022 11:21:22 +0100 Subject: [PATCH 16/19] Update EIPS/eip-5883.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5883.md | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index bfe6ae35f1443..260872b207e5a 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -78,18 +78,6 @@ $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 From 8b64b8686671fd6f7c6a281d61365e9223a75c55 Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Sun, 27 Nov 2022 11:21:29 +0100 Subject: [PATCH 17/19] Update EIPS/eip-5883.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5883.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index 260872b207e5a..953fac4beb646 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -84,7 +84,7 @@ The rationale fleshes out the specification by describing what motivated the des 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 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 users is not used anymore. Which means that due to a not used contract 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. From 869bf48081c454cd1203ceb7845e66734f526f08 Mon Sep 17 00:00:00 2001 From: wsdt Date: Sun, 27 Nov 2022 11:35:30 +0100 Subject: [PATCH 18/19] applied feedback - 5883 --- EIPS/eip-5883.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index bfe6ae35f1443..2579e042dbacb 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -1,7 +1,7 @@ --- eip: 5883 title: Token Transfer by Social Recovery -description: On-Chain Social Recovery +description: On-Chain Social Recovery taking users' reputation into account & using a nearest-neighbour approach. author: Erhard Dinhobl (@mrqc), Kevin Riedl (@wsdt) discussions-to: https://ethereum-magicians.org/t/eip-5806-delegate-transaction/11409 status: Draft @@ -25,7 +25,7 @@ It is a known problem that the private key of an account can be lost. If that ke pragma solidity ^0.8.7; -interface ISBT { +interface ISocialRecovery { function calcScore(address identityAddr_) external view returns (int256); function approveTransfer(address from_, address to_) external; @@ -46,7 +46,7 @@ $$ score(n) = tanh({ { {\displaystyle\sum_{i = 1}^{|N|} } {log{(n_i^{r} {1 \over where: -$t$ is the current time (whether here and in correlation with $n_i^{t}$ the current block number is stored or some other time identifying value is irrelevant) +$t$ is the current time (can be any time-identifying value such as `block.timestamp`, `block.number`, etc.) $n^{r}$ is the reward count of the node n @@ -96,9 +96,9 @@ function log(uint256 z) public pure returns (uint256) { 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 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 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. -3) Another problem we see is that the network of the users is not used anymore. Which means that due to a not used contract 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. +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. ## Copyright From 11f3be92cac86533dade8955b269264f586d9800 Mon Sep 17 00:00:00 2001 From: "Riedl Kevin, Bsc" Date: Tue, 31 Jan 2023 11:28:37 +0100 Subject: [PATCH 19/19] Fixing comments. --- EIPS/eip-5883.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-5883.md b/EIPS/eip-5883.md index 640daa7cad0b9..05b6969384f78 100644 --- a/EIPS/eip-5883.md +++ b/EIPS/eip-5883.md @@ -26,10 +26,10 @@ It is a known problem that the private key of an account can be lost. If that ke pragma solidity ^0.8.7; interface ISocialRecovery { - function calcScore(address identityAddr_) external view returns (int256); - + /// @dev Related but independent identity approves the transfer function approveTransfer(address from_, address to_) external; + /// @dev User wants to move their onchain identity to another wallet which needs to be approved by n-nearest neighbour identities function requestTransfer(address from_, address to_) external payable; function addNeighbour(address neighbour_) external; @@ -76,7 +76,7 @@ $n_i^{t}$ is the last timestamp (where a reward was booked on that account) of n ## Rationale -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. +The formula proposed was deemed very resilient and provides a coherent incentivation structure to actually see value in the on-chain score. The formula adds weights based on scores based on time which further contributes to the fairness of the metric. ## Security Considerations