Topic: can someone point me to hard (objective) technical evidence AGAINST SegWit? - page 2. (Read 2597 times)

They already tried to ram Segwit down Litecoin users' throats:

https://www.litecoinpool.org/pools
How much of the hashing power is signaling SegWit support? NEW!
    About 540 GH/s, or 22.0% of the network (110 out of the last 500 blocks).

Total fail. No one wants this!


I agree with this assessment. However, bitcoin has always had flaws other than the artificially constrained blocksize and the resultant high fees and slow confirmations. Difficulty re-targeting is broken. The currency emission rate is not optimal, etc.. But Bitcoin has the largest market cap and a huge lead in adoption, credibility, and investment.   That said, its first mover advantage is fading as we speak.



You present a false dichotomy - firstly they are not opposites, secondly they are not the only options on the table. Segwit is a wonky code fork that will be forgotten in 2 years. BU is a wacky attempt to challenge Core's status quo, and will also likely be forgotten in two years. Hard fork to 2MB blocks with no other changes from 0.12 is still possible at any time. A bitcoin hard fork was done in 2014 without issue.

I guess you didn't even read this thread or the links posted in it? I count the word "code" 36 times on this page alone. If the thread still isnt technical enough for you after you're actually read it (and the articles linked), read the code. It's an attempt to rewrite the signature layer of bitcoin, and these changes are supposed to propagate on the live network without breaking anything.

Also, you implyiing that technical arguments are more "substantial" than political ones?

I am also looking for evidence against SegWit but am having problems finding something substantial. Most of it is political, not technical...

What is the status of the "lets do nothing camp"?

On https://coin.dance/blocks#hashrate I noticed a few pools signal neither (SegWit/BU):

https://pool.btc.com/
https://bixin.com/
http://solo.ckpool.org/
http://btc.top/
https://xbtc.exx.com/

to name a few.

Do they even know all this debate is going on?

You got it.  So a coin should remain itself, and when it is outdated, people should switch to other coins.  Simple as that.  The coin remaining itself can maybe still maintain a niche application.  And most probably what will happen in the long run.

But what is the alternative, to sit and do nothing beyond hoping endless blocksize increases can cope somehow with user adoption rates? I suppose an altcoin can be cajoled into doing SW first, but that should have been done a year ago if really needed.

The dilemma Bitcoin is now in runs as follows: Cryptocurrency is rapidly innovating, and coins that lack the feature set and capabilities of newer coins are likely to die out no matter how popular they once were. (That's why we no longer see Model T's on the road.) On the flip side, technical issues or exploits associated with changes can kill a coin real fast.

Core and Bitcoin Unlimited now exemplify the dichotomy in how Bitcoin approaches these two risks. On the one hand we have the "Go-too-slow" approach of Core, which has been patiently waiting for miners to adopt SW/LN while the rest of the crypto space keeps advancing. On the other hand we have the buggy development of hard-charging Bitcoin Unlimited and their "You have to fork it to find out what's in it" approach handing over protocol power to the miners in an unprecedented and risky manner.

The Segwit soft fork has the potential for a TON of these types of issues. As you say, they're very time-consuming to find and fix. At this point it's likely that Segwit will not move forward, and development will probably need to shift in some way. If Core tries to ram Segwit through with a UASF (User activated soft fork), the Bitcoin Unlimited folks will likely try to hard fork the blockchain. In this case there could be as many as 5 different bitcoin implementations fighting for the highest adoption for consensus. A crazy scenario, likely to be very contentious. If this does come to pass, it will forever be part of software development history! And you'd better believe that there will be some hard lessons on why you must test your code extensively and keep it simple...

In my experience, asynchronous issues that can occur on a live system are very difficult to replicate in a test environment. They can be very difficult to diagnose and fix.

Surely SegWit provides a lot more advantages than just a solution to the problems of transaction delays. SegWit increases the potential intelligence that can be built into transactions.

I understand the problems, but I still believe that it would be better to try to find ways to decrease the block generation time to keep Bitcoin fast and agile, rather than increasing the blocksize so that it is about as fast as a McDonalds customer.

I didn't say the devs weren't responsible. 15-50 defects per KLOC is a software industry average. Add in one defect per thousand lines for each covert NSA/CIA employee at the company. /s

Test code can have bugs in it, and when it does, they can obscure bugs in the main code.

Unit tests often miss higher-level bugs that require live interaction, timing, or edge case scenarios. Like, say protocol changes on a live running network with thousands of contentious and/or malicious actors?

Bugs in Segwit have been found and fixed. But you can never really certify code bug-free. That's why it's best to keep changes as simple as possible and keep the total lines changed to a minimum.  

Nobody shouting from any towers here, Carlton. Unless you are?

All software has bugs. The questions are: has anyone found them, what are their consequences, and how easily can they be fixed?

Sometimes the bug is in the dev's head - there seems to be an innate desire of the coder to over-complicate matters... known colloquially as "Error occurred between keyboard and seat".

litecoin has been running for 6 years..
but i dare you to start throwing litecoin rules and keys into bitcoin on activation day.

there is a big bug known about since last year. instead of fixing it, they are doing work arounds.
such as the upstream downstream. not relaying segwit unconfirmed tx's to native nodes, banning native nodes from being upstream and preventing native blocks from being produced ontop of segwit...

yet you will remain adamant thats is all "compatible" LOL

That's... not how it works. I think that the core developers have been quite responsible, a lot of unit tests have been written for the code changes.

You forgot to subtract all the LoC that are adapted or new testing code They form most of the changes, i.e. the Bitcoin devs are being as assiduously diligent as possible.

You also forgot to mention how many bugs have been found and fixed (having not caused any incident, as you'd be shouting about it from the roof of your tower block) on the Bitcoin Testnet, which has been running live Segwit for over 6 months

Sorry it's 5.305 lines added, 571 lines removed, for a total of 5,876 changed lines, in EIGHTY files. https://github.com/bitcoin/bitcoin/pull/8149/files

Industry average being 15-50 defects per thousand lines of code (source: Code Complete), would yield  87 - 290 bugs in Segwit. Most would be minor, but a few... Not to mention the implementation bugs in 3rd party wallet, exchange, and utility code. A nightmare. Or, maybe job security for a bunch of coders?

There must be a typo there...For a second it looked like you said 50,000 lines of code.

That section also stood out to me, because I wasn't aware of this issue, I know that UTXO bloat is a big concern for everybody.  

I suppose the Core devs mean that, assuming Segwit activation plus some percentage, the old UTXO set SHOULD be near empty and could be retired?

To me this shows Core's level of arrogance in assuming that everyone would be running their code...
 

Segwit changed 5,000 lines of code in bitcoin core, and requires refactoring thousands of lines of code in exchange, wallet, and utility software. Statistically guaranteeing 100+ bugs.


No one is banning knives.

This oddly-shaped Segwit knife that requires everyone to build new knife racks is being put back in its packaging and returned to the vendor. We've still got a ton of cutting to do, and there is a Unlimited knife handy that claims to enable us to do that cutting. Many are using it simply because it's an alternative.

It sure would be nice to just have a knife that works and everyone can use.

Rico, good post.  i may look into some of this stuff.

almost feels like Nancy Pelosi saying "we need to pass obamacare so we can find out whats in the bill"

this thing is huge and messy.

and people think its a good idea to activate this BEFORE we simply increase the blocksize?  why??

Thanks for the
https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
it is very thorough in describing SW.

In fact so thorough, that for the "Problems with SW" only about 30% of the article remain.
Naturally I had a deeper look at these

as for 3.1 SW creates a financial incentive for bloating witness data


Unfortunately it's not elaborated what this financial incentive is or how it comes into play. Maybe I'm overlooking something evident, but as is in the article it is a simple statement without any proof or even explanation.

as for 3.2 SW fails to sufficiently address the problems it intends to solve

This section contains a very weak, almost no-argument against SW, namely

i.e. "The good properties of SW will not be available to non-SW UXTOs", which in itself is a homage to SW and similar to the argument like

"But Bitcoin will not fix the USD..."

On the other hand, it contains a very strong argument - the strongest I've seen so far - against a new UXTO class:


I followed the link to the reddit discussion and I didn't believe what I've read. If there are really people in the Bitcoin community who want to put an expiration date to Bitcoins, and some UXTO discrimination should help these f*cktards to achieve their wet fantasies. Then I have to agree: We cannot have that.

It doesn't seem like a genuine SW-UXTO problem though, more than SW-UXTO being a vehicle for discrimination according to hypothetical future bad politics. This seems like killing your newborn, because it might become Hitler.

=> Again, no technical argument, merely a political. But it surely scared the shit out of me.


as for 3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits

It essentially says: "There is code change involved and that's dangerous, SW does not provide enough benefit to justify the risk of bugs in the new code."

Well - the question is, if BU or other proposals do provide enough benefit, because as is, this argument could be interpreted as "Never change a running system".

as for 3.4 Economic distortions and price fixing

purely non-technical and may be titled "I do not like soft-forks"

as for 3.5 Soft fork risks

reiteration of "I do not like soft-forks"

as for 3.6 Once activated, SW cannot be undone and must remain in Bitcoin codebase forever.

While not providing evidence for the claim there could be no roll-back, I give him that: Not having a plan B (roll-back) for the case of some catastrophic sideways fuggup is a bad thing. In general.


Executive Summary:

SW may give zealots the possibility to discriminate between SW-UXTOs and non-SW-UXTOs (a.k.a. our old good UXTOs) and as such might help foster some "interesting" novel Bitcoin policies, like destroying old coins etc.

Well - theoretically - it might. But I believe this is also a non-technical issue and more an educational one. Should such an issue arise, the bitcoin community should still be "man enough" to take a stick and beat the shit out of such zealots until they come to reason.

Executive executive Summary:

SW is like a knife: It can be useful in the kitchen, or you might slash your wrist with it. Should we ban knives?


Rico

This is the worst argument against Segwit I've seen yet. The whole point of miner fees is to pay them for the work they do to confirm ON-CHAIN transactions. Why on earth should anyone pay them when they are not doing any work, for offchain TX???

The blockchain will by necessity remain the backbone of bitcoin in a segwit/LN ecosystem. It just won't be under the monopoly rule of the miners, giving people more options. That's why the miners are fighting it.

So let's repeat the question the OP stated: Where are the technical objections to Segwit? It's looking now like there is very little.

And now, the question is: why should one pay miners ?  Answer: in a PoW system, you HAVE TO pay miners a HUGE AMOUNT of money, because the security of the system depends on that ; but also, in a PoW system, it are the miners that have the vote over the protocol.  THIS is why segwit will not be activated: miners don't want this lucrative market be crippled.  And why they give enough lip service to BU or whatever alternative: not because they want that activated, but to stop segwit from being activated. 

However, there's no way in which a "banking layer" can be avoided on top of a crypto.  The only thing is, a crypto with a banking layer on top (like LN) has absolutely no advantage over a fiat banking system.  So the problem is simply that: a crypto with a banking layer is useless.  LN or something else.

In a PoW system,if a fee market is in place, nothing is going to change that, because it is now immutably a part of the consensus.

OK,  
Boyo you asked for it.  

https://bitcointalksearch.org/topic/m.18100392
https://bitcointalksearch.org/topic/m.18105140
https://bitcointalksearch.org/topic/m.18105140
https://bitcointalksearch.org/topic/m.18094064

Cliff Notes, for those not liking to read.
Segwit allows LN to steal transaction fees from the Onchain Miners.
(Common lie is that once LN is activated Miners will make more money.)
So lets test that,
If I tell you , you will make more money if you give me your Paycheck every 2 weeks , are you dumb enough to believe it?
If so , I can PM you a PO Box , where you can send me your paycheck.  
(that is why segwit is really deadwit.)