Topic: [2017-04-26]UASF Developer Revises Controversial Bitcoin Scaling Proposal (Read 4421 times)
April 25, 2017, 12:58:04 PM
What I also notice lately is that a lot of crappy press releases has been in circulation, from misspelling to no actual basis. And most are rushed articles. Just trying to write one just for the sake of releasing one in order to beat a certain deadline by some editor or website.
April 25, 2017, 11:48:36 AM
bitcoin's scaling debate
Yet again: what scaling debate?
Segwit only lays the groundwork for scaling, but without the subsequent changes that Segwit will permit, Segwit does nothing to change scale of the Bitcoin network's operation.
The bigger blocks "solutions" solve nothing, and certainly cannot be appropriately described as anything to do with scaling the Bitcoin network. Bigger blocks add capacity, no different to Segwit standalone, but capacity increases are by definition not changes to scale.
Any genuine scaling solutions are going to be taking place in the future, after all this Segwit and big blocks nonsense is a disappearingly faint memory.
However, with the community stalled over SegWit (and litecoin moving forward on its upgrade)
Uh, anyone home at coindesk.com?
According to the thread title, this article was published on 26th April 2017 (which is tomorrow), yet the above sentence appears to have been written about 2 months ago, when Segwit signalling actually was stalling. Whereas in the actual observable present (which coindesk.com "journalists" appear to be incapable of achieving), Segwit signalling for Bitcoin has risen steadily for the past 6-8 weeks, from 25% to 33%.
Do some journalism if you want to be referred to as journalists or news, coindesk
April 25, 2017, 11:21:43 AM
UASF Developer Revises Controversial Bitcoin Scaling Proposal
A controversial proposal for upgrading the bitcoin blockchain saw a notable strategy shift this weekend.
Since its publication on the bitcoin-dev mailing list on 25th February, a proposal by pseudonymous contributor Shaolinfry for a user-activated soft fork (UASF) has been widely discussed – and framed by some as a possible way around the current deadlock over SegWit activation.
Conversation has so far centered on how the need for a supermajority consensus in network decision-making means that any mining pool with enough hashing power holds effective veto power over any proposal, a fact many believe is responsible for delays in SegWit adoption.
The logic of a UASF, by contrast, is to bypass this veto power and put signaling into the hands of the digital currency's user base as a whole.
After the first general proposal for a UASF, Shaolinfry put forward a second proposal, BIP148, focused on putting the onus of supporting SegWit onto the 'economic majority', moving power out of the miners' hands.
Yet, even after it gained momentum, high-profile voices such as Bitcoin Core developer Gregory Maxwell and other bitcoin developers rejected the proposal on the basis it could undermine the stability of the bitcoin ecosystem.
"We should use the least disruptive mechanisms available and the BIP148 proposal does not meet that test," Maxwell wrote.
It's against this backdrop that Shaolinfry has announced work on a redraft of the proposal, which is aimed to address some of the concerns voiced by Maxwell and others in the community.
Shaolinfry conceded at the beginning of an announcement post that the reason for the changes is related to technical criticisms of how the plan would upgrade the network.
Shaolinfry wrote:
"BIP 148 is certainly not what a normal UASF would or should look like. While support for BIP 148 is surprisingly high, there are definitely important players who support UASF in general but do not like BIP148 approach."
The revised proposal, allocated the identifier BIP8, is an addition to BIP9, a proposal that concerns how soft forks are implemented.
Scaling context
The changes also hint at what could happen should bitcoin's scaling debate continue over the course of 2017.
Currently, if the 95% hashrate support for SegWit is not reached by the end of a certain time window (15th November), the proposal is set to be discarded by default.
However, technical changes made in a proposal under the terms of BIP8 would be automatically locked in at the end of the time period, although they could also be adopted sooner.
Shaolinfry's suggestion is that after the 15th November cut off date, a UASF SegWit proposal be made under the terms of BIP8.
This would mean that the community would have a full year from the present date to prepare for upgrading by means of a UASF, removing the possible destabilizing effect of a short-term.
The developer argued in the post:
"I believe this approach would satisfy the more measured approach expected for bitcoin and does not have the issues [Maxwell] brought up about BIP148."
So far, there has been less of a response from the community on the terms of BIP8, but the idea of an automatic lock-in could be contentious.
However, with the community stalled over SegWit (and litecoin moving forward on its upgrade), the suggestion of an unambiguous adoption procedure will doubtless seem appealing for many observers.
http://www.coindesk.com/lets-try-this-again-uasf-developer-puts-forth-new-proposal/
A controversial proposal for upgrading the bitcoin blockchain saw a notable strategy shift this weekend.
Since its publication on the bitcoin-dev mailing list on 25th February, a proposal by pseudonymous contributor Shaolinfry for a user-activated soft fork (UASF) has been widely discussed – and framed by some as a possible way around the current deadlock over SegWit activation.
Conversation has so far centered on how the need for a supermajority consensus in network decision-making means that any mining pool with enough hashing power holds effective veto power over any proposal, a fact many believe is responsible for delays in SegWit adoption.
The logic of a UASF, by contrast, is to bypass this veto power and put signaling into the hands of the digital currency's user base as a whole.
After the first general proposal for a UASF, Shaolinfry put forward a second proposal, BIP148, focused on putting the onus of supporting SegWit onto the 'economic majority', moving power out of the miners' hands.
Yet, even after it gained momentum, high-profile voices such as Bitcoin Core developer Gregory Maxwell and other bitcoin developers rejected the proposal on the basis it could undermine the stability of the bitcoin ecosystem.
"We should use the least disruptive mechanisms available and the BIP148 proposal does not meet that test," Maxwell wrote.
It's against this backdrop that Shaolinfry has announced work on a redraft of the proposal, which is aimed to address some of the concerns voiced by Maxwell and others in the community.
Shaolinfry conceded at the beginning of an announcement post that the reason for the changes is related to technical criticisms of how the plan would upgrade the network.
Shaolinfry wrote:
"BIP 148 is certainly not what a normal UASF would or should look like. While support for BIP 148 is surprisingly high, there are definitely important players who support UASF in general but do not like BIP148 approach."
The revised proposal, allocated the identifier BIP8, is an addition to BIP9, a proposal that concerns how soft forks are implemented.
Scaling context
The changes also hint at what could happen should bitcoin's scaling debate continue over the course of 2017.
Currently, if the 95% hashrate support for SegWit is not reached by the end of a certain time window (15th November), the proposal is set to be discarded by default.
However, technical changes made in a proposal under the terms of BIP8 would be automatically locked in at the end of the time period, although they could also be adopted sooner.
Shaolinfry's suggestion is that after the 15th November cut off date, a UASF SegWit proposal be made under the terms of BIP8.
This would mean that the community would have a full year from the present date to prepare for upgrading by means of a UASF, removing the possible destabilizing effect of a short-term.
The developer argued in the post:
"I believe this approach would satisfy the more measured approach expected for bitcoin and does not have the issues [Maxwell] brought up about BIP148."
So far, there has been less of a response from the community on the terms of BIP8, but the idea of an automatic lock-in could be contentious.
However, with the community stalled over SegWit (and litecoin moving forward on its upgrade), the suggestion of an unambiguous adoption procedure will doubtless seem appealing for many observers.
http://www.coindesk.com/lets-try-this-again-uasf-developer-puts-forth-new-proposal/
Jump to: