8

It sounds like you are being front run. This means that a bot is watching you send a transaction, reading the input (specifically, _answer), and submitting a transaction with the correct answer but a higher gasPrice. A miner will accept their transaction before yours, causing theirs to succeed and yours to fail. You can see that this is, in fact, what is ...


3

This attack was eliminated for all practical purposes by EIP 150, which was implemented in October, 2016. For details see How does EIP 150 change the call depth attack?


2

No. At least not as far as the EVM and contracts are concerned. The EVM has too much overhead and lacks the constructs needed to exploit either of these bugs.


2

A few ideas, but nothing concrete. Might be verging on the speculative... we randomly... How? Are you using a source that lists all contracts deployed in the time period? Or are you just looking at contracts that use the transfer/withdraw pattern, and checking what proportion of those contains a reentrancy vulnerability? If you're using a sample from ...


2

Technically speaking, there's nothing you can do. The code is immutable and it will stay like that forever. Socially, there's a lot which can be done. In most cases, a comment should be enough, indeed. However, if you reckon that's a high-volume contract with many daily active users, contact Etherscan, MetaMask and alert the Reddit community. If it's more ...


2

Let's suppose you have a raffle and can reserve a number contract Raffle { mapping(uint256 => address) reserved; event Reserved(uint256 value, address owner); function reserve(uint256 value) public { require(reserved[value] == address(0), "Already reserved"); reserved[value] = msg.sender; emit Reserved(value, msg....


2

This would have been possible if at least one honest actor would have voted for this split. Since the attacker is most likely the only shareholder and the curator of this DAO the same attack can not be done. Quoted from the FAQ. Update: Lefteris Karapetsas found out a way how to enter the "darkDAO" - this allows indeed to counter attack the "darkDAO" and ...


2

Yes! the attacker would have to use a call in his wallets fallback function and call the function again so he will be able to detract the money within the same recursion call, before p.executed = true.


1

People have been explaining this since Bitcoin emerged on the scene but it's a little difficult to grasp at first and usually takes a few explanations from a few angles, so I'll try for an overview that zeros in on your specific question. Bear with me as a layer a few concepts. Blockchain consensus is mainly concerned with reaching an agreement about the ...


1

When the caller is an smart contract if it can re-enter BuggyWithdraw and can change balance[msg.sender] then it will be possible that BalanceDecreased is never emitted. So an off-chain service that relies on that event might not take into account the balance has decreased.


1

No, it is not necessary. Its use is unrelated to tx.origin vulnerability. I think the idea of the question was to have two files: Victim: contract TxUserWallet Attacker: interface TxUserWallet, contract TxAttackWallet


1

If somebody calls function pay of a C instance with the address of a D1 instance: The C instance is supposed to send n wei to the D1 instance As a result of d.send, the fallback function of the D1 instance will be executed This function changes a state-variable of the D1 instance, an operation which costs at least 5000 gas Since this is more than the 2300 ...


1

totalSupply stores the current amount of minted tokens, not the maximum amount of tokens which can be minted. In order to restrict this amount, one needs to apply additional code (not part of the ERC20 standard). Otherwise, it is restricted only by the limitation of the underlying platform (i.e., the size of uint256).


1

In the transferProxy fucntion, if(balances[_from] < _fee + _value) revert(); can cause overflow error. They didn't check _fee + _value is less than 2^256. So when you set REALLY big number on _value, then _fee + _value, the sums up to 0 in 256 bit, so balances[_from] check will be passed!! There nothing wrong with signature verification, it has problem ...


1

As always there is no silver bullet. Different features with different tradeoffs between maintainability, complexity, and trust are possible: Who can upgrade? nobody - impossible to upgrade/evolve since the code is carved into the stone (e.g.: trust++, complexity++, maintainability--) owner only - participants are forced to accept the change (e.g.: trust--,...


1

It's not possible. The application that the ledger is interacting with constructs the transaction and sends it to the Ledger. The Ledger then displays the address for you to verify. You verify it shows the expected address, click confirm, and the Ledger signs it. The signature is actually a signature of the hash of the whole transaction, which includes the ...


1

Well... you should really specify the visibility of your functions and at least include safe math. look at the compiler outputs: https://ethfiddle.com/qI7KPs6GVW


1

I second that interchanging the two lines will not cause any vulnerability, however if you send any form of value before updating the 'balances' mapping, then you might be vulnerable to reentrancy attacks. Just make sure you implement the two lines before sending any type of value regardless of order(even though it would be best practices to subtract and ...


1

AFAIK, Interchanging these 2 lines will not cause any vulnerability. But the question is why you want to do so? Ideally, we first subtract balance from sender then add it to the receiver. This could harm only in cases if the first line executes and the second doesn't. But I guess this should never happen. Even if the gas supplied with the transaction is ...


Only top voted, non community-wiki answers of a minimum length are eligible