Bitcoin Forum

So you've probably heard by now that the large pools have been meeting in secret to discuss a way forward for the bitcoin protocol that would both activate segwit and a future 2MB hard fork. It appears the closed doors meetings did indeed come to an agreement, but not quite what has been assumed by the community.

This is allegedly the draft agreement:
https://pastebin.com/VuCYteJh

Copied below:

In short, what this actually means is a large proportion of the big mining pools have agreed to ignore pretty much all scaling signalling and adopt their own to further their desires. They plan to do a hard fork within 4 months6 months(updated) that both activates segwit and creates a base block size increase of 2MB concurrently. In addition, they are NOT going to be using the existing segwit bits, signalling instead their own bit to activate segwit which is incompatible with the segwit activation from core. They are also planning activation at >80% hashrate.

In essence this means the pools are creating a fork of the current bitcoin code which is planned to be incompatible with any current version should their hard fork go ahead. Which means that every single current code node user, be they core, BU, classic, XT, whatever, is currently going to be on an incompatible fork of bitcoin after their planned deployment in SeptemberDecember. So they are asking the entire community to ignore all existing bitcoin implementations and adopt their software node implementation before that time, or risk being on a very hashrate poor fork, even though there is no published code to support this SeptemberDecember fork yet.

This isn't remotely what many of us were expecting when we heard the pools were agreeing to implement segwit provided a hard fork was also available. In retrospect it makes sense given their aggressive stance in the past, but basically this is without doubt the most aggressive stance yet by the mining consortium. It's even more amazing given bitcoin.com allegedly signed the agreement - BU's reference pool implementation owned by Roger Ver. I wonder if all the groups that allegedly signed the agreement are even aware of what it is they're agreeing to? Bitfury for example are in there, who have been vocal proponents of segwit to date.

This will no doubt make the community even more aggressive in response with its BIP148 stance. I don't like BIP148, but I like this even less.

I'd like to believe this draft agreement was heavily revised and is basically wrong, but at this stage this is all we have to go off.

-ck only wants posts that agree with his narrative

my post is about sgwit... not any other implementation or people..(not bu, ver, jihan, classic, xt)
but expect my post to get deleted even if it speaks truth

1. if core is perfect working code, then why does it need "fixes" such as malleability, quadratics
2. if segwit works beautifully on litecoin then why are the pools who voted for it not even using segwit keys (where the actual segwit function/benefits lay)

i find it funny that pools pushed for segwit but too afraid to put their coinbase(blockrewards) into a segwit keypair..

all these efforts of
core-bip9
uasf
barry silbert
are all the same crap trying to get segwit activated but doing NOTHING to ensure any user benefit is guaranteed.
doing nothing to meet any promises of segwit or anything after segwit

expect my post to get deleted even if it speaks truth

should be discussed by the community in as open and as free a manner as possible.

1. if core is perfect working code, then why does it need "fixes" such as malleability, quadratics

Then you make a self moderated thread? :P

Core will never accept any form of automatically increasing on-chain scaling as they view this as the leading to the centralization and ultimately the failure of bitcoin.

The perception of immutability is not necessarily bad for value so this is not a terrible thing. That said if the cost to send bitcoin approach the cost to wire fiat this will slow growth and adoption.

This is simply untrue, and in fact the published capacity increases plan message (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html) directly contradicts you.
...
Your remark is doubly off the mark, to the point of a bit of offense,  because segwit _IS_ "on chain" scaling.    (It is both an increase of the chains scalablity and of its capacity.)--  doubly so because the same people have been doing all this work to keep up with load since _2011_ and have been responsible for 100+ times increases in scalablity from the original software.

That was an interesting read. I did not understand it all but it was interesting. There is a lot of technically advanced work being done behind the scenes in bitcoin.  

Perhaps my statement was overly broad. I should have simply said that Core will not accept any of the currently proposed algorithms for automatic blocksize increases as they believe these threaten progressive centralization. I did not intend to imply that the Core developers would be opposed to automatic scaling should a technical breakthrough change the perceived risks.

Segwit may be an on-chain scaling increase but as far as I can tell the miners don't see it that way. They seem to view it as capitulation and giving up on future on-chain scaling in favor of pursuing off-chain solutions going forward. Just as Core feels rash increases in block size threatens to bitcoin viability. The miners seem to feel that favoring of off-chain over on-chain transactions will in the future threatens their long term viability. Thus we get gridlock. This is my current understanding of the current dynamics in play. Am I misunderstanding anything?

I am glad that you highlighted the work the Core team and yourself have put into this. The community should know the blood sweat and tears that have been investing into the protocol to date and most of us don't.

Statements from Core don't mean anything. This you should know by now.

Then you make a self moderated thread? :P

In any case... I'd say stick a fork in it,  but it sounds like Bitmain is now planning on doing just that.  They've announced their intention to fork off onto a new and incompatible direction,  (also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce).

In my view, that after the near unanimous rejection of segwit2x by active developers (even BU) Bitmain announcing they're gonna do a spinoff is the final killing blow on that absurd agreement.


uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit. Segwit is the fix and it was needed because the protocol design Satoshi had a few limitations.  There have been many softforks in the past to fix other limitations in the original design-- some performed by Satoshi himself, some performed by the current folks that maintain the software.

also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce

This is simply untrue, and in fact the published capacity increases plan message (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html) directly contradicts you.

uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit.

this agreement is joke from community . This reminds me LTC round table when 12 miners called themselves all users.
I have never been fo staing at 1MB forever but this binding segwit to HF in 6 months is joke.
HF to just increase to 2MB is weak. With HF you can add some good features to protocol why rush so much.
I don't want BTC hijacked by miners and their GREED...
this agreement is joke from 90% users running core client that are my 2 cents

But the issue is that Bitmain and friends ... claim that only miners should run nodes,

Given the vitriol in the community on this topic I unfortunately felt that was necessary. This is the only self moderated thread I have ever started.

I have never before deleted anyone's post on any forum to date and I hope to keep this record. However the hostility around this topic necessitates the following rule.

Rule: No personal attacks.

Example: "CoinCube is a Russian agent looking to hack and take over bitcoin" would get deleted. Similar personal attacks on either miners or developers would be deleted.

Then you make a self moderated thread? :P

In any case... I'd say stick a fork in it,  but it sounds like Bitmain is now planning on doing just that.  They've announced their intention to fork off onto a new and incompatible direction,  (also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce).

In my view, that after the near unanimous rejection of segwit2x by active developers (even BU) Bitmain announcing they're gonna do a spinoff is the final killing blow on that absurd agreement.


uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit. Segwit is the fix and it was needed because the protocol design Satoshi had a few limitations.  There have been many softforks in the past to fix other limitations in the original design-- some performed by Satoshi himself, some performed by the current folks that maintain the software.

But the issue is that Bitmain and friends ... claim that only miners should run nodes,

This reminds me LTC round table when 12 miners called themselves all users.

With HF you can add some good features to protocol why rush so much.

That is a valid stance and I agree that Segwit2x is not perfect. I see it more as one of the few possibilities we have to unlock the current stalemate without a chain split. And perhaps, in 6 months some of these "good features", in theory, could be integrated in the hard fork.

would seem to belie either a willful ignorance or maliciousness.

damn hypocrit

False personal attacks based on no evidence should be deleted.

Come on folks. This thread only has one rule. No personal insults towards individuals or groups. It’s not that hard.

They also claim that only miners should run nodes, that it's okay if eventually Bitcoin nodes just exist in five data centers.

this agreement is joke from community . This reminds me LTC round table when 12 miners called themselves all users.
I have never been fo staing at 1MB forever but this binding segwit to HF in 6 months is joke.
HF to just increase to 2MB is weak. With HF you can add some good features to protocol why rush so much.
I don't want BTC hijacked by miners and their GREED...
this agreement is joke from 90% users running core client that are my 2 cents

Agreed. UASF is the way with a blockchain with no miners

 :-\

That's perfectly possible, but that's a proof of stake consensus chain, not a proof of work consensus chain.

My personal opinion is that bitcoin's scaling problems will be solved once the "bitcoin" brand has eroded away his first mover value, which seems to come quicker than I thought.  Most probably, by August or November, this will already be the case.  Once the unicity of bitcoin's brand name is not the main stake any more, forking will not be hampered by "but we should get the bitcoin brand name with our chain", and one will be able to fork without fear.
That's just my personal intuition at this point.

Please meet my friend, the byzantine general :p
http://2.bp.blogspot.com/-5rSSvomx2bk/UvMQM_fd8LI/AAAAAAAA_4A/0R-fJ5f4eTA/s1600/maurice-by-emilian-stankev-from-rulers-of-the-byzantine-empire-published-by-kibea.jpg

:)

edit: just in case. I was not intending to be offensive with the post. just a joke.

Politics has gripped Bitcoin and it’s about the only thing people have been wanting to talk about for the past few years. I’ve written before about how the Bitcoin ecosystem is like the three branches of government, with Developers being the legislative branch, Miners being the executive branch and Users being the judicial branch. I’ve also written before about how Bitcoin changes through consensus, and how consensus is not supposed to be easy.
In this article, I examine an alternative path to the current political stalemate and how that can help empower Developers, Miners and Users.

Current State of Miners
Among mining manufacturers, it’s pretty obvious that Bitmain is the biggest and most successful. They produce somewhere around 50–75% of the Bitcoin network hash power through their chips and other manufacturers have a tough time competing with them on price. Their first product, the S1, came out in 2014 when there were many more competitors (CoinTerra, KNC Miner and Spondoolies Tech to name a few). They distinguished themselves by having the product on-hand at various Bitcoin conferences and unlike many of their competitors, having great supply chain management helped them win fans around the world.

As Bitcoin experienced a 3-year bear market, many mining manufacturers simply went out of business as the economics turned from wildly profitable to barely survivable. It didn’t help that many had products that often had defects and delivery issues. Bitmain not only survived this time, but thrived, and managed to capture significant market share.

Whatever your opinion of the company may be, Bitmain is the most dominant Miner and they are the 800 lb gorilla in the mining space.

Current State of Developers
It’s well known that Satoshi Nakamoto made the first Bitcoin client and released it to the world in 2009. Many people have contributed to what’s called the “reference client” and Bitcoin Core, as it’s now called, has hundreds of developers that contribute to the open source repository.

What’s less known is that there have been many different attempts to create alternative Bitcoin clients. Obelisk, btcd, Toshi and bcoin are just some of the many attempts at creating new Bitcoin clients from scratch. Bitcoin Unlimited, Bitcoin XT and the newest Segwit2x are some forks of Bitcoin Core. While each has had a varying degree of success, it appears most of the network continues to run Bitcoin Core. Most estimates are well over 90%.
Why is Bitcoin Core the most popular? There’s certainly history to consider. People managing money tend to be conservative and changing any part of the tool chain for managing money tends to be a dicey proposition as any errors may cause monetary loss. Further, Core has the largest developer community and the most rigorous development processes in place.

Whatever your opinion of Bitcoin Core may be, Bitcoin Core is the dominant client on the network and they are the 800 lb gorilla in the development space.

Balance of Power
While before 2014, the Miners and Developers generally got along, things started to change once the issue of scaling came up. We’ve gotten to the point where the scaling conflict is often seen as Bitmain vs Bitcoin Core (I’m sure neither are happy with that characterization). We have two dominant groups that have been in conflict.
Miners are frustrated because they’ve been asking for large blocks for years. From Bitmain’s perspective, none of the Developers seem even interested in any sort of hard fork. When they ask, the usual responses range from “follow the Bitcoin Improvement Proposal process” (which inevitably gets voted down) to “fork off”.
Developers are frustrated because they’ve been asking for Segwit for years. From Bitcoin Core’s perspective, the Miners seem to be obstructing good technology for no good reason. When they ask for a reason, the usual responses range from “we want larger blocks” to “you’re carrying water for Blockstream”.

Consensus and Control
Generally, when there’s a conflict that’s not getting resolved, you have to go up a level of abstraction to figure out the problem. While scaling is the reason everyone claims for this conflict, the actual reason may lie higher up. And when you think about the actual consensus process that’s required to change Bitcoin, it’s clear that both sides want more control than they currently have.

And this makes sense. Both groups are interested in more say over the long haul as Bitcoin becomes more and more valuable. A small concession or precedent set now has consequences going forward. Bitcoin Core may be thinking a hard fork now would set a precedent for additional, possibly more dangerous, hard forks later. Bitmain may be thinking cooperation on a soft fork without getting some concession would set a precedent for being dominated and having requests ignored later.

Bitcoin Unlimited in this context can be seen as a way to get around the Developers by replacing them entirely. Similarly, BIP148 and other UASF proposals are a way to get around the Miners.
This has brought us to the current impasse. Both sides want control, but given that Bitcoin is a consensus-based system, there’s no way to give each side what it wants and keep Bitcoin on a single chain.
The way to solve this problem, then, is not by trying to solve the presenting technical issue, but by solving the deeper issue of control. The question isn’t so much “how can we scale bitcoin” but “how can we give each side more control?”

The Naive Solution
The most obvious way to give each side more control would be to split Bitcoin in two, or what I would call the Solomon Solution. We can hard fork Bitcoin and each side can do whatever it wants on their chain. One side would have to find new Miners (or even a new Proof-of-Work function) and the other side would have to find new Developers.

While this has some appeal, splitting Bitcoin in two has the potential to cause significant collateral damage. Indeed, most contentious forks have this as a possible endpoint as both sides have the ability to hard fork. Bitcoin may be the baby that dies if nobody agrees.

A More Thoughtful Solution
So far, we’ve only been talking about two of the three branches of the Bitcoin governance: Miners and Developers. When the two disagree, the ideal solution would be to have the Users adjudicate. Unfortunately, safe, liquid adjudication is only available after a hard fork when the price between the tokens can float.
But what if we can give both Miners and Developers control over separate, smaller domains? What if each could run separate chains and each could change and use them according to their needs and desires? Further, what if these separate chains were actually extensions of Bitcoin itself?

Wouldn’t Users naturally utilize the one that they preferred? Wouldn’t the best idea win instead of the best political player?

If this sounds familiar, it should. This is what the whole sidechains project is all about.
What are sidechains?

If you haven’t heard about sidechains, think of them as a separate blockchain where you can deposit and withdraw Bitcoins. That is, if you deposit 1 Bitcoin to the sidechain you add 1 Bitcoin to your balance on the sidechain and if you withdraw 1 Bitcoin from the sidechain, you subtract 1 Bitcoin from your balance on the sidechain.
The separate blockchain can have all sorts of new features and won’t actually affect Bitcoin. And this is the key. You can give control of one sidechain to the Miners and another to the Developers. In fact, you can add lots more sidechains for a variety of purposes to see how well they work. Users can vote with their feet by going to sidechains that they find most useful. Merchants, for example, may want to go to a sidechain that’s much quicker to confirm. Exchanges may want to go to a sidechain with more financial instruments available.
That sounds awesome! Why don’t we have it yet?

Good question. One sidechain implementation already works. The sidechain is called Liquid and has been developed by Blockstream. They utilize something called a federation, which is a fancy way of saying deposits to the sidechain are Bitcoins sent to multisig addresses.

The Liquid security model requires a bunch (11+) of known, trusted entities (like exchanges) and that’s still in the process of being set up. The good news with Liquid is that it requires no changes to Bitcoin in order to work. The bad news is that you have to trust that a majority of entities won’t steal from you.
The other sidechain implementation is something called Drivechains. The good news is that Drivechains don’t require (less) trusted entities and the code is almost done. The bad news is that Drivechains require a soft fork.
Wouldn’t this give everybody what they want?

It certainly seems so. Having the market decide instead of committees seems like a much more scalable solution (pun intended). And indeed Paul Sztorc has proposed Drivechains as an alternative to Segwit or 2MB blocks. Segwit can easily be deployed on one sidechain and larger blocks in another sidechain.
It’s not all good news, however. There’s the obvious fact that BIP148 and BUIP0055 are scheduled for August 1 and October 18 respectively. Both are potentially contentious forks and may very well cause some serious disruption.
Liquid requires finding enough trusted entities in enough jurisdictions. Many Users don’t like having to trust other entities so this may be a non-starter.

Drivechains requires a soft fork where Miners validate new rules. Further, there are some technical issues that may need to be addressed as well as code that needs extensive review and testing before a soft fork can happen. Developers and Miners would ultimately have to agree to pursue this path.
Conclusion

The benefits of a sidechain solution are pretty clear. Developers and Miners are empowered since they can try out new, riskier features on sidechains and don’t have to get anyone’s approval for doing so. Each can control their own sidechain without disrupting any other part of Bitcoin. Users are empowered since they can have a choice of features without having to leave Bitcoin.

The downsides of a sidechain solution are a bit murkier and require a more thorough examination of the incentives to really evaluate properly.

As Bitcoin enters its fourth year of scaling conflict, creative solutions like Drivechains and Liquid deserve more rigorous consideration. There very well may be technical or trust issues that are insurmountable but it’s vital that as a community, we leave no stone unturned.

We are currently embroiled in a bitter political war. This is because we’re essentially stuck in a zero-sum game of consensus building. Innovation is a better way to resolve conflict than politics. Politics is messy, divisive and harmful. Innovation is clean, unifying and constructive. If an innovative path can be found, we owe it to ourselves as a community to find it.