Ricardo Prado

Hi @erikzhang, but we are keeping both neo2 and neo3 running simultaneously for some time, aren't we? At least during this period of time, we need to describe if the...

I think only one is better. Other fields may be optional.

@igormcoelho I think @shargon is correct. We need o be able to change behavior using the block height, like Ethereum. So if we release a "NEO 3.1", we can be...

@igormcoelho The problem of not having this inside the VM is that we are letting the compatibility problems for our users, and this shouldn't be the case, right? I mean,...

@shargon but shouldn't this kind of information be visible at "protocol" level? Or do you think that we should have this logic hardcoded?

Hi @Tommo-L, #327 only fixes the "control-c" issue, I prefer to have this issue open to deal with the exception messages, ok? Thanks

Hello hello, Yes. using different addresses is one option; however, it doesn't solve the user problems. In fact, you are just creating another problem: maintain another wallet. This is riskier...

Yes. We need to update both Neo library and the Compiler. I think that only adding this method won't resolve the problem (it will improve but not fix it totally)....

We don't store the transaction hash inside the ContractState object. This information exists only on the transaction that deployed the contract. Adding this information anywhere else would be duplicating data....

> The sender of a deployed contract is not necessarily the owner of the contract. A contract may have logic to modify its owner. Maybe `CheckWitness(contract.Hash)` directly? Yes, it may...