blockScrape: Some addresses are invisible to blockScrape but not getTrans and getBlock

[tjayrush]

This transaction

0xee424c7cc37bcf625b79b352123f6902df257e41fb1185a67b60d75d69842b68

is included in the transaction cache of address

0x168296bb09e24a88805cb9c33356536b980d3fc5

by the monitor code, but this command

getTrans 0xee424c7cc37bcf625b79b352123f6902df257e41fb1185a67b60d75d69842b68 --belongs 0x168296bb09e24a88805cb9c33356536b980d3fc5

returns not found.

On the other hand, this command

getTrans -v -t 0xee424c7cc37bcf625b79b352123f6902df257e41fb1185a67b60d75d69842b68 | grep 168296bb09e24a88805cb9c33356536b980d3fc5

finds the address as part of the input data field.

I think this is because the input data is not 'normally' aligned (that is, the address does not align to a 32-byte boundary in the input data).

This is weird for two reasons:

• Because we do not have a specific address to search for during blockScrape we have no way to find this type of non-aligned address during the creation of blooms,
• Only if an address appears elsewhere in a block (and therefore hits the bloom because of that appearance) will it be found for this occurrence. The same transaction with a misaligned address in a block where that address appears elsewhere will be found; whereas if that address appears no-where else in the block, it won't be found (because we ignore the block since it doesn't hit the bloom).

[tjayrush]

[COPIED FROM #749]

The input data from this transaction 4005820.123:

0x0a19b14a
0000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000004f6185b1b33c0000
000000000000000000000006810e776880c02933d47db1b9fc05908e5386b96000
00000000000000000000000000000000000000000000003782dace9d900000000
0000000000000000000000000000000000000000000000000000003e796100000
0000000000000000000000000000000000000000000000000009348f1e8000000
000000000000000000ae7a63c8543bdd1c32927a7137529b82ab9ea88f000000000
000000000000000000000000000000000000000000000000000001bc45dd58155
970f8b32fd855bda5b4960d4b44e1f2ad6d609d432799e4be8122f116e1befdf25f14d
744b6cd078e3866127fef01a3315aa172c1829911acd34f3000000000000000000000
00000000000000000000000000004f6185b1b33c000

articulates into this data

 "articulatedTx": {
    "name": "trade",
    "inputs": [
      { "name": "tokenGet", "value": "0x0000000000000000000000000000000000000000" },
      { "name": "amountGet", "value": "357500000000000000" },
      { "name": "tokenGive", "value": "0x6810e776880c02933d47db1b9fc05908e5386b96" },
      { "name": "amountGive", "value": "250000000000000000" },
      { "name": "expires", "value": "4094305" },
      { "name": "nonce", "value": "2471031272" },
      { "name": "user", "value": "0xae7a63c8543bdd1c32927a7137529b82ab9ea88f" },
      { "name": "v", "value": "27" },
      { "name": "r", "value": "c45dd58155970f8b32fd855bda5b4960d4b44e1f2ad6d609d432799e4be8122f" },
      { "name": "s", "value": "116e1befdf25f14d744b6cd078e3866127fef01a3315aa172c1829911acd34f3" },
      { "name": "amount", "value": "357500000000000000" }
    ]
  },

which is easy to do if QB has an ABI file for the to address. During the creation of the blooms and transaction index, we do not (and cannot) have the ABIs (although see below). If we have the ABIs, we can easily see which parts of the input data (and each log's data data), so we can parse them. Without the ABIs, we need to use heuristics.

When building enhanced blooms and transaction per address indexes, we want to include potential addresses found in the input data of the transaction/trace or the data field of logs such as the example below from transaction 4005820.123.

An address can start anywhere in the string of bytes represented by input or data (hereinafter called simply data). For example, for function calls the eight bytes (do you know the eight bytes) are followed by a string of bytes.

Normally, we can pull each 32-byte chunk of data and pretty easily see if it's an address (12 leading zeros, greater than the largest imaginable number of wei -- see below). And this finds many, many addresses in the input data.

But sometimes, the data is aligned differently (for example a function such as func(bytes4 x, address a) will have the address aligned off the 32-byte boundaries).

This code is the code that searches these input data fields and tries to identify potential addresses which is the best we can do.