figs999 / ethereum Goto Github PK

• internal library functions do not use delegatecall and if the type is a value type, it does not even use memory.

I have gone through your idea implemented in EventStorage.sol and found that you rely on blockhash()

In other words you assume that blockhash() will always return a correct value for any correct block number. But at the same moment I can read in Solidity documentation that

The block hashes are not available for all blocks for scalability reasons.
You can only access the hashes of the most recent 256 blocks, all other values will be zero.

(https://solidity.readthedocs.io/en/v0.4.24/units-and-global-variables.html#block-and-transaction-properties)

So, judging on this your code will work only if the block we are referring has the number greater than (N-256) where N is the current block number. Is it known limitation or Solidity documentation is obsoleted?

Hey, I've noticed the 100**0 thing as well. Do you know what solidity code (and compiler) creates it?

Was running into this error when I was passing in data into storeBytes

Uncaught Error: Number can only safely store up to 53 bits

Ran into this issue.
trufflesuite/truffle#405

I see that the issue is that you have bytes indexed data. Were you able to get around this problem?

I'm trying to better understand event logs in ethereum and their usage with bloom filters. Everything I read about event logs indicates that the very first topic should be the hash of the event signature keccak256(keccak256(DataStored(bytes,bytes)))

However in EventStorage.sol the first topic is the hash of the address of the contract that the event originated from, in this case EventStorage (

Exerpt from solidity docs:

Up to three parameters can receive the attribute indexed which will cause the respective arguments to be searched for: It is possible to filter for specific values of indexed arguments in the user interface.

If arrays (including string and bytes) are used as indexed arguments, the Keccak-256 hash of it is stored as topic instead.

The hash of the signature of the event is one of the topics except if you declared the event with anonymous specifier. This means that it is not possible to filter for specific anonymous events by name.

As I mentioned in the beginning of the issue, everything I read indicates that the first topic should be the hash of the event signature:
https://ethereum.stackexchange.com/questions/12950/what-are-event-topics
https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e
https://ethereum.stackexchange.com/questions/25006/does-the-address-of-an-event-get-automatically-indexed?rq=1

But as is evident by EventStorage.sol this is not the case (I believe event log records in etherscan indicate this as well)