Post your SegWit questions here - open discussion - big week for Bitcoin!

[achow101]

SegWit doesn't look like is going to get activated any time soon, some Chinese miners have gone the BU way and possibly more will switch, but I hope not.

What other options are there for SegWit to be activated? Can the way to activate it be changed at this stage? Or what other possible way is there?

There's UASF, but most of the developers and miners don't think that UASF is safe. As of now, there are no other plans to get segwit activated. I think that it is possible for the timeout date to be pushed back once we get close to it, but so far no proposal for that has been made yet. I highly doubt that the activation threshold will be lowered.

[coin@coin]

SegWit doesn't look like is going to get activated any time soon, some Chinese miners have gone the BU way and possibly more will switch, but I hope not.

What other options are there for SegWit to be activated? Can the way to activate it be changed at this stage? Or what other possible way is there?

There's UASF, but most of the developers and miners don't think that UASF is safe. As of now, there are no other plans to get segwit activated. I think that it is possible for the timeout date to be pushed back once we get close to it, but so far no proposal for that has been made yet. I highly doubt that the activation threshold will be lowered.

Thanks will look into UASF, that's what I thought for the rest... sigh.  

[da2ce7]

SegWit doesn't look like is going to get activated any time soon, some Chinese miners have gone the BU way and possibly more will switch, but I hope not.

What other options are there for SegWit to be activated? Can the way to activate it be changed at this stage? Or what other possible way is there?

There's UASF, but most of the developers and miners don't think that UASF is safe. As of now, there are no other plans to get segwit activated. I think that it is possible for the timeout date to be pushed back once we get close to it, but so far no proposal for that has been made yet. I highly doubt that the activation threshold will be lowered.

UASF isn't as safe as when you you have a coperative miner upgrade. However we don't have coperative miners (or at lest don't have a majorty or coperative miners).  UASF becomes very reasonable in this unfortunalte state; as it removes controll from the miners hands.

Of course it is better to do a miner-based upgrade, however this option, in this politcal enviroment, is not reasonable.

[Fatman3001]

Alts are literally taking over in terms of market cap as we speak. Thx @gmaxwell, thx luke-jr, thx adam back. Thx for destroying Bitcoin.

(this was going to be a bump on a plan b, but we all know the moral and ethereal angel-beings in Core don't do a plan b)

Can Craig Wright please creep out of his hole soon and set things straight?!?! FFS!!!

[hv_]

Alts are literally taking over in terms of market cap as we speak. Thx @gmaxwell, thx luke-jr, thx adam back. Thx for destroying Bitcoin.

(this was going to be a bump on a plan b, but we all know the moral and ethereal angel-beings in Core don't do a plan b)

Can Craig Wright please creep out of his hole soon and set things straight?!?! FFS!!!

Yeah. Lessons needs to be learned and we are in the middle of a big social economical experiment where main goal is about disruption.

Learned: try to control this by any means is gonna be disrupted. -> let it flow by its greed by design and it will be self healing

[polyhedron]

Will SegWit be mandatory deployed since Aug. 1?

I've read from a post from a Chinese forum that in BIP 148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

the "mandatory" start time of originally suggested Oct. 1 was predated to Aug. 1.

Although the proposal is written "soft fork", when no concensus is made till Aug. 1, will a hard fork suddenly occur at that time?

So my questions: What is actually written in this code, and is this BIP accepted and will be released in the new Core version?

[achow101]

Will SegWit be mandatory deployed since Aug. 1?

I've read from a post from a Chinese forum that in BIP 148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

the "mandatory" start time of originally suggested Oct. 1 was predated to Aug. 1.

Although the proposal is written "soft fork", when no concensus is made till Aug. 1, will a hard fork suddenly occur at that time?

So my questions: What is actually written in this code, and is this BIP accepted and will be released in the new Core version?

BIP 148 (aka UASF) is not accepted by pretty much all developers. It has not been accepted by Core nor is it likely to be accepted and implemented by Core. As of now, the segwit implementation in Core is as is specified in the segwit BIPs, which do not include BIP 148.

[Carlton Banks]

BIP 148 (aka UASF) is not accepted by pretty much all developers. It has not been accepted by Core nor is it likely to be accepted and implemented by Core. As of now, the segwit implementation in Core is as is specified in the segwit BIPs, which do not include BIP 148.

So it's now stalemate from 2 directions at once?

Wouldn't it make more sense for the devs against BIP148 to quit Bitcoin altogether given that attitude? Once a different cryptocoin implements a successful 2nd layer, Bitcoin will lose a significant competitive edge. There's nothing magic about contributing to the Bitcoin codebase, another team could implement Segwit and other future technologies without them.

Why continue to be a part of a project that's being prevented from progressing? The devs are going to run out of non-fork improvements and maintenance coding (for the most part). I'm seriously considering looking at why I'm still involved at all.

[stdset]

BIP 148 (aka UASF) is not accepted by pretty much all developers. It has not been accepted by Core nor is it likely to be accepted and implemented by Core. As of now, the segwit implementation in Core is as is specified in the segwit BIPs, which do not include BIP 148.

I'm waiting for an implementation. Once we have a reviewed and tested implementation, I will upgrade my node to activate UASF at whatever date has most support from the community. Miners had a lot of time to upgrade. Alts are advancing. I'd prefer to activate UASF sooner rather than later.

[Carlton Banks]

BIP 148 (aka UASF) is not accepted by pretty much all developers. It has not been accepted by Core nor is it likely to be accepted and implemented by Core. As of now, the segwit implementation in Core is as is specified in the segwit BIPs, which do not include BIP 148.

I'm waiting for an implementation. Once we have a reviewed and tested implementation, I will upgrade my node to activate UASF at whatever date has most support from the community. Miners had a lot of time to upgrade. Alts are advancing. I'd prefer to activate UASF sooner rather than later.

As will I.

The developers arguing against it are contemptible. It's supposed to be a readiness formality, not a vote. If you think that the disruption will be too much for your delicate little nerves to handle, you clearly don't understand the political significance of Bitcoin to begin with. We're being forced into taking drastic steps by the miners, and now "Core" wants to stonewall too?

I'd like to know exactly which Core contributors are taking this non-productive, obstructive stance, those that lack courage are not suited for this type of project. The users would certainly have sufficient fortitude to back this move, they're interested in the growing success of the project not to mention their own success.

achow101, which Core developers lack the fortitude to support the users making their own decision on activating Segwit, BIP148 or otherwise?

[classicsucks]

Why continue to be a part of a project that's being prevented from progressing? The devs are going to run out of non-fork improvements and maintenance coding (for the most part). I'm seriously considering looking at why I'm still involved at all.

STAHP with the drama Carlton, you're not going anywhere. You'll make the last post on this forum before it shuts down 10+ years from now, mark my words.

Besides, last time I checked, you were blacklisting non-Segwit nodes with your own little CarltonBanksCoin fork, what happened to that epic thread? LOL

[Gimpeline]

Why continue to be a part of a project that's being prevented from progressing? The devs are going to run out of non-fork improvements and maintenance coding (for the most part). I'm seriously considering looking at why I'm still involved at all.

STAHP with the drama Carlton, you're not going anywhere. You'll make the last post on this forum before it shuts down 10+ years from now, mark my words.

Besides, last time I checked, you were blacklisting non-Segwit nodes with your own little CarltonBanksCoin fork, what happened to that epic thread? LOL

It's not just Carlton.
Most of us are sick of the attacks on the blockchain from BU, classic, etc..
We want to improve bitcoin and move on, but these constant attacks makes it impossible

[classicsucks]

Most of us are sick of the attacks on the blockchain from BU, classic, etc..
We want to improve bitcoin and move on, but these constant attacks makes it impossible

You're saying that "attacks" are blocking Segwit adoption? Ridiculous.

Classic did nothing, and nobody even broke a sweat. Did you ever wonder why Unlimited keeps gaining support? It's another vain attempt to communicate to the core devs to increase the effing blocksize. Nobody seems to be listening.

Personally I'm sick of the cult-like core devotees who claim to be intelligent and technically knowledgeable.

[-ck]

It's another vain attempt to communicate to the core devs to increase the effing blocksize. Nobody seems to be listening.

Personally I'm sick of the cult-like core devotees who claim to be intelligent and technically knowledgeable.

Personally I'm sick of people not being willing to understand or accept that an allegedly 'simple' blocksize increase exposes the network to a DoS risk. Yes it was thought a plain blocksize increase would be fine in the past; now we know better. Does that mean we should plough on regardless, knowing it's flawed?

[JayJuanGee]

It's another vain attempt to communicate to the core devs to increase the effing blocksize. Nobody seems to be listening.

Personally I'm sick of the cult-like core devotees who claim to be intelligent and technically knowledgeable.

Personally I'm sick of people not being willing to understand or accept that an allegedly 'simple' blocksize increase exposes the network to a DoS risk. Yes it was thought a plain blocksize increase would be fine in the past; now we know better. Does that mean we should plough on regardless, knowing it's flawed?

I would surmise that even a large majority of the big blockers realize that they are just spouting off bullshit - and I think that there has been a considerable amount of evidence that a lot of them are merely paid banking shills.

So, yeah, it all sounds fine and dandy to argue for an increase in the blocksize limit, but the smarter big blockers likely don't even believe their own bullshit.  

We also know that a large number of these big blockers have been propagating this big blocker nonsense for nearly two years and even a little bit before the current bullrun from the lower $200s to $1350 (correction down to $891) and now floating in the $1,145 territory.

Surely through the past couple of years big blocker nonsense has been able to contribute to causing some loss of confidence in bitcoin from some folks which likely exacerbates BTC price corrections and causes less upwards BTC price pressures, yet the ongoing upwards price pressures does tend to demonstrate that a lot of the "smart" money in bitcoin realizes that these various big blocker saboteurs are not too likely to cause any kind of significant and meaningful interference to the main trend and adoption of bitcoin as the best of the cryptos and the most secure, solid and immutable of the cryptos (which immutability is a feature and not a bug in bitcoin).

Accordingly, even if we do not ultimately achieve getting seg wit (which I kind of doubt), bitcoin is still going to continue to have a considerable amount of value because of its inability to be changed easily - even if it were to stay in a kind of current 1mb forever status which is also not too likely of a scenario because it seems quite likely that various powers that be in core including the realization of the superiority of the seg wit solution within the larger bitcoin community is going to cause some kind of ways to slip aspects of seg wit into the protocol, even if it ends up being some combination of support that shows consensus coming from various other aspects of the bitcoin community outside of the miners - yet without necessarily only seeking 95% of the miners..

Maybe some of those minority miners are going to have to direct their engergies (and their mining power, if that is what they got to offer) somewhere else.  Ultimately, bitcoin should not be held hostage by mining power, and there is quite a lot of mining power in existence, so if several of the miners direct their resources somewhere else under the belief that they can be more profitable ways and at other coins, for example, then maybe that would also be a decent solution..  So, yeah, currently, there may be some miners, too, who are attempting to play a card to attempt to show that they have a better hand than they actually have (that is called bluffing, unless they actually play the card, which might be the better outcome since quite few folks already realize that they are exaggerating what cards that they actually have to play).

[classicsucks]

It's another vain attempt to communicate to the core devs to increase the effing blocksize. Nobody seems to be listening.

Personally I'm sick of the cult-like core devotees who claim to be intelligent and technically knowledgeable.

Personally I'm sick of people not being willing to understand or accept that an allegedly 'simple' blocksize increase exposes the network to a DoS risk. Yes it was thought a plain blocksize increase would be fine in the past; now we know better. Does that mean we should plough on regardless, knowing it's flawed?

Are you ignoring the fact that the 1MB blocksize limit exposes the network to a DoS risk AND alienates the user base? Fees and confirmation times rose dramatically over the past 3 months due to the limit. User flight to altcoins is massive, and cannot simply be waved away.

Who is "plowing on regardless"? Unlimited sounds scary, but likely won't win the fork war. Segwit is complicated, and not a proven technology at all.

Keep your eye on Litecoin's Segwit adoption. If we're lucky, Litecoin will activate Segwit and unmask all of those subtle bugs that nobody found during testing... let's talk in 6 months...

[andrew24p]

at this point just drop the 2mb block increase on segwit and just get malleability fixed for lightning.

[X7]

at this point just drop the 2mb block increase on segwit and just get malleability fixed for lightning.

Interesting what is happening on the LTC chain - and how they are handling the situation.

This is a good test pilot for bitcoin with 0 risk

[Fatman3001]

It's another vain attempt to communicate to the core devs to increase the effing blocksize. Nobody seems to be listening.

Personally I'm sick of the cult-like core devotees who claim to be intelligent and technically knowledgeable.

Personally I'm sick of people not being willing to understand or accept that an allegedly 'simple' blocksize increase exposes the network to a DoS risk. Yes it was thought a plain blocksize increase would be fine in the past; now we know better. Does that mean we should plough on regardless, knowing it's flawed?

And now Core's inability to properly manage and communicate their scaling solution is leading us towards a much more dangerous HF. A damaging contentious HF now will primarily be Core's failure, not anyone else's victory. Not exactly stellar risk management.

It is unfortunate that everything had to be bundled together like this. Especially when the contention in the BTC community became apparent. I understand there are technical reasons for doing so, but that's a lot of eggs in one basket.

[hv_]

It's another vain attempt to communicate to the core devs to increase the effing blocksize. Nobody seems to be listening.

Personally I'm sick of the cult-like core devotees who claim to be intelligent and technically knowledgeable.

Personally I'm sick of people not being willing to understand or accept that an allegedly 'simple' blocksize increase exposes the network to a DoS risk. Yes it was thought a plain blocksize increase would be fine in the past; now we know better. Does that mean we should plough on regardless, knowing it's flawed?

And now Core's inability to properly manage and communicate their scaling solution is leading us towards a much more dangerous HF. A damaging contentious HF now will primarily be Core's failure, not anyone else's victory. Not exactly stellar risk management.

It is unfortunate that everything had to be bundled together like this. Especially when the contention in the BTC community became apparent. I understand there are technical reasons for doing so, but that's a lot of eggs in one basket.

And we can always find risks for any solutions any changes any actions, even for no action.
So best way is to try as many as possible and find back to the initial experiment thinking of Satoshi.
Shrink the code to protocol level, clean it down to minimal essential params and diversify code bases. Best will win but only if free use is possible to find out about what works and what not.