Topic: New Client Proposal: Bitcoin Core++ (Read 1338 times)

The original Bitcoin Core client is mainly neutral.  They do not wish to force anything on anybody even if it is in the best interest for the entire group.  For example, Bitcoin Core Segwit activation requires 95% of hashing power.  The 5% remaining of hashing power can block this activation.  In general core developers in conjunction with the community support this conservative stance of pushing for 95% super majority for soft forks.

The purpose of Bitcoin Core++ is to promote the work of core developers by being less conservative so it can continually advance and technically promote protocol efficiency and usage.  

I may sit down and put more thought into this so we can define what exactly is the purpose of BC++ with support from the community.

Why not ignore BU-blocks only as long as there is no regular block on top of it?

That would increase the chance of a BU-block to get orphaned by slowing down its propagation on the network, but it will not cause are fork.

Just curious, what's the purpose of the client?

I am thinking any protocol changes would be unacceptable for BC++ because of the potential of an alt-coin fork.  Features for BC++ would have to focus on things like limiting the network effect of BU.  I would say that any limitation would have to be passive in that BC++ does not intend to attack other clients.  BC++ would not allow BU to use the resources of BC++.  Limiting/dropping network connections to BU would be a primary example.  I would also like to explore this and know if this has any ramifications for the bitcoin network.

Another idea for BC++ is to turn on the right signaling flags as standard instead of letting others turning on the flags manually.

While the ignoring blocks idea might be dead on arrival, I wouldn't mind gaining a better understanding of the effects of the other idea raised:


If BC++ was in theory a one way system, so it still accepted all the blocks produced but didn't relay transactions to Unlimited clients, what impact might this actually have given sufficient adoption?  Could this also potentially result in a fork?  Or would it just create gaps in node coverage and cause hindrance to Unlimited users to get their transaction relayed if they couldn't see enough "accepting" peers?   




As I've been making the case quite a bit in recent threads lately, its an open market, so I don't think we should shy away from such conversations.  We could certainly handle them better in future, though.  Anything that could potentially lead to a stronger and more resilient system should at least be considered and discussed, even if it means questioning the path we're currently on.  Alternative clients do have their uses in terms of checks and balances.  Increasingly, I believe them to be crucial to a robust system where we don't just blindly accept what's laid out in front of us.  Always challenge the status quo.

People converging into one client that satisfies most is the key of what we want. Another clients would only add to the confusion, I think, for reasons already listed. Threads about "client X vs client Y" would emerge again...

I think this is the opposite of what we want with Bitcoin.

Yep.  This is the problem with your idea.

Unless an overwhelming majority of miners choose to use your software, all you'll do is create a useless fork of the blockchain.  All the users, miners, and merchants that aren't using your software will be on a fork that sees confirmations, and generates blocks rewards with value.  Miners using your software won't be able to spend any of their block rewards anywhere, since those block rewards won't be recognized on the main chain that everyone else is using.  Therefore, the block rewards that miners on your software earn will be effectively worthless.

Why would a miner spend all their hash power generating block rewards that they can't spend?  Sounds like a huge financial incentive for your software to fail.

If your idea worked and you're ignoring all the blocks found by Unlimited pools, all that would achieve is that anyone who had a transaction in those blocks gets their transaction delayed.  Remember that users don't get a choice over which pool secures their transaction in the blockchain.  It's whoever finds the block first. 

The other thing you might not have thought through is that BC++ would then find itself forking onto a completely different chain.  Because both Core and Unlimited will still recognise those blocks BC++ is ignoring.  BC++ would effectively become an altcoin unless it follows the longest chain that all the other clients agree on.  To follow the longest chain, you can't start ignoring blocks at random.

I am proposing a new bitcoin client called Bitcoin Core++ (BC++).  It's a bitcoin client that advocates for the success of Bitcoin Core.  What makes this client different?  The original Bitcoin Core client is mainly neutral.  They do not wish to force anything on anybody even if it is in the best interest for the entire group.  For example, Bitcoin Core Segwit activation requires 95% of hashing power.  The 5% remaining of hashing power can block this activation.  In general core developers in conjunction with the community support this conservative stance of pushing for 95% super majority for soft forks.  The purpose of Bitcoin Core++, however, is to promote the work of core developers by being less conservative so it can continually advance and technically promote protocol efficiency and usage, and to disregard politics.  Decisions will lean to be technical instead of political.

For example, Bitcoin Core++ may block clients attempting to subvert the core protocol.  For example, if a Bitcoin Unlimited client mines a block or relays a block then BC++ will ignore it.  BC++ will also not allow BU clients to connect to itself.  If you have any other suggestions then please post in this thread.  Or, if you have any technical ideas or issues then let us know.

I am looking for volunteers to help create this new client including programmers, web developers, and online marketers.