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 294CF2C for ; Sun, 24 Jun 2018 08:28:33 +0000 (UTC) X-Greylist: from 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 5C4CE12E for ; Sun, 24 Jun 2018 08:28:32 +0000 (UTC) Date: Sun, 24 Jun 2018 04:28:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1529828910; bh=h/Nej394J4XTeHVNmL1CaDlnuL/xTyAfAYvvUH7HnAs=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=Racsdr1aOdeAZXqC6k4pv+MWCU53k53uV1XxaUsd24qorhQwvTYMXwO9OkRwldRkx hc3rdowDRK/BAx7sw6lVBW5FjAHWmcubgvK/ud5GCyUafGVdoUIr+mhP6nSEU0MeIk 5osQy+yXO9kVmrHQykd13v1HBguYnvTNXgZFobxc= To: Andrea , Bitcoin Protocol Discussion From: Andrew Chow Reply-To: Andrew Chow Message-ID: <4BLLfQQ5BFO3Z2E2NagJ5trtBmdr6if2KSR9gWpYQY2xKu6THdvk0LJbkRxr8Yie2HA17KOZIM2ljupV_H8cfVkGFFcRjOrA0b13KG9ciF4=@achow101.com> In-Reply-To: References: <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com> <20180621195654.GC99379@coinkite.com> <87zhzlbfq5.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 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: Sun, 24 Jun 2018 08:28:33 -0000 I disagree with the idea that global types can be removed. Firstly, it is less of a breaking change to leave it there than to remove it entirely. Secondly, there may be a point in the future where global types would be useful/necessary. By having it still be there, we allow for future extensibility. Andrew On 06/24/2018 01:19 AM, Andrea wrote: > Hi,=20 > > I think in the revised spec we can remove completely the "global types" a= s a map or even as typed record. Since there is only one type (the transact= ion) and it's compulsory to have one (and only one) we could just drop the = definition of global type and the key associated with it, simply after the = header + separator there must be a transaction.=E2=80=8B=E2=80=8B Having re= ad all the discussion i also agree having per-input key derivation and per-= output data is a lot more handy for signers, no special feeling regarding t= he encoding.Looking forward for the test vectors and the new spec. > > Cheers, Andrea. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > > On June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev wrote: > >> =E2=80=8B=E2=80=8B >> >> On 06/23/2018 10:00 AM, William Casarin wrote: >> >>> Since we're still considering the encoding, I wonder if it would be a >>> >>> good idea to have a human-readible part like lightning invoices[1]? >> I don't think that is necessary. >> >>> Then perhaps you could drop the magic code as well? >> The magic is still necessary for the binary format in order to prevent >> >> normal transaction deserializers from accidentally deserializing a psbt. >> >>> Also we could do a base encoding that excludes + and / characters, such >>> >>> as base62 (gmp-style). It's easier to copy/paste (double clicking a >>> >>> string stops at / or + in base64 encodings). >> While that would be ideal, I think it is better to use an encoding that >> >> most wallets already support. Most wallets already have Base64 decoding >> >> available so that they can decode signed messages which also use Base64 >> >> encoding. I think it is unnecessary to introduce another encoding. >> >> On 06/23/2018 11:27 AM, Peter D. Gray wrote: >> >>> Personally, I don't think you should spec an encoding. It should be bin= ary only and hex for developers and JSON interfaces. My thinking is that PS= BT's are not user-visible things. They have a short lifetime and are nothin= g something that is "stored" or referenced much later. Hex is good enough a= nd has no downsides as an excoding except for density. >> I think what will end up happening though is that, at least in the >> >> beginning, PSBTs will primarily be strings that people end up copy and >> >> pasting. Since a PSBT can get pretty large, the strings are rather >> >> cumbersome to move around, especially as hex. At least with Base64 the >> >> strings will be smaller. >> >>> On the other hand, suggesting a filename extension (probably .PSBT?) an= d a mime-type to match, are helpful since wallets and such will want to reg= ister with their operating systems to become handlers of those mimetypes. R= eally that's a lot more important for interoperability at this point, than = an encoding. >> Agreed. I will include those in the BIP. >> >>> Looking forward to test vectors, and I might have more to say once my c= ode can handle them (again). >>> >>> Feedback on the BIP as it stands now: >>> >>> - Appendix A needs an update, and I suggest defining symbols (PK_PART= IAL_SIG =3D=3D 0x02) for the numeric key values. This helps implementers as= we don't all define our own symbols and/or use numeric constants in our co= de. >> Okay. >> >>> - Those tables are just not working. Might want to reformat as descri= ptive lists, point form, or generally anything else... sorry. >> I will try my best to fix that. Mediawiki sucks... >> >> Andrew >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev