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 7E0AD4A5 for ; Thu, 27 Oct 2016 16:22:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from omr2.cc.vt.edu (outbound.smtp.vt.edu [198.82.183.121]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A56C922A for ; Thu, 27 Oct 2016 16:22:31 +0000 (UTC) Received: from mr6.cc.vt.edu (mr6.cc.vt.edu [IPv6:2607:b400:92:8500:0:af:2d00:4488]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id u9RGMUlg010641 for ; Thu, 27 Oct 2016 12:22:30 -0400 Received: from mail-pa0-f69.google.com (mail-pa0-f69.google.com [209.85.220.69]) by mr6.cc.vt.edu (8.14.7/8.14.7) with ESMTP id u9RGMOar006481 for ; Thu, 27 Oct 2016 12:22:30 -0400 Received: by mail-pa0-f69.google.com with SMTP id r13so26241835pag.1 for ; Thu, 27 Oct 2016 09:22:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=tFJF3XIgncuUL2tKsIdZc/xbgZq/Xy6IiF74g7UlEwc=; b=ThBXG6zc4G52Z+pO5+7Y7ITZcc+LlKk6r7V0jIJQAce0BFGyjE1P7tCnzavGpFLGer OWqVtLXLENW4Fm0VXJbOYJ7umTtuG5iADQtveah/XEbVUyxqmJWd5OkCn/7NdIF167Da OtUh2in/GlIKWg+pGojC6LJirmo1E5U93KGwr3HCi/w5fXumflxlM40wQg4QdiG7LR2w T1huzqTlMldfeAHLLySqQCMfeIo7Tt24cKTRKJecRDcnkK4Z3KtGJHtw7i4bAm03QlaQ jPECxVG9VWd1IVudDk0OD2mu7eZ2luRHonzUdugkCywt3Z6xKHJvoElF7lKiQQz9SMVl NHVA== X-Gm-Message-State: ABUngvcNF4NBVoLHnYILIDB5Zc9dLihr7dbKNrcKS2IdOUxUbY9XA1bZAUJOpilBdxhSqyKAzAEjAmgxr3ZNuQqOyqp6qNjSvXwpEHuP4wC50u8vu/RXTjFokWJto9wBf5WUw5cste69EHRnK9GI5O+qxVjQDlmQZzKp20iBysTf86NJgMKVm4Pw3nPmSkF7uuZqd6624b99u+AAvXuEAaA= X-Received: by 10.98.32.82 with SMTP id g79mr15881742pfg.142.1477585344395; Thu, 27 Oct 2016 09:22:24 -0700 (PDT) X-Received: by 10.98.32.82 with SMTP id g79mr15881684pfg.142.1477585344002; Thu, 27 Oct 2016 09:22:24 -0700 (PDT) Received: from Doug-Armory.local (c-24-22-123-27.hsd1.or.comcast.net. [24.22.123.27]) by smtp.googlemail.com with ESMTPSA id cp2sm12954688pad.3.2016.10.27.09.22.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2016 09:22:23 -0700 (PDT) To: Andrew , Bitcoin Discuss References: From: Douglas Roark Message-ID: <25040902-d057-8b58-b268-55b2b4579017@vt.edu> Date: Thu, 27 Oct 2016 09:22:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OxBlGgL9eeEmipWLod1j4putSl7bQwel2" X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] The Soft Fork Deception 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: Thu, 27 Oct 2016 16:22:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OxBlGgL9eeEmipWLod1j4putSl7bQwel2 Content-Type: multipart/mixed; boundary="9gS1209B55qfOmkFvQK5TkAjrcS26celW"; protected-headers="v1" From: Douglas Roark To: Andrew , Bitcoin Discuss Cc: Bitcoin Protocol Discussion Message-ID: <25040902-d057-8b58-b268-55b2b4579017@vt.edu> Subject: Re: [bitcoin-dev] The Soft Fork Deception References: In-Reply-To: --9gS1209B55qfOmkFvQK5TkAjrcS26celW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Am attempting to move this over to bitcoin-discuss, as this (IMO) isn't appropriate for dev and is borderline trolling. I won't be replying on dev beyond this reply. I'll also try to keep this reply technical in nature. (If this continues on discuss, no promises. :) ) On 2016/10/27 08:38, Andrew via bitcoin-dev wrote: > I have been reading recently through the history of soft forks provided= > by Bitcoin Core: > https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-re= cord-of-blockchain-soft-forks. That list is incomplete. https://www.reddit.com/r/Bitcoin/comments/2y4mq2/list_of_soft_and_hard_fo= rks/cp68q4q/ is closer to the reality of the situation and is probably still incomplet= e. > It has led me to think that there is a deceiving notion that soft forks= > do not force Bitcoin users to upgrade software. Yes, it's true that the= > past soft forks still allow old nodes to accept blocks under the tighte= r > rules as valid, but what about miners who are still using old software?= > What about users who want to make a transaction using the old rules? > Those people are no longer able to do those things. And if they want to= > do those things, a hard fork will result. I don't see a particularly strong movement rallying for the right to use sigs without strict DER, previously NOP opcodes that now do something, etc. I'd imagine that a soft fork that "truly" forced people to do things they didn't want would be much more controversial than SegWit. > Remember what happened when BIP 66 was activated? What, you mean miners who were deploying cheap hacks in order to eke out a bit more hashpower? They got what they deserved. > Obviously every one can debate about what should be the definition of a= > soft fork, but whatever that is, I think it is unacceptable how sloppil= y > the past soft forks have been deployed. I can think of many ways in > which we could have these new features that the soft forks provided, bu= t > without forcing the new rules, and simply making them features that can= > be used on an individual miner or transaction signer basis. Well then, lay it on us. If your idea is so great, people will come around to it eventually. As is, the only thing I can see is a load of switches that would cause the code to act in all manner of weird ways. New features would have to plan for every single possible use case, including bizarre use cases that should have no basis in reality. Congratulations. New feature deployment is now far more complicated, and Bitcoin, depending on one's viewpoint, will become further stuck in the mud feature-wise. > Now that Segregated witness is scheduled to be deployed on November 15,= > we should take a look at this "soft fork" as well. I like the idea of > Segregated Witness, but from conversations on Reddit and IRC, I see > people saying that this soft fork will be like the others: requiring a > hard fork in order to revert it. Is this true? I am getting conflicting= > messages by reading the BIP. It says that if all transactions are > non-segwit, then a node will validate the block as before. But if we > pass the threshhold (usually 95 % for 1000 blocks) will miners mining > non-segwit blocks be ignored? This is not good... I'd imagine that, if a block has zero SegWit Txes, everything will function as it did before. It's not like SegWit forces everyone to use SegWit when sending coins. It's just an optional method for sending coins= =2E > Now, we can't go back in time and fix the deployment of the soft forks,= > but I do propose one clean way to fix things: Remove all the previously= > "soft forked" rules for non segwit transactions, and require them only > for segwit transactions. But make segwit optional! In addition to what = I > talked about above, this may also relieve some tensions of people who > are not comfortable with segwit and are thinking of joining a hard fork= > like the Bitcoin Unlimited project. Can you clearly define all the rules that you will remove? Are you going to include things like the original OP_VER opcode (see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011= 938.html for why this would be, IMO, a bad idea)? What about the multi-byte opcodes (e.g., OP_PUBKEYHASH), which were hard forked off the network but were technically soft forks since nobody had actually used them on the network? > Unless people can give me a good explanation as to why we are deploying= > soft forks in such forceful manner, or Bitcoin Core accepts my proposal= , > then I will have no choice but to create a new client (I'm thinking to > call it Bitcoin Authentic), that will be just as Bitcoin Core but will > always follow the chain with the most work regardless of whether soft > fork rules are respected, and I would put at least CHECKLOCKTIMEVERIFY > as mandatory within segwit transactions. If you're going to create yet another Core fork, you'd better be sure to define just how "authentic" you want to be. I'm guessing you don't want the overflow output Tx fix (i.e., "the 92 billion Bitcoin bug") removed, but that one was arguably a soft fork too. Sure, Satoshi committed it and didn't even give the miners a chance to vote, but he still "forced" everyone to deploy it. If freedom =FCber alles is what you seek, you'll need to revert just about everything Satoshi included too, which will be difficult since a lot of his fixes have been drastically changed in the code (albeit in a manner where they still function as intended). --=20 --- Douglas Roark Cryptocurrency, network security, travel, and art. https://onename.com/droark joroark@vt.edu PGP key ID: 26623924 --9gS1209B55qfOmkFvQK5TkAjrcS26celW-- --OxBlGgL9eeEmipWLod1j4putSl7bQwel2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYEim+AAoJEEOBHRomYjkkwBEP+QHTsTwwA7zf2qjv7Sa3+PET /4dYWTJ/NYLSfWmoib8aEYPukWQp0NCd6aLumcLK3RiZGJUm0iAaJsWya9L1bUMB u+AmMAInNln9SewA+ho1cT3MurTJuBC8fKJck9hqR9dMORWD7WIzovwPdI0vby0H WT7SiE7wl8TqfmwPsR7lZrZPUmxzBqDqE152Cyrf3OJ3bkhGR11SFliAqTqm1G/G Tzj70pmlW1HwVw4eZfOeB3rRI8DYX9cmBBP31Wq48joc+dFJUFgTTPeHbuEjDLEj F3EaNsMHVMdew9jcJaFTd5jEAnr4FvmSdD+oiIgimjKmnq8+SffXQK2R33dbA4aI 09JDNXx0YC/+1SSYDtiUwImtT21TX/biePg6nvCvCR4J7zRW1CVzYjGlpIidJxSQ 1nrK9EWjCybHCnL/tsLCwJThLnocB100itrt+qzhzO72yJyzmmFGmBtqt6xAz8K3 c449WHHBYHSvmO+9qrZ8QNb0WCVx03jZkeIY6jzHdD3I3gTYVfg2tRGMHOfGHPxs j0RPEiR8bIonlHIdQyqE2SuUX6/TabHnyyw77zHcYsYiFulbe30XK31giXf73xFC YqS1Y6UCo9S9KFCpgjcxsIga54wRIaoS+jdkUSgem0SMxAFvFeqi3Z05o1ONpp4m DjJfzRExaB1jXpHP5zhO =tQgo -----END PGP SIGNATURE----- --OxBlGgL9eeEmipWLod1j4putSl7bQwel2--