From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 626F2BC6 for ; Wed, 27 Jun 2018 13:39:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 737F1619 for ; Wed, 27 Jun 2018 13:39:07 +0000 (UTC) Date: Wed, 27 Jun 2018 09:39:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1530106744; bh=pSGeimGqM9G79v5uMprhJuzoT7uXDSbiOoQXSbpYAy0=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=rjBIGkfY6b591popCr4vNqKWIq57Y1txVb0VdO/HpaDXrZx9W2C/9Ax/soRrWvlOW sUFwbhujQ0I0fvB7G518v6Xf5P7Nvqo7DmA4446AXKHIz7vSvQ1SXIs1gkifpeLEAQ N5LMiiMpde+Op9hq2Zp0e5Y3/ILwraTZ/+2wv91U= To: William Casarin , Bitcoin Protocol Discussion From: Andrea Reply-To: Andrea Message-ID: In-Reply-To: <87k1qk7oca.fsf@jb55.com> References: <20180621195654.GC99379@coinkite.com> <87k1qk7oca.fsf@jb55.com> Feedback-ID: x-YXDi3m_TiFBHTDMZypFbA_HjfCQuhNiwHDBR0xli2NzJKdIoqs25GtJLT5wHvl0eyVBeRQs8LMD0l_SOtUrQ==: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, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Wed, 27 Jun 2018 13:42:06 +0000 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: Wed, 27 Jun 2018 13:39:08 -0000 Hi William, Andrew, list, As noted by William there are some types missing in the global-types defini= tion, because the number of each map for I/O must be known to the parser in= order to use the correct definitions for the types. At the moment a parser= reading a key-value record does not know whether it should read it as per-= input type or per-output, a way to address this is to declare in advance th= e number of maps and ensure they are ordered (inputs first). If you haven't= already worked out some types for that i propose using: Number of inputs - key (None, only the type): PSBT_GLOBAL_INPUT_NUMBER =3D 0x01 =20 - value: Varint=20 Number of outputs - key (none, only the type): PSBT_GLOBAL_OUTPUT_NUMBER =3D 0x02 - value: Varint On another note I think we can set a hard limit on the size of the PSBT, cu= rrently is 'legal' to produce a very large PSBT with an excessive number of= Inputs and Outputs. By excessive I mean that even in the best case scenari= o (using the smallest possible scriptPubKey as in P2WPKH) it is possible to= create a PSBT that would certainly create an invalid transaction (because = of its size) when finalized. I haven't found anything related to this in th= e previous discussions, please ignore this if it was already proposed/discu= ssed. Cheers, Andrea. =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 June 27, 2018 8:09 AM, William Casarin via bitcoin-dev wrote: > =E2=80=8B=E2=80=8B >=20 > Hey Andrew, >=20 > If I'm reading the spec right: the way it is designed right now, you >=20 > could create hundreds of thousands of zero bytes in the input or output >=20 > key-value arrays. As far as I can tell this would be considered valid, >=20 > as it is simply a large array of empty dictionaries. Is this right? I'm >=20 > worried about buffer overflows in cases where someone sends a large blob >=20 > of zeros to an unsuspecting implementation. >=20 > Also, the extensibility section reads: >=20 > > Additional key-value maps with different types for the key-value pairs > >=20 > > can be added on to the end of the format. >=20 > "different types for the key-value pairs", is this referring to new >=20 > types beyond the current global, input and output types? >=20 > > The number of each map that follows must be specified in the globals > >=20 > > section >=20 > Is this out of date? Since there is only one type in the global section >=20 > now (tx). >=20 > > so that parsers will know when to use different definitions of the > >=20 > > data types >=20 > I'm not sure what this means. >=20 > Thanks! >=20 > Will >=20 >=20 > ------------------------------------------------ >=20 > https://jb55.com >=20 > bitcoin-dev mailing list >=20 > bitcoin-dev@lists.linuxfoundation.org >=20 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev