4 ms·

Sorry if this is a stupid question, but why not both? It doesn't appear that the two strategies are mutually exclusive. Is it just that SegWitX2 is considered t

Sorry if this is a stupid question, but why not both? It doesn't appear that the two strategies are mutually exclusive. Is it just that SegWitX2 is considered too rushed? Is it just that miners have a vested interest in maintaining influence? Personally it seems like smart contracts and other similar services beget an ecosystem that could swell the market cap by a significant amount, I assume miners would have a long term goal of doing just that. As a disclaimer, I own Bitcoin, but I'm definitely a layman and I don't really have a horse in the race. What I'm most concerned is what these changes are going to accomplish when looking back 10 years from now. I'm in BTC for the long-term, and this whole thing stinks of petty bias and tribal power plays.

kanzure 9y ago
> Is it just that SegWitX2 is considered too rushed? https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/divtc93/ https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone... and https://www.reddit.com/r/Bitcoin/comments/6hkuze/greg_maxwell_a_hasty_snapshot_of_a_few_of_my_views/ https://www.reddit.com/r/Bitcoin/comments/6hkuze/greg_maxwel... and a long-term view i guess https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/diyu6ys/ https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone... more broadly-- although with less explanation-- https://en.bitcoin.it/wiki/Segwit_support https://en.bitcoin.it/wiki/Segwit_support
mhluongo 9y ago
Sounds like you already know. The Core devs say that SegWit2x is too rushed (and I tend to agree), but it's also putting forward a new client that could become the default over Core (btc1), and a potential refresh of the dev team. This is less about the tech and more about the politics, at this point.
statoshi 9y ago
There are many reasons, but one is that few people in the technical community support a somewhat rushed hard fork that does nothing but increase the block size a bit. There are plenty of other things that would be great to clean up if a hard fork is to be deployed. https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/Hardfork_Wishlist
Torgo 9y ago
both sides are in many ways right in their criticisms about the other side, they are just fundamentally conflicting visions of the long term nature of the network. In my opinion the problem here is the network was built so that it operated only by people acting on incentives and those incentives being aligned with the good of the network, and it turned out that miners acting in their own interest wasn't actually good for scaling past a certain size and operating on certain types of transactions.
- duckingtest 9y ago
  You should ask the question about Core developers' incentives: what do they personally gain from scaling bitcoin? Nothing, at best increase in value of their holdings which they share with lots of free-riders, and only until they sell. They only gain continuously if scaling is prevented as that opens space for their second-layer solutions - presumably to be enabled by planned 'improvements' to bitcoin. Ie. their only incentive is to capture bitcoin for rent extraction. Miners are the only entities that have a continued incentive to improve bitcoin directly. THAT'S the real conflict, everything else is BS.
fpgaminer 9y ago
> Sorry if this is a stupid question, but why not both? By both you mean, SegWit + Bigger blocks? It's not possible today to raise the blocksize without exponentially increasing the computing resources required to run a Bitcoin node. So it's not a parameter that can be easily tweaked without drastic consequences. Also, increasing the blocksize requires what's called a hardfork. That's a backwards incompatible change. Anyone who hasn't updated their Bitcoin software will be left in the dust, and potentially dangerously so. SegWit, on the other hand, raises the effective blocksize to 2MB, patches a bunch of issues, and provides a means to safely enable off-chain transactions on top of Bitcoin. It does all this as a soft fork; backwards compatible. That doesn't mean a blocksize increase isn't appropriate; it needs to happen at some point. But because hardforking is so disruptive, it would be best to roll in other breaking changes while we're at it. We should have a solution to the exponential computation issue, and we should have a mechanism to increase blocksize again in the future without another hardfork. Those are hard problems to solve that will take time. SegWit was meant to be a stop-gap. All that said, I'm not personally opposed to the idea of a more immediate hardfork, ala SegWit2X. I don't think it's the _best_ idea, and I think the hardfork should happen at least 12 months down the road, not 3 months as SegWit2X plans, but the perfect is the enemy of the good. The big issue with SegWit2X is that the developers working on it are not competent for the task at hand, and it's being pushed by parties with perverse incentives.
- badloginagain 9y ago
  Thanks for the explanation, that makes the bit about 80% of miners needing to adopt make sense. Why do you lack confidence in the SegWit2X developers? It seems the miners would be the last ones wanting a potentially fatal bug. Do they have less to lose if an exploit/honest bug burns the blockchain? Again, apologies if these are uninformed questions- I have only a layman's understanding of BTC.
  - fpgaminer 9y ago
    > Why do you lack confidence in the SegWit2X developers? I think the fact that they're pushing a hardfork 3 months after SegWit activates says a lot. We're talking about making all existing clients on a 40 billion dollar network obsolete and open to abuse. Giving only 3 months time to upgrade is absurd. Also, I believe SegWit2X was spawned some time in May? Being generous, that's only been 3 months of development so far. When it comes to software like Bitcoin, where the slightest bug can result in catastrophe, I want the most conservative developers imaginable. The development of btc1 (the SegWit2X client), AFAIK, has not been open. Most of it has occurred behind closed doors, with only the merges to the public repo being visible. Another notable concern is there was a pull request submitted recently against the SegWit2X client (btc1). It changes the "seed nodes" list; adding in nodes that will run SegWit2X software. That's fine, except one of the nodes belongs to a company who's goal is to monitor and de-anonymize the Bitcoin network. For those not familar, seed nodes are the nodes the Bitcoin client initially connects to, from which they can learn about other nodes on the network. Giving a company that is actively trying to make Bitcoin unfungible is ... concerning to say the least. > It seems the miners would be the last ones wanting a potentially fatal bug. Do they have less to lose if an exploit/honest bug burns the blockchain? Just because you have a massive mining farm under your belt, doesn't mean you know the first thing about the ins-and-outs of Bitcoin. Mining is such a small part of what is otherwise a massive ocean of domain knowledge needed to understand Bitcoin. The people who contribute to Bitcoin Core have been doing it for 8+ years! And they're a band of cutthroats who aggressively review each other's code. The developers working on SegWit2X have no of those advantages.

kanzure 9y ago

> Is it just that SegWitX2 is considered too rushed? https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/divtc93/ https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone... and https://www.reddit.com/r/Bitcoin/comments/6hkuze/greg_maxwell_a_hasty_snapshot_of_a_few_of_my_views/ https://www.reddit.com/r/Bitcoin/comments/6hkuze/greg_maxwel... and a long-term view i guess https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/diyu6ys/ https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone... more broadly-- although with less explanation-- https://en.bitcoin.it/wiki/Segwit_support https://en.bitcoin.it/wiki/Segwit_support

mhluongo 9y ago

Sounds like you already know. The Core devs say that SegWit2x is too rushed (and I tend to agree), but it's also putting forward a new client that could become the default over Core (btc1), and a potential refresh of the dev team. This is less about the tech and more about the politics, at this point.

statoshi 9y ago

There are many reasons, but one is that few people in the technical community support a somewhat rushed hard fork that does nothing but increase the block size a bit. There are plenty of other things that would be great to clean up if a hard fork is to be deployed. https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/Hardfork_Wishlist

Torgo 9y ago

both sides are in many ways right in their criticisms about the other side, they are just fundamentally conflicting visions of the long term nature of the network. In my opinion the problem here is the network was built so that it operated only by people acting on incentives and those incentives being aligned with the good of the network, and it turned out that miners acting in their own interest wasn't actually good for scaling past a certain size and operating on certain types of transactions.

duckingtest 9y ago
You should ask the question about Core developers' incentives: what do they personally gain from scaling bitcoin? Nothing, at best increase in value of their holdings which they share with lots of free-riders, and only until they sell. They only gain continuously if scaling is prevented as that opens space for their second-layer solutions - presumably to be enabled by planned 'improvements' to bitcoin. Ie. their only incentive is to capture bitcoin for rent extraction. Miners are the only entities that have a continued incentive to improve bitcoin directly. THAT'S the real conflict, everything else is BS.

fpgaminer 9y ago

> Sorry if this is a stupid question, but why not both? By both you mean, SegWit + Bigger blocks? It's not possible today to raise the blocksize without exponentially increasing the computing resources required to run a Bitcoin node. So it's not a parameter that can be easily tweaked without drastic consequences. Also, increasing the blocksize requires what's called a hardfork. That's a backwards incompatible change. Anyone who hasn't updated their Bitcoin software will be left in the dust, and potentially dangerously so. SegWit, on the other hand, raises the effective blocksize to 2MB, patches a bunch of issues, and provides a means to safely enable off-chain transactions on top of Bitcoin. It does all this as a soft fork; backwards compatible. That doesn't mean a blocksize increase isn't appropriate; it needs to happen at some point. But because hardforking is so disruptive, it would be best to roll in other breaking changes while we're at it. We should have a solution to the exponential computation issue, and we should have a mechanism to increase blocksize again in the future without another hardfork. Those are hard problems to solve that will take time. SegWit was meant to be a stop-gap. All that said, I'm not personally opposed to the idea of a more immediate hardfork, ala SegWit2X. I don't think it's the _best_ idea, and I think the hardfork should happen at least 12 months down the road, not 3 months as SegWit2X plans, but the perfect is the enemy of the good. The big issue with SegWit2X is that the developers working on it are not competent for the task at hand, and it's being pushed by parties with perverse incentives.

badloginagain 9y ago
Thanks for the explanation, that makes the bit about 80% of miners needing to adopt make sense. Why do you lack confidence in the SegWit2X developers? It seems the miners would be the last ones wanting a potentially fatal bug. Do they have less to lose if an exploit/honest bug burns the blockchain? Again, apologies if these are uninformed questions- I have only a layman's understanding of BTC.
- fpgaminer 9y ago
  > Why do you lack confidence in the SegWit2X developers? I think the fact that they're pushing a hardfork 3 months after SegWit activates says a lot. We're talking about making all existing clients on a 40 billion dollar network obsolete and open to abuse. Giving only 3 months time to upgrade is absurd. Also, I believe SegWit2X was spawned some time in May? Being generous, that's only been 3 months of development so far. When it comes to software like Bitcoin, where the slightest bug can result in catastrophe, I want the most conservative developers imaginable. The development of btc1 (the SegWit2X client), AFAIK, has not been open. Most of it has occurred behind closed doors, with only the merges to the public repo being visible. Another notable concern is there was a pull request submitted recently against the SegWit2X client (btc1). It changes the "seed nodes" list; adding in nodes that will run SegWit2X software. That's fine, except one of the nodes belongs to a company who's goal is to monitor and de-anonymize the Bitcoin network. For those not familar, seed nodes are the nodes the Bitcoin client initially connects to, from which they can learn about other nodes on the network. Giving a company that is actively trying to make Bitcoin unfungible is ... concerning to say the least. > It seems the miners would be the last ones wanting a potentially fatal bug. Do they have less to lose if an exploit/honest bug burns the blockchain? Just because you have a massive mining farm under your belt, doesn't mean you know the first thing about the ins-and-outs of Bitcoin. Mining is such a small part of what is otherwise a massive ocean of domain knowledge needed to understand Bitcoin. The people who contribute to Bitcoin Core have been doing it for 8+ years! And they're a band of cutthroats who aggressively review each other's code. The developers working on SegWit2X have no of those advantages.