Topic: Are we stress testing again? - page 11. (Read 33192 times)

i want to know the reason behind the spam attack / test more than any thing else.
but it is good to be able to send and receive bitcoin without any more stress of whether or not it is going to get confirmed!

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

It doesn't sound like you're aiming or explaining anything very well at all.  How about, instead of spreading your proposal out in drips and dribbles over several posts (in a thread where it's not really on topic anyway) and then lashing out at anyone who questions you because no one can tell what you're actually proposing until you clarify some points afterwards, would it not be better if you present some sort of coherent proposal in a new thread?  It's no use hinting at one thing, then saying "oh, it's not aimed at you anyway" when someone replies.  If you start a topic explaining who your idea is aimed at, instead of randomly blurting it out in an unrelated thread, then maybe you'll reach your desired target audience.

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?

Well, the 'stress tests' could have many objectives, some of them public some of them non-public.

It reminds me of the old story about hiring telegraph operators, when the telegraph was a novel, high-tech invention. There was a standard 'help wanted' add published in a newspapers and the candidates were directed to a thin-walled waiting room. One could hear the din of many telegraph operators working inside. But the hiring manager didn't invite anyone for an interview. He just sat right behind the wall and loudly tapped in the Morse code "QUIETLY GET UP, GET OUT OF THE ROOM, WALK UP TO THE FRONT DOORMAN, TELL THEM ABRACADABRA-2112 AND YOU WILL BE HIRED IMMEDIATELY" (I don't remember the exact, difficult to understand in Morse, test phrase, so I wrote ABRACADABRA-2112). The hiring manager knew that the best operators are those who can read Morse by ear, not just sight-reading the tape.

Something similar probably happened during this test. The private keys used in the tests weren't exactly 'private', those were some rather obvious brainwallet-style phrases/words. So maybe the true information sough was: who was going to try (double-)spend those transactions and to what addresses are they going to direct the funds?
 

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.

All right, this is a proof that you don't understand what you are talking about.

They are analyzing data outside of the blockchain. The information was public, but volatile, it got forgotten by all those, who run bare reference client.

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.

The algorithms there were secret, but the data was not, at least, that is what I understand. They gathered publicly available data from the blockchain and used their own secret algorithms to analyze and do something with the data. The information is public, you just need to figure out how to analyze it and use it yourself.

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.

There is the other side of the medal:
When an exchange was hacked the coins were sent to a site which was accessible only by TOR network.
Cant remember the site name but it was something like bitcoin foggy or something like that.
Search a bit and i think you will find about it.

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.

"All information is public"? This is very far from true.

Of the top of my head I could name at least two companies doing a non-public information gathering using secret, proprietary algorithms: blockcypher and chainalysis.

Personally, I'm not interested into going into very narrow market like that.

You are on this forum longer than I do. How could you miss the discussions about explicitly logging valid double-spend attempts? I mean, even before I registered here, there was a non-open-source patch to Satoshi's code doing that logging. And the people who were selling it had as one of the selling points "the concept was rejected by the core development group from the inclusion into the reference client."

Doesn't that speak something about the later successful double-spends?

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".

That was already a considerably high fee. The minimum fee would be 1 decimal more. So 0.00001 Bitcoin.

Though it looks the spamming of the network stopped finally.

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.

I guess a bigger block mb size will help in cases like this, is stress testing really a good way to point out to others that bitcoin needs bigger size blocks, then it comes the dilemma of miner saying one size and core developers an other.

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?

so i've heard that the chinese were the culprit of this, they stopped performing their infamous attack, and have taken profit  by abusing of the fees?

or it was a real test that lasted so long? which seems really strange to me

and what is the conclusion of this? are we going to increase the TX limit in the future as a planned?

Yup, just checked my mempool... only around ~500 transactions. It seems almost too low