Topic: Between two extremes, but not quite in the middle (Read 538 times)

+++

Nice write up you came up with and I do share your take about Bitcoin being well able to ward off its handful of enemies from without, but helpless about the infighting that is fast snowballing into a civil war as you said. The looks of things is far from suggesting that a compromise between the two extremes - Core and Unlimited, is in the air. We are more likely to have a split except something new and interesting happens. All the same, standing between two extremes, but not quite in the middle means you have taken a stand where you belong!

Meni,

Thank you for very eloquently saying what I feel like I've been thinking for a long time.

If a compromise that looked anything like what you've described were to be put forward as the new reference client, I'd be happy to join you in trumpeting its cause and encouraging its use.  Doesn't matter to me if it was presented by Core, Unlimited, or some third party (perhaps you and I should fork the github repository and see what we can do with it).

 

atleast your admitting that people need to stop with the "gigabytes by midnight" fud

storage issues is not a problem.. 8 years of data can sit on a fingernail
secondly prunned / no witness modes has more potential to reduce the full node count. because there would be less people with full archival data to sync from.. its much like bittorrents when you kill off a majority of torrent seed with full downloads and just have a cludge of people with only 10% of a datafile being leachers

id say stop with the half gestures crap.. and do a proper full job.
-new fee priority
low txsigops that doesnt increase
1merkle to avoid the tier cludge.. and ensure peer network status
allow all features that can only be implemented in a hard consensus.

then a proper NODE and then POOL consensus.. none of this pool then UA crackpot back to front crap.

then let the pools dip their toe in the water with a 1.000250 block and see if there is any orphan risk, and grow at a safe pace the pools find acceptable which wont kill off the nodes.. much like pools didnt just jump to 1mb of spam in 2010 even with the 1mb rule.. they instead held at 0.25 and only progressed when they were happy.

once people stop reading the reddit FUD scripts to find excuses.. they can start thinking of idea's.. not excuses

only an issue if txsigops went UP
simple solution txsigops stays at 4k or actually goes DOWN

i see no reason why any single TX deserves 20% of blocksigops allowance.

plus segwit does not solve quadratics. it just allows innocent people (who dont bother quadratic spamming anyway) move funds to segwit keys to disarm themselves from performing quadratics..
thats like offering people who dont have a gun licence to let their kids go to a gun-free school. but still not have metal detectors at the school entrances to stop strangers just walking in and filling the school with bullet holes.

Meni I feel exactly the same way and wished the proponents of all alternatives would view it this way, but I fear the urgency with which all sides are making aggressive attacks on the network means they are all unwilling to listen to each other now. Both a rushed UASF and a miner driven BSFORK 2mbsegwit are clearly aggressive stances from both sides. As the dates for both activations approaches, even MORE people are choosing sides and digging in instead of considering negotiation. It is still not too late to do something about it but I see us waterskiing down a river with 2 major tributaries getting larger by the day with sharks in both of them, and only a tiny creek off to the side that doesn't have sharks which is in danger of drying out completely.

For the record, I'd prefer to see segwit activated first as well, but I also do not have a problem with a fork to a (base blocksize) 2MB increase. The quadratic scaling issue with a 2MB block will largely persist but it would take a concerted effort by a pool to maliciously create one since it is very much a non-standard transaction and they'd be potentially harming their own biosphere by doing so. The current bitcoind implementation is a lot faster at handling it than in the 25 second block era (2.5 times faster?) but it could still be a 30 second confirmation block. Whether it will crash smaller nodes with less ram is still up for question. Either way, it would be at the pool's expense and potential detriment to create such a block.

All the other disadvantages of a 2MB block I don't feel outweigh the potential increase in fee holding blockspace to pools. If the large storage and data transfer is an issue then there will be a natural attrition to the number of nodes but I doubt it will be as dramatic as the doomsayers have been saying. Pruned node capability has largely offset the storage issue - consequently one running a pruned node which won't advertise the network bit has far less connections and less data transfer as well.

So back to the discussion - how do we get people to the negotiation table if both have taken an aggressive stance and core refuses to be seen as an entity?

(Cross-post from my blog)

If you're reading this, you probably know that the Bitcoin community is amidst a civil war.

And you might also know that for almost 2 years, I've been advocating the position that if no agreement or compromise can be reached, the best course of action is to have a clean split of the network into two incompatible, competing currencies.

However, I also said that a compromise is the better outcome if at all possible. And I also said that for a split to work it must be done properly, and my fear that this will not be the case is growing.

Which is why I think we should give diplomacy another shot and pursue a genuine compromise, and why I urge people from both sides of the fence to be more receptive to it. And yes, compromise does mean giving up things that you hold dear.

I will not go into exact detail about what such a compromise could consist in. But overall, two key components will almost certainly have to be activation of Soft-Fork SegWit as soon as possible, together with a hard fork to increase the block size further (perhaps with a built-in growth schedule) without more delay than is necessary.

My own side in the debate is no secret - I believe that the best technical solution is to activate SegWit immediately, and figure out later whether we need a hard fork, and which.

But I support a compromise along the aforementioned general lines, for several reasons which I will explain.

Technical merit

I've said before that I didn't really personally experience the dreaded datageddon that others reported, with slowly confirming transactions and prohibitive fees. Transactions still confirmed quickly and with relatively cheap fees. This made me question the need to rush the scaling solutions.

But time has passed and I'm sad to report this is no longer the case. Bitcoin has experienced another burst of explosive growth, and so did demand for space in the blockchain. I've observed firsthand that getting transactions confirmed within reasonable time requires fees upwards of a dollar. I don't care too much about my own costs, but I'm beginning to feel embarrassed to praise the merits of Bitcoin as I have always done.

This leads to two conclusions: First, we need to resolve the situation, we can't remain in the current situation indefinitely. If a compromise is what it takes to move forward, so be it.

Second, if previously I thought that SFSW is good enough for now - now I think that SFSW is probably sorta kinda good enough for now. If growth continues as it has so far, we'll need a more aggressive blocksize increase sooner rather than later. So despite all the risks and disruptions, an expedited movement towards a hard fork starts to sound like not such a terrible idea.

The other technical issue is that I think we should be more open to the concept of a hard fork. When I got into Bitcoin I didn't sign up to the idea that a hard fork would occur only whenever a mule foals. There are many much-needed upgrades to the protocol which can only be done by way of a hard fork. If we can't even change a well-understood parameter, it doesn't inspire confidence that we'll be able to handle the bigger changes ahead.

Conservativeness in forks is important, but there is such a thing as too much conservatism, and we might be approaching that point. Which is why, again, expediting the hardfork schedule might not be such a bad idea.

For people, by people

More important than the technical reasons why a compromise is palatable, are the social reasons why we need it.

I don't see Bitcoin as a piece of art, an engineering wonder that I can put on display and marvel at its technical correctness. It is a tool created by people with the goal of benefiting people. If it fails at this purpose, it should be fixed.

And right now Bitcoin is stuck, and what's important is to unstick it, not to pat ourselves on the back for how rigorous our technical development methodology is.

Furthermore, Bitcoin is not as robust as some people might think - it is always at the risk of attack by a determined attacker of means. Its security is based on a combination of its own technical defense mechanisms, together with making sure it has as few enemies as possible. Bitcoin has enough enemies from without to worry about. It doesn't need infighting and the threat of some segments of the Bitcoin community attacking others, which may well be the case if we go for the more militant methods of resolving the conflict. Bitcoin is strongest when all its proponents are allied, and this is what a compromise aspires to achieve.

But the issue goes much deeper than that.

The debate, it seems, becomes more and more divisive every passing day. People who express disagreement are labeled as sellouts or traitors to the Bitcoin cause. Demonization, personal attacks and mudslinging are rampant. People have picked sides. Propaganda has succeeded. It's sad and doesn't further a solution.

It is becoming clear that people have firmly tethered their identity to their side on the debate. And this is bad news. As Paul Graham eloquently explains, you can't have a rational, civil debate when people's identities are on the line. People adopt new ideas and resist others not for their underlying merit, but for which side the idea is associated with. This can quickly escalate (and in our case, already has), as people become more and more entrenched in their position, and the more vile a person is perceived just for expressing a dissenting position.

I miss the times when all Bitcoiners were on the same boat. When we could discuss technical topics based on their technical merits. When you could express an opinion without being painted as belonging to one camp or another, or having your opinion ignored just because you are already perceived as belonging to the wrong camp. When ideas were just ideas, not "the ideas of this side" and "the ideas of that side".

But despite our sad state of affairs, I hope that we can reach a compromise. That we will each make sacrifices and rally behind the same banner. If we can do that... Then I hope it will take us back to those better times. That it will diffuse all the tension that has been built up over the years, and take the sting out of the debate. That we will be able to trust each other once more and spend our energies not on quarreling, but on moving forward and furthering solutions.

That, I believe, is a vision worth fighting for.