Probably a very naive question, but when attacks occur such as the etherdelta one yesterday, what's stopping having a system in place to basically freeze assets in a certain address before the attacker moves funds? I.e. Each node submits a vote to blacklist a certain address and when consensus is reached, nodes refuse to include any transactions from that certain address. Does something like this exist (on any chain), if not why?

  • 1
    Have in mind that the attack on EtherDelta didn't involve the smart contracts at all. Someone hijacked the site by attacking their DNS servers and changing the site, so basically if you interacted with it, you are/were giving out information to a completely different site. Blacklisting addresses would not solve any problem as funds in the smart contracts are not being attack. Rather, they are "just" stealing the private keys of people that interact with the fake site. – pabloruiz55 Dec 21 '17 at 17:43
  • 1
    I understand but the attacker sent all of the ether/tokens to one address, which was held for a significant amount of time before splitting to other addresses. – Strife Dec 21 '17 at 18:43

Partial answer.

If voting were free and part of the protocol, there's nothing to stop a sybil attack from blacklisting legitimate accounts or removing malicious accounts from a blacklist.

If voting had a cost, because accounts are free to create, there's nothing to stop someone from splitting up an attack to create a huge cost for members of the network to blacklist the accounts -- another attack on the network.

If voting were free and not part of the protocol (such as an external voting system that resulted in a hard fork), then the system would be unresponsive to attacks. TheDAO attack was only able to be countered on the mainnet without rolling back any transactions because of the waiting period for withdrawal of ether in TheDAO contract.

If voting were restricted to manipulation of the protocol (such as via miners censoring transactions by refusing to mine/relay any transactions involving the to-be-blacklisted account), this would have the same effect as above, except that the network could soft fork if miners are hard-headed enough. Then the cost of voting becomes one's ability to acquire hashing power (or staking power) -- which then falls back into the second case.

Ironically, if users act individually, they can resolve this problem. One can ignore tainted ether/tokens and treat them the same way an honest person would treat counterfeit cash: by disposing of it. This can be done by burning the tokens. One can also declare that tokens sent by an account (or via a tainted address) will be burned. For example, Changelly blacklisted the address for the Parity wallet theft earlier this year. Any tainted coins thus become destroyed like being sent to a tar pit. If users individually agree that a particular account should be tar-pitted, then they ought to respect transactions sent from an account that was tainted but then burned the coins. If these users are the majority, then there is a strong individual incentive to burn the coins to prevent one's accounts from becoming tainted/blacklisted. If these users are in the minority, then one is burning coins for nothing (except, perhaps, one's own conscience and for transacting with the rest of the minority).

  • Makes sense, a completely different idea. What if the protocol implemented a unique id to each token and restricted it to some arbitrary indivisible amount i.e. each ether can only be split until 0.1 and each of those has its own id. That 0.1 ether would be the min base cost for any transaction, and any transaction would incorporate all the ids sent. That way all tokens can be tracked / blacklisted on consensus at a later time, even if the attacker spread them among several addresses. – Strife Dec 21 '17 at 19:03
  • That would take up a lot of space and processing time to handle and would become impractical due to dynamic range issues. If the smallest transaction you wanted to make was one billionth of the size of the total transaction sizes, storing the blockchain's current state would take, in the worst case, 32 GiB (look-up table for each of the 1B tokens mapping to 1Bx256-bit addresses, stored as an array with no metadata). If you even look at the transactions occurring inside even a city, compare the cost of a coffee ($1?) to the houses in the area ($500K * 2M houses) is a billion-to-one. – lungj Dec 21 '17 at 19:10
  • One could attempt to avoid this by compressing values by sending contiguous coins using different allocation efforts. Even assuming no malicious users, we would eventually run into fragmentation issues en.wikipedia.org/wiki/Fragmentation_(computing) . This is the same reason a computer can be unable to allocate RAM despite having lots of free memory. Defragmentation could potentially be done on a tangle-like system (as used in IOTA), but IMHO, tangles have huge issues as formulated (and IOTA has even more issues). Defrag could not be done in a state-preserving blockchain. – lungj Dec 21 '17 at 19:12

It cannot be done. The reason being it opens a DDOS vector. The malicious address can be hidden by creating a program of very high complexity and then running this program would result in no gas going to miners due to the block being excluded. This is because it's impossible to perform statics analysis of a turing complete program.

Also, an attempt a stealth fork (such as collusion by top 5 miners) would create orphaned blocks and forked chains and this would be obvious to the rest of the community when high gas transactions don't get processed or are processed on a smaller chain.

more info:




What happens if a miner who didn't soft fork mines an "invalid" block?






  • This is a good answer but please refrain from posting links(they may expire) and instead, highlight the required part in your answer. – Vignesh Karthikeyan Jun 11 '18 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.