You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Block 100: Bob's account was registered in transaction T_bob.
Block 101: Alice transfers Steem to Bob in transaction T_alice.
The net effect of T_bob followed by T_alice is a legitimate transfer of STEEM.
Attacker Eve controls a few malicious witnesses, but nowhere near a majority.
Then suppose Eve performs the following attack:
Eve's witnesses produce a fork with a different account_create_operation for Bob's account, which registers the name bob to Eve. This is T_eve in block 100_eve.
Eve's fork also migrates (copies) T_alice from the legitimate fork.
The net effect of T_eve followed by T_alice is a fraudulent theft of STEEM.
If Eve controls three consecutive witnesses, she may create 101_eve and 102_eve creating a fork that is longer than the legitimate fork, resulting in the permanent inclusion of her theft.
Basically anything that involves an account but doesn't require the account's signature (for example the to account in transfer_operation) needs to TaPoS on a block in which the account was registered. So for example Alice needs to TaPoS on block 100.
But the wallet shouldn't blindly accept whatever registration exists in the chain at the moment it's broadcast, it could be that the fork happened between the point in time Alice decided to transfer the STEEM to Bob and the time Alice clicked the "submit" button or pressed Enter to finalize the transfer.
The safest thing to do is for Alice to wait until Bob's been irreversibly created. It also wouldn't hurt for Alice to wait for a fixed amount of wall-clock time as well (i.e. Alice won't transfer to any account younger than 15 minutes old).
The proper place to add this check is in the wallet.
The text was updated successfully, but these errors were encountered:
Suppose we have the following situation:
T_bob
.T_alice
.T_bob
followed byT_alice
is a legitimate transfer of STEEM.Then suppose Eve performs the following attack:
account_create_operation
for Bob's account, which registers the namebob
to Eve. This isT_eve
in block100_eve
.T_alice
from the legitimate fork.T_eve
followed byT_alice
is a fraudulent theft of STEEM.101_eve
and102_eve
creating a fork that is longer than the legitimate fork, resulting in the permanent inclusion of her theft.Basically anything that involves an account but doesn't require the account's signature (for example the
to
account intransfer_operation
) needs to TaPoS on a block in which the account was registered. So for example Alice needs to TaPoS on block 100.But the wallet shouldn't blindly accept whatever registration exists in the chain at the moment it's broadcast, it could be that the fork happened between the point in time Alice decided to transfer the STEEM to Bob and the time Alice clicked the "submit" button or pressed Enter to finalize the transfer.
The safest thing to do is for Alice to wait until Bob's been irreversibly created. It also wouldn't hurt for Alice to wait for a fixed amount of wall-clock time as well (i.e. Alice won't transfer to any account younger than 15 minutes old).
The proper place to add this check is in the wallet.
The text was updated successfully, but these errors were encountered: