Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B1A37C0001 for ; Thu, 4 Mar 2021 17:05:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 92F994B6DA for ; Thu, 4 Mar 2021 17:05:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T9PBT0jcCMe for ; Thu, 4 Mar 2021 17:05:41 +0000 (UTC) X-Greylist: delayed 01:09:18 by SQLgrey-1.8.0 Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by smtp4.osuosl.org (Postfix) with ESMTPS id 4FBD1400D2 for ; Thu, 4 Mar 2021 17:05:41 +0000 (UTC) Received: by mail-ot1-x32c.google.com with SMTP id b8so27893848oti.7 for ; Thu, 04 Mar 2021 09:05:41 -0800 (PST) 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 :cc; bh=HgrDf6DClSV92tzZAS/tgC33tUaBcRtmC/hfOi77U9U=; b=Pxl8WI5KbXIffq5mtlprRypBfY4aeEV3qfNB75yFoyv678pLZC1APp0QBs0GV5U0t/ VVux7vHqqlyyIfhJqqlg7lJl0xkE1BWf46u1PJ34m3x5UfXo5SzHRcWeisexBTZBL3hi zpPXlv2gvl+xxlAslzeOBMdgPiMp3zDmiqozlBD//LSoCLWNt82+MV2QkMToFw+G9R+V 6t1ybpFAnDFlVg45gzhwTYQzraDDc0t2cfNxGVy07zWrNvQkVNXam+XcOTT1swdkW6+V uoYc9AQ/pXUAq8uZs9i2JaQuJwMkKNgGjBBDaUjLytgvvrGSMyofPZYvzTH6cA5/8cmB FTUQ== 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:cc; bh=HgrDf6DClSV92tzZAS/tgC33tUaBcRtmC/hfOi77U9U=; b=nY3QR3OD8JsZSv1BmSyyrGbhs3VvWVJNFIcd0EJMw8QI0XtK27u7FYPmZwT0BsHxd6 fK721Ayl0cldn+qOQvKc03gY5DW16Aj5jjlu4qJTNIcwgeGTnK+HmT+RxQZlaKxJvaU3 CQbZw1xuCnxepiwTzMbMorjQYt/GCs6k3Lvn6LFA2hBNjKbWOr+blWcVTn1KElp6GWm0 oEqWIzgZK7WFNALg2jCe5sH0EFsmSIwtKCoCY71H52L9jWbwNQGOr9djsuxFD1h98g2S 66vlngZk1O7bjP1BCGi23V/qbwGdf/g9dJKqep0YtxJ8/ppC8ZQt4z7vDhJQ1V527qEG UdLA== X-Gm-Message-State: AOAM533F7hkBO3Du8RCXmDrTqcae4XYtmdkuP0n9ODB2m1reJFU8vucJ gMnx1bVaeLIjwkw03y2swTIjm06zMJkD7+uYBrdTaHkCv7U= X-Google-Smtp-Source: ABdhPJyjZppKxVlAeIHOPdr6QFzKz0vTv2NBq4zE6ZyiRFBeySRmJQU9H97j6kIDloPxs6vn1uxzrNoGX8G1OV19D8w= X-Received: by 2002:a05:6830:135a:: with SMTP id r26mr3863452otq.77.1614873382035; Thu, 04 Mar 2021 07:56:22 -0800 (PST) MIME-Version: 1.0 References: <63e9654c-44b8-740b-79a7-bb58f7bd198c@electrum.org> In-Reply-To: From: P G Date: Thu, 4 Mar 2021 07:56:10 -0800 Message-ID: To: Eoin McQuinn , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000004b233105bcb802d7" X-Mailman-Approved-At: Thu, 04 Mar 2021 18:15:21 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 17:05:43 -0000 --0000000000004b233105bcb802d7 Content-Type: text/plain; charset="UTF-8" Hi Thomas, > Nevertheless, there is ONE feature of BIP70 that I find useful: the fact that payment requests were signed. In addition to signing the actual payment request, a nice addition to a new payment protocol is an assurance that the receiving address can in fact spend later on. Many users send "test" transactions to a wallet address before sending their intended full amount. If the protocol includes a response containing a signature using BIP322, there is better assurance for the sender. Outside of the merchant context, a sender can use the protocol to have peace of mind when sending between their own wallets. This should likely be an optional parameter given cold storage setups cannot return a signature quickly. - Philip On Sun, Feb 21, 2021 at 5:26 AM Eoin McQuinn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What is a 'pull request'? > > On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 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 >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > -- > eoin.substack.com > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000004b233105bcb802d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,

> Nevertheless, there is = ONE feature of=C2=A0BIP70=C2=A0that I find = useful: the fact
that payment requests were signed.

In addition to signing the actual payment request, a nice addition to a ne= w payment protocol=C2=A0is an assurance that the receiving address can in f= act spend later on. Many users send "test" transactions to a wall= et address before sending their intended full amount. If=C2=A0the protocol = includes a response containing a signature using BIP322, there is better as= surance for the sender. Outside of the merchant context, a sender can use t= he protocol to have peace of mind when sending between their=C2=A0own walle= ts. This should likely be an optional parameter=C2=A0given cold storage set= ups cannot return a signature quickly.

- Philip


On Sun, Feb 21, 2021 at 5:26 AM Eoin McQuinn = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
What is a 'pull= request'?

On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Thomas= ,

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

1. The= re is no reliance on X.509, since that seems to have been the main reason f= or 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 use= d to solve a similar problem with coin exchange. When you are sending BTC t= o 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 addre= ss, but also that the exchange service has your correct LTC address.
<= div>
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 mes= sage 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 cre= ate a SLIP documenting all this.

Andrew

[1] https://github.com/trezor/trezor= -firmware/compare/andrewkozlik/payreq2
[2] https://github.com/trezor/trez= or-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#= L403-L427
[3] https://github.com/trezor/trezor-firmware/blob/andrewkozl= ik/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 <= br> 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=3Db6cb8e81e3&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRequest= &minWithdrawable=3D5000&maxWithdrawable=3D7000&defaultDescripti= on=3Dexample&custom1=3DCUSTOM1_PARAM_VALUE&custom2=3DCUSTOM2_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=3DCUSTOM1_PARAM_VALUE&custom2=3DCUSTOM2_PARAM_VALUE&defaul= tDescription=3Dexample&id=3Db6cb8e81e3&maxWithdrawable=3D7000&m= inWithdrawable=3D5000&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRe= quest`

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=3DCUSTOM1_PARAM_VALUE&custom2=3DCUSTOM2_PARAM_VALUE&defaul= tDescription=3Dexample&id=3Db6cb8e81e3&maxWithdrawable=3D7000&m= inWithdrawable=3D5000&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRe= quest&signature=3DHMAC_SHA256_SIGNATURE`.

You can find more details here:

https://github.com/chill11= 7/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/b= lob/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 wh= en
> 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 fa= ct
> that payment requests were signed. I am making this post to discuss th= is.
>
> When I send bitcoins to an exchange, I would like to receive a signed<= br> > request. I want to have a proof that the exchange asked me to send coi= ns
> 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 gue= ss
> this is because BIP70 is a terrible standard. LN payment requests are<= br> > signed, do not require SSL, do not require interactivity, and therefor= e
> exchanges use them. Can't we achieve the same for on-chain payment= s? 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/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000004b233105bcb802d7--