Well, after the last one on 2012-11-28 the price basically remained flat for 5 weeks.   

There was a rally after that, true; but before and after that halving there were several other rallies and crashes, which can hardly be consequences of it.  So, there is no good reason to think that the Jan--Apr 2013 rally was connected to it, either.

Things may be different this time, of course.  However, I would guess that the only direct effect will be a drop in the hashrate.  If that happens, there may be indirect negative effect on price. 

I am not "biased a bit". I think that raising the blocksize LIMIT is necessary and urgent to avoid severe degradation of bitcoins usability.  It should have been a no-brainer non-event, if the developers affiliated with Blockstream had not dumped a huge mountain of FUD in its way.  

From all that I read, I concluded that the arguments against it, like the alleged risk of centralization, are ridiculous excuses.  To me it is obvious that the Blockstream guys simply want the network to become saturated, as soon as possible and at any cost, and don't give a damn about what that would mean for its users.  In fact they want to convert the network from its original goal (peer-to-peer payments without the need of trusted middlemen) to a totally different purpose (the settlement layer of their overlay network) without the knowledge, much less the consent, of all the other players -- by abusing their control of the Core implementation.  

Perhaps the Blockstream guys genuinely believe that the Lightning Network will be viable and working in six month's time, and will be much better than bitcoin as it is now.  However, I am increasingly doubtful of that.  They cannot be so naive.  Perhaps they just intend to push all users to companies like Coinbase and Circle.

I don't have particular admiration for Gavin, Mike Hearn, or Jeff Garzik, but I believe that in this issue they are just trying to do what the Core devs should be doing:  keep bitcoin usable for its original purpose, at least as well as it has worked so far, for a few more years.  

No sign of consensus as of yesterday.  The "old devs" (Gavin, Mike Hearn, Jeff Garzik) want to increase the limit before the traffic gets close to saturation.  The "new devs" (Adam Back, Greg Maxwell, Peter Wuille, Luke-Jr, and others -- most of them working for Blockstream Inc) want instead to see the network saturate so that a "fee market" develops.  Since it is a discrete (binary, boolean) choice, no compromise is possible.

Gavin backed down from his original 20 MB proposal to 8 MB, starting early next year, with automatic increases afterwards. Jeff proposed a "compromise" plan with 2 MB blocks.  Peter Wuillie made a counter-proposal to increase the limit only in 2017 -- that is, no compromise.

Not really: even with low traffic, the expected time to the first confirmation woud still be 10 minutes.

However, if traffic keeps increasing at the current pace, in 6 months time it will hit the 1 MB ceiling. Then there will be frequent "traffic jams".  No matter what fees clients use, the average wait time then may be hours. Raising the limit to 8 MB would postpone saturation for several years.  "Traffic jams" could also be created by "spam attacks", but they will be much more expensive and less effective with 8 MB limit rather than with 1 MB.

Indeed most (all?) of the ~80'000 "test" transactions in the queue have 0.2 mBTC/kB fee, so if you pay more than that you should get confirmed in the next block or two -- as used to be the case before the stress test, even with minimum fee.

However, there are several hundred transactions with fee 0.4 mBTC/kB, and another few hundred paying 0.5.   It is not clear whether they were issued by the tester, too, or by normal clients who raised their fees to bypass the backlog.


The fact that most transactions pay the same low fee seems to make it a "brutal test" rather than an outright attack.  That is, the tester is not really trying to block the network (he woudl have to kep raising the fees to do that), but does not give a damn about the ~12'000 transactions that are caught in the backlog with fees below 0.2 mBTC/kB, whose issuers probably have no idea of what is going on.


There is no way to prevent a spam attack by someone who has a large enough budget.  All one can do is make such attacks more expensive, hence less likely.

Increasing the block size to 8 MB would make a similar attack 15-20 times more expensive.  It would also clear the backlog 15-20 times faster.

Just watched Patrick Byrne's announcement.  Basically he announced "t0.com" (tee-zero), a registry for asset ownership that uses ~~the~~ a blockchain to record actual ownership of stocks and similar things.  He claims it will give shareholders actual ownership of the shares, and contrasted it with the current system, under which a shareholder does not actually own a share of the company, but only has an IOU from a privileged company that actually owns all the shares.

They are ging to use the Bitcoin blockchain at first, but he said something like "It is ledger agnostic - it can work on Bitcoin, on Ripple, and on another one we are working with but can't tell you yet".

AFAIK, the "simulation" is only for the top graph (what fees you would need to get expectation of N minutes to first confirmation), and for the dashed line (capacity) on the bottom graph.  The backlog (solid line) and incoming traffic (dotted) on the bottom graph are real data.

The information about the fees being paid by teh unconfirmed transactions comes from this other site.  The big step at 0.20 mBTC/kB must be largely due to the test transactions. 

Right now there appeared another large step at ~0.50 mBTC/kB; that may be test transactions, too.  However, those transctions are still below the 750 kB level, so they may affect only those transactions (a few thousand?) that paid between 0.20 and 0.35 (beware that the graph is changing all the time).  But they may be a sign that the "tester" is raising his annoyance goal...


Sorry, I don't follow the news about the general economy.  Bitcoin watching already takes too much of my time...

Another "stress test" just started.  The backlog is already 60 MB of unconfirmed transactions, and the input traffic is ~ 3 MB every 10 minutes, or ~5 kB/s .  So far, the tester is paying 0.2 mBTC/kB, like the last one.  Will it keep at that, or increase the fees later?

Another "stress test" just started.  The backlog is already 60 MB of unconfirmed transactions, and the input traffic is ~ 3 MB every 10 minutes, or ~5 kB/s .  So far, the tester is paying 0.2 mBTC/kB, like the last one.  Will it keep at that, or increase the fees later?

At the time (and even now), many bitcoiners totally ignored China, and assumed that the Apr/2013 and Nov/2013 rallies were "Western" things.  While the causes of the first are still debatable, the Dec/2013 crash and the events in Mar--May/2014 should have been enough to prove that the Nov/2013 rally was due to Chinese demand.

A comparison of the prices among the various exchanges shows that Bitfinex and BTC-China were clearly leading the Apr/2013 rally, while the Nov/2013 one was pulled BTC-China, Huobi, and OKCoin (ad possibly other Chinese exchanges for which I have no data).

Popper's book (in the excerpts that have been published elsewhere) seems to say that the April/2013 boom was due to big whales like Andreessen and the Fortress Group investing lots of money in bitcoin, after attending a bitcoin presentation by Wences Casares in March 2013.

As I wrote before, my own favorite theory is that the first 2013 bubble started in January, when BTC-China and Bitfinex made bitcoin popular in Shanghai and Hong Kong.  My guess is that Mark or some other MtGOX insider decided to profit from the bubble by trading in China with the customers' bitcoins.  That guy then created Willy, a robot which would buy bitcoins from other MtGOX customers at a 10% premium with non-existent dollars.  The gy then would withdraw those coins and sell them in China.  The plan must have been to bring the revenue from those sales out of China, and use part of it to fill the clients' dollar accounts, pocketing the profit. 

That scheme apparently continued all through the Nov/2013 peak.  But the plan would have collapsed in Dec/2013 when the PBoC blocked the accounts of the Chinese exchanges.  Otherwise, the purchases of bitcoins by the Chinese during 2013 would have meant at least half a billion dollars in CNY leaving the country, in exchange for a bunch of "worthless nothings" that had been imported without licenses or taxes...

By the way, Popper's account is not incompatible with this theory.  The big investors who started buying in March/2013 may well have bought at Bitfinex, or even at BTC-China, for reasons of liquidity.

Ashley Barr, A.K.A "Adam Turner", the first Mt.Gox employee (Jun/2011--May/2012), is doing an Ask Me Anything (AMA) session on reddit.

Ashley Barr, A.K.A "Adam Turner", the first Mt.Gox employee (Jun/2011--May/2012), is doing an Ask Me Anything (AMA) session on reddit.

According to the CSV file available from this site, this is the situation of the unconfirmed transaction queues, about one hour ago

    total unconfirmed transactions 97'544 kB (~195'000 tx)

    fee range (mBTC/kB)                  tx kB       #tx
    ---------------------------------  -------  --------
    0.000000000000 --  0.199893048128     2806     ~5600 
    0.200000000000                       58519   ~107000
    0.200000000001 --  0.200099800399       45       ~90
    0.200105764146                       30139    ~60000
    0.200105820106 --  0.200219538968     5390    ~10600
    0.201005025126 --  5.235602094240      645     ~1300

The tx counts are estimated, assuming that the average transaction has 0.5 kB.

Because of empty and partly empty blocks, each block can take ~780 kB of transactions (~1560 tx) , on average.

The ~107'000 transactions with fee exactly 0.2 mBTC/kB  must be the spammer's.  

The ~60'000 transactions with fee exactly 0.200105764146 mBTC/kB may be also from the spammer, or from some wallet that uses that specific fee.

The ~1300 transactions with fees 0.201 mBTC/kB or higher should have been processed in the next block.

The ~5600 transactions with fees smaller than 0.2 mBTC/kB should sit there until the backlog clears (min 48 hours).

Coinwallet.eu posted on reddit their plans and an analysis of their first aborted attempt.  There has been no communication after the second successful attempt, ~July 7--19, that reached 250 MB of unconfirmed transactions.  

AFAIK, there has been no announcement or explanation, by anyone, for the current "test" that peaked at 50 MB of  backlog and used higer fees (0.2 mBTC/kB).  This too seems to be a test (or an attempt to drive fees up), rather than an outright attack: any transaction that pays 0.25 mBTC/kB should confirm as fast as it did before the "attack".

Abut a week ago, someone also ran another test with average 5 tx/s (the normal traffic being ~1.4 tx/s). The test traffic was issued as many busts of ~10 tx/s spaced maybe 5 min apart, IIRC.  However almost all of those transactions were rejected; maybe they were attempts at double-spends, or a stress test of the RBF mechanism. Unfortunately, statoshi.org and several other sites have purged that data and now show only valid traffic

One job that you should never waste your time applying for is Public Relations of a Big Respectable Corporation. 

Just before @oda.krell's quote, the article also says


It is very unlikely that NASDAQ will build a critical software on top of a platform maintained by two random volunteers.  I would expect that they copy that code, and whatever Chain delivers, and hand it over to their own software development team.

Is it certain that they will be using the bitcoin blockchain, rather than a blockchain with bitcoin technology?

It seems that all his transactions have fee 0.2 mBTC/kB exactly. If you use a slightly larger fee, your transactions should go through right away.

This site may be useful to follow the "test".

It does not seem to be an accidental surge of traffic.  There was a sustained excess All these excess transactions seem to have the same fee (0.2 mBTC/kB) so transactions that pay less than that fee will be delayed until the backlog clears.  

According to that site (approximate values):

Normal incoming tx rate         N = 0.67 kB/s (400 kB/block)

Peak incoming tx rate in test   P = 2.33 kB/s (1400 kB/block)

Apparent network capacity       C = 1.32 kB/s (790 kB/block)

Current backlog                 B = 13 MB.  

Current incoming tx rate        R = 0.90 kB/s (540 kB/block)

Expected time to clear          T = B/(C - N) = 5.6 hours (33 blocks)