Bitcoin Forum

The spam experiments of the last two days was fine but small, and can't give us lots of answer on longer term about blocks being fulled.
I'm proposing to provide a Bitcoin site #SpamTheBlockchain as a Service and throw it to all redditors, so we get fixed about what will happen.

I will give redditors an address that they can fund to automatically spam the blockchain. (UTXO and Transaction explosion)
I expect the spam experiment will be order of magnitude bigger in space and time. (compared to the 2 last days)

At the same time, I expect providing real time charts (https://bitcointalk.org/index.php?topic=1055594.msg11394989#msg11394989) about what is happening. (hopefully with the help of laurentmt)

Surely, if something big happens I will cut down the service.

The current debate about the block size is hurting everyone, and provoke lots of uncertainty about bitcoin and, rightfully, impact future investments.
If we can't reach consensus, I think it will provoke a split of Bitcoin (XTCoin versus Bitcoin), which is to my mind, the equivalent of a nuclear disaster to this space.

Every bit of data which can help to make the mind of everybody about the real effects of full blocks will, to my hope, unlock the situation.

Before working on it, I want first your impression about this idea.
Before you yell about any disaster that might or might not happen as a result of this experiment, I will point out that the current real disaster is today's lack of visibility on the future of Bitcoin by the conflict about block size.
I hope to bring some objective light which will help to find a consensus.

What I think will happen as a result of the experiment is a UTXO set getting bigger and bigger, which will bring down decentralization.
But if a spam experiment can bring down decentralization, is keeping the block size for preventing it a good justification ?

I may be wrong, but the best way to know is to test out and give the tools for everybody to make their own conclusions. (hopefully a common one)

144MB per days of drive space will be needed to keep up with it. (well, for non pruned node, 144 for the blocks, but also 144 for the UTXO set -may be wrong-)
Which will after some months, will have some impacts. (assuming redditor keep sending money for spamming, which might fail)

Hi Nicolas,

It's a very good idea to have spamming as a service and if this successed will have better vision about situation around block size and costs.

I'm going to support this, hopefully you will receive support from others to make spamming continually for two days.

To be clear, my intention is to make it long lasting, not a simple 2 days, the economical repercussion on the middle/long term can't be felt in 2 days.
The spammer would be able to decide how much to spend and the timespan to spam.
I will make big transactions with the estimated fees for 3 blocks confirmations.

I second that and think it's a very good idea to work on such service.

see also
https://bitcointalk.org/index.php?topic=1023190

it is possible to include arbitrary data in blockchain for only 0.0001 per kilobyte
(I am sure that the price can be lowered down to 0.00001 per kb or even less)

But we all know what happens if we spam the network to fill up blocks, this doesn't prove anything we don't already know. It doesn't remotely simulate the real world where real forces like innovation, adaptation and potentially fees all play a part in how things progress.

You don't know the impact it will have on decentralization. One of the reasons for the limit is protecting decentralization, do you think it hold if the UTXO set get to several GB ?

It will simulate innovation and adaptation, if the experience last for several months, people will need to take steps now to fix the problem.
What step will they take ? Will they leave Bitcoin and use centralized credit systems (intra coinbase transactions) ? Will they continue to use bitcoin only with higher fees ?
Will payment hubs be developped and incorporated to wallet software ? (please merge CLTV !)
Will they go to an alt coin ?

I don't think it is clear what will happen. But we can find out very easily with such experiment. If the result is one where the whole ecosystem disagree (and by that I mean the tech community also), then at least we will know how to evolve Bitcoin instead of staying in such divided opinions.

The problem is not 1MB versus 20MB, the problem is that we can experience a split of currency if the ecosystem continues to disagree.

Why should anyone be in agree with others in every question for infinite time?

The problem is the risk of a disastrous split, not a general principle that everyone should agree for all time. Regardless of which side wins, the split itself may be disastrous for both sides.

Thanks amaclin for your link.

The problem is not about 1MB versus 20MB. The problem is that we are in a disagreement.

A split of currency is even worse than a bug in the bitcoin consensus code provoking a fork, because a bug can be fixed with some short term damages.
A disagreement like we have now is equivalent to a consensus code bug provoking a fork which can't be fixed. (which might even put into question the future of any future crypto currency driven by open source)

Hell is not a hard fork caused by a bug. But a hard fork caused by fundamental disagreement.

We can't reach an agreement if everybody is speculating on their own what ifs. So I propose a large scale spam in size and time, so if something bad happen, we knows the numbers, can shut down the spam, reach a common conclusion and fix it before all blocks are full for real.

This is not a problem because we haven't even been in agreement.
We can not create such agreement, because of https://en.wikipedia.org/wiki/Omnipotence_paradox

Good idea! Let us kill bitcoin as soon as possible!
I prefer large transactions which waste disk space rather than spaming blockchain with a thousands of small txs!  ;D
It's partytime!  ;D

So change to "we don't have consensus" if it pleases you.
I am for lifting the limit, but if I had to choose between staying at 1MB and having a new currency competing on par with bitcoin, then I choose the 1MB.

It is erroneous to think that "Bitcoin will become bitcoin XT and replace core". No it will not, since it is clear that there is no clear majority. We will have two branches of the Blockchain.

I don't want to enter in the block limit debate, since it is clear to me that everyone will camp on his position. Actually, by now, I think it is a waste of devs time to debate anymore.
But what we can do is a real environment experiment with objective data which will shift positions. (Maybe mine will be)

We (bitcoin users) have. Now. Today. This second.
But "we" != "everyone". We do not have consensus with LiteCoin users. They have their own consensus.
And "todays consensus" != "tomorrow consensus".
May be tomorrow we will split to two forks with their own consensus. Why not? We can not prevent it

one can hope that cold hard facts and statistics will help taking an educated decision

I think that is an exaggeration. 

I guess that fewer than 1% of the bitcoiners (2'000 in 200'000) are so opposed to the very idea of a hard fork -- even one with a single outgoing branch -- that they will rather use the "old bitcoin" only among themselves, with a ridiculous block rate, than user the "new bitcoin".

The other 99% of bitcoiners do not know about the issue, do not care enough to bother, are in favor of the change, or will assent to it because they do not want problems.

For the large players that matter -- large miners, exchanges, payment processors -- the 20 MB limit will be only a small annoyance. They will go with the crowd.

Thus, i expect that most players will upgrade to the large-block version, well before the fork.  They will not even notice when the fork happens, and the price will not suffer any permanent drop.

I also expect that most of those "rebels" will then give up and upgrade too, in order to recover the value of their investment.

Thus, if the "old bitcoin" does not die immediately after the fork block, it will probably die very soon after that.

I think quite the opposite will happen. The majority will go with Bitcoin Core, big companies and miners will not chose to be political, they will not risk being political in order to force a change. The nuance is, if Bitcoin Core chose 20MB blocks, everyone would upgrade, but if Bitcoin Core remains with 1MB blocks and Bitcoin XT attempts to hard fork, people wont join Bitcoin-XT.

Think about it from a business owner's perspective. Would you support the de facto official version which has dozens of developers, or a new fork that has 2?

The only bitcoin buisnesses are mining and exchanging.
All other buisnesses are based on fiat currency.
Hodling bitcoins - is not a buisness. Today you hodl 1 btc. Tomorrow you will hodl 1 bitcoin and 1 gavincoin.  ;D

It's good to stress the chain, but it should be ramped up gradually so as to give people time to deal with the changes for the best adaptation. You could say the sudden shock would be a better stress test, but this isn't so much a test as much as a way of incentivizing optimization. (Right?)

One other thing to keep in mind is that if this were actual actual transaction demand miners and others could figure into their future business models that they can rely on these fees and they may start adjusting their fees to try to maximize revenue (making this attack prohibitively expensive, as we want it to be). If it's just a temporary attack, even if it continues for weeks, miners aren't going to have any incentive to change things. Well, they may have a personal or altruistic incentive to raise their fees for the good of the network, but not really an economic one. And even if they raise their fees, they may not have an incentive to make it easier for users to know how much to pay.

Also, it should be noted that if this jams up the network it doesn't necessarily support either side of the debate. It's not going to force a blocksize increase if everyone is experiencing delays; hopefully it will force better resource usage through the price system, though.

Frankly, I don't know. Imagine Bitpay Coinbase and a big china's miner say "FUCK IT GO XT", what would happen ? Maybe it is not possible, frankly I don't know. But being divided on an issue is hurting us, and I think better data and observation will make people's mind.
I'm in Bitcoin only since last year, it is the first big disagreement I have seen.

The goal is not to kill the network, I will shutdown the service if any big problem.

I don't know. What if it cause decentralization to drop dead because of UTXO set size ? would you continue to defend the block limit ? (again, please I don't want to debate that, just to give an example)
Maybe it will break nodes count from 6K to 1K. (In which case, I can fix the problem by closing the opened utxo, so we all know that the block limit is not the main factor of decentralization)

Maybe nothing will happen and the fees will naturally rise, killing the spam.

I don't want to speak about "this I think will happen", the spam is meant to be massive for months so we can feel the impact. (if enough funding)

I think we will learn a lot, and have time to fixup things before it becomes real.
I wonder if miners will make contracts with payment providers to process "premium" transactions. (which would be a new revenue stream for miners, mainly the big one)

IF I DO IT, WHAT TYPE OF CHART WOULD YOU LIKE ?

What kind of data would you think help to make our minds ?

I don't want to debate whether it is useful. Vote will be made with wallets. I want to know if there is any strong opposition and deep concern about that, and if it is, why.

1) spam kbytes per day
2) miner fees of spam txs per day

As I've said above - it is easy enough to create 1x99kb spam transaction instead of 200x500 byte txs.
Anyone will be able to put his favorite photo in jpeg to blockchain for only 0.01 btc  ;D

Some metrics I'd like to see, along with the current "spam level" and the health of major services : number of nodes active, consistency of mempool across all nodes, size of blocks mined, time between blocks mined

What should I do to be a part of your sect bitcoin? Let me in! ;D

@OP
Could you explain what you are trying to show?

ability?

I'm intrigued what this might mean. I agree it's worthless debating anymore, each side is drawing on hypothetical's that are largely unknown, whereas there's only one thing that will happen for sure if we run this experiment - the blocks will be full.

Are you close to having it running?

I told in the post why I think it is necessary to do that.

What am I trying to show ? Objective data + a peak about how miners / payment providers / wallet providers / users will behave in real economic condition.
I don't want to proove anything, I hope that discussion about data will replace the "pies in the skies" discussions about what will happen.

Personally, I am curious about what will happen if UTXO set grow several order of magniture.
And also what will happen to any in memory mempool implementation will behave when the tx rate is higher than 7 per sec for long period of time.

I am asking you the data you would like to see, so anybody can learn something out of it that might change your view, and hopefully reach a common agreement.

The debate about block size is not anymore in a productive state (but a destructive one), I hope changing the situation.


I did not start coding it, but if I start I should do it in 1 or 2 weeks. I hope laurentmt, who is better than me for presenting information the right way, will help me (or provide his own separate analytics website) so we can get fixed faster.
There is also an unknown : Maybe the community will not be able to fund enough fees for spamming for a long enough time.

My goal is at least to maintain something like 14 tx/s in total tx on the network for a month. (with estimated fees for 3 block confirmation)
Maybe it won't be possible, and I will adjust fees. Or maybe I'll just ask the spammer what amount he wants to spend per spammed KB.

Just to put it in some perspective:

With a size of roughly 250-350 kB per transaction, that's about 4000-6000 BTC spent in total for fees, with estimatefee 3 = 0.00044247 BTC/kB, and 14 tx/s for one month.

Would you like to hire me?  ;D
Let us start 0.00005 per transaction or 0.0001 per kilobyte.

Very true, I've done back of the envelop calculation also, and it would get very expensive.
Note that we already have approx 3 tx per seconds (400KB block average), for reaching 14, it is "only" 11 tx. (or 5 tx to be just above)

Last 2 spam days experiences was done by 2 persons I thought having read somewhere [citation needed here, I may be wrong].
You are right though, estimatedfees is too high, and I will need to find a compromise about minrelaytx and estimatedfee. (Or ask the spam to customize the fees himself)

Not sure what you are talking about. Have I hurted you because I used the terms "ecosystem", "we" or "community" ? I'm not interested in the terminology, replace by what you want. I'm interested with people who wants to learn from the experience, or devs strongly opposed for specific technical reasons.

Well, tweaking the fees will be easy anyway when the website is on.
Do you want to help ? I think the most important stuff to provide is all the raw data and charts for others to analyze.
I think the spamming site (which I can take care of, even if I would appreciate help for the front end "spammer" UX) will be decoupled from charts sites, I hope to reference websites of other developers providing and presenting the data.

The value will be more in the data we can collect from this than into the spam service itself. (without great feedback, there will be no great incentives to spam)
I did not thought other devs would help, I can create a group on github if it helps where we can put all projects related to the spam service, if I'm not the only coder.

I mean that I can send useless txs. I am not ready to make a website

That makes this idea seem like an insanely expensive experiment!  How could this ever be a feasible thing to pull off if dexX7 is right about these costs?

And if the infrastructure isn't ready for it and is damaged as a result, how would you fix it? I could be misunderstanding something but it seems like inoculating someone with a disease in order to study how he will react in real conditions.

He wouldn't.
There are several categories in car racings: pilots, mechanics and spectators. Pilots do not repair broken cars. Spectators also.

It should be noticed that "estimatefee", a Bitcoin Core command to estimate fees to pay, seems a bit high, when it suggests to pay 0.00044247 BTC/kB to get a confirmation within 3 blocks.

And further, 14 tx/s is about 10x the transaction volume we currently see, assuming those transactions make it (which they wouldn't).

But either way, I agree, even with some magnitudes cheaper costs, this seems expensive. ;)

NB: what is your goal anyway? Disturb the network and delay legit transactions? I'd would feel more comfortable, if those experiments use rather low fees instead, so that regular transactions are mostly unaffected, or require only a small fee bump.

Salut Nicolas,

I feel uncomfortable with your "experiment" as from what I understood, it is not more not less than a real attack towards the Bitcoin network.

TestNet appears to me like a better suited environnement for this kind of experiment.

This sounds like something I'm in the works of developing! I wonder what the outcome will be long term, hoping for the best.

FWIW I can mine testnet coin very easily. In a few hours I mined about 18,000, more than enough to fund this experiment for a month.

In fact, I've been giving it a go - https://www.blocktrail.com/tBTC/address/n2GcwNsdybZrr6mbLakrwgQoWSurABHU3a I've broadcast about 30,000 transactions on testnet in the past 12 hours. It currently leaves about 4000 tx's in the mempool with and none of the blocks exceeding 750kb.

Some numbers: I moved 30testnet coins in 30,000 transactions, for a fee of 0.51 (dynamically calculated by the client). I have 18,000 testnet coins. So we can deploy this on testnet today, and see exactly what will happen.

Did you deploy?  And are the issues these guys are eperiencing related to you? https://bitcointalk.org/index.php?topic=1079182.0;topicseen

Just curious.

Testnet is testnet. Bitcoin is bitcoin. (http://log.bitcoin-assets.com/?date=25-05-2015#1144870)

I was responding to his queries about the antminer blocks.

I did get it running. 2 nights ago I did 2000tx/hr using the RPC. This time I can turn a single 4BTC output into 781 transactions, and repeat this until I have enough to really stress things (by precomputing many in advance). Unfortunately my laptop runs out of memory when I try to split outputs of over 10BTC..

This is the address I'm using: https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg

spam is among the worst thing on the internet. everyone always looking to spam something

Why don't you try this on some Altcoins. After all thats their purpose :D
Lets use those as the guinea pig, if not testnet. As far as I know I have been able to send tx with 0 fee without any problem in most altcoins.

FYI, I don't like your experiment. I don't like spam.

Do it elsewhere, not on mainnet.

Sorry, I got a bit busy this week, so here my responses


I will not, since their code would have broken anyway later on. We can contact me so I stop the website (btw, the code will be open source so other people might host it)

Knowing generally what will happen if tx/s is above 14, mempool continually growing. (well, this is what I want to see, other people would be more interested into economic impact on fees, machine spec for nodes, decentralization impact)

You are right for testing a mempool attack, (so I will provide a testnet mode) but we can't test the economical impact with fake money.

Not me, I have not yet started coding it.

The spam is no different from what will happen for real when blocks will be full.
The goal is to learn what we can about that before we hit the real wall.

If the attack can't work because fees are too high, then it would also proves something valuable.

Nicholas: I've been playing with this over the past few days on testnet. I reckon the most effective way is to take a txid and private key (which can spend an output of that txid) from the user, grow it into a tree of dependent transactions, and then broadcast all at once.

The value of the output limits how many subsequent transactions you can get. I'm using a redis queue and a bash loop to call something to pop, split into $split new transactions, and push new ones to the end for further splitting.

I've launched it a few times, normally in batches of 700 tx's. Broadcasting is a very fast step, and the mempool fills up quickly. Block explorers seem to hold their ground, though are can be slow to make all transactions in a block available in the UI. In fact, many seem to rush to publishing the block on their website, despite the transactions not being fully imported to their database. I wonder what fast, full blocks would do to these services. If they can't keep up with 1Mb blocks ("full" or otherwise) we'll learn something from this.

Full blocks blocks max out at 750kb, or about 2111 transactions. There is still a miner who is not including transactions.. I wonder if he's sympathetic to this experiment.. They appear to to have about 50% of the hashrate at times, so this makes the spamming more effective, as the rate the mempool is purged is effectively halved.

What way do you plan on doing it? I found using the RPC quite slow, and since new change keys/addresses are generated you run into a bottleneck.

https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg (https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg)
Well, actually you crashed my firefox when I browsed https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg/transactions (https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg/transactions)
I also see the mempool peak in RAM of my bitcoind (to 150MB but it then dropped to 50MB and stopped moving) and my block explorer (tapi.qbit.ninja (http://tapi.qbit.ninja)) holding.
I thought the mempool was keeping transactions in memory. (must go back to the source code to check how implemented)
The problem of a tree of transaction is that if a node transaction in the tree is missed, the bitcoind willl reject further transactions to go in the pool.

The deeper the tree, the higher the odds of one of its parent not having reached the mempool before one of the child, and thus preventing the hierarchy to further spam nodes.

I am also curious about keeping the rate just at more than 7 tx per sec for months.

I'll make the website, and provide a way for the spammer to choose whether he wants testnet or mainnet, as well as spamming in volume or in duration.

I will not be using RPC at all, so should not have a bottleneck.

The way I'm traversing it should mean tt pops a parent, and adds 5 new ones to the end. 'The end' gets further away each time. I am also saving all transactions to a file, so I rebroadcast that every once in a while.

At this point I think there's about 42 blocks worth of transactions in there (90k). Bitcoin's 7tx per second rate is essentially the maximum rate it can clear the mempool (assuming all blocks are full). I can produce transactions at roughly this rate, so the mempool should at least stay fixed in size.

However, most of the blocks on testnet have no transactions in them, reducing the rate of mempool clearance, so the mempool should continue to increase in size.

It might be worth noting that regardless of the transaction size, I have attached a default fee of 100,000 satoshis for each transaction. This seems to be sufficient for most of the tree, and I've had very few with insufficient priority.

you broke blockchain info ? :D https://twitter.com/blockchain/status/607227102639865856?s=09 (https://twitter.com/blockchain/status/607227102639865856?s=09)

Haha - probably unrelated. Do they have a testnet explorer?

I pinged a few testnet faucets for coins to see how long they take, with all this going on. If there's a huge difference in priority maybe they'll be scattered over the following few blocks?

You underestimate the capacity of bc.i to have creative bugs.

wow!  ;D

Somebody sent a large amount of spam transactions ~2 hours ago
All of them are here: https://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T as incoming txs
(this is well-known chbs-address)

Note: the spamer spent very small amount for fee.
for example this tx https://blockchain.info/tx/e7bf1079255f6defe23ff2c87aad1a9302183bf8f7db10d07567ff535eeeb8f2
contains ~15 kb of data and costs him only 0.00019843 BTC (as fees)

not me, but would have helped if he asked me.
This is 0.012 BTC for fulling a block, or 1.728BTC for a fully day, a goal of 30 day is "only" 51 BTC.
The spam website I want to do, funded by anybody who wants to spam, may reach such goal.

And I don't even want to reach full blocks, only keep a rate superior to 7tx/s, so would cost probably around 25 BTC.

I am also in progress of writing such tool.
I prefer Qt/C++ , so I am rewriting now Peter Todd's  tool
https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py

UPDATE:
The stored data is bitcoin core developers chatlog. It is visible here:
http://bitcoinstrings.com/blk00281.txt
I am too lazy to read it :)

Here is existing service for blockchain spamming:
http://cryptograffiti.info/

It has big costs, but spams also to UTXO set  ;D

Are you guys spamming the blockchain at this transaction.

https://www.blocktrail.com/BTC/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T/transactions

Have you read messages above in this topic?  ;D
https://bitcointalk.org/index.php?topic=1075590.msg11579864#msg11579864

Actually I can get a STBaaS set up and running pretty quickly if the payment is right; how far have you got?

Anyway blockchain.info seems to be breaking very frequently these days; who is responsible? :D

On my side, did not started yet. Will do, I want to provide a way for the spammer to spread the spam on time and size.
Should be quick once get some free time, I'll try to release a quick and dirty alpha sunday.

The unit of spam will be measured in KB/Blocks with the adjustable timespan.

I see somebody spamming blockchain with sending small amounts.
There are a lot of transactions like these past few blocks
https://blockchain.info/tx/1af09e021cba5eeec99c232f9a32796dc9a419e1d26ce5f492d023574ed2d497
https://blockchain.info/tx/d3d9353ca0655e35e348f9ca4c9510d4b33c3dcfaaf22837229d72932dc53d74
https://blockchain.info/tx/d783e2881aa943b0f64215bf85a587b5a90b9747b376aa26539d92774b206be9
https://blockchain.info/tx/ba5940b2622efa4860fd8d79d2013439fe17105b790a9920cf37056655f04d2b
https://blockchain.info/tx/d9aec25080bd07a74189a4a254f2f6ba5363e4d50903ef4dfb107aa4c1866100
etc etc

not me, I'm late at doing the site. Ended up learning TypeScript (because I wanted to try on the project) instead of doing the work. :/

I am also too lazy to program useless things  ;D
Just for the intention of those people who say that the number of txs grows.

I thought I saw something about this on the mailing list earlier, there seems to be a company carrying it out on mainnet. At least they have the funds for it :)

https://np.reddit.com/r/Bitcoin/comments/3agk61/ultimate_bitcoin_stress_test_monday_june_22nd/

There is a suspicion that the Coinwallet.eu "stress test" is actually a scam:

I believe we have our first scammer organizing a Bitcoin stress test
http://np.reddit.com/r/Bitcoin/comments/3ahl43/i_believe_we_have_our_first_scammer_organizing_a/

Some results of the test gleaned from this plot (https://bitcoinfees.github.io/#3h):

  Estimated network capacity:  85 kB/min

  Typical input tx rate before test: 30--50 kB/min

  Typical queue size before test: 300--600 kB

  Peak input tx rate during test: 126 kB/min (~3x normal, ~50% over capacity)

  Peak queue sizes during peak test: 12 MB (14:00), 14 MB (21:30)

  Sustained input tx rate for several hours after peak: 70-100 kB/min

The test definitely showed that even a small player can create a large backlog with modest expense.

It showed that when the input transaction rate is close to the network capacity, even a small increase in that rate can create a huge backlog.   Between 18:00 and 21:30, when the input rate increased from ~75 kB/min to ~112 kB/min (a 50% increase), the queue grew from ~3 MB to ~14 MB (a 370% increase).

The previous stress test (on a late friday night) used only free transactions, so the fee-paying transactions were delayed only slightly. This one used fee-paying transactions: it will be interesting to see how it affected the ordinary fee-paying transactions.  I hope that someone will do a detailed analysis.

Thanks Jorge for the mini-analysis.  I'm the developer of that site.

The plot you linked is a dynamic one; so here is the static plot of that time interval:

https://i.imgur.com/dVzx0BL.png

And the same graph, but scaled for viewing of the tx byterate:

https://i.imgur.com/MEfBHg7.png

Some things to note (I should have added this on the site, ideally):

1. The tx byterate estimation is done using a exponential moving average, with a halflife of 1 hour.

2. The capacity byterate is given by

blockrate * expected max block size

where expectation is taken over the mining pools; estimates for pool max block size policies can be found here (https://bitcoinfees.github.io/misc/pools/).

Queueing, but no catastrophe so far...

Most of the craziness went down yesterday.  I got caught in it and a standard transaction (with a standard fee) took 8 hours to confirm.  I read that these guys are planning on doing this again next Monday.  I, for one, will be avoiding sending transactions this next time and will enjoy it on the sidelines, with popcorn, where I should have been last time.

Yesterday I made a few transactions with Bitcoin Core, with a moderate transaction fee ("estimated to begin confirmation within 12 blocks"). No drama whatsoever, all transactions confirmed within the next block.

I guess the network is more resilient than many think.

Did you happen to look at the size of the mempool at the moment you sent?  I'm pretty sure, based on the time in which you wrote "yesterday" that you actually missed the stress test by about 24 hours.  Nevertheless, even if you had been sending at the height of the congestion, obviously with a stochastic process your mileage may vary.  My experience, and yours, are merely anecdotal.  The big picture is what matters.

bitcoinfees, very useful, do you think to provide querying historical data ?
Can you provide a query format where we can select a particular the timespan ?

Once I get out from my procrastination zone, I want to make my spam site and just link to yours to provide the graphs.

Why isn't the spam being tested on the testnet?

I'm guessing they want to try a real life situation. Basically trying to show the weakness you may face when buying or selling things.

In this case, they're screwing everyone up with their experimentation.