Please check the status of the natspec project. https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format

In case minimal funding is not reached we need some code to refund users.
Firstly, check how Singularity has done it.
If no better ideas, there must be a function user can trigger what will send him the ethers back. We can reuse function() for user-friendliness.

cap: 820k ETH
min: 150k ETH

The following action must be performed after the funding has ended:

• unlock transfer,
• generate endowment,
• transfer ethers to Founder.

Variant 1

1. Auto unlock transfer after the funding has ended.
2. Allow the Founder to generate the endowment single time.
3. Allow the Founder to transfer ethers from the Token contract unlimited number of times.

Pros:

• current implementation,
• independent actions,

Cons:

• the endowment is generated when the transfer is already unlocked,
• implementing crowdfunding logic in a separated contract hard or not possible.

Variant 2

Allow the Founder to perform a single transaction that will unlock transfer and generate the endowment and transfer ethers from the Token.

Pros

• the endowment is generated when the transfer is locked,

Cons

• the Founder can delay (or block) the transfer unlocking, however has big incentive not to do it (ethers).

Variant 3

Allow anyone to perform a single transaction that will unlock transfer and generate the endowment and transfer ethers from the Token to the Founder.

Pros

• the endowment is generated when the transfer is locked,

Cons

• the Founder must be ready to receive the ethers before the funding ends.

That means:

• you cannot deploy Crowdfunding contract,
• you don't have control over GNT and e.g. cannot start migration.

It might be Ethereum Wallet UI issue only.

If Token.decimals is uint8 how can it fit 10^18?

Check gas costs for every function according to recent hard fork.

Require all sources to be compiled with solidity 0.4.3 (bugfix release).

All should be non-zero. End block > start block > current block.
And add unit test for that.

For external reviewers it must be very misleading to see a lots of contracts in contracts/ directory. We should separate the ones used only for tests.

Someone pointed me at your repository noting that the tests are written in python. I was curious if your team knew about populus which might take some of the overhead out of your testing setup?

The EIP160 changes EXP gas costs from 10 + 10 per byte of exponent to 10 + 50 per byte of exponent. As this comes in the next HF we should run our tests with these changed gas costs. Especially .send must be tested carefully as it sends only 2300 units of gas.

I think the simplest way is to hack pyethereum, because these changes are not going to be released on time.

Write down all preconditions (depending on params and data) for all function to search for patterns and to name them.

• Try to send ether to the Crowdfunding contract not through function().
• Send ether to the Crowdfunding with random data.
• Send random data to the Crowdfunding.

Looking at allocation of tokens to devs. Gas limit could be problem if attacks persist. Ideally contract is < 500k gas to deploy and execute. (And/or can be executed in stages)

The Multisig Wallet contract deployed from Ethereum Wallet is produced by solidity 0.3.2 and without optimizations (according to etherscan.io https://testnet.etherscan.io/address/0xb53A1e14E3fF4A617D2C09291fc8054e26F6EEF4#code). Verify that and check if we can do anything about it.

Scenario is as following: a lot of small transactions is made from different accounts, blowing up size of balances array. Can this affect other funders?

I see three possibilities.

a) gas cost of creating one more entry in balances is not a constant function of size(balances).
b) gas cost is constant, but work is not constant and this operation can be used to spam network
c) no worries, ETH has withered more complicated attacks

Test actual values and bounds of the code greater than what will actually occur. Gas-bound purchaser limit is test which maximizes purchases based on gas-limit during CF phase, ex: blockPeriod*4500000/purchaseGasCost

Can be the Transfer to 0.

The distribution is below. Because we will need a lot of static data for that I suggest to implement endowment (including params and for the Factory as well) in a separated function.

25
7.3
7.3
7.3
7.3
7.3
6.3
6.3
6.3
6.3
3.1
1.5
1.5
1
1
1
0.7
0.7
0.7
0.7
0.7
0.4
0.3

By HKG example https://etherscan.io/address/0xb582baaf5e749d6aa98a22355a9d08b4c4d013c8, there are a lot of failed transaction probably because users assigned not enought gas for their transactions. Check what is default value in wallets and check if your function fits in.

• Check if Ethereum Wallet requires this part of ERC20 token interface.
• Check how Raiden / state channels use it and how it should be implemented.

See also #19.

Are we susceptible to chain replay attack?

ETH/ETC chain replay does not affect us since contract will be deployed only on one chain.

Can planned hard fork affect us? I think it's perfectly benign and created chain will not have any value whatsoever.

For formal verification is it suggested to try https://github.com/ethereum/oyente.

What will happen if attacker will attempt to bump into stack depth limit while being in our code?

Scenario:
StackLimit = N

def stack_filler(X):
   if X < N:
     stack_filler(X+1)
   else:
     GolemNetworkToken.send(1000)

Will EVM just do what it does when throw or "out of gas" occurs and restore original state?

Source of inspiration: https://www.kingoftheether.com/contract-safety-checklist.html

Form: things that can be automated are preferred in automated form.

We need to lock ability to the crowdfunding agent to change its payout address. But we probably want to allow migration agent to change its address in case of the first one is compromised.

Solutions:

1. Separate addresses.
2. Lock changeCrowdundingAgent() during funding.

The 1. is better if we want to cleanup funding data after the funding. Do we?

Populus does not support solidity 0.4 yet (work in progress). Try to help with that.

When deploying the Crowdfunding contract from Ethereum Wallet:

• it cannot be done using bytecode,
• using solidity source code is compiled by builtin solc, but the result contract cannot be verified on etherscan.io.

Test insufficient gas and extra gas all calls, especially refund and migration

Even if it is purely theorical and requires a huge amount of ETH, the function() code should check for overflow before the addition and multiplication.