Poll: What is the best course of action if Classic does not activate

[rocks]

If Classic does not activate due to a few miners acting as holdouts, but a large majority of users and Bitcoin companies demand 2MB blocks, what is the best course of action for the community to take?

Explanation of the options:

Do nothing :
Accept the miner vote and limit Bitcoin to 1MB

Promote Classic :
Have the user community more positively engage with miners and explain the reasons for Classic to try and convince more to join and activate the fork.

Hard fork with Classic miners :
This option sets a fixed activation block number where users who demand 2MB blocks will automatically fork. This can be done even with <50% of miners behind the fork. The mechanism would be to post-fork ONLY accept blocks >1MB and <2MB. If there are not enough transactions in the mempool to create >1MB blocks, miners would have to add extra data to the block to pad it to >1MB. In this manner even if just 10% of miners followed the fork, the fork would effectively branch and the user base would have an active chain with >1MB blocks.

Hard fork with new miners :
Similar to the option above, but with the addition of changing the PoW algorithm to a CPU-only algorithm (there are options here). This would save from having to pad blocks to be >1MB since the new PoW would create a new set of miners where 100% already accept >1MB blocks.


These are difficult options, but if a clear economic majority of a ~$5B ecosystem want to scale Bitcoin, but the current actors do not follow market preferences there needsto be available options for the market to follow Satoshi's vision.

 

[Erdogan]

Someone daring should just make a large block, and hope that enough miners build on it, possibly with a small block.

 

[cypherdoc]

Wait for the Chinese miners to hard fork their own version of 2mb which they've already said they'd do.

 

[steffen]

Someone daring should just make a large block, and hope that enough miners build on it, possibly with a small block.

What will a mining pool running a default Bitcoin Classic do with that block?
A. Ignore it because the 75% threshold has not (yet) been met or
B. Accept it

If the answer is A then there is very little chance the large block will be accepted by a majority of hashing power in the network. If the answer is B then it could be a good way to do a quick hard fork.

If A is the answer the next way to attempt a hard fork could be to modify Bitcoin Classic so that the answer would be B after block number something.

 

[Erdogan]

What will a mining pool running a default Bitcoin Classic do with that block?
A. Ignore it because the 75% threshold has not (yet) been met or
B. Accept it

If the answer is A then there is very little chance the large block will be accepted by a majority of hashing power in the network. If the answer is B then it could be a good way to do a quick hard fork.

If A is the answer the next way to attempt a hard fork could be to modify Bitcoin Classic so that the answer would be B after block number something.

Agreed, but the sensible thing to do first, for any miner, is to accept and build on any large block, and later, mine large blocks.

So it is about sensing, using all available information channels, the risk of orphaning. Someone has to be first.

And there is a prize for producing a large block, orphaned or not, currently of 0.25 BTC.

https://bitco.in/forum/threads/badass-big-block-bounty-the-great-blocksize-war-of-2016-the-peoples-offensive-100001-season-i-fun.817/#post-10536

 

[cypherdoc]

If miners have upgraded to Classic with the 2mb limit, the software will automatically accept blocks over 1mb immediately. Other miners will just accept them as standard and start building upon them.

 

[Erdogan]

^
Great, I didn't know. That is what we want.

 

[Zangelbert Bingledack]

Since empty blocks are a critical defense as per @theZerg's paper, isn't there a way to change some other kind of block setting to force a fork without all blocks having to be >1MB?

Also, without an activation threshold, a futures market would be ideal for determining support in advance for this.

 

[sgbett]

What will a mining pool running a default Bitcoin Classic do with that block?
A. Ignore it because the 75% threshold has not (yet) been met or
B. Accept it

If the answer is A then there is very little chance the large block will be accepted by a majority of hashing power in the network. If the answer is B then it could be a good way to do a quick hard fork.

If A is the answer the next way to attempt a hard fork could be to modify Bitcoin Classic so that the answer would be B after block number something.

Im only a non mining node(s), but I'm running BU for exactly this reason. If someone out there mines a bigger block I'm happy to pass it on...

 

[Richy_T]

Yep. If Classic doesn't activate, people should move to BU to signal willingness to accept big blocks anyway and wait for the miners to sort things out.

Of course, they should probably be running BU anyway but I understand the impetus to show support.

 

[Melbustus]

If Classic doesn't activate, I think we may be in the unfortunate position of waiting for the mining ecosystem to mature. Classic's failure would indicate that the current set of miners is neither sophisticated enough nor proactive enough to act in their own long-term best interests, and Bitcoin will essentially remain an unstable experiment with an indeterminate outcome until things change in the mining ecosystem.

I think that change will necessarily occur when we move on from this phase where power-cost is everything. At some point, miners will vertically integrate services, and/or things will otherwise mature such that a moderate power-cost advantage is not *the* dominate force in mining profitability. And I think that that will almost necessarily mean that miners will be *forced* to be a lot more sophisticated in their outlook and innovation, and will consequently ramp up how proactive they are in the ecosystem in general. Having a huge % of represented hashrate say "eh, we'll do whatever Blockstream says", will just not be an option for them any more. Hopefully Bitcoin's network effect will still be sufficiently intact at that point.

If we can get to a rational mining ecosystem sooner, all the better, as it de-risks the long-term tremendously. Bitcoin is going to be held back, both in price and adoption numbers, until we get clarity that the system will continue to advance such that it remains cheap, fast, global, p2p cash.

 

[freetrader]

@rocks: TBH I think your poll is missing an option which is not exactly Do-Nothing but also not covered by the others:

[ ] Vote with your Ƀ - move enough holdings out of Bitcoin into other currencies to effect a price signal to miners

To me this still seems a more benign course of action than the listed hard fork options, which could be resorted to eventually. It is a screw which can be turned to the required torque.

I am not able to vote directly for any of the other options before trying this economic one.

 

[Peter Tschipper]

The miners can hard fork anytime they want...they don't need core to make a version for them. When/if they are on the precipice they will have to act in co-ordination with each other. So for us, I think the best thing is to not get discouraged with the ups/downs of Classic and instead get BU v12 out there so that the network is ready to handle bigger blocks. And of course continue to develop the options and enhancements that node operators want to see. Developing good software will give us solid support over time and win over the miners who are rightfully conservative.

 

[solex]

@Peter Tschipper
You mentioned that Xtreme thinblocks can form its own kind of relay network.

The existing RN only has 6 nodes.
Is competing with it as simple as getting a bunch of nodes running BU within the Chinese GFW?
If BU had 100 nodes all with Xthin and some were within the GFW, and some in HK or TW with good connections, can we trumpet that the RN is superseded and call for miners to use it?

 

[Peter Tschipper]

@solex Well, I wouldn't trumpet anything just yet before we actually did a benchmark comparison. I'm very curious to see how xthins (in it's present state) compares with RN. I've looked a little at the RN code and I raised my eyebrows a little. I'd say that there is a good possibility we are already faster than RN but I wouldn't say so until we have real data. (But we are fast, no doubt, I've seen full blocks downloaded and validated in less than a second from nodes 1200 miles away on a old slow laptop)

But yes we can easily setup our own RN by using the connect-thinblock feature. However, we can also make the whole thing even faster. My own vision is for us to eventually build a "Lightning block relay" specifically for the miners, leveraging xthins but with a few extra enhancements that would be slightly less efficient bandwidth wise but faster in propagation.

Ultimately I think the miners will want to see real data and compare whatever we come up with to RN but I don't see us building Lightning Relay until we get the other scaling issues out of the way. The two that are dead ahead and I'd like to work on are are Datastream compression with enhanced tx relay, and MultiThreaded networking. For me, once those are done (if approved) I would say all the building blocks are in place for Lightning relay for miners.

 

[Richy_T]

to eventually build a "Lightning block relay"

Please don't call it that.

 

[solex]

Thanks @Peter Tschipper for the further info.
We will trumpet BU v0.12 when it is released, but I agree not to push the RN aspect until a good collection of metrics are obtained.

Agreed also further compression and multi-threading are good features.

Yeah. Lightning is probably not the best choice, too much baggage already in this space.
I have raided the thesaurus for some alternatives...is "firebolt" a flier?

• flat out
• headlong
• high-speed
• breakneck
• full tilt
• dangerously fast
• excessive

• fulmination
• firebolt
• precipitate
• rapid

• reckless
• speedy
• whirlwind

 

[Peter R]

• block warp drive
• block hyperdrive
• block xdrive
• block teleporter
• block transporter
  
• hyper-relay
• Xrelay
• extreme block accelerator
• block xccelerator

 

[bluemoon]

firebolt, rapid, xdrive, xrelay, hyper-relay look good to me.

Also maybe:

• tempest
• hurricane
• storm
• whizz
• mega
• quick
• enhanced
• fast
• ultra
• BU
• unlimited
• sprint
• advanced
• flash
• new

... block relays

 

[Peter Tschipper]

Ya probably a little bit of baggage there with "Lightning" and on second thought would confuse a few people too. I like the Hyper-Relay, Hyper-Relay-Network suggestion, or HRN.

Thanks for the input.