[2017-04-23]Bitcoin Proponents Are Laser Focused on One Particular Mining Pool

[runningm520]

Following the Bitcoin scaling debate has been interesting over the past few months. A lot of people have been focused on certain characters and organizations within the cryptocurrency environment by highlighting their opinions and scaling choices on social media. One particular individual and entity of interest has been the mining group F2 Pool and the pool’s associate Wang Chun.
All Eyes on F2 Pool

The Chinese F2 Pool formally known as “Discus Fish” is a mining organization that was formed in May of 2013. The Chinese mining pool is well known for commanding a significant portion of Bitcoin’s hashrate distribution over the past few years. Currently, F2 Pool is the second largest mining operation behind Bitmain’s Antpool capturing 11 percent of the network’s hashrate. People have been focused lately on F2 Pool’s actions because many are curious to find out what scaling solution the pool supports.
read more:https://news.bitcoin.com/bitcoin-proponents-laser-focused-particular-mining-pool/

[1714934144]

1714934144

[1714934144]

1714934144

[Carlton Banks]

It's not a scaling debate

If it was, everyone from all positions would be arguing about scaling, but they're not.



I would like to see genuine discussions on scaling taking place, and frequently talk about actual scaling paradigms for Bitcoin's blockchain to grow without endangering it's decentralisation (which is a huge part of what makes Bitcoin so powerful, and hence, valuable).

But loud relentless opposition to scaling is always drowned out by people pushing for capacity increases that do not scale, sacrificing decentralisation is not a problem for these people. And these same people falsely state that increasing the transaction capacity at the same scale actually is changing the scale, it's mind-blowingly foolish talk.



It's best just to face the facts: a very determined group of people have infiltrated Bitcoin's culture, and are trying incredibly hard to wear everyone down with over 2 years of constant repetition of non-factual presentations on how to improve Bitcoin's transaction capacity, and they will never stop and always ignore genuine reasoning in favour of every trick they can possibly come up with. And up to now, their proposals (XT, Classic and BU) have been unanimously rejected, every single time (one hilarious trick is to constantly repeat the falsehood that everyone in Bitcoin is in favour of the latest on-chain non-scaling proposal, despite the overwhelming majority of real Bitcoin nodes on the Bitcoin network rejecting all these proposals)


So, if one group of people aggressively and unrelentingly push for x, when their idea is actually NOT-x, what are they really arguing for?

The proposals of the on-chain non-scaling contingent always involve hard-forking both the software code and the blockchain itself to a completely different set of programmers than those who currently develop Bitcoin. This group don't just want to make the Bitcoin network more centralised with their plans, they also want to change the leadership. It's been suggested to them on many, many occasions that they could try their ideas on a new and separate cryptocurrency. They consistently reject this, claiming to already represent the "real" Bitcoin (despite having nothing but assertions to this claim, and despite pushing for taking control and never getting the support to do it).

[classicsucks]

It's not a scaling debate

If it was, everyone from all positions would be arguing about scaling, but they're not.

Good to see you, Carlton.

Well he said in the article

“It’s not about segwit or not,” says Wang Chun. “It’s about communicating, listening, understanding, and respecting. All those the things current Core devs lack.”

[Carlton Banks]

Indeed, and you'll notice that I concentrated on scaling vs non-scaling, no mention or allusion to Segwit in any way, shape or form..


You're part of the false narrative, classicsucks. You actually speak as though you believe that changing the transaction capacity without changing how that scales the Bitcoin network is somehow the same thing as scaling the network.

And all you can do is the same thing all non-scalers do: tell obvious troll-ish lies about what I said (nothing to do with Segwit and all about scaling vs non-scaling), and throw mud at the Core project.


You know who's not listening, in the face of reason, and simultaneously presenting non-reasoned sophistry as technical arguments? You and the "blocksize is the only thing that exists, sorry, can't hear you, fingers-in-ears" brigade.

[Iranus]

Indeed, and you'll notice that I concentrated on scaling vs non-scaling, no mention or allusion to Segwit in any way, shape or form..

What you said very strongly implies that you think SegWit is the only viable possible solution though, because you believe that changing the transaction capacity through block size isn't actually scaling the network and the network needs to be scaled.

So you implied that you think SegWit is the only major solution given which would actually scale the network (and therefore that you support it, unless you find some completely irrelevant solution that none of us have heard of).

[Carlton Banks]

Nope, Segwit does what I don't want in terms of scaling, Segwit just adds more transaction capacity by adding more blockspace. I implied nothing different, you're straw-manning (and it's boring)

Segwit lays the foundation, the capability to scale off-chain. It's got zero relationship to on-chain scaling, it increases capacity using the Bitcoin network's resources at the same scale as we have right now (i.e. 1MB block holds ~ 2000 transactions). A factor of 4 increase in the amount of transactions using a factor of 4 increase in the blocksize is not scaling (i.e. 4MB Segwit blocks hold ~ 8000 transactions), it needs to be a factor of > x increase in transactions using a factor of x blocksize to actually scale up on-chain capacity, and Segwit doesn't do that. At all. And I have never said that it did.

[DooMAD]

Or to put it another way, if Carlton had been in charge of developing SegWit, it would likely have been .25 MB for the original keypair transactions we currently use and .75 MB for the new witness data, still maintaining a total of 1MB blocksize.  SegWit's potential of up to 4 MB is too large for Carlton's preferences and thus sees SegWit as a compromise.  

But a .25/.75 approach would have been messy.  As for the degree of how messy, it depends how long the developers of all the wallet clients out there take to update their software and how long the users take to adopt that new software.  At least with the 1/3 setup we're actually looking at, it wouldn't add to the problems with the choice of either higher fees or slower confirmations.  It should gradually ease some pressure.

*Carlton telling me how wrong I am in 3... 2...*

[Carlton Banks]

No, I more or less agree with you.

The only "messy" aspect of a 0.25 MB/ 0.75 MB Segwit would've been that it couldn't be done without a hard fork, i.e. both miners and regular nodes would need to upgrade in a very coordinated and holistic manner, which is quite like what you're saying anyway, I just choose to add different details presented a little differently. And I agree about your 1/3 comments too, you should make it clear that the necessary hard fork to implement 0.25/0.75 MB Segwit is the reason why the 1/3 MB soft-fork solution is smoother on the user experience (no choice between 2 chains, as you say).

[DooMAD]

No, I more or less agree with you.

Who are you and what have you done with Carlton?  I thought for sure I'd be "putting words in your mouth" again.   

The only "messy" aspect of a 0.25 MB/ 0.75 MB Segwit would've been that it couldn't be done without a hard fork, i.e. both miners and regular nodes would need to upgrade in a very coordinated and holistic manner, which is quite like what you're saying anyway, I just choose to add different details presented a little differently. And I agree about your 1/3 comments too, you should make it clear that the necessary hard fork to implement 0.25/0.75 MB Segwit is the reason why the 1/3 MB soft-fork solution is smoother on the user experience (no choice between 2 chains, as you say).

And the small but decidedly noticeable part where there would be less space for all the "vanilla" transactions, causing backlogs to become longer until everyone had the chance to update.  Surely you see why some people might not appreciate that?  I certainly wouldn't have wanted anything to do with a proposal in that form and couldn't have got behind it if that had been the case.  The "compromise" of a higher throughput was absolutely necessary. 

[Carlton Banks]

When you're wrong, or putting words in my mouth, I say it, how could I do anything else? You (or anyone else) has never had to call me out for arguing using underhand tactics, because I simply don't do it.

You're saying that calling you out when you claim I've said something I didn't is all I ever do. This is categorically no different to your behaviour in those previous exchanges between us; because you can't make your points fairly, you choose to come at me with personal sleights that have no merit.

You have no shame, basically. You say something you know I will agree with, just so you can paint an exaggerated caricature of my comportment in debate, reactions that are forced on me by the bad sportsmanship of people like you.



And, I'm not sure I totally follow your "less space for vanillas transactions" remark.

If it's Segwit by hard fork, then there are by definition 2 chains, the same block space exists for the 1MB fork as did before in that circumstance. The 4MB Segwit chain could arguably have less space for P2PKH & P2SH transactions (aka the "vanilla" types, as you call them), but that balance is to be determined by the market price of transaction confirms, just like now.

One could make the same argument for the price/resource differential between the P2PKH and P2SH transaction types we can already use with Bitcoin today; P2SH is inherently more expensive, as it uses more space even for the simplest P2SH transaction. Are P2SH transactions "causing backlogs to become longer until everyone had the chance to update"? People that only wanted to use P2PKH could've just failed to update to the version of Bitcoin that introduced P2SH, but in practice, they accepted the compromise of having to compete with higher fees for the additional blockspace with P2SH transactions, presumably because they wanted the new features and bugfixes that came with new Bitcoin software that inevitably included P2SH.

Using Segwit transactions as a parallel example, the native P2WPKH and P2WSH formats (i.e. not the initial implementation that nests them inside a P2SH script) will be slightly smaller than their vanilla PKH and SH types anyway, so it's really difficult to see what you're getting at. What are you getting at?

[DooMAD]

And, I'm not sure I totally follow your "less space for vanillas transactions" remark.

If it's Segwit by hard fork, then there are by definition 2 chains, the same block space exists for the 1MB fork as did before in that circumstance. The 4MB Segwit chain could arguably have less space for P2PKH & P2SH transactions (aka the "vanilla" types, as you call them), but that balance is to be determined by the market price of transaction confirms, just like now.

One could make the same argument for the price/resource differential between the P2PKH and P2SH transaction types we can already use with Bitcoin today; P2SH is inherently more expensive, as it uses more space even for the simplest P2SH transaction. Are P2SH transactions "causing backlogs to become longer until everyone had the chance to update"? People that only wanted to use P2PKH could've just failed to update to the version of Bitcoin that introduced P2SH, but in practice, they accepted the compromise of having to compete with higher fees for the additional blockspace with P2SH transactions, presumably because they wanted the new features and bugfixes that came with new Bitcoin software that inevitably included P2SH.

Using Segwit transactions as a parallel example, the native P2WPKH and P2WSH formats (i.e. not the initial implementation that nests them inside a P2SH script) will be slightly smaller than their vanilla PKH and SH types anyway, so it's really difficult to see what you're getting at. What are you getting at?

I'll walk you through it.

All of the bitcoin stored on native keys (or for emphasis, every single satoshi currently in active circulation) will have to be transacted over to SegWit keys in order for SegWit's witness space to provide any benefit.  This potentially means a short-term increase of transactions which are formed of a large number of inputs from people who usually collect and hodl.  Anyone who has been receiving weekly sig campaign payouts and has never moved those coins, or worse still, people using faucets, all suddenly feel the urge to move their funds.  Not only would this be an increase to the volume of transactions over the short term, but also potentially larger sized transactions that would take up more space than average due to the number of inputs.  None of these coins will utilise any of the witness space until they have arrived on the new keypairs.  Combining that with a sudden introduction of a .25 MB bottleneck would be an unmitigated disaster.

Hence my view that it would be a bad idea to do it that way, so I'm glad you're not in charge if that's how you'd run the show.  

[Carlton Banks]

1. We're not talking about hypothetical 0.25MB base blocks anyway, we can throw that out instantly

2. I got into a conversation with Franky about this (one of the last I had with the people who man that account). If every single transaction in every block was from a pre-Segwit address to a Segwit address, it would only take 6 weeks to move it all across with today's UTXO set.


So realistically, it might take a few months, as not everyone will try to switch to Segwit addresses at once, they're going to want value for money. But as more people moved BTC to Segwit addresses, they'd start using the extra 3MB Segwit blocks straight away, gradually taking pressure off the 1MB base blocks used to switch over to Segwit address types. Sure, it's another compromise, but it will be a worthwhile 2-6 months of increased fee pressure, and it would be the reality no matter which way segregated witness was implemented. I certainly won't need to move my funds straight away, so not every single user will be exerting this effect on the blockspace simultaneously.

[DooMAD]

So realistically, it might take a few months, as not everyone will try to switch to Segwit addresses at once, they're going to want value for money. But as more people moved BTC to Segwit addresses, they'd start using the extra 3MB Segwit blocks straight away, gradually taking pressure off the 1MB base blocks used to switch over to Segwit address types. Sure, it's another compromise, but it will be a worthwhile 2-6 months of increased fee pressure, and it would be the reality no matter which way segregated witness was implemented.

Yes, as long as we're clear and up front about that, then it's fine.  This is one of those things that some users may not have anticipated, so it's better to set realistic expectations and overcome the objections before it actually happens.  My suspicion is that traffic will increase after SegWit activates and the queues may be slightly longer at first until the witness space begins to ease the load.  I'm also anticipating a few opportunists might seize upon this busier spell to claim SegWit has failed in helping with scaling, so heads up for that shitstorm.  Again, the more transparent we can be now on the realistic impacts, the calmer the transition will be.

[Carlton Banks]

I'm also anticipating a few opportunists might seize upon this busier spell to claim SegWit has failed in helping with scaling, so heads up for that shitstorm.

If we're taking that 100% literally, then that would be true, Segwit isn't a scaling solution on it's own.

The versionbits BIP9 that's part of the Segwit fork will kind of help (so that more than one soft-fork can be signaled at once, only one can be signaled and/or activated concurrrently with the present soft forking mechanism).

And of course, Segwit will allow for a range of 2nd layer networks on top of the Bitcoin blockchain, of which Lightning is only one (just the one most talked about).


But Segwit does nothing for scaling the network, it does increase capacity, but capacity and scaling are not the same concepts.


You're right and wrong about detractors denouncing Segwit's efficacy, it will of course happen, but as I mentioned above, it's actually already started to happen months ago (the claim was that it would take years to move to move every unspent BTC output to Segwit addresses, not the months that it will more likely take) You can't really give the heads-up for something that's already happened, sadly

[classicsucks]

You're part of the false narrative, classicsucks. You actually speak as though you believe that changing the transaction capacity without changing how that scales the Bitcoin network is somehow the same thing as scaling the network.

And all you can do is the same thing all non-scalers do: tell obvious troll-ish lies about what I said (nothing to do with Segwit and all about scaling vs non-scaling), and throw mud at the Core project.

You know who's not listening, in the face of reason, and simultaneously presenting non-reasoned sophistry as technical arguments? You and the "blocksize is the only thing that exists, sorry, can't hear you, fingers-in-ears" brigade.

The pot calling the kettle black. You seem smart enough to escape the Core echo-chamber, and I know you understand the landscape well enough to know that Segwit is dead in the water. Don't bother arguing for an idea that has come and gone.

This discussion of moving funds to use Segwit is amazing. Yet another reason that Segwit is deeply fuxored and unnecessary.

It looks like Segwart is activating on Litecoin. Why don't you go play with it over in their sandbox-coin, and leave the men here to decide the future of bitcoin?

[Carlton Banks]

Have fun waving your weenie. On the internet.