I do not support the BIP 148 UASF
7 messages, 14 to 20 Apr 2017. Started by Chris Acheson.
Erik Aronesty (2), Chris Acheson, Mark F, Ryan Grant, Gregory Maxwell, Alphonse Pace
Speaking as one of the BIP148 agitators:
Quoted text (5 lines)
> 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.
Quoted text (6 lines)
> "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.
Quoted text (5 lines)
> 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.
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
On Sat, Apr 15, 2017 at 8:42 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (6 lines)
> 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.
On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (5 lines)
> 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.
Quoted text (5 lines)
> 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.
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:
Quoted text (34 lines)
> 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 > >
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:
Quoted text (48 lines)
> 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 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 <alp.bitcoin@gmail•com> wrote:
Quoted text (55 lines)
> 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 >> >> >