Ideally, for SPV nodes to help with verification, verification steps should be compartmentalized.
Etotheipi
suggested adding the value of the inputs into the transaction.
It occurred to me that with the proposed OP_MAST system, you could include everything necessary to verify the transaction in the transaction itself.
It would increase the size of the transaction, but keeps it entirely local.
Some information would be included in both the scriptPubKey and the scriptSig.
scriptPubKey: <input value> <hash of sigScript> OP_MAST
scriptSig: <serialized sigPubKey> <merkle pruned sigScript> <input value> <hash of sigScript>
OP_MAST would check that both input values are the same, and match each other and similarly that the <hash of sigScript> matches the provided <merkle pruned sigScript>. It would then verify that the serialized public key can spend the provided pruned sig script.
Once in place, a P2SH like-rule could be added that all transactions must conform to this format to be included in blocks after <some block>. Blocks up to that point would be assumed to be well checked.
To spend transactions from before the point, the format could be
scriptSig: <input value> <serialized scriptPubKey> <inputs as normal>
This assumes that spending of all current sigPubKeys would not be affected by pushing 2 items on to the stack before the standard spend?
This means that a transaction can be internally checked. The SPV node can request a random block and then check a portion of it. By asking for a range, it should not put to much load on hard drive of the other node. Asking for 1024 random transactions would be slower than asking for 1024 transactions starting from transaction 7 in block 123456. In addition, asking for transactions in sequence makes checking the merkle links more efficient.
It can check that the outputs add up to less than or equal the inputs. It can check all the signatures are valid, since it has the <hash of sigScript> in the sigScript. This would be CPU intensive, since it is checking the ECDSA but not so hard on the bandwidth.
Next there should be a reverse lookup system for the database. For each transaction in a block, you store the inputs into that transaction and their merkle path as part of the block.
To prevent overload, it would be worth adding a limit to the size allowed. For example, a transaction with 10 inputs would need to store 11 times as much data to store, since it has to store the transaction and all the input transactions.
This could directly limit the number of inputs in a block. However, it might be better to limit the expanded block size directly (expanded block size must be less than 16X the block size). That itself needs to be verified, so a sum tree is required.
This sum tree could have a root in the coinbase extra nonce could also do inflation checking.
32 bytes in the extra nonce could be added for as the root of an (expandable) set of tree roots.
0: Sum of fees (inflation check)
1: Sum of tx sizes (verify the blocks are less than the allowed)
2: Sum of expanded tx sizes (verify that the expanded block size is allowed)
3: Reserved
3 can then be used as the root for a another set of 3 trees + a reserved tree.
