It was doomed to fail, everything pointed in this direction. I expected it to get more support initially and die slowly, so it happened much quicker than even I expected.

I guess we can finally carry on like nothing happened, right?

The Bitcoin network has forked as of block 478559 !!!!!!!!!

We have August 1 and so far BCC actually silence.12:20 UTC -> After this hour the first block of BCC was to be excavated. Did this happen? No.

HAHAHA! Oh so yeah,  so according to your calculations that's 2% of the global hashing power. Actually it's more like 1.5%.
What other pools are mining BCC? And how much?

At the end of the day, it turns out Bitcoin Cash did something wrong: To put into the market the opportunity to show if there is demand for bigger blocks, and doing it with real money.

Well turns out nobody wants to hardfork into this nonsense. Nobody is using it, and now im doubting if we'll ever see a single >1MB block.

For me, BCash situation is over. Next step in the big blocker agenda is segwit2x. They will be back with the hardforking drums of war, and the price will collapse at time highs. Everyone predicting this is right. Mark these words, and remember to blame everyone involved in NYC when your BTC crashes. Oh and remember also this post when Roger spams the network to create fake demand.

And what's funny is, Greg Maxwell went on the Bitcoin ABC github and warned them about the rule to process a block greater than 1 MB to steal the split, and now it seems that will generate problems.

This is a shitshow already, I think people isn't going to be able to properly dump their coins.

Blocks in the real Bitcoin happen every 10 minutes. This Bitcoin Cash thing (or Bitmain Cash as I like to call it) it's having big, big problems right now. They haven't started mining yet a single block because there is a trigger mechanism that must be activated first, and this activation needs to mine a block that is larger than 1MB.

So not only their nodes are all fake and getting attacked, but they can't even get started mining.

This is what happens when you rush a hardfork. Take notes NYCtards.

Mining is a business, and right now redirecting your hash power to BCH is a loss, because the difficulty is huge while the reward is small. When BCH difficulty will drop, some hashpower/BCH_price equilibrium will be established. So, it doesn't mean that BCH is already dead, but still it's funny how miners, who were crying for big blocks, are refusing to switch to Bitmaincoin, because they have no confidence in its price. Hope it will be a lesson for everyone who didn't realize that Bitcoin's direction is decided by economic majority and not some pure hashrate.

EPIC FAIL!
Bitmain Cash has less then 5% of Bitcoins hash power.
I'm calling it this thing its fucking dead in the water.  There is absolutely no hope for this shit coin.

Even if it manages to produce a block in the next 24 hours it can't survive unless it gains a huge amount of hash power.

https://bitcointalk.org/index.php?topic=1928093.msg20317745#msg20317745
-ck Today at 06:10:07 AM

Not this shit again... If you want to discuss the pros/cons of blocksize/segwit/bu/classic/xt/abc/whatever, take it elsewhere. This thread was about development and activation of segwit2x. I know it's hard to believe that you can discuss one without the other but that's bullshit - you just want to talk about what your current gripes are and find a way to link it into this discussion. I think this thread has run its course and will only be useful in 3 months' time again.  I can't even be bothered moderating posts that stray from it so I'll just lock it.

https://bitcointalk.org/index.php?topic=1928093.msg19682416#msg19682416
Re: The Barry Silbert segwit agreement with >80% miner agreement.
-ck June 21, 2017, 04:46:26 AM


One major one is the belief that segwit provides "discounted" transactions because the fee is only related to their block space usage and not the segregated witness component which is not stored in the block. In some regards this is somewhat true as the resources required to store and transmit the data for a segwit transaction are slightly larger than an equivalent classic transaction. The argument against this is that the data need not be stored long term and that the actual computational complexity of segwit transactions is less than that of traditional transactions. Pools are hoping that a rapid change to 2MB blocks means most people will continue to use traditional transactions and the accompanying fee schedule. There was a lot of debate about what block weight and segwit transaction weighting should mean if core implemented 2MB+segwit themselves, but because they felt the argument for 2MB+segwit was a bait and switch exercise by miners they abandoned it. Which means the miners are implementing their own segwit2x without even really thinking about it, and leaving the alleged discounted transactions in. Funny...

The second major reason is that they've been arguing for so long that a bigger block is an easy, simple, safe way to scale that they can't change their minds now. It's hard to know if they're aware it's unnecessary and it's a massive saving-face exercise, or they still believe they're right about it, but the end result is the same.

Finally there's the concern that if they don't strike while the iron's hot, then we'll be stuck with 1MB+segwit only as a transaction expansion mechanism for the foreseeable future. Since there is no other hard scaling solution committed to the development timeline, in some respects this is also partially true. If we wait till another scaling solution comes around, and yet again it provides more discounted ways of increasing transaction capacity without a concomitant rise in fees, then rising fees as an incentive to miners are once again at risk.

In essence it's primarily about fees and secondarily about saving face.

==> and this is where Greg's 2 layer model doesn't make any sense: the waste tax is going to be paid by all transactions.  Those on layer 1 and those on layer 2.  And in order for this tax to be sufficiently high, these transactions have to be sufficiently scarce.  If those on layer 2 are too cheap, then everybody will run to layer 2, and layer 1 will be left without "market pressure" and hence without fees.

It doesn't matter what mechanism you use to build layer 2 on top of layer 1.  In the end, transactions, whether they are on layer 2 or on layer 1, have to become scarce enough that people will be willing to pay fees to get them.

Most probably, Greg realized this.  1 layer or 2 layers, it doesn't matter.  The problems are the same.  In the end, transactions need to pay for the waste in proof of work, which is the ultimate security of the bitcoin system (and THAT is the other fundamental flaw in bitcoin).  And you need scarcity of these transactions to establish a fee market, whether that market is essentially on layer 1 or layer 2 doesn't matter.  If transactions are too fluid and cheap, the system will crumble in any case.  So you CANNOT allow cheap and fluid transactions, even if they are only cheap and fluid on layer 2.  Because they would crash the market on layer 1

Yeah, right.

For a newbie and your short posting history of nonsense, you surely have established yourself as a credible source for reliable information.

Thanks for the specific information you gave it really helps lot and it clarifies the thing I am confused of, and the things I don't know because at the time it is announced, I only know that the bitcoin will be split in two and if it will be done by the 1st of August the blockchain transactions will become faster, that's all I know but right now I understand it clearly because of the specific information you shared. Thank you.

Did you know? MtGox CEO blamed "transaction malleability" for the $1 billion hack of their website.

It's called sarcasm...

Mainly, I fail to see why it's even a post. For years, Maxwell has

• argued against any sizable increase
• argued that one of the key reasons to keep blocks small is to keep fees high, and
• argued that we should "_decrease_ the [tx] limit below...300k/txn/day level"

I'm not sure why it matters that he still holds the same relative position he's held for so long (or why he matters, even)....

https://reddit.com/r/btc/comments/6o872y/behind_on_bitcoin_drama_a_short_history_of_scaling/dkg42ct/

Behind on Bitcoin Drama? A (Short) History of Scaling by Lukovka in btc

[–]jstolfi 1 point 2 days ago*

For some reason ;-) Blockstream's Pravda suddenly felt the need to post the Official Approved History of The Block Size War Scaling. Spin Doctor Peter Rizzo starts off on a good foot with a nice "sidetruth":

>    OCTOBER 8 2014 -- OCTOBER 9, 2014
>
>    SCALING ENTERS THE SPOTLIGHT
>
>    In the face of growing network use, bitcoin developer Gavin Andresen proposes increasing bitcoin's capacity by changing the network's rules.

Sorry Tovarisch, but scaling has been discussed since 2009 by Satoshi and others. It was always been clear that bitcoin would scale well enough to meet the expected demand, and that the 1 MB safety limit should be raised before it affected the operation of the network.

The Block Size War started in February 2013, when Core contributor Gregory Fulton Maxwell (/u/nullc) claimed that Satoshi's design was doomed and the salvation would be to switch to a radical redesign of his own.

Namely, Greg proposed to push all user payments to a completely different "layer 2" network (still to be designed), and restrict bitcoin to a vehicle for high-value "settlements" of the same. The capacity of bitcoin was to be intentionally restricted to be less than the demand, so those "settlement" payments would be forced to pay very high fees by means of a "fee market".

Gavin (the chief bitcoin developer at the time) and Mike Hearn rejected that plan, and insisted that the increase in the block size limit, that has been planned since 2010, was long overdue.

The next slide says

>    DECEMBER 8, 2015 -- DECEMBER 9, 2015
>
>    SEGREGATED WITNESS DEBUTS
>
>    After months of debate, developer Pieter Wuille debuts a scaling proposal called Segregated Witness. Developers are wildly positive about the proposal and its implications for future network growth.

I was in the US when the canonical American view of China, for business expediency, had to change from 1 billion treacherous criminals (as they were depicted, for example, in every other episode of Hawaii Five-O) to 1 billion industrious and friendly guys more huggable than panda bears.

As part of that spin-flipping event, PBS aired a multi-part documentary on the history and culture of China, from a very positive view. I was looking forward to see how they would handle the episode of the Opium Wars -- in which England, with help of French and US warships, invaded China and forced the government to allow the free sale of opium from British India.

But they didn't: between one sentence and the next, without breaking the narrative, the documentary jumped directly from early 19th century to early 20th century, omitting completely any reference to those wars.

Tovarisch Rizzo achieved the same feat there, skipping over the most important event of bitcoin's history since the collapse of MtGox: namely, the creation of Blockstream, their hiring of key Core developers, the defenestration or Gavin and Mike, and the imposition of Greg's two-layer redesign as the new roadmap for the project.

The "reporter" also managed to pack an amazing number of "false truths" in that little text:

>    After months of debate

There had been no public debate or announcement of SegWit before Pieter presented it as the last talk of the last of the two Blockstream-organized Bitcoin Scaling conferences. Rather, SegWit had been developed quietly by Blockstream's employee Pieter and other Blockstream staff/contractors/associates (Greg, Luke, Lombrozo) for months.

>    Pieter Wuille debuts

Not "Pieter Wuille" but "Blockstream". It became obvious that the two "Scaling" conferences were meant to be just a stage for Blockstream to present SegWit, which was just one step of their already-defined roadmap

>    a scaling proposal ... its implications for future network growth.

SegWit has nothing to do with scaling or network growth. It fixes the so-called "malleability bug" which has no impact on the network's capacity.

The proposed implementation of SegWit by Core includes a change in the rules for counting the size of a block, that is expected to be equivalent to a plain increase of the block size limit to 1.7 MB.

(Calling SegWit a "scaling proposal" is ironic given that the first thing that Greg blasted against in that February post was that increasing the block size limit would only "scale" the capacity by a constant factor.)

>    Developers are wildly positive about the proposal

People can judge by themselves whether the reactions to Pieter's talk were "wildly positive".

In fact SegWit is, by far, the most controversial change to the protocol ever. To the point that it led to open death threats against a major miner who is reluctant to accept it...

https://np.reddit.com/r/Buttcoin/comments/6ndfut/buttcoin_is_decentralized_in_5_nodes/dk9c27f/
Core/Blockstream/Greg Maxwell explained. Great post by JStfolfi (np.reddit.com)
submitted 6 days ago by jonald_fyookball

jstolfi 160 points 6 days ago*

SegWit is another messy imbroglio that resulted from that pile of lies. The "malleability bug" is a flaw of the protocol that lets a third party make cosmetic changes to a transaction ("malleate" it), as it is on its way to the miners, without changing its actual effect.

The malleability bug (MLB) does not bother anyone at present, actually. Its only serious consequence is that it may break chains of unconfirmed transactions, Say, Alice issues T1 to pay Bob and then immediately issues T2 that spends the return change of T1 to pay Carol. If a hacker (or Bob, or Alice) then malleates T1 to T1m, and gets T1m confirmed instead of T1, then T2 will fail.

However, Alice should not be doing those chained unconfirmed transactions anyway, because T1 could fail to be confirmed for several other reasons -- especially if there is a backlog.[//b]

On the other hand, the LN depends on chains of the so-called bidirectional payment channels, and these essentially depend on chained unconfirmed transactions. Thus, given the (false but politically necessary) claim that the LN is ready to be deployed, fixing the MB became a urgent goal for Blockstream.

https://np.reddit.com/r/Buttcoin/comments/6ndfut/buttcoin_is_decentralized_in_5_nodes/dk9c27f/
Core/Blockstream/Greg Maxwell explained. Great post by JStfolfi (np.reddit.com)
submitted 6 days ago by jonald_fyookball

jstolfi 160 points 6 days ago*

In my understanding, allowing Luke to run his node is not the reason, but only an excuse that Blockstream has been using to deny any actual block size limit increase.

The actual reason, I guess, is that Greg wants to see his "fee market" working. It all started on Feb/2013. Greg posted to bitcointalk his conclusion that Satoshi's design with unlimited blocks was fatally flawed, because, when the block reward dwindled, miners would undercut each other's transaction fees until they all went bakrupt. But he had a solution: a "layer 2" network that would carry the actual bitcoin payments, with Satoshi's network being only used for large sporadic settlements between elements of that "layer 2".

(At the time, Greg assumed that the layer 2 would consist of another invention of his, "pegged sidechains" -- altcoins that would be backed by bitcoin, with some cryptomagic mechanism to lock the bitcoins in the main blockchain while they were in use by the sidechain. A couple of years later, people concluded that sidechains would not work as a layer 2. Fortunately for him, Poon and Dryja came up with the Lightning Network idea, that could serve as layer 2 instead.)

The layer 1 settlement transactions, being relatively rare and high-valued, supposedly could pay the high fees needed to sustain the miners. Those fees would be imposed by keeping the block sizes limited, so that the layer-1 users woudl have to compete for space by raising their fees. Greg assumed that a "fee market" would develop where users could choose to pay higher fees in exchange of faster confirmation.

Gavin and Mike, who were at the time in control of the Core implementation, dismissed Greg's claims and plans. In fact there were many things wrong with them, technical and economical. Unfortunately, in 2014 Blockstream was created, with 30 M (later 70 M) of venture capital -- which gave Greg the means to hire the key Core developers, push Gavin and Mike out of the way, and make his 2-layer design the official roadmap for the Core project.

Greg never provided any concrete justification, by analysis or simulation, for his claims of eventual hashpower collapse in Satoshi's design or the feasibility of his 2-layer design.

On the other hand, Mike showed, with both means, that Greg's "fee market" would not work. And, indeed, instead of the stable backlog with well-defined fee x delay schedule, that Greg assumed, there is a sequence of huge backlogs separated by periods with no backlog.

During the backlogs, the fees and delays are completely unpredictable, and a large fraction of the transactions are inevitably delayed by days or weeks. During the intemezzos, there is no "fee market' because any transaction that pays the minimum fee (a few cents) gets confirmed in the next block.

That is what Mike predicted, by theory and simulations -- and has been going on since Jan/2016, when the incoming non-spam traffic first hit the 1 MB limit. However, Greg stubbornly insists that it is just a temporary situation, and, as soon as good fee estimators are developed and widely used, the "fee market" will stabilize. He simply ignores all arguments of why fee estimation is a provably unsolvable problem and a stable backlog just cannot exist. He desperately needs his stable "fee market" to appear -- because, if it doesn't, then his entire two-layer redesign collapses.

That, as best as I can understand, is the real reason why Greg -- and hence Blockstream and Core -- cannot absolutely allow the block size limit to be raised. And also why he cannot just raise the minimum fee, which would be a very simple way to reduce frivolous use without the delays and unpredictability of the "fee market".

Before the incoming traffic hit the 1 MB limit, it was growing 50-100% per year. Greg already had to accept, grudgingly, the 70% increase that would be a side effect of SegWit. Raising the limit, even to a miser 2 MB, would have delayed his "stable fee market" by another year or two. And, of course, if he allowed a 2 MB increase, others would soon follow.

Hence his insistence that bigger blocks would force the closure of non-mining relays like Luke's, which (he incorrectly claims) are responsible for the security of the network, And he had to convince everybody that hard forks -- needed to increase the limit -- are more dangerous than plutonium contaminated with ebola.

SegWit is another messy imbroglio that resulted from that pile of lies. The "malleability bug" is a flaw of the protocol that lets a third party make cosmetic changes to a transaction ("malleate" it), as it is on its way to the miners, without changing its actual effect.

The malleability bug (MLB) does not bother anyone at present, actually. Its only serious consequence is that it may break chains of unconfirmed transactions, Say, Alice issues T1 to pay Bob and then immediately issues T2 that spends the return change of T1 to pay Carol. If a hacker (or Bob, or Alice) then malleates T1 to T1m, and gets T1m confirmed instead of T1, then T2 will fail.

However, Alice should not be doing those chained unconfirmed transactions anyway, because T1 could fail to be confirmed for several other reasons -- especially if there is a backlog.

On the other hand, the LN depends on chains of the so-called bidirectional payment channels, and these essentially depend on chained unconfirmed transactions. Thus, given the (false but politically necessary) claim that the LN is ready to be deployed, fixing the MB became a urgent goal for Blockstream.

There is a simple and straightforward fix for the MLB, that would require only a few changes to Core and other blockchain software. That fix would require a simple hard fork, that (like raising the limit) would be a non-event if programmed well in advance of its activation.

But Greg could not allow hard forks, for the above reason. If he allowed a hard fork to fix the MLB, he would lose his best excuse for not raising the limit. Fortunately for him, Pieter Wuille and Luke found a convoluted hack -- SegWit -- that would fix the MLB without any hated hard fork.

Hence Blockstream's desperation to get SegWit deployed and activated. If SegWit passes, the big-blockers will lose a strong argument to do hard forks. If it fails to pass, it would be impossible to stop a hard fork with a real limit increase.

On the other hand, SegWit needed to offer a discount in the fee charged for the signatures ("witnesses"). The purpose of that discount seems to be to convince clients to adopt SegWit (since, being a soft fork, clients are not strictly required to use it). Or maybe the discount was motivated by another of Greg's inventions, Confidential Transactions (CT) -- a mixing service that is supposed to be safer and more opaque than the usual mixers. It seems that CT uses larger signatures, so it would especially benefit from the SegWit discount.

Anyway, because of that discount and of the heuristic that the Core miner uses to fill blocks, it was also necessary to increase the effective block size, by counting signatures as 1/4 of their actual size when checking the 1 MB limit. Given today's typical usage, that change means that about 1.7 MB of transactions will fit in a "1 MB" block. If it wasn't for the above political/technical reasons, I bet that Greg woudl have firmly opposed that 70% increase as well.

If SegWit is an engineering aberration, SegWit2X is much worse. Since it includes an increase in the limit from 1 MB to 2 MB, it will be a hard fork. But if it is going to be a hard fork, there is no justification to use SegWit to fix the MLB: that bug could be fixed by the much simpler method mentioned above.

And, anyway, there is no urgency to fix the MLB -- since the LN has not reached the vaporware stage yet, and has yet to be shown to work at all.

No, I censored you all on my ownsome. They had trolled you quite satisfactorily and proved you wrong many times over.

Quote from: Troll Buster on July 07, 2017, 08:54:52 PM

Just because you say so doesn't make it true.
It's obvious to professionals that gmaxwell doesn't know what he's doing.

Let's see some honest feedback from non fan boys:

You make no sense...

No one is going to agree to be a lemming and to walk over a cliff just because all the lemmings in front of them are going over the cliff, right?

If the agreement is not clear and does not provide a clear and unambiguous mechanism, then how the fuck they going to be on the same page regarding what it is that they are agreeing to do, exactly?

There's no code to follow or review, so there are way too many ambiguities in the supposed agreement.  And it is not even bad faith to have a different way of interpreting what it requires.

https://www.reddit.com/r/btc/comments/6ohyyk/979_of_the_blocks_mined_today_supports_segwit2x/dki5f6m/

[–]JustSomeBadAdvice 3 points 7 hours ago

> Are you sure? All I see is voting for BIP91 and BIP91 doesn't say anything about a 2 MB HF.

BIP91 is segwit2x. Core is trying to pretend that they are different, but the email that proposed BIP91 puts a lie to that claim in the very first line of it. BIP91 was a compatibility kluge, nothing else.

The btc1 client forks to bigger blocks 3 months after segwit locks in, regardless of anything else. Meaning those who are running that software at that time will be forking. The fork can't be rolled back unless it is completely abandoned, as it requires a >1mb block at fork time.

Now that BIP91 has locked in, segwit signaling will be forced in the next few days and segwit will activate shortly after that. 3 months from that moment, BTC1 and the big blockers will fork; Core's only challenge is whether or not their legacy chain will be viable or completely stuck due to lack of miners.

We're free of core now.

> And why do we need to rush Segwit? If we have three months to wait for 2 MB we would have had three months to wait for Segwit. There is no sane reason to do Segwit before the hardfork.

Segwit would have timed out before the hardfork upgrade could be safely rolled out to the users that needed the upgrade. That was the reason. BIP148 added more urgency, but it wasn't necessary. If anything the speed at which segwit2x just activated, before the final release client had even dropped, should be an indication of how badly miners want Bitcoin to Actually Scale instead of be Bitcoin Jr.

> So, to summarize, the NYA did, what the "Dragon's den" wanted.

It did not. Read the emails, comments, posts, and github comments they've been posting nonstop trying to make the project look bad. The project's charter explicitly called out that signatories must be willing to provide resources including developer support and testing/logistics support. They knew full well that they were going to have to do this without any assistance from Core whatsoever.

We're free man.

but I think we can go ahead and recognize that Troll Buster isn't going to be contributing anything more than the chest thumping.

Fun fact: Mike Hearn contributed a grand total of something like 6 relatively minor pull requests-- most just changing strings.  It's popular disinformation that he was some kind of major contributor to the project. Several of his changes that weren't string changes introduced remote vulnerabilities (but fortunately we caught them with review.)

Yes, I've been using Bitcoin pretty much its entire life and I can easily demonstrate it. My expertise is well established, why is it that you won't show us yours though you claim to be so vastly more skilled than everyone here?

From 2009? ... you know that the blocks are not accessed at all, except by new peers that read all of them right?  They're not really accessed any less accessed than blocks from 6 months ago. (they're also pretty much completely incompressable with lz4, since unlike modern blocks they're not full of reused addresses).

As to why? Because a 10% decrease in size isn't all that interesting esp at the cost of making fetching blocks for bloom filtered lite nodes much more cpu intensive, as that's already a DOS vector.

Uh, sounds like you're misinformed on this too:  Pruning makes absolutely no change in the security, privacy, or behavior of your node other than that you no longer help new nodes do their initial sync/scanning. Outside of those narrow things a pruned node is completely indistinguishable.  And instead of only reducing the storage 10%, it reduces it 99%.

Lz4 is fine stuff, but it isn't the right tool for Bitcoin almost all the data in Bitcoin is cryptographic hashes which are entirely uncompressed.  This is why a simple change to more efficient serialization can get over 28% reduction while your LZ4 only gets 10%.     As far as other things-- no we won't: block data is not like ordinary documents and traditional compressors don't do very much with it.

(And as an aside, every one of the items in your list are exceptionally slow. lol, for example I believe the top item in it takes it about 12 hours to decompress its 15MB enwiki8 file. heh way to show off your ninja recommendation skills)

If you'd like to work on compression, I can point you to the compacted serialization spec that gets close to 30%... but if you think you're going to use one of the paq/ppm compressors ... well,  hope you've got a fast computer.

Can you show us a non-trivial patch you made to any other project anywhere?