can we admit segwit SF is never going to get 95% approval?

[jonald_fyookball]

Segwit as a hard fork is nearly the same as segwit as a soft fork. As a hard fork, it means that the witness commitment would be part of the block header. However, this is not desireable because the same data can be put into the coinbase transaction with no additional overhead and would make it a soft fork.

The difference is that as a hard fork, there's almost no reason why it couldn't also include a bump to the base (2mb).   

[1715564228]

1715564228

[1715564228]

1715564228

[1715564228]

1715564228

[1715564228]

1715564228

[1715564228]

1715564228

[Sadlife]

I think an hardfork or softwork will never occur even after many years past
it will only get implemented when we stand in a brink of destruction caue by bitcoin scaling
an hardfork will only happen if all the options has been used, we dont wanna risk hardforking an controversial HF or SF. Im sure many solutions will bw presented in up coming so why hurry hardforking.

[Lauda]

Segwit as a hard fork is nearly the same as segwit as a soft fork. As a hard fork, it means that the witness commitment would be part of the block header. However, this is not desireable because the same data can be put into the coinbase transaction with no additional overhead and would make it a soft fork.

The difference is that as a hard fork, there's almost no reason why it couldn't also include a bump to the base (2mb).   

Lots of reasons when there is a potential for 8 MB blocks to be created full of spam.

I think an hardfork or softwork will never occur even after many years past

It will happen.

it will only get implemented when we stand in a brink of destruction caue by bitcoin scaling

"Brink of destruction"? You truly are a shit poster.

an hardfork will only happen if all the options has been used, we dont wanna risk hardforking an controversial HF or SF. Im sure many solutions will bw presented in up coming so why hurry hardforking.

Classic shit post.

Don't worry we shall activate SegWit on Bitcoin. It's already activated on LTC and we see how it's going, then get it on Bitcoin.

There are three ways of activating Segwit:
1) MASF.
2) UASF with BIP 148.
3) UASF with BIP 149.

One of them is going to happen.

[AgentofCoin]

...

blockstreams tier network vs node consensus per network using consensus to grow without blockstream spoonfed limits...
you think the tier network is less centralised??

Yes, a tier network (second layer), as you call it, preserves the base network from
failure and centralization. Whether the tier network (second layer) becomes
centralizing or not isn't relevant for many reasons. One, it could be designed to be
decentralized. Two, different layers/tiers can compete against the others while all
still finalizing on the base network. Three, if it becomes a "bank tier/layer" that
becomes restrictive or censorship prone/etc, we can destroy it and create a new
second layer. We could "fork away" from this restrictive second layer, and Bitcoin
and it's base network will remain unharmed.

On the other hand, if we change the base network, there is no going back. If it
becomes totalitarian and mined by government controlled corporations with blacklisting
and etc, then Bitcoin is dead. The base network has failed.

here is a lesson
1. unless nodes (important) are there and united and same level playing field to save off large orphan risks... pools wont do anything.

this means nodes have to unite around a consensus first. then pools will follow.
that is where blockstream went wrong.. trying to bypass nodes by going soft.
smart pools wont do anything unless nodes are there..

pools have said many times they wont do anything if theres more then a few % risk of orphans as that will hurt their income.
they can wave a flag or a hat to say they support something but they wont actually create it at any activation date if ther is orphan risk.

so its nodes that matter most.

Core only bypassed verifying nodes by using a SF because:
(1) it was possible with this type of proposal/hack,
(2) it is pretty impossible currently to get high consensus for hardforks,
(3) hardfork's byproduct is centralization and other issues.

I don't understand the significance of your pools % risk orphan comment.
Majority of node's using the Core client are not signalling for a blockincrease
hardfork, but for SegWit. If that is the case, then the pools could SF now and
those Core nodes would be supporting them, both non-segwit blocks and
segwit blocks.

solution.. ASK THE COMMUNITY FOR A SHOPING LIST OF FEATURES EVERYONE WANTS. and all unite in building a version of the protocol in all the different brands/langages that fulful that list.

call it planB
EG core v0.15B
EG BU vX.xB
EG classic vx.xB
and so on.

yep that means stop using these several roundtable meeting to be used as bribes and ass-kiss events.. but to actually use their EARS to listen and actually settle on features that will actually unite the community and solve the issues

things like
limiting tx sigops to 4k or below IN CONSENSUS.H
allowing a hardish rule for blocksize of 8mb (long term debate ender (even core devs and others know 8mb is network safe))
and allow NODES to set a secondary preferential limit amount below that, starting at say 2mb. that is dynamic. (yep EC)

thus keeping POOLS inline with majority below preference and way below consensus.
(imagine it like nodes having a lil more sway over when/if pools should have moved beyond 0.5mb in 2013, even while the 1mb consensus existed)

thus letting nodes have a little more say in when pools increment up without actually causing real orphan stress/drama
other features like xthin and compact blocks finding a united way to communicate across the network between the different brands and get the data they need.
where by the core devs WORK WITH other implementations (OMG did i just say core devs should try being independent and help the network.. yes i did)

I agree with your comment about roundtables and ass-kiss events.
But the problem with settling community issues with agreed upon features is
that some are fine and others are contentious. The 8MB hardfork (baseblock pre/no
SegWit or after SegWit?) you propose will never be accepted anytime soon. Maybe
some would agree to 3MB, but in the larger picture it isn't worth doing a hardfork
for just 3MB. That is why the issue has stalled. If we go all the way, it needs to be
near perfect, if not, we stay where we are now.

Until more systems are created that supports the base network, there will never
be high consensus for a hardfork. Those days are long gone now, not because of
blockstream or Core, but because people now understand that is the weakest point
of our network. It is both an upgrade mechanism and an attack vector.

A hardfork is a "God Key", it has the capability to do good and/or bad. The problem is
that we will never know if a hardfork decision was good or bad until far into the
future with hindsight. That is why SFs are currently preferred if possible. For example,
ETH & ETC split, no one really knows whether that was a correct choice or not. Anyone
claiming that it was a success or failure doesn't really know and is an opinion. Personally
I don't think it was the correct choice for the coin, but good for the devs legal liability.

Personally, I don't think EC can work. Nodes could be manipulated to create false
positives for block raising which could be financed by the largest miners, intended
not for more fees or txs, but to eliminate the least powerful miners. EC is just another
possible attack vector that leads to centralization, which is what we must strive to
mitigate. If the proposal could be reasonably exploitable, it isn't good IMO.

The problem is that you can not create an EC system where the minority voting nodes
can be ignored and over ruled. If there are 50,000 nodes and 49,500 nodes want 3MBs,
but 500 nodes still want to remain at 2MBs, they should stay at 2MBs until new systems
are developed that supports those 500 nodes, IMO. In the above example, imagine that
majority of that 49,500 was fake and those 500 where the only real nodes. There is no
way to mitigate that until Proof of Node is solved. My only concern is security, not
scalability. If we can have both that is great, but I do not think we can have both
at this moment in time.

The real discussion in the community is "who is willing to roll the dice and who is not?".

But, at the end of the day, I am not advanced in the technicals of Bitcoin. I am only
addressing my concerns and opinion as a low level Bitcoiner. I want scaling and
understand its overall importance, but I do not wish to roll the dice if it means losing
certain properties of Bitcoin that I think are novel and most interesting.

[jonald_fyookball]

A hardfork is a "God Key", it has the capability to do good and/or bad. The problem is
that we will never know if a hardfork decision was good or bad until far into the
future with hindsight. That is why SFs are currently preferred if possible.

This doesn't make any sense.  How is a SF any different than a HF with regard to the change being good or bad.
In either case, you are stuck with the change forever, unless you make special rules to parse certain ranges
of the blockchain differently.

In the case you want to undo it, Segwit SF is actually much worse than a HF block increase, because
if you ever wanted to roll back the HF block increase, you can have a few lines of code set the max size based
on a condition of the block height.  However, with Segwit SF, you would have to have all nodes include the segwit
code just to undo it, in order to correctly verify the witness data for the set of blocks it was active in.

[AgentofCoin]

A hardfork is a "God Key", it has the capability to do good and/or bad. The problem is
that we will never know if a hardfork decision was good or bad until far into the
future with hindsight. That is why SFs are currently preferred if possible.

This doesn't make any sense.  How is a SF any different than a HF with regard to the change being good or bad.
In either case, you are stuck with the change forever, unless you make special rules to parse certain ranges
of the blockchain differently.

In the case you want to undo it, Segwit SF is actually much worse than a HF block increase, because
if you ever wanted to roll back the HF block increase, you can have a few lines of code set the max size based
on a condition of the block height.  However, with Segwit SF, you would have to have all nodes include the segwit
code just to undo it, in order to correctly verify the witness data for the set of blocks it was active in.

With a softfork, all non-mining nodes are preserved because the changes are
either backwards compatible or not in violation of the current protocol. On the
other hand, with a 2MB hardfork, all non-mining nodes that have not upgraded
will reject the whole 2mb blockchain as a violation.

Simply, a SF could be neutral, where as a HF will be good or bad. The full impact
of a HF is not know, where as with a SF, the impact is passive since it is not a
fundamental change, but could be ignored if requested. For example, RBF, CLTV,
and those SF could be ignored. But with a HF, those changes can not be ignored.

Whether a SF or HF is revertible is irrelevant and has no bearing on whether the
choice was good or bad. The issue is the future. Are you saying that Bitcoin would
revert a 2MB increase 2 years from now if the community decided that 2MBs
destroyed the decentralized network? No, at that point the deed is done and
we already entered a state of  failure.

SFs are better since any impact is passive in that the "features" are not dominate.
They are voluntary use. A HF is not voluntary, they are mandatory and that will later
be determined to be good mandatory or bad mandatory. In theory, no one could
use any SegWit SF scripts after activation throughout Bitcoin's life and it wouldn't
change anything significantly within Bitcoin.

On the other hand, a 2MB increase is not truly reversible. It is like childbirth, in
theory you can push the child back up there, but in reality the child is here. You
now must deal with the child and all of it's future consequences whether good or bad.

[aguila]

This topic is going to be very interesting to read. I think that this situation will take some time to resolve. In the meantime altcoins are eating chunks of BTC's market share and cap.

[cryp24x]

Last 144 blocks (24 hours) , its only 20.1%.

I mean, come on guys...

Current proposal from core is not gonna happen.   If you really want Segwit, you need to back segwit HF.

If nothing of these two camp give way or come into consensus and agreed to merge their proposal, then the solution for Bitcoin scaling that they proposes will never happen.  They will be forever in stale since both camp are holding aces that can prevent each other from implementing the "fix"  to scalability issue.

[aguila]

Last 144 blocks (24 hours) , its only 20.1%.

I mean, come on guys...

Current proposal from core is not gonna happen.   If you really want Segwit, you need to back segwit HF.

If nothing of these two camp give way or come into consensus and agreed to merge their proposal, then the solution for Bitcoin scaling that they proposes will never happen.  They will be forever in stale since both camp are holding aces that can prevent each other from implementing the "fix"  to scalability issue.

No winners, only losers. Do you think that the price is being jeopardized?

[Viscount]

If nothing of these two camp give way or come into consensus and agreed to merge their proposal, then the solution for Bitcoin scaling that they proposes will never happen.  They will be forever in stale since both camp are holding aces that can prevent each other from implementing the "fix"  to scalability issue.

There's no two camp. There's Bitcoin community and small malicious group of chinese miners under control of Jihad wu and altcoin guy Roger-Doger, trying to take over bitcoin.

[jonald_fyookball]

SFs are better since any impact is passive in that the "features" are not dominate.
They are voluntary use. 

That's not really true, as I see things.  If most miners start including segwit transactions in blocks, then this definitely will dominate the network. What usefulness would there be for nodes that don't upgrade, since they can't validate the blockchain? 

[shillfudder]

Last 144 blocks (24 hours) , its only 20.1%.

I mean, come on guys...

Current proposal from core is not gonna happen.   If you really want Segwit, you need to back segwit HF.

Yes it does not look like it will be activated. But the time to wait for it is until mid November right? Just wait for it until that time and if nothing happens then we should accept it. There is nothing wrong with waiting.

Well, yeah. But I'm afraid the market won't wait. A future crash will be blamed on this indecision.

[BillyBobZorton]

Just more nonsense from the usual anti segwit idiots. This is just (again) block variance giving the advantage to Buggy Unlimited, that's all. It's still A TIE! What's so hard to understand?

Meanwhile, Litecoin is flying into the moon as segwit activates. Of course, segwit deniers will not admit that the market values segwit positively.

[foxbat]

There are three ways of activating Segwit:
1) MASF.
2) UASF with BIP 148.
3) UASF with BIP 149.

One of them is going to happen.

Does this mean that segwit will definitely happen? I am looking forward to its results. However, with the options you give, I hope you can give your opinion on its effectiveness. Which method would be better for bitcoin? Besides these advantages, is there any disadvantage?

[jonald_fyookball]

 It's still A TIE! What's so hard to understand?
 

which means it wont get 95%.

There are three ways of activating Segwit:
1) MASF.
2) UASF with BIP 148.
3) UASF with BIP 149.

One of them is going to happen.

Does this mean that segwit will definitely happen? I am looking forward to its results. However, with the options you give, I hope you can give your opinion on its effectiveness. Which method would be better for bitcoin? Besides these advantages, is there any disadvantage?

In Lauda's self-created reality, yes, it will definitely happen.

[David Rabahy]

I suggest compromise or walk away.  Prolonged contention is unlikely the best course.

[squatz1]

I don't think it's going to end up being activated at any point through any means like this, we're going to need a full-scale assault pretty much close to what BTU was attempting to do in order to take over Bitcoin. I know they did some pretty scummy practices which probably consisted of bribes and such in order to try to get people to come along with his hostile takeover.

But I don't think it's going to get the approval it needs in order to go through, we're gonna need to incentivize it for the miners, even the ones using the practices of ASIC boost as they're going to be losing capital and do control a ton of the market. It's tough to want to negotiate with people who were scumming the network like this and stalling for personal gain, but that's how business works.

[mackenzied]

I suggest compromise or walk away.  Prolonged contention is unlikely the best course.

Agreed, compromise is always the best option for both sides. Competition always has consequences for both. However, in this case, I think competition is essential, I think bitcoin should be segwit.

[David Rabahy]

I suggest compromise or walk away.  Prolonged contention is unlikely the best course.

Agreed, compromise is always the best option for both sides. Competition always has consequences for both. However, in this case, I think competition is essential, I think bitcoin should be segwit.

And there's the rub; walking away means one "side" gets the legacy/brand and the other is an altcoin.

[Lauda]

Does this mean that segwit will definitely happen? I am looking forward to its results. However, with the options you give, I hope you can give your opinion on its effectiveness. Which method would be better for bitcoin? Besides these advantages, is there any disadvantage?

Correct. It will happen, with or without the miners. The only reason for which a POW change is not being deployed right now is because of a few friendly miners/pools (Bitfury, BTCC, F2Pool). If they were not supporting Segwit, these BIPs would probably be POW change proposals. The miners do not control Bitcoin. Never have and never will.

In Lauda's self-created reality, yes, it will definitely happen.

Classic shill talk. Wake up, BU is dead, with 0 or 100% of the hashrate.

I suggest compromise or walk away.  Prolonged contention is unlikely the best course.

Segwit is the compromise. How can you not understand this?