diff options
| author | P G <philipglazman@gmail.com> | 2021-03-04 07:56:10 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-04 17:05:43 +0000 |
| commit | 6b3ddcc9e931e2c700adbf837a5af835c998e7f8 (patch) | |
| tree | 4bc206a4451dd089c7485018840551440d9a474a | |
| parent | 2e95203b0c3c05edc727f9897fece81cdc8fd43f (diff) | |
| download | pi-bitcoindev-6b3ddcc9e931e2c700adbf837a5af835c998e7f8.tar.gz pi-bitcoindev-6b3ddcc9e931e2c700adbf837a5af835c998e7f8.zip | |
Re: [bitcoin-dev] BIP70 is dead. What now?
| -rw-r--r-- | c0/7bd274d998108846a43b890ef894a397fd5a03 | 481 |
1 files changed, 481 insertions, 0 deletions
diff --git a/c0/7bd274d998108846a43b890ef894a397fd5a03 b/c0/7bd274d998108846a43b890ef894a397fd5a03 new file mode 100644 index 000000000..e866678ba --- /dev/null +++ b/c0/7bd274d998108846a43b890ef894a397fd5a03 @@ -0,0 +1,481 @@ +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>> 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 "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.</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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org= +">bitcoin-dev@lists.linuxfoundation.org</a>> 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 'pull= + request'?</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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_= +blank">bitcoin-dev@lists.linuxfoundation.org</a>> 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'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'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.</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'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.<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 <<a href=3D"mailto:= +bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.= +linuxfoundation.org</a>> 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'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`, "Server <br> +parameters" (see [Subprotocols](#subprotocols) above), and any custom = +<br> +parameters. The `id` parameter should be equal to the API key's ID. <br= +> +Example: <br> +`id=3Db6cb8e81e3&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRequest= +&minWithdrawable=3D5000&maxWithdrawable=3D7000&defaultDescripti= +on=3Dexample&custom1=3DCUSTOM1_PARAM_VALUE&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= +> +- _ . ! ~ * ' ( )`. 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 "payload". Example: <br> +`custom1=3DCUSTOM1_PARAM_VALUE&custom2=3DCUSTOM2_PARAM_VALUE&defaul= +tDescription=3Dexample&id=3Db6cb8e81e3&maxWithdrawable=3D7000&m= +inWithdrawable=3D5000&nonce=3Dd585674cf991dbbab42b&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&custom2=3DCUSTOM2_PARAM_VALUE&defaul= +tDescription=3Dexample&id=3Db6cb8e81e3&maxWithdrawable=3D7000&m= +inWithdrawable=3D5000&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRe= +quest&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 "tag" 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> +> I never liked BIP70. It was too complex, had too many features, and wh= +en<br> +> people discuss it, they do not even agree on what the main feature was= +.<br> +><br> +> Nevertheless, there is ONE feature of BIP70 that I find useful: the fa= +ct<br> +> that payment requests were signed. I am making this post to discuss th= +is.<br> +><br> +> 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<br> +> to that address, in case it has been hijacked by some intern working<b= +r> +> there. If that feature was implemented by an exchange, it would guide = +my<br> +> decision to use that exchange over its competitors.<br> +><br> +> I do not think that a single exchange ever implemented that, but I gue= +ss<br> +> 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<br> +> exchanges use them. Can't we achieve the same for on-chain payment= +s? Is<br> +> anyone working on that?<br> +><br> +> I would be more than happy to remove BIP70 support from Electrum, if<b= +r> +> there was another standard for signed requests.<br> +><br> +> Thomas<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> +_______________________________________________<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-- + |