The first Bitcoin Cash block has been mined
blockdozer.com
blockdozer.com
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.
(1) https://blog.coinbase.com/update-for-customers-with-bitcoin-...
(2) http://bitcoinist.com/mass-exodus-from-coinbase-spawns-12hou...
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:
https://twitter.com/brian_armstrong/status/89248668753155686...
Hope it helps. Thx!
http://blog.kraken.com/post/1150/bitcoin-cash-and-a-critical...
http://blog.kraken.com/post/1183/bitcoin-cash-and-a-critical...
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
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?
No. 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.
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.
7) Profit.
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.
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.
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.
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.
> 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.
[1] https://www.coinbase.com/legal/user_agreement?locale=en-US#1....
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
[flagged]
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.
https://github.com/Bitcoin-ABC/bitcoin-abc/blob/174846aaaf56...
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[1] 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-...
Specifically, it:
- 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 [0]. Also take a look of this graph of orphaned blocks [1]. 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?
[0] - http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bi... [1] - 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 [0]. Also take a look of this graph of orphaned blocks [1]
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:
http://monerolink.com/monerolink.pdf
https://drive.google.com/file/d/0B7e8g-wJId8md3FYUGF0TlB5NjQ...
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. :)
this article will probably cover it better than I can. https://coingeek.com/core-think-bitcoin-cash/
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:
http://www.mail-archive.com/cryptography@metzdowd.com/msg099...
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.
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.
https://jochen-hoenicke.de/queue/#1w
The connection between full blocks and transaction fees is here:
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.[1] 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.
[1] https://medium.com/@SimpleCrypto/bitcoin-cash-difficulty-adj...
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.
http://thevarguy.com/open-source-application-software-compan...
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.
https://www.reddit.com/r/Bitcoin/comments/5p9iv8/arguments_a...
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.
https://en.bitcoin.it/wiki/Block_size_limit_controversy#Argu...
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..
Despite all this, market forces may drive one or the other coin up or down over the next days and months depending on how important the differing features are to the community. It could also turn out that there is a market for both feature sets and they both do well.
Inside? First salvo in a massive political civil war between interests with different goals. There's this Bitcoin Cash implementation vs Segwit.
And really, there were lots of skirmishes before any of that even. This is a long, old battle, and the fork is more like a resolution (two sides peacefully going their separate ways) than a continuation of the war.
If it doesn't (and it's far too early to tell) then this schism isn't going to go away. It might end up moot but right now this isn't resolved, it's just a big push.
It's also the largest in a long while.
It's just a strategy. Granted, it's a good one.
For years the market wanted to increase the arbitrary 1mb blocksize limit. They finally got fed up with the stalling/lies and forked off.
people were misled into thinking Hard forks and >1mb blocksize was "dangerous". Bitcoin cash proves these to be false.
>nothing bad happened
>"it's totally fine guys"
I mean, you can say the same about a lot of disasters
My take on this is this is partisans of big blocks saturating the original chain; as if to try to prove a point. It does cost them some little amount of money, though.
In particular this section:
> How to redeem my BCC?
> BCC wallets will require you to import your seed or your private keys, which can be exported from Electrum. Doing so will expose all your Bitcoin funds associated with that seed to the BCC wallet you decide to use.
> Therefore, after the BCC fork, but before you enter a seed or private key in a BCC wallet, you should move all your funds to a new Electrum wallet, with a new seed. You will still be able to use the old seed or private key with BCC, because BCC has replay protection. Wait until your funds are confirmed in your new Bitcoin wallet, before you enter the old private key in a BCC wallet. This will protect your BTC funds from rogue/untrusted software.
https://blog.ledger.co/managing-the-bitcoin-cash-fork-7229dd...
I would expect this relationship to hold -- that for every dollar BCH gains, BCT is prevented from gaining a dollar. Unless somebody has some good reason this wouldn't be the case.
At the same time ETH ran up from about $205 to $225.
I would expect the total value to decline if there's not one clear winner, since the value somewhat depends on network effects (e.g. Metcalf's Law)
Following your assumption that means that the split increased the total value by about $600!
Make of that what you will. :)
I did happen to write my comment around the top of the price chart, as the current price is $447.
Coinbase has not honored giveaways of these previous coins to their customers, so it sort of makes sense that they treat this one exactly the same. Otherwise they'd have to answer why they treated this one differently.
(Most other coins have just copied the UXTO set from a certain block height and not the entire historical blockchain. This saves a lot of space as you can start with megabytes of data instead of a hundred gigabytes. There are probably marketing reasons why it was made this way.)
Ironically, Coinbase holding onto the Bitcoin Cash (by not supporting it, and hence not letting their users sell it) is probably helping it, since Coinbase users cannot dump their BCC for a quick buck. As you say, it's kind of a giveaway..
[1] https://www.viabtc.com/quot/realtime?currency=btc&dest=bcc&c...
[1] https://coinmarketcap.com/currencies/bitcoin-cash/#markets
You get all your tweets on the new site for free.
Same with BCC. They copied the Bitcoin database at block 478558. So if you have a coin in a BTC account before block 478558, you now have the same coin on the BTC chain, and a copy of that coin on the copied BCC chain.
To use it, you just need to use a BCC wallet, the same way you'd use a BTC wallet to use BTC.
But if you don't know your private key (usually because your coin was on an exchange) then you are out of luck. Google if your exchange will credit you BCC.
There are technical differences that may make one or the other succeed.
Some fun facts: Forked should have name XBC as per ISO bt thats already taken so they named BCH
1st BCH block 478559 & BTC Block no 478559 where mined by ViaBTC
ViaBTC dedicated BCH block to her daughter by adding comment on 1st Block of BCH "�_M�*/ViaBTC/Welcome to the world, Shuya Yang!/�q���3�0c"
People will use whatever fits their use case and there will be well-oiled exchanges arbitraging the valuations.
I'm probably neglecting some of the short term effects of a splitting chain here.
And Bitcoin Cash with increased block size limit.