The stress test guys may be identifying their transactions, but in a real hostile attack it would be impossible to distinguish the attacker's transactions from legitimate ones.  But gettng miners to "censor" transactions of "bad guys" would be the end of bitcoin.  The plan was that there would always be a miner willing to send your transactions through, even if some of the miners wanted to block them.


Litecoin requires a fee for each small output of the transaction.  Bitcoin considered doing the same but rejected the idea for some reason.


The current maintaners of the reference implementation want to keep the blocks small so that the fees will go up so that only large entities would be able to use bitcoin directly; other bitcoiners would have to use services like Coinbase or Circle, or some "overlay network" that their company is developing.

The first test was done by a bunch of volunteers recruited informally through an /r/bitcoin thread.  Each volunteer tried to spam transactions on his own, within a specified 1-hour window (that became 2-3 hours actually) on a Friday night.

The second test, about 2 weeks ago, was started by an entity called "coinwallet.eu".  They described their plans on /r/bitcoin.  They had a 5000 euro budget.  That attempt was aborted after spending ~500 euros because their scripts/servers could not handle the load.  They also realized that their fees were too low.  They promised to retry in a couple of weeks.

This must be their promised retry.  Their goal is to get 250 MB of unconfirmed transactions in the queues.  They got already over 100 MB and the backlog is still growing.  The network could theoretically process 1 MB (~2500 tx) every 10 minutes, but the miners have been processing only ~0.5 MB (~1300 tx) of transactions per block, on average, even when the queues are fulll; and the normal traffic has been using ~0.32 MB (~800 tx) lately.  Therefore, once the test traffic ends, it will take ~1400 blocks (~10 days) to clear the backlog.

Apparently they are sometimes using more than the standard fees, but (most of the time) they don't seem to be adjusting the fees to aggressively keep normal traffic blocked.  That is, legitimate transactions that pay 2-3 times the standard fee are apparently able to jump the queue and get confirmed in the next block or two.

Not all the extra traffic is theirs.  Many of their transactions send many very small amounts to Wikileaks, charitable organizations, or addresses with well-known private keys.  As the recipients of those micro-donations collect them, their transactions add to the test traffic.

The first "stress test" was organized informally by a crowd call on /r/bitcoin.  Each volunteer spammed what and when it felt like, during a specified time window.

The second "stress test" was organized by a mysterious entity called "coinwallet.eu".  They said they had ~5000 euros to spend on fees.  that attempt failed after spending ~500 euros because their servers broke under the load. The testalso wasn't effective because they were using low fees. 

This test is their new attempt, with more servers and smarter scripts, paying higer and adaptive fees.  They said that their aim was to get 250 MB of unconfirmed transactions on the queues; which, with 1 MB blocks filled 50%, will take ~10 days to clear after they stop the test.

They are already at 150 MB, still climbing.  Yesterday they managed to drive up the "effective minimum fee" (EMF) that you would need to pay for prompt service, to ~100'000 satoshis/kB, or ~0.4 mBTC (~0.11 USD) for a typical transaction.  (Maybe more, the plots that I am watching broke down at that point.) Now they seem to be using lower fees, because the EMF is less than half of that even though the backlog is much bigger.

A Spam attack does not aim to put spam on the blockchain (there is plenty of it already), but to swamp the queues so as to deny service by hours or days.  With 1 MB blocks, the spammer needs to issue only 0.7 tx/s, at a sufficiently high fee, to keep legitimate transactions from being confirmed.  With 8 MB blocks, it would have to issue ~15 tx/s all at the same high fee to keep those same transactions from being confirmed.

Hard to believe that the let-it-saturate-hooray camp can honestly think that SMALLER block sizes will make spam attacks more difficult.  What have they promised to their investors, that they need to resort to lies and ad-hominems to try to prevent any block increase?

To prevent the filling up of the blockchain and the utxo tables with spam, there is a much simpler measure: set a fixed, hard, and significant transaction fee, say 0.2 mBTC (~0.05 USD), for each output, whatever its amount; and a fixed, hard, and significant minimum output value, say 0.1 mBTC (~0.03 USD).  Any existing UTXO smaller than this amount then can be removed from the tables.

F2Pool is still the second-largest pool, after AntPool; in spite of RBF and their role in the "Fork of July" incident (and of them saying that, sorry, but they will not change their methods).

Define "fishy".  Most likely, a miner's cartel will use its power to increase their total revenue over some future time span.  That means more money for their members.  If the pool managers conclude that their plan is worth the trouble and risk, why would the pool members dislike it?


Those are "deep forks" that split before their genesis blocks.  

I meant a hard fork with network partition and coin split, like the Beast of Apocalypse of the Anagavinists.  The fork creates two independent bitcoins ("series A" and "series B"), each with its own set of miners and nodes, and with its own blockchain.  Each blockchain is invalid by the other coin's rule, but the chains share a common prefix that is valid for both.  So the history of both coins is the same up to the fork, and just after that each person owns the same amount of coins in the same addresses, on both chains.  Each person can move either coin independently by using the proper version of software and wallet.  

Each coin will have its exchanges and market price. The price (and therefore market cap) of the original bitcoin will probably be split among the two clones.   Then, those who don't like one of the coins can sell all their holdings of the same and buy more of the other coin.  One nice effect is that the nertwork capacity of each coin will be the same as that of the original bitcoin.  So the two coins together can support twice as many users; however, to send payments across the "ocean" between them, people will have to use an exchange or a broker.

Good that you agree about the block reward problem.  But you must have missed my preaching on /r/bitcoin about the illusion of the "fee market".

The "new devs" are impatient for the network to saturate so that the "fee market" will arise, and they have invented several spiffy gadgets to handle it that they are dying to use.  No matter how people explain, they don't want to understand that

* even 80% of saturation would render the use of bitcoin a nightmare, driving users away from bitcoin and stopping its growth well before full saturation.

* when the traffic will stop growing, say at ~80% of capacity in daily average, the "traffic jams" will arise erratically at peak hours and at random variations  of demand and supply;

* the queue lengths will vary pretty fast during a jam,  and will be emptied in a few hours;

* the fees will be useless outside of the jams;

* the right fees will be impossible to predict during a jam, because each jam will be different, the queue status will vary too fast;

* the right fee that you should use to be among the first 2500 entries of the queue that will get into the next block depends on the 3000 transactions that will be issued in the next 10 minutes, by 3000 clients who are trying to choose a fee that will put their transactions ahead of yours;

* twidding the fees will not reduce the average delay by one second, only make everybody spend more money and make the individual delays more unpredictable;

* many clients will end up paying much more than the standard fee, only to wait more than if the transactions were processed first-come, first served;

* most clients -- espcially those who issue important transactions -- have better things to do with their time than sit two hours watching the queues and playing the silly "fee hopscotch" game.

It is useless to point out to them that no business in the world, from lemonade stands to airline manufacturers, uses (or could use) anything remotely like this bizarre pricing mechanism.  It is useless to explain to them that the "fee market" will not be a "fRee market", because they have this silly libertarian definition of "free market" as "a market without government regulations".

Unfortunately, they are so detached from the real world, so fired up with the "fee market" fantasy, and so anxious to see their toys at work -- that they cannot even understand how that "fee market" will transform the act of paying something with bitcoin from a mildly complicated routine into an absolutely stupid, lengthy, incomprehensible and frustrating game.

They are like kids who set fire to the house because they want to play firemen and put the filre out with their water guns.


No it doesn't.  From the beginning, Satoshi himself was aware, and said so clearly, that the system would work only if a majority of the mining power acted according to their selfish immediate interest of maximinzing their revenue.  If a mining majority decided to do something else, all bets were off.  He was counting on mining remaining decentralized, so that such cartels could not form.


Bitcoin has been dead for more than a year, and was very sick before that.  What is still twitching there is a bizarre and terribly expensive payment system that resembles bitcoin, and works like it for some puroses; but with a crucial difference -- it depends on 5 people not having bad ideas.

There is still some hope though: if the price crashes to below 1$, all the industrail miners will go bankrupt, and bitcoin may then return to how it was in 2009, with mining well distributed through the remaining clients.

That, if the "new devs" can be stopped and the fire can be put out before the house burns to the ground.

Sorry, my mind exaggerated the memory it seems.  I cannot find his reaction to the first actual GPU miner (if there was one), but there is a well known plea of his, from Dec/2009, for a moratorium on such miners:

https://bitcointalk.org/index.php?topic=12.msg54#msg54

Makes sense, and hopefully the miners will improve their strategy as you suggest.  Consider telling that to your favorite miner...

However, until now that the chance of the parent block being invalid was very small, like 0.01% or less. That must be the reason why they did not bother to check the parent at all...

Also, are you sure that the delay is only "seconds"?  even when the nodes are struggling with 150'000 transactions in the queue, or 4 x the maximum transaction rate...

Well, forking bitcoin would be a simple and natural solution to the scaling problem. 

However, the changes that the cartel may want to make will be such that they increase their revenue, or bring some other benefit.  In that case, the compensation that the orhodox users would be willing to pay may not be enough for the cartel to tolerate the old branch.

For example, suppose that the cartel wants to postpone the next halving for 2 years.  They could let the old chain prosper, and put some of their miners to work on it.  However, in my math, that would give them tens of millions of dollars less revenue that if they kill the old chain immediately at the fork, and put all miners to work on the new one.

Transactions seem free only because the cost of mining (~1 million USD/day) is currently paid by the new investors who buy the mined coins.  That is not healthy economics; the cost of the system should be paid by the users of the system.  At current traffic levels, the cost would be equivalent to ~2% of the total output value of every transaction (excludng obvious change-backs); or to a flat fee of ~8 dollars per transaction; or any suitable combination of the two.  

Therefore, a flat fee of (say) 0.05 USD per output, and a minimum output value of (say) 0.25, would still be extremely generous.  If SatoshiDice is not viable with such fees, too bad: bitcoin was not created to offload the cost of online gambling on non-gambling investors.  Ditto for the other "opportunistic" applications

An increase in the blocksize LIMIT does not mean an increase in blocksize.

An increase in block size will not reduce the fees.  The minimum fee is fixed by the relay nodes, and could (should, IMHO) be part of the 'consensus rules' so that the miners cannot raise or undercut it.

A spam attack is effective only if it puts out more transactions per minute than the network can process.  With 1 MB block size limit, an attacker needs to issue 0.7 tx/s to create a backlog. With 1 US cent of fee per transaction, that would cost him only 25 dollars per hour.  If the max block size limit was 8 MB, the attacker would have to issue ~15 tx/s and spend ~500 USD/h.  So a bigger block size will make spam attacks a lot less likely (and will clear the backlog faster if they still were to occur).

AFAIK, the priority rules and some other safeguards prevent those attacks from disturbing the transactions that pay the minimum fee.  Only legitimate but no-fee transactions will be delayed.

However, those low- or zero-fee attacks do overload the nodes and other programs that look at the queues.  The last (prematurely aborted) stress test crashed blockchain.info and put all bitcoins ATMs out of service.  It may have caused problems also for BitPay and other services that inspect the queues to accept 0-confirmation payments.  The present test even broke this site that was created precisely to monitor the queue s


Indeed, someone just computed the average of the actual size of mined blocks, and found that they are only 50% full on average, even though the queues have a huge backlog of fee-paying transactions.  Part of the problem is the "hash stealing" shortcut that many pools use, that allows them to start (and finish) mining an empty block well before they can pull the information needed to fill it.  

Thus the maximum capacity of the network is actually only 180'000 tx/day, or ~2.1 tx/s. The current traffic (excluding the stress test) is already 120'000 tx/day.  So if it grows only 25% (30'000 tx/day more) , there will probably be recurrent traffic jams, during which the wait time for the first confirmation will be hours instead of minutes.


I believe that there will have to be both a hike in the transaction fees and in increase to 8 MB.  That would buy another couple of years, at least before the network saturates.

I think that it is very likely that, sooner or later, the miners will use their power to force changes to the protocol. 

It will not be totally trivial, but it will be much easier and quicker than the BIP66 or BIP100/BIP101 changes.  There would be no lengthy discussion on forums, blockchain voting, etc.  They cartel will just announce their decision to change the protocol with a couple of months in advance, with a suitable "for the good of bitcoin" spin.  They will put up the modified programs for download, that trigger a hard fork at a specified block number.  They will warn everybody that those who fail upgrade before the deadline will be unable to use their coins until they do.

Knowing that the cartel means what it says, most clients, nodes, services, and non-cartel miners will upgrade before the fork, and will sail smoothly through it.   The cartel will use their hashpower to kill the old branch, if some recalcitrant miners will insist on mining it; then any clients still running the old version will be unable to move their coins.  Those laggards will either upgrade (and find their coins still where they left them) or lose their coins.  And that will be it.


Indeed, I am convinced that most bitcoiners will not care about a protocol change imposed by a mining cartel, if it does not affect them directly.  In fact they will support the cartel and pretend that they approve the change, to preserve the value of their coin.  I am pretty certain that you will be among them.  If you don't have a problem with 5 pools having 70% of the power, or with the 5$ cost of your transaction being subsidized by investors, or with the growing pyramid of "debt" -- then you surely will not have a problem with a mere postponement of the next halving, or with the extinction of independent relay nodes, for example.

I saw a quote by F2Pool - perhaps on this same thread - confirming that they will not do full validation of the parent before mining on top of it.  They will however re-enable validation of the parent in parallel, if and when they receive the full block from the relay nodes.

What the pools do (probably all of them, because they will be at a clear disadvantage if they didn't) is more radical than "SPV mining".  They subscribe incognito as members of other open pools.  When some other member of some other pool X mines a block B(N), it will usually tell all its members to start mining B(N+1) on top of B(N), even before sending B(N) out to the relay nodes.  To do that, it has to send to all its members the header template of block B(N+1), that includes the hash of block B(N). The pool Y that is spying on X will then take that hash and start mining its own block B'(N+1) on top of B(N).

This shortcut is usually quite safe, because pool X must validate the contents of block B(N), and cannot afford to send a false hash to its members, even though it knows that some of them must be spies for the competition.  But this trick failed in the "fork of july" because pool X (BTCNuggets) was still running the v2 version of the software, so the block B(N) was invalid under v3 rules.  The hash of B(N) was stolen from BTCNuggets by BTC-China, that was running v3 but did not realize that BTCNuggets was v2. Then F2Pool stole the hash of B(N) from BTC-China, and won the race to B(N+1); and the mistake continued for another 4 blocks more.   A similar incident happened again on the 5th of July.

The pools obviously will not give up on this shortcut, unless some way is found to make it unprofitable.  

Moreover, whenever pool Y starts mining on top of the stolen hash of a block B(N), it must start mining an empty block B(N+1).  Pool Y cannot include any transaction from the queue in B(N+1), because it cannot check whether that transaction was already included in B(N), or tries to spend some UTXO that was spent by another transaction in B(N).  Pool Y must wait until it gets the whole of B(N) from the relay nodes, before it can safely add more transactions to B(N+1).  But often pool Y solves B(N+1) before that time.  That may be the cause of the empty blocks that are often seen after a short interblock interval.

Probably not. Bitcoiners are extremely resilient, they don't change their opinions just because of mere facts.  


"Fork" does not mean to increase the blocksize, although changing it would require a fork.  (Luke Dashjr wants a fork to reduce the max block size to 100 kB.)


The larger the block size limit, the more expensive a spam attack would be.  To be effective, a spam attack must generate more transactions per second than the network can confirm (in addition to its normal traffic).  With 1 MB blocks, that would be more than 1.8 transactions per second.  With 8 MB blocks, it would be ~21 tx/s,  With 20 MB blocks, it would be ~53 tx/s.  Only the excess spam above those numbers would accumulate in the queues, creating and feeding the backlog.

More transactions make the attack more expensive.  The average transaction fee now is ~0.01 USD/tx, it seems.  Assuming an attack with twice the traffic numbers above,  the cost would be ~80 USD/h with 1 MB blocks,  ~850 USD/h with 8 MB blocks, and ~2100 USD/h with 20 MB blocks.

Also, the larger the block size limit, the faster a backlog will clear out.  The goal of the current spam test was to reach 250 MB of unconfirmed transactions (but they got about 70 MB maximum, so far).  The backlog will clear at the rate equal to the capacity of the network, minus the current traffic (which is about 30% of the capacity).  So, with 1 MB blocks, minus 300 kB per block,  it would take ~360 blocks (~2.5 days) to clear 250 MB of backlog.  With 8MB blocks, it would take ~33 blocks (~5.5 hours).  With 20 MB blocks, it would take ~13 blocks (~2 hours).

Increasing the block size limit to 8 MB or even 20 MB will not make the risk of a spam attack become negligible, because a determined attacker with deep pockets can afford much more than 2100 USD/hour.  But it would make the attack 10 times more expensive, and clear any backlog almost 10 times faster.

But the main reason to increase the limit is not to ward of spam attacks (which, as said above, are impossible to avoid).  It is only to prevent the network from becoming saturated due to a possible increase in normal traffic.  If the average normal daily traffic gets to about 300'000 tx/day (only 3 times the current value), there will be recurrent "traffic jams" that take several hours to clear.   The delays due to traffic jams will drive more users away from bitcoin, until the traffic stops growing.  Only users who really need bitcoin (like drug users and ransomware victims) will put up with the jams.  

Increasing the block size should have been a no-brainer non-event, a trivial and routine maintenance action to get one possible problem out of the way.  It is what any plumber would try to do when he notices that a rain or sewer pipe is about to become insufficient for the flow it is supposed to carry.  Unfortunately, the business plan of Blockstream requires forcing all individuals who now use bitcoin to use their "overlay network" (Sidechains, Lightning Network, whatever) instead.  To do that, they must keep the block size limited to 1 MB until the network saturates, in order to force all clients to pay much more in return for much longer confirmation times.  All in name of freedom, of course...

Last time I checked, the top 3 pools and the top 4 Chinese pools had ~55% of the total hashpower.  The top 5 pools (the Chinese one plus the Ukranian BitFury) had over 70%.

Objectively, bitcoin failed.  Users and holders must trust that those top 5 miners will not do anything nasty.  If they conspired to put all other miners out of business, they could do it.  If they agreed to block an account forever, they could do it.  If they agreed to make some change to the protocol, they could easily force everybody do accept it.  There would be much cursing ang grawing of teeth, but the only choices for all users and holders would be to either accept the change, of lose their coins.  Since the whole point of bitcoin was to eliminate the need to trust an intermediary, the system has become pointless.

It is often stated that miners don't have that power, and it is the "economic majority" that matters; or that they will never want to do it because "it would destroy the value of their investment".  That is bullshit, it is the fairy tale that has been spun to hide a problem that has no solution.  Indeed, if the miners do force a change in the protocol, those same people will spin the tale that it was no big deal, that the change was in fact approved by the majority, that it is in fact "good for bitcoin" etc. -- because, like now, the value of their investment will depend on preserving the public image of security and stability.

By the way, we know that the Chinese miners can get together and agree to a common policy, with a document signed and stamped with red stars.

This is not the way that bitcoin was supposed to be.  Implicit in the original design was the assumption that, while full relaying nodes might end up restricted to businesses that could afford to run a server 24/7,  mining would be done by ordinary clients, as an alternative to buying coins.  As long as that was the case, having the integrity of the system depend on a mining majority would actually ensure the independence and security of the system.

Satoshi was quite upset when someone published the first GPU mining program, because such greedy miners would invalidate mining by ordinary clients.  That problem unfortunately got worse and worse, ending with the current situation -- where the network is just one small step away from being run and controlled by a closed consortium of private miners.

The immediate cause of the problem was the disparity between the fixed block reward (currently 25 BTC/bk) and the market price of the coin (currently 270 USD/BTC).  That combination made mining into a business with an extremely large revenue stream, now still ~1 million USD/day  By comparison, BitPay, the largest bitcoin payment processor in 2014, processed less than 0.5 million USD/day during that year -- including payments related to mining (i.e., internal to the bitcoin system as a whole) and purchase of precious metals (which was basically investors switching from bitcoin to another investment asset).  Even assuming that BitPay processed only a fraction of all the e-payments using bitcoin, the cost of maintaining the network (including or excluding the miner's profit) is totally out of proportion to the actual use of bitcoin as a currency -- the purpose for which it was designed and implemented.

The high price of bitcoin, in turn, resulted from speculative investment, fueled by expectations of extremely high value in some vague future, based in turn on its alleged scarcity, "deflationary" character, and dreams of it capturing a significant slice of the credit card market.  While the future may still bring surprises, those claims have been largely debunked since the crash of the 2013 bubble.

Another consequence of this overvaluation of the coin is that the huge cost of mining is not borne by the users of the coin, or by its current investors, but by the new investors who are buying the coin today.  Theirs is the only money flowing into the bitcoin system: that money flows out of the system as miners' revenue (1 million USD/day), the payoff of the early investors who are reducing their holdings (an unknown amount) and part of the fees of bitcoin exchanges, payment processors, and other bitcoin services (also an unknown amount, but probably much less than 1 million USD/day).

Because of this unhealthy economic structure, the bitcoin system is creating an increasing mountain of "moral debt": the money that people have invested in bitcoins, and expect to get back with at least some profit.  Of course, there is no entity guaranteeing to pay this debt.  It is not possible to compute this "Bitcoin National Debt" (BND), because there is no way to know the price that each bitcoin holder paid for his coins; but we can tell that it is somewhere between 400 million and 17 billion USD.  The only way the current holders can recover their investment is by selling their coins to new investors; but that will only increase the BND...  Obviously this snowball rolling cannot go on forever, and it can only end in tears.

I am not an expert, I am just learning from what is posted on forums, too.  But basically mining pools have a way to "steal" the hash of newly mined blocks from each other, even before those blocks get out to the relay nodes. They must immediately start to mine a new block Y with the stolen block X as the parent,  without waiting for X to propagate out to the relay nodes, otherwise the pool that mined X will have many seconds of head start.  If they are lucky, they will solve block Y even before the block X has finished propagating to the nodes and the nodes have validated it.

Those miners do validate the transactions that they put into block Y (in parallel with mining it), but they cannot start validating block X, or even check whether it was mined by a v3 miner, because they only have the hash of block X, nothing else.  Apparently they used to fetch and check block X, also in parallel with mining, once it became available; but F2Pool had stopped doing so,  because (they said) it had cost them a block reward once (perhaps by using up some of their internet bandwidth).

Usually this shortcut works, because the block X was verified by its miner, and is valid 99.99% of the time.  Hoever, just after the BIP66 rule became active, the miner BTCNuggets, that was still running v2 software, happened to mine the next block X. The BTC-China pool stole its hash from BTCNuggets, and F2Pool stole it from BTC-China.  F2Pool (who had upgraded to v3) mined a new block Y on top of X, without realizing that X was invalid because it was mined with v2 rules.  Then F2Pool mined another block Z on top of it, and AntPool mined another one on top of Z, and so on -- all without realizing that X was invalid.

This is called "replace-by-fee" and there are several versions of it.  But it will only make the problem worse.  Your transaction many be delayed not only by those that will be issued after it, but also by those that were already issued and will be re-issued with a higher fee.  So you will have to stay connected, watching the queue and re-issuing your own transaction with higher fees, until it gets confirmed.

The main purpose of the block reward was to get the coins in circulation.  In Satoshi's idea, mining would be done by the clients themselves. You want to use bitcoin? You can buy some, or you just mine some, helping to secure the system in a decentralized way.  He was very upset when someone wrote a GPU mining program, because it meant the end of such "popular" mining.  Considering the current centralization of mining (the 5 largest pools have >70% of the total hashpower; the 4 largest Chinese ones have >55%), a honest evaluation should be that bitcoin has failed, and cryptocurrency designers should go back to the drawing board, to find a way to keep mining distributed.


They have no motivation to spam; they would only collect fees that they paid themselves.  

But I agree that the variable fee is an open door to extortion. A mining cartel could easily impose monopoly-level fees.  The fee should be fixed by the protocol, so that miners could not charge a satoshi more or less; and transactions were processed first-come-first-served, to the extent that miners can be persuaded to do so.

There was a second incident on July 5th, with a 3-block orphan branch.  There are still v2 miners out there, and the v3 miners are still accepting recent block hashes from them, and mining new blocks on top of them before they have time to validate (or even see) those parent.  The fork was blotched.

Whatever they intended to prove, the previous test did not work: everybody claimed that the test validated their claims.

Maybe they are big-blockians trying to show what happens when the traffic exceeds the network's capacity.

Maybe they are small-blockians trying to justify the need for an "overlay network".  Or core devs who cannot wait for a chance to test replace-by-fee and other toys.

Maybe they are skeptics trying to get people to really understand the sentence "bitcoin cannot scale".

Or maybe they are indeed enemies trying to get people to abandon bitcoin for some altcoin...