5 ms·
In my point of view (a strong Bitcoin Core supporter) this is an attack on Bitcoin by most of the big miners that increases centralization of the miners even mo
by xiphias 9y ago
In my point of view (a strong Bitcoin Core supporter) this is an attack on Bitcoin by most of the big miners that increases centralization of the miners even more.
The sad part is that if that if they do what they are signaling, the difficulty adjustment of Bitcoin will take many months, and only 2-3 blocks will be mined every day until then.
- r1ch 9y agoNot really sure I follow your argument. Bitcoin Core has wanted to push Segwit and the miners agreed to it as long as a 2MB hardfork was also forthcoming. The 2MB adjustment is all part of the plan. Segwit has locked in, which while being a "soft fork", already breaks compatibility with the original "Bitcoin". The remainder of the miners who don't agree with this plan have likely already moved to mining Bitcoin Cash, which has no Segwit and 8 MB blocks. I doubt there will be anyone interested in mining a Segwit/1MB fork, it will be technically obsolete.
- RustyRussell 9y agoIt's not true, sorry. The core developers wanted segwit, and refused to agree to another size doubling as well. The miners did it anyway. The bitcoin reference client is not supporting this, and claims that 90% of miners will split are completely unverified (and, to be fair, unverifiable).
- modeless 9y ago> claims that 90% of miners will split are completely unverified The best available evidence is mined blocks, as they are unforgeable. Despite being under no obligation to do so, >90% of miners are currently explicitly endorsing the 2x agreement in their blocks[1]. Any claim that miners will fail to do what they continue to explicitly say they will do should be met with skepticism. [1] See "Segwit2x (intention)" here: https://coin.dance/blocks https://coin.dance/blocks
- RustyRussell 9y ago> Despite being under no obligation to do so Most mining pools set that for you, BTW. And there has been some (unverifiable) claims that the main mining manufacturer, Bitmain, is pressuring their customers on this. > Any claim that miners will fail to do what they continue to explicitly say they will do should be met with skepticism. On the contrary, it's clear we're going to get a split, and in the past we've seen miners mine pretty much exactly according to exchange range on each side of the fork. Annoyingly, lite clients won't be able to choose, because the BTC1 dev refuses to use the hardfork bit (the sign bit of nVersion in the block header) to flag their fork. Lite clients, unlike full nodes, follow the most-work chain without checking; since they anticipate hashrate majority, they seem to be trying to leverage that into a user majority. It's going to get messy :(
- acidus 9y agoWhat are lite clients?
- nadaviv 9y agoLite clients (also called SPV clients) don't fully validate the network rules, but instead follow whatever the miners say blindly. That's unlike a full node, which fully validates every block and transaction on the bitcoin network on his own. Full nodes will insist on following the network rules they're familiar with, regardless of what the miners say.
- oscilloscope 9y agoWhich part isn't true? The miners and many companies were quite explicit about their conditional support for Segwit with the New York Agreement. This is not a surprise move for anyone following the scaling debate.
- nadaviv 9y agoAll of these companies already supported segwit before that. This whole show was for pleasing Bitmain, who were blocking segwit for nearly a year. The companies couldn't care less about doing an hardfork to double the capacity again after segwit, they just caved in to Bitmain's demands.
- r1ch 9y agoMy mistake, I was under the impression Segwit2x was approved by Core. I still think this is a good thing. The Bitcoin Core developers have restricted the Bitcoin network for too long. Perhaps this will serve as a wake up call. Personally I still think Bitcoin Cash was the right move. Segwit adds a lot of complexity and technical debt, bigger blocks were really all that's needed as evidenced by how quickly BCC dealt with the transaction backlogs. Unfortunately the market didn't agree.
- RustyRussell 9y ago> My mistake, I was under the impression Segwit2x was approved by Core. :(
- nadaviv 9y ago> I still think this is a good thing. The Bitcoin Core developers have restricted the Bitcoin network for too long. Restricted it how?
- r1ch 9y agoBy not doing enough to increase network throughput. We could have had a 2-8MB fork years ago and not had to worry with the transaction backlogs caused by the 1MB block limit we're now stuck with.
- RustyRussell 9y ago> My mistake, I was under the impression Segwit2x was approved by Core. Crap, I just found out about the fake "bcoreproject" twitter account, which of course, claims this as a pinned post. And then the fake "nullc_" twitter account (nullc is the common nick of Greg Maxwell, blockstream CTO and core supporter). I feel saddened and a little dirty that this is A Thing :(
- nadaviv 9y ago> Segwit has locked in, which while being a "soft fork", already breaks compatibility with the original "Bitcoin". How so? The very definition of a softfork is that its backwards- and forwards- compatible. Segwit is a softfork that is backwards- and forwards- compatible.
- 6nf 9y agoThat doesnt make any sense. Why would the bitcoin adjustment take many months when 90% of the miners support the segwit2x agreement?
- deleted 9y ago[deleted]
- andrewla 9y agoThis is a very confusing view. If increasing block size were the sole goal, then the miners would switch to Bitcoin Cash and obviate the whole thing. Why the middle ground if they're looking to attack -- if 90% of the hash power switched to Bitcoin Cash then Bitcoin would be dead in the water. The mining community seems split between strong segwit supporters and large block supporters. Segwit alone was not able to achieve consensus and would never have activated. Segwit2x was a compromise that conceded segwit in exchange for an increase in the block size. If the goal of the miners is to increase centralization by increasing the block size, they had the opportunity to switch to Bitcoin Cash when it forked. Note that I don't completely buy the centralization argument, especially when we're talking about a 2MB -- it's not like 1MB is some magical number handed down by Ganesh. The main risk of the increase has always been the attendant dangers of a hard cork. I'm a Bitcoin Cash supporter, but even I'll admit that Bitcoin Cash is a direct attack on Bitcoin (Core), that was not entirely successful, although more successful than opponents thought it could be.
- nullc 9y agoBitcoin Cash is at least honest (except perhaps for the confusing name)-- it isn't attempting to force anyone to use it. It trades as its own asset, and you can see that the market (so far) hasn't really wanted what its offering. Beyond the deceptive name, Bitcoin Cash is at worst an honest difference in views. S2X on the other hand is being promoted with extreme levels of deception and dishonesty (like the content of this article, which states it's an upgrade rather than an incompatible replacement and claims that BU and Classic are compatible full nodes when they aren't any such thing: they don't implement any of the new under-specified S2X rules, ... they don't even implement segwit.) > about a 2MB You're not talking about 2MB-- 2MB is the size of blocks with segwit in effect. You're talking about 4 to 8 MB, which are above what prior research indicated was supportable even while considering a subset of considerations (such as initial synchronization), _and_ while not allowing any safety margin.
- andrewla 9y agoOut of curiosity, can you point me to the prior research that you mention? Aside from a couple of blogs, notably [1], I haven't seen much formal research, much less anything showing bounds on supportability. [1] https://rusty.ozlabs.org https://rusty.ozlabs.org
- CyberDildonics 9y agoAn attack on bitcoin is more like using subversive tactics and huge censorship on forums like /r/bitcoin to artificially limit the max block size and thus transaction throughput. Bitcoin Cash has already proven what everyone who has actually used bitcoin already knew: there is no technical limitation to have bigger blocks and more throughput. The cpu usage is trivial, the bandwidth is trivial.