Charles Hill [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-19 📝 Original message:Hi, Thomas, I developed a ...
📅 Original date posted:2021-02-19
📝 Original message: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
>
📝 Original message: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
>