...
I guess there is often a ton of code to merge but I believe Segwit was by far the most
complicated change which has had basically
zero impact on the scaling problems that are now becoming very serious with the fees going parabolic and effectively locking up to 50% of coin inputs. BTC is bleeding while Greg is drinking "champaign", I don't think I wish to follow this genius any further down the road he is building...
It looks like people are taking in interest based on market demand...
You've lost me now... these projects have no shortage of questionable people surrounding them, I think it's best to try to ignore all of that and focus on implementation. You've given a line count now and say it's complicated. Can you point to where in that 6k line count it's complicated? Where it's not addressed in unit-testing? I need technical specifics to understand. Segwit is actually a very small part of this v0.14 update, a tightening of consensus rules / not a hard fork, and it's an optional type of transaction to boot.
I agree that we don't need to worry about personalities. 6000 lines of dense code that changes consensus on a distributed network is complicated and risky by nature.
I have to correct one word here, and that's "changes". If it were to change consensus it would be a hard fork. This is a "tightening" of consensus. Older nodes still work fine, you don't have to use segwit transactions if you don't want to.
I don't think we need to go line-by-line to agree on that?
Actually, yes, that's exactly what I'm asking for. Where exactly in the core software is the concern? Line number, function, etc. I'm looking for specifics and not page after page of conjecture.
Unit testing is good in Bitcoin Core but what's the point of it for a useless change?
I don't see it as a useless change. I am intrigued by new capabilities like cross-chain swaps, rootstock-like applications, lightning (almost-instant payments) and MAST (especially the privacy that MAST could deliver). I think many folks probably didn't see the point in BIP16 at the time, but now we have multisig and it seems like second nature.
On top of this, Segwit requires an estimated of 100k lines of code changes in all of the utility code in the ecosystem (building and revalidating transactions in the new format, wallets, etc.).
Do you have a source for this? Why can't they just continue to use traditional transactions if they don't want to participate? Regardless, I can only focus on the core client right now so let's keep the conversation focused there I suppose.
I really don't see anything in that link that specifically points to a flaw in the core client beyond the client not being complete yet. Good code takes time and peer review. From what I've observed I'm confident in the upstream process (which is not just Blockstream by the way). Core is still beta software after all. I'd hate to see someone suggest that because the Myriadcoin reference implementation is still evolving it can't be useful or interesting.
I'm sorry to see XMY/MYR get embroiled in this.
I'm glad we can talk this through like adults. This must be the first Segwit discussion I've had with anyone that didn't get heated and personal.
In my opnion Segwit doesn't work, and it hasn't solved the problems it was touted to solve, most notably SCALING (this is supported by stats on the BTC main chain, which is almost unusable right now due to limited blocksize and insane fees). Since scaling isn't an issue with Myriad (yet), Segwit was especially not needed. Let's face it - some coins jumped to adopt Segwit to get on the hype train. Litecoin and a few others pumped in value when they added Segwit, so others followed suit.
Segwit does make transactions smaller in some use cases, but it's so complicated that even the Bitcoin Core wallet doesn't support making transactions using Segwit. My understanding is that Segwit makes Lightning and other Layer2 solutions easier to implement - since those don't work yet I am not holding my breath. I also have serious issues with the concepts behind the L2 solutions and believe that they won't ever see mass adoption, even if they get the technical issues sorted out.
Again these are not line-by-line code issues, they're more like the "elephant in the living room". Code does stuff or it doesn't. In this case, the code doesn't do do anything tangible and is extremely complicated. My argument would be that therefore the code is not useful so should not be merged. I'm happy to be proven wrong by some future cool tech that uses Segwit features, but I guess we'll cross that bridge when we get to it?
I get that Segwit was complicated so that it could be a soft fork. But again, if no one is adopting it then what good is it? Even the Core people have stopped talking about it other than to complain that "nobody is adopting it".
Hindsight is always 20/20. At this point I can say that Segwit was a mistake. You probably know that devs rarely admit mistakes, and they very rarely roll back changes in software. So here we are with an albatross around our necks.
LOL at MyriadCash. Don't worry one MYR/XMY can rule them all!