Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 34. (Read 120014 times)

Fine, I can respect a man with standards, I'll leave the performance bitching for another day.

Now you're seriously offtopic in my opinion (and since this is my thread my opinion gets final word). Complain all you like about the core code (I'm not a fan of its performance either), but do it elsewhere please. Let's stick to segwit2x discussions or I'll start deleting posts.

I see, on top of those, they're also storing the chainstate.

Wait, you mean they're not actually compressing the blk files at the moment? That's even worse.

If you want performance there are far better choices than LevelDB. The whole point of using LevelDB is for the compression, wtf are they not using it for the blocks?

Compressing the block files saves way more than 10G, for a 150G blockchain you save at least 20G with something like Lz4.

You would have thought they'd actually care about storage space when they're the one bitching about larger blocks and using Raspberry Pi as an excuse for small blocks.

Even then I still don't get why they are stuck with LevelDB, RocksDB is clearly far superior.

When the index and chainstate alone reaches 150G, switching to RocksDB will still save 10G or more.

And why are they not compressing the blk files?

When you compress them you read more in each read, CPU speed is not the bottleneck, memory speed is, so when you read less memory, you gain more speed even if you use more CPU for compression/decompression.

No way. Blockchain isn't stored in LevelDB. It is stored in raw data files (blk*.dat) and raw undo files (rev*.dat). LevelDB is used only to store indices into those raw files. "Just switching" wouldn't change the situation much, it takes rather substantial rewrite to change the storage engine in Bitcoin Core.

The same reason BDB hasn't ever been replaced, because even after a softtfork and a hard fork, new wallets must still be backwards-compatible with already nonfunctional 2011 wallets. 

He can whine about it.. which seems to be what he is doing right now... preemptively.   

Why the hell is Core still stuck on LevelDB anyway?

RocksDB Features that are not in LevelDB

RocksDB is way more advanced and allows much finer control on how to store/compress/read data.

You can store tx older than 1 year with profile optimized for space efficiency (huge compression), because they have the least chance of being read during normal operation.

Then store recent tx with profile optimized for read and write, no compression.

LevelDB has similar features but RocksDB is far more advanced.

Saves at least 10-20G out of a 150G blockchain just by switching.

When the blockchain reaches 2TB-100TB, use two RocksDB profiles, one for SSD, and one for mechanical disks, store recent years on SSD, older years on mechanical disks, mirror/raid the disks if you have to.

Pure r/btc FUD.

Core did a very good job, we will have Segwit in the comming months and there is nothing you can do about it 

I would go so far as to say, that you can choose to be dishonest. That indeed is the essence of choice.

As regards to patenting, sadly, they do slow down innovation. They don't stop it.

Anyway, no patent is going to obligate anyone to use Bitcoin. This is why I say i.e. Bitmain has no interest in conquering a 100% Monopoly on Block Production. If they happen to be the only ones producing blocks, anyone is free to create new software and fork it off.

The real choice here is with the users. And users vote with their money, not with their "nodes".

But there is alot of populism in this discussion. In Bitcoin, as in all choice related systems, information is essential.

Nokia was also good at testing and reliability, where are they now?

And Core code is shit, anyone experienced in writing kernels/drivers, or ultra low latency communication/financial/military/security systems would instantly notice:

1. The general lack of regards for L0/L1/TLB/L2/L3/DRAM latency and data locality.
2. Lack of cache line padding and alignment.
3. Lack of inline assembly in critical loops.
4. Lack of CPU and platform specific speed ups.
5. Inefficient data structures and data flow.
6. Not replacing simple if/else with branchless operations.
7. Not using __builtin_expect() to make branch predictions more accurate.
8. Not breaking bigger loops into smaller loops to make use of L0 cache (Loop tiling).
9. Not coding in a way that deliberately helps CPU prefetcher cheats time.
10. Unnecessary memory copying.
11. Unnecessary pointer chasing.
12. Using pointers instead of registers in performance sensitive areas.
13. Inefficient data storage (LevelDB? Come on, the best LevelDB devs moved onto RocksDB years ago)
14. Lack of simplicity.
15. Lack of clear separation of concerns.
16. The general pile-togetherness commonly seen in projects involving too many people of different skill levels.

The bottleneck of performance today is memory, the CPU register is 150-400 times faster than main memory, 10x that if you use the newest CPUs and code in a way to make use of all the execution units parallelly and make use of SIMD (out-of-order execution window size, 168 in Sandy Bridge, 192 in Haswell, 224 in Skylake).

One simple cache miss and you end up wasting the time for 30-400 CPU instructions. Even moving 1 byte from one core to another takes 40 nanoseconds, that's enough time for 160 instructions on a 4GHz CPU.

You take one look at Core's code and you know instantly most of the people who wrote it knows only software but not hardware, they know how to write the logic, they know how to allocate and release memory, but they don't understand the hardware they're running the code on, they don't know how electrons are being moved from one place to another inside the CPU at the nanometer level, if you don't have instinctive knowledge of hardware, you'll never be able to write great codes, good maybe, but not great.

Since inception, Core was written by amateurs or semi-professionals, picked up by other amateurs or semi-professionals, it works, there are small nugget of good code here and there, contributed by people who knew what they were doing, but over all the code is nowhere near good, not even close, really just a bunch of slow crap code written by people of different skill levels.

There are plenty of gurus out there who can make Core's code run two to four times faster without even trying. But most of them won't bother, if they're going to work for the bankers they'd expect to get paid handsomely for it.


So even a Core fan boy have to agree that Core must fall in line to stay relevant.

A fan boy can fantasize everyone flocking back to Core after they lose the first to market advantage.

But the key is even if Core decide to fall in line to stay relevant, they can no longer play god like before.

So what's your point.

That is so stupid.

Look around, every phone looks the same, same features, same OSes.

Here you are starting an argument claiming that is not possible.

Just what cave have you been stuck in for the past 8 years.

Even the subsequent logic is wrong.

Nokia had and still has one of the biggest arsenal of mobile related patents. Apple still have to pay royalties to Nokia today:
Apple to pay Nokia big settlement plus royalties in patent dispute

Nokia was the undisputed heavy weight champion in both market share and patent.

Nokia had enough patents to blast Apple into oblivion before Apple even begin, but Nokia didn't pay attention until it was too late.

Nokia simply underestimated Apple, Nokia thought they were the standard and it would stay that way forever, if Nokia reacted quickly to user demand and followed the path of Samsung, you'd still see Nokia in the market today.

Stop making stupid arguments over things you don't understand.

I see, what you say is true. I know this seems biased but I am in favor of BIP148 because it frees us from miner overpowering the decisions. There is too many conflicts of incentives to try and move segwit forward. Segwit2x still gives miners the option to Veto at any moment, since the hash power is so centralized. Just my opinion though, apologies for using the word honest.

Due to BIP91, SegWit2x is indeed compatible with UASF BIP148 activation, regardless of bit1 vs bit4.  The best article I've seen so far to explain it is this one.

Also, it simply isn't the case that "any honest segwit supporter should support BIP148 over Segwit2x" because real choice doesn't involve alluding to telling people what they can or can't support by questioning the integrity of those you might disagree with.  By throwing the word "honest" in there, you are opting to include a thinly veiled insult to your perceived opponents.  The choice isn't nearly as binary or black and white as you portray.

Don't think Segwit2x is compatible with UASF BIP148 activation(Bit1 vs Bit4), the main point of UASF isn't activating segwit, rather it stops miners from stopping people from adopting segwit. Segwit2x still requires for 80% consensus, it is really hard to say whether or not a mining pool like Bitmain (who controls 20%) can pull out last second. Any honest segwit supporter should support BIP148 over Segwit2x, because it gives people a real choice, not succumb to miner's power.

If you're talking about physical hardware with a specific manufacturer and point of origin, like mining chips that take advantage of asicboost, again, physical products can indeed fall afoul of patents.  That's literally what I just said.  Try to keep up.  It's pretty clear Troll Buster was talking about code.  Not a physical product.

My point was, that when it comes to open source software, like the code that governs Bitcoin, all that becomes irrelevant.  Code what you like, copy what you like, no one can stop you.  It's entirely up to you if your code conforms to consensus or proposes a change to consensus and then it's up to users if they want to run that code or not.  If anyone wanted to stop you from copying their code, they have to go down the route of closed source, which then involves willingly removing themselves from Bitcoin because closed source is for bankster crapcoins like Ripple and no user in their right mind wants that.  So again, any developer can decide to jump on board with a 2MB fork and wouldn't have to sacrifice market share if users still want to run their code.

I think that if the code is open source, then you can do whatever the fuck you want.

A problem could come in the event someone tries to claim that he had already patented or copyrighted the code, but in a decentralized system, who the fuck is going to be sued for such?  

You gonna file a lawsuit against core?  What is core,  a bunch of loosely affiliated contributors, right?  You gonna individually sue them or individually sue the ones that have the commitment rights for approving code that might have been patented?

Sure it is possible to file such lawsuits and even file them as a form of harassment suit.

What is the name of this mystical, not-Earth planet that you "envision"?  

Please tell us more. I especially would like to hear how we have a completely decentralized crypto coin without any patents or whatsoever. Also mention how great bitmain is and its contributions to our decentralized system and its non-patented software ASICBOOST. I'd like to know more.

The Apple/Nokia thing doesn't really apply here in our permissionless system.  In "real world" products, sure.  Patents mean that one company can't release an identical (or near-identical) product to that of a competitor.  That isn't allowed and they can be prevented from doing it.  But we don't have anything like that here in cryptoland.  If there is adequate support to activate a 2MB fork (and I agree there may well be), any developer can simply slap a 2MB cap in there and carry on as though nothing had happened.  That is allowed and they can't be prevented from doing it.  So in effect it's the complete opposite to Apple/Nokia.

The thing to bear in mind is that Core have an exemplary record for testing, bugfixing and just generally having an incredibly stable and reliable codebase.  So while people may run SegWit2x code in the interim to make sure it's activated, I envision many of them would switch back to Core the moment Core release compatible code.  As such, any loss in Core's dominance would probably only be temporary.

In short, I agree there's probably enough support to active a 2MB fork, but I disagree that Core will lose any significant market share over the long term, even if the 2MB fork creates the longest chain and earns the Bitcoin mantle.

Like the world is going to care about the <10% chain running on Raspberry Pi.