Allowing contracts to declare a transaction invalid

Comments

• Jasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭

  August 2014

  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)

  1 · Share on TwitterShare on Facebook
• tomgalvin Member Posts: 10 ✭

  August 2014

  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.

  1 · Share on TwitterShare on Facebook
• Jasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭

  August 2014

  i = 0
  while tx.gas > 0:
       if sha256(i) != 0x1bfcd53a87e20ae004cd931d092057d5852f54701c52dc0e607f29a82a1e8e6c:
            invalid()
       i+=1
  

  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)

  0 · Share on TwitterShare on Facebook
• tomgalvin Member Posts: 10 ✭

  August 2014

  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?

  0 · Share on TwitterShare on Facebook
• Jasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭

  August 2014

  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.

  1 · Share on TwitterShare on Facebook