Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 20F2AD6D for ; Thu, 21 Jun 2018 00:45:48 +0000 (UTC) X-Greylist: delayed 00:06:33 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 22DE54DA for ; Thu, 21 Jun 2018 00:45:47 +0000 (UTC) Date: Wed, 20 Jun 2018 20:39:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1529541551; bh=VUltNiQ9FXp3shj6JHOg9HWGuyyt5sOs5EME5Q2/ggU=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=i6knOGJMcoLP6qOeU+hp7xNNuGqDA+3F94JWFUOojoaEMuuNdikbMjdeM1rtZqVqs ry659hoSlS/KBq6xV2Ddk9YLSM/6ChukvRbMnRj2DtGP+NsyWlx6E4citRvhWvtpHC 2L04bG0MgSeOk3uzFirDVm5cwN74eWO2/+EHjitg= To: Bitcoin Protocol Discussion From: Achow101 Reply-To: Achow101 Message-ID: In-Reply-To: References: 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: Thu, 21 Jun 2018 00:45:48 -0000 Hi, On June 15, 2018 4:34 PM, Pieter Wuille via bitcoin-dev wrote: >=20 > Hello all, >=20 > given some recent work and discussions around BIP 174 (Partially > Signed Bitcoin Transaction Format) I'd like to bring up a few ideas. > First of all, it's unclear to me to what extent projects have already > worked on implementations, and thus to what extent the specification > is still subject to change. A response of "this is way too late" is > perfectly fine. While I agree that the BIP itself should be revised to reflect these sugges= tions, I fear that it may be too late. I know of a few other developers who= have implemented BIP 174 already but have not yet responded to this email. > =20 > - Generic key offset derivation > > Whenever a BIP32 derivation path does not include any hardened steps, > the entirety of the derivation can be conveyed as "The private key fo= r > P is equal to the private key for Q plus x", with P and Q points and = x > a scalar. This representation is more flexible (it also supports > pay-to-contract derivations), more efficient, and more compact. The > downside is that it requires the Signer to support such derivation, > which I don't believe any current hardware devices do. > Would it make sense to add this as an additional derivation method? While this is a good idea, I'm not sure that implementers would understand = this as it requires knowing the cryptography which makes this possible. As = an optional feature, not all wallets would understand it, and those that do= could create PSBTs which other wallets do not understand and thus cannot s= ign even if they have the private keys and actually can sign. > =20 > - Hex encoding? > =20 > This is a very minor thing. But presumably there will be some standar= d > way to store PSBTs as text for copy-pasting - either prescribed by th= e > spec, or de facto. These structures may become pretty large, so > perhaps it's worth choosing something more compact than hexadecimal - > for example Base64 or even Z85 (https://rfc.zeromq.org/spec:32/Z85/). Agreed. Are there any encodings that do not have double click breaking char= acters? On June 19, 2018 2:38 AM, Jonas Schnelli via bitcoin-dev wrote: > I think it could be more flexible (generic) in BIP174. > It could be just a single child key {32-bit int}, or just a keypath ({32-= bit int}]{32-bit int}=E2=80=A6) which is very likely sufficient for a HWW t= o derive the relevant key without the creation of a lookup-window or other = =E2=80=9Emaps". This ignores all of the other times that a BIP32 keypath needs to be provid= ed. It is not only used for multisig, there may be other times that there a= re multiple derivation paths and master keys due to multiple inputs and suc= h. Adding a field specific to multisig and HWW only seems pointless and red= undant to me. On June 19, 2018 2:38 AM, Jonas Schnelli via bitcoin-dev wrote: > > A question to consider is, > will there be more per-output data? If yes, it might make sense to have > an output section. I think it is unlikely that there would be anymore per-output data. > 3) The sighash type 0x03 says the sighash is only a recommendation. That >seems rather ambiguous. If the field is specified shouldn't it be binding? I disagree. It is up to the signer to decide what they wish to sign, not fo= r the creator to specify what to sign. The creator can ask the signer to si= gn something in a particular way, but it is ultimately up to the signer to = decide. > 4) Is it a good idea to skip records which types we are unaware of? We > can't come up with a reasonable example, but intuitively this seems as a > potential security issue. We think we should consider introducing a > flag, which would define if the record is "optional". In case the signer > encounters a record it doesn't recognize and such flag is not set, it > aborts the procedure. If we assume the set model we could change the > structure to {data}. We are not keen on > this, but we wanted to include this idea to see what you think. The idea behind skipping unknown types is to allow forward compatibility. A= combiner written now should be able to combine transactions created in the= future with new types as combining is really only just merging the maps to= gether. > In general, the standard is trying to be very space-conservative, > however is that really necessary? We would argue for clarity and ease of > use over space constraints. We think more straightforward approach is > desired, although more space demanding. What are the arguments to make > this as small as possible? If we understand correctly, this format is > not intended for blockchain nor for persistent storage, so size doesn= =E2=80=99t > matter nearly as much. Size is not really a constraint, but we do not want to be unnecessarily lar= ge. The PSBT still has to be transmitted to other people. It will likely be= used by copy and pasting the string into a text box. Copying and pasting v= ery long strings of text can be annoying and cumbersome. So the goal is to = keep the format still relatively clear while avoiding the duplication of da= ta. Andrew