"dev mode" properties of chain forks

[nmushegian]

Certain "mock blocks" can only be extended by blocks with the same or looser validation rules. On slack we discussed this as a single "dev mode". Not sure if it makes sense to group them all together, since there would still be a class of scenarios we couldn't test.

brainstorming some examples of "alternative validation rules" for mocking:

• To mock tx.origin, the fork should be put in a mode where the signature is interpreted as a raw address if it doesn't validate otherwise.
• To mock alternative transaction history, block header validation can be disabled

[mhhf]

Do we want to mock tx.origin do this implicit or explicit?
Currently this woks explicit by calling dapplechain.addFakedOwnership(<address>) from which point on transactions from <address> are accepted. But <other_address> are rejected if no private key is know. This could be accessed with an interface like dapple chain fake <address>

I can do this in an implicit style where every transaction is accepted.

The dev-mode flag is is written if at least one faked transaction gets included.

[nmushegian]

What do you mean "are accepted"? What does the ORIGIN opcode return?

[mhhf]

tx.origin returns whatever address you place in the from field of the eth_sendTransaction call. E.g.
calling the contract:

import "dapple/test.sol";

contract TO is Test {
  function testOrigin() {
    //@log `address tx.origin`
  }
}

with web3.eth.defaultAccount = '0x0000000000000000000000000000000000000000';
yields:

$ dapple test --report
Testing...

TO
  test origin
  LOG:  0x0000000000000000000000000000000000000000
  Passed!


Summary
  Passed all 1 tests!

However first i had to make sure the address 0x0000000000000000000000000000000000000000 has enough funds to execute the call and also including it to the known faked address set:
dapplechain.addFakedOwnership('0x0000000000000000000000000000000000000000');

However, this last extra step can be also done implicit by just including each transaction origin address, for which no private key is known. Just wondering which approach is better.

[nmushegian]

I think in the actual transaction, the address is always recovered from the signature (there is no "from"). Gav suggested passing the raw signature as the address when it looked like one (eg has enough leading zeros or a magic value). I think your solution is fine.