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 >> >> >