Currently the slot for each new coin is determined by an incrementing ID which is the number of coins numCoins. This can be replaced by keccak256(numCoins) to enforce sparseness on the coin slots. We can additionally add a contractAddress field and the deposited coin's owner (i.e. the original owner) coinOwner in the hash calculation in order to support coin deposits from multiple contracts
We truncate all hashes to tree_depth-bits, 64-bits. As per Joseph Poon's comment, if a collision is found during slot creation we can recalculate it slightly mutated, e.g. via an incrementing nonce.
calculateCoinSlot(uint64 numCoins, address coinAddress, address coinOwner, uint nonce)
uint64 slot = calculateCoinSlot(uint64 numCoins, address coinAddress, address coinOwner, uint nonce)
while slot exists --> calculateCoinSlot with incremented nonce.
It is to be expected that the increased gas costs won't be significant from the recalculation process.
aupiff
commented
6 years ago
Currently the slot for each new coin is determined by an incrementing ID which is the number of coins
numCoins. This can be replaced bykeccak256(numCoins)to enforce sparseness on the coin slots. We can additionally add acontractAddressfield and the deposited coin's owner (i.e. the original owner)coinOwnerin the hash calculation in order to support coin deposits from multiple contractsWe truncate all hashes to tree_depth-bits, 64-bits. As per Joseph Poon's comment, if a collision is found during slot creation we can recalculate it slightly mutated, e.g. via an incrementing nonce.
calculateCoinSlot(uint64 numCoins, address coinAddress, address coinOwner, uint nonce)It is to be expected that the increased gas costs won't be significant from the recalculation process.