Quote from: cellard on January 04, 2017, 06:33:51 PM

Quote from: CoinCidental on December 30, 2016, 02:00:55 PM

Quote from: Xesystme on December 30, 2016, 09:03:28 AM

Quote from: CoinCidental on December 30, 2016, 05:04:18 AM

Quote from: Hyena on December 21, 2016, 05:23:11 PM

Quote from: thejaytiesto on December 21, 2016, 12:58:42 PM

The elegant solution is segwit precisely because it doesn't require a hard fork. There's nothing cool about a hard fork, it's the opposite of elegant. Also you are asking for things that don't make sense technically. Segwit is everything that's needed to fix transaction malleability and so on, and it will make the LN better and allow us to have Schnorr sigs and other cool stuff that anyone that isn't a troll or stupid would agree to add at a protocol level.

Clearly you know nothing about software development. Hard forks are always times more clean and elegant than soft forks. The only problem with hard forks is that nodes which fail to update are going to be left behind for sure. SegWit's soft fork is no better than a hard fork because old nodes won't understand segwit transactions and they will just ignore them. For that reason SegWit is even worse than a proper hard fork.

SegWit won't activate unless there is strong consensus reached. Guess what? An elegant hard fork can also be made in a way that it won't activate unless a strong consensus is reached. Then why we have a soft fork hack called SegWit in the first place? There is no good reason for that. It's just dumb. They propagate this "soft fork" idea as if it was any better than a hard fork just to find more acceptance. It's a clever marketing. Why do the Core devs need sneaky marketing? So many questions, I'd say they are doing foul play. My own writings have now made me realize that I hate SegWit even more than before.

I agree with this

I think segwit introduces more complexity to the system than its fixing and reversal will be too difficult and dangerous to take the chance....

Thankfully there are other scaling offers on the table we can consider, including bu's gradual scaling approach and the new solution from lead devs called "teechan" definitely is worth considering before we do anything hasty like segwit

We may try the scale method used by other cryptnote coins such as the Monero. I think they are very elegant.

Definately ,elegant scaling that scales up or down according to use such as monero uses seems like a winner over some arbitrary block limit cap that needs to be raised via some fork every time we hit the new ceiling

if we could scale to 1.1mb for a while then 1.2mb etc that would be great ,miners will not make a massive block because it would simply orphan by the other 99% of network so that fearmongering simply isnt true

developers i have spoken to have said this and LN implemenation can be done without segwit safely and without
changing the underlying fundamentals that took us this far

Guess what's also "arbitrary", the 21 million coin limit. 1MB has been good enough, the node count is right now at 5k ish, this point out to 1MB being good enough for the current average hardware out there. Of course, in the future we will increase it further, but I don't see any other way but doing it "manually" through a roadmap. Once we get segwit, we will get 2MB. If we never get segwit, we may never get 2MB, because hard forking without segwit is a mistake, a lot of people aren't going to go through with it, so you can thank those that block segwit for any lack of further blocksize increases.

A dynamic blocksize may seem elegant at first, but if you study it further it appears to have severe exploitable problems.

forking without segwit is not a mistake if most people want higher block size.