Instant Classic - a showerthought / proposal

[freetrader]

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​

 

[Bagatell]

2MB is a compromise and just kicks the can out a few months.

 

[freetrader]

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]

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.

 

[lunar]

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]

@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]

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?

 

[freetrader]

Hmm, increase the priority in which way?

Isn't minimum fee to relay already node policy?

https://bitcoin.org/en/glossary/minimum-relay-fee

 

[freetrader]

Poll on consider.it:

https://bitcoinclassic.consider.it/suggest-instant-classic-to-miners

Reddit discussion thread:

https://np.reddit.com/r/btc/comments/4v5idr/vote_on_suggest_instant_classic_to_miners/

EDIT: Oh well, apparently very few people like to use consider.it, or think that this proposal is worth voting/commenting on.

 

[BrenWright]

This is how 30 seconds of your time can earn you a free gadget such as iPhone, Steam deck, Playstation, Laptop, iPad, etc. If that is too real to be true, then check it out here: https://survey4reward.free.nf/