After the soft fork, all accounts whose ultimate CREATE ancestor is 0xbb9bc244d798123fde783fcc1c72d3bb8c189413 are enumerated into a list L.
At some block #TBD:
All ether throughout all accounts in L will be transferred to 0xbb9bc244d798123fde783fcc1c72d3bb8c189413.
The code for 0xbb9bc244d798123fde783fcc1c72d3bb8c189413 will be replaced by a simple contract with only a single (default) function. When called, this returns an amount of ether proportional to the DAO tokens held by that sender in both the main DAO and in all (statically enumerated) child DAOs.
At #1,760,000 If block gas limit < 4,000,000 then:
From this block and all blocks later, blocks MAY NOT CONTAIN any transaction which satisfies the constraint: Ultimately results in the reduction of the balance of at least one account whose code hash is 6a5d24750f78441e56fec050dc52fe8e911976485b7472faac7464a176a67caa.
ppratscher @ppratscher: Is there any activitation threshold built into the soft-fork logic so that miners do not accidentally end up on a wrong chain? e.g. if 950 out of the last 1000 blocks where mined by miners who support the fork then the logic gets activated?
Gav Wood @gavofyork: yes - <=4m gas limit will enable the fork
anything higher and it won't trigger
@ppratscher: how does the gas limit relate to the comitment of a miner to support the fork?
and is this parity only or does it also apply for geth?
@gavofyork: just being used as a proxy
there's a general agreement (i.e. vitalik suggested and nobody had a problem with it) that it should be used as a signal.
@ppratscher: what was the rationale behind not implementing a proper signaling on block level? this solution sounds quite hacky to me
e.g. a block version flag similar to bitcoins?
@gavofyork: expediency.
i guess we can do a better job when metropolis comes around.
@ppratscher: because right now there is a very high probability as a miner to end up on the wrong chain
@gavofyork: there isn't really a wrong chain for a soft fork
and given uncle rewards are so high and the chance of a bad transaction being included so low, miners will lose little if nothing regardless whether they enable soft-fork or not.
assuming the soft-fork is approved, the only time they'll lose their 5ETH is when a non-soft-fork enabled miner mines on a block that itself contains an invalid transaction
however, that's rather unlikely, especially so if the soft-fork majority is large.
and practically-speaking, gas limit will either be 3.1m or 4.7m - it will be very clear whether the soft-fork is approved.
though you're right - it's a hack
@ppratscher: mhm, I am more worried about a 50:50 situation where half of the network decides to go with the soft fork and the other half does not
@gavofyork: well, the chance of that is pretty small.
but if it's close and majority soft-fork, then die-hard hard-fork miners (i.e. those who use --dogmatic or don't upgrade) stand to lose a little in their rewards from blocks built on those with bad transactions that can't be used as uncles
no other circumstances lead to any loss in reward payments.
@ppratscher: ok, thx for the explanation, do you plan to publish this facts somehow? I am not sure that miners are perfectly aware of that implications