Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 19FE5C0001 for ; Sat, 20 Feb 2021 15:54:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0EDA685E51 for ; Sat, 20 Feb 2021 15:54:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1SUMIZ0OFsk for ; Sat, 20 Feb 2021 15:54:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) by fraxinus.osuosl.org (Postfix) with ESMTPS id D800B85DF6 for ; Sat, 20 Feb 2021 15:54:09 +0000 (UTC) Received: by mail-ot1-f44.google.com with SMTP id v16so7976540ote.12 for ; Sat, 20 Feb 2021 07:54:09 -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; bh=IJUsWguqrroZ5FkHhpgJNe6gvSGXI0ixtupT2IGCiJo=; b=U//8jBRHvhH/Ez06SrK/oScg8UsJxo8WuNa2YN/PZDQX+KlvWB8GwuBzaIvM126R+B TUvzJ+NVijTYZ+lWRWRiMUT9H0hss7swkyh7F0O28Bc5FEoqra8FBJIZomSLnIaicBII LpzGOgssoq9/KR/Rfe+xmZ7vggUaTTLSXps8lez7cJvN/+0bIyjb//EhVgzzvTZdikKb Tc0pcAWpQmQVk2g36O+ewSvHIdz1DqjFbQ0BQxKT4fuJZs3w/3M7xvU55buT7pVPuzEI aPyWYnqPwgeLBfm3coJV3s8DPWqt8EmerAQZVqZsU2F5Tgv8EkVmKPGh4TfapaYOvyvg KoMw== 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=IJUsWguqrroZ5FkHhpgJNe6gvSGXI0ixtupT2IGCiJo=; b=VrPng8iDAXyaQKuIL7+s5ODPkSopnOJsZZKNFQ390hYhUs1LGbBxlcxysKDHjU8B3M vwb6qfWt9rBh4eWyCHHckrGYaqGxTuy0TFKAO6unZ+9yXV8arSLmhXA/zoD4Uu1C1Dhm hHmIm7GwCancu8ax/GpyKEWR1qcE6SQuQUQwRv+4sApopkJDHD2egYjyPh0lzjT6lit1 5ks1ybyaV+6Rj7IMKmDcvoZnV96sfl4KVTiAQ5C1YLaIll7R6W4YPzavmUm4HqCVnBxK NXKiRdo1i9Z7sjoVitcV+kEbdk+6JRliKvvqhCy69MGQarigIufPVAyAK1geBdWhnirz Upsw== X-Gm-Message-State: AOAM531opqfR7tvRb6obcG56+JwbZDiXB8DSe/raMasCpns/KcjN9fnr 3VimhatEKZkegEE4ZTEnYqlHyDVvu7vhhKy42fU= X-Google-Smtp-Source: ABdhPJwGXHmbFB+eR+Ez67T4/XbXHYCY35M/4NIM93Jyxq5f8oBSbKnrADNZiYUt4Fb7OrZC6rQCDoxgjsig9vPpFYs= X-Received: by 2002:a9d:6c4c:: with SMTP id g12mr10933583otq.53.1613836449036; Sat, 20 Feb 2021 07:54:09 -0800 (PST) MIME-Version: 1.0 References: <63e9654c-44b8-740b-79a7-bb58f7bd198c@electrum.org> In-Reply-To: From: Eoin McQuinn Date: Sat, 20 Feb 2021 15:53:57 +0000 Message-ID: To: Andrew Kozlik , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000453cbc05bbc69485" X-Mailman-Approved-At: Sun, 21 Feb 2021 13:26:05 +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: Sat, 20 Feb 2021 15:54:12 -0000 --000000000000453cbc05bbc69485 Content-Type: text/plain; charset="UTF-8" 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 --000000000000453cbc05bbc69485 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 res= pects it's similar to BIP-70. The main differences are:

<= /div>
1. There is no reliance on X.509, since that seems to have been t= he 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 a= re sending BTC to a trusted exchange service and expecting another cryptocu= rrency in return, say LTC, you want to be sure that you not only have the c= orrect 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 `TxA= ckPaymentRequest` 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 inte= rchange between wallets. We haven't defined the interchange format yet.= I intend to create a SLIP documenting all this.

And= rew

[1] https://github.c= om/trezor/trezor-firmware/compare/andrewkozlik/payreq2
[2] https://gith= ub.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messa= ges-bitcoin.proto#L403-L427
[3] https://github.com/trezor/trezor-firmwa= re/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 <= 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


--
--000000000000453cbc05bbc69485--