1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
Return-Path: <chill@degreesofzero.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 826A0C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 10:55:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 6879C606A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 10:55:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id wYpCYrA5kTFM
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 10:55:35 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
id 33025606C4; Fri, 19 Feb 2021 10:55:35 +0000 (UTC)
X-Greylist: delayed 00:21:44 by SQLgrey-1.8.0
Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com
[209.85.208.176])
by smtp3.osuosl.org (Postfix) with ESMTPS id BF438606A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 10:55:32 +0000 (UTC)
Received: by mail-lj1-f176.google.com with SMTP id e17so17929656ljl.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 02:55:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=degreesofzero-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding:content-language;
bh=qRcWizEAoSvmf21OsmHstdaPo8ltL3wr+P4ovpVvkLY=;
b=T+blpEZAFnnjsWYstMjCjqEhITlAY7meVr6sHgh7rOfZZw9kPOeZ28ndU6j9zfh+Vj
l/TBr61X7aIwPDao4Brm4u98SmVSeF7H3Hqsll/uIm/vhyoeURkw3nLLM2L4DTOeKYmo
MOCNntvpoOLs7oO+Ttrry0QWXhCHjHRtwph7lELWQ2HlNaVkomoFSLAM20jTCD5jByT5
mLsHiO7ycBOlFrVFAtWWxMdiKAX4VdzTSwyJDXZG8d8mHZ7n0gUv70+uqFWbrJxZ01sT
wGjqnOmMDbrLpAtTqEb3kTXG3+O9RKGA54INCvV2EAC90zhBrSFKPHnJdzLTaktrNzZl
pWJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=qRcWizEAoSvmf21OsmHstdaPo8ltL3wr+P4ovpVvkLY=;
b=BdazHsjrLSWjPhAC1+lfyJ3u3Pn5FyeoPuWU0rM8MlEL9rcefp7FS0BUMV5/vWeyvy
xznaPbmmsSl5EfJnkNdYLiSVlF2FDSepmubnnJp3b1swdkAX/lg1fzTSnUBmFk6ywTxS
cAajkAxEfUOZmufPqYRMbGNvDvW4wAIBPm98drtR+T0NzJRspBKp0w6mIuAPUvkP/xEP
0j8kO+ATiCXEvX8gqOpaApv4I7uB0Ybjp26136s45p1mL863KkzAilgo8lB6Z3Isl7GI
4rYJlvKHw/lwij11GJFumdSZYjDwv/UxJuSAcq2DyP7PvimdK9fDA4DZV9bCm55wjI43
Bq9A==
X-Gm-Message-State: AOAM530apO3VJ5VTAcbdA1LYqZsjeA14zCyszuhWbBU8LkR4JT2OMGq5
1qkAQzelrACnyhHe4c505mqA4VnMuRO10A==
X-Google-Smtp-Source: ABdhPJxQ2eu2a6XBYvnSyspT+SL2HHgKKVBviizcYdcxPjamUXEH1Wf/DkXfvWw64BNXlCg+dU0tDg==
X-Received: by 2002:aa7:d80b:: with SMTP id v11mr8549645edq.17.1613730826713;
Fri, 19 Feb 2021 02:33:46 -0800 (PST)
Received: from [192.168.88.250] (ip-86-49-240-155.net.upcbroadband.cz.
[86.49.240.155])
by smtp.gmail.com with ESMTPSA id w2sm3457661edq.77.2021.02.19.02.33.45
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 19 Feb 2021 02:33:46 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <63e9654c-44b8-740b-79a7-bb58f7bd198c@electrum.org>
From: Charles Hill <chill@degreesofzero.com>
Message-ID: <b60a7654-0252-90af-7ec1-b3de3ed74ae7@degreesofzero.com>
Date: Fri, 19 Feb 2021 11:33:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <63e9654c-44b8-740b-79a7-bb58f7bd198c@electrum.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailman-Approved-At: Fri, 19 Feb 2021 12:42:43 +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: Fri, 19 Feb 2021 10:55:36 -0000
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
>
|
