Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AD628C94 for ; 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 ; 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 From: Achow101 Reply-To: Achow101 Message-ID: In-Reply-To: <87in5ttrpb.fsf@jb55.com> References: <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 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: 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 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 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