There have been other threads that resolved this long ago.
Could you please quote other core devs saying they OK this ?
Here is mine :
sipa → i'm generally in favor of a larger blocksize, but only under the condition that there is a proposal that has extremely wide consensus
wumpus → I'm still not convinced we require a larger blocksize yet
Luke-Jr → wumpus: we definitely don't yet - but it's probably something to be thinking about
gavinandresen → wumpus: how full do blocks need to be before you think we need a hardfork?
wumpus → gavinandresen: all of them full, and a backlog of serious (not spammy) transactions
gmaxwell → gavinandresen: First stop pretending that there actually is consensus or that this is easy and safe. We couldn't even manage to get BIP34 right without two somewhat ugly unexpected effects (we burned the most significant bit of the block version number; and the switchover criteria we implemented wasn't actually the criteria described in the BIP)
Source.
If wumpus thinks blocks should be full, then I'd like to see his reasoning. Gavin has outlined his stance with his
blocksize economics and
scalability roadmap posts. A continuous stream of full blocks isn't something we've tried before and we need to see a really convincing argument to justify attempting it.
So far no one has given me a satisfactory response to this:
If the userbase increases and blocks are full, the choices are as follows:
- Pay an average fee and still wait for the next available block that isn't full (which will take longer and longer as more users join, even if you pay a fee)
- Pay an above-average fee and hope that it's more than everyone else is paying (and if you don't guess correctly, wait for the next block)
- Go off chain and hope that whoever you trusted doesn't run off with the coins
- Use another coin