Allowing contracts to declare a transaction invalid

Is there a built-in function that allows a contract to make the calling transaction invalid, and thus ineligible to be included in a block? I've searched Google, but wasn't able to find even a discussion concerning it. Such behavior can already be implemented using an infinite loop, so a built-in would simply be a convenience function. Is it planned on being implemented, or is the concept of invalidating a transaction from a contract discouraged because it would mess with the strict serial nature of the transactions coming from a specific address?


  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Yeah it could be a useful feature, because you could run it in-simulation and not-publish the transaction if invalidity is reached. That said, the infinite while loop might be sufficient?
    (def (invalid) (for {} 1 {} {}))
    Because in the halting problem you cannot predict whether and arbitrary program will stop without running it until it stops. This is why if it is published, nothing can be put in place to avoid the gas being burned, it has to be eligible for placement in a block.(infact in principle things could be made such that nothing needs to be executed at when creating a block)
  • tomgalvintomgalvin Member Posts: 10
    I looked into this a little further, and found this in the whitepaper:
    If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.
    So the infinite loop (or some other method of burning all the gas) does not invalidate the transaction, it would only result in no changes to the contract storage and the gas fee being transferred to the miner.

    Perhaps an invalid EVM opcode could do the job? I don't see that behavior defined anywhere, and the current EVM implementation just throws a exception.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    i = 0
    while tx.gas > 0:
    if sha256(i) != 0x1bfcd53a87e20ae004cd931d092057d5852f54701c52dc0e607f29a82a1e8e6c:
    Knowing which value is sha256-summed, you can immediately know whether it is invalid, otherwise, it might just happen to not run out of gas. The miners cant see which is which, or which code is 'like this' from many variants. We dont want to create a cat and mouse game where people make new code to try give themselves an advantage relative to other miners.

    Also, i like the idea of not needing to execute the code before accepting transactions.(code from prior blocks does have to be executed, of course)
  • tomgalvintomgalvin Member Posts: 10
    If a contract identifies a transaction as invalid, it would not propagate throughout the network, just as a transaction with an invalid signature would not. Thus, the only way for a miner to slow down other miners by creating invalid transactions would be to connect to them and send many of these transactions directly. This is basically a DoS attack and could be committed with or without invalid transactions.

    PS. Out of curiosity, what hashes to 0x1bfcd53a87e20ae004cd931d092057d5852f54701c52dc0e607f29a82a1e8e6c?
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Yeah but if the max gas and ethers sent determines the validity, that doesnt require any computation, and you could even have nodes keep track on how much was sent so far, and block once there wouldnt be enough ethers on an address to send it.

    Whereas with an 'invalid' statement in the code, you do need to compute, and cannot keep track of those numbers, an attacker can keep sending new ones. Besides, client-side logic might be able to determine whether to send that transaction in the first place. Maybe you could have a instruction that asks the miners nicely, and good defaults about it.
    PS. Out of curiosity, what hashes to 0x1bfcd53a87e20ae004cd931d092057d5852f54701c52dc0e607f29a82a1e8e6c?
    Dunno, generated it with echo $RANDOM$RANDOM$RANDOM$RANDOM |sha256sum(or more/less $RANDOMs) which actually the wrong way to do it, it takes the number as a string, and includes the newline.
Sign In or Register to comment.