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 16AACC9E for ; Wed, 13 Mar 2019 00:54:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9AA1582B for ; Wed, 13 Mar 2019 00:54:36 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id b20so3892785edw.11 for ; Tue, 12 Mar 2019 17:54:36 -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:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Zs1eGAjTlXb4hW3kM7nxZvE3YncsuTfak2qaRpVUSdU=; b=TLbsKe6+/QeC/O64K52dmWLJGLMcStR9+E37suiBJ5Hgb1v+urHV5ENQg3shBNoa2x b92Rly0QecS8OrfnHAr015ENF/wfDdVgtF/PmYndkkKr34xSHGcUIhqHcc8BgKgHU7ul EjDh1H9COJNESzcwDgqGcERkh4pdGj8uk37ztt8lTv6m4GGjt+Lcgz/Fp2cAqeV+7T4e VPIVqGzFL9jeTKKHezyr4AUEL5yU4NddWTuns4bsi2J/RAZNV8R+Wy6OAw9xh4khPvm4 ogbegae/IPuQRKZ0CPouyXKG/ASlnRFumPL4RtfYHfocKLXZYAMSVpMspk2NnW26Fihs MauQ== X-Gm-Message-State: APjAAAX25g3ICCnN1A5Ulb+yo/D9OvxAMnP6tGVWLQnYHNJg/N+VFoV9 wpyMOHIEPzYpS4C2xUdiMFY+tAmxsoXuYCL0lVluEQ== X-Google-Smtp-Source: APXvYqx81BIudJIWaDz5tMJ6CdHDJ+GxO6ZsZc6EGfWZIAkH/LN9EwN/UJqkaGA1f6rPsr7oWCNt3AKyIvm6+L4jfO4= X-Received: by 2002:a17:906:6c12:: with SMTP id j18mr26007475ejr.99.1552438475214; Tue, 12 Mar 2019 17:54:35 -0700 (PDT) MIME-Version: 1.0 References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> <88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com> In-Reply-To: From: Gregory Maxwell Date: Wed, 13 Mar 2019 00:54:23 +0000 Message-ID: To: Jacob Eliosoff , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE 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: Wed, 13 Mar 2019 06:45:58 +0000 Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup 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: Wed, 13 Mar 2019 00:54:38 -0000 On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev wrote: > Also, if future disabling isn't the point of making a tx type like OP_COD= ESEPARATOR non-standard - what is? If we're committed to indefinite suppor= t of these oddball features, what do we gain by making them hard to use/min= e? It makes them infeasible to abuse without miner assistance... which doesn't fix them, but in practice greatly reduces the risk they create and allows efforts improving the system to be allocated to other more pressing issues. > I see questions like "Is it possible someone's existing tx relies on this= ?" as overly black-and-white. We all agree it's possible: the question is = how likely, vs the harms of continued support - including not just security= risks but friction on other useful changes, safety/correctness analyses, e= tc. Don't underestimate the value of taking a principled position that *strongly* avoids confiscating user funds. Among many other benefits being cautious about this avoids creating a situation where people are demanding human intervention to restore improperly lost funds and the associated loss of effort that would come from the effort wasted debating that. It's true that most other cryptocurrencies proceed without any such caution or care-- e.g. bcash recently confiscating all funds accidentally sent to segwit using Bitcoin addresses because of their reckless address aliasing as a result of promoting the standardness rule that made those txn non-standard before segwit without considering the implications--, but they're not the standard we should hold Bitcoin to... > Again, the point being not to throw caution to the wind, but that a case = like this where extensive research unearthed zero users, is taking caution = too far. All things in balance: Codeseperator and its related costs are not an especially severe problem. The arguments on both side of this point have enough merit to be worth discussing, at least.