summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAchow101 <achow101-lists@achow101.com>2018-07-06 14:59:50 -0400
committerbitcoindev <bitcoindev@gnusha.org>2018-07-06 19:00:02 +0000
commit6f9beb828d56254f22782eeee2412fa0019deb3c (patch)
tree293b743c3c61cdc6dbc37f0d3f3d56c2123338ef
parent8d2dfdd1ae60450ac1d845228e8ae301883aab79 (diff)
downloadpi-bitcoindev-6f9beb828d56254f22782eeee2412fa0019deb3c.tar.gz
pi-bitcoindev-6f9beb828d56254f22782eeee2412fa0019deb3c.zip
Re: [bitcoin-dev] BIP 174 thoughts
-rw-r--r--97/2cd5634a134708c368659b1d60e925ccb8eb3b149
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
+
+
+