From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 88C7A5A7 for ; Tue, 23 May 2017 06:30:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B1608AD for ; Tue, 23 May 2017 06:30:28 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 482F114C0BD for ; Tue, 23 May 2017 15:30:26 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 23 May 2017 15:30:26 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 2DA664C087 for ; Tue, 23 May 2017 15:30:26 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw25.oz.hdemail.jp (ip-10-174-0-130.ap-northeast-1.compute.internal [10.174.0.130]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 2879714C0C1 for ; Tue, 23 May 2017 15:30:26 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Durian-MailFrom: karljohan-alm@garage.co.jp X-Durian-RcptTo: bitcoin-dev@lists.linuxfoundation.org Received: from gw25.oz.hdemail.jp (gw25.oz.hdemail.jp [127.0.0.1]) by gw25.oz.hdemail.jp (gw25.oz.hdemail.jp [127.0.0.1]); Tue, 23 May 2017 15:30:24 +0900 X-Received: from mail-qk0-f198.google.com (lb1.oz.lo.hdemail.jp [54.248.222.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw25.oz.hdemail.jp (Postfix) with ESMTP id 92BD5148C13D for ; Tue, 23 May 2017 15:30:23 +0900 (JST) X-Received: by mail-qk0-f198.google.com with SMTP id 23so60662241qks.12 for ; Mon, 22 May 2017 23:30:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0xS5G41+UWSQ5jFInkF1lvbOhS3Y9mtKPQkYUsiZ1pk=; b=ukksi5WsO754o9qwpOgWgYT8ps9P15uXhOhvEGyDZ+6oswg9PbRKtZJwYV3cHWqZ2t V9kLwhYH/dQxOhSKo0quRnihLXp4EcOd27CY+/d/67XaTkFHLdz+ylb6P2H7LzlGmzgT yAWFu2/A0/uXRoGnKeNlRXkod9WAq/FR/mSWYCTdlCJbxOiNJjTiOD5BfAPH6538W6pG ESqv+0XinmsbcoT8DEsyxfbziUjjW/1wCSQBQKKM85UbrbUJrB1FZKzNiN2iRo3iMbeF hSOcaomBCKgV3+aNc1fqDHwA9a+iA89F4dRnTk6i3PAx8eYX5KnUPx8l4r3+oQZcGbdc jfqg== X-Gm-Message-State: AODbwcC7vYFJVDPAkMBvIPKV+g0CM49D0tPHP40T492Yc1mtOt0+1S5g xmK0oMBJMkxxc/mKBsX2Nxi2+FeM1YxGKakcsdk1ISEOVFxREh1jolXg00HiVtoykiKx1n6B+5U TUhXZdCB4n6+jFLfqVT0KYlA2GhakmJb5/iz6sIXqbA0GNA== X-Received: by 10.200.55.29 with SMTP id o29mr26040211qtb.120.1495521021660; Mon, 22 May 2017 23:30:21 -0700 (PDT) X-Received: by 10.200.55.29 with SMTP id o29mr26040196qtb.120.1495521021515; Mon, 22 May 2017 23:30:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.12.137.38 with HTTP; Mon, 22 May 2017 23:30:01 -0700 (PDT) In-Reply-To: References: From: Karl Johan Alm Date: Tue, 23 May 2017 15:30:01 +0900 Message-ID: To: Steven Pine Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 23 May 2017 12:03:05 +0000 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: Tue, 23 May 2017 06:30:29 -0000 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.