Charles Hill [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-02-19 to 2021-10-20
💬 Posted a total of 2 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:00:16

- reply

📅 Original date posted:2021-10-20
📝 Original message:Hello, Owen,
The GPG signature verification has changed for bitcoin core version 22
and later. There were two main changes:
1) The sha256 checksums are now in a separate file from the GPG
signatures. So download a new file named "SHA256SUMS" (contains the
checksums) and also the "SHA256SUMS.asc" which contains the signatures.
2) The signature file now contains multiple signatures. These signatures
are generated by multiple "builders" who have provided their own public
keys to verify against. Not all builders will provide a signature for
each release.
You can find more information at bitcoincore.org/en/download/ [1] under
the "Linux verification instructions" section - click to expand.
Instructions about where to find and how to import the full list of
"builder" public keys can be found in the bitcoin core github repo [2].
> I also notice that, as of 22.0, Wladimir is no longer signing the
releases, and I have no trust in my gpg network of the people who seem
to have replaced him.
The list of "builder" public keys includes many long-time bitcoin core
contributors as well as Wladimir's. Caution is always warranted but
please do not spread unnecessary FUD.
- chill
[1] https://bitcoincore.org/en/download/
[2] https://github.com/bitcoin/bitcoin/tree/master/contrib/builder-keys
On 10/20/21 8:20 PM, Owen Gunden via bitcoin-dev wrote:
> On Wed, Oct 20, 2021 at 04:47:17PM +0200, Prayank wrote:
>>> It seems confusing to have two sites that seemingly both represent
>>> bitcoin core.
>> There is only one website which represents Bitcoin Core full node
>> implementation. You can download Bitcoin Core from
>> https://bitcoincore.org
> I also notice that, as of 22.0, Wladimir is no longer signing the
> releases, and I have no trust in my gpg network of the people who seem
> to have replaced him.
>
> Given the level of security at stake here, my eyebrows are raised at
> this combination of items changing (new website + new gpg signers at the
> same time).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:00:16

- reply

2023-06-07 18:29:06

- reply

📅 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
>

2023-06-07 18:29:06

- reply