Bitcoin Core to Release SegWit in November

[streazight]

Segregated Witness, Bitcoin Core’s innovative scaling solution, is expected to be released on November 15, in Bitcoin Core’s 0.13.1 release.

Bitcoin Core developer Pieter Wuille made the announcement in the Bitcoin-dev mailing list, in which he stated that BIP 141, or the SegWit soft fork proposal, could be activated on the 15th of November if the 95% hashpower validation threshold is reached.

If this happens (the release on the 15th November) , how much more time It should take to see the Lightning network fully functional ?

source : https://cointelegraph.com/news/ready-steady-fork-bitcoin-core-to-release-segwit-in-november

A great news and welcome development to the ever lasting bitcoin currency. As we wait for the release date lets also hope that the price of the bitcoin may appreciate significantly as this must be one of the technical milestone after recent halving  

[1715215391]

1715215391

[1715215391]

1715215391

[1715215391]

1715215391

[1715215391]

1715215391

[1715215391]

1715215391

[1715215391]

1715215391

[franky1]

but we know you are not just a "user" so i specifically chosen to get an answer from you.
here is the subtle point.

Your point is not subtle. Look up the definition of subtle.

wait for it..

The opposition? As in Classic and BU? Or do you mean other wallets like Armory and Electrum?
Either way, no, that time frame is way too long, for both hard and soft forks. Technology moves quickly, that timeframe is much too long.

it is subtle. because here is the thing..
i did not inform you i was going to tell you my questions applied to BU. to let you presume i was talking about core and defend cores RC.
to see your answer as if you were defending BU (without realising it)
i was taking your mindset and answers of core to apply them BU's RC that has been released MONTHS AGO..

secondly hard forks. would work like this
95% node
then
95% pool
thus giving time due to 2 rounds of votes
but im glad your atleast saying 12 month coding and 6 months grace is too long.

now explain the last year of civil war.
where core agreed to flex caps. a RC was released. but then core backtracked.

When did Core agree to flex caps? When was a release made with flex caps?

2015 roadmap - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Further out, there are several proposals related to flex caps or
incentive-aligned dynamic block size controls based on allowing miners
to produce larger blocks at some cost. These proposals help preserve
the alignment of incentives between miners and general node operators,
and prevent defection between the miners from undermining the fee
market behavior that will eventually fund security. I think that right
now capacity is high enough and the needed capacity is low enough that
we don't immediately need these proposals, but they will be critically
important long term. I'm planning to help out and drive towards a more
concrete direction out of these proposals in the following months.

greyed out bit is irrelevant now due to blocks being at capacity NOW (autumn 2016) so its more important NOW

but months after the roadmap, a consensus roundtable was requested to get the "more concrete direction"

so consensus roundtable in early 2016 had signatures signed and agreements agreed..
core team agreed and signed the consensus agreement including a block increase.

then they backtracked and said they dont represent core and only turned up as individuals..(facepalm moment for many)

[achow101]

it is subtle. because here is the thing..
i did not inform you i was going to tell you my questions applied to BU. to let you presume i was talking about core and defend cores RC.
to see your answer as if you were defending BU (without realising it)
i was taking your mindset and answers of core to apply them BU's RC that has been released MONTHS AGO..

secondly hard forks. would work like this
95% node
then
95% pool
thus giving time due to 2 rounds of votes
but im glad your atleast saying 12 month coding and 6 months grace is too long.

I've never said anything about BU or Classic about their timeframes. I am mostly ok if one of them gains consensus. I prefer segwit, but it wouldn't kill me if segwit wasn't activated (I'd merely be disappointed). What I speak up against BU and Classic is against the people. From what I have seen, most people who support BU and Classic are spreading FUD, trolling, and just generally being assholes.

I also don't think that any of the "solutions" (segwit included) are actually solutions but rather kicking the can down the road. Segwit does a bit more, which is why I like it. I also think that BU with the idea of "emergent consensus" is stupid and a flawed. Given the choice between Classic and BU though, I would take Classic (minus Zander).

The only thing related to timeframes that I spoke up against was Classic's 75% threshold which I think is too low.

2015 roadmap - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Further out, there are several proposals related to flex caps or
incentive-aligned dynamic block size controls based on allowing miners
to produce larger blocks at some cost. These proposals help preserve
the alignment of incentives between miners and general node operators,
and prevent defection between the miners from undermining the fee
market behavior that will eventually fund security. I think that right
now capacity is high enough and the needed capacity is low enough that
we don't immediately need these proposals, but they will be critically
important long term. I'm planning to help out and drive towards a more
concrete direction out of these proposals in the following months.

greyed out bit is irrelevant now due to blocks being at capacity NOW (autumn 2015) so its more important NOW

Autumn 2015?

I think the flex caps he is talking about there is more in line with BIP 106 which is algorithmically determined block size limits rather than BU where the users set their own limits.

but months after the roadmap, a consensus roundtable was requested to get the "more concrete direction"

so consensus roundtable in early 2016 had signatures signed and agreements agreed..
core team agreed and signed the consensus agreement including a block increase.

then they backtracked and said they dont represent core and only turned up as individuals..(facepalm moment for many)

They weren't backtracking. The agreement explicitly said that they were just contributors and they would recommend a proposal to Bitcoin Core, which implies they aren't representing Core. They wouldn't be presenting something to Core if they were supposed to be Core. Also, AFAIK none of the Core devs there can actually commit to Core.

[franky1]

They weren't backtracking. The agreement explicitly said that they were just contributors and they would recommend a proposal to Bitcoin Core, which implies they aren't representing Core. They wouldn't be presenting something to Core if they were supposed to be Core. Also, AFAIK none of the Core devs there can actually commit to Core.

the reason why adam back and luke were invited was because they are not just some random secretary or floor cleaner .. they are part of core.
they CODE!
why invite a floor cleaner/secretary of a group who can only "suggest" something.
when the purpose was to get the actual CODING devs that will actually agree to CODE something!!

has adam back coded anything inline with what he signed??? nope. then he back tracked 100%.
luke backtracked by denouncing his own coding skills too, pretending to be the equivalent to a floor cleaner. only able to make a suggestion

then as the debate escalated and he then said he may code something..
but its been months since that flip flop and nothing is coming to a fruition.

but hey.. lets follow the usual brush that under the carpet and pretend it never happened.
anyway its been three pages of posts
where you admit that 6 months grace and 12 months coding after RC should not be required. even when th security and stability arguments of why core were delaying crap was due to those numbers.

so now segwit coding is fully complete, done and dusted and ready to rock and just needs activation as you say.

devs can concentrate on real blocksize increases via "algorithmically determined block size". lets hope i never see you shout for grace periods and delays now that you have been suggesting that activation in only a couple months is ok.

[BiTZeD]

Interesting news. I'm wondering : might it be the reason for the recent price increase that is still happening now ?

[achow101]

the reason why adam back and luke were invited was because they are not just some random secretary or floor cleaner .. they are part of core.
they CODE!

Adam Back is NOT part of Core. He has never contributed anything to Bitcoin Core. I don't understand why everyone lumps him in with the Core devs, he is not one of them.

why invite a floor cleaner/secretary of a group who can only "suggest" something.
when the purpose was to get the actual CODING devs that will actually agree to CODE something!!

They can code the actual HF and recommend that it be merged into Core. But they cannot force that to happen. When they do recommend something, it likely will be merged, but there are no such guarantees that that will happen.

has adam back coded anything inline with what he signed??? nope. then he back tracked 100%.

Again, Adam Back has never written anything for Core.

luke backtracked by denouncing his own coding skills too, pretending to be the equivalent to a floor cleaner. only able to make a suggestion

He can write the code and make the suggestion that it be merged. His suggestion will have a lot of weight, so it will likely be merged, but it is not guaranteed. His code will still be subject to the stringent and extensive code review and testing that segwit has gone through. The final decision to merge it comes down to one of the maintainers.

devs can concentrate on real blocksize increases via "algorithmically determined block size". lets hope i never see you shout for grace periods and delays now that you have been suggesting that activation in only a couple months is ok.

I never have shouted for grace periods and delays. Stop putting words in my mouth. Stop with the bullshit.

But do you know who is shouting for longer grace periods and delays? Tom Zander. He keeps shouting for a long grace period and delay for segwit even though he doesn't want one for Classic's HF.

[Wind_FURY]

Yep. Even if the opportunity wasn't taken to make the signature blocks bigger, this still would've been the most important update purely because it makes Lightning possible, and Lightning's going to do more for the transaction rate than any blocksize increase can.

It could but we should also not forget that it will have its own flaws and shortcomings when we actually start seeing it used in practice. Both core and the big blockers have their implementation set in their minds and can already see how beautifully it would work in theory.

I mentioned before that the Lightning Network might mean heftier transactions on the blockchain that might cause bottlenecks, limiting the opening and closing of payment channels. There is also the question of fungibility as LN.BTC's price could be more or less than "real" BTC.

One great potential for LN is the possibility of it being a bridge to other blockchains. I am very excited for that use case.

[DooMAD]

One great potential for LN is the possibility of it being a bridge to other blockchains. I am very excited for that use case.

There are (or possibly were) people working on cross-blockchain transactions already, so I don't know for certain if Lightning was necessarily a prerequisite for that.  I know two altcoins managed to achieve it successfully, so ACCT, as they call it, works.  The developers who made that possible were convinced that OP_CHECKLOCKTIMEVERIFY was the only missing ingredient and that it should now be possible to do in Bitcoin now that feature is supported.  I can only assume they hit a snag somewhere, though.  Things seem to have gone quiet on that front.

But yes, that absolutely needs to happen.  It means less reliance on exchanges that keep losing everyone's coins and less negative headlines about it as a result.  Decentralised trading to operate between various decentralised networks.

[countryfree]

Well, it's about time. All blocks are full! I understand it's difficult to reach consensus, but a solution needs to be found if we want BTC to keep on growing. We shall also know that SegWit is only a part of the solution. The problem will come back in some 18/24 months.

[unamis76]

Finally we'll see the conclusion of all those discussions about capacity increases a few months earlier. I think best case scenario here is SegWit will keep us on track for the next year or two. Although I'm not entirely convinced of SegWit's capacity in increasing capacity long term, it's probably the best for now... And Core devs wouldn't be phasing this out if it wasn't a good solution.

I would have actually wanted to see it sooner, so that the bugs.. if there were any, could be sorted out before the Xmas season started.
We do not want to be in a testing phase, when the holidays hits us and we start buying presents for Xmas. Oh, better late than never, or
so they say. 

Well, I think we can say that testing phase has already gone. I know testnets can't really predict everything on the mainnet, but it's the best we have. I think we can say this is the most ready to go live as possible.

[Wind_FURY]

One great potential for LN is the possibility of it being a bridge to other blockchains. I am very excited for that use case.

There are (or possibly were) people working on cross-blockchain transactions already, so I don't know for certain if Lightning was necessarily a prerequisite for that.  I know two altcoins managed to achieve it successfully, so ACCT, as they call it, works.  The developers who made that possible were convinced that OP_CHECKLOCKTIMEVERIFY was the only missing ingredient and that it should now be possible to do in Bitcoin now that feature is supported.  I can only assume they hit a snag somewhere, though.  Things seem to have gone quiet on that front.

But yes, that absolutely needs to happen.  It means less reliance on exchanges that keep losing everyone's coins and less negative headlines about it as a result.  Decentralised trading to operate between various decentralised networks.

Yes I am aware of the atomic cross chain transfers already developed in a couple of altcoins. But I forgot the names of those altcoins. Now that is where the difference of a Lightning Network based blockchain bridge and an altcoin ACCT based solution would come in. That big difference would be in the popularity and the marketing of the blockchain bridge implementation. Because it is developed on top of Bitcoin and for Bitcoin, that will make the whole difference. The developments of new technology done in altcoins could be looked at and seen as testnets for Bitcoin at best.

[katiecbell]

This thread escalated quickly into a word war between core and the big blockers. While I do support both movements and could see the advatages of both, I do like to see Segwit and then the Lightning Network be implemented first. I just think avoiding a hard fork for as long as possible as a safety measure must be the path to follow.

I am excited for 0.13.1, let's all hope everything all goes as planned and as smoothly as possible. From a speculator's standpoint, the potential for the Lightning Network is more promising and exciting for me.

Yeah safety measurement always matters a lot in everything we do in life, if safety is not guaranteed then there is bound to be problem somehow somewhere. We just hope that release is gonna favor us and not give us the opposite of what we expected. Eagerly awaiting to experience new bitcoin core.