Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 77C8F11E7 for ; Wed, 11 Jul 2018 20:05:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com [209.85.217.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1E23772 for ; Wed, 11 Jul 2018 20:05:34 +0000 (UTC) Received: by mail-ua0-f176.google.com with SMTP id t14-v6so16995407uao.8 for ; Wed, 11 Jul 2018 13:05:34 -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=4VQFrtwHA1cKnJk1HvAGL+r9lQ2KSGn9fgQW51037Hc=; b=ri12L1u0ocopChYCS+95xb8gLrPgIcDsmlHJSidlfaZblVsLTNHrWB9f6jVgQJF7G6 +SzsSMoER8X9QOyoBN5KBc+NdOcoK3Hu6TjdFm3ikqkf9uiSdsWAAnSJ4sfdGJyLoDT1 0Jryw2AV5KdKQWRoRMxRGKIsOCUfCAK8N15Acl9iygLiHx+Eo4CrgmBnMwRoABiDfGWg G/wpS1TBSFDj1gDjgnCwq3GCLSWkTlXNGniwj7JduqDJ5VUmjj7e+WcUDzh0gpQwtFpy XdMiCuPNlCp/Ke9WxGEY9AWDpXs+AxRW+yj8c+3/Ya4FFrW/MKQV9w5m8+H5yrLM6gFa V36g== 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=4VQFrtwHA1cKnJk1HvAGL+r9lQ2KSGn9fgQW51037Hc=; b=q0KHEq4jywKyrG9Z2eR2OyjHJLIRKb10b5lc1jVoVjCbch93vvzsYNKwdymgsF44WO neXGSxIJyV0nh7UUj1fuDwQMfF2bAaKOd2wYhn6zUfApNPGbIJRTMpbeFSW+7RrA4E9n VXX144E2M2Dmw6CiQ04vdlfYxxqLPMTGtMH+rB7xnt2DghQ6azmX684WyQyHVtYZIr+n JuscL8V8R7Vj2QYxCKVLzy51Y2D6lm4h0p1us8NKQXJ4RmGD0OkmUNaX+vbOrn8/U5oi 1KTEwyoARBj3YnqS6MoVcZD0FgF1eaYPpHvKCQVRhsd6Dlbj27hKjpm/pKYDk4hmjEzT USBw== X-Gm-Message-State: AOUpUlE13+3JvKgihOjsIFDEj/AsqzvqmSlHtQtrgb635VP4eziqZydf QFa29B0D0CAIbyhcp0aZ9wHxY7GeLQ3RK+QCnq8= X-Google-Smtp-Source: AAOMgpfcyQz8pywOwUbN8gB68BUQbbkFbRVPuz/+bAnquTQ6Q4Ia4T2n27+xWL8Mc8y7CSPYpdva7zWv9J/cH3aB0FQ= X-Received: by 2002:ab0:5cc7:: with SMTP id z7-v6mr37473uaf.107.1531339533955; Wed, 11 Jul 2018 13:05:33 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 2002:a67:51c9:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 13:05:32 -0700 (PDT) In-Reply-To: References: <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> <797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com> From: Gregory Maxwell Date: Wed, 11 Jul 2018 20:05:32 +0000 X-Google-Sender-Auth: Ye7dcGoW4F0ft8ixBxwkcPGP7J4 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 Subject: Re: [bitcoin-dev] BIP 174 thoughts 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, 11 Jul 2018 20:05:35 -0000 On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev wrote: > I don't think that's a particularly useful policy, but certainly > Signers are allowed to implement any policy they like about what they > accept in signing. Do we really want the specification to permit conforming implementations to refuse to sign because there is extra metadata? ISTM this would make it very hard to implement new features that require extra data. For example, say you have a checkmultisig with one key in it using schnorr multisignature which require the extra rounds to establish an R, and the other keys are legacy stuff. If the other signer(s) suddenly stop working when there are extra fields irrelevant to them, then this will create a substantial pressure to not extend the PSBT in the intended way, but to instead find places to stuff the extra data where it won't interfere with already deployed signers. This would be really unfortunate since PSBT was created specifically to avoid field stuffing (otherwise we could have accomplished all the intended goals by field stuffing a bitcoin transaction encoding). Obviously no signer should be signing data they don't understand, but extra data that they ignore which doesn't change their signature should not stop them. Another way of looking at it, perhaps somewhere someplace some idiot defined signatures starting with 0xdead to give away all the users funds or whatever. That's something you "can't understand" either, ... but no one would conclude because something could happen somewhere that you don't know about that you just can't sign at all... yet it is possible. :) If someone wants to make a non-conforming signer, that is cool too and they may have good reason to do so-- but I think it would be sad if new applications get gunked up, slowed down or forced to use ugly hacks, due to the intentional extension support in the protocol being blocked by things claiming to support the spec. The whole reason the spec doesn't lock in exactly the possible fields and allow no others is to allow extensions without breaking compatibility.