i don't think it was a test. not in a conventional way.

it seemed to me more like proving a point, maybe the group behind it was trying to force increasing fees, or some say the block size.

did anybody take responsibility for the test/spams yet?

Funnily, it had the opposite effect on me ... while I used to be in favour of bigger blocksize (although preferring BIP100 over XT) I am now not so sure it is the right solution. For one, I don't necessarily want spammy, low-fee transactions filling up the blockchain. With a healthy fee-market miners also will benefit which seems good. I'm not sure what the best solution is yet, but I'd prefer to not jump on the bigger-because-more too haphazardly.

Yeah, exactly as expected, the typical shit-slinging from a code monkey warning about "exponential increase" and "network shutdown".

This is a general discussion group, so it may be better to frame the explanation in the terms more familiar to the less experienced computer user, not a software developer.

The popular Apache web server has in the typical configuration two log files: "access" and "errors". The first is logging the boring stuff that can be later compiled into various statistical graph. The second one logs the interesting and unusual events. The second one is where one would look for e.g. hack attempts, abuse, etc.

The typical reasonably popular web site may have a constant stream of invalid login attempts from all over the world, and storing all of them has a little value. On the other hand a single attempted login to the administrative account with revoked password (meaning a valid password that was replaced by a new one) could be a breakthrough in the investigation of the internal fraud. E.g. it was from Israel and the organization recently fired for drunkenness a holder of two passports, one of them Israeli.

Similar reasoning applies to logging errors over Bitcoin network. A slew of completely invalid transactions is of little interest. On the other hand a single invalid/conflicting transaction bearing a correct signature is potentially very valuable indicator.

I'll encourage the readers who happen to be interested in the discussed concepts look up "fraud proof" and "compact fraud proofs".

If you want to keep all of those transactions, by all means do it. Write your own patch and set up your own nodes to log all of the transactions and data. Publish it publicly so that people can examine it. But don't make that something part of the reference client which forces everyone who runs that code to have to keep all of the data they don't want. For the average user, keeping all of those transactions so that someone can analyze them is pointless. I only want to run a node to help the network. I can't afford extra RAM and disk space to maintain the mempool and databases required for keeping all of those transactions. If you can do that, please do it, it may help the network. But I can't do that, so I will opt out.

And with opting out. Maybe it should be an option, like a supernode or something. It stores all of the transactions, but only for people that want to do that. It shouldn't be enabled by default, but perhaps such an option should exist for those that want to do that analysis.

This is a very naive view that you are exhibiting. I don't get a "code monkey" vibe from you, seems like you misunderstood the various technical and architectural possibilities.

Your concern over block broadcast time is valid, but the implications you make are false on several levels.

1) One could simply store in RAM the subset of 'mempool' that is included in their block mining template, ready for broadcasting as soon as valid header hash is found.

2) "mempool" could be stored in a general https://en.wikipedia.org/wiki/In-memory_database, with or without hybrid on disk storage

3) any sensible general-purpose database system will have a cache where the recently accessed items are stored.

4) there are at least two pending proposals that do away with duplicate sending of transaction after the block header: Matt Corallo's relay network and IBLT alternative block broadcast protocol.

I hope my explanation made it clearer for the readers of this sub-forum why futzing with mempool at this stage is very similar to the optimizing time after Ctrl-Alt-Del that it takes MS-DOS to reboot.

I'm not aiming my explanations at those who "only want to run a node to help the network." I'm trying to reach people who try to incorporate Bitcoin into their business and really want to understand what is going on, who's winning and who's losing, who don't want to be "average user" meaning "average chump".

The current prevailing mood of whitewashing history is going to change. I don't know exactly when, but it will happen. It is a lesson I learned from understanding many earlier technologies in the history of finance.

You are contradicting yourself. Now you say the information was public but earlier you said

And yes, I don't quite understand the situation involving those two companies and that patch you mentioned earlier. I wasn't around when that patch was created and I did not pay much attention to what those two companies did.

Lol, even I tried to spend some of the addresses. It's not like that it is hard to do.
You mean, I am now on a watchlist? Since I already use Tor from time to time and god knows what other "bad" things I have done on the internet, I am already on many watchlists.
Should I prepare for the SWAT-Team storming my flat?

There's no more stress test, which is nice. I hope the guy who did it will share some info with us.

After the first aborted attempt, Coinwallet.eu posted a report of the method and effects on reddit.  Hopefully they will do the same for this one.