Bitcoin Forum

If so, what is preventing BTC developers from watching how well the BCC fork plays out and, if it has no bugs or issues, adopting an 8MB block for itself and supplanting the BCC advantage?

BCH was done to prevent Segwit and the Bitcoin Cash lightning network will work in a different way.
Also you cannot cancel transactions on Bitcoin Cash, so you can do 0 confirmation transactions.

The only reason Bitcoin Cash works thus far is because nobody uses it. If it were to be working at scale (that is, full blocks) people running nodes would get kicked out of the network, eventually leading only to datacenters running the BCH network. Also 0 confirmation transactions would once again be nonviable, unless they keep raising the blocksize forever, guaranteeing there are only a couple nodes worldwide. At that point your coin is nothing but a Paypal with a token, and that is exactly what Roger Ver wants. BCH's whole scaling roadmap is an one way ticket to centralization, which is funny because this is what they say about LN.

The point is that Bitcoin Cash network is already centralized but the market doesn't care. The current transaction capacity is at 8MB which is equivalent to 2.5 million transactions per day. As long as the tx volume is below 2 million per day, or 6x the current rate of bitcoin, the fees will very low.

Bitcoin at the moment is hijacked by greedy miners and that will mean it´s death.

Well now with coinbase support and BCH mining pairs, a lot of people are going to start using it. Wanna bet 1 BTC/5 BCH that the fees will remain low?

No, the 8MB blocksize is not the only difference.  The misnamed pretender “Bitcoin Cash” does have a security vulnerability (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9230) called “covert ASICBOOST (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html)”, which Bitcoin fixed with Segwit.  That is a very important feature to the parties reasonably presumed to be exploiting it for profit.  BCH also has tx malleability (also fixed by Segwit), the quadratic sighash problem which makes for trouble scaling (fixed by Segwit), obsolete technology (no upgrade to Segwit), and no forward-compatible script version system (introduced by Segwit).  Due to that last, it will be unable to simply copy over forthcoming new Bitcoin features such as Schnorr signatures and MAST, which will depend on Segwit.

“Bitcoin Cash” also has the advantage of having “fired Core”.  Who needs developers?  Instead, they have a clique of promoters who lack sufficient credibility to sell used cars, but do have plenty of money to manipulate the market and prop up their pet scamcoin.  Also, they have the domain name “bitcoin.com”—which never had anything to do with Bitcoin (https://bitcointalk.org/index.php?topic=88.msg806#msg806), according to Satoshi.

But to me, the most important feature of “Bitcoin Cash” is centralization.  The network is safely under control of a nanny named Roger Ver (or more likely, his handlers).  Why, it’s comfy as a padded playpen!


False.  0-confirmation transactions were never safe, and are not safe now in so-called “Bitcoin Cash”.  Also, Bitcoin transactions cannot be “cancelled”.

Bitcoin now has a strictly opt-in feature, Replace-By-Fee (RBF), which permits clearly marked RBF unconfirmed transactions to be replaced.  The majority of transactions do not use this feature; and anybody accepting 0-conf can distinguish RBF from non-RBF transactions, so as to wait at least 1 confirmation for the RBF ones.  Non-RBF transactions cannot be “cancelled”.  Thus, in Bitcoin, 0-conf is just as safe as it ever was—that is, not safe.

To understand the problem with 0-conf, you must first discard all wrongheaded notions of “the mempool”.  There is no such thing as “the mempool” (and if there were, then we wouldn’t need miners).  Each and every node has a mempool, consisting of unconfirmed transactions it happens to have seen.  Everybody’s mempools are each a bit different from each other.  In both Bitcoin and “Bitcoin Cash”, a double-spender needs to get a transaction into the mempool of the node he wishes to fool, and a conflicting double-spend transaction into the mempool of the miner who mines the next block.  Nothing on either network can affirmatively prevent this, although it is moderately difficult on both networks.


Well said, except that 0-conf was never viable; and that’s not a blocksize issue.

It half-amuses, half-disgusts me that all the BCH Ver-sycophants are too stupid to ask one question:  Why were Bitcoin fees low before?  Well, that would be because it wasn’t popular!  It was not so valuable; few people used it; thus, its blocks were almost empty.  And why are BCH fees low now?  (Crickets chirping.)


What a compelling argument for “Development & Technical Discussion”:  Ignore the plain fact that fees will skyrocket in any blockchain with full blocks, and instead, toss off a wager you know nobody will take.  Feels safe, doesn’t it?  I’ll bet you don’t even have that much money—figuratively speaking, I mean.

I agree that 0-confirmation transactions were never really secure. However,
many operators had a business model that was based on 0-conf transactions
(e.g. the now defunct betting site Directbet). Therefore something seems
to have changed, because otherwise these operators would still be able
to use 0-conf transactions.

I can´t imagine that this is only due to increased fraud by people attempting to double-spend
a gambling transaction (e.g. double-spend after their bet already lost on Directbet). There has
to be a technical explanation why 0-conf transactions are not widely used anymore
when that was still the case in 2014-2015 (at least at Bitcoin gambling sites).

Satoshi said that 0 confirmation transactions were never to rely upon, or at least he literally considered 0 confirmation users as "second class citizens" in the bitcoin network:

http://image.ibb.co/nBMk1b/satoshi_on_0_confirmations.png

It's not clear to me if he had 0 confirmations to be part of the network model. Big blockers often argue that 0 confirmations are perfectly fine and the only reason they aren't now is due the blocks not being big enough. 0 confirmations never made any sense to me. Maybe for smaller transactions, but I would rather trust an LN channel than a 0 confirmation transaction.

Does the absence of 8 MB block imply inadequacy in decentralized crypto currency or does it make it even
more centralized?If the coders are reliable, does the  8 MB lag pose any threat that could raise any doubt of
non-performance?

Increasing the blocksize ALWAYS come with a centralizing factor, since the rule of "the bigger the blocksize, the harder to host your own node" always applies, therefore, you want to avoid raising the blocksize for as long as possible.

Reducing on-chain size with segwit and Schnorr sigs et al are ways to go around this, some consider anything but legacy transaction not safe, then again, if you don't consider that safe, you can't be a BCashier pretending BCash is a better idea.

Hahaha that is one way of looking at it

This is a nice thread. I also wanna ask if one can transfer one's coin from BTC to BCC and vise versa.

It was not long ago that businesses were relying upon 0-confirmation transactions, and had very little "credit losses" from doing so. The reason why this was generally safe in the past was because businesses could look at the transaction fee attached to a transaction, and very confidently predict if a transaction would confirm within ~3 blocks, even if the network had very "bad luck" in the subsequent three blocks.

Today, most transaction included in blocks cannot be predicted they will be confirmed three blocks ahead of time because the necessary transaction fee to get a transaction included in a block is so volatile, and has the potential to spike.

Also, the default settings of Bitcoin Core (which in part are in place due to realistic memory limitations) result in many transactions being dropped from many (most?) nodes' mempools that were expected to confirm quickly at the time the transaction was broadcast because of spikes in transaction volume and/or spikes in necessary transaction fees required to get a transaction confirmed. This means it is often trivial to double spend a 0-confirmation transaction that does not include a "RBF" flag that was expected to quickly confirm (within 4 hours/25 blocks) as of when it was broadcast.

For a business using Bitcoin Cash, the business can look at a transaction and reasonably infer if a transaction will quickly confirm, and nodes are not needing to drop large percentages of transactions from their mempools after they relay said transactions.

Maybe. But centralization is a direct result of ASIC, first and foremost.

Bitcoin has sufficient real world problems, it may not be helpful to argue against alternatives.

Perhaps better to attempt to understand them, their various advantages and disadvantages.

differ teams and boss..

When I looked at the comparison of both even on several other forked coins website, the only thing that made sense to me is the 8mb while bitcoin having 1mb others are technical jargons to me. And this made me even felt that there is no much difference in the two because as we have the 1mb of bitcoin getting filled up which led to the challenges being witnessed everywhere, sooner or later, the 8mb would equally be filled up all that it could take a longer years than bitcoin and we are all back to where we all started.

What I expect is that rather than every circle of developers going about creating their own forks and claiming its the best bitcoin or the real bitcoin, the vision bitcoin and all sorts of nomenclature, all efforts should be contested at making it better just like what you suggested or if that is not possible, projects such as SegWit or the recent lightning network should have been way back implemented.

Also, just knowing that this thread will be answered by knowledgeable people, why is segwit not being adopted quickly? Was it not agreed as helpful for the comunity?

No. They just don't know that they care YET. They will care. A lot.

There are several reasons in my opinion - though I admit that some of them are pure conjecture on my part:

1. Wrong priorities
Some exchanges that are responsible for a large part of daily Bitcoin transaction volume have been
busy adding altcoins instead of deploying SegWit. This is partly understandable, because every additional
trading pair of course increases their revenue. On the other hand they would also save huge amounts
of money due to the 20-40 % that they would save on Bitcoin transaction fees when consolidating deposits
or processing user withdrawals.

2. Political motives
Some exchanges don´t support the scaling roadmap of Bitcoin and instead want to see a Bitcoin fork succeed
that uses a different solution for scaling. Therefore it is obviously in their interest to stall SegWit adoption as much as possible
in order to sabotage the effort. This seems to be partly successful, because many people are wondering why
SegWit hasn´t really had an effect on the mempool and on the transaction fees.

3. Incompatible business model
Some services like BitPay have a business model that won´t really work if Bitcoin becomes a
settlement layer for high-value payments. They need fast and cheap transactions, because otherwise
no one would use their service to pay for goods. This is why they added support for different altcoins
instead of deploying SegWit, because even a 20-40 % decrease in transaction fees due to SegWit
wouldn´t really save their current business model.

There are many other reasons, but this should be enough for now.