Until BitcoinXT activates the 8 MB limit -- indeed, until someone mines a block larger than 1 MB -- both are the same bitcoin, with the same miners and users.

If and when an oversize block gets created and solved (in 2016) the chain will split, and each branch will have a set of miners; but it will not be two coins still, because each transaction issued will be executed in principle in both chains.  Only expert clients will be able to craft transactions that execute in only one chain; for normal clients, that may happen, but largely outside their control (and Core clients may get quite confused).

However, if and when BitcoinXT gets 75% of the hashpower, the rest of the miners and most of the services and clients should quickly switch to it too (even Mircea Popescu).  So, when the limit is finally raised and an oversize block gets mined, the Core branch will have  less than 1 block per day; while it will be business as usual for the XT clients.  

AFAIK most or all of the BitcoinCore developers work for Blockstream.  Their "team" page lists Adam Back (President), Greg Maxwell, Pieter Wuille, Matt Corallo, Mark Friedenbach, Rusty Russell, Patrick "Intersango" Strateman, Jorge Timón, and Glen Willen. There may be others.  Luke Dash Jr works for Blockstream as contractor.  Peter Todd works half-time for Viacoin, an altcoin that claims to be bitcoin done right (e.g. 25 times faster confirms).

Blockstream got 21 million USD of venture capital from a mix of investors.  Obviously Adam and Greg must have described to the investors some business plan, that must have involved some mix of sidechains, perhaps the Lightning Network, the fee market and fee increases, turning bitcoin into a settlement layer for high-value transactions, etc..  Presumably they relied heavily on the prediction that the network would become congested in early 2016 and the fee market would then arise.

It is therefore quite likely that, if the block size limit were to be lifted, even if only to 2 MB, their "business plan" would collapse.  For 2 or 3 years at least, there would not be any fee market, and there would not be any need for an overlay network of any type. 


Luke tried to convince me a few weeks ago that the protocol is so complicated that the only safe way to use it is by using the BitcoinCore implementation; and that disaster would occur if one used an implementation that did not have exactly the same quirks and bugs.  However, that is bullshit.  You can write your own code from scratch, or take either the Core or the XT implementation and patch them as you like.  If you make any mistakes, only you will be affected.  If you don't like Mike and Gavin, you can take the Core code and add the patches of XT that implement the 8 MB limit.  I saw on reddit a claim by someone that he had already built one.

The point is that bitcoin and bitcoin forking do not require consensus and a single implementation.  What Mike and Gavin are doing is normal and bitcoin should not care.  Bitcoin's robustness does not come from preventing forks, but from each player choosing whether to play the game
[/quote]

Those are relay nodes, not miners.  They have no direct say on the bock size increase; but by showing support they may convince miners to switch. 


They were OK with 8 MB but did not want to switch to XT; they wanted all the devs to get together.  But that was weeks ago, and it is clear that Core will never agree to any increase.  Who knows what they are thinking now.

Many of those "major economic players" as well as 4 of the 5 largest miners have expressed support for increasing the block size limit to 8 MB, in some form.  That is not yet support for BitcoinXT, of course.  If the Core devs had some respect for the community, they would cede and raise the limit in the Core too; and then the crisis would be resolved.  

Need I remind everybody that it is LIMIT that is being increased, not the block SIZE? The limit has been 1 MB since 2010, but the average block size is still 450 kB, and has never hit the limit until the recent "stress tests".  

So, if the limit is increased to 8 MB, either by Core and/or by XT, it would make no difference until mid-2016, when the average block size is expected to be ~800 kB.  Thereafter, the difference will be that, with 8 MB, the average block size will continue growing slowly,  in the measure that adoption continues to increase (perhaps to 1.5 MB in mid-2017, 3 MB in mid-2018, etc.); whereas, with 1 MB, there would be recurrent traffic jams starting in mid-2016, and adoption would stop growing.

Motivation of the "stress tests" now revealed: Coinwallet.eu has a wallet that computes the correct fee to get through their "tests".

http://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981

Note that they plan another mega stress test for September.  

Someone should do a *real* spam attack on bitcoin, not like those stupid "stress tests" that use fixed fees. If BitcoinXT prevails and the block size limit is lifted to 8 MB in 2016, both "stress tests"  and real spam attacks will become 10 times more expensive.

To do a real spam attack, you pick a goal percentage of transactions that you want to delay, say 50%.  Then you start issuing spam transactions at such a rate and with such a fee that 50% of the legitimate transactions in the pool are kept out of the next block.  

Typically, when a new block is mined, there will be 450 kB of legitimate unconfirmed transactions in the pool.  To keep half of those out of the next block, it suffices to issue 775 kB of spam transactions, all with a fee F that is higher than the median of the fees in the pool.  The next block, if it is full, will take your 775 kB of spam and 225 kB of legit traffic, leaving the other 225 kB  on the pool.  Then, you must issue quickly another 775 kB of spam with that fee F, and keep adding more spam, with increasing fees if needed, as more legit transactions arrive, so that the top 1 MB of the pool will include at most 225 kB of legit traffic.  

The average capacity of the network is less than 1 MB every 10 minutes, because there are many empty blocks even when there is a backlog in the pool.  Thus, on average, it may be enough to issue only 575 kB of spam every 10 minutes, rather than 775 kB, if you are able to guess the required fees exactly.  

You keep doing that until your budget is exhausted.  During that attack, a backlog of legit traffic will develop in the pool (mixed with some spam), growing by at least 225 kB of legit traffic every 10 minutes.  If your budget is enough to keep up that attack for one day (144 blocks), the backlog will then clear ay the rate of ~300 kB every 10 minutes; so the legit transactions alone will take at least ~100 blocks to clear.  The average delay for the transactions that had the bad luck of being below the median will then be ~20 hours (instead of the ~10 minutes of normal conditions).

The fee-adjusting tools that have been proposed by the Blockstream devs, to be used in the "fee market", woudl make this atack much cheaper.  inevitably, some of yous spam will end up in the backlog, with fees that are smaller than most of the legit traffic there.  So, instead of issuing new spam transactions with increasing fees, you could use Peter Todd's replace-by-fee feature to re-issue the spam of yours that is in the pool.  

To foil this attack, everybody would have to raise their fees so high and so fast that the attacker will run out of funds after a few blocks.  I am too lazy to compute now what would be a suitable Branson-level fee.  

Another solution is for everybody to use a smart wallet that picks a fee that is guaranteed to be above the median of the fees picked by all other clients using that same smart wallet.  But I think there may be some obscure technical obstacles to that approach.

You have never looked at a typical quarterly financial report, or at any official website or document by a company directed at investors, I presume.

But at least it is evidence of sincerity.  Do you know how many bitcoins other bitcoin evangelists own, by chance?

Gavin and Mike have the right to do what they did, and each client has the right to choose which version of the software to run.

Just as some jerk created NotBitcoinXT, another jerk could create NotBitcoinCore -- a version of BitcoinXT that accepts puts out blocks with the Core stamp, but actually accepts block with more than 1 MB, and may generate them if there is enough stuff in the pool.  What woudl be the point of doing either, I don know.

However, I must concede that this initiative already made two valuable contributions to the project.

One, it underscored the silliness of the idea of blockchain voting.  That is the typical hacker mentality at work: use a complicated programming solution to avoid a simpler one that requires human interaction.  The right way to do a protocol change is to describe the intended change to the major players and users, listen to their opinions, try to convince them, find a solution that they could all agree to (that is what 'consensus' means to normal people), then formalize the proposal, and confirm that it will be accepted by the majority of affected people.  Only  then post the code that will implement the change, programmed to be activated at a fixed block number, a couple months in the future.

That is what Gavin and Mike did. That is what the Blockstream hackers are quite incapable of doing.  And that is what the Blockstream devs mean when they accuse Gavin and Mike of "populist tactics".  And, finally, that is why the Blockstream devs like soft forks: because they allow changes to be implemented without having to explain and justify them to the community.  (That is also why they did not program a grace period in the BIP66 fork: because the purpose of the grace period is to send alerts to all clients still running the old version -- and they did not want to do that.)

Two, the NotBitcoinXT initiative prompted this message from Alan Back, Ph. D., to the bitcoin developers' mailing list:


So Adam Back, Ph. D., thinks it is okay (if not wonderful) that nodes lie to the bitcoin community in order to preserve Blockstream's exclusive control of the protocol.  

Think of that before trusting your savings to a system whose security strongly depends on the integrity of the BitcoinCore implementation.

Theymos is the creator/mod of /r/bitcoin, a section of reddit ("subreddit").  As such he has substantial freedom to decide what gets posted and who gets banned.  

However there are some general reddit rules for mods (e.g. he should not moderate topics in which he has a financial interest, or ban people who did not violate any rules), and there are clais that he violated those limits.    

But those who are unhappy with it have moved to /r/bitcoin_uncensored or /r/bitcoinxt.  He has no authority over these.


Theymos claims that he is not directly involved with moderation here, and leaves that task to other moderators.


The Blockstream devs have admitted already that Sidechains are not a solution to the scaling problem.

LN is a large-scale payment system to be built using Payment Channels.  Think of a Payment Channel as a length of pipe, and LN as an oil refinery.  What has been implemented so far is a two tanks with a pipe between them.  The other details of the refinery are still only at the vague ideas stage; and no one knows whether the refinery will be economically viable.  Indeed, there are several back of the envelope calculations indicating that the LN will be as viable as a balloon made of reinforced concrete.

Even if the LN can be designed and implemented, even if it were to be viable, it will not be "bitcoin itself", not even remotely.  

Bitcoin was designed to be a peer-to-peer payment system that did not require a trusted third party.   The only reason why Satoshi designed and implemented it was because no such thing existed, and he thought that he had figured out how to build one.  

The LN will depend totally on trusted intermediaries -- the hubs.  Even though in theory anyone could set up a hub, or any two parties could set up a payment channel between them, in practice that will not be possible, for many reasons.  The hubs will necessarily be large companies that will have to be registered, licensed, comply with AML/KYC, etc.  They will charge significant fees on top of the fees of the bitcoin network, and will have lots of control over the clients' payments.  For one thing, they will be able to block payments and freeze funds for months, block payments between specific clients (whose identities they will know), and may even be able to divert payments or steal coins.  Almost like the current banking system -- only much more inconvenient and expensive.

I am sure that Satoshi would not have spent a couple of years creating bitcoin, if it had to end up that way.  One thing that the world does not need is another lousy banking system.

It happens when your computer goes to sleep and stops fetching data from the server.  Just do a full refresh of the page (SHFT-reload in my browser).

Why did the image pass through my mind of a miner vigorously banging his head with a spoon?

And 0% XT blocks mined, which is what really matters.  But that in only 2 days, and there are still 6 months to go before the XT have reason to be embarassed.  

On the other hand, subscriptions to /r/bitcoin have been dropping (now at 171,663, 747 online).
On the other hand /r/bitcoin_uncensored got 1485 subscribers in 1-2 days, and another subreddit whose name cannot be uttered in diesen Heil'gen Hallen got 3,227.

The BitcoinXT version may never conquer 75% fo the hashpower.  Then there will be no fork, and people can continue using either version, indifferently, modulo future upgrades and forks.

Suppose the BitcoinXT does get 75% of the hashpower.  Since BitcoinXT implements a grace period between the 75% vote and the actual lifting of the limit, there will be time to alert all remaining Core players to upgrade, and hopefully they will do so.  Then only the XT branch will survive, and there will be no other complication for the clients.

However, if the Core players are stubborn, the two branches will persist for a while.  There would be

  a "XT" branch, with more PoW, mined by the XT miners and accepted by all XT players and (IIRC) by the SPV Core clients; but also

  a "Core" branch, with less PoW. mined by the Core miners and accepted by full Core nodes only.

If the ratio were to remain 75% XT : 25% Core, thenThe XT branch may start out with one block every ~13 minutes, and the Core branch with one block every ~40 minutes; but eventually their difficulties would readjust so that both will have 1 block every 10 minutes.

Given the way that the way the fork is programmed, every transaction issued will be executed in principle on both chains; so, for most clients, there will seem to be only one coin.  However, by accident or intentionally, a transaction may eventually include fresh coins mined after the fork, and therefore will be valid only on the branch where those coins were mined.  An expert bitcoiner could exploit that trick to sell one version of coins and buy more of the other, or spend each version independently.  However, as soon as the impasse resolves itself, and everybody moves to one of the two branches, the other version of the coins will become useless and worthless.  So one should be wary of buying "minority coins" or accepting them in payment.

But the tide may turn, and instead of everybody moving to XT, some miners may decide to go back to Core.  If the XT slice drops to less than 50%, AFAIK the XT version will NOT reduce the block size limit again.  Then there will be just one persistent chain of 1 MB blocks, but with occasional side branches that are orphaned after a few blocks.   All miners will mine on the persistent branch, but when a XT miner solves and posts an oversize block, a new side branch will start, and it will be mined by XT miners until the Core branch overtakes it.   Full Core nodes will only see the main branch, but full XT nodes as well all SPV clients will see the chain "stutter"  as transactions get confirmed in the side branch, then unconfirmed, then confirmed again.  The closer the hashpower is to a 50:50 split, the longer and more frequent the side branches will be.

In short, the states with mixed XT/Core mining are messy, and not much fun for consumers or traders.  I don't think that there are significant opportunities in them.

BitcoinXT is an independent implementation of the reference bitcoin software ("Bitcoin Core") with a small change in the bitcoin protocol, specifically in the rules that define when a block is valid. Instead of limiting the block size to 1 MB, BitcoinXT says that blocks up to 8 MB are OK.  (Currently blocks are ~0.450 MB each on average; but traffic is increasing the network will become congested when it reaches ~0.700 MB/block, which is expected to happen in 6--12 months time.)

That BitcoinXT change is programmed to become effective only in 2016.  Until then, BitcoinCore and BitcoinXT will do the same thing, on the same blockchain. Clients, miners, and relay nodes can use either version, indifferently.   After the criticla block, when the change becomes effective, things may get complicated.

If enough miners approve the increase in the block size limit, it is very likely that everybody will switch to BitcoinXT before the critical block.  If too few miners approve, it is almost certain that everybody will continue using BitcoinCore, or switch back to it.  Either way, clients should check, by the end of 2015, which version (Core or XT) has got more mining power, and make sure that their wallet is compatible with that version.  Then they will not even notice the fork.

The possible complication is if the community gets stuck in a half-way state, with almost equal mining power on each side.  Then there may be two blockchains, lots of orphaned blocks and branches, etc.. 

You don't want to know about that possibility; just pray that it does not happen, and, if it does, just stop issuing transaction until the impasse gets resolved as above.  Even after the critical block, all the unspent coins that were created before that block will remain there, no matter what happens. 

Riight... like Pravda was advancing the cause of communism... 


Hm, yes, I guess so... 

YESSS!!! Bitcoiners trying to hurt bitcoiners over some stupid political squabble!

The world has not seen such entertainment since Christians killed Christians over the right way to be a Christian in the Thirty Years' War

The mods at /r/bitcoin are now deleting every post that mentions the existence of the "other" implementation of bitcoin, whatever the contents.  Dozens of posts that had hundreds of upvotes and hundreds of comments.  And banning users who defend it, too.

So much for the great age of freedom and stuff that bitcoin was going to bring.

Oh, and the bitcoin "news" webshites, like CoinDesk, have been as silent on the topic as any statist newsmedia would be.

Satoshi just came back to declare it dead. 

I think that doubling every two years is silly, because it is ridiculously optimistic.

But note that what will increase is the block size LIMIT, not the block SIZE (although the small-blockians always say the latter).  

The block SIZE will just continue to grow (or not) gradually, proportionally to the traffic.  Right now the numbers are ~450 kB and ~120'000 tx/day.  The traffic doubled in the past 12 months, from 60'000 tx/day, growing almost constantly at 5000 tx/day per month.  

The traffic now is more than half of the network's capacity, which was revealed in the recent stress tests: ~750 kB/block, ~200'000 tx/day.  (It is less than 1 MB/block because of many empty blocks, due to the way miners work, and to partially full blocks, that some miners generate by choice.)  

If it keeps growing at the same pace of the last 12 months, and the block size limit remains 1 MB, "traffic jams" should become frequent at peak hours in mid-2016, or maybe earlier, when the traffic will be 180'000 tx/day or so; and then the traffic should stop growing, as any new adoption will have to be matched by a similar "un-adoption".  

If the block size limit is increased to 8 MB, the traffic may keep growing naturally and gradually beyond that 180'000 tx/day limit.  There is no reason to think that the traffic will grow faster just because the size limit has been lifted.  The limit has been 1 MB/block since 2010, and yet the traffic has always been well below the network's capacity, even during the Nov/2013 rally and later crashes (except for the recent "stress tests").  So, the doubling of the limit every two years will, quite probably, have no effect whatsoever on the traffic (and therefore on the average block size).

"Prices all over the place" was a characteristic of the pseudo-trades by which Willy the Goxbot's slave accounts transferred coins to the master account.  Nothing to do with those Gemini trades, of course.