Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev wrote: > On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote: >> Essentially, if we make a potentially very harmful option easy to >> enable for users, we are putting them at risk, so yes, this is about >> protecting users of the base Bitcoin Core implementation. > > In this case, NOT enforcing BIP148 puts users at more risk. Since devs are > divided in opinion, we should at the very least have an option to let users > decide one way or the other. Well, it's putting users at more risk only if for those users who actively decided to put themselves at risk. I also feel bip148 is rushed and that makes it more risky. I don't want to reiterate points other have made but I don't fully agree with all of them. I prefer the way it is over the way it was (just activating at a given date without forcing mining signaling), but I still think it's rushed and unnecessarily risky (unless activating segwit was urgent, which I think it's not, no matter how much I want it to become active as soon as possible). On the other hand, I support uasf and bip8 to replace bip9 for future deployments, since bip9 made assumptions that weren't correct (like assuming miners would always signal changes that don't harm any user and are good for some of them). Perhaps bip149 can be modified to activate earlier if the current proposal is perceived as unnecessarily cautious. Luke, I've seen you say in other forums that "bip148 is less risky than bip149", but I think that's clearly false. As a reminder, one of my complains about bip109 was precisely that it was also rushed in how fast it could activate. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote: > Essentially, if we make a potentially very harmful option easy to > enable for users, we are putting them at risk, so yes, this is about > protecting users of the base Bitcoin Core implementation. In this case, NOT enforcing BIP148 puts users at more risk. Since devs are divided in opinion, we should at the very least have an option to let users decide one way or the other. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Tue, May 23, 2017 at 1:03 PM, Steven Pine via bitcoin-dev wrote: > Correct me if I am wrong, but currently core developers are arguing over > whether or not to allow an optional configuration switch which defaults off > but signals and enforces BIP148 when used. Who are we protecting users from, > themselves? Are you protecting core? from what? I am somewhat genuinely > befuddled by those who can't even allow a user config switch to be set. Essentially, if we make a potentially very harmful option easy to enable for users, we are putting them at risk, so yes, this is about protecting users of the base Bitcoin Core implementation. Users have, hopefully, come to appreciate this implementation for the peer review-based strict development process, and making a hasty decision due to time constraints (segwit activation expiration) may have undesirable consequences. Opinions among the regular contributors are split on the matter, which to me is an indication we should be cautious and consider all aspects before making a decision on the matter. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
> Who are we protecting users from, themselves? Are you protecting core? from what? I am somewhat genuinely befuddled by those who can't even allow a user config switch to be set. Indeed. It seems silly. If you're activating the switch, you're most likely fully aware of what you're doing. I also saw some very harsh rhetoric being used against BIP148, which seems unjustified as we have no idea yet how it all will play out. We can only guess. Hampus 2017-05-23 6:03 GMT+02:00 Steven Pine via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > I'm glad some discussion has been moved back here. > > Correct me if I am wrong, but currently core developers are arguing over > whether or not to allow an optional configuration switch which defaults off > but signals and enforces BIP148 when used. Who are we protecting users > from, themselves? Are you protecting core? from what? I am somewhat > genuinely befuddled by those who can't even allow a user config switch to > be set. > > I guess I find it all incredibly silly, but perhaps I suffer from some > basic confusion. > > > > On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I also do not support the BIP 148 UASF, and I'd like to add to the points >> that Greg has already raised in this thread. >> >> BIP 148 would introduce a new consensus rule that softforks out >> non-segwit signalling blocks in some time period. I reject this consensus >> rule as both arbitrary and needlessly disruptive. Bitcoin's primary >> purpose is to reach consensus on the state of a shared ledger, and even >> though I think the Bitcoin network ought to adopt segwit, I don't think >> that concern trumps the goal of not splitting the network. >> >> Many BIP 148 advocates seem to start with the assumption that segwit >> already has a lot of support, and suggest that BIP 148 does as well. >> However I don't think it's fair or correct to separate the activation >> proposal for segwit from the rest of the segwit proposal. The deployment >> parameters for segwit are consensus-critical; assuming that some other >> deployment has consensus because it would result in the rest of the segwit >> proposal activating is an unjustified leap. >> >> Even if there were no feasible alternate segwit deployment method >> available to us, I would hesitate to recommend that the network adopt a >> potentially consensus-splitting approach, even though I firmly believe that >> the ideas behind segwit are fundamentally good ones. But fortunately that >> is not the situation we are in; we have substantially less disruptive >> methods available to us to activate it, even if the current BIP 9 >> deployment were to fail -- such as another BIP 9 deployment in the future, >> or perhaps a BIP 149 deployment. >> >> If we do pursue a "user-activated" deployment of segwit, I'd recommend >> that we do so in a more careful way than BIP 148 or 149 currently suggest, >> which as I understand would otherwise make very few changes to the current >> implementation. However, due to the BIP 9 activation assumption, the >> Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together >> the idea that miners would both enforce the rules and mine segwit blocks. >> However, we can separate these concerns, as we started to do in the Bitcoin >> Core 0.14.1 release, where mining segwit blocks is not required in order to >> generally mine or signal for segwit in the software. And we can go further >> still: without too much work, we could make further improvements to >> accommodate miners who, for whatever reason, don't want to upgrade their >> systems, such as by improving block relay from pre-segwit peers [1], or >> optimizing transaction selection for miners who are willing to enforce the >> segwit rules but haven't upgraded their systems to mine segwit blocks [2]. >> >> If we would seek to activate a soft-fork with less clear miner signaling >> (such as BIP 149), then I think such improvements are warranted to minimize >> network disruption. In general, we should not seek to censor hashpower on >> the network unless we have a very important reason for doing so. While the >> issues here are nuanced, if I were to evaluate the BIP 148 soft-fork >> proposal on the spectrum of "censorship attack on Bitcoin" to "benign >> protocol upgrade", BIP 148 strikes me as closer to the former than the >> latter. There is simply no need here to orphan these non-signalling blocks >> that could otherwise be used to secure the network. >> >> To go further: I think BIP 148 is ill-conceived even for achieving its >> own presumed goals -- the motivation for adding a consensus rule that >> applies to the version bits on blocks is surely for the effect such bits >> have on older software, such as Bitcoin Core releases 0.13.1 and later. >> Yet in trying to bring those implementations along as segwit-enforcing >> software, BIP 148 would risk forking from such clients in t
Re: [bitcoin-dev] I do not support the BIP 148 UASF
I'm glad some discussion has been moved back here. Correct me if I am wrong, but currently core developers are arguing over whether or not to allow an optional configuration switch which defaults off but signals and enforces BIP148 when used. Who are we protecting users from, themselves? Are you protecting core? from what? I am somewhat genuinely befuddled by those who can't even allow a user config switch to be set. I guess I find it all incredibly silly, but perhaps I suffer from some basic confusion. On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I also do not support the BIP 148 UASF, and I'd like to add to the points > that Greg has already raised in this thread. > > BIP 148 would introduce a new consensus rule that softforks out non-segwit > signalling blocks in some time period. I reject this consensus rule as > both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to > reach consensus on the state of a shared ledger, and even though I think > the Bitcoin network ought to adopt segwit, I don't think that concern > trumps the goal of not splitting the network. > > Many BIP 148 advocates seem to start with the assumption that segwit > already has a lot of support, and suggest that BIP 148 does as well. > However I don't think it's fair or correct to separate the activation > proposal for segwit from the rest of the segwit proposal. The deployment > parameters for segwit are consensus-critical; assuming that some other > deployment has consensus because it would result in the rest of the segwit > proposal activating is an unjustified leap. > > Even if there were no feasible alternate segwit deployment method > available to us, I would hesitate to recommend that the network adopt a > potentially consensus-splitting approach, even though I firmly believe that > the ideas behind segwit are fundamentally good ones. But fortunately that > is not the situation we are in; we have substantially less disruptive > methods available to us to activate it, even if the current BIP 9 > deployment were to fail -- such as another BIP 9 deployment in the future, > or perhaps a BIP 149 deployment. > > If we do pursue a "user-activated" deployment of segwit, I'd recommend > that we do so in a more careful way than BIP 148 or 149 currently suggest, > which as I understand would otherwise make very few changes to the current > implementation. However, due to the BIP 9 activation assumption, the > Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together > the idea that miners would both enforce the rules and mine segwit blocks. > However, we can separate these concerns, as we started to do in the Bitcoin > Core 0.14.1 release, where mining segwit blocks is not required in order to > generally mine or signal for segwit in the software. And we can go further > still: without too much work, we could make further improvements to > accommodate miners who, for whatever reason, don't want to upgrade their > systems, such as by improving block relay from pre-segwit peers [1], or > optimizing transaction selection for miners who are willing to enforce the > segwit rules but haven't upgraded their systems to mine segwit blocks [2]. > > If we would seek to activate a soft-fork with less clear miner signaling > (such as BIP 149), then I think such improvements are warranted to minimize > network disruption. In general, we should not seek to censor hashpower on > the network unless we have a very important reason for doing so. While the > issues here are nuanced, if I were to evaluate the BIP 148 soft-fork > proposal on the spectrum of "censorship attack on Bitcoin" to "benign > protocol upgrade", BIP 148 strikes me as closer to the former than the > latter. There is simply no need here to orphan these non-signalling blocks > that could otherwise be used to secure the network. > > To go further: I think BIP 148 is ill-conceived even for achieving its own > presumed goals -- the motivation for adding a consensus rule that applies > to the version bits on blocks is surely for the effect such bits have on > older software, such as Bitcoin Core releases 0.13.1 and later. Yet in > trying to bring those implementations along as segwit-enforcing software, > BIP 148 would risk forking from such clients in the short term! If one > really cared about maintaining consensus with older, segwit-enabled > software, it would make far more sense to seek segwit activation in a way > that didn't fork from them (such as BIP 149, or a new BIP 9 deployment > after this one times out). And if one doesn't care about such consensus, > then it'd be far simpler to just set (e.g.) August 1 as the flag day > activation of segwit, and not play these contortionist games with block > version bits, which carry no useful or intrinsic meaning. Either of these > two approaches should have the advantage of reduced fork risk, compared > with BIP 148. > > Of
Re: [bitcoin-dev] I do not support the BIP 148 UASF
I also do not support the BIP 148 UASF, and I'd like to add to the points that Greg has already raised in this thread. BIP 148 would introduce a new consensus rule that softforks out non-segwit signalling blocks in some time period. I reject this consensus rule as both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to reach consensus on the state of a shared ledger, and even though I think the Bitcoin network ought to adopt segwit, I don't think that concern trumps the goal of not splitting the network. Many BIP 148 advocates seem to start with the assumption that segwit already has a lot of support, and suggest that BIP 148 does as well. However I don't think it's fair or correct to separate the activation proposal for segwit from the rest of the segwit proposal. The deployment parameters for segwit are consensus-critical; assuming that some other deployment has consensus because it would result in the rest of the segwit proposal activating is an unjustified leap. Even if there were no feasible alternate segwit deployment method available to us, I would hesitate to recommend that the network adopt a potentially consensus-splitting approach, even though I firmly believe that the ideas behind segwit are fundamentally good ones. But fortunately that is not the situation we are in; we have substantially less disruptive methods available to us to activate it, even if the current BIP 9 deployment were to fail -- such as another BIP 9 deployment in the future, or perhaps a BIP 149 deployment. If we do pursue a "user-activated" deployment of segwit, I'd recommend that we do so in a more careful way than BIP 148 or 149 currently suggest, which as I understand would otherwise make very few changes to the current implementation. However, due to the BIP 9 activation assumption, the Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together the idea that miners would both enforce the rules and mine segwit blocks. However, we can separate these concerns, as we started to do in the Bitcoin Core 0.14.1 release, where mining segwit blocks is not required in order to generally mine or signal for segwit in the software. And we can go further still: without too much work, we could make further improvements to accommodate miners who, for whatever reason, don't want to upgrade their systems, such as by improving block relay from pre-segwit peers [1], or optimizing transaction selection for miners who are willing to enforce the segwit rules but haven't upgraded their systems to mine segwit blocks [2]. If we would seek to activate a soft-fork with less clear miner signaling (such as BIP 149), then I think such improvements are warranted to minimize network disruption. In general, we should not seek to censor hashpower on the network unless we have a very important reason for doing so. While the issues here are nuanced, if I were to evaluate the BIP 148 soft-fork proposal on the spectrum of "censorship attack on Bitcoin" to "benign protocol upgrade", BIP 148 strikes me as closer to the former than the latter. There is simply no need here to orphan these non-signalling blocks that could otherwise be used to secure the network. To go further: I think BIP 148 is ill-conceived even for achieving its own presumed goals -- the motivation for adding a consensus rule that applies to the version bits on blocks is surely for the effect such bits have on older software, such as Bitcoin Core releases 0.13.1 and later. Yet in trying to bring those implementations along as segwit-enforcing software, BIP 148 would risk forking from such clients in the short term! If one really cared about maintaining consensus with older, segwit-enabled software, it would make far more sense to seek segwit activation in a way that didn't fork from them (such as BIP 149, or a new BIP 9 deployment after this one times out). And if one doesn't care about such consensus, then it'd be far simpler to just set (e.g.) August 1 as the flag day activation of segwit, and not play these contortionist games with block version bits, which carry no useful or intrinsic meaning. Either of these two approaches should have the advantage of reduced fork risk, compared with BIP 148. Of course, everyone is free to run the software of their choosing. I write this to both generally convey my opposition to a careless proposal, which I believe represents a way of thinking that is detrimental to Bitcoin's long run success, and specifically explain why I oppose inclusion of this proposal in the Bitcoin Core implementation [3]. The Bitcoin Core project hasn't been, and shouldn't be, careless in deploying consensus changes. Instead, I think the Bitcoin Core project ought to stand up for the best practices that our community has learned about how to deploy such changes (specifically for minimizing chain-split risk when deploying a soft fork!), and I think we should all avoid adoption or encouragement of practices that would depart from
Re: [bitcoin-dev] I do not support the BIP 148 UASF
If the flag day for a wtxid commitment is timed before the current segwit period end, I suspect segwit would activate within the current period. On Tue, Apr 25, 2017 at 2:46 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tuesday 25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote: > > > https://github.com/bitcoin/bitcoin/compare/master... > shaolinfry:uasegwit-f > > > lagday > > > > > > I believe this approach would satisfy the more measured approach > expected > > > for Bitcoin and does not have the issues you brought up about BIP148. > > > > I have not reviewed it carefully yet, but I agree that it addresses my > > main concern! I think this is a much better approach. Thanks. > > FWIW, I disagree in this case. I think given the circumstances, if we are > going to do a UASF for segwit at all, we need a clearly decisive outcome, > which is given by BIP 148. Using the approach in BIP 8 makes sense in many > cases, but in this case, it is liable to simply create a prolonged > uncertainty > where nobody knows the outcome when segwit's rules are challenged by a > malicious miner. > > If BIP 148 fails to achieve widespread support, we could do a BIP 8-based > UASF > with Segwit v2 (along with some other changes I suggested in the other > thread), but I think the tradeoffs right now favour BIP 148 as the best > UASF > deployment. > > Luke > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Tuesday 25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote: > > https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-f > > lagday > > > > I believe this approach would satisfy the more measured approach expected > > for Bitcoin and does not have the issues you brought up about BIP148. > > I have not reviewed it carefully yet, but I agree that it addresses my > main concern! I think this is a much better approach. Thanks. FWIW, I disagree in this case. I think given the circumstances, if we are going to do a UASF for segwit at all, we need a clearly decisive outcome, which is given by BIP 148. Using the approach in BIP 8 makes sense in many cases, but in this case, it is liable to simply create a prolonged uncertainty where nobody knows the outcome when segwit's rules are challenged by a malicious miner. If BIP 148 fails to achieve widespread support, we could do a BIP 8-based UASF with Segwit v2 (along with some other changes I suggested in the other thread), but I think the tradeoffs right now favour BIP 148 as the best UASF deployment. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Thu, Apr 20, 2017 at 6:39 PM, shaolinfry wrote: > I agree with much of your thoughts. I originally started working on a > generalized way to deploy user activated soft forks, in a way that leveraged > BIP9 to allow for optional faster MASF activation. BIP148 came about as a > way to satify many people's frustrations about the current segwit > activation. I have said several times in various places that the proposal > requires a very high amount of consensus that needs to be present to make > actual deployment feasible. BIP148 is certainly not what a normal UASF would > or should look like. > > I remain convinced the community very much wants segwit activated and that > the UASF movement in general has gained a lot of traction. While support for > BIP148 is surprisingly high, there are definitely important players who > support UASF in general but do not like BIP148 approach (which you rightly > point out is a UASF to force a MASF). [...] > With BIP8 we could perform a UASF segwit deployment. Due to some > complexities in the peering logic, I recommend a new deployment with a fresh > bit that starts right after November 15th (when BIP9 segwit timesout) with a > BIP8 timeout for April 2018. The code can deployed much earlier. For example > if code was deployed today, it would give the economy a year to upgrade. > Activation could still occur safely by MASF any time from now until April > 2018 (SEGWIT until Nov, then UASEGWIT from Nov until April 2018). > > I am still working on the finer implementation details, but you can see a > rough draft from this diff (which includes BIP8 in the first commit, and the > proposed bip-segwit-uasf in the second commit). > > https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday > > I believe this approach would satisfy the more measured approach expected > for Bitcoin and does not have the issues you brought up about BIP148. I have not reviewed it carefully yet, but I agree that it addresses my main concern! I think this is a much better approach. Thanks. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Dear Greg, Thank you for taking the time to review the BIP148 proposal. I agree with much of your thoughts. I originally started working on a generalized way to deploy user activated soft forks, in a way that leveraged BIP9 to allow for optional faster MASF activation. BIP148 came about as a way to satify many people's frustrations about the current segwit activation. I have said several times in various places that the proposal requires a very high amount of consensus that needs to be present to make actual deployment feasible. BIP148 is certainly not what a normal UASF would or should look like. I remain convinced the community very much wants segwit activated and that the UASF movement in general has gained a lot of traction. While support for BIP148 is surprisingly high, there are definitely important players who support UASF in general but do not like BIP148 approach (which you rightly point out is a UASF to force a MASF). In any case, I have been working on various iterations for generalized deployment of soft forks. My latest iteration adds a simple flag to a BIP9 deployment so the deployment will transition to LOCKED_IN at timeout if the deployment hasnt already activated or locked in by then. This is nice because it allows for a long deployment of a soft fork, giving the ecosystem plenty time to upgrade with an effective flagday at the end of the timeout. The hash power can still optionally activate earlier under MASF. BIP8 (was uaversionbits) can be seen here https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki With BIP8 we could perform a UASF segwit deployment. Due to some complexities in the peering logic, I recommend a new deployment with a fresh bit that starts right after November 15th (when BIP9 segwit timesout) with a BIP8 timeout for April 2018. The code can deployed much earlier. For example if code was deployed today, it would give the economy a year to upgrade. Activation could still occur safely by MASF any time from now until April 2018 (SEGWIT until Nov, then UASEGWIT from Nov until April 2018). I am still working on the finer implementation details, but you can see a rough draft from this diff (which includes BIP8 in the first commit, and the proposed bip-segwit-uasf in the second commit). https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday I believe this approach would satisfy the more measured approach expected for Bitcoin and does not have the issues you brought up about BIP148. I do not support the BIP148 UASF for some of the same reasons that I do support segwit: Bitcoin is valuable in part because it has high security and stability, segwit was carefully designed to support and amplify that engineering integrity that people can count on now and into the future. I do not feel the the approach proposed in BIP148 really measures up to the standard set by segwit itself, or the existing best practices in protocol development in this community. The primary flaw in BIP148 is that by forcing the activation of the existing (non-UASF segwit) nodes it almost guarantees at a minor level of disruption. Segwit was carefully engineered so that older unmodified miners could continue operating _completely_ without interruption after segwit activates. Older nodes will not include segwit spends, and so their blocks will not be invalid even if they do not have segwit support. They can upgrade to it on their own schedule. The only risk non-participating miners take after segwit activation is that if someone else mines an invalid block they would extend it, a risk many miners already frequently take with spy-mining. I do not think it is a horrible proposal: it is better engineered than many things that many altcoins do, but just not up to our normal standards. I respect the motivations of the authors of BIP 148. If your goal is the fastest possible segwit activation then it is very useful to exploit the >80% of existing nodes that already support the original version of segwit. But the fastest support should not be our goal, as a community-- there is always some reckless altcoin or centralized system that can support something faster than we can-- trying to match that would only erode our distinguishing value in being well engineered and stable. "First do no harm." We should use the least disruptive mechanisms available, and the BIP148 proposal does not meet that test. To hear some people-- non-developers on reddit and such-- a few even see the forced orphaning of 148 as a virtue, that it's punitive for misbehaving miners. I could not not disagree with that perspective any more strongly. Of course, I do not oppose the general concept of a UASF but _generally_ a soft-fork (of any kind) does not need to risk disruption of mining, just as segwit's activation does not. UASF are the original kind of soft-fork and were the only kind of fork practiced by Satoshi. P2SH was activated based on a date, and all prior ones were b
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Bitcoin must level the playing field for mining or it is fundamentally broken. And there are two obvious solutions: 1. WTXID commitment has as a flag day upgrade. It's a fix to a fairly serious security issue - made even worse by the existence of patents on the code. 2. Embed the code for performing a covert ASICBOOST into Bitcoin core's reference implementation. But, since this would violate patents held in China and the U.S., it could be a problem. Of these, I think the first should be far less controversial. One or the other must be done - if we can't fix security and licensing problems in Bitcoin, what can we fix? On Thu, Apr 20, 2017 at 10:23 AM, Alphonse Pace wrote: > A WTXID commitment would (likely) need to be a UASF. > > > On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> The "UASF movement" seems a bit premature to me - I doubt UASF will be >> necessary if a WTXID commitment is tried first. I think that should be >> first-efforts focus. >> >> On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> triggering BIP141 activation, and therefore not enabling the new consensus rules on already deployed full nodes. BIP148 is making an explicit choice to favor dragging along those users which have upgraded to BIP141 support over those miners who have failed to upgrade. >>> >>> I do not follow the argument that a critical design feature of a >>> particular "user activated soft fork" could be that it is users don't need >>> to be involved. If the goal is user activation I would think that the >>> expectation would be that the overwhelming majority of users would be >>> upgrading to do it, if that isn't the case, then it isn't really a user >>> activated softfork-- it's something else. >>> >>> On an aside, I'm somewhat disappointed that you have decided to make a public statement against the UASF proposal. Not because we disagree -- that is fine -- but because any UASF must be a grassroots effort and endorsements (or denouncements) detract from that. >>> >>> So it has to be supported by the public but I can't say why I don't >>> support it? This seems extremely suspect to me. >>> >>> >>> >>> ___ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
A WTXID commitment would (likely) need to be a UASF. On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The "UASF movement" seems a bit premature to me - I doubt UASF will be > necessary if a WTXID commitment is tried first. I think that should be > first-efforts focus. > > On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> triggering BIP141 activation, and therefore not enabling the new >>> consensus rules on already deployed full nodes. BIP148 is making an >>> explicit choice to favor dragging along those users which have upgraded to >>> BIP141 support over those miners who have failed to upgrade. >>> >> >> I do not follow the argument that a critical design feature of a >> particular "user activated soft fork" could be that it is users don't need >> to be involved. If the goal is user activation I would think that the >> expectation would be that the overwhelming majority of users would be >> upgrading to do it, if that isn't the case, then it isn't really a user >> activated softfork-- it's something else. >> >> >>> On an aside, I'm somewhat disappointed that you have decided to make a >>> public statement against the UASF proposal. Not because we disagree -- that >>> is fine -- but because any UASF must be a grassroots effort and >>> endorsements (or denouncements) detract from that. >>> >> >> So it has to be supported by the public but I can't say why I don't >> support it? This seems extremely suspect to me. >> >> >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
The "UASF movement" seems a bit premature to me - I doubt UASF will be necessary if a WTXID commitment is tried first. I think that should be first-efforts focus. On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> triggering BIP141 activation, and therefore not enabling the new >> consensus rules on already deployed full nodes. BIP148 is making an >> explicit choice to favor dragging along those users which have upgraded to >> BIP141 support over those miners who have failed to upgrade. >> > > I do not follow the argument that a critical design feature of a > particular "user activated soft fork" could be that it is users don't need > to be involved. If the goal is user activation I would think that the > expectation would be that the overwhelming majority of users would be > upgrading to do it, if that isn't the case, then it isn't really a user > activated softfork-- it's something else. > > >> On an aside, I'm somewhat disappointed that you have decided to make a >> public statement against the UASF proposal. Not because we disagree -- that >> is fine -- but because any UASF must be a grassroots effort and >> endorsements (or denouncements) detract from that. >> > > So it has to be supported by the public but I can't say why I don't > support it? This seems extremely suspect to me. > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > triggering BIP141 activation, and therefore not enabling the new consensus > rules on already deployed full nodes. BIP148 is making an explicit choice > to favor dragging along those users which have upgraded to BIP141 support > over those miners who have failed to upgrade. > I do not follow the argument that a critical design feature of a particular "user activated soft fork" could be that it is users don't need to be involved. If the goal is user activation I would think that the expectation would be that the overwhelming majority of users would be upgrading to do it, if that isn't the case, then it isn't really a user activated softfork-- it's something else. > On an aside, I'm somewhat disappointed that you have decided to make a > public statement against the UASF proposal. Not because we disagree -- that > is fine -- but because any UASF must be a grassroots effort and > endorsements (or denouncements) detract from that. > So it has to be supported by the public but I can't say why I don't support it? This seems extremely suspect to me. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Sat, Apr 15, 2017 at 8:42 AM, Mark Friedenbach via bitcoin-dev wrote: > The alternative [Greg presents] (new BIP bit) has the clear downside > of not triggering BIP141 activation, and therefore not enabling the > new consensus rules on already deployed full nodes. BIP148 is making > an explicit choice to favor dragging along those users which have > upgraded to BIP141 support over those miners who have failed to > upgrade. A proposal from yesterday would separate this concern; though not retroactively. One way to name this proposal would be "Catch-All Segwit Activation". "extended BIP9 activation of segwit, for legacy nodes" https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014160.html If this release valve exists, then discussions (such as this thread) can get back to focusing on finding the safest incentive-compatible transitions, with time improving the situation instead of making it worse. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Greg, If I understand correctly, the crux of your argument against BIP148 is that it requires the segwit BIP9 activation flag to be set in every block after Aug 1st, until segwit activates. This will cause miners which have not upgrade and indicated support for BIP141 (the segwit BIP) to find their blocks ignored by UASF nodes, at least for the month or two it takes to activate segwit. Isn't this however the entire point of BIP148? I understand if you object to this, but let's be clear that this is a design requirement of the proposal, not a technical oversight. The alternative you present (new BIP bit) has the clear downside of not triggering BIP141 activation, and therefore not enabling the new consensus rules on already deployed full nodes. BIP148 is making an explicit choice to favor dragging along those users which have upgraded to BIP141 support over those miners who have failed to upgrade. On an aside, I'm somewhat disappointed that you have decided to make a public statement against the UASF proposal. Not because we disagree -- that is fine -- but because any UASF must be a grassroots effort and endorsements (or denouncements) detract from that. Mark Friedenbach ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
> Besides that, I also just don't believe that UASF itself as a method to activate softforks is a good choice. The only two reliable signals we have for this purpose in Bitcoin are block height (flag day) and standard miner signaling, as every other metric can be falsified or gamed. UASF can be just a flag day. On Sat, Apr 15, 2017 at 9:23 AM, Natanael via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org>: > > > Not sure if you missed my previous reply to you, but I'm curious about > your thoughts on this particular point. I contend that for any UASF, > orphaning non-signalling blocks on the flag date is [maybe] safer [for > those in on the UASF fork] than just > considering the fork active on the flag date. > > > Note my additions. > > Enforcement by orphaning non-compliance makes it harder to reverse a buggy > softfork, since you necessarily increase the effort needed to return enough > mining power to the safe chain since you now have mostly unmonitored mining > hardware fighting you actively, whose operators you might not be able to > contact. You'd practically have to hardfork out of the situation. > > There's also the risk of the activation itself triggering concensus bugs > (multiple incompatible UASF forks), if there's multiple implementations of > it in the network (or one buggy one). We have already seen something like > it happen. This can both happen on the miner side, client side or both > (miner side only would lead to a ton of orphaned blocks, client side means > netsplit). > > It is also not economically favorable for any individual miner to be the > one to mine empty blocks on top of any surviving softfork-incompatible > chain. As a miner you would only volunteer to do it if you believe the > softfork is necessary or itself will enable greater future profit. > > Besides that, I also just don't believe that UASF itself as a method to > activate softforks is a good choice. The only two reliable signals we have > for this purpose in Bitcoin are block height (flag day) and standard miner > signaling, as every other metric can be falsified or gamed. > > But there's also more problems - a big one is that we have no way right > now for a node to tell another "the transaction you just relayed to me is > invalid according to an active softfork" (or "will become invalid". This > matters for several reasons. > > The first one that came to my mind is that we have widespread usage of > zero-confirmation payments in the network. > > This was already dangerous for other reasons, but this UASF could make it > guaranteed cost-free to exploit - because as many also know, we ALSO > already have a lot of nodes that do not enforce the non-default rejection > policies (otherwise we'd never see such transactions on blocks), including > many alternative Bitcoin clients. > > The combination of these factors means that you can present an UASF > invalid transaction to a non-updated client that is supposedly protected by > the deliberate orphaning effort, and have it accept this as a payment. To > never see it get confirmed, or to eventually see it doublespent by an > UASF-valid transaction. > > I would not at all be surprised if it turned out that many > zero-confirmation accepting services do not reject non-default > transactions, or if they aren't all UASF-segwit aware. > > This is why a flag day or similar is more effective - it can't be ignored > unlike "just another one of those UASF proposals" that you might not have > evaluated or not expect to activate. > > This is by the way also a reason that I believe that all nodes and > services should publish all concensus critical policies that they enforce. > This would make it far easier to alert somebody that they NEED TO prepare > for whatever proposal that might conflict with their active policies. > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Not sure if you missed my previous reply to you, but I'm curious about your thoughts on this particular point. I contend that for any UASF, orphaning non-signalling blocks on the flag date is [maybe] safer [for those in on the UASF fork] than just considering the fork active on the flag date. Note my additions. Enforcement by orphaning non-compliance makes it harder to reverse a buggy softfork, since you necessarily increase the effort needed to return enough mining power to the safe chain since you now have mostly unmonitored mining hardware fighting you actively, whose operators you might not be able to contact. You'd practically have to hardfork out of the situation. There's also the risk of the activation itself triggering concensus bugs (multiple incompatible UASF forks), if there's multiple implementations of it in the network (or one buggy one). We have already seen something like it happen. This can both happen on the miner side, client side or both (miner side only would lead to a ton of orphaned blocks, client side means netsplit). It is also not economically favorable for any individual miner to be the one to mine empty blocks on top of any surviving softfork-incompatible chain. As a miner you would only volunteer to do it if you believe the softfork is necessary or itself will enable greater future profit. Besides that, I also just don't believe that UASF itself as a method to activate softforks is a good choice. The only two reliable signals we have for this purpose in Bitcoin are block height (flag day) and standard miner signaling, as every other metric can be falsified or gamed. But there's also more problems - a big one is that we have no way right now for a node to tell another "the transaction you just relayed to me is invalid according to an active softfork" (or "will become invalid". This matters for several reasons. The first one that came to my mind is that we have widespread usage of zero-confirmation payments in the network. This was already dangerous for other reasons, but this UASF could make it guaranteed cost-free to exploit - because as many also know, we ALSO already have a lot of nodes that do not enforce the non-default rejection policies (otherwise we'd never see such transactions on blocks), including many alternative Bitcoin clients. The combination of these factors means that you can present an UASF invalid transaction to a non-updated client that is supposedly protected by the deliberate orphaning effort, and have it accept this as a payment. To never see it get confirmed, or to eventually see it doublespent by an UASF-valid transaction. I would not at all be surprised if it turned out that many zero-confirmation accepting services do not reject non-default transactions, or if they aren't all UASF-segwit aware. This is why a flag day or similar is more effective - it can't be ignored unlike "just another one of those UASF proposals" that you might not have evaluated or not expect to activate. This is by the way also a reason that I believe that all nodes and services should publish all concensus critical policies that they enforce. This would make it far easier to alert somebody that they NEED TO prepare for whatever proposal that might conflict with their active policies. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On 04/15/2017 03:04 AM, Gregory Maxwell via bitcoin-dev wrote: > Considering that you did not spare a single word about the specific > property that I am concerned about-- that the proposal will reject > the blocks of passive participants, due to avoidable design > limitations-- I can't help but feel that you don't even care to > understand the concern I was bringing up. :( Not sure if you missed my previous reply to you, but I'm curious about your thoughts on this particular point. I contend that for any UASF, orphaning non-signalling blocks on the flag date is safer than just considering the fork active on the flag date. Unless we have majority miner support for the fork, we have to assume that a chain split will occur at some point. With the orphaning approach, we know exactly when that will be, and can plan around it. Miners know that they need to upgrade by the flag date in order to get paid. We even have an opportunity to back out if it looks like we don't have enough economic support. With the non-orphaning approach, the split won't occur until someone chooses to craft a malicious block (short bitcoin; rent hash power; profit). We don't know when that will be, so we can't plan around it. Some nodes and miners will assume it won't happen at all. When it happens, our responses to it will be clumsy, uncoordinated, and likely panicked. While the orphaning approach is potentially disruptive to miners, it is necessarily so in order to minimize disruption to users. In general, users should be prioritized over miners. The point of Bitcoin is to have secure, digital money that we can *use*, not to enable people to earn money from running busy-work computations. > How many people barely reviewed the specifics of the proposal simply > because they want something fast and this proposal does something > fast? I have scrutinized the strategy of BIP148 a fair bit. I was initially opposed to it, but after Bitfury showed their support, and especially after the Asicboost revelation, I think it has solid potential to succeed. It would be a waste not to at least attempt to organize around it. If it turns out that we can't get the necessary support in time, we can abandon the effort and reassess our options. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Thank-you for your prompt response, I believe I must have a different prospective of Bitcoin to you. Ideologically I don’t agree that miners can be passive participants in the Bitcoin Network; and I certainly don’t see them acting as passive participants in the Bitcoin Community now. The miners are very much political actors. Hence why I fail to take-to-heart your concern "that the proposal will reject the blocks of passive participants”. With AsicBoost, there are three miner groups: Those who use it (and have legal sanction to do so); Those who use it (without legal sanction); and those who don’t use it. If SegWit didn’t directly affect miners, then one could possibly claim that there could be an ideal passive participant miner in reality. However since your important revelations on AsicBoost: SegWit cannot be a ‘passive’ option for miners. Hence, I don’t care about orphaning the blocks of of the theoretical "passive participant” miner. As I have no logical reasoning to suggest one could exists; and a large amount of evidence to suggesting one dose not exit. On BIP 16 vs. BIP 17; I cannot see how BIP 148 similar engineering tradeoffs. Is there any long-term ‘technical debt’ from BIP 148 that I’m unaware of that could be similar to BIP 16? On the Drama: Well 100M USD p/a can pay for lots of Drama; Hence going back to the first point: The miners are not passive participants when it comes to *any* form of activation of SegWit. Cameron. > On 15 Apr 2017, at 10:04 AM, Gregory Maxwell wrote: > > On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham wrote: >> As many may remember, there was quite some controversy about the BIP16 vs >> BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how >> this was the already “tested and proven to work” solution. > > And as a result we ultimately got a clearly inferior solution (520 > byte script limit; 80-bit security; months of orphaned blocks-- and > two of those were not issues in BIP17). I went along for the cram > fest on 16 after 12 caught fire, and I was mistaken to do so. > > Doubly so because it took years for P2SH to achieve any kind of mass > deployment due to issues far away from consensus. An extra two months > spent on some ground-work (including communications and documentation) > could have pulled forward practical deployment by a year and given > time to find and fix some of the flaws in the design of P2SH. > >> BIP 148 is out (our?) terms of peace. The Bitcoin Community is >> tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a >> outlet, and in Maxwell words: “...almost guarantees at a minor level of >> disruption.”. > > It seems I lost a word in my comment: that should have been "almost > guarantees at _least_ a minor level of disruption". A minor level of > disruption is the _minimum_ amount of disruption, and for no good > reason except an unprecedented and unjustified level of haste. > > Considering that you did not spare a single word about the specific > property that I am concerned about-- that the proposal will reject the > blocks of passive participants, due to avoidable design limitations-- > I can't help but feel that you don't even care to understand the > concern I was bringing up. :( > > How many people barely reviewed the specifics of the proposal simply > because they want something fast and this proposal does something > fast? > >> tired-to-death of this war and wants a resolution swiftly > > By now competitors and opponents to Bitcoin have surely realized that > they can attack Bitcoin by stirring up drama. > > As a result, the only way that we will ever be free from "war" is if > we choose to not let it impact us as much as possible. We must be > imperturbable and continue working at the same level of excellence as > if virtual shells weren't flying overhead-- or otherwise there is an > incentive to keep them flying 24/7. Internet drama is remarkably cheap > to generate. "The only thing we have to fear is fear itself". > > The alternative is that we hand opponents a ready made formula for > disruption: astroturf enough drama up that Bitcoiners "sacrifice > correctness" themselves right off a cliff in a futile attempt to make > it go away. :) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham wrote: > As many may remember, there was quite some controversy about the BIP16 vs BIP > 17 split; the main argument for BIP16 was the urgency of P2SH, and how this > was the already “tested and proven to work” solution. And as a result we ultimately got a clearly inferior solution (520 byte script limit; 80-bit security; months of orphaned blocks-- and two of those were not issues in BIP17). I went along for the cram fest on 16 after 12 caught fire, and I was mistaken to do so. Doubly so because it took years for P2SH to achieve any kind of mass deployment due to issues far away from consensus. An extra two months spent on some ground-work (including communications and documentation) could have pulled forward practical deployment by a year and given time to find and fix some of the flaws in the design of P2SH. > BIP 148 is out (our?) terms of peace. The Bitcoin Community is > tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a > outlet, and in Maxwell words: “...almost guarantees at a minor level of > disruption.”. It seems I lost a word in my comment: that should have been "almost guarantees at _least_ a minor level of disruption". A minor level of disruption is the _minimum_ amount of disruption, and for no good reason except an unprecedented and unjustified level of haste. Considering that you did not spare a single word about the specific property that I am concerned about-- that the proposal will reject the blocks of passive participants, due to avoidable design limitations-- I can't help but feel that you don't even care to understand the concern I was bringing up. :( How many people barely reviewed the specifics of the proposal simply because they want something fast and this proposal does something fast? > tired-to-death of this war and wants a resolution swiftly By now competitors and opponents to Bitcoin have surely realized that they can attack Bitcoin by stirring up drama. As a result, the only way that we will ever be free from "war" is if we choose to not let it impact us as much as possible. We must be imperturbable and continue working at the same level of excellence as if virtual shells weren't flying overhead-- or otherwise there is an incentive to keep them flying 24/7. Internet drama is remarkably cheap to generate. "The only thing we have to fear is fear itself". The alternative is that we hand opponents a ready made formula for disruption: astroturf enough drama up that Bitcoiners "sacrifice correctness" themselves right off a cliff in a futile attempt to make it go away. :) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Hello, It is hard for me to come out disagreeing with Maxwell, however in this case I feel I must. As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution. I was one of the man hold-out supporters of BIP17, not for any clear reason (I now have a much better technical understanding of the Bitcoin technical details, as we all do); But because it was the ‘more elegant’ solution. I knew from other fields of engineering that elegant solutions very often better deal with the ‘unknown, unknowns’. I also didn’t agree with Gavin’s ‘the sky is falling’ sense of urgency. However, of-course the community got behind BIP16, it was activated, fortunately, without any signifiant incident. I did learn that in Bitcoin there is something more valuable than technical elegance: that is community buy-in. On the technical side, the engineers need to make sure the solutions are viable: however on the community side we need to make sure that the good solutions are adopted in a reasonable timeframe. It is both my empirical view and heart-felt belief that the wider Bitcoin Community wants SegWit quickly. In this case the sacrifice of some technical elegance and correctness for expediency is prudent! It is my unfortunate view that Maxwell is missing the political forest for the technical trees. Not only is SegWit a technical solution to technical problems; it has come to represent, by the larger Bitcoin Community, a political solution to the conflict that we are waist-deep in every, single, day. BIP 148 is out terms of peace. The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”. I am willing to go through this minor level of disruption, as the daily disruption from the “scaling debate war”; in my personal online life, is far greater. SegWit is a exceptional feat of engineering, it solves and mitigates so many small and highly subtle issues within Bitcoin; yet still managed to be simple enough successfully reviewed: now the community is clearly calling for a quick activation of the ‘viable’ technical choice. If you/we are going to provide any engineering solution to activating SegWit, then Swiftness should be the 1st priority after viability. BIP 148 is both Swift and Viable. Cameron. > On 14 Apr 2017, at 10:56 AM, Gregory Maxwell via bitcoin-dev > wrote: > > I do not support the BIP148 UASF for some of the same reasons that I > do support segwit: Bitcoin is valuable in part because it has high > security and stability, segwit was carefully designed to support and > amplify that engineering integrity that people can count on now and > into the future. > > I do not feel the the approach proposed in BIP148 really measures up > to the standard set by segwit itself, or the existing best practices > in protocol development in this community. > > The primary flaw in BIP148 is that by forcing the activation of the > existing (non-UASF segwit) nodes it almost guarantees at a minor level > of disruption. > > Segwit was carefully engineered so that older unmodified miners could > continue operating _completely_ without interruption after segwit > activates. > > Older nodes will not include segwit spends, and so their blocks will > not be invalid even if they do not have segwit support. They can > upgrade to it on their own schedule. The only risk non-participating > miners take after segwit activation is that if someone else mines an > invalid block they would extend it, a risk many miners already > frequently take with spy-mining. > > I do not think it is a horrible proposal: it is better engineered than > many things that many altcoins do, but just not up to our normal > standards. I respect the motivations of the authors of BIP 148. If > your goal is the fastest possible segwit activation then it is very > useful to exploit the >80% of existing nodes that already support the > original version of segwit. > > But the fastest support should not be our goal, as a community-- there > is always some reckless altcoin or centralized system that can support > something faster than we can-- trying to match that would only erode > our distinguishing value in being well engineered and stable. > > "First do no harm." We should use the least disruptive mechanisms > available, and the BIP148 proposal does not meet that test. To hear > some people-- non-developers on reddit and such-- a few even see the > forced orphaning of 148 as a virtue, that it's punitive for > misbehaving miners. I could not not disagree with that perspective any > more strongly. > > Of course, I do not oppose the general concept of a UASF but > _generally_ a soft-fork (of any kind) does not need to risk disruption > of mining, just as segwit's ac
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Sat, Apr 15, 2017 at 4:10 AM, Steven Pine wrote: > but segwit does > have a 'time out' as defined in BIP 9 with the date of November 15th? There is a technical requirement that BIP 9 bit allocations must have a timeout so that a bit is not forever burned if a proposal is ever abandoned (e.g. because something better came along before it activated). This isn't a timeout for the proposal, but for the bit assignment. If a proposal hasn't activated but there is still interest it will just get a new bit (and can alternate back and forth between a pair). This is a timeout of the bit, not the proposal. It has to be setup this way because there is no real way to communicate abandonment to old software, so a timeout must be set in advance. > Does core plan "Core" doesn't plan on much of anything beyond the immediate pipeline of activities, similar to other large open source collaboration, or open standards development organizations. It isn't a company. Individuals have plans about their own work which they may collaborate in one place or another. But allocating a new bit is how BIP9 works. > meaning was every census change has gone through a core defined process (not > counting the changes that occurred before there were BIPs and such), isn't What is a "core defined process"? BIP _itself_ was created by someone who, AFAICT, has never made a commit to Bitcoin Core. Numbers are currently assigned, a nearly judgement-less administrative task, by someone that authors competing fork of the software (Knots). > it would seem like the first time census occurred outside core Yet it was proposed on this list, had a BIP defined... if it got eventually used it would presumably end up in the Bitcoin Core project eventually... so what exactly is your definition of outside? Above you seemed to be saying a BIP was not outside, but here you are saying something documented as a BIP is outside? If your preference is to not insult then it may be advisable to not disregard distinctions which you do not understand as semantics. :) I am not prone to arguing over semantics-- the continually binning in almost all public collaboration as the work of some centralized entity is really harmful to our community. The distinction is real, and not semantics. > To be clear, the fast and reckless part for you is the mechanism by which > segwit could possibly be made active? Do you envision a means of segwit > being made consensus that does not have 95% mining support? Sure, and I said so directly in my message. I believe I was adequately clear that my complaint about BIP148 is specifically that it has forced orphaning of passive participants which can be easily avoided but at the expense of actually needed users to adopt the change. For clarity, it could be summarized as: I would not classify BIP148 as a user activated soft-fork but instead as "user enforced miner soft-fork activation". The consequence of this is that it likely cannot achieve low disruptiveness-- this limitation would be excusable if we weren't aware of any alternative, but in this case we are and the only relative downside of it is that users will need to upgrade for it-- which should not be a problem in principle if we believe a UASF is really user activated. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
I don't want to be rude and I will refer to your expertise, but segwit does have a 'time out' as defined in BIP 9 with the date of November 15th? Does core plan on just releasing another BIP with a new timeout hoping it will eventually get 95% census? As for the other point, we can play semantics but that's boring, I guess my meaning was every census change has gone through a core defined process (not counting the changes that occurred before there were BIPs and such), isn't that the case? If the currently discussed UASF goes through it would seem like the first time census occurred outside core's mailing list of pull requests, acks, and merge to master, I only note it as a thing of interest. To be clear, the fast and reckless part for you is the mechanism by which segwit could possibly be made active? Do you envision a means of segwit being made consensus that does not have 95% mining support? I appreciate your time and expertise, and to not take up anymore, back to lurking i go. On Fri, Apr 14, 2017 at 11:29 PM, Gregory Maxwell wrote: > On Sat, Apr 15, 2017 at 2:01 AM, Steven Pine via bitcoin-dev > wrote: > > Regarding this last point I was under the impression that if Segwit did > not > > activate by November then core was going to move on, is that no longer > the > > Wow. Where did you get that idea? That is _absurd_ and untrue, and I > struggle a bit to even comprehend how someone could believe it. It > would continue until something clearly better came along or people > lost interest in it, why would it be anything else? > > > census change that was not rolled out and done by the core team? I only > > mention this because BIP148, if it goes ahead (and is successful), would > be > > the first time a consensus change occurs outside of the core developers > -- > > but again I am not an expert on the history of changes and could be > wrong, I > > There is a definitional issue there. There isn't much of "the core > team" there is a lot of amorphous public collaboration; everything > ends up being retroactively defined as the core team. With open > participation and hundreds of contributors and software running > everywhere in the network, its unlikely that someone would advance to > the point of being able to make a credible proposal without at some > point making some improvement to the project or without the help of > someone who has. > > In some sense you are coming very close to asking for a list of people > who have contributed to Bitcoin without contributing to Bitcoin. > > CLTV was a proposal by Peter Todd whom has done a number of other > things in core but AFAIR had no involvement in any prior soft-fork > (though perhaps I'm forgetting one?), though he subsequently > contributed to BIP66 (which activated before CLTV), and he contributed > mostly after-the fact review of segwit. CSV was mostly the work of > Mark Friedenbach whom I believe was not involved in any prior or > subsequent soft-fork (and whos total contributions to Bitcoin core > weigh in at 14 commits over 5 years). > > > My impression is that the community is ready for this and wants it, and > if > > that impression is correct it will go ahead. No one knows the future, and > > simply assuming it's better to be slow and methodical isn't especially > > I am not suggesting slow. I am suggesting that we not be outright > reckless. Some people are expecting changes which are effectively > orders of magnitude faster than changes in centralized systems > elsewhere which are far easier and safer to take quickly. > > (Some more comparatives here: > https://www.reddit.com/r/Bitcoin/comments/65bch8/gregory_maxwell_i_do_not_ > support_the_bip_148_uasf/dg9xfam/ > ) > > > Technology is in someways the history of failure, > > By all means, take risks-- but you don't get to choose to make other > peoples things fail; you certainly don't get to demand their support, > though you could try to earn it if you care, by figuring out how to > meet their concerns. > -- Steven Pine (510) 517-7075 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Sat, Apr 15, 2017 at 2:01 AM, Steven Pine via bitcoin-dev wrote: > Regarding this last point I was under the impression that if Segwit did not > activate by November then core was going to move on, is that no longer the Wow. Where did you get that idea? That is _absurd_ and untrue, and I struggle a bit to even comprehend how someone could believe it. It would continue until something clearly better came along or people lost interest in it, why would it be anything else? > census change that was not rolled out and done by the core team? I only > mention this because BIP148, if it goes ahead (and is successful), would be > the first time a consensus change occurs outside of the core developers -- > but again I am not an expert on the history of changes and could be wrong, I There is a definitional issue there. There isn't much of "the core team" there is a lot of amorphous public collaboration; everything ends up being retroactively defined as the core team. With open participation and hundreds of contributors and software running everywhere in the network, its unlikely that someone would advance to the point of being able to make a credible proposal without at some point making some improvement to the project or without the help of someone who has. In some sense you are coming very close to asking for a list of people who have contributed to Bitcoin without contributing to Bitcoin. CLTV was a proposal by Peter Todd whom has done a number of other things in core but AFAIR had no involvement in any prior soft-fork (though perhaps I'm forgetting one?), though he subsequently contributed to BIP66 (which activated before CLTV), and he contributed mostly after-the fact review of segwit. CSV was mostly the work of Mark Friedenbach whom I believe was not involved in any prior or subsequent soft-fork (and whos total contributions to Bitcoin core weigh in at 14 commits over 5 years). > My impression is that the community is ready for this and wants it, and if > that impression is correct it will go ahead. No one knows the future, and > simply assuming it's better to be slow and methodical isn't especially I am not suggesting slow. I am suggesting that we not be outright reckless. Some people are expecting changes which are effectively orders of magnitude faster than changes in centralized systems elsewhere which are far easier and safer to take quickly. (Some more comparatives here: https://www.reddit.com/r/Bitcoin/comments/65bch8/gregory_maxwell_i_do_not_support_the_bip_148_uasf/dg9xfam/ ) > Technology is in someways the history of failure, By all means, take risks-- but you don't get to choose to make other peoples things fail; you certainly don't get to demand their support, though you could try to earn it if you care, by figuring out how to meet their concerns. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
>Regarding this last point I was under the impression that if Segwit did not activate by November then core was going to move on, is that no longer the case, does the core team plan on trying to activate Segwit in some other way? Since block size seems to be the controversial issue, AFAIK we *could* remove the block size increase (by removing the discount on signature data). This discount was put in place for two reasons 1.) It allows for a block size increase 2.) It makes it more expensive to create UTXOs. UTXO bloat is a problem on the bitcoin network and segwit was an elegant way to make the network appreciate their real cost in terms of hardware/RAM. We would still get the benefits of: 1.) Tx malleability elimination 2.) Script versioning -Chris On Fri, Apr 14, 2017 at 9:01 PM, Steven Pine via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Segwit is a good improvement > and we should respect it by knowing that it's good enough to wait for, > and for however its activated to be done the best way we know how. > > Regarding this last point I was under the impression that if Segwit did > not activate by November then core was going to move on, is that no longer > the case, does the core team plan on trying to activate Segwit in some > other way? > > I am also curious, but has there been a softfork, hardfork, or other major > census change that was not rolled out and done by the core team? I only > mention this because BIP148, if it goes ahead (and is successful), would be > the first time a consensus change occurs outside of the core developers -- > but again I am not an expert on the history of changes and could be wrong, > I only bring this up because core developers have in the past stressed they > are a part of the bitcoin ecosystem and not the drivers of it (at least > that is the ideal it seems). > > My impression is that the community is ready for this and wants it, and if > that impression is correct it will go ahead. No one knows the future, and > simply assuming it's better to be slow and methodical isn't especially > convincing. Technology is in someways the history of failure, we like to > celebrate the seemingly sudden breakthroughs and successes but it's rare > that the original innovator retains a monopoly on their invention, more > often it becomes quickly refined and iterated upon as market forces take > hold to bring costs down and other external political issues > take precedence, all this is say that in ten years everyone could be > chuckling over the 3 year bitcoin scaling debate, or they could be using > litecoin, or ethereum or some other crypto coin, or something entirely > different, no one knows. > > On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I do not support the BIP148 UASF for some of the same reasons that I >> do support segwit: Bitcoin is valuable in part because it has high >> security and stability, segwit was carefully designed to support and >> amplify that engineering integrity that people can count on now and >> into the future. >> >> I do not feel the the approach proposed in BIP148 really measures up >> to the standard set by segwit itself, or the existing best practices >> in protocol development in this community. >> >> The primary flaw in BIP148 is that by forcing the activation of the >> existing (non-UASF segwit) nodes it almost guarantees at a minor level >> of disruption. >> >> Segwit was carefully engineered so that older unmodified miners could >> continue operating _completely_ without interruption after segwit >> activates. >> >> Older nodes will not include segwit spends, and so their blocks will >> not be invalid even if they do not have segwit support. They can >> upgrade to it on their own schedule. The only risk non-participating >> miners take after segwit activation is that if someone else mines an >> invalid block they would extend it, a risk many miners already >> frequently take with spy-mining. >> >> I do not think it is a horrible proposal: it is better engineered than >> many things that many altcoins do, but just not up to our normal >> standards. I respect the motivations of the authors of BIP 148. If >> your goal is the fastest possible segwit activation then it is very >> useful to exploit the >80% of existing nodes that already support the >> original version of segwit. >> >> But the fastest support should not be our goal, as a community-- there >> is always some reckless altcoin or centralized system that can support >> something faster than we can-- trying to match that would only erode >> our distinguishing value in being well engineered and stable. >> >> "First do no harm." We should use the least disruptive mechanisms >> available, and the BIP148 proposal does not meet that test. To hear >> some people-- non-developers on reddit and such-- a few even see the >> forced orphaning of 148 as a virtue, that it's punitive for >> misbehaving
Re: [bitcoin-dev] I do not support the BIP 148 UASF
> Segwit is a good improvement and we should respect it by knowing that it's good enough to wait for, and for however its activated to be done the best way we know how. Regarding this last point I was under the impression that if Segwit did not activate by November then core was going to move on, is that no longer the case, does the core team plan on trying to activate Segwit in some other way? I am also curious, but has there been a softfork, hardfork, or other major census change that was not rolled out and done by the core team? I only mention this because BIP148, if it goes ahead (and is successful), would be the first time a consensus change occurs outside of the core developers -- but again I am not an expert on the history of changes and could be wrong, I only bring this up because core developers have in the past stressed they are a part of the bitcoin ecosystem and not the drivers of it (at least that is the ideal it seems). My impression is that the community is ready for this and wants it, and if that impression is correct it will go ahead. No one knows the future, and simply assuming it's better to be slow and methodical isn't especially convincing. Technology is in someways the history of failure, we like to celebrate the seemingly sudden breakthroughs and successes but it's rare that the original innovator retains a monopoly on their invention, more often it becomes quickly refined and iterated upon as market forces take hold to bring costs down and other external political issues take precedence, all this is say that in ten years everyone could be chuckling over the 3 year bitcoin scaling debate, or they could be using litecoin, or ethereum or some other crypto coin, or something entirely different, no one knows. On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I do not support the BIP148 UASF for some of the same reasons that I > do support segwit: Bitcoin is valuable in part because it has high > security and stability, segwit was carefully designed to support and > amplify that engineering integrity that people can count on now and > into the future. > > I do not feel the the approach proposed in BIP148 really measures up > to the standard set by segwit itself, or the existing best practices > in protocol development in this community. > > The primary flaw in BIP148 is that by forcing the activation of the > existing (non-UASF segwit) nodes it almost guarantees at a minor level > of disruption. > > Segwit was carefully engineered so that older unmodified miners could > continue operating _completely_ without interruption after segwit > activates. > > Older nodes will not include segwit spends, and so their blocks will > not be invalid even if they do not have segwit support. They can > upgrade to it on their own schedule. The only risk non-participating > miners take after segwit activation is that if someone else mines an > invalid block they would extend it, a risk many miners already > frequently take with spy-mining. > > I do not think it is a horrible proposal: it is better engineered than > many things that many altcoins do, but just not up to our normal > standards. I respect the motivations of the authors of BIP 148. If > your goal is the fastest possible segwit activation then it is very > useful to exploit the >80% of existing nodes that already support the > original version of segwit. > > But the fastest support should not be our goal, as a community-- there > is always some reckless altcoin or centralized system that can support > something faster than we can-- trying to match that would only erode > our distinguishing value in being well engineered and stable. > > "First do no harm." We should use the least disruptive mechanisms > available, and the BIP148 proposal does not meet that test. To hear > some people-- non-developers on reddit and such-- a few even see the > forced orphaning of 148 as a virtue, that it's punitive for > misbehaving miners. I could not not disagree with that perspective any > more strongly. > > Of course, I do not oppose the general concept of a UASF but > _generally_ a soft-fork (of any kind) does not need to risk disruption > of mining, just as segwit's activation does not. UASF are the > original kind of soft-fork and were the only kind of fork practiced by > Satoshi. P2SH was activated based on a date, and all prior ones were > based on times or heights. We introduced miner based activation as > part of a process of making Bitcoin more stable in the common case > where the ecosystem is all in harmony. It's kind of weird to see UASF > portrayed as something new. > > It's important the users not be at the mercy of any one part of the > ecosystem to the extent that we can avoid it-- be it developers, > exchanges, chat forums, or mining hardware makers. Ultimately the > rules of Bitcoin work because they're enforced by the users > collectively-- that is what makes Bitcoin
[bitcoin-dev] I do not support the BIP 148 UASF
Speaking as one of the BIP148 agitators: > There have been some other UASF proposals that avoid the forced > disruption-- by just defining a new witness bit and allowing > non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I > think they are vastly superior. They would be slower to deploy, but I > do not think that is a flaw. I'm assuming that you're referring to the flag date "segwit is on now" approach. This is more dangerous than the orphaning approach that BIP148 uses. If we orphan non-signalling blocks on the flag date and don't have majority hash power supporting us, there will be a chain split on the flag day. We expect this to happen, we plan for it, and we employ strategies to mitigate any damage. The bulk of the economy has coordinated around this event happening. We even had the opportunity to pull the plug before the flag date if things were looking too grim. After the dust settles, 100% of the miners are guaranteed to have upgraded, assuming they didn't choose to forgo 2+ weeks of income. Any further chain splits would have to be the result of deliberate action by 51%+ of the mining power. If we just have segwit activate on the flag date without orphaning the blocks of non-segwit miners, we set ourselves up for a chain split at some unknown time in the future. Without majority hash power on our side, as soon as someone mines a segwit-invalid transaction, the chain will split, with upgraded nodes and miners on one side, and non-upgraded nodes and miners on the other side. The segwit-invalid transaction doesn't even need to come from someone with their own mining equipment. Open a short on BTC, rent some hash power, profit. Since we don't know when this attack will occur, we won't be organized and ready for it. It's also easy for both miners and users to get complacent about it and fail to upgrade. The damage will be far worse than if we had used the orphaning approach. > "First do no harm." We should use the least disruptive mechanisms > available, and the BIP148 proposal does not meet that test. To hear > some people-- non-developers on reddit and such-- a few even see the > forced orphaning of 148 as a virtue, that it's punitive for > misbehaving miners. I could not not disagree with that perspective any > more strongly. Punitive action against miners is not the point of BIP148, it's an unavoidable side-effect of making the UASF less disruptive for the users of Bitcoin. Minimizing disruption for users must take priority over minimizing disruption for miners. Given the intensity of this dispute and the bad faith of certain actors, some schadenfreude is bound to occur. Don't let that distract you from the actual reasons that BIP148 is designed the way it is. > We should have patience. Bitcoin is a system that should last for all > ages and power mankind for a long time-- ten years from now a couple > years of dispute will seem like nothing. But the reputation we earn > for stability and integrity, for being a system of money people can > count on will mean everything. I respect this perspective, and I agree with it to a certain extent. However, continuing to wait has costs. I do not believe we have the luxury of continuing to wait for a couple more years. In doing so it's entirely possible that we may damage our reputation for stability and integrity rather than build on it. We have a window of opportunity with BIP148, and it would be a waste not to act on it. In the event that we still lack sufficient support by July, we can abandon the project, and make plans for how best to proceed from there. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Fri, Apr 14, 2017 at 9:10 PM, James Hilliard via bitcoin-dev wrote: > would have to intentionally modify the code to mine an invalid block > which is not something that would be likely to happen accidentally. IIRC-- If you do it accidentally you'll fail the tests, though there have been a couple reckless alternative implementations that have just ripped out most of the tests... In any case there is no need to speculate or guess-- invalid segwit spends are not being mined today... ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Fri, Apr 14, 2017 at 3:58 PM, Tom Zander via bitcoin-dev wrote: > On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote: >> This doesn't remove the need for consensus rule enforcement of course. > > Thanks for confirming my point. > > This means that Gregory was incorrect saying that there is no risk to a non- > upgraded node on a SegWit network mining a new invalid block. That risk is > most definitely there for any miners "left behind" operating on a different > set of consensus rules than the majority. Greg is correct. There is effectively no risk to a non-upgrade accidentally mining a new invalid block itself, the only risk is that a non-upgraded miner could itself mine on top of an invalid block. You would have to intentionally modify the code to mine an invalid block which is not something that would be likely to happen accidentally. > > Kind of obvious, when you think about it. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote: > This doesn't remove the need for consensus rule enforcement of course. Thanks for confirming my point. This means that Gregory was incorrect saying that there is no risk to a non- upgraded node on a SegWit network mining a new invalid block. That risk is most definitely there for any miners "left behind" operating on a different set of consensus rules than the majority. Kind of obvious, when you think about it. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Fri, Apr 14, 2017 at 8:34 PM, Tom Zander via bitcoin-dev wrote: > I expected you to know this, but ok, I'll explain. Please stop abusing participants on this list. Your activity is actively driving people off this list. James Hilliard should be commended for correcting your misinformation. > If you depend on one implementation and user configuration for the avoidance > of chain forks, you are going to have a hard time. Anyone can modify their software to produce invalid blocks at any time. If they want to be stupid, they can be stupid. The fact remains that miners who haven't gone and wreaked their software internals will not mine segwit incompatible blocks. Right now _no_ observable has broken node in this way. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Fri, Apr 14, 2017 at 3:34 PM, Tom Zander wrote: > On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote: >> This is false, >> >> Those "everyone can spend" transactions are prohibited from being >> mined due to policy rules. > > I expected you to know this, but ok, I'll explain. > > A policy rule is not a protocol rule, a mining node is certainly not > guarenteet to have it, and those that do typically make it configurable. Yes one can override policy rules and mine invalid SW transactions, but that's not something that's likely to happen accidentally. > > If you depend on one implementation and user configuration for the avoidance > of chain forks, you are going to have a hard time. We don't depend on policy to avoid chain forks, policy however is quite useful for making forks smoother since it can prevent miners from accidentally mining invalid blocks and prevents users from accepting invalid transactions accidentally. This doesn't remove the need for consensus rule enforcement of course. > > Thanks for your thoughtful reply, though. > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote: > This is false, > > Those "everyone can spend" transactions are prohibited from being > mined due to policy rules. I expected you to know this, but ok, I'll explain. A policy rule is not a protocol rule, a mining node is certainly not guarenteet to have it, and those that do typically make it configurable. If you depend on one implementation and user configuration for the avoidance of chain forks, you are going to have a hard time. Thanks for your thoughtful reply, though. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Fri, Apr 14, 2017 at 2:20 PM, Tom Zander via bitcoin-dev wrote: > On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev > wrote: >> Segwit was carefully engineered so that older unmodified miners could >> continue operating _completely_ without interruption after segwit >> activates. > > >> They [Older nodes] can >> upgrade to it [segwit] on their own schedule. The only risk >> non-participating >> miners take after segwit activation is that if someone else mines an >> invalid block they would extend it, > > This is false, > > a segwit transaction to the miner you describe is an "everyone can spend" > transaction, and as such a miner that does not validate the segregated area > in a post-segwit world will be able to create blocks that will not validate > for segwit miners by including a transaction that spends a SW tx. > > This would then lead to a chain-fork as the SW miners reject it and the non- > SW miners continue to mine on it. This is false, Those "everyone can spend" transactions are prohibited from being mined due to policy rules. The risk is only in regards to mining on top of an invalid block that intentionally mined an invalid SW transaction. > > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev wrote: > Segwit was carefully engineered so that older unmodified miners could > continue operating _completely_ without interruption after segwit > activates. > They [Older nodes] can > upgrade to it [segwit] on their own schedule. The only risk > non-participating > miners take after segwit activation is that if someone else mines an > invalid block they would extend it, This is false, a segwit transaction to the miner you describe is an "everyone can spend" transaction, and as such a miner that does not validate the segregated area in a post-segwit world will be able to create blocks that will not validate for segwit miners by including a transaction that spends a SW tx. This would then lead to a chain-fork as the SW miners reject it and the non- SW miners continue to mine on it. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
On Friday, 14 April 2017 18:50:47 CEST praxeology_guy via bitcoin-dev wrote: > Criticizing 148 without suggesting a specific alternative leaves the > community in disarray. Here is a list of clear alternatives; https://github.com/bitcoin/bips/ See the BIPs with number 010[1-8]. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Chris, >Food for thought, why are we rejecting *all* blocks that do not signal segwit? >Can't we just reject blocks that *do not* signal segwit, but *do* contain >segwit transactions? It seems silly to me that if a miner mines a block with >all pre segwit txs to reject that block. Am I missing something here? If you read my email, you will see that I am requesting that gmaxwell or someone code up an alternative that doesn't unnecessarily orphan blocks, just as you are requesting. > Re: old blocks containing SegWit transactions From my understanding, old blocks can contain txos w/ the new SegWit format. But if transaction tries to spend a new SegWit format txo in an old block, such would already break protocol rules, particularly for SegWit activated nodes. And old nodes don't have code that even knows how to spend SegWit format txos. Worst case, such may lead to a fork if <= 50% of the miners are verifying SegWit blocks. > Re: Reckless hand waving: Maybe first you need to prove that forks are necessarily bad for our long term success. How much do we need to be getting delayed in rolling out new good policy before we come to consensus on forking from the delayers? The operating assumption of 148 is that no matter what we are going to fork. So might as well do it then in a controlled manner instead of later when someone creates an invalid SegWit block. Then my only recommendation would be to also implement a boilerplate replay attack prevention just in case the SegWit delayers aren't bluffing. Cheers, Praxeology Guy___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
>Criticizing 148 without suggesting a specific alternative leaves the community in disarray. I really disagree with this sentiment, you don't need to provide alternatives to criticize a technical proposal. I don't like this "active segwit at all costs" theme that has been going around the community. I am a fan of segwit, but we shouldn't push things through in an unsafe manner. >If 148 causes orphaning and a fork, I don't think such really matters in the long term. The non-SegWit miners will probably just quickly give up their orphans once they realize that money users like being able to have non-mutable TX IDs. If they do create a long lasting branch... well that is good too, I'd be happy to no longer have them in our community. Good luck to them in creating a competitive money, so that we can all enjoy lower transaction fees. This seems like a lot of reckless hand waving to me. Food for thought, why are we rejecting *all* blocks that do not signal segwit? Can't we just reject blocks that *do not* signal segwit, but *do* contain segwit transactions? It seems silly to me that if a miner mines a block with all pre segwit txs to reject that block. Am I missing something here? -Chris On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Gregory Maxwell, > > Criticizing 148 without suggesting a specific alternative leaves the > community in disarray. > > I know you are emphasizing patience. But at the same time, with your > patience we are allowing ourselves to get dicked for longer than necessary. > > I think that core could easily develop code that could create a > solid/reliable date/height based activation to allow miners to create > SegWit block candidates and having nodes fully verify them. Shaolinfry is > the only person Ive seen actually make such a proposal: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2017-April/014049.html. His makes it so that SegWit default gets > activated at the end of the BIP9 signalling timeframe instead of default > leaving it non-activated. > > I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a > Denial of Service, given that other activation methods are available. > Someone just needs to code something up that is better that we can all use > in a satisfying time frame. So far 148 is the most practical and reliable > method I'm aware of. > > If 148 causes orphaning and a fork, I don't think such really matters in > the long term. The non-SegWit miners will probably just quickly give up > their orphans once they realize that money users like being able to have > non-mutable TX IDs. If they do create a long lasting branch... well that > is good too, I'd be happy to no longer have them in our community. Good > luck to them in creating a competitive money, so that we can all enjoy > lower transaction fees. > > SegWit has already undergone enough testing. It is time to activate it. > > Cheers, > Praxeology Guy > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
Gregory Maxwell, Criticizing 148 without suggesting a specific alternative leaves the community in disarray. I know you are emphasizing patience. But at the same time, with your patience we are allowing ourselves to get dicked for longer than necessary. I think that core could easily develop code that could create a solid/reliable date/height based activation to allow miners to create SegWit block candidates and having nodes fully verify them. Shaolinfry is the only person Ive seen actually make such a proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014049.html. His makes it so that SegWit default gets activated at the end of the BIP9 signalling timeframe instead of default leaving it non-activated. I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a Denial of Service, given that other activation methods are available. Someone just needs to code something up that is better that we can all use in a satisfying time frame. So far 148 is the most practical and reliable method I'm aware of. If 148 causes orphaning and a fork, I don't think such really matters in the long term. The non-SegWit miners will probably just quickly give up their orphans once they realize that money users like being able to have non-mutable TX IDs. If they do create a long lasting branch... well that is good too, I'd be happy to no longer have them in our community. Good luck to them in creating a competitive money, so that we can all enjoy lower transaction fees. SegWit has already undergone enough testing. It is time to activate it. Cheers, Praxeology Guy___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] I do not support the BIP 148 UASF
I do not support the BIP148 UASF for some of the same reasons that I do support segwit: Bitcoin is valuable in part because it has high security and stability, segwit was carefully designed to support and amplify that engineering integrity that people can count on now and into the future. I do not feel the the approach proposed in BIP148 really measures up to the standard set by segwit itself, or the existing best practices in protocol development in this community. The primary flaw in BIP148 is that by forcing the activation of the existing (non-UASF segwit) nodes it almost guarantees at a minor level of disruption. Segwit was carefully engineered so that older unmodified miners could continue operating _completely_ without interruption after segwit activates. Older nodes will not include segwit spends, and so their blocks will not be invalid even if they do not have segwit support. They can upgrade to it on their own schedule. The only risk non-participating miners take after segwit activation is that if someone else mines an invalid block they would extend it, a risk many miners already frequently take with spy-mining. I do not think it is a horrible proposal: it is better engineered than many things that many altcoins do, but just not up to our normal standards. I respect the motivations of the authors of BIP 148. If your goal is the fastest possible segwit activation then it is very useful to exploit the >80% of existing nodes that already support the original version of segwit. But the fastest support should not be our goal, as a community-- there is always some reckless altcoin or centralized system that can support something faster than we can-- trying to match that would only erode our distinguishing value in being well engineered and stable. "First do no harm." We should use the least disruptive mechanisms available, and the BIP148 proposal does not meet that test. To hear some people-- non-developers on reddit and such-- a few even see the forced orphaning of 148 as a virtue, that it's punitive for misbehaving miners. I could not not disagree with that perspective any more strongly. Of course, I do not oppose the general concept of a UASF but _generally_ a soft-fork (of any kind) does not need to risk disruption of mining, just as segwit's activation does not. UASF are the original kind of soft-fork and were the only kind of fork practiced by Satoshi. P2SH was activated based on a date, and all prior ones were based on times or heights. We introduced miner based activation as part of a process of making Bitcoin more stable in the common case where the ecosystem is all in harmony. It's kind of weird to see UASF portrayed as something new. It's important the users not be at the mercy of any one part of the ecosystem to the extent that we can avoid it-- be it developers, exchanges, chat forums, or mining hardware makers. Ultimately the rules of Bitcoin work because they're enforced by the users collectively-- that is what makes Bitcoin Bitcoin, it's what makes it something people can count on: the rules aren't easy to just change. There have been some other UASF proposals that avoid the forced disruption-- by just defining a new witness bit and allowing non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I think they are vastly superior. They would be slower to deploy, but I do not think that is a flaw. We should have patience. Bitcoin is a system that should last for all ages and power mankind for a long time-- ten years from now a couple years of dispute will seem like nothing. But the reputation we earn for stability and integrity, for being a system of money people can count on will mean everything. If these discussions come up, they'll come up in the form of reminding people that Bitcoin isn't easily changed at a whim, even when the whims are obviously good, and how that protects it from being managed like all the competing systems of money that the world used to use were managed. :) So have patience, don't take short cuts. Segwit is a good improvement and we should respect it by knowing that it's good enough to wait for, and for however its activated to be done the best way we know how. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev