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
>