From b27f40621c212dcc80bf62ea5e7b303283e7bd0a Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Fri, 11 Nov 2022 09:33:49 -0800 Subject: [PATCH 1/7] Move EIP-5732 to Final --- EIPS/eip-5732.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md index e208ec9edb1d9a..8689dca12f65bf 100644 --- a/EIPS/eip-5732.md +++ b/EIPS/eip-5732.md @@ -4,8 +4,7 @@ title: Commit Interface description: A simple but general commit interface to support commit-reveal scheme. author: Zainan Victor Zhou (@xinbenlv), Matt Stam (@mattstam) discussions-to: https://ethereum-magicians.org/t/erc-5732-simple-commit-interface-to-support-commit-reveal-schemes/11115 -status: Last Call -last-call-deadline: 2022-11-13 +status: Final type: Standards Track category: ERC created: 2022-09-29 From b0ce23eb8e459c5c274b05388189b81e997dc9ac Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Fri, 11 Nov 2022 09:39:51 -0800 Subject: [PATCH 2/7] Wording --- EIPS/eip-5732.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md index 8689dca12f65bf..64976d1a2607e6 100644 --- a/EIPS/eip-5732.md +++ b/EIPS/eip-5732.md @@ -8,7 +8,7 @@ status: Final type: Standards Track category: ERC created: 2022-09-29 -requires: 165 +requires: 165,1271 --- ## Abstract @@ -65,7 +65,7 @@ interface IERC_COMMIT_GENERAL { But there MUST be a way to supply an extra field of `secret_salt`, so that committer can later open the `secret_salt` in the reveal TX that exposes the `secret_salt`. The size and location of `secret_salt` is intentionally unspecified in this EIP to maximize flexibility for integration. -8. Compliant contract is RECOMMENDED to implement [EIP-165](./eip-165.md). +8. A compliant contract is RECOMMENDED to implement [EIP-165](./eip-165.md). ## Rationale @@ -117,6 +117,7 @@ function commit(bytes32 commitment, bytes calldata data) public { 5. Contract implementations SHOULD consider deleting the commitment of a given sender immediately to reduce chance of replay attack or re-entry attack by adversaries. 6. Contract implementations MAY consider also include the ordering of commitment received to add restriction on the order of reveal TX transactions. 7. Cautious on the potential replay attack across different chain-ids or chains resulting from forks, in which case, a ChainId shall be included in the generation of commitment. +For applications with higher risk of replay-attack, implementors SHOULD consider cryptographically battle-tested solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution. 8. Proper time-gap is suggested if the purpose is to avoid front-running attack. 9. For compliant contract that requires the `_timePoint` from next TX to be _strictly greater_ than a previous TX, `block.timestamp` and `block.number` are not reliable as two TX could co-exist in the same block resulting in the same `_timePoint` value. In such case, compliant contract is to take extra measures to enforce this strict-monotone-ness. For example, use a separate state variable in the contract to keep track of number of commits it receives, or reject any second/other TX that shares the same `block.timestamp` or `block.number`. From 0bcdfe8c7c2f9314a90399b42355c77f198067aa Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Fri, 11 Nov 2022 12:00:21 -0800 Subject: [PATCH 3/7] Update requires --- EIPS/eip-5732.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md index 64976d1a2607e6..81d34a71f2fa46 100644 --- a/EIPS/eip-5732.md +++ b/EIPS/eip-5732.md @@ -8,7 +8,7 @@ status: Final type: Standards Track category: ERC created: 2022-09-29 -requires: 165,1271 +requires: 165, 1271 --- ## Abstract From 93bbec171e5c654ebfb5c888a8fb17f15daf5e46 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 11 Nov 2022 21:28:12 -0500 Subject: [PATCH 4/7] Tighten up grammar --- EIPS/eip-5732.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md index 81d34a71f2fa46..50e540e5968a9b 100644 --- a/EIPS/eip-5732.md +++ b/EIPS/eip-5732.md @@ -65,7 +65,7 @@ interface IERC_COMMIT_GENERAL { But there MUST be a way to supply an extra field of `secret_salt`, so that committer can later open the `secret_salt` in the reveal TX that exposes the `secret_salt`. The size and location of `secret_salt` is intentionally unspecified in this EIP to maximize flexibility for integration. -8. A compliant contract is RECOMMENDED to implement [EIP-165](./eip-165.md). +8. It is RECOMMENDED for compliant contracts to implement [EIP-165](./eip-165.md). ## Rationale From 61d3e84c24e079a9cc848597aab4f348cec2879a Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 11 Nov 2022 21:28:44 -0500 Subject: [PATCH 5/7] Fix list formatting --- EIPS/eip-5732.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md index 50e540e5968a9b..de393f7359f617 100644 --- a/EIPS/eip-5732.md +++ b/EIPS/eip-5732.md @@ -117,7 +117,7 @@ function commit(bytes32 commitment, bytes calldata data) public { 5. Contract implementations SHOULD consider deleting the commitment of a given sender immediately to reduce chance of replay attack or re-entry attack by adversaries. 6. Contract implementations MAY consider also include the ordering of commitment received to add restriction on the order of reveal TX transactions. 7. Cautious on the potential replay attack across different chain-ids or chains resulting from forks, in which case, a ChainId shall be included in the generation of commitment. -For applications with higher risk of replay-attack, implementors SHOULD consider cryptographically battle-tested solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution. + * For applications with higher risk of replay-attack, implementors SHOULD consider cryptographically battle-tested solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution. 8. Proper time-gap is suggested if the purpose is to avoid front-running attack. 9. For compliant contract that requires the `_timePoint` from next TX to be _strictly greater_ than a previous TX, `block.timestamp` and `block.number` are not reliable as two TX could co-exist in the same block resulting in the same `_timePoint` value. In such case, compliant contract is to take extra measures to enforce this strict-monotone-ness. For example, use a separate state variable in the contract to keep track of number of commits it receives, or reject any second/other TX that shares the same `block.timestamp` or `block.number`. From d7969c06259c55d0750217b7a93f9b84926e07e5 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 11 Nov 2022 21:36:53 -0500 Subject: [PATCH 6/7] Tighten security considerations --- EIPS/eip-5732.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md index de393f7359f617..1c00885c0aa937 100644 --- a/EIPS/eip-5732.md +++ b/EIPS/eip-5732.md @@ -111,15 +111,15 @@ function commit(bytes32 commitment, bytes calldata data) public { ## Security Considerations 1. Do not use the reference implementation in production. It is just for demonstration purposes. -2. The reveal transactions, parameters, especially `secret_salt` MUST be kept in secrecy before revealing to achieve privacy. -3. The length of `secret_salt` cryptographically long enough and the way to generate a `secret_salt` shall be cryptographically safe. -4. User shall NEVER reuse a used `secret_salt`. It's RECOMMENDED for client application to warn User for reusing a secret_salt. -5. Contract implementations SHOULD consider deleting the commitment of a given sender immediately to reduce chance of replay attack or re-entry attack by adversaries. -6. Contract implementations MAY consider also include the ordering of commitment received to add restriction on the order of reveal TX transactions. -7. Cautious on the potential replay attack across different chain-ids or chains resulting from forks, in which case, a ChainId shall be included in the generation of commitment. - * For applications with higher risk of replay-attack, implementors SHOULD consider cryptographically battle-tested solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution. -8. Proper time-gap is suggested if the purpose is to avoid front-running attack. -9. For compliant contract that requires the `_timePoint` from next TX to be _strictly greater_ than a previous TX, `block.timestamp` and `block.number` are not reliable as two TX could co-exist in the same block resulting in the same `_timePoint` value. In such case, compliant contract is to take extra measures to enforce this strict-monotone-ness. For example, use a separate state variable in the contract to keep track of number of commits it receives, or reject any second/other TX that shares the same `block.timestamp` or `block.number`. +2. The reveal transactions and parameters, especially `secret_salt`, MUST be kept secret before they are revealed. +3. The length of `secret_salt` must be cryptographically long enough and the random values used to generate `secret_salt` must be cryptographically safe. +4. Users must NEVER reuse a used `secret_salt`. It's recommended for client applications to warn users who attempt to do so. +5. Contract implementations should consider deleting the commitment of a given sender immediately to reduce the chances of a replay attack or re-entry attack. +6. Contract implementations may consider including the ordering of commitment received to add restrictions on the order of reveal transactions. +7. There is potential for replay attacks across different chainIds or chains resulting from forks. In these cases, the chainId must be included in the generation of commitment. + * For applications with a higher risk of replay attacks, implementors should consider battle-tested and cryptographically-secure solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution. +8. Proper time gaps are suggested if the purpose is to avoid frontrunning attacks. +9. For compliant contract that requires the `_timePoint` from the next transaction to be _strictly greater_ than that of any previous transaction, `block.timestamp` and `block.number` are not reliable as two transactions could co-exist in the same block resulting in the same `_timePoint` value. In such case, extra measures to enforce this strict monotonicity are required, such as the use of a separate sate variable in the contract to keep track of number of commits it receives, or to reject any second/other TX that shares the same `block.timestamp` or `block.number`. ## Copyright From 22cad6a34dbae21654ba85503ed696a953844b16 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 11 Nov 2022 21:39:34 -0500 Subject: [PATCH 7/7] Remove random sublist --- EIPS/eip-5732.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md index 1c00885c0aa937..0828f88c2a39e0 100644 --- a/EIPS/eip-5732.md +++ b/EIPS/eip-5732.md @@ -116,8 +116,7 @@ function commit(bytes32 commitment, bytes calldata data) public { 4. Users must NEVER reuse a used `secret_salt`. It's recommended for client applications to warn users who attempt to do so. 5. Contract implementations should consider deleting the commitment of a given sender immediately to reduce the chances of a replay attack or re-entry attack. 6. Contract implementations may consider including the ordering of commitment received to add restrictions on the order of reveal transactions. -7. There is potential for replay attacks across different chainIds or chains resulting from forks. In these cases, the chainId must be included in the generation of commitment. - * For applications with a higher risk of replay attacks, implementors should consider battle-tested and cryptographically-secure solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution. +7. There is potential for replay attacks across different chainIds or chains resulting from forks. In these cases, the chainId must be included in the generation of commitment. For applications with a higher risk of replay attacks, implementors should consider battle-tested and cryptographically-secure solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution. 8. Proper time gaps are suggested if the purpose is to avoid frontrunning attacks. 9. For compliant contract that requires the `_timePoint` from the next transaction to be _strictly greater_ than that of any previous transaction, `block.timestamp` and `block.number` are not reliable as two transactions could co-exist in the same block resulting in the same `_timePoint` value. In such case, extra measures to enforce this strict monotonicity are required, such as the use of a separate sate variable in the contract to keep track of number of commits it receives, or to reject any second/other TX that shares the same `block.timestamp` or `block.number`.