path: root/10/059ff08367bbfb69be1566fd022c094e2aa9cb

Return-Path: <andrew.kozlik@satoshilabs.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F591C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 13:41:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 069B186C03
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 13:41:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vfel86p4lbtj
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 13:41:39 +0000 (UTC)
X-Greylist: delayed 00:07:10 by SQLgrey-1.7.6
Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com
 [209.85.208.182])
 by whitealder.osuosl.org (Postfix) with ESMTPS id F3C8686A92
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 13:41:38 +0000 (UTC)
Received: by mail-lj1-f182.google.com with SMTP id c8so20573923ljd.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 05:41:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=satoshilabs.com; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=gUZd/MSucVB9gfzmx41YJ3V9k0XbvfVasXRXAgubUyU=;
 b=F5awJQyJ4LVddEBa6xrzc6OFJHw76UXd5oCgsA3ew1QidNnWikylqAC/Fd8GOTkrcw
 e0wCz5AAP8A7TRMhH1SowRCasHfaECb7SGn4wt65vrLUpICbBdPif7NsLOLRMPJdi6wp
 1DJqd1hvot5jSrWeqjQxJ5O6I5ZH6c8jN2bsKph2ssq5S1jZo6heBKX9WXDHvUbtU1qc
 qY5xo5jrkj7tips+h7KU65g3k96KFFvATtdh4XXNuH/FvDH4O504L21HOPGBOSGMVP3Y
 6FqI2fjC/qqkmWdf3Ww2ICj/3IeqboLE3m0t96q2zzUlb3b5g310n7vu2I6SjmoUqCid
 zo7A==
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=gUZd/MSucVB9gfzmx41YJ3V9k0XbvfVasXRXAgubUyU=;
 b=lekCGkMNZlJOsX+Zn9KCltLqvuI6Rj4xIlWj1iZIMVdYd023LESmZVdTvZ61COspaQ
 wHXxdZDMfFYlr2M1o6IgE+cs4TyWICQFEBwGwVskIT8FZ6vHc7gC28AtH4naWCtzPGsY
 7yDXn0py1/zJmN0Yw4g5G5R7ELwJ2PArHucMtP2D0SWYwvdMsIXY+Nv9fo3JaJA41Tna
 KBNQXFN7VARBuT/GKlmQzXpAJTwRcPDp/n6EifCmb3hzYoFtKpCk9nx5417Y0sWdb4+U
 jkkp9CuKXrOnmnv7Vp/L9bnzA1rQA/TdeHWQqMDlNsoOei6Esq7sQ+pX7eE2UhGTfuGz
 FqZw==
X-Gm-Message-State: AOAM530t8IqXfxZZP7L/KTgSa6Y31ksFPwHoXhp8aduphwp67hopN9XE
 euw7W8sxiV3QZNpYKoH1D3JloUf4hEDu3/eW0ajKgfS6NFJwHA==
X-Google-Smtp-Source: ABdhPJwlCpWR3qndxee9tTDOhtEhHPL+8qenYTbvnyGu13vYdu43c1xBIIq8ATJ4DxT69sK3ajIZBbImmmRG0wDhjC8=
X-Received: by 2002:a50:e1c4:: with SMTP id m4mr9172528edl.182.1613741667027; 
 Fri, 19 Feb 2021 05:34:27 -0800 (PST)
MIME-Version: 1.0
References: <63e9654c-44b8-740b-79a7-bb58f7bd198c@electrum.org>
 <b60a7654-0252-90af-7ec1-b3de3ed74ae7@degreesofzero.com>
In-Reply-To: <b60a7654-0252-90af-7ec1-b3de3ed74ae7@degreesofzero.com>
From: Andrew Kozlik <andrew.kozlik@satoshilabs.com>
Date: Fri, 19 Feb 2021 14:34:16 +0100
Message-ID: <CACvH2ek=bM=0vH-skjhr2VnaF47U3eht5P3ukJ7CUnB3V8ZGQQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Thomas Voegtlin <thomasv@electrum.org>
Content-Type: multipart/alternative; boundary="000000000000d29d9205bbb08274"
X-Mailman-Approved-At: Fri, 19 Feb 2021 13:49:49 +0000
Subject: Re: [bitcoin-dev] BIP70 is dead. What now?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Fri, 19 Feb 2021 13:41:41 -0000

--000000000000d29d9205bbb08274
Content-Type: text/plain; charset="UTF-8"

Hi Thomas,

I am working on an experimental implementation [1] of a new payment request
format in Trezor T. In some respects it's similar to BIP-70. The main
differences are:

1. There is no reliance on X.509, since that seems to have been the main
reason for BIP-70's downfall. The signature is mandatory, since for us the
main feature is protection against a man-in-the-middle attack. So in this
sense it's more similar to BOLT11.

2. It can be used to solve a similar problem with coin exchange. When you
are sending BTC to a trusted exchange service and expecting another
cryptocurrency in return, say LTC, you want to be sure that you not only
have the correct BTC address, but also that the exchange service has your
correct LTC address.

3. It uses an optional nonce for replay protection.

The two interesting parts in [1] are probably the `TxAckPaymentRequest`
protobuf message [2] and the signature verification [3]. The protobuf
message is only for communication between Trezor and the host software
running on the user's computer. It's not intended for interchange between
wallets. We haven't defined the interchange format yet. I intend to create
a SLIP documenting all this.

Andrew

[1] https://github.com/trezor/trezor-firmware/compare/andrewkozlik/payreq2
[2]
https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-L427
[3]
https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py

On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi, Thomas,
>
> I developed a URL signing scheme for use with LNURL as a method for
> authorizing payments on behalf of offline devices /applications. It's
> not specifically off-chain or on-chain related, but could be repurposed.
> The gist of the scheme is as follows:
>
> Before any signing is done:
>
> 0) Generate an API key (ID/reference, secret, encoding) to be shared
> between a server and an offline device or application.
>
> To generate a signature:
>
> 1) Generate a random nonce (unique per API key)
>
> 2) Build a query string with the `id`, `nonce`, `tag`, "Server
> parameters" (see [Subprotocols](#subprotocols) above), and any custom
> parameters. The `id` parameter should be equal to the API key's ID.
> Example:
> `id=b6cb8e81e3&nonce=d585674cf991dbbab42b&tag=withdrawRequest&minWithdrawable=5000&maxWithdrawable=7000&defaultDescription=example&custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE`.
>
> Note that both the keys and values for query parameters should be URL
> encoded. The following characters should be __unescaped__: `A-Z a-z 0-9
> - _ . ! ~ * ' ( )`. See
> [encodeURIComponent](
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description)
>
> for more details.
>
> 3) Sort the query parameters by key (alphabetically). This is referred
> to as the "payload". Example:
>
> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest`
>
> 4) Sign the payload (the sorted query string) using the API key secret.
> Signatures are generated using HMAC-SHA256, where the API key secret is
> the key.
>
> 5) Append the signature to the payload as follows:
>
> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest&signature=HMAC_SHA256_SIGNATURE`.
>
> You can find more details here:
>
> https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme
>
>
> I would change a few things with this scheme to fit better with the
> use-case you describe. For example:
>
> * Remove the "tag" and LNURL-specific parameters
>
> * Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key
> signing instead. The lnurl-auth subprotocol has an interesting approach
> to protecting user privacy while allowing verification of signatures.
> See for more details on that:
>
> https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md
>
>
> - chill
>
>
> On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:
> > I never liked BIP70. It was too complex, had too many features, and when
> > people discuss it, they do not even agree on what the main feature was.
> >
> > Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
> > that payment requests were signed. I am making this post to discuss this.
> >
> > When I send bitcoins to an exchange, I would like to receive a signed
> > request. I want to have a proof that the exchange asked me to send coins
> > to that address, in case it has been hijacked by some intern working
> > there. If that feature was implemented by an exchange, it would guide my
> > decision to use that exchange over its competitors.
> >
> > I do not think that a single exchange ever implemented that, but I guess
> > this is because BIP70 is a terrible standard. LN payment requests are
> > signed, do not require SSL, do not require interactivity, and therefore
> > exchanges use them. Can't we achieve the same for on-chain payments? Is
> > anyone working on that?
> >
> > I would be more than happy to remove BIP70 support from Electrum, if
> > there was another standard for signed requests.
> >
> > Thomas
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi Thomas,</div><div><br></div><div>I am working on a=
n experimental implementation [1] of a new payment request format in Trezor=
 T. In some respects it&#39;s similar to BIP-70. The main differences are:<=
/div><div><br></div><div>1. There is no reliance on X.509, since that seems=
 to have been the main reason for BIP-70&#39;s downfall. The signature is m=
andatory, since for us the main feature is protection against a man-in-the-=
middle attack. So in this sense it&#39;s more similar to BOLT11.</div><div>=
<br></div><div>2. It can be used to solve a similar problem with coin excha=
nge. When you are sending BTC to a trusted exchange service and expecting a=
nother cryptocurrency in return, say LTC, you want to be sure that you not =
only have the correct BTC address, but also that the exchange service has y=
our correct LTC address.</div><div><br></div><div>3. It uses an optional no=
nce for replay protection.</div><br>The two interesting parts in [1] are pr=
obably the `TxAckPaymentRequest` protobuf message [2] and the signature ver=
ification [3]. The protobuf message is only for communication between Trezo=
r and the host software running on the user&#39;s computer. It&#39;s not in=
tended for interchange between wallets. We haven&#39;t defined the intercha=
nge format yet. I intend to create a SLIP documenting all this.<br><div><br=
></div><div>Andrew <br></div><div><br></div>[1] <a href=3D"https://github.c=
om/trezor/trezor-firmware/compare/andrewkozlik/payreq2">https://github.com/=
trezor/trezor-firmware/compare/andrewkozlik/payreq2</a><br>[2] <a href=3D"h=
ttps://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/p=
rotob/messages-bitcoin.proto#L403-L427">https://github.com/trezor/trezor-fi=
rmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-=
L427</a><br>[3] <a href=3D"https://github.com/trezor/trezor-firmware/blob/a=
ndrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py">https=
://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/app=
s/bitcoin/sign_tx/payment_request.py</a><br></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 19, 2021 at 1:43 PM=
 Charles Hill via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, Thomas,<br>
<br>
I developed a URL signing scheme for use with LNURL as a method for <br>
authorizing payments on behalf of offline devices /applications. It&#39;s <=
br>
not specifically off-chain or on-chain related, but could be repurposed. <b=
r>
The gist of the scheme is as follows:<br>
<br>
Before any signing is done:<br>
<br>
0) Generate an API key (ID/reference, secret, encoding) to be shared <br>
between a server and an offline device or application.<br>
<br>
To generate a signature:<br>
<br>
1) Generate a random nonce (unique per API key)<br>
<br>
2) Build a query string with the `id`, `nonce`, `tag`, &quot;Server <br>
parameters&quot; (see [Subprotocols](#subprotocols) above), and any custom =
<br>
parameters. The `id` parameter should be equal to the API key&#39;s ID. <br=
>
Example: <br>
`id=3Db6cb8e81e3&amp;nonce=3Dd585674cf991dbbab42b&amp;tag=3DwithdrawRequest=
&amp;minWithdrawable=3D5000&amp;maxWithdrawable=3D7000&amp;defaultDescripti=
on=3Dexample&amp;custom1=3DCUSTOM1_PARAM_VALUE&amp;custom2=3DCUSTOM2_PARAM_=
VALUE`. <br>
Note that both the keys and values for query parameters should be URL <br>
encoded. The following characters should be __unescaped__: `A-Z a-z 0-9 <br=
>
- _ . ! ~ * &#39; ( )`. See <br>
[encodeURIComponent](<a href=3D"https://developer.mozilla.org/en-US/docs/We=
b/JavaScript/Reference/Global_Objects/encodeURIComponent#description" rel=
=3D"noreferrer" target=3D"_blank">https://developer.mozilla.org/en-US/docs/=
Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description</a>)=
 <br>
for more details.<br>
<br>
3) Sort the query parameters by key (alphabetically). This is referred <br>
to as the &quot;payload&quot;. Example: <br>
`custom1=3DCUSTOM1_PARAM_VALUE&amp;custom2=3DCUSTOM2_PARAM_VALUE&amp;defaul=
tDescription=3Dexample&amp;id=3Db6cb8e81e3&amp;maxWithdrawable=3D7000&amp;m=
inWithdrawable=3D5000&amp;nonce=3Dd585674cf991dbbab42b&amp;tag=3DwithdrawRe=
quest`<br>
<br>
4) Sign the payload (the sorted query string) using the API key secret. <br=
>
Signatures are generated using HMAC-SHA256, where the API key secret is <br=
>
the key.<br>
<br>
5) Append the signature to the payload as follows: <br>
`custom1=3DCUSTOM1_PARAM_VALUE&amp;custom2=3DCUSTOM2_PARAM_VALUE&amp;defaul=
tDescription=3Dexample&amp;id=3Db6cb8e81e3&amp;maxWithdrawable=3D7000&amp;m=
inWithdrawable=3D5000&amp;nonce=3Dd585674cf991dbbab42b&amp;tag=3DwithdrawRe=
quest&amp;signature=3DHMAC_SHA256_SIGNATURE`.<br>
<br>
You can find more details here:<br>
<br>
<a href=3D"https://github.com/chill117/lnurl-node#how-to-implement-url-sign=
ing-scheme" rel=3D"noreferrer" target=3D"_blank">https://github.com/chill11=
7/lnurl-node#how-to-implement-url-signing-scheme</a><br>
<br>
<br>
I would change a few things with this scheme to fit better with the <br>
use-case you describe. For example:<br>
<br>
* Remove the &quot;tag&quot; and LNURL-specific parameters<br>
<br>
* Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key <b=
r>
signing instead. The lnurl-auth subprotocol has an interesting approach <br=
>
to protecting user privacy while allowing verification of signatures. <br>
See for more details on that:<br>
<br>
<a href=3D"https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md" =
rel=3D"noreferrer" target=3D"_blank">https://github.com/fiatjaf/lnurl-rfc/b=
lob/master/lnurl-auth.md</a><br>
<br>
<br>
- chill<br>
<br>
<br>
On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:<br>
&gt; I never liked BIP70. It was too complex, had too many features, and wh=
en<br>
&gt; people discuss it, they do not even agree on what the main feature was=
.<br>
&gt;<br>
&gt; Nevertheless, there is ONE feature of BIP70 that I find useful: the fa=
ct<br>
&gt; that payment requests were signed. I am making this post to discuss th=
is.<br>
&gt;<br>
&gt; When I send bitcoins to an exchange, I would like to receive a signed<=
br>
&gt; request. I want to have a proof that the exchange asked me to send coi=
ns<br>
&gt; to that address, in case it has been hijacked by some intern working<b=
r>
&gt; there. If that feature was implemented by an exchange, it would guide =
my<br>
&gt; decision to use that exchange over its competitors.<br>
&gt;<br>
&gt; I do not think that a single exchange ever implemented that, but I gue=
ss<br>
&gt; this is because BIP70 is a terrible standard. LN payment requests are<=
br>
&gt; signed, do not require SSL, do not require interactivity, and therefor=
e<br>
&gt; exchanges use them. Can&#39;t we achieve the same for on-chain payment=
s? Is<br>
&gt; anyone working on that?<br>
&gt;<br>
&gt; I would be more than happy to remove BIP70 support from Electrum, if<b=
r>
&gt; there was another standard for signed requests.<br>
&gt;<br>
&gt; Thomas<br>
&gt;<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>

--000000000000d29d9205bbb08274--