Topic: Some 'technical commentary' about Core code esp. hardware utilisation (Read 4910 times)

Locking the thread now because asked and answered.
@gmaxwell's responses seemed very clear, thanks
interesting which trolls and which sane people turned up

Wrong and wrong, sir. I am just one more bitcoin supporter. It is telling that you go for the diversion and failed to make any clear point.

Thanks for demonstrating your lack of either clue or integrity for the record-- some people might have been mistaking your endorsement of Wright as a moment of bamboozle rather than a deeper character flaw.

But just in case you missed the response to his claims there:


So, dumping some output of a google search citing code that we already had-- isn't exactly "showing us the wound", would you say?

Not to mention your highlight of the use of sha256^2 which is part of the protocol definition from day one and not something we could change without invalidating every transaction and block. (Nor is it entirely pointless...)  But I guess as Craig Wright's partner in crime you already know all about that because he's totally Satoshi. (lol)


So, you're telling us that "TB" is Craig Wright?  Because that easily debunked claim is Wright's as far as I know.

Sure. Spending little too much time and efforts at beeing so.. Sigh

Bitcoin Core Dev's are the smartest developers in the world.

And when each response to "show us something you've worked on" or "why don't you take this on and join the project" is replied to with "You fools!  MWA HAHA", then that self-proclamation starts to look incredibly weak, imo.

QFT and mined for the gold.

It is very rare these days that someone outside the core team is so helpful to them as in this post.  Most outside core would be just as happy to see core fade away instead of being so very helpful as TB is being here, albeit TB was masterfully trolled by GM into doing GM's job for him, it is just as likely that GM's ego or outside incentives will prevent him from taking any of this helpful advice to heart.

Most interesting here is that TB has found where Core team have added the Big-O Quadratic Sighash bug which is their big issue of why then need SegWit and can't scale.

GM shoots Bitcoin in the leg, TB shows him the wound, the blood, the gunpowder marks on his hand and hands him the surgical kit.
GM sits there mocking him and shrugging.
Bitcoin's blood leaking out while GM stares around wondering why he doesn't get more love.

My reading was that Troll Buster's points were all replied to by gmaxwell.  Once you cut away all of the "stupid", "worthless", etc, invective there were a few criticisms in there and I'm pretty sure they were addressed.  Then, when Mr. Buster continued with the "you're all so stupid" style posts, I think people naturally respond with "ok, can you, like, show us why you're so smart", to which Mr. Buster sorta ran away screaming:




Hardly seems unreasonable to reply with technical answer to the few bits of detail in Troll Buster's post (which gmaxwell did) and then to address his invective and screaming by asking him to show something more productive than insults.

https://bitcointalksearch.org/user/wiffwaff-221980

Gosh Roger Ver/fake satoshi Craig Wright you forked out for quite an old account.
frighted?

Troll Buster is pointing out poor decisions that can be improved upon and people here are trying to find something of their's to be able to bash. This is typical Core tactics, whereby they fail to address the issue being highlighted and instead attempt to launch person attacks on the person stepping forward.

This is exactly why bitcoin development fragmented under the fifth column attacks that forced out the best and brightest, leaving us with the cesspit we have today.

Go on, fire up some BIP148 hashing power. I double-dare you.

Shit, you mean I could end up just like you?

So here you're just admitting that you're only here to troll?


There was this other thing that they said, something about talk being cheap.  Then there was another one I heard once that went something like 'put up or shut up'.  Maybe those are relevant here.

---

At this point it's pretty clear to me that Troll Buster is just here to spew bile.  It's really striking how puffed up he is about his skills and badassery and then when someone asks him to point to a project he's worked on or generally to prove his talk with something more than a google search his reply is all 'hey, look over there!'

I'll keep watching this thread because amongst all the chest thumping are some interesting technical details, but I think we can go ahead and recognize that Troll Buster isn't going to be contributing anything more than the chest thumping.

Irrelevant.
You challenged me to find one person who quit because of you. I gave you a whole team.
Here is another team, the Bitcoin Classic team, they left for similar reasons.


I didn't claim anything about myself.
Your code sucks, you said nope they're great, so I shown you where, I shown you how to improve it.
Then you went all "Says the few days old account", "i spent years on a porn codec" ego authority bullshit.
I don't care what you think about yourself or me.
Stick to the tech or stfu.


So now you're going to use new peers as an excuse to not compress the blocks?

That is so stupid.

When compression is enabled, and a new peer requests an old block.
Just send him the entire compressed block as is and let him process it.
It'll actually save bandwidth and download time.

Just add the compression feature and setting.
Some user would like to save 20G on their SSD by changing a 0 to 1, some wouldn't.
Just add the feature and move on, what's so complicated.
Compression is standard stuff, don't argue over stupid shit.


Who said anything about security or privacy.
To suggest pruning over simple compression was silly enough.
One minute you go all "My expertise is well established"
Next minute you talk total nonsense.
It's like amateur hour.


Look, here is the bottom line.
Compression is a common feature used everywhere for decades.
It's not some new high tech secret, why talk so much bullshit making it sound so complicated.

The point is you're already a few years late.
10%, 20%, 30%, Lz4, not Lz4, who gives a shit, in the end it's a space/time trade off.
If you can't decide what settings to use, just offer 3 settings, low/medium/high.
If you can't decide which algorithm to use, let user choose 1 out of 3 algorithms, give users the choice.
Compression is simple, libs and examples are everywhere, just figure it out.
Stop giving stupid excuses and stop mumbling irrelevant bullshit.


Like they said, "I could tell you but then I'd have to kill you."
Too much hassle.

Fun fact: Mike Hearn contributed a grand total of something like 6 relatively minor pull requests-- most just changing strings.  It's popular disinformation that he was some kind of major contributor to the project. Several of his changes that weren't string changes introduced remote vulnerabilities (but fortunately we caught them with review.)

Yes, I've been using Bitcoin pretty much its entire life and I can easily demonstrate it. My expertise is well established, why is it that you won't show us yours though you claim to be so vastly more skilled than everyone here?

From 2009? ... you know that the blocks are not accessed at all, except by new peers that read all of them right?  They're not really accessed any less accessed than blocks from 6 months ago. (they're also pretty much completely incompressable with lz4, since unlike modern blocks they're not full of reused addresses).

As to why? Because a 10% decrease in size isn't all that interesting esp at the cost of making fetching blocks for bloom filtered lite nodes much more cpu intensive, as that's already a DOS vector.


[Edit: dooglus points out the very earliest blocks are actually fairly compressible presumably because they consist of nothing but coinbase transactions which have a huge wad of zeros in them.]

Uh, sounds like you're misinformed on this too:  Pruning makes absolutely no change in the security, privacy, or behavior of your node other than that you no longer help new nodes do their initial sync/scanning. Outside of those narrow things a pruned node is completely indistinguishable.  And instead of only reducing the storage 10%, it reduces it 99%.

Lz4 is fine stuff, but it isn't the right tool for Bitcoin almost all the data in Bitcoin is cryptographic hashes which are entirely uncompressable.  This is why a simple change to more efficient serialization can get over 28% reduction while your LZ4 only gets 10%.     As far as other things-- no we won't: block data is not like ordinary documents and traditional compressors don't do very much with it.

(And as an aside, every one of the items in your list are exceptionally slow. lol, for example I believe the top item in it takes it about 12 hours to decompress its 15MB enwiki8 file. heh way to show off your ninja recommendation skills)

If you'd like to work on compression, I can point you to the compacted serialization spec that gets close to 30%... but if you think you're going to use one of the paq/ppm compressors ... well,  hope you've got a fast computer.
 
Can you show us a non-trivial patch you made to any other project anywhere?

How about just posting a link (as I've asked 3 times now) to where you advocate "switching to --i instead of ++i"?

I am quite aware of what "goes on inside a CPU" and have actually done several CPU designs.  Although I think you need to drop the "Buster" since you are just trolling us.

How about the entire XT team for starters:


Right, if the logic doesn't work, just fall back to using registration date and post counts to establish authority.

Like the guy above you who claimed to have "30 years experience" while demonstrating less knowledge about CPU and compilers than a snot nosed newbie drone programmer.


At the time I didn't even know you guys were stupid enough to not compress the 150G of blocks, until someone reminded me in that thread. Seriously what is the point leaving blocks from 2009 uncompressed? SSD is cheap these days but not that cheap.


So after all the talk about your l33t porn codec skills, your solution to save space is to just prune the blocks? LOL. You might as well say "Just run a thin wallet".

Why do you think compression experts around the world invented algorithms like Lz4? Why do you think it's part of ZFS? Because it is fast enough and it works, it is simple proven tech used by millions of low power NAS around the world for years.


I would have made patches a long time ago if the whole project wasn't already rotten to the core.




I see you just added this part:


Here, there are over 100 compression algorithms, all invented and benchmarked for you.
You'll easily find one that has a size/speed/mem profile that just happen to work great on bitcoin block files and is better than LZ4.

Just pick ONE.

Everyone knows compression costs performance, it's for space efficiency, wtf are you even on about.

Most people's CPU is running idle most of the time, and SSD is still expensive.

So just use RocksDB, or just toss in a lz4 lib, add an option in the config and let people with a decent CPU to enable compression and save 20+G.