Why don't we change the max coins to 7,000,000,000 so EVERYONE can have a Bitcoin?
That is how I feel about SegWit, block size increases, etc.
I am so sick of all the FEAR, people thinking Bitcoin won't scale or whatever. Just Leave it Alone already. If Bitcoin is flawed as is, then let it fail. If you think Bitcoin can be better with changes, then make your own Alt-coin.
It is working JUST FINE and has been for 8 YEARS.
More people = Slower confirmation times = HIGHER fees. This is GOOD for the Free Market and rewards Miners.
People will pay higher fees to get confirmed faster. Some people will be fine waiting 24 hours for a confirmation.
Just relax folks. You don't need instant dust transactions. There can be microwallets and altcoins for that.
Topic: If we didnt had idiots blocking segwit we would be sittting on 4 figures by now - page 3. (Read 7300 times)
January 05, 2017, 02:33:43 AM
January 05, 2017, 12:09:42 AM
...snip...
We're talking about 1 year of testing (up to today), 4-5 Months on a special testnet, and 7-8 Months on the Bitcoin testnet. That's as close as it gets to having it live on the main chain.
...snip...
We're talking about 1 year of testing (up to today), 4-5 Months on a special testnet, and 7-8 Months on the Bitcoin testnet. That's as close as it gets to having it live on the main chain.
...snip...
Deploying Segwit on a live altcoin network would be MUCH closer to having it on the main chain. Testnet coins have 0 value. Until there is value at risk, there is no reason other than ego to search for a flaw. It is utterly irresponsible to put a 18 billion dollar network at risk when the value of the networks it has been tested on stands at exactly $0.
January 05, 2017, 12:03:20 AM
Forget Segwit, Swgwit dont move markets, marketmakers too.
[i m g]https://i.imgflip.com/1fp0j1.jpg[/img]via Imgflip Meme Generator
[i m g]https://i.imgflip.com/1fp0j1.jpg[/img]via Imgflip Meme Generator
that was obviously because of halving hype. the second block reward halving happened in July (2016-07-09 to be exact) and before that there were a long period of FUD to keep price down around $450 and accumulate and then the big pump came, if we want to see that again we need something as big as halving and if not the price will continue rising slowly as before.
You are misguided son. Never dismiss the power of the marketmaker aiming for new highs. The force is strong and very hard to fight. Let's see what happens in 20 days from now.
/u/RemindMe! 20 days
i admit i did not see this happening 20+ days ago. apparently i need to change some of the mentality i have about this market to understand it better.
Respect.
January 04, 2017, 06:01:02 PM
I do believe that adopting Segwit or something similar that boosts TPS will have a positive impact on Bitcoin and it's price.
Yes its actually very impressive that price continues to climb, even in the midst of the blocksize debate (argument?)
Imagine what could be achieved if we were able to reduce transaction time, one of the main roadblocks for many business models that might consider accepting Bitcoin.
January 04, 2017, 05:54:02 PM
Here we can see that SegWit won't have any positive impact on the Bitcoin's ability to achieve 4 digits. We are already at 4 digits and we have achieved this WITHOUT SEGWIT. This proves that SegWit is not necessary for Bitcoin to soar in value.
This is a ridiculous train of thought. It could also be said that the fact that we are about to smash the last all time high proves that nobody gives a flying fuck about the block size anymore (which I personally think it was always the case... people only wanted to rush a block size increase because they thought it would trigger something like what we are seeing right now, only to find out that we are seeing it with still the good ol 1MB limit)
Im sure if someone makes that claim, you and the big blockers will come and say "bbut its in spite of the small block size.. if we were at 8MB blocks we would be at 10k!" or some ridiculous shit like that.
I personally think this applies to segwit, we are at 1k, but we would be at 2k+ if we had segwit, because segwit means blocksize increase incoming and more importantly, all the new cool features that come with it would be getting ready too.
so it's "ridiculous shit" when it goes against your politics, and sensible otherwise. Lol.
Either solutions, small or big blocker, would dramatically help the price, and for most speculators the subtleties are uninteresting. However, SegWit is NOT the solution. Lightning Network is the proposed "solution" and that will be a long way off even with SegWit enabled. Which is why we should have had a stop gap block size increase long ago, simply to demonstrate that the devs actually give a shit about the users.
January 04, 2017, 01:33:51 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.
January 04, 2017, 01:17:20 PM
Here we can see that SegWit won't have any positive impact on the Bitcoin's ability to achieve 4 digits. We are already at 4 digits and we have achieved this WITHOUT SEGWIT. This proves that SegWit is not necessary for Bitcoin to soar in value.
This is a ridiculous train of thought. It could also be said that the fact that we are about to smash the last all time high proves that nobody gives a flying fuck about the block size anymore (which I personally think it was always the case... people only wanted to rush a block size increase because they thought it would trigger something like what we are seeing right now, only to find out that we are seeing it with still the good ol 1MB limit)
Im sure if someone makes that claim, you and the big blockers will come and say "bbut its in spite of the small block size.. if we were at 8MB blocks we would be at 10k!" or some ridiculous shit like that.
I personally think this applies to segwit, we are at 1k, but we would be at 2k+ if we had segwit, because segwit means blocksize increase incoming and more importantly, all the new cool features that come with it would be getting ready too.
January 04, 2017, 12:01:53 PM
Here we can see that SegWit won't have any positive impact on the Bitcoin's ability to achieve 4 digits. We are already at 4 digits and we have achieved this WITHOUT SEGWIT. This proves that SegWit is not necessary for Bitcoin to soar in value.
January 04, 2017, 11:50:00 AM
that was obviously because of halving hype. the second block reward halving happened in July (2016-07-09 to be exact) and before that there were a long period of FUD to keep price down around $450 and accumulate and then the big pump came, if we want to see that again we need something as big as halving and if not the price will continue rising slowly as before.
You are misguided son. Never dismiss the power of the marketmaker aiming for new highs. The force is strong and very hard to fight. Let's see what happens in 20 days from now.
/u/RemindMe! 20 days
This is your 9 day left reminder, and things are just about to get very interesting. #2016bitcoinmoon
Still looking interesting with 2 days left.
How the hell did you call this?
January 04, 2017, 11:45:34 AM
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
I also think the bitcoin should adopt the Monero style of block size scale. There will be no argument later.
December 30, 2016, 09:10:34 AM
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
Well according to this article about "teechan" http://www.newsbtc.com/2016/12/25/teechan-can-potential-solution-bitcoin-scalability/, they are offering an easier scalability solution for the Bitcoin blockchain.
Now with this this will be very hard to choose on what to go on. Only one problem is with teechan, only Intel’s Skylake range of processors is equipped with Software Guard Extension, which makes it impractical until such solution becomes an industry standard, and this may be problem for implementing it in future.
i checked the list and i already have a compatible processor and it wasnt very expensive even a year ago (i5-6400)
the thing to remember is not every bitcoin user needs to have an intel cpu ,afaik its only miners,businesses and full nodes who would need one ..........they dont cost a lot and ordinary bitcoin users would benefit by default (roughly 2400 tx/ps )
December 30, 2016, 09:00:55 AM
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
December 30, 2016, 04:03:28 AM
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.
December 30, 2016, 03:15:46 AM
eh those idiots rightly believe that segwits may introduce some unknown security hole to the bitcoin environment, because it was not fully tested yet and bug can also appear at some point
if some sort of bug/exploit will emerge then you are forced to hard fork anyway, it's a gamble, it's better to directly hard fork to 2MB anyway
This claim is false. Once the developers figured out how to deploy Segwit via a soft fork, they've started developing it for Bitcoin (it was already a Blockstream project, but required a HF prior to that). They've released a Segnet (specific testnet for it) around last New Years Eve. Over time, there have been 4 versions of Segnet (IIRC), after which it was deployed on the testnet and actively tested/developed around April/May. if some sort of bug/exploit will emerge then you are forced to hard fork anyway, it's a gamble, it's better to directly hard fork to 2MB anyway
We're talking about 1 year of testing (up to today), 4-5 Months on a special testnet, and 7-8 Months on the Bitcoin testnet. That's as close as it gets to having it live on the main chain.
hardware centralization imho ..same problem ..wearing a different coat.....
Similar, not 'same'.I do believe that adopting Segwit or something similar that boosts TPS will have a positive impact on Bitcoin and it's price.
December 30, 2016, 02:55:33 AM
eh those idiots rightly believe that segwits may introduce some unknown security hole to the bitcoin environment, because it was not fully tested yet and bug can also appear at some point
if some sort of bug/exploit will emerge then you are forced to hard fork anyway, it's a gamble, it's better to directly hard fork to 2MB anyway
if some sort of bug/exploit will emerge then you are forced to hard fork anyway, it's a gamble, it's better to directly hard fork to 2MB anyway
That would be the elegant solution....have seg witness choke in some manner..fix such with a hard fork and thus have some sense and do the block size hard fork
at the same time an or asap. Thus BOTH camps of this dispute could claim victory. The seg witness bitcoin core fork that seg witness is then repaired and next
step the lightning network and the block size quick fix folk on perhaps hardforks are NOT as passe as bitcoin core seemed to imply.
December 30, 2016, 02:52:20 AM
eh those idiots rightly believe that segwits may introduce some unknown security hole to the bitcoin environment, because it was not fully tested yet and bug can also appear at some point
if some sort of bug/exploit will emerge then you are forced to hard fork anyway, it's a gamble, it's better to directly hard fork to 2MB anyway
if some sort of bug/exploit will emerge then you are forced to hard fork anyway, it's a gamble, it's better to directly hard fork to 2MB anyway
December 30, 2016, 02:45:57 AM
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
Well according to this article about "teechan" http://www.newsbtc.com/2016/12/25/teechan-can-potential-solution-bitcoin-scalability/, they are offering an easier scalability solution for the Bitcoin blockchain.
Now with this this will be very hard to choose on what to go on. Only one problem is with teechan, only Intel’s Skylake range of processors is equipped with Software Guard Extension, which makes it impractical until such solution becomes an industry standard, and this may be problem for implementing it in future.
hardware centralization imho ..same problem ..wearing a different coat.....
December 30, 2016, 01:37:28 AM
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
Well according to this article about "teechan" http://www.newsbtc.com/2016/12/25/teechan-can-potential-solution-bitcoin-scalability/, they are offering an easier scalability solution for the Bitcoin blockchain.
Now with this this will be very hard to choose on what to go on. Only one problem is with teechan, only Intel’s Skylake range of processors is equipped with Software Guard Extension, which makes it impractical until such solution becomes an industry standard, and this may be problem for implementing it in future.
December 30, 2016, 01:26:46 AM
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
Don't disagree. But the other thing that comes to mind...is the bigger the bitcoin network and the money involved the LESS likely to get everyone on board to do a hard fork.
Just saying the 'herding of cats' to a hard fork 'could' be quite the task. The sitting back and groaning about bitcoin devs and their seg witness code install without a complete
hard fork..may just happen by the apathy of default.
Again have no real position in either camp..but having a hard time seeing a "hey everyone we are having a hard fork for block size increase....re-do everything or lose you BTC"
would go over very well at this point in time.
anyway how I see the process at this time
December 30, 2016, 12:04:18 AM
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
Jump to: