Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 531329E2 for ; Wed, 20 Jun 2018 00:39:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com [209.85.192.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E56F48A for ; Wed, 20 Jun 2018 00:39:45 +0000 (UTC) Received: by mail-pf0-f173.google.com with SMTP id a22-v6so674190pfo.12 for ; Tue, 19 Jun 2018 17:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance; bh=XNdtzX6JuDtGaqOmhh43tmj/ocvLH6wBk/Y1d/lnuWY=; b=tBI+tlHz8vEN4xOjJ2Pyts/PBe/lY0+ZOUcPXe+2C3VbmKLRtDWqrLQ6hMsCjJCSRA u7BOxi5DfE1eVuZGHZy+9KJNdw1Nrqi94Iu6mNBt7XF650+3hQrfHT3y8XLYao09jTJ3 JrkqFiI63imXdj1rYO93Plzui/CNnhxXEQeHF2PlgEU5Cnvo98oVa9YLus1zLCCGTCFd HaZdkYwK4kBNV12RBGOTZpIgxo1UDCsTZAfbBOh+knTiBKEO72YQM7Z1pE9s7WOT44fR CbHwubeRJQQYOob+YxF8drjA/rnqItr/oa7rqElldPGcK6n52K2b89AR1HP31NLWVLTF wtQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=XNdtzX6JuDtGaqOmhh43tmj/ocvLH6wBk/Y1d/lnuWY=; b=QmpGzN3AKr4En8ItGDpiv3Y0c/pq5xaoWpQWLY3apTVEQVoTSyE1uQ//xdzuytMdiQ 5p9Yr/310Iu9IjX6GxkhNPsrCjE1wjmmeW+KnetHJuDqIjJj+/hYK7BvQstfwBvDLFoN /nO7aF/zW40Jrq/2+8/ceQ6vPG+1GHYOrft3vNiMRA4KeGGqdivrmWahJeW1He24+2mA o8lbvc7UQZxNrre9L3Jiz3KtecUxD3qDbwnSXxPTo+XrF27xsGsTEaLVyii3TmnorRZR qe094Mg3l2TeDaD4l8UkNofIeXOWtfLFOFrjAPYBUwxDcwkpsZRxcUtLA1NaYDaqcyjC zwXQ== X-Gm-Message-State: APt69E0jIcQIZzvLUlusNYZ4xObA88LcCYuA4btFIAnYb+L7nXui7ADZ O1thFbGTvO6fDZONZWTeJm1vPxA= X-Google-Smtp-Source: ADUXVKJ5hUxBf5vz+0aH2iokYf6CMFcYbNuT2o7VTkmtTj9zWmmvaR9tYs4j4oEy/9xXAOerH2ZTXw== X-Received: by 2002:a62:6f86:: with SMTP id k128-v6mr20400619pfc.150.1529455185249; Tue, 19 Jun 2018 17:39:45 -0700 (PDT) Received: from ?IPv6:::ffff:192.168.7.31? (cpe-107-185-81-42.socal.res.rr.com. [107.185.81.42]) by smtp.gmail.com with ESMTPSA id g4-v6sm1174103pfg.38.2018.06.19.17.39.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 17:39:44 -0700 (PDT) Message-ID: <5b29a250.1c69fb81.8d368.4610@mx.google.com> MIME-Version: 1.0 To: "bitcoin-dev@lists.linuxfoundation.org" From: Jason Les Date: Tue, 19 Jun 2018 17:39:46 -0700 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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, 20 Jun 2018 00:42:48 +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, 20 Jun 2018 00:39:46 -0000 --_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote: ... > 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. ... I am working on a python implementation of BIP 174 as part of a multi-sig h= ardware wallet I have in the works. I am not so far along as to say that al= l these changes are way too late, but I=E2=80=99ll comment on the following= : > Key-value map model or set model I believe the key-value map model should be kept because as Jonas Schnelli = said it=E2=80=99s probably not worth significantly breaking existing implem= entations like Peter Gray=E2=80=99s, or maybe more who have not spoken up. = However, I appreciate the benefit of the set model particularly in regards = to size consideration and the merging of redeemscripts and witnesscripts in= to single =E2=80=9Cscripts=E2=80=9D records. >Ability for Combiners to verify two PSBT are for the same transaction This idea makes a lot of sense, much more intuitive. >Hex encoding? I was hoping for some standard here was well and I agree using something mo= re compact than hex is important. My understanding is Z85 is better for use= with JSON than Base64, which is probably a good benefit to have here. I will continue developing under the current spec and if there ends up bein= g consensus for some of the changes here I=E2=80=99m fine with re-doing the= work. I will be following this thread closer now. Best, Jason Les --_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote:

=

...

> First of all, it's un= clear to me to what extent projects have already

&g= t; worked on implementations, and thus to what extent the specification

=

> is still subject to change. A response of "t= his is way too late" is

> perfectly fine.

...

 

I am working on a python implementation of BIP 174 as par= t of a multi-sig hardware wallet I have in the works. I am not so far along= as to say that all these changes are way too late, but I=E2=80=99ll commen= t on the following:

 

> Key-value map model or set model

= I believe the key-value map model should be kept because as Jonas Schnelli = said it=E2=80=99s probably not worth significantly breaking existing implem= entations like Peter Gray=E2=80=99s, or maybe more who have not spoken up. = However, I appreciate the benefit of the set model particularly in regards = to size consideration and the merging of redeemscripts and witnesscripts in= to single =E2=80=9Cscripts=E2=80=9D records.

&= nbsp;

>Ability for Combiners to verify two= PSBT are for the same transaction

This idea makes = a lot of sense, much more intuitive.

 

>Hex encoding?

I was= hoping for some standard here was well and I agree using something more co= mpact than hex is important. My understanding is Z85 is better for use with= JSON than Base64, which is probably a good benefit to have here.

 

I will continue de= veloping under the current spec and if there ends up being consensus for so= me of the changes here I=E2=80=99m fine with re-doing the work. I will be f= ollowing this thread closer now.

 <= /p>

Best,

Jason Les

 

= --_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_--