Which was essentially they are treating the new Bitcoin cash as a shitcoin, aka not supporting it.
They took the position that if you want your "free" Bitcoin Cash, move your BTC out of Coinbase.(1)
This led to the inevitable service decay & delays that CoinBase has become well known for in the bitcoin community whenever leading up to a high volume event. (2)
And yet their internal PR team has given somewhat measured responses that "if Coinbase decides to support Bitcoin Cash in the future, it will distribute the balances that accrue at the time of the August 1 fork." (3)
The article w/that nugget goes on to state that when Ethereum split "Coinbase eventually let customers withdraw their share of the new currency, known as "Ethereum Classic," even though it still does not allow it to be bought and sold on the Coinbase site."
Seems like a risky bet not to just say something closer to "Hey if Bitcoin Cash is a thing and worth more than 1% of the original BTC we'll support it. If it's not at the end of 90 days we'll give you a way to take it out either way."
Judging by the volume of concern and disdain from newbies in the Bitcoin forums a lot of people got woken up by this event and what it means to have your decentralized currency controlled by a central authority.
I certainly wouldn't say we are treating it as a "shitcoin". I tweeted out a few thoughts here to share how I think about it:
Hope it helps. Thx!
Here's Coinbase's original statement, which seems to be exactly what the grandparent comment was saying: https://twitter.com/coinbase/status/890986442674941953
"Coinbase does not intend to interact with the Bitcoin Cash blockchain."
It simply says, not supporting BCC now, but might in the future -- we will not acquire the BCCs for Coinbase.
"Wait and see" is usually a reasonable stance for companies to take, but in the case of securities splitting in two, withholding the new securities until their value changes - potentially even keeping them yourself - really shows your hand.
Among other things, this split has thrown into relief the stances various exchanges take with regard to their clients, and anyone researching which exchange to use should take a good hard look at moves like this when considering who to invest with.
It's just strange that Coinbase either wasn't prepared or sees BCH as a threat. Balkanization of bitcoin is unnecessary. Why refuse to support what everyone else supports? https://twitter.com/Yelka_Pineda/status/891020902066003968
There are political elements, for sure, but the overall reason for it is there are a genuine segment of people who believe segwit is kludge, and on chain scaling is the way forward.
Whether or not those people are correct, this chain represents their version of the bitcoin vision, dismissing it as a political move is a tad arrogant.
Helping the split in any way (e.g. by making the split easier to use or by acknowledging it as a reasonable alternative) means facilitating future splits and future balkanization, driving down long term value of BTC.
I agree with this point, and I see Coinbase's comm as trust-building with their (perhaps nonvocal majority?) customers.
The future of this technology cannot work if you must understand the jargon and consequences of a fork (and whatever else can happen), and then form an opinion of your exchanges as a mainstream adopter based upon how they deal with these intricacies. Most people just want something easy to use. Coinbase has allowed that happy path to continue, and I trust them as a result of the manner in which they handled this event.
(Now, for people in-the-know, things are different. But I'd bet that Coinbase's target audience is not blockchain hackers.)
It perhaps makes sense from a business standpoint: why support a new coin from day 1 instead of waiting for the ecosystem to mature? Coinbase already doesn't support other coins like XRP or Monero or whatnot.
Will Coinbase keep BCC coins for itself?
Coinbase does not intend to support or interact with the new blockchain in any way. If this were to change, Coinbase would make those coins available for customers to withdraw, not keep them.
Ironically, not "interacting" with that chain only serves to create more dead coins and thus push up value. Imagine if the value grows considerably... customers might be changing their tune if they feel that they lost out and feel they were misinformed.
The email laid out the process if you want access to the fork.
Downtime should be unacceptable and exceptional for a financial marketplace.
On Coinbase however, downtimes and unexpected behavior are common place, and happen multiple times a week.
It's outright fraudulent when you allow your employees to trade during those downtimes.
What the hell.
Many that left their BTC assets on CB in interest of your core benefits - simplicity, security - will watch with interest for further communication in the coming weeks as price of bt cash stabilizes.
I imagine most of the exchanges that didn't support BCH are going to lose a lot of customers over it.
I didn't know much about the fork up until a few days ago, but I did know to make sure I unloaded everything off of Coinbase if I wanted to benefit and double my tiny little bit of BTC since there had been a notice for weeks now about how they won't support it and a cursory Google search showed what you needed to benefit.
1) I'm a long time miner who owns a massive wealth of Bitcoins.
2) I fund some developers to create a hardfork.
3) I dedicate a small percentage of my mining power to prop up the new coin.
4) Coinbase adds support for the new coin.
5) I deposit all my new split coins at Coinbase, trade for BTC, and withdraw BTC.
6) Using the rest of my mining power I then reverse the depositing transactions to Coinbase by double spending.
I think it's positively absurd that _any_ exchange is supporting BCH.
But to each their own peril.
Coinbase and others saying they'll "wait and see" is really just another bump on a long road of screwing users out of funds. They once again profit off of later price information - and in this case can even decide to argue that they held the assets and so own the BCH - essentially just earning another piece of their users' pies.
I'm amazed people still stick with Coinbase. Any exchange that even nominally 'puts users first' (i.e. isn't trying to screw them for profit) has offered withdrawal of BCH from the get-go. Though OTOH anyone who has seen how Coinbase operates with price fluctuations and so on would have guessed they'd end up doing this for the fork.
Pick your partners wisely folks. :)
It's just very unlikely this could work. Possible, but very unlikely.
Edit: Also, if you have a very large amount of coins, you probably want to sell it off slowly, instead of tanking the market in one go. This makes it even more difficult since if you're caught reversing the first few transactions, your account will be flagged.
If you have >51% of the mining power, you can overpower the rest of the network. Simply pick a block in the past and start mining from there, ignoring everyone else. With >51% of the hashrate you _will_ overcome the rest of the network and enforce your new chain.
They can do it in secret. Build a secret parallel chain while they transact, then release the chain after they've got their BTC.
And 51% is not "insane". It's absolutely tiny. As I said, _any_ of the large pools could do it, right now.
How can you have more than one pool, each with more than half the power?
EDIT: OK I see where you're coming from I think... you mean any of the pools could 51% the forked branch, right?
Imagine a new sport called zoccer. It's just like regular soccer, but if a team scores 5 goals within the 90 minutes, they automatically win the match.
Right now there are only a few small teams playing. But Nike has said they are willing to sponsor a tournament, if there is enough interest.
At any point, Barcelona or Manchester United or Real Madrid or Chelsea or AC Milan or any other large soccer team team can just say "we are now a zoccer club" and swoop in take Nike's money.
They all have the power to switch and dominate the new scene.
You don't need to mine 6 blocks in a row against the other miners, you just need to have a longer chain. So you simply fork the chain, and then submit that as the "real" chain.
With 60% of the mining power and a 6 block deficit, you'd overtake the main chain in 120 minutes (approx; 12 blocks), since you're making up half a block of deficit per block they mine.
If you really had 60% of the mining power, you could undo 3 days of transactions in about a week of mining.
Exchanges can quite easily protect themselves.
All they have to do is increase the confirmation time before they "accept" coins.
The longer you wait, the more secure your coins are. I would suspect that a day is easily enough time to be confident that a double spend won't happen.
Sure, you can build a longer blockchain, but nothing forces other people to accept that blockchain.
IE, people can checkpoint the chain.
Also, if 51% attacks consistently started to happen, that would cause the price if that chain to plummet to 0.
There is no point stealing money that is worth 0.
Not really cool to be ambiguous about stealing $2000+ from your users.
don't keep your bitcoin in exchanges. it defeats three of the main appeals of bitcoin: autonomy, trustlessness, anonymity
Bitcoin itself isn't anonymous at all: All transactions are public. Only via a Laundry you can cover up your tracks.
Zerocoin and Zcash were created to fix that.
The laundry scheme isn't tied to Bitcoin, that's why I think it's wrong to say that one of Bitcoins advantages is anonimity.
So make a new key, and tumble the Bitcoins until you feel safe again.
EDIT https://news.ycombinator.com/item?id=14918545 This just started getting popular if you want to talk more about tumbling.
Serious question: under what legal theory (not loose analogy) is the BCH corresponding to a wallet held by Coinbase property of Coinbase's users and not Coinbase?
That's hardly specific.
> Stuff like this happens all the times in spinoffs
There's a reason I specifically excluded loose analogies.
> the rules are very clear about who is entitled to the proceeds.
And the specific rules that specifically apply to a fork of a cryptocurrnecy and a firm providing wallet services like Coinbase are...what, precisely?
Perhaps general securities laws are written in a way which encompasses this scenario, but I'm asking about the specific applicable laws that cover the situation at hand.
It's more akin to a forex brokerage deciding not to support EUR when it first came out over the lira. You can easily use someone else, Coinbase is hardly the only service around.
Under these circumstances, you'd have serious reservations about passively parking any assets with that particular broker...
Which analogy is the best one depends on your point of view on this debate.
No obligation would exist, but I'd rather take my business to a broker who would do so, given the choice.
Furthermore: It is possible to directly transfer stocks from one brokerage account (similar to a wallet) to another at a different brokerage without having to liquidate assets.
Your "forex brokerage" then decides they're "not going to mess with this newfangled currency", leaving you none the wiser with how they're handling the newly created funds if at all.
If it goes up, they could shrug and say that they had the serial numbers so it was theirs the whole time. If it crashes, they could credit everyone the decreased value of the lira out of money they made by selling off earlier and pocket the rest. (Or take option A and pocket all of it, if the 'good' PR is not worth the slightly decreased profits.)
Considering the prices people end up having gotten "locked-in" on after price fluctuations when using Coinbase, this wouldn't even be "far-fetched" for them so much as par for the course.
Which, if you aren't familiar with what the word "fork" means in the developer world, was exactly what I wanted to hear from a legitimate company like Coinbase.
And BCC will start at 0.01 BTC.
To me you don't need to be a developer to understand that.
Any other easily-googlable questions? :)"
It's not unreasonable to expect some delays accessing their cold storage (which is key split across geographically disparate safe deposit boxes, last I heard)
That said, I was around during Mt. Gox's failure (fortunately didn't lose anything then) so I get a little skittish when I hear about a wallet/exchange experiencing withdrawal delays...
First of all, I've always trusted Coinbase a lot more than most other Bitcoin services. They're a US company, a YC company, I've met the founders, I know some of the employees, they at least appear to be very serious about security, etc.
Second, those 80 BTC are not all of my Bitcoin. I don't completely trust myself to securely store Bitcoin, so I like having some diversification of risk.
But yes, some of it comes down to laziness. I should probably figure out a better way diversify the risk without needing to trust a 3rd party.
You'd argue it's better for me to have wait until the price stabilizes at 2% of BTC before I'm allowed to cash out?
Imagine a bank anouncing they would keep all the dividends of one particular stock, because the didn't like it. That's what coinbase is doing. It plain and simply theft.
Is it your property? It's a benefit that people have decided to extend to whoever controls existing Bitcoin wallets. Do you have an agreement with Coinbase that obligated them to transfer to you any such benefit that should accrue to the Bitcoin wallet they control for you?
1) At last not legaly binding, that had to be there at the very least in red flashing letters, possibly even then it would have been void.
In the absence of any specific agreements with Coinbase regarding usufruct rights, you wouldn't have them (just as you don't have usufruct rights when depositing currency in a bank account) - you don't own that BTC, Coinbase owes you some fixed amount of BTC, and that's that.
Of course, that would be a nice thing to test in courts - after all they decide who owes what to whom, not the algorithms of BTC/BCC.
Right, that's governed by your contract with Coinbase, and is the service they offer.
> Now every btc owner gets bcc.
No, everyone controlling a BTC wallet is now also controlling a BCC (or BCH, I've seen both used as the abbreviation) wallet with an equal number of coins.
I'm guessing rights to coins on alternative chains that Coinbase ends up controlling due to BTC forks are not covered in your contract with Coinbase.
There is a difference between ownership and possion. Technically (in the meaning "how it is realized in computer code") bcc is given to the person possessing btc. But by the law the owner is entitled to the profits of a thing. But coinbase does not own my coins, it merely posses them.
Yes, ownership is a matter of law. By what law does the act of a fork which grants possession of BCH to controllers of BTC wallets grant ownership to anyone else?
> But by the law the owner is entitled to the profits of a thing
That's, at best, imprecise. I own money, which I hold on a bank, which contracts a certain rate of interest (which may be zero) to be paid on it while I hold it there. I absolutely do not own any profits the bank is able to realize through holding the money (any more than, beyond those contracted, I am liable for any costs associated with their holding of money); indeed, their ownership of the net profits realizable by having the money in their hands is central to their business model. (There are restrictions on their ability to use the money they are holding to prevent undue risk of them not being able to pay my money back, but if they gain a windfall, I don't share in it.)
The real question seems to be legally whether BCH is a gift to those owning BTC or those possessing it. In the absence of very strong evidence to the contrary, I think the law is likely to say that who possession was given to also determines who ownership was given to. If I give a thousand dollars cash to everyone I see wearing a green hat, and one of those people had borrowed the hat, the owner of the hat is going to have a difficult time arguing that they own the thousand dollars.
Bch is not a gift. Who should have gifted it? Who is the previous owner? How did the previous owner aquire it? It is a "fructus" of btc. And that belongs to the owner.
This right can be signed away, with life estate or usufructus. But that's a big deal. That can't be somewho implied in a sentence hidden somewhere in a long ToS.
> Coinbase securely stores all Digital Currency private keys in our control in a combination of online and offline storage.
And if you read the whole thing,
> supported Digital Currency
is mentioned multiple times.
That's wrong, and obviously so. That concept is "possession" and not "ownership".
What they write in their ToS doesn't matter, it does not change fundamentals of porperty law. (Well, as every legal argument on the internet it depends on your jurisdiction and the jurisdiction of the coinbase, as coinbase resides in multiple)
Not sure what happened on this month's job thread (too late to delete?); it's not like it's a secret!
https://news.ycombinator.com/item?id=14902743 vs. https://www.coinbase.com/careers/477665
King_mansur 17 hours ago
AvenueIngres 17 hours ago
>* Our APIs are currently powered by Rails with a MongoDB backend
Everything makes so much sense now (Coinbase's single digit SLA)
In case you are wondering what technologies we use at Coinbase, we’re built using a combination
of Ruby, Node.js, PostgreSQL, MongoDB, Redis, Swift (for iOS), and Java (for Android).
> when Ethereum split "Coinbase eventually let customers withdraw their share of the new currency, known as "Ethereum Classic," even though it still does not allow it to be bought and sold on the Coinbase site.
Note the ETC withdrawal option came after ETC spiked in price and retreated like 80%. Coinbase then ended ETC withdrawals at the end of 2016. I suspect you'll see the same with BCH.
Pretending like you're "staying out of it" works 9 times out of 10 for businesses, but in this case it's pretty transparent that they're banking on the ignorance/apathy of users who decide to leave their funds with CB despite warnings so that CB can trade or even pocket the BCH and profit off of deciding based on future price information.
I wouldn't be surprised to see them cross the line into out-and-out fraud someday. Until then, I'd keep my money somewhere else.
My biggest issue with Coinbase is that they claim insured wallets, but actually only insure the 2% of bitcoins stored in their hot wallets. Cold storage is uninsured. If their cold storage gets lost/stolen/hacked, all holders are going to lose 98% of bitcoins. That's not insurance.
The important bit:
> Enforce strong replay protection (require SIGHASH_FORKID and SCRIPT_VERIFY_STRICTENC compliance)
That completely changes the consensus rules of BCH. Again, 5 days before a hardfork. 5 days.
I just ... I can't wrap my brain around why _anyone_ in their right mind would think that BCH should be worth anything, if this is the acumen of the development team.
Why would any exchange trust the code? Why would users trust the code?
If BCH is any kind of experiment, it's not an experiment of big-block vs small block (Bitcoin has had bigger block functionality for over 6 months now). It's an experiment to see if cowboy programmers can patch a live $40 billion network willy nilly and convince everyone that that's okay.
If you don't trust the code powering BCH then you can simply ignore all your coins on BCH and pretend they don't exist, you're in the exact same situation as you were yesterday.
The fear mongering of 'all hard forks are dangerous' is just that, fear mongering, and has no basis in actual reality.
Unless it crashes and burns, in which case faith in Core will be even stronger.
>If anything the fact that things are working as intended(so far) proves that such a change is not nearly as dangerous as BCC developers make it out to be.
A single round of russian roulette where no one dies is not proof that guns are harmless. Things work out until they don't. We should always avoid unnecessary risks even if we have been lucky in the past.
There's a great blog post which summarizes the situation here: https://www.linkedin.com/pulse/why-heck-bitcoin-might-split-...
- reduces the need for fees on transactions, as block space is no longer a sufficiently scarce resources
- makes orphaned blocks more likely, which means that the probability of losing a block that you already successfully mined is increased.
Although I'm a large-blocker myself, Segwit has one thing going for it, namely, fixing transaction malleability. For anyone who has to deal with bitcoin in bulk (any business using bitcoin, basically), malleability is a killer bug -- it makes it very hard to detect if your transactions have made it on to the network, and impossible to chain transactions together reliably. That's who benefits from Segwit, and it's a big benefit.
It also enables some off-chain solutions that are infeasible in a malleable-prone network.
The opposition to Segwit, in my opinion, stems mainly from the fact that it is complicated, and was given priority over the "clear and present" problem of blocks being full that had a simpler solution of hard-forking to increase block size. So it's being held up as a totem by the large-blocking crowd of the poor decisions of Core, and for alleged conflicts of interest around the off-chain solutions.
Other than the risk of a hard fork itself, the negative effects of a block size increase are so small as to be meaningless, for users and for miners.
If bitcoin popularity grows, more transactions with lower per-tx fees will likely result in more total fees per block, compared to a world in which the block size is fixed and individual fees are higher. The induced demand will be a significant factor. This is fairly straightforward economics. This is a good thing by the way =)
Regarding orphan rates: I don't understand all of the gritty details, but I have seen some convincing explanations describing how, if block space isn't scarce, a miner's decision to include an additional tx is largely based on the likelihood that adding the tx will result in a block they find being "orphaned". So it is a self-regulating feedback loop of sorts. And as another poster said, it should affect all miner's equally, assuming they have a sufficiently sophisticated setup (low-latency, well-connected, etc).
For those don't know about orphan rates: An "orphaned" block is one that is wasted (and the reward thus lost). This happens when another miner finds a competing candidate block at a similar time and manages to propagate it more quickly through the network such that it is chosen by the majority as the next block.
A higher orphan rate won't reduce miner profitability. Since everyone would experience the orphaning, the difficulty will stabilize at a lower level and profitability should be the same.
This is exactly what happened when blocksize jumped from 100k to 250k: every small miner jumped to the largest pool (ghash.io) because they were seeing increased orphan rates, driving that pool over 50% of hashing power.
Larger block size increases computation necessary to solve the block, so it is equivalent to increasing the difficulty. Another factor is that you might decide to wait longer to get more transactions in the block. This reduces your chance of solving the block, but increases your payback. I can't see how it could possibly increase the orphan rate because it increases the possible spread for solution time (some people will wait, while other won't). In other words, it should decrease the orphan rate.
I suppose block size increases the network latency for advertising solved blocks... but going from 100k to 250k every 10 minutes does not strike me as being particularly problematic.
Also, I'm trying to verify your claim and I can't see any evidence of it. It appears that different clients were using different block sizes for a long time. The maximum block size on the BTC network has been over 250K since 2013, according to . Also take a look of this graph of orphaned blocks . It seems to be highly variable between 2014 and 1016, but then lower since then. I see no evidence of a sudden increase in orphans. Clearly, having most of the hashing power in one miner will reduce orphans, but I just don't see a connection at all with blocksize.
So what am I missing?
 - http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bi...
 - https://blockchain.info/charts/n-orphaned-blocks?timespan=al...
No, they're merkled, so it doesn't.
> I suppose block size increases the network latency for advertising solved blocks... but going from 100k to 250k every 10 minutes does not strike me as being particularly problematic.
Doesn't matter how often it is, I find a block, I mine the child immediately. You have to wait until you've received and validated the block. It's all about latency.
> Also, I'm trying to verify your claim and I can't see any evidence of it. It appears that different clients were using different block sizes for a long time. The maximum block size on the BTC network has been over 250K since 2013, according to . Also take a look of this graph of orphaned blocks 
Yep, this is now ancient history. Mean blocksizes tend to mask what's really happening, but I recall the orphaning problem and ghash.io spike personally.
And blockchain.info's orphan block measurements are completely unreliable :(
More background: https://rusty.ozlabs.org/?p=535 (my blog)
Some claim that anything larger than 1MB will "hurt decentralization", but many others have shown this to be a very weak argument (sorry, I don't have any links handy).
You don't need every Jane Smith running a full node on a rasberry pi to have robust decentralization.
I actually don't fully understand the reasons for why the pro-segwit side doesn't want to increase the block size (even beyond 2MB), except that it's a slippery slope: with Bitcoin, every time you change the block size it requires a hard fork.
Increasing the block size isn't a long-term solution, because there's always going to be some new ceiling. Eventually increasing the block size will become impractical.
As an aside, some coins have a variable block size to deal with this. AFAIK Monero is the only "major" coin which features variable blocks. It's also the only coin that's actually private.
Can you cite any sources?
The Wikipedia article has two papers that draw similar conclusions about the traceability:
RingCT claims to conceal the amount, and "stealth addresses" claims to obscure output addresses, but I have not verified these claims because I'm reluctant to spend more time verifying a coin that I am skeptical about.
Monero enforces privacy on all transactions by default. Back in the day you could send non-private transactions but during one of the previous hard-forks they removed that ability.
That's it. Remember that decentralization in bitcoin concerns miners, and miners only. 'Nodes' in the whitepaper are synonymous with miners.
Non-mining wallets need to have enough bandwidth to download blocks from miners as they appear. For 1GB blocks 20Mbps is enough. Which means a full verifying wallet for 1GB blocks is practical on a LTE connection.
Storage is also a non-problem with utxo commitments.
Regardless, from what I heard it's not a problem anymore. Even if it was, allowing 'fast passage' for bitcoin blocks seems like a obvious course of action for the Chinese government, it's just another export industry at this point.
You can only say this if you're too ignorant to be worth a damn on the subject, or are insane enough to think that the people who have developed the protocol for the last 8 years are all misguided. If you launch into some conspiracy about Blockstream, Inc., then we'll know it's a combination of both.
> Remember that decentralization in bitcoin concerns miners, and miners only
And exchanges, merchants, consumers. If you have a stake in the ledger by owning or accepting BTC, then you have a stake in the monetary policy of BTC. If you have a stake in the monetary policy of BTC, then you can only hope to enforce it (or attempt to change it) by running a node.
That's before the mathematics of bigger blocks, where the decentralization of miners is threatened even by a 2 MB block size, as those with more hash rate get another bonus due to the latency increases of even a 1 MB block size increase.
If all that mattered in Bitcoin was the decentralization of miners, this game would have been over a long time ago. Anybody who thinks that even a landscape of thousands of miners, pooled by very few pools, is decentralized enough on its own, without others validating and auditing the blockchain, is too capable of assumptions to be let near engineering.
Why does every currency that has ever existed get devalued into dogshit by its policymakers? Every currency dies because those close to the mint can afford devaluation more than those further from it.
This is completely ridiculous. If someone can't send 2MB of data across the network in less than a few seconds, then of course they shouldn't be mining.
Argument from authority
>where the decentralization of miners is threatened even by a 2 MB block size
proof by assertion
>is too capable of assumptions to be let near engineering.
ie 'u dumb'
I'm sure you convinced many people with your thoughtful comment. :)
Proof by assertion i.e. leaving off the second half of a sentence and leaving only the assertion.
ie 'u dumb' i.e. I have picked up on that you are calling me dumb and can only reply by misusing Debate 101 nomenclature.
this article will probably cover it better than I can.
but there was only ever the "big blocks" camp to begin with. Starting with Satoshi and Gavin Andresen. The "small block" movement is the newer "vision" and didn't/wouldn't exist if not for the financial interest suddenly employing the core developers.
The market has wanted bigger blocks for YEARS, and each attempt was slandered/DDoS'ed/attacked. Bitcoin Cash is the result of the market finally getting what it wants.
ASICBoost might be a reason miners are against segwit. But enabling offchain payments kills the P2P aspect pretty hard.
There's no good reason for not having had at least 2MB blocks years ago. And it'd have provided solid info on the real impact, not just fear mongering.
It's silly to say it's not a permanent solution therefore not worth doing at all.
Blocksize should be growing at the same rate that bandwidth availability is growing, but is isnt. Why not? That wouldnt affect decentralization at all.
Secondly, the Chinese miners overwhelmingly support segwit2x, including the 2mb HF that comes with it. If they are trying to keep asicboost (which has not been proven to actually being used), why would they support segwit2x instead of trying to force BU instead? Segwit2x includes....you guessed it....segwit...which disables covert asicboost.
Of all the sales pitches for this coin, Satoshi's original plan makes the least possible sense. This is a fork from Satoshi's coin that removes features, the most important of which is the enabler of payment channels, which if anything was Satoshi's plan.
It's not like it's hard to read Satoshi's writings directly from the source. It's seven years ago, not ancient Rome. The forum has almost all of it intact verbatim and then there's the wiki. In what little sense there ever was a "plan" it's in plain view for everyone to see and read all about what people thought of payment channels, fraud proofs, and everything else.
I'm not for or against either side, but what you just said is just plain wrong and it looks as if you are the one who has not read either the paper or the forum post. He did not mention payment chains either in the paper or the old original post about block size.
It just happens to also be the case that the design Satoshi had for payment channels at that time was horribly broken and left nodes open to DoS attacks. So it was removed by other developers and slowly over time safe versions of the features were added again in the form of BIP68 (sequence number transaction replacement) and BIP141 (segwit).
And large blocks were very much part of Bitcoin's original plan. They were described even before the initial release of the software:
It's strange thing to try to summarize something and have someone question it happened at all. The subtext of this confuses me. This is a public mailing list and most of the people are still around and can answer much better than I can why the design of the opcodes are the way they are. There have been surprisingly many blind alleys in the short life of Bitcoin.
Payment channels are what Satoshi advocated, but it was my impression at the time that many others were more interested in things like sidechains and bearer proofs. The scalability of a system where everyone stores everyone else's transactions for all eternity was and still is the first thing people comment on. The second is the feasibility of everyday payments when the recommended confirmation time is up to an hour, best case. That's the reason people took interest in these proposals, even at a time when there was no economic pressure to do so, as transactions were completely free.
There's was no "original plan" as much as there were discussions. That doesn't mean Satoshi didn't have opinions. If your impression of the block size is shaped by the carnival mirror that is Reddit, it might be interesting to look at the reasoning why this limit was kept in place. But none of that matters in practice right now, because there is overwhelming consensus to double the block size (or quadruple, thinking adversarially) in a backwards compatible way and this will be active in a matter of weeks.
I didn't say that. I said there was no code added with the intention of making payment channels possible. The claim that there was is based on nothing more than conjecture on what the intended purpose of the script was, and the dating of an undated email from Satoshi that was first made public in late 2013.
>There's was no "original plan" as much as there were discussions.
There were multiple statements by Nakamoto explaining how Bitcoin could and would scale. This was widely understood to be the scaling plan, as evidenced by what the Bitcoin Wiki said about scaling all the way up to late 2014. 
It's odd for you to describe your conjecture about the intended use for op codes and data fields as facts, while dismissing clear statements of intent by Nakamoto regarding how Bitcoin would be able to scale.
I merely summarized some of the many discussions that took place on a mailing list a few years ago. There are several pointers to notable posts in the wiki, and the archive contains all the source material.
If you or anyone else were also present in those discussions and wishes to analyze what was said and what could have been, I'll gladly take that discussion private. But I'm not interested in discussing the equivalent of whether the moon landing was staged.
There were lots of discussions around applications of Bitcoin at the time. Payment channels were only one of the suggestions, but it was what Satoshi advocated. Why do you think opcodes for lock times were put in there?
See my answer below. There is no reason to lash out with misguided accusations when everyone can read the discussions in verbatim.
this isn't an opinion about any bitcoin fork, just curiosity about what you are referring to. you say its not hard to read satoshi's words, but you rely on having to read and interpret every single forum post scattered around the internet?
The white paper is only the overview of the underlying system. You're not going to find anything about the marketplace (look that up, it's funny), payment systems or other applications of Bitcoin in there.
That's why I mentioned the wiki. Like all wikis it's bit rotten and outdated, but it contains a lot of good pointers to the source material, both code and discussions. The page about "Payment channels" isn't a bad first guess. It is too old to help you understand modern systems like Lightning, but it will contain pointers to several other payment channels that have been proposed. Including Nakamoto fast transactions, which as the name might suggest was suggested by Satoshi. It turned out to be a flawed design, but the underlying ideas are basically the same as today.
As an interesting side note, that design was based on replaceable transactions. Another popular thing to copy paste into Bitcoin discussions is some conspiracy why this was developed (and it was indeed proposed for removal in the altcoin chain released today), but here you can see it was actually in Bitcoin from the beginning and how it was supposed to work.
You will also note that many other developers were sceptical about payment channels and preferred instead to work on sidechains, ecash bonds, and other methods. It's not like Poon and Dryja worked in a vacuum, but their work looks like it could actually be useful. Personally I don't expect it to be the final design for payment channels, and there are still much work to do on other methods of zero-confirmation high-throughput payment networks for Bitcoin (such as the above mentioned).
There's still a tremendous amount of work on the technical side of Bitcoin almost every day. Much of it just isn't end user visible because people are still laying the ground work for things to come. We're still very early. This is probably also the reason why these types of work doesn't stir up so much discussion on the mailing list. People are not going to re-base their ongoing work to some other codebase just because someone on Twitter threw a tantrum.
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments.
Payment channels, as described by the lightning network, are optional.
The mempool on both chains are practically empty and both chains function the same, until the mempool is full.
One chain will allow for optionally greater throughput via payment channels and possible a block size expansion.
One chain will allow for block propagation upwards of 8 megabytes.
Neither relies exclusively on third parties. The first mentioned chain has an optional ironic future where everyone operates a payment channel and eventually consolidates into one payment channel provider, I guess.
Both chains have other "threats" towards centralization.
The connection between full blocks and transaction fees is here:
if it wasn't clear, I was writing that they are practically empty right now. at the time of writing.
Satoshi's plan is defined by his original whitepaper and his public comments, which are pretty specifci.
If mining of that chain is very low, it will take a long time before the difficulty adjusts downward. So far 6 blocks have been mined on that chain. Rate is maybe one per hour, instead of the usual one every 10 minutes. That puts the difficulty adjustment maybe six weeks out. We'll have to see who mines on that chain. The hash rate may go up or down, depending on what the big miners do. Mining will be unprofitable until the next difficulty adjustment, because the price of the coin is lower than the "mainstream" coin. Confirmations will be really slow. After the next adjustment, the chain will work better.
Something similar happened to some altcoins. Some big miner mined for a while, made some money, ran up the difficulty adjustment way up, and then stopped. Block generation then stalled. This thing self-adjusts, but adjusts to big changes in hash rate very slowly.
Whoever is mining should take about 20% of their capacity off line (presumably devoting it to the other Bitcoin) for a day to force the early hash rate reduction.
After that, BCC should function normally. The financial end is a separate issue; that won't be clear until BCC markets are fully functional.
This is about twice as much as is possible in a block of the old Bitcoin chain.
This will become super interesting.
A lot of popular engineers in powerful positions have been working for years on how to scale Bitcoin.
Now some people said "Fuck that! We will just increase this integer from 1 to 8".
Reminds me of how Linus Torvalds created a simple monolithic Kernel while GNU&Co were working on sophisticated microkernels. Now, 26 years later, everything from servers to smartphones runs on Linux. And GNU Herd is still considered experimental.
If you look at Linux distributions, GNU ist just a relatively small part if you look at lines of code. And of that most is GCC and GDB:
>GNU is not an operating system
Could you please elaborate on this position?
>but a collection of mostly commandline tools.
"Mostly" being the keyword, it also contains multiple implementations of different programming languages as well as their standard libraries, a kernel as well as a package manager. Also in the commandline tools it includes most (if not all) of the tools that are required by POSIX.
> If you look at Linux distributions, GNU ist just a relatively small part if you look at lines of code
I am unsure how this is relevant. In fact, I would argue that this is to be expected, especially when considering that the link checked everything in the main repository.
> Could you please elaborate on this position?
GNU is not an operating system, but some small projects that are used as minor components of Linux distributions
> GNU HURD and GNU MACH
Nobody uses them. They are as relevant as the Windows Services for UNIX
I think that I will have to disagree with that. Instead I would argue that it is actually like saying that Busybox + Linux is an operating system as defined by POSIX or like saying that if Busybox had its own kernel it would be its own operating system as defined by POSIX.
> GNU is not an operating system, but some small projects that are used as minor components of Linux distributions
In my previous post I mentioned some of the components that allow GNU to be used as a modern and POSIX compatible OS. It just so happens that most Bash distributions instead of using GNU Mach use Linux as their kernel.
> as minor components of Linux distributions
I think that calling them as "minor components" is quite a bold claim.
> Nobody uses them
Does not change the fact that they are both part of the GNU project. Nor does it change the fact that one can use them in order to run the GNU operating system without 3rd party software.
Hell, neither does GNU/Linux for that matter (it's not technically POSIX) but busybox is really way too minimalistic to be considered an OS.
In the time frame they are talking about, 1993-1994, almost nobody was using Linux commercially (except tjhe distros selling it). Even after that, Linux was fairly immature. If BSD was going to be a real contender, it still had a sizable lead. That it didn't win in the end leads me to believe other factors were more important, such as the license (which the article you linked also notes).
The BSD license is more permissive and appealing to a lot of organizations, but the requirement of the GPL to give back ultimately lead to a virtuous cycle where companies moved portions of their code in-kernel, because out of kernel is more problematic if it's also not proprietary.
What should give us pause about that?
Even if I had a million dollars in funding, that would buy me mining power for oh so long. All the meanwhile, If I change the rules too much no one would even attempt to join my fork.
Even If I had another million dollars to pay developers to build services on my new fork, there'd be no users and no economic activity. The fork would die.
There SHOULD be a lot of hard forks. Why? Because they're voluntary and most will fail without doing harm (they require consensus to matter). The good ones will survive on merit and act as protocol upgrades.
BCC is currently not congested only due to small number of transactions happening there.
Had this fork been done months before, not many would have noticed or cared. Well played.
The other complaints about expensive nodes are unfounded. Just downloading existing blocks is still very feasible at 8MB even with data caps.
This could have been prevented by going to 2 or 4 megs years back, avoiding the stupid arguments and providing real solid experimental data in the process. It'd have alleviated some of the congestion, too.
The first BCC fork block was mined at 8:12:41 PM, almost 5 hours later.
The 2nd one was mined at 8:33:06 PM, 20 minutes later.
And then an other one not 5 minutes later.
Meanwhile the difficulty remained constant at 860221984436.2223
Clearly there's been a sudden surge in the hash rate.
Someone had to figure out the problem and stuff a block so it could make progress.
Edit: that didn't happen yet, I stand corrected
From what I read, Bitcoin Cash is an alternative cryptocurrency like Ethereum, but based on a change to the original design of Bitcoin algorithms, which increased the basic block size of the transactions. It seems this was done to increase transaction performance.
Also it seems there were competing proposals in the community about how to accomplish the goal of increasing transaction performance, "SegWit2x" and "BitCoin Cash" - and the folks who started the BitCoin Cash fork didn't agree with the SegWit2x strategy.
Anybody else more in the know, can explain it like I'm 5?
Is this a good thing or a bad thing? Are people exploiting this via some sort of arbitrage or whatever to try to make money again? It seems risky?
EDIT: Removed quotes around the word "fork".
No, it's a fork. The fact that you put quotation marks around the word makes it seem like you think it's some kind of allegory. It's as much a fork as it gets. Ethereum was a whole new chain, not a fork.
There's a bunch of political reasons on both sizes as well.
It is an altcoin, but unlike most altcoins it has a shared history with Bitcoin. Basically, at the moment of it's creation (today, August 1st), everone who owned bitcoins owned an equal number of Bitcoin Cash. So now they are two separate coins and two separate chains, but with a shared history.
> Is this a good thing or a bad thing?
It's hard to give a judgement. When Apple started working on a self-driving car, was that a good thing or a bad thing? Hard to say, it more of just was a thing to know, unless you had a horse in the self-driving car race. Bitcoin Cash will either be successful in some capacity or it will flop altogether, but the original Bitcoin certainly isn't going anywhere.
If you don't have a horse in the race, I wouldn't think of it as a good or bad thing. It's just an event that doesn't mean too much unless you are excited about Bitcoin Cash and the principles it stands for, or if you have Bitcoin and don't realize that you also have an equivalent number of Bitcoin Cash (currently trading at like $200 each - a nontrivial sum!)
If the number of bitcoins you have stays the same, but just the block size of storage in transaction changes, then I'd guess it's very similar to a bigger unit of currency.
Not a great analogy I guess, but the point is that it's definitely not the same as having a new denomination of currency. It's a whole new currency entirely, it's just that everyone who had Bitcoin was "granted" (sorta) this new currency too, in the same volume that they had the old currency.
I find it interesting that the two split and then essentially float as different currencies at different rates. Surely, there will be some inter-relationship between them as well.
I don't know much about Bitcoin, so I am curious why you think that? Mostly because I own a (miniscule) amount of Bitcoin..