Return-Path: <a.raspitzu@protonmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 67470A47 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 24 Jun 2018 09:00:58 +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 6B343E2 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 24 Jun 2018 09:00:57 +0000 (UTC) Date: Sun, 24 Jun 2018 05:00:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1529830855; bh=sOh3ZvDuMJqafGNCkGkqZMtfQ8faQPHi2tTcB/itYZ0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=mZvLpluEtIHToEnRyN0vwMXbGDJSDYwKOkw+5nyzJICt0FsdNMduFOf+oTydVq+pe q9N/MdtJtwGV3RtmMd2F2HQwmwjqrYCb62YnowInU08RJtuEnI73ZhZi/wr/I1KBsO t0qhb0pHTtECXPfRcsbfIE/v3M1o/VJg97WRQGEo= To: Andrew Chow <achow101-lists@achow101.com> From: Andrea <a.raspitzu@protonmail.com> Reply-To: Andrea <a.raspitzu@protonmail.com> Message-ID: <VL10ISVuFyUBiT2QCjil36o2GN1xLS3r7X3m1QYqBBYetcFsYKr_H3PG2Mqy5hC7SnbxWXqy7dYQ-sb83cEuZyLdy0SpIp3lxWmhql4UPO8=@protonmail.com> In-Reply-To: <4BLLfQQ5BFO3Z2E2NagJ5trtBmdr6if2KSR9gWpYQY2xKu6THdvk0LJbkRxr8Yie2HA17KOZIM2ljupV_H8cfVkGFFcRjOrA0b13KG9ciF4=@achow101.com> References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com> <CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com> <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com> <20180621195654.GC99379@coinkite.com> <CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com> <ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com> <87zhzlbfq5.fsf@jb55.com> <qqrkCNKaf2L_MWkEU5F2u3Jna2QdA-bGNPDE9aU64Im0SUlIo4mfexfp8CXQSj9vEp9XM25DHSJIp4HnKFyLsflAhreppaNJQy-g1hXtjNU=@achow101.com> <HWG4r9Lgi0mPONMhHwAXqnGPYeqeAvarQBUlqaRa-iZeysawpb2CN76M0ywrxbhLGJirwWViKIJqwadJcjYPRdYff4ISkSYXAO4a0SWBdVA=@protonmail.com> <4BLLfQQ5BFO3Z2E2NagJ5trtBmdr6if2KSR9gWpYQY2xKu6THdvk0LJbkRxr8Yie2HA17KOZIM2ljupV_H8cfVkGFFcRjOrA0b13KG9ciF4=@achow101.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: Sun, 24 Jun 2018 12:26:11 +0000 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: Sun, 24 Jun 2018 09:00:58 -0000 Keeping it for future extensions is a good point, my understanding was that= since we always need exactly one transaction it could be part of the defin= ition of PSBT instead of being a key-value (although it is more of a breaki= ng change).=20 Cheers, Andrea. =E2=80=8B=E2=80=8B =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 24, 2018 10:28 AM, Andrew Chow <achow101-lists@achow101.com> wrote: > =E2=80=8B=E2=80=8B >=20 > I disagree with the idea that global types can be removed. Firstly, it >=20 > is less of a breaking change to leave it there than to remove it >=20 > entirely. Secondly, there may be a point in the future where global >=20 > types would be useful/necessary. By having it still be there, we allow >=20 > for future extensibility. >=20 > Andrew >=20 > On 06/24/2018 01:19 AM, Andrea wrote: >=20 > > Hi, > >=20 > > I think in the revised spec we can remove completely the "global types"= as a map or even as typed record. Since there is only one type (the transa= ction) and it's compulsory to have one (and only one) we could just drop th= e definition of global type and the key associated with it, simply after th= e header + separator there must be a transaction. Having read all the discu= ssion i also agree having per-input key derivation and per-output data is a= lot more handy for signers, no special feeling regarding the encoding.Look= ing forward for the test vectors and the new spec. > >=20 > > Cheers, Andrea. > >=20 > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina= l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80= =90 > >=20 > > On June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev bitcoin-dev@list= s.linuxfoundation.org wrote: > >=20 > > > On 06/23/2018 10:00 AM, William Casarin wrote: > > >=20 > > > > Since we're still considering the encoding, I wonder if it would be= a > > > >=20 > > > > good idea to have a human-readible part like lightning invoices[1]? > > > >=20 > > > > I don't think that is necessary. > > >=20 > > > > Then perhaps you could drop the magic code as well? > > > >=20 > > > > The magic is still necessary for the binary format in order to prev= ent > > >=20 > > > normal transaction deserializers from accidentally deserializing a ps= bt. > > >=20 > > > > Also we could do a base encoding that excludes + and / characters, = such > > > >=20 > > > > as base62 (gmp-style). It's easier to copy/paste (double clicking a > > > >=20 > > > > string stops at / or + in base64 encodings). > > > >=20 > > > > While that would be ideal, I think it is better to use an encoding = that > > >=20 > > > most wallets already support. Most wallets already have Base64 decodi= ng > > >=20 > > > available so that they can decode signed messages which also use Base= 64 > > >=20 > > > encoding. I think it is unnecessary to introduce another encoding. > > >=20 > > > On 06/23/2018 11:27 AM, Peter D. Gray wrote: > > >=20 > > > > Personally, I don't think you should spec an encoding. It should be= binary only and hex for developers and JSON interfaces. My thinking is tha= t PSBT's are not user-visible things. They have a short lifetime and are no= thing something that is "stored" or referenced much later. Hex is good enou= gh and has no downsides as an excoding except for density. > > > >=20 > > > > I think what will end up happening though is that, at least in the > > >=20 > > > beginning, PSBTs will primarily be strings that people end up copy an= d > > >=20 > > > pasting. Since a PSBT can get pretty large, the strings are rather > > >=20 > > > cumbersome to move around, especially as hex. At least with Base64 th= e > > >=20 > > > strings will be smaller. > > >=20 > > > > On the other hand, suggesting a filename extension (probably .PSBT?= ) and a mime-type to match, are helpful since wallets and such will want to= register with their operating systems to become handlers of those mimetype= s. Really that's a lot more important for interoperability at this point, t= han an encoding. > > > >=20 > > > > Agreed. I will include those in the BIP. > > >=20 > > > > Looking forward to test vectors, and I might have more to say once = my code can handle them (again). > > > >=20 > > > > Feedback on the BIP as it stands now: > > > >=20 > > > > - Appendix A needs an update, and I suggest defining symbols (PK_= PARTIAL_SIG =3D=3D 0x02) for the numeric key values. This helps implementer= s as we don't all define our own symbols and/or use numeric constants in ou= r code. > > > > =20 > > > > Okay. > > > > =20 > > >=20 > > > > - Those tables are just not working. Might want to reformat as de= scriptive lists, point form, or generally anything else... sorry. > > > > =20 > > > > I will try my best to fix that. Mediawiki sucks... > > > > =20 > > >=20 > > > Andrew > > >=20 > > > bitcoin-dev mailing list > > >=20 > > > bitcoin-dev@lists.linuxfoundation.org > > >=20 > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev