Skip to content
This repository has been archived by the owner on Oct 20, 2020. It is now read-only.

Malicious slowdown using valid headers #15

Open
MaksymZavershynskyi opened this issue Sep 5, 2020 · 0 comments
Open

Malicious slowdown using valid headers #15

MaksymZavershynskyi opened this issue Sep 5, 2020 · 0 comments
Assignees
Labels
bug Something isn't working

Comments

@MaksymZavershynskyi
Copy link
Contributor

Suppose there is NearOnEthClient running on Ethereum blockchain that accepts headers every 4 hours from Near2EthRelay. Suppose the last header in NearOnEthClient hash height X, as soon as it passes the challenge period someone malicious submits a valid header of height X+1. This header is valid and cannot be challenged, but it progresses client only 1 block ahead. In 4 hours the attack can be repeated.

The solution proposed by @abacabadabacaba is the following:

Allow replacing the current block during challenge period if the new block is at least 5 hours ahead of the current block. When this happens, the challenge period is restarted.

@MaksymZavershynskyi MaksymZavershynskyi added the bug Something isn't working label Sep 5, 2020
abacabadabacaba added a commit that referenced this issue Sep 11, 2020
…added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
abacabadabacaba added a commit that referenced this issue Sep 11, 2020
…added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
abacabadabacaba added a commit that referenced this issue Sep 12, 2020
…added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
abacabadabacaba added a commit that referenced this issue Sep 15, 2020
…added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
abacabadabacaba added a commit that referenced this issue Sep 19, 2020
…. Now a newly added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
abacabadabacaba added a commit that referenced this issue Sep 20, 2020
…. Now a newly added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
abacabadabacaba added a commit that referenced this issue Sep 21, 2020
…. Now a newly added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
abacabadabacaba added a commit that referenced this issue Sep 22, 2020
…. Now a newly added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.
MaksymZavershynskyi pushed a commit that referenced this issue Oct 6, 2020
* Bump version, change the state machine used for processing new blocks. Now a newly added block that is not yet trusted is stored in untrustedHead. After the challenge period is over, it can be moved to head. Fixes #13, #15.

* CHANGELOG

Co-authored-by: Maksym Zavershynskyi <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants