Instant Classic - a showerthought / proposal

Do you think an 'Instant Classic' version could lead to a survivable hard fork?

  • yes

  • no

  • unsure


Results are only viewable after voting.

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
Showerthought I had on Saturday:
  • a version of Classic 1.x without the voting mechanisms, just hard-set to 2MB (no built-in flag day / block height)
  • miners announce they will run Classic or a compatible 2MB on day X where X is in the near future (e.g. end of August, i.e. reasonable grace period for rest of network)
  • release it as 'Instant Classic', with soft-block limit <= 1MB of course
  • this would find good support and see a lot of people switch to Instant Classic
I think it would be a terrific name for a HF solution which could be agreed to by the miners and Classic and could finally lead to bigger blocks and break the deadlock.

Anyway, just an idea, and opening the discussion here since the GCBU thread is currently (permanently?) CLOSED.

a47856ea0d52ca576509830d6a7b9b496f07b5a921604c7e97b23b5f88493060
 

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
Agreed. This could probably be bumped to 4MB with some minor testing around sigops. That should significantly extend the range, though it would still be a can kick.
 

Bagatell

Active Member
Aug 28, 2015
728
1,191
It's the governance that needs fixing not the blocksize limit. Any fixed sized limit will sooner or later bring us back to where we are today.
 
  • Like
Reactions: 79b79aa8

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
If this is the route that you want to go down, why not just go the whole way and remove Blocksize from the consensus layer altogether? Spam be dammed.
 

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
@Bagatell: That's exactly why I think it would be a way better idea to have a transition to Classic (driven by the miners, if that's their decision) than another round of endless stalling talks with only a measly 1.8MB SWSF as a result.

@lunar: Although I agree with the long-term goal of removing the block size limit entirely, I see two reasons why I think this may not be practical right now:
  1. More work to linearize scaling tx signature verification should be done, i.e. what SW should have brought as a side benefit. If that's missing, then the "totally unlimited" (well, except for technical limits due to protocol field sizes) seems a little reckless. I realize that there may be emergent properties of the system which could offset these risks, but I'm not sure we should proceed without further hard data on how the system would behave under attack if scaled like this.

  2. I don't think many people fully grasp the BU concept yet, and what they don't understand they will fear, i.e. not accept such a solution. Gradual scaling toward removal of the limit seems a more acceptable / comprehensible way forward. It would take some clear statements from the big miners to the contrary to prove they've understood and are fine with this way. Currently they seem to be still struggling to indicate clear support for 2MB :-/
 

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
Is there anyway to increase the priority of a minimum fee?

I realise there would always be ways around this from the transaction broadcast side, but If nodes simply didn't relay anything that had fee less than say 0.001cent (w.r.t the price of say gold) we could have a sort of dynamic soft limit on minimum fee as a replacement to blocksize?