summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAchow101 <achow101-lists@achow101.com>2018-07-04 14:35:16 -0400
committerbitcoindev <bitcoindev@gnusha.org>2018-07-04 18:35:23 +0000
commite3826b4c897d774a41bf0b1a84a26737010ff365 (patch)
tree33e028a095074e44c85f3dee563b6b267b8d398e
parentb831e6c03cdd91cca017da66e87fd019e6db9a29 (diff)
downloadpi-bitcoindev-e3826b4c897d774a41bf0b1a84a26737010ff365.tar.gz
pi-bitcoindev-e3826b4c897d774a41bf0b1a84a26737010ff365.zip
Re: [bitcoin-dev] BIP 174 thoughts
-rw-r--r--5a/7d4dbaecbb4707b848a84c01a837019cb946fa203
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
+