Topic: Bitcoin Core to Release SegWit in November (Read 2281 times)

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.

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.

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.


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.

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.

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.

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.

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.

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.

Again, Adam Back has never written anything for Core.

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.

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.

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

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.

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.

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.

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.

wait for it..

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.

---

2015 roadmap - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
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)

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  

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

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.

If we assume that the changes were implemented and the only time that those changes were seen are after the release has been made, I would say that 1 month is probably sufficient to fully implement and test a large code change such as segwit assuming that the released version of the reference implementation has no major bugs, is well documented, and the devs actively answer questions and comments (which means that they extensively tested the change prior to the release).

With the code available beforehand but still somewhat WIP (as with the case of segwit where the vast majority of the code was already finalized and merged with just some local stuff that was being changed), then I would say that 2 weeks are sufficient. This is because the devs can work on their implementations at the same time as or immediately after the main code change was implemented and merged. Any following changes can also be implemented relatively quickly. It is much easier to implement something when there is an existing codebase that you can reference.

A 6 month grace period is too long. I would say 4 weeks at most, 2 weeks is fine, for both hard and soft forks (keep in mind that previous soft forks except CSV have had no grace period whatsoever).

And I know you are going to say that those other devs did not test the change itself. But in actuality, they do. When they implement the change using the existing reference implementation as a reference, they are essentially doing code review on that. If they find any bugs during that review, they are reported and fixed. Those devs will also be running their own tests on their implementation of the software. If they find any issues there and it is related to the change itself and not the implementation, then those are reported too. Having the devs work on different implementation simultaneously allows for more robust code as each dev will have their own set of tests that will catch issues in the entire change itself and not just their implementation.

I don't see how that changes anything.

Yes. However it is their choice whether to make an implementation or not.

No. Devs should still take their time to carefully implement the changes even after the official release has already been made. This is the case for Armory because we started work on segwit a few months following the merge of the code change instead of working on it simultaneously. It is unlikely that we will have the segwit stuff released by November 15th.

No. When they are doing the code review during their own implementations, any critical issues with the implementation of the rc can and should be reported. These can be blockers and delay the official release, but it is all needed and welcomed in order to produce code that is as secure as possible.

Given that segwit is a soft fork, anyone asking for time should be disregarded unless they find a critical bug. If it is just a request for a delay because they want to have a release out for segwit at the same time, then that can be disregarded. Their software's current state will continue to function following activation. They can still take their time to implement segwit properly. Note that this is only because segwit is a soft fork.

For hard forks, anyone asking for time should not be disregarded so that everyone on the network can upgrade at around the same time to avoid chain splitting.

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

Oh wait, I can predict you cherry-picking my answers so it seems like they flip flop to you so you can further attack me.

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

here is the subtle point.

if there is a RC available next week with unchanged code viewable (consensus AND LOCAL) available for a weeks prior.
should there be a 12 month coding delay just so that the opposition can code something equivalent.
then after 12 months. get to 95%. and then after 95% have 6 months grace
even when the code has been viewable weeks before RC release 18 months earlier then when you finally want it activated.

give yourself an answer and hold that answer and dont change it.

now then lets add an extra dimension to the question
if there is a RC available months ago with unchanged code (consensus AND LOCAL) available even before that.
blah blah same timescale 12month 95% 6 months grace
blah blah code available before RC

if the answer is no. then you will see the issue in a minute

however lets continue
if devs have not coded a diverse implementation by the time a RC is released. it is the devs own fault .. right??
devs should instead not give own timescales to then make their own equivalent as its deemed delaying..  but just run the RC ... right??
they should not test the RC because its their fault and treated as delaying if making a request for time. and trust the RC works... right??

think long and hard about the subtle point.

now if you still think there is no reason for 12 months coding and 6 months grace after a RC, anyone asking for time should be disregarded..right?

now explain the last year of civil war.
where core agreed to flex caps. a RC was released. but then core backtracked.
oh wait i can predict you flip flopping your answers while reading this to protect your interests

do you atleast see the subtle point of hypocrisy?

I highly suggest that you not listen to people other than the developers of their software. No developer I have talked to has ever said "rush it rush it" for segwit. No developer I have talked to has said that they are going to cut corners to get segwit out the door as fast as possible.

All the people who are saying "rush it" or "we need super long grace periods for hard forks" are misconstruing what the developers are saying. The concern about the hard forks was because for it to be done properly, everyone needs to upgrade. However, people have misconstrued that and continuously repeated that over and over again as "we need super long, months long, grace periods". No developer has said that "we need segwit out asap so rush it", only uninformed users.

Users who use Core do not represent Core, only the developers. Likewise users who use Classic or BU do not represent them, only their respective developers. To say that the users who use those software represent what those groups of developers are saying or want to do, is disingenuous.

same has been said about BU which is actually already running on mainnet for months as a release.. yet the 12 months coding rhetoric, and 6 months grace, 6 months grace, 6 months grace repeated 'safety' concern
do you see the hypocrisy
delay or else..
but rush core activation.. screw pools own local needs..instead 95% by christmas, beat your chest, get it done now now now

why so desiring a pre-new year activation.. hmm? why not just let pools flag it when THEY ARE CONFIDENT. why not atleast be calm and say hopefully by spring 2017

again emphasis: why wishing for rushing to 95% yet argue other proposals should take a natural long time to get 95%.

Franky, stop with the lies.

The last code change was 6 days ago. The thing that changed 3 days ago were just docs (the release notes) and some comments in the code.

The vast majority of the segwit changes have been fixed in stone since the PR for it was merged several months ago. The final change was just the deployment which required changing two lines. People have been running those changes since they went in, either with a build of the master branch or with one of the RC's for 0.13.1 that were tagged and released last week.

The release is going to be available for a few weeks before that earliest start time. The Nov. 15th date is not the date for the software release but rather the date the miners can start signallying. It is very different from the software release date which will be next week.

Segwit isn't being "tweaked daily". The things that are being tweaked are not consensus related and do not matter to other developers implementing segwit. All of the consensus changes were made a long time ago. No one is saying "rush it rush it".

All that safety rhetoric is still there, but the key point is that all those wallets and miners have been working on their implementations of segwit long before the release. They don't have to start working on it after the release, they work on it beforehand. Again, no consensus changes to segwit have been made since it was merged except for the deployment start time which is a very easy change. Only local node policy (which can be easily taken care of because that local node policy was already a standard thing for wallets to already be doing) and local changes within Bitcoin Core itself.

my only criticism is this hypocritical 9 days to attain 95% and then the month to keep 95% to activate before the christmas new year period.
yet cores code is not set in stone yet. even 3 days ago it has changed.

other proposals have had a RC running on mainnet right now and for months, code is fixed in stone for their concept..
yet core proposal doesnt even have an RC that is actually running on mainnet. or fixed in stone for others to confidently make their diverse implementations of.
pools need to change alot. and while the code is still tinkering with even days ago. its silly to try suggesting activation before the new year.

but strangely 9 days after RC is available(code set in stone) is hypocritically acceptable time for others to make their own diverse implementations based on cores RC next month.
afterall there is no point using cores 2 month old code, thats outdated already.
also to keep tweeking it daily to match the tinkerings. and then told 'all is fine rush it, rush it rush it,'

but simultaneously core have been saying it will take them a year to code something similar whats already an RC of other proposals
followed by 6 months for others to make their own diverse versions after cores version becomes an RC..(before activation can even occur)

its has all been a bait and switch double-standard hypocrisy.
afterall
where is all the safety rhetoric about grace period time for others to make diverse implementations that meet the rules
even smart people should not be shouting "now now now" simply to uphold their old "safety concerns"

Huh?

The very most conservative change to bitcoin would be to keep historical distance from used block size to max limit - in percentage!

No more

 

This is the big joke IMO amongst the whole debate: that's pretty similar to what my actual position is, too. But I'm probably cast, by those doing the casting, as an arch small-blocker.
"Staying conservative for as long as possible" is how I'd sum it up, but that doesn't close the door on increasing the transaction blocksize as well as the signature blocksize. Be kind of hard for me to support Segwit without supporting blocksize increases, the signature block is 6x the size it would have been if no increase had been introduced with Segwit.


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.