[bitcoindev] Re: BIP idea: Timelock-Recovery storage format

'orenz0' via Bitcoin Development Mailing List
2026-03-16T10:48:46Z

> I couldn't figure out how to subscribe to the group without using my Gmail address,

You can create a Google account with a non-gmail email - but I'm not sure about privacy issues (i.e. Google may require a phone number).

> Would be worth mentioning in the description of the "checksum" field that it is to be entirely omitted during checksum calculation. That is a noteworthy exception to the "mandatory" constraint.

Noted. I'll create a PR for that.

> What's the point of doing that? Given that order is important, why wouldn't you just output the entries of the object sorted by their keys?

Actually I checked again the Nostr protocol and it's really hashing an array of the object values in a fixed key-order, without the keys themselves. However, this might break if the standard has optional fields, because without the key-name you can't be sure which field the value belongs to.

The Javascript implementation of this is trivial: `JSON.stringify(Object.entries(obj).sort())`, and so would be a Python implementation.
I'm pretty sure the ECMAScript standard (https://262.ecma-international.org/16.0/index.html#sec-json.stringify ) is very specific regarding newlines and non-ascii characters.

Regards,
Oren

Sent with Proton Mail secure email.

On Friday, 13 March 2026 at 18:29, Matt Whitlock <bitcoin@mattwhitlock.name> wrote:

> On Friday, 13 March 2026 12:05:41 EDT, orenz0 wrote:
> > Hi Matt,
> > I can't find your message on https://groups.google.com/g/bitcoindev so I'll answer directly from my email.
>
> I couldn't figure out how to subscribe to the group without using my Gmail address, so when I tried to post from my bitcoin@mattwhitlock.name address, the listserv rejected my post. Oh well.
>
> >> * What should be the value of the "checksum" field during the checksum calculation? Null? An empty string? Absent entirely? None of those options satisfy the schema, which mandates that the value must be a string of 8 to 64 characters. Perhaps a string of eight zeros?
> >
> > The checksum field should be absent entirely during checksum calculation.
>
> Would be worth mentioning in the description of the "checksum" field that it is to be entirely omitted during checksum calculation. That is a noteworthy exception to the "mandatory" constraint.
>
> >> * What is "an array of key, value pairs"? Is it [{"key":"one","value":1},{"key":"two","value":2}]? The example JavaScript code implies that it should be [["one",1],["two",2]], but this is not spelled out in the normative text. Typically in a specification, example code is non-normative, and all necessary information to implement the spec is provided in the normative text.
> >
> > Your interpretation is correct, key-value pairs are exactly converting an object like {"one":1,"two":2} into [["one",1],["two",2]].
>
> What's the point of doing that? Given that order is important, why wouldn't you just output the entries of the object sorted by their keys? (I think you're going to tell me that you have no control over the order that ECMAScript's JSON.stringify() function outputs an object's keys, and I'm going to suggest not using a function whose output you can't precisely control.)
>
> > How would you improve the description of "...by converting the top-level JSON object to an array of [key, value] pairs" (in https://github.com/bitcoin/bips/blob/master/bip-0128.mediawiki#checksum-calculation )?
>
> "...by constructing an array of arrays, where each element of the outer array is an array of two elements, the first of which is the key of a property in the object and the second of which is the value of that property."
>
> > Converting objects into key-value pairs (i.e. with the Object.entries() function) is pretty common when the order of the keys is important - i.e. when you need a consistent hash. For example it is used in the Nostr protocol before signing event objects.
>
> That's a very ECMAScript-centric notion. JSON is a generic structured data transmission format that most high-level programming languages have adopted/implemented, and not all languages have an equivalent of Object.entries(), and even when they do, it may not do the same thing as ECMAScript's. For instance, jq's "to_entries" filter converts an object into an array of objects:
>
> $ jq -c 'to_entries' <<<'{"one":1,"two":2}'
> [{"key":"one","value":1},{"key":"two","value":2}]
>
> Java's Map.entrySet() method returns a Set view of a Map, in which the elements implement the Map.Entry interface, which exposes "key" and "value" properties.
>
> C++'s std::map::iterator dereferences to a std::pair whose "first" data member holds an entry's key and whose "second" data member holds the entry's value.
>
> Etc., etc. The point is: the world does not revolve around ECMAScript, so a protocol specification that incorporates by reference a particular algorithm from ECMAScript is under-specified for most consumers.
>
> >> * What does "stringifying" mean? There are many ways to encode abstract structured data into JSON. For instance, just look at all the possible "flags" that can be passed to PHP's json_encode function: https://www.php.net/json_encode . Are non-ASCII characters to be encoded in UTF-8 or as hex escapes? How about control characters? How are quotation marks to be escaped: as a backslash and a quotation mark or as a Unicode hex escape? Is there any optional whitespace between terminals in the encoding? If so, where, and are the line endings LF or CR+LF?
> >
> > I think we should agree that "stringifying" means using Javascript's JSON.stringify() function with a single parameter (no "replacer" and no "space" parameters). All other programming languages should follow the ECMAScript specification.
>
> Similar comments apply as above. Additionally, is the output of JSON.stringify() even guaranteed to be identical across all versions and implementations of ECMAScript? For instance, might some implementations choose to escape newline characters as "\n" while others might write code point U+000A directly into the output without escaping it? Unless ECMAScript specifies *exactly* what the function is to do in every case and guarantees that the specification will never change, you're under-specifying how your object is supposed to be encoded.
>

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/T9ttcpWk8Flqa-fqSfqKAhIyFavsFtfq-CKUK9VS1i4juyLIC7mV5HGQIfthZd2rixggBPLDsNfkvydMbQRYB5BPi4EhQNRlzIG9mnQlpI8%3D%40protonmail.com.