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 CDF01D0A for ; Wed, 4 Jul 2018 19:09:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3CD4978F for ; Wed, 4 Jul 2018 19:09:32 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id w126-v6so12439097oie.7 for ; Wed, 04 Jul 2018 12:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=smRrOI2SDkVyTYyHBKpQL7+OmHdkY9BfWyZgWBPs2Ug=; b=tk0CdQhFNIAwr3e25EWudNW3GPXYUtLshOI/lacrjjHCvlcGBhRGuIlAITaUJf3of3 w1mlnPnbjKd3bvQRy2HFdigag/6xo9HFNuuHJF3zbTquIigcQjSEKbiE2B07ucmO7uqv rtIkLm3618QMYMA+heqAmNAXYOLXtdKUEqQFaLtak4SaqOjHvFndQTENnQW4FHXB9Mca ZFlBFIFRcYm4w+iA3xcBTKUxmwFaDvduJ+GvPbVHTi/4pUkyvCsLPo6Y84qvCw5EvolX DBA1+CQFhF5SL4Nypi3xRvtTbxjaR9J6UTdL2dT3muQXRYsj5Eev6AdNfYGVAVFsk4M4 UDnQ== 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=smRrOI2SDkVyTYyHBKpQL7+OmHdkY9BfWyZgWBPs2Ug=; b=Uemb3/XMKN0HHrZb4czog6ia0+OpvrVudrY6K2icj8HomVC5OSmv6lfMBPhOZPuKNs FecrQ8tjT7N6KRx8xvAWBqaz51XJj/u22/Q134BwQBWqGBpv6b7aOCrIFv9sR/pRWJ16 TDq7cLgYK/INUrzX9eUxNHLCTyrdUSIZ7DaoEL0+3HPD3J4pWckPcqm11dRuSW9dNCDO m6MBZAPEs1fD+tccrR1MBf6h/P79gyUeuyYnDBlZ7zACnRCrew1TdBiETHjIgZbbULkX N3ZaAjU5foJ/0FNrE1zF/KkD3ivRgH0k1Ex9pN7WGEcrsrypcy5ydnSqK5GutMZs+2m8 65fQ== X-Gm-Message-State: APt69E28ErqOVSgNG85LVHFQZP58fqN5R1OOZ8LGgLvZlgh6Z1jcKDxI pFzg8+IKPGbkc5Hah5PzY8JIxXa1IIBr1rNmhS9C0Q== X-Google-Smtp-Source: AAOMgpdjwdD1hsHNYMt51AfnpeVDV+y4jwG36BKH8HE08wD9o7t7r8V+BF/HqyKPdjWKOxLNFVA32erc2uUMQGK9+aw= X-Received: by 2002:aca:670c:: with SMTP id z12-v6mr3582972oix.76.1530731371258; Wed, 04 Jul 2018 12:09:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 12:09:29 -0700 (PDT) In-Reply-To: References: <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> From: Pieter Wuille Date: Wed, 4 Jul 2018 12:09:29 -0700 Message-ID: To: matejcik Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 Cc: Bitcoin Protocol Discussion 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, 04 Jul 2018 19:09:32 -0000 On Wed, Jul 4, 2018 at 6:19 AM, matejcik wrote: > hello, > > we still have some concerns about the BIP as currently proposed - not > about the format or data contents, but more about strictness and > security properties. I have raised some in the previous e-mails, but > they might have been lost in the overall talk about format. > > * Choosing from duplicate keys when combining. > We believe that "choose whichever value it wishes" is not a good > resolution strategy. We propose to either change this to "in case of > conflicts, software MUST reject the conflicting PSBTs", or explain in > more detail why picking at random is a safe choice. Outlawing conflicting values would imply forcing all Signers to implement fixed deterministic nonce generation, which I don't think it very desirable. Otherwise PSBTs that got copied and signed and combined again may fail. So I think we should see it the other way: we choose the keys in such a way that picking arbitrarily is safe. If there really is a future extension for which it would not be the case that picking arbitrarily is acceptable, more data can be moved to the keys, and leave the actual resolution strategy to the Finalizer. That way Combiners can remain dumb and not need script-specific logic in every interaction. An alternative would be to have a fixed resolution strategy (for example, when combining multiple PSBTs, pick the value from the first one that has a particular key set), but I don't think this adds very much - if picking the first is fine, picking a arbitrary one should be fine too. > * Signing records with unknown keys. > There's been some talk about this at start, but there should be a clear > strategy for Signers when unknown fields are encountered. We intend to > implement the rule: "will not sign an input with any unknown fields > present". > Maybe it is worth codifying this behavior in the standard, or maybe > there should be a way to mark a field as "optional" so that strict > Signers know they can _safely_ ignore the unknown field. Can you envision a situation in which this is needed? In every scenario I can come up with, the worst that can happen is that the resulting signature is just invalid. For example, if PSBT existed before segwit, and then was later extended to support it, a pre-segwit signer would not recognize that BIP143 would need to be used for segwit inputs, and produce signatures using the old sighashing algorithm. The result is just an invalid signature. I believe that what you're trying to accomplish is preventing signing something you don't understand, but that's an independent issue. Signers generally will want to inspect the transaction they're signing, or ask for confirmation w.r.t. fees or payment destinations involved. The case where unknown fields are present for a reason you'd want to withhold signing for will generally also just be the situation where you don't understand the transaction you're signing. Here is (perhaps far fetched) example of why it may not be desirable to reject unknown fields when signing. Imagine an extension is defined which adds pay-to-contract derivation for keys (Q = P + H(Q||C)G); this would be a field similar to the current BIP32 derivation one, but instead give a base key P and a contract C. Now say there is a 2-of-2 multisig in which you're one signer, and the other signer is (unknown to you) using P2C. After the other party Updating, the input would contain a P2C field which you don't understand - but it also isn't something you care about or affects you. I would not be opposed to having fields with an explicit flag bit that says "Don't sign if you don't understand this", but I expect that that can also be left for future extensions. > * Fields with empty keys. > This might be inferred from the definition, but is probably worth > spelling out explicitly: If a field definition states that the key data > is empty, an implementation MUST enforce this and reject PSBTs that > contain non-empty data. > We suggest adding something to the effect of: > "If a key or value data in a field doesn't match the specified format, > the PSBT is invalid. In particular, if key data is specified as "none" > but the key contains data beyond the type specifier, implementation MUST > reject the PSBT." > (not sure about the languge, this should of course allow processing > unknown fields) Completely agree here. Any implementation that understands a particular field must enforce whatever structure the field is known to have. > * "Combiner can detect inconsistencies" > Added in response to this comment [1], the current wording looks like > it's describing what the Combiner is _capable of_, as opposed to > prescribing what the combiner is _allowed to_ do. > We suggest changing to something like: > "For every field type that the Combiner understands, it MAY also refuse > to combine PSBTs that have inconsistencies in that field, or cause a > conflict when combined." Agree, just because Combiners are expected to work correctly on unknown fields doesn't mean they can't enforce extra consistency checks on known fields. Cheers, -- Pieter