diff options
author | Achow101 <achow101-lists@achow101.com> | 2018-07-06 14:59:50 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-07-06 19:00:02 +0000 |
commit | 6f9beb828d56254f22782eeee2412fa0019deb3c (patch) | |
tree | 293b743c3c61cdc6dbc37f0d3f3d56c2123338ef | |
parent | 8d2dfdd1ae60450ac1d845228e8ae301883aab79 (diff) | |
download | pi-bitcoindev-6f9beb828d56254f22782eeee2412fa0019deb3c.tar.gz pi-bitcoindev-6f9beb828d56254f22782eeee2412fa0019deb3c.zip |
Re: [bitcoin-dev] BIP 174 thoughts
-rw-r--r-- | 97/2cd5634a134708c368659b1d60e925ccb8eb3b | 149 |
1 files changed, 149 insertions, 0 deletions
diff --git a/97/2cd5634a134708c368659b1d60e925ccb8eb3b b/97/2cd5634a134708c368659b1d60e925ccb8eb3b new file mode 100644 index 000000000..5cf52cec0 --- /dev/null +++ b/97/2cd5634a134708c368659b1d60e925ccb8eb3b @@ -0,0 +1,149 @@ +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 AD628C94 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 6 Jul 2018 19:00:02 +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 54B60E2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 6 Jul 2018 19:00:01 +0000 (UTC) +Date: Fri, 06 Jul 2018 14:59:50 -0400 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; + s=protonmail; t=1530903597; + bh=sokThW+qH7O0GSpN56m4KXcOugEF+IBluOAqjqZcp68=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: + Feedback-ID:From; + b=mIfQ7qpRmLffEZTM3a38oOPAeB+YpSGAzVPzUr/kySKxzT2ixX/EUm1ID95z5xCQ+ + RVH2Gi5AWW91LAi9WZt/rWa7yChYwP9MPtBUI7FUIIA+cfVQ2bOJ7TR3AU/Xx123In + bREaIpmNwJWi4HhKnJVWO/AvemdIfyMRX686SzbU= +To: William Casarin <jb55@jb55.com> +From: Achow101 <achow101-lists@achow101.com> +Reply-To: Achow101 <achow101-lists@achow101.com> +Message-ID: <rLAEe3CQTgqUy2RbJ3hiSotoHbIRt3fKZ4sKYmVbVoh29MTvd0yLGy7bySq1KbMOpgxvixFpwU8evLc1XxK7itMEM_KyxLeYPxGQJE64LE8=@achow101.com> +In-Reply-To: <87in5ttrpb.fsf@jb55.com> +References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com> + <CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com> + <ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com> + <f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com> + <TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com> + <c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com> + <J0KV-aP96fSVHPkPw85N2qdKV_F5vqXt5fIFwKDp9wBjRKJ6bZpUEtzbgHyxlWW9PCXMOEVZnyUnJ-kW281ZbblbCp2sbZI_UyTP46q-PiY=@achow101.com> + <87k1qk7oca.fsf@jb55.com> <87in5ttrpb.fsf@jb55.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: Fri, 06 Jul 2018 19:00:02 -0000 + +Hi, + +=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= +ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 + +On July 5, 2018 12:20 PM, William Casarin <jb55@jb55.com> wrote: + +> =E2=80=8B=E2=80=8B +>=20 +> I have another concern with the format. (my original bip comment for some= + context: [1]) +>=20 +> It looks like the one of the reasons I was confused is because you can +>=20 +> only parse the format properly by first deserializing the transaction. +>=20 +> Since there is no "length" field for the key-value map arrays, you must +>=20 +> count the number of transaction input/outputs, and use that as the +>=20 +> number of kv maps to parse. + +I don't think this is really a problem. + +Almost all roles have to deserialize the unsigned tx anyways before they ca= +n do anything. +The only role that doesn't is a simple combiner (a combiner that does sanit= +y checks would +still have to deserialize the unsigned tx), and even then it doesn't matter= +. It just shoves +key value pairs together and doesn't need to know whether the map is for an= + input or for +an output. + +>=20 +> This is pretty brittle, because now if a Combiner writes the wrong +>=20 +> number of key-value maps that don't align with the number of inputs and +>=20 +> outputs in the transaction, then the psbt will not be able to be +>=20 +> deserialized properly, but is still a valid PSBT. It can't even detect +>=20 +> these situations, because the input and output types share the same enum +>=20 +> values.=20 + +If a combiner writes the wrong number of key-value maps, then it would simp= +ly be invalid +to the next person that receives the PSBT. It would not deserialize properl= +y because the +key value pairs would have incorrect values for their types. Not deserializ= +ing properly means +that the PSBT is simply invalid. The same numerical types might +be shared, but their meanings are different between the input and output ty= +pes. + +I don't see anywhere that says the number of key value maps MUST +>=20 +> match the number of inputs/outputs, perhaps it's implied? + +I have added that to the BIP. + +=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= +ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 + +On July 5, 2018 10:23 AM, Jason Les <jasonles@gmail.com> wrote: + +> Has there been any thought to standardizing file names used when creating= + .psbt files? Maybe something that gives some reliability of being collisio= +n resistant and descriptive. For example: +>=20 +> [8 char trim of hash of unsigned tx]+[Role that created file (Ex: Signer)= +]+[4 char trim of hash of data unique to that role (Ex: partial sig)] +>=20 +> It may be useful to especially the combiner to have some idea of what fil= +es they have. +>=20 +> -Jason Les + +I haven't considered this, but I'm not sure if it is really useful. I don't= + think it is really necessary +for any role to know who created the PSBT. If it did, this information woul= +d generally come +out-of-band anyways as someone has to give the PSBT to that person. + + + +Andrew + + + |