Bitcoin Forum
March 28, 2024, 10:29:16 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 [53] 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 »
  Print  
Author Topic: The Barry Silbert segwit2x agreement with >80% miner support.  (Read 119957 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
DooMAD
Legendary
*
Offline Offline

Activity: 3738
Merit: 3081


Leave no FUD unchallenged


View Profile
July 05, 2017, 08:34:05 PM
 #1041

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.

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.

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
1711621756
Hero Member
*
Offline Offline

Posts: 1711621756

View Profile Personal Message (Offline)

Ignore
1711621756
Reply with quote  #2

1711621756
Report to moderator
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711621756
Hero Member
*
Offline Offline

Posts: 1711621756

View Profile Personal Message (Offline)

Ignore
1711621756
Reply with quote  #2

1711621756
Report to moderator
1711621756
Hero Member
*
Offline Offline

Posts: 1711621756

View Profile Personal Message (Offline)

Ignore
1711621756
Reply with quote  #2

1711621756
Report to moderator
CuriousInvestor
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
July 05, 2017, 09:25:54 PM
 #1042

1) What is Bitmain's incentive to back Segwit2x? Is there a version of Segwit where Covert ASIC Boost mining still works? Referring to this blog: https://medium.com/@WhalePanda/asicboost-the-reason-why-bitmain-blocked-segwit-901fd346ee9f
"Bitmain wanted to push Segwit either through a hard fork, or in Extension Blocks which would be compatible with their ASICBoost. A soft fork of Segwit, which is by far the safest option, isn’t compatible and they would lose their advantage over other miners."

There is no proof Bitmain uses asicboost on live chain. The structure of their blocks indicate they dont.
But I dont doubt they tested/developed it.


2) If 80% Signaling is reached and Segwit2x (BIP91) is locked in before August 1, and then UASF fails due to this activation (too little hash power support, subjected to replay attack), will Bitmain be able to pull out still afterwards so there will be no Segwit, which will delay Segwit?

In your case SegWit2x is compatible with the UASF BIP148 activation, so your following speculation is moot.

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.
DooMAD
Legendary
*
Offline Offline

Activity: 3738
Merit: 3081


Leave no FUD unchallenged


View Profile
July 05, 2017, 10:08:46 PM
 #1043

In your case SegWit2x is compatible with the UASF BIP148 activation, so your following speculation is moot.

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.

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
CuriousInvestor
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
July 05, 2017, 11:06:52 PM
 #1044

In your case SegWit2x is compatible with the UASF BIP148 activation, so your following speculation is moot.

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.

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.

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.
Troll Buster
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
July 06, 2017, 12:34:10 AM
Last edit: July 06, 2017, 01:46:08 AM by Troll Buster
 #1045

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.

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.


Troll Buster
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
July 06, 2017, 12:53:20 AM
Last edit: July 06, 2017, 08:50:29 AM by Troll Buster
 #1046

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.

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

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.
Cuber Krypton
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
July 06, 2017, 01:59:04 AM
 #1047

In your case SegWit2x is compatible with the UASF BIP148 activation, so your following speculation is moot.

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.

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.

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.
Paashaas
Legendary
*
Offline Offline

Activity: 3414
Merit: 4319



View Profile
July 06, 2017, 02:30:42 AM
 #1048

And Core code is shit

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  Kiss
Troll Buster
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
July 06, 2017, 02:32:48 AM
 #1049

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.
JayJuanGee
Legendary
*
Offline Offline

Activity: 3668
Merit: 10063


Self-Custody is a right. Say no to"Non-custodial"


View Profile
July 06, 2017, 03:06:42 AM
 #1050

And Core code is shit

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  Kiss

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

1) Self-Custody is a right.  There is no such thing as "non-custodial" or "un-hosted."  2) ESG, KYC & AML are attack-vectors on Bitcoin to be avoided or minimized.  3) How much alt (shit)coin diversification is necessary? if you are into Bitcoin, then 0%......if you cannot control your gambling, then perhaps limit your alt(shit)coin exposure to less than 10% of your bitcoin size...Put BTC here: bc1q49wt0ddnj07wzzp6z7affw9ven7fztyhevqu9k
ComputerGenie
Hero Member
*****
Offline Offline

Activity: 1092
Merit: 552


Retired IRCX God


View Profile
July 06, 2017, 04:11:25 AM
 #1051

Why the hell is Core still stuck on LevelDB anyway?
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.  Roll Eyes

If you have to ask "why?", you wouldn`t understand my answer.
Always be on the look out, because you never know when you'll be stalked by hit-men that eat nothing but cream cheese....
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1060



View Profile
July 06, 2017, 04:28:57 AM
 #1052

Saves at least 10-20G out of a 150G blockchain just by switching.
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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Troll Buster
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
July 06, 2017, 04:54:03 AM
Last edit: July 06, 2017, 08:20:18 AM by Troll Buster
 #1053

Saves at least 10-20G out of a 150G blockchain just by switching.
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.


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.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4060
Merit: 1622


Ruu \o/


View Profile WWW
July 06, 2017, 05:08:42 AM
 #1054

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Troll Buster
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
July 06, 2017, 05:13:06 AM
 #1055

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.

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

Activity: 2128
Merit: 1060



View Profile
July 06, 2017, 04:13:27 PM
 #1056

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 hope you'll not delete my post. The reason why technical arguments are important in a political discussion is that they are the simplest way to do distinguish between empty politicking and true long-term planing. Even non-technical people can understand those arguments.

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

This is the type of gang-warfare argumentation: LevelDB-s contra RocksDB-s.

It is my understanding that -ck was involved in the Linux kernel development. Long time ago Linux was mired in the internecine warfare of various gangs of fanboi-s for the various file systems. The strategic choice wasn't to choose one over the other, it was to implement an abstraction layer for any file system underneath: https://en.wikipedia.org/wiki/Virtual_file_system . That's because there isn't a single universal best file system, there are however best filesystems for various usage scenarios.

The same approach is the correct one for any Bitcoin client implementation: there is a need to implement an abstraction layer(s) for the blockchain and transaction storage. And remember: mempool is also a database, although rather trivial.

Some supporters of segwit2x (and other proposal) make political arguments about decentralization of Bitcoin client development. It could be fairly easy to see if they really support decentralization by asking them about their stance about abstracting the storage engines used by the Bitcoin clients.

The rest of the technical arguments will be in a parallel thread: https://bitcointalk.org/index.php?topic=2006262.0 .

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
BillyBobZorton
Legendary
*
Offline Offline

Activity: 1204
Merit: 1028


View Profile
July 06, 2017, 04:23:07 PM
 #1057

Nobody will be stupid enough to run segwit2x code, and those that do will pay, just like they paid with Buggy Unlimited crashing. It's only a matter of time they get exposed for being amateurs. Meanwhile Bitcoin Core will continue being the most robust and stable software.

If Bitmain is stupid enough to hardfork into the NYCoin, whales will dump and crush NYCoin. It's as simple as that. There will be no stupid hardfork to 2MB backed by unsafe code.
The One
Legendary
*
Offline Offline

Activity: 924
Merit: 1000



View Profile
July 06, 2017, 04:39:05 PM
 #1058

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.

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

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.

Not to dispute what you had wrote, but memory is faster than HDD and using memory to store temporary data is faster than using HDD.

..C..
.....................
........What is C?.........
..............
...........ICO            Dec 1st – Dec 30th............
       ............Open            Dec 1st- Dec 30th............
...................ANN thread      Bounty....................

ComputerGenie
Hero Member
*****
Offline Offline

Activity: 1092
Merit: 552


Retired IRCX God


View Profile
July 06, 2017, 05:15:58 PM
 #1059

Nobody will be stupid enough to run segwit2x code, and those that do will pay, just like they paid with Buggy Unlimited crashing. It's only a matter of time they get exposed for being amateurs. Meanwhile Bitcoin Core will...There will be no stupid hardfork to 2MB backed by unsafe code.
Careful, your inner, fact-ignoring fanboy is showing.  Roll Eyes

If you have to ask "why?", you wouldn`t understand my answer.
Always be on the look out, because you never know when you'll be stalked by hit-men that eat nothing but cream cheese....
JayJuanGee
Legendary
*
Offline Offline

Activity: 3668
Merit: 10063


Self-Custody is a right. Say no to"Non-custodial"


View Profile
July 06, 2017, 06:29:45 PM
 #1060

Nobody will be stupid enough to run segwit2x code, and those that do will pay, just like they paid with Buggy Unlimited crashing. It's only a matter of time they get exposed for being amateurs. Meanwhile Bitcoin Core will...There will be no stupid hardfork to 2MB backed by unsafe code.
Careful, your inner, fact-ignoring fanboy is showing.  Roll Eyes

What are the relevant and material facts being ignored?

There remains a question about how many changes there are going to be in software  and software run in the coming months.

This is called speculation about the future based on what we have seen in the past, so there is going to be some interesting dynamics to see how many folks actually begin running various modalities of segwit2x software or if segwit gets activated by some other seemingly "safer" means, no?  And the safer means would be running some kind of core implemented software, right? 

We already seem to have some shifting in core by the release of BP148 code, correct?

- mentioned a couple pages back.

https://bitcointalk.org/index.php?topic=1928093.msg19940344#msg19940344

1) Self-Custody is a right.  There is no such thing as "non-custodial" or "un-hosted."  2) ESG, KYC & AML are attack-vectors on Bitcoin to be avoided or minimized.  3) How much alt (shit)coin diversification is necessary? if you are into Bitcoin, then 0%......if you cannot control your gambling, then perhaps limit your alt(shit)coin exposure to less than 10% of your bitcoin size...Put BTC here: bc1q49wt0ddnj07wzzp6z7affw9ven7fztyhevqu9k
Pages: « 1 ... 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 [53] 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!