SpendingCondition: use ripemd160(length, sha3(bytecode)) instead of just using ripemd160

[pinkiebell]

Bounty

leap-node should use ripemd160(length, sha3(bytecode)) for spencon¹ addresses

Scope

• update checkSpendingCondition

Deliverables

• updated code
• updated unit tests

Gain for the project

Publicly visible delivery

Roles

bounty worker: name / 50%
bounty reviewer: name / 50% (security related)

---

¹ — Spending Condition

[troggy]

related? leapdao/leap-core@832f255#diff-e652b5ccb2708f628a9de325cf105fb7R262

[pinkiebell]

related? leapdao/leap-core@832f255#diff-e652b5ccb2708f628a9de325cf105fb7R262

Yes, related. But we still need to do the same for the addressing scheme.
@johannbarbie
This one slipped through :/

[pinkiebell]

One proposal after all the madness today, and that I discovered that the solidity abi encoder doesn't hash the length of a dynamic bytes array:
better use ripemd160(sha3(sha3(length), sha3(bytecode)))

@johannbarbie What do you think? :)

[johannbarbie]

in general not a bad idea.
why notripemd160(uint256 length, keccak256(bytecode))?

[johannbarbie]

ideally we would use ripemd160(uint256 length, bytecodeMerkleRoot), so that solEVM can use the value and can be fed with compact proofs.

[troggy]

@johannbarbie I guess we should do it the right way before the migration, otherwise it would be a breaking change later, right?

[pinkiebell]

ideally we would use ripemd160(uint256 length, bytecodeMerkleRoot), so that solEVM can use the value and can be fed with compact proofs.

ripemd160(keccak256(uint256 length, bytecodeMerkleRoot)) 😄

just a joke. that's ok

[troggy]

bytecodeMerkleRoot = merkleized array of opcodes? Do you have a code for it in solEVM already which could be reused? nevermind, we have merkleTree implementation in leap-core

[johannbarbie]

Do you have a code for it in solEVM already which could be reused?

nope, but @peara working on it here: leapdao/solEVM-enforcer#117

[troggy]

ah, I see it should be exactly the same as in solEVM

[troggy]

@johannbarbie @pinkiebell can someone point me out why we need length in here just to produce hash?

[pinkiebell]

@troggy This helps us securing the validation of proofs. If we know the length, we know the tree depth and therefore an attacker won't be able to send us bogus-length proofs for a 'theoretical' birthday attack

[troggy]

forgive me my ignorance, can you explain how this hash will be used later on? What do you mean by "If we know the length" in the context of this issue?

[pinkiebell]

@troggy
Ah sorry, I was deep into solEVM territory, assume we want to validate the correctness for a given opcode(s) to be used in the verification game by using merkle proofs.
We gain more security by knowing the length of the bytecode of the contract and can therefore calculate the tree depth for the contract's bytecode merkle tree to enforce a strict size on the number proofs to be used/needed to validate the submission.

[troggy]

From the Ops Tactical:

decided to go with ripemd160(length, sha3(bytecode)) here and create another spending condition type once leapdao/solEVM-enforcer#117 is done