+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

+>

+