Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 707FBD69 for ; Wed, 4 Jul 2018 18:35:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-1857040132.protonmail.ch (mail-1857040132.protonmail.ch [185.70.40.132]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A24F779A for ; Wed, 4 Jul 2018 18:35:22 +0000 (UTC) Date: Wed, 04 Jul 2018 14:35:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1530729320; bh=iCf8GLvGcVJzXIumGW5jpFm9KWngu+YY8cjpDRK1UrY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=PwTIbCMt+yjVwdGAEQaGfb9PzXWa5SfGvPcwjDBip6Q4YZ0NF32gwH0dlo8bt6KwX nGCx2/YmwL6RbOVpIpPlCQhOHvhlJ8o7jOFPILM4bVdMMb6dZD+ZouKMiZi9dU3odS F3s6IRp6qiRur67pUaPkeUcn9Zdtgm31IJiOCT8k= To: matejcik From: Achow101 Reply-To: Achow101 Message-ID: <7cIbglgQM_K07YQ3dgHTMIQwC_7OXa9DeqFquUZyfuM7HnliTUiIQZuJzo753ICjzUhqh5qLKPbGBVtGGrUT5DvkB7p3YQZePDEtiWd5Xs4=@achow101.com> In-Reply-To: References: <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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 18:35:23 -0000 Hi,=E2=80=8B On July 4, 2018 6:19 AM, matejcik wrote: > =E2=80=8B=E2=80=8B >=20 > hello, >=20 > we still have some concerns about the BIP as currently proposed - not >=20 > about the format or data contents, but more about strictness and >=20 > security properties. I have raised some in the previous e-mails, but >=20 > they might have been lost in the overall talk about format. >=20 > - Choosing from duplicate keys when combining. > =20 > We believe that "choose whichever value it wishes" is not a good > =20 > resolution strategy. We propose to either change this to "in case of > =20 > conflicts, software MUST reject the conflicting PSBTs", or explain in > =20 > more detail why picking at random is a safe choice. You cannot simply reject PSBTs for having conflicting values for the same k= ey. Especially for the Partial Signatures, you can have two signatures for the same pubkey= that are both completely valid. This situation could happen, for example, if a signer tha= t does not use deterministic k values can sign multiple inputs but one input is missing a UTXO so it doe= sn't sign it. So it receives one PSBT and signs the first input but not the second. It receives a PSBT = for the same transaction which has the second input's UTXO but does not have its signatures for the = first input. The signer would sign both inputs. When the two PSBTs are combined (suppose the first = PSBT has other=20 signatures too), you will have two keys that have different values. The dif= ferent values are both valid signatures, just with different k values since they were randomly gen= erated instead of deterministically. If we fail to merge these, then you could potentially ha= ve a situation where nothing can be done with the PSBTs now, or now everyone has to resign and i= n some specific order to avoid the conflict. That complicates things and is much more annoy= ing to deal with. So a simple solution is to allow the combiner to choose any value it wants = as it is likely that both values are valid. Allowing combiners to choose any value also allows for intelligent combiner= s to choose the correct values in the case of conflicts. A smart combiner could, when combi= ning redeem scripts and witness scripts, check that the redeem scripts and witness scripts matc= h the hash provided in the UTXO (or in the redeem script) and choose the correct redeem script = and witness script accordingly if there were, for some reason, a conflict there. Can you explain why it would be unsafe for combiners to arbitrarily choose = a value? > =20 > - Signing records with unknown keys. > =20 > There's been some talk about this at start, but there should be a cle= ar > =20 > strategy for Signers when unknown fields are encountered. We intend t= o > =20 > implement the rule: "will not sign an input with any unknown fields > =20 > present". > =20 > Maybe it is worth codifying this behavior in the standard, or maybe > =20 > there should be a way to mark a field as "optional" so that strict > =20 > Signers know they can safely ignore the unknown field. I think that requiring there to be no unknowns is a safe change. > =20 > And two minor points: > =20 > - Fields with empty keys. > =20 > This might be inferred from the definition, but is probably worth > =20 > spelling out explicitly: If a field definition states that the key da= ta > =20 > is empty, an implementation MUST enforce this and reject PSBTs that > =20 > contain non-empty data. > =20 > We suggest adding something to the effect of: > =20 > "If a key or value data in a field doesn't match the specified format= , > =20 > the PSBT is invalid. In particular, if key data is specified as "none= " > =20 > but the key contains data beyond the type specifier, implementation M= UST > =20 > reject the PSBT." > =20 > (not sure about the languge, this should of course allow processing > =20 > unknown fields) Agreed. > =20 > - "Combiner can detect inconsistencies" > =20 > Added in response to this comment [1], the current wording looks like > =20 > it's describing what the Combiner is capable of, as opposed to > =20 > prescribing what the combiner is allowed to do. > =20 > We suggest changing to something like: > =20 > "For every field type that the Combiner understands, it MAY also refu= se > =20 > to combine PSBTs that have inconsistencies in that field, or cause a > =20 > conflict when combined." Agreed. Andrew