Addressing security issues with a January hardfork?

[arvicco]

The latest round of attacks against ETH unearthed a number of possible attack vectors against the network. Some of them may be fixed/patched and thus mitigated, but a hard fork is required for a permanent solution, as discussed here:
ethereum/EIPs#150

My question is, should we strive to include such fix in a January hardfork, while we are at it? Would be interested in your perspective.

@whatisgravity @splix @igetgames @elaineo @mikeyb @ericsomdahl @avtarsehra @realcodywburns

[elaineo]

I'm not a huge fan of the strategy that's being used there -- guessing at numbers for gas costs and seeing what happens. If the guesses are bad, we have to HF again. Surely we can come up with a better strategy? (Probably not in time for January though.)

Is it sufficient to set default geth gas limit lower?

[trustfarm-dev]

@elaineo
I think make one time trasfer gas fee to low.
But, In case of multiple contract loop , eg

1. for (1 ; xxx ; many) or while (many--)
2. recursefunc() {
   recursefunc()
   }

• like 1,2 case of codes, gas fee must increase multiple ratio and exponentially, when branch call or goto call, prevent DDOS contract attacks.

It needs more complicated approach, I think.

Recent days of ETH, there's several DDOS Attack vectors, so, most of geth and parity has big difficulties making blocks. theres' many Orphans blocks.