What is the difference between Bitcoin Core and UASF?

Question

I am a little confused about what the actual difference is between Bitcoin Core and UASF, are they both only for SegWit?

If so who is then for SegWit2X?

Answer 1

Correct, core and UASF groups are both Segwit supporters (as are Segwit2x supporters). Both core and UASF are against 2x. UASF is just an attempt to force segwit if miners had rejected it (miners did not reject). I'm not really sure how they expect UASF could have been successful without hash power if miners had actually rejected Segwit.

I've seen some core supporters argue that UASF was reckless (would have disrupted non-Segwit nodes), so though the chains they support today are the same, the groups are not perfectly in alignment. More details here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html

You can see who supports the New York Agreement (Segwit2x) here:

https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

As stated in the link, they represent (at the time of the agreement):

• 58 companies located in 22 countries
• 83.28% of hashing power
• 5.1 billion USD monthly on chain transaction volume (likely larger now with higher price)
• 20.5 million bitcoin wallets

Most notable from my perspective are Bitpay, Coinbase, and the majority of miners.

Here you can also find those who supported the original Hong Kong Agreement from a year ago:

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

The original HKA failed. Many who signed onto the HKA (e.g. Adam Back of blockstream and the core contributors) seem strongly opposed to 2x today, which is most of why it failed. The Segwit2x of NYA is in some ways an attempt to bypass those who agreed to pursue 2x a year ago but who actually ended up fighting it.

Opposition (the core devs, who effectively want to retain veto power) argue that giving in to miners/businesses gives them too much power. Some from the 2x crowd argue blockstream & core are attempting to block capacity increases to force users into the lightning network. It's all rather political and there isn't much trust. Ill will is taken for granted in most debates.

The HKA was a bit less committal ("This hard-fork...will only be adopted with broad support across the entire Bitcoin community") which I suppose is how the core team can say they aren't technically violating their word.

My impression is that these particular core HKA signatories are the primary driver of "the Bitcoin community" that opposed. When it became clear that core had no intention of pursuing 2x and were actively fighting it, the initial HKA compromise no longer seemed relevant or in good faith -- i.e. activating Segwit would sacrifice any near-term opportunity for a meaningful capacity increase. Blocking Segwit became a tool to fight for a capacity increase. All this further fanned the flames of the rather toxic scaling/capacity debate.

Here's a list of companies tracked by coin dance that support or oppose segwit2x, though the data is a bit sparse. As of today 67% are neutral, 24% support, and 9% oppose. I don't recognize many of the "no" voting companies other than blockstream. They give the option to weight the votes by total web traffic (not perfect but gives some indication of relevance), bringing support to 44%, neutral to 56%, and opposition to nearly zero.

https://coin.dance/poli

Answer 2

I try to answer from a non-politcal view: as we are here in a developper world...

First let me say, that "the core devs" can be many people, it can even be you and me. Learn the code, contribute, and you're ready to propose github entries/change requests (and if it is only a documentation correction), and suddenly you are a core dev :-) Core devs is not a company, core devs are individuals all around the world.

These core devs, who developped the code for bitcoin, are proposing segwit since years (via soft fork). And it is these developpers, who brought the code forward, which is today running the equivalent of a multi billion Euro/Pound/Dollar network at an incredible stability and on the vast majority of nodes (+98%). These core devs not only created segwit to get rid of tx malleability and increase throughput, they also laid the foundation for the future scaling with lightning network. There is several 100.000 hours of knowledge and expertise in this code base! In greedy moments it makes no sense, to bash the core devs, forgetting the the roots, where we are coming from...

The miners didn't follow the segwit soft work proposal for many (maybe political) reasons, but fact is, they blocked the further development of the bitcoin code. And as such they were taking all users and participants as "hostages", not being able to increase throughput and having many, many issues with transaction fees.

Given this enourmous knowledge and experience of core devs Bitcoin software makes segwit2x proposal seem rather dangerous for the Bitcoin network, and when miners can take the community as hostage for their own interests, then the idea of decentralized, immutable and "non governance" value network has vanished. As such it is fully tolerable to be against an "urgently written" software with the capability to have negative impact to the network.

UASF was then the idea, to "block" forwarding of data to these potentially malicious nodes, that didn't signal segwit support. This would not forward tx data to miners who are against segwit soft fork, and they would loose money (cause they could only find lesser blocks). I see this as a trigger for the miners, for a need to find a solution, which is this segwit2x proposal. Thankfully Barry and team provided this proposal in a way, which did allow the miners, to keep the reputation in this scaling debate.

The good thing is, that segwit locks in, removing the old code flaws and providing a path to new development going forward. The time of financial interests (miners) and trust (into core devs) might not be finished, but the way going forward looks more than positive.

I thank all participants in this community, at the end "we" are preparing the road to the future.

... and kudos to Trace Mayer, I think I copied a bit from his podcasts in here :-)