diff options
author | Achow101 <achow101-lists@achow101.com> | 2018-07-04 14:35:16 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-07-04 18:35:23 +0000 |
commit | e3826b4c897d774a41bf0b1a84a26737010ff365 (patch) | |
tree | 33e028a095074e44c85f3dee563b6b267b8d398e | |
parent | b831e6c03cdd91cca017da66e87fd019e6db9a29 (diff) | |
download | pi-bitcoindev-e3826b4c897d774a41bf0b1a84a26737010ff365.tar.gz pi-bitcoindev-e3826b4c897d774a41bf0b1a84a26737010ff365.zip |
Re: [bitcoin-dev] BIP 174 thoughts
-rw-r--r-- | 5a/7d4dbaecbb4707b848a84c01a837019cb946fa | 203 |
1 files changed, 203 insertions, 0 deletions
diff --git a/5a/7d4dbaecbb4707b848a84c01a837019cb946fa b/5a/7d4dbaecbb4707b848a84c01a837019cb946fa new file mode 100644 index 000000000..236532ef7 --- /dev/null +++ b/5a/7d4dbaecbb4707b848a84c01a837019cb946fa @@ -0,0 +1,203 @@ +Return-Path: <achow101-lists@achow101.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 707FBD69 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <jan.matejek@satoshilabs.com> +From: Achow101 <achow101-lists@achow101.com> +Reply-To: Achow101 <achow101-lists@achow101.com> +Message-ID: <7cIbglgQM_K07YQ3dgHTMIQwC_7OXa9DeqFquUZyfuM7HnliTUiIQZuJzo753ICjzUhqh5qLKPbGBVtGGrUT5DvkB7p3YQZePDEtiWd5Xs4=@achow101.com> +In-Reply-To: <c7a4476b-8643-3ddd-723b-1ff8b8910e36@satoshilabs.com> +References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com> + <TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com> + <c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com> + <CAPg+sBhhYuMi6E1in7wZovX7R7M=450cm6vxaGC1Sxr=cJAZsw@mail.gmail.com> + <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> + <CAPg+sBg4MCOoMDBVQ2eZ=p3iS3dq506Jh4vUNBmmM20a6uCwYw@mail.gmail.com> + <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> + <RdSjdFhvANrG9ve8bXVnqs68ih5_iVK11jdOAL6WoMI2358TdylR3H2SyGHQfByKwMYYOfIJIOq0l6clYf-az8_D_D-D7cByzqbyYt1nV4c=@achow101.com> + <c7a4476b-8643-3ddd-723b-1ff8b8910e36@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 <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jan.matejek@satoshilabs.com> 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 + |