path: root/9e/c5ada1bd58bdeb3c0af1bfef35901f926e054b

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C9790CA4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 21 Jun 2018 15:40:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D088E6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 21 Jun 2018 15:40:17 +0000 (UTC)
Received: by mail-wm0-f49.google.com with SMTP id v131-v6so7009674wma.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 21 Jun 2018 08:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=CywzNiOxiMuah80EJyQQMrwZcNGyOiYNMzX2N9LSXc8=;
	b=qsReyY4w0gEmS2d2x8012RCGb0eTC7gTwEBLmdG9MtBno//zt5xcd2ISlPmAJMnTJL
	tEj271ZEuum1dRKroMjiAgxpF4vznDr3j+LpUkhDy7k39I/IfihzZhE2Pu19KZDDZzjR
	YPkkmLwuaDKmlyBwdgKM31iQmLrdfgM15IQxr9BxP8YZbftuqUn9zNYW6Xo4uYDTpH8D
	N1h1LnaCT44aDjztcqNpP90QTWHOV9iLiK2jNkJaxaCQsxLKK0nm4GmqU8abJnVIEFPG
	t6wf/7l2kJOPPVqqzRSfp+FQTsBT0sHa8sa8xYGVwMMvxfeIjLsQV/SV/Zqbo3R+6mjG
	QYQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=CywzNiOxiMuah80EJyQQMrwZcNGyOiYNMzX2N9LSXc8=;
	b=QsFoKuR+H46LgD61sQLSjf8pqRp5Lj/pXzQRTqJgJpTcAZKbeY/fohi4CMoMOC/pdF
	VNQfU/i2BPUOaL4l8vFFq7oCF8MWgAMJH2LFLB7bUA6PW+kOAvI3llQrJNiLE24KXhY+
	iTr1wWi5p9ojsSdwkh3w3AwkcfbxI9wKeuGwf1sFvu5NLDPl3ypYAlrqGil9U+IMfmed
	sp4OdHGzCLib3C3sJvlM4zaOnV4kxnXG4fWGTDzW1PIUPgzFfR3opAxHTfOFvHBhn+7/
	cI4dRojR9vHNP1JVW977Z+ufxNU4u244Aytwu4vWp/KTpKCO6GwVZgDpxMKZReTGozAc
	EPog==
X-Gm-Message-State: APt69E1Z0JhxusOktjU78laioma86KW/vT19ACDp13Evg3aqzCCkzMWT
	1f5C1wPDTnc2ZPNDxkEc/QOy8ePr15EOZUFysjU=
X-Google-Smtp-Source: ADUXVKL1NdRcl0aCDbPrm8LaI3DYWyaM4KtzLY6mEWI+IAiEH9rRltueJ5m5RisGtKNFkBgV+Fm54/hOdxfWhvpUj+s=
X-Received: by 2002:a50:d2d7:: with SMTP id
	q23-v6mr22115408edg.214.1529595615964; 
	Thu, 21 Jun 2018 08:40:15 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
	<21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com>
In-Reply-To: <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 21 Jun 2018 11:40:04 -0400
Message-ID: <CAB3F3DsA5KDx-zRuYyQbeWYAAjuY_+_gwma-9_ZRa0u8-B5p2g@mail.gmail.com>
To: tomas.susanka@satoshilabs.com, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000056f1b0056f28bbae"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no 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 <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: Thu, 21 Jun 2018 15:40:18 -0000

--00000000000056f1b0056f28bbae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>Hmm, upon further reflection, maybe it's not even worth including *any*
per-output data, aside from what the original transaction contains.

>The output redeem script is either:
- unknown, because we have received only an address from the receiver
- or it is known, because it is ours and in that case it doesn=E2=80=99t ma=
ke
sense to include it in PSBT

Signers are an extremely heterogeneous bunch. A signer may need to
introspect on the script, such as "this is a 2-of-3,
and I'm one of the keys". Even in basic p2pkh settings not adding any
output information rules out things like change
detection on any conceivable hardware wallet, or even simple software
wallets that don't carry significant state.

On Thu, Jun 21, 2018 at 10:35 AM Tomas Susanka via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> First of all, let me thank you for all the hard work you and others have
> put into this.
>
>
> On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> > While I agree that the BIP itself should be revised to reflect these
> suggestions, 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 responde=
d
> to this email.
>
> We do realize that this discussion should have happened earlier, however
> agreeing on a good standard should be the number one priority for all
> the parties involved.
>
> The fact that someone already implemented this is indeed unfortunate,
> but I don't think we should lower our demands on the standard just
> because of a bad timing.
>
> >> A question to consider is,
> >> will there be more per-output data? If yes, it might make sense to hav=
e
> >> an output section.
> > I think it is unlikely that there would be anymore per-output data.
>
> Hmm, upon further reflection, maybe it's not even worth including *any*
> per-output data, aside from what the original transaction contains.
>
> The output redeem script is either:
> - unknown, because we have received only an address from the receiver
> - or it is known, because it is ours and in that case it doesn=E2=80=99t =
make
> sense to include it in PSBT
>
> We got stuck on the idea of the Creator providing future (output)
> redeem/witness scripts. But that seems to be a minority use case and can
> be solved efficiently via the same channels that coordinate the PSBT
> creation. Sorry to change opinions so quickly on this one.
>
> >
> >> 3) The sighash type 0x03 says the sighash is only a recommendation. Th=
at
> >> 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, no=
t
> for the creator to specify what to sign. The creator can ask the signer t=
o
> sign something in a particular way, but it is ultimately up to the signer
> to decide.
>
> This seems very ambiguous. The Signer always has the option of not
> signing. *What* to sign is a matter of coordination between the parties;
> otherwise, you could make all the fields advisory and let anyone sign
> anything they like?
>
> We don't understand the usecase for a field that is advisory but not
> binding. On what basis would you choose to respect or disregard the
> advisory field? Either one party has a preference, in which case they
> have to coordinate with the other anyway - or they don't, in which case
> they simply leave the field out.
>
> > Size is not really a constraint, but we do not want to be unnecessarily
> large. The PSBT still has to be transmitted to other people. It will like=
ly
> be used by copy and pasting the string into a text box. Copying and pasti=
ng
> very 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
> data.
>
> I agree. Just to put some numbers on this: if we expect a 5-part
> derivation path, and add the master key fingerprint, that is 4 + 5*4 =3D
> 24 bytes (~32 base64 letters) per input and signer. I'd argue this is
> not significant.
> If we used full xpub, per Pieter's suggestion, that would grow to 32 +
> 32 + 5*4 =3D 84 bytes (~112 letters) per input/signer, which is quite a l=
ot.
>
> On the other hand, keeping the BIP32 paths per-input means that we don't
> need to include the public key (as in the lookup key), so that's 32
> bytes down per path. In general, all the keys can be fully reconstructed
> from their values:
>
> redeem script key =3D hash160(value)
> witness script key =3D sha256(value)
> bip32 key =3D derive(value)
>
> The one exception is a partial signature. But even in that case we
> expect that a given public key will always correspond to the same
> signature, so we can act as if the public key is not part of the "key".
> In other words, we can move the public key to the value part of the recor=
d.
>
> This holds true unless there's some non-deterministic signing scheme,
> *and* multiple Signers sign with the same public key, which is what
> Pieter was alluding to on Twitter
> (https://twitter.com/pwuille/status/1002627925110185984). Still, I would
> argue (as he also suggested) that keeping the format more complex to
> support this particular use case is probably not worth it.
>
> Also, we can mostly ignore deduplication of witness/redeem scripts.
> These still need to be included in the resulting transaction, duplicated
> if necessary, so I think counting their repetition against the size of
> PSBT isn't worth it.
>
>
> Best,
> Tomas
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000056f1b0056f28bbae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;<span style=3D"text-decoration-style:initial;text-deco=
ration-color:initial;float:none;display:inline">Hmm, upon further reflectio=
n, maybe it&#39;s not even worth including *any*</span><br style=3D"text-de=
coration-style:initial;text-decoration-color:initial"><span style=3D"text-d=
ecoration-style:initial;text-decoration-color:initial;float:none;display:in=
line">per-output data, aside from what the original transaction contains.</=
span><br style=3D"text-decoration-style:initial;text-decoration-color:initi=
al"><br style=3D"text-decoration-style:initial;text-decoration-color:initia=
l"><span style=3D"text-decoration-style:initial;text-decoration-color:initi=
al;float:none;display:inline">&gt;The output redeem script is either:</span=
><br style=3D"text-decoration-style:initial;text-decoration-color:initial">=
<span style=3D"text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline">- unknown, because we have received only an addr=
ess from the receiver</span><br style=3D"text-decoration-style:initial;text=
-decoration-color:initial"><span style=3D"text-decoration-style:initial;tex=
t-decoration-color:initial;float:none;display:inline">- or it is known, bec=
ause it is ours and in that case it doesn=E2=80=99t make</span><br style=3D=
"text-decoration-style:initial;text-decoration-color:initial"><span style=
=3D"text-decoration-style:initial;text-decoration-color:initial;float:none;=
display:inline">sense to include it in PSBT</span><div><span style=3D"text-=
decoration-style:initial;text-decoration-color:initial;float:none;display:i=
nline"><br></span></div><div>Signers are an extremely heterogeneous bunch. =
A signer may need to introspect on the script, such as &quot;this is a 2-of=
-3,</div><div>and I&#39;m one of the keys&quot;. Even in basic p2pkh settin=
gs not adding any output information rules out things like change</div><div=
>detection on any conceivable hardware wallet, or even simple software wall=
ets that don&#39;t carry significant state.=C2=A0</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Thu, Jun 21, 2018 at 10:35 AM Tomas Su=
sanka via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">Hello,<br>
<br>
First of all, let me thank you for all the hard work you and others have<br=
>
put into this.<br>
<br>
<br>
On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:<br>
&gt; While I agree that the BIP itself should be revised to reflect these s=
uggestions, I fear that it may be too late. I know of a few other developer=
s who have implemented BIP 174 already but have not yet responded to this e=
mail.<br>
<br>
We do realize that this discussion should have happened earlier, however<br=
>
agreeing on a good standard should be the number one priority for all<br>
the parties involved.<br>
<br>
The fact that someone already implemented this is indeed unfortunate,<br>
but I don&#39;t think we should lower our demands on the standard just<br>
because of a bad timing.<br>
<br>
&gt;&gt; A question to consider is,<br>
&gt;&gt; will there be more per-output data? If yes, it might make sense to=
 have<br>
&gt;&gt; an output section.<br>
&gt; I think it is unlikely that there would be anymore per-output data.<br=
>
<br>
Hmm, upon further reflection, maybe it&#39;s not even worth including *any*=
<br>
per-output data, aside from what the original transaction contains.<br>
<br>
The output redeem script is either:<br>
- unknown, because we have received only an address from the receiver<br>
- or it is known, because it is ours and in that case it doesn=E2=80=99t ma=
ke<br>
sense to include it in PSBT<br>
<br>
We got stuck on the idea of the Creator providing future (output)<br>
redeem/witness scripts. But that seems to be a minority use case and can<br=
>
be solved efficiently via the same channels that coordinate the PSBT<br>
creation. Sorry to change opinions so quickly on this one.<br>
<br>
&gt;<br>
&gt;&gt; 3) The sighash type 0x03 says the sighash is only a recommendation=
. That<br>
&gt;&gt; seems rather ambiguous. If the field is specified shouldn&#39;t it=
 be binding?<br>
&gt; I disagree. It is up to the signer to decide what they wish to sign, n=
ot for the creator to specify what to sign. The creator can ask the signer =
to sign something in a particular way, but it is ultimately up to the signe=
r to decide.<br>
<br>
This seems very ambiguous. The Signer always has the option of not<br>
signing. *What* to sign is a matter of coordination between the parties;<br=
>
otherwise, you could make all the fields advisory and let anyone sign<br>
anything they like?<br>
<br>
We don&#39;t understand the usecase for a field that is advisory but not<br=
>
binding. On what basis would you choose to respect or disregard the<br>
advisory field? Either one party has a preference, in which case they<br>
have to coordinate with the other anyway - or they don&#39;t, in which case=
<br>
they simply leave the field out.<br>
<br>
&gt; Size is not really a constraint, but we do not want to be unnecessaril=
y large. The PSBT still has to be transmitted to other people. It will like=
ly be used by copy and pasting the string into a text box. Copying and past=
ing very long strings of text can be annoying and cumbersome. So the goal i=
s to keep the format still relatively clear while avoiding the duplication =
of data.<br>
<br>
I agree. Just to put some numbers on this: if we expect a 5-part<br>
derivation path, and add the master key fingerprint, that is 4 + 5*4 =3D<br=
>
24 bytes (~32 base64 letters) per input and signer. I&#39;d argue this is<b=
r>
not significant.<br>
If we used full xpub, per Pieter&#39;s suggestion, that would grow to 32 +<=
br>
32 + 5*4 =3D 84 bytes (~112 letters) per input/signer, which is quite a lot=
.<br>
<br>
On the other hand, keeping the BIP32 paths per-input means that we don&#39;=
t<br>
need to include the public key (as in the lookup key), so that&#39;s 32<br>
bytes down per path. In general, all the keys can be fully reconstructed<br=
>
from their values:<br>
<br>
redeem script key =3D hash160(value)<br>
witness script key =3D sha256(value)<br>
bip32 key =3D derive(value)<br>
<br>
The one exception is a partial signature. But even in that case we<br>
expect that a given public key will always correspond to the same<br>
signature, so we can act as if the public key is not part of the &quot;key&=
quot;.<br>
In other words, we can move the public key to the value part of the record.=
<br>
<br>
This holds true unless there&#39;s some non-deterministic signing scheme,<b=
r>
*and* multiple Signers sign with the same public key, which is what<br>
Pieter was alluding to on Twitter<br>
(<a href=3D"https://twitter.com/pwuille/status/1002627925110185984" rel=3D"=
noreferrer" target=3D"_blank">https://twitter.com/pwuille/status/1002627925=
110185984</a>). Still, I would<br>
argue (as he also suggested) that keeping the format more complex to<br>
support this particular use case is probably not worth it.<br>
<br>
Also, we can mostly ignore deduplication of witness/redeem scripts.<br>
These still need to be included in the resulting transaction, duplicated<br=
>
if necessary, so I think counting their repetition against the size of<br>
PSBT isn&#39;t worth it.<br>
<br>
<br>
Best,<br>
Tomas<br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000056f1b0056f28bbae--