Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EF59AC25 for ; Sat, 15 Apr 2017 04:47:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com [209.85.217.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E8F2A4 for ; Sat, 15 Apr 2017 04:47:45 +0000 (UTC) Received: by mail-ua0-f179.google.com with SMTP id a1so54033554uaf.3 for ; Fri, 14 Apr 2017 21:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VzhTx/P2L0KE2OM5mIhTni6kS7nM67GEZ16Y0iTOLsg=; b=Qp6BV6eytZZIxKu9XgzFnjFSelS10NnJVhLRRu6soVsBVaOtmfNAUKaBrKHFZb5iU+ bPjIKnNAXzNOo+5cu8AzA2xlekwC5dA3HrrDIQBh3OomUEGgQUprh3T9xIxoBVdx2gI5 Cx3hbDLywluVfRv8yBj6yRXik5Eqi4Hui3uOJKft9yUSabx3RZMI2I9wyZGHvvU5EVfo NGAWiz9omwFVhFnh317louNS6RYqCGfQc2oJhtmCgNpmOOkxVdoeMMOG2s7OXMI8ql12 qmDKQk0I0c789LxjPhWWWo31SP3OglujS669irLcaS+MhXrcyr2//zKN4Zfv1NSOLTnO 4siQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VzhTx/P2L0KE2OM5mIhTni6kS7nM67GEZ16Y0iTOLsg=; b=gR/2iahX3xXG31AwEL36XEEfr0RaYLiJcrYg6xksI2F1D36xsBSO+Ys+lGYcLDmBf9 NqZfdrv+DFZZmIoc0H9TEcn3yASM/HYIq/EtGqsxymRMp6RXm2o3yWWIYJV6Q035/UQ5 HiD05Nk4QyHzdJsUiVb4h+raAfqJuEz77YJWmeJtseTvGfdIBJdHxzoibgTNhmN98G+H ZAz9gAgmOIexoxltNZNuwdQ7xIDwAB/CsdNLjc9ktwhgNhsxx/KA3MTffhpz69/jZWZN lt7vAlegsuoYw7hh2ucgr6v5Wn9btGdObpoS+fCK05kIiclMPUfrmtp5ovtfA2c3tHY3 jfvQ== X-Gm-Message-State: AN3rC/5z8dne/ay2HCLjkM4y9syQC81VvfdeiFeRbcq3eUvEkaIDqQFL GnL1kiO81voem5x00zlra9v7IfSrdA== X-Received: by 10.159.32.67 with SMTP id 61mr4331899uam.42.1492231664501; Fri, 14 Apr 2017 21:47:44 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.94.132 with HTTP; Fri, 14 Apr 2017 21:47:43 -0700 (PDT) In-Reply-To: References: From: Gregory Maxwell Date: Sat, 15 Apr 2017 04:47:43 +0000 X-Google-Sender-Auth: SqavohFca0qVXKhxB37FMmBlI8E Message-ID: To: Steven Pine Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 04:47:46 -0000 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.