Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 25. (Read 84847 times)

There is no precedent on that front in terms of what happens should a soft/hard fork not activate so no one knows yet if/how the core devs would respond. On the other hand segwit has one year to activate and it's way too early to pass any kind of judgement on that front.

Changing to the original block limits would be 32MB, and since current transactions have a quadratic scaling problem, it would be possible to create 32MB of transaction(s) on one block that would take half hour to process with current bitcoind on the current network protocol, bringing the network to a standstill. By the way, segwit transactions don't have this scaling problem, they scale linearly.

So if their hard work is not activated, are they willing to remove the code ?

I think the fact that they could release a successive number of updates that all support Segwit kinda sways things in favor of it being adopted, unless the biggest miners adamantly stick to v 0.12.

Myself i'm not totally convinced this is the best solution, but it is progress... I would have said segwit + revert to original block size limit, that would have caused less argument while allowing a lot of room for scaling.

Dude you are not paying attention to the big picture. Segwit is not only about scaling, but about all the cool new features that will come with it. We are looking at increased privacy with segwit like Shnorr signatures, Confidential Transactions, fast velocity decentralized exchanges due improved LN... holy cow, how can anybody be against segwit in 2017 is beyond me.  I literally cannot imagine any other scenario but:

1) People that don't understand it
2) People paid to shit on Core/Blockstream and attempt to hijack the project with yet another XT/Classic/Unlimited/whatever they be shilling nowadays.

Do you really believe what you are suggesting would have supposedly been a better approach?

First, as far as the evidence seems to suggest (and you seem to agree) bitcoin is not broken; however, no one is suggesting that Seg wit is any kind of "desperate" fix - instead, it was publicly proposed in December 2015, and it was applauded, touted and lauded by many of the technical insider folks to be a sound, reasonable and prudent direction forward.

Sure there were other things going on in respect to scaleability questions, and some folks that were spouting out misinformation and even seeming inclined to suggest that bitcoin was broken... but over several months, a lot of those folks have lost credibility in some circles, yet in other circles they continue to spout nonsense ideas about bitcoin being broken or that there some better path forward to make a hard increase in the blocksize limit prior to seeing how seg wit plays out...

The essence of the matter remains that bitcoin is a considerably non controversial way forward and an improvement upon bitcoin, even though it does seem like it is taking a bit of time for some of the miners to begin to signal it's support. 

Seems like segwit support signaling remains under 30%  (https://blockchain.info/charts/bip-9-segwit)   (and I am considering that support level number will improve in the coming months and it just takes a bit of time for miners to incorporate segwit support into their software and practices). 

What would be the ramifications of orphaning potentially half of the blocks found? (Besides perhaps a delay in confirmation times?)

Well no one is forced to implement it; so ready to implement does suggest a small amount of support at least. FWIW, before segwit's activation was set in Bitcoin Core I reached out directly to most of the non-mining Bitcoin related companies that I could fine to specifically prompt for opposition. I received back many positive responses, none opposed, and the only negative comment was from a party that hoped activation would take longer so they would have more time to add support-- it's still possible that they don't support it,  apparently not enough to send a respond saying so. After that there was a public discussion on the bitcoin-development list and the only party that argued against it was Tom Zander.

Yep, only just over half is strictly needed if they're willing to orphan the other almost-half.

The consensus would be among the miners, and not necessarily among the entire Bitcoin economy. Just because 95% of the blocks that the miners produce doesn't mean that non-mining Bitcoin related companies and other Bitcoin users support SegWit (Note: ready to implement != support).

Technically speaking, the threshold is 50.694% (or potentially less depending on luck) for activation as the miners who support SegWit could decide to ignore blocks that lack a signal of support for SegWit.

Making facts hard to find is not a good strategy for gaining support if you ask me.

Written in places that do not constitute a total waste of time and effort, i.e. not in response to trolls

Here's your problem, your facts? Where are they...

Here's your problem. Your opinion doesn't comport well with facts.

Bitcoin has been scaling just fine in my opinion. If Bitcoin is unscalable and desperately needs this SegWit "fix", then why didn't the Devs get together and create their own alt-coin better than Bitcoin? Why change Bitcoin if it's obsolete?

Thank you everyone for an interesting thread. And thank you to the people who took the time to patiently answer the questions from users. You guys are the best. I wish you all a happy new year. Sorry no questions for now.

Not all-- we've increased it over time in response to prior instability and as we all learned better the implications.  BIP30 just used a 'past this time' decree. BIP16 was based on 55% and just used a time for the actual activation, and resulted in months of low levels of orphaned blocks being produced.  Satoshi used several hard cut softforks that were just triggered on blockheights.  BIP34 was the first to use 95% but it actually started enforcing the rules for a subset of blocks at 75%.

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% under the old approach.  But we saw no reason to lower the criteria:  basically when it activates the 95% will have to be willing to potentially orphan the blocks of the 5% that remain if they happen to mine invalid blocks.   If there is some reason when the users of Bitcoin would rather have it activate at 90%  (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

So basically setting the criteria high protects the stability of the network in the common case, but never ties anyone's hands against something not activating. By default the safest thing happens, but no one can exploit this in an attack.

Because of this, the trade-offs favor a high threshold.

I'm pretty sure 70% of these people are paid to just frustrate you and waste your time on responses, you're a brilliant coder. Ignore the nonsensical banter with people who have clear motivations of just battling your position without engaging in logical rebuttals.

And do what you shine at, code 

So that the soft fork deploys with supermajority. It will essentially have consensus when it deploys. This ensures that the new rules will be deployed and enforced by the miners. The 95% rule has been used for all previous soft forks, no reason to change that now.

Why was 95% adoption rate selected for activation as oppossed to 80% or 50% or even 5%?

Again, you are showing profound confusion.  If you do not spend _your own_ unconfirmed coins you can be restricted to make only a _single_ transaction until you receive a confirmation... meaning you might easily be waiting an hour before you can make a second payment after making a first while waiting on a block.

Without the ability to spend unconfirmed transactions you cannot engage in many useful protocols like cross chain atomic swaps or coinswaps.


A bit of a wrinkle there. Tracking if a payment has been made is what I was referring to above, but that text is referring to needing code to _unfuck_ a wallet after a chain of transactions has been disrupted with malleability. I'm not aware of any wallet that does this today, not even core. It too hard to do right, compared to just fixing the malleability. The distinction is that no amount of "modular" cosmetic ID can help that, because once the transaction chain is broken, it's broken.  Previously I was responding above the kind of cosmetic issues you were discussing when you suggested that a non-normative ID could help.


You are just spouting nonsense here. Who is the third party? What risk is offloaded?  I think at this point you are literally just making things up and not even earnestly expressing your own confused views.

Lightning does not require segwit. Simply repeating it over and over again will not make it true.

Since GMaxwells ignore system doesn't seem to be functioning, I may address that when I have more time but in the meantime....

I have no idea what "rbtc" is. Searches yield mainly bible groups, so I've really no idea what is being referenced.

The linked document by tertius993 gives 4 benefits.

1. Wallet authors tracking spent bitcoins
According to GMaxwell no one cares, apparently.

2. Anyone spending unconfirmed transactions
This was never a good idea and has always been stated that 6 confirmations is the bare minimum and use zero at your own risk. It is an obvious area for improvement but segwit just offloads the risk to a third party like any side-chain as was intended in the original design.

3. The Lightning Network
Of course.

4. Anyone using the block chain
This is just a sales pitch. At best it is a corollary of #1 without explicit definition.

#1 & #4, if we take these as read, are saying that having an immutable txID has benefits (IMO, malleable TxID was a bug).
#3 was a design decision and the usual retort to things like that from the eminent legendaries is "go make your own alt-coin".

None of them are peculiar to SegWit but #3 requires it.