path: root/c0/7bd274d998108846a43b890ef894a397fd5a03

Return-Path: <philipglazman@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B1A37C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 17:05:41 +0000 (UTC)
Received: by mail-ot1-x32c.google.com with SMTP id b8so27893848oti.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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>
 <b60a7654-0252-90af-7ec1-b3de3ed74ae7@degreesofzero.com>
 <CACvH2ek=bM=0vH-skjhr2VnaF47U3eht5P3ukJ7CUnB3V8ZGQQ@mail.gmail.com>
 <CAPeP9hkhJPu_wEa0_qudiUQNb8Lkb7L6Ue1aTVLGrPD0mF6yFw@mail.gmail.com>
In-Reply-To: <CAPeP9hkhJPu_wEa0_qudiUQNb8Lkb7L6Ue1aTVLGrPD0mF6yFw@mail.gmail.com>
From: P G <philipglazman@gmail.com>
Date: Thu, 4 Mar 2021 07:56:10 -0800
Message-ID: <CABkoRmpOJcrtiv+FU7SE8H2FXGV-+-6t+xjEDnmtJZgZk9bvZA@mail.gmail.com>
To: Eoin McQuinn <emcquinn8@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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, 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

<div dir=3D"ltr">Hi Thomas,<div><br></div><div>&gt; Nevertheless, there is =
ONE feature of=C2=A0<span class=3D"gmail-il">BIP70</span>=C2=A0that I find =
useful: the fact</div>that payment requests were signed.<div><br></div><div=
>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 &quot;test&quot; 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.</div><div><br></div><div>- Philip</d=
iv><div><div><br></div></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, Feb 21, 2021 at 5:26 AM Eoin McQuinn =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">What is a &#39;pull=
 request&#39;?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Thomas=
,</div><div><br></div><div>I am working on an experimental implementation [=
1] of a new payment request format in Trezor T. In some respects it&#39;s s=
imilar to BIP-70. The main differences are:</div><div><br></div><div>1. The=
re is no reliance on X.509, since that seems to have been the main reason f=
or BIP-70&#39;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&#39;s more similar to BOLT11.</div><div><br></div><div>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><=
div><br></div><div>3. It uses an optional nonce for replay protection.</div=
><br>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&#39;s computer. It&#39;s not intended for interchange between =
wallets. We haven&#39;t defined the interchange format yet. I intend to cre=
ate a SLIP documenting all this.<br><div><br></div><div>Andrew <br></div><d=
iv><br></div>[1] <a href=3D"https://github.com/trezor/trezor-firmware/compa=
re/andrewkozlik/payreq2" target=3D"_blank">https://github.com/trezor/trezor=
-firmware/compare/andrewkozlik/payreq2</a><br>[2] <a href=3D"https://github=
.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/message=
s-bitcoin.proto#L403-L427" target=3D"_blank">https://github.com/trezor/trez=
or-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#=
L403-L427</a><br>[3] <a href=3D"https://github.com/trezor/trezor-firmware/b=
lob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py" =
target=3D"_blank">https://github.com/trezor/trezor-firmware/blob/andrewkozl=
ik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py</a><br></div><b=
r><div class=3D"gmail_quote"><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.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-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>
_______________________________________________<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><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr"><a href=3D"http://eoin.substack.com" target=3D"_blank">eo=
in.substack.com</a></div></div>
_______________________________________________<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>

--0000000000004b233105bcb802d7--