Hi,

The BCR-2020-005 paper says (about CBOR byte strings)

"If the encoded byte string has 65536..2^32-1 bytes, it is preceded by (0x60, b1, b2, b3, b4) where b(n) is the big-endian four byte length of the following byte string."

This is not correct. According to https://tools.ietf.org/html/rfc7049 the header for 65536+ byte strings is 0x5a (Indeed, the value after 0x59. 0x60 is the header of shortest UTF-8 strings)

Some specifications, such as BCR-2020-005, are specified in terms of reference implementations. Ideally, specifications should be complete without those implementations, but if its unavoidable we propose them be released into the public domain for maximal interoperability.

Our concrete issue is that the SeedHammer implementation is in the public domain and it adds friction to implement your specifications without becoming a derivative and thus having to include your license.

On the paper BC32, there is a Todo on Checksum parameters, any detail info about it? what the parameters are currently using?

and I have check out the code on https://github.com/BlockchainCommons/bc-bech32/blob/master/src/segwit_addr.c

use version_bech32_bis(0x3fffffff) XOR with checksum, is it just for seperating with the origin bech32 ?

Re: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-0003-uri-binary-compatibility.md

Should we define a new specification that is bech32 but addresses the HRP collision problem with the URI reserved character set? Maybe call it bc32?

I'm also trying to get the parameters from @sipa for a possible 64-128 byte optimized form that could also form a new specification. (see Twitter thread https://twitter.com/pwuille/status/1250663639930953729?s=20 )

I like bech32 for its ability to be read over phone and to offer both error detection and some error correction. But we have to specify it carefully, quoting @sipa in BIP-0173:

An unfortunate side effect of error correction is that it erodes error detection: correction changes invalid inputs into valid inputs, but if more than a few errors were made then the valid input may not be the correct input.…Because of this, implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.

This limitation also makes bech32 as an encoding format limited in another way that Base64URL format is not — it is only suitable for short lengths.

Either, or both of these new specifications I might be able to run the flag up to get standardized in IETF or W3C.

cc/ @maaku @kanzure @Fonta1n3 @ksedgwic

-- Christopher Allen

crypto-hdkey can have names, but crypto-output cannot. This issue proposes adding a name property to crypto-output.

This is useful to identify a particular wallet setup, in particular where the names of individual shares are not important. For SeedHammer, each steel plate represents a share, but without descriptor names a user can't easily know which plates form a wallet.

One workaround is to give every crypto-hdkey in a descriptor the same name. However, at least Sparrow enforces unique names, for good reasons. Adding numbers ("My Cold Storage #1", "My Cold Storage #2"...) is feasible, but ugly and confusing.

This is not really an issue just a question.

Prompted by discussions at wizardsardine/liana#539, this is a sketch for a BIP proposal for serializing wallet descriptors. I raise it here for comments and because Blockchain Commons is a recognized standards body for Bitcoin specifications. If there's enough interest, it should be fleshed out and proposed as a BIP.

A Go implementation written from scratch is here: https://github.com/seedhammer/bip-serialized-descriptors

At the high level, this is a binary and compact serialization specification for the [wallet-policies] BIP.

• Binary format, based on the [BIP174] PSBT format.
• Descriptor is in text, as described in BIPs 380-386 (+389). Like the wallet-policies BIP, keys are always by indexed reference.
• Key references uses the wallet-policies format @<key-index>.
• Miniscript is trivially supported, except pk(NAME) expressions are replaced with key indexes.

Borrowing from BIP174, the format would be

 <desc> := <magic> <global-map> <key-map>*
 <magic> := 0x64 0x65 0x73 0x63 0xFF
 <global-map> := <keypair>* 0x00
 <key-map> := <keypair>* 0x00
 <keypair> := <key> <value>
 <key> := <keylen> <keytype> <keydata>
 <value> := <valuelen> <valuedata>

The current test for the Fisher-Yates Shuffle returns a different list of shuffled indexes for each iteration of the map method because the same random number generator variable is reused for all calls on the shuffled() method. This does not invalidate the test, but makes it less obvious what the count argument does in the shuffled() method. When implementing myself, I was initially under the impression that the count somehow influenced the returned result, which was puzzling. Moreover, I was contrasting this implementation with the Hummingbird implementation of this method, which always returns the fully shuffled list. I was expecting the count to simply help me return a subset of the list, but since all the lists were different on each iterations in the Swift test, I got confused for a little bit until I realized that the issue was simply that the rng was being reused for each call.

Current test

func testShuffle() {
    let rng = Xoshiro256(string: "Wolf")
    let indexes = 1...10
    let values = Array(indexes)
    let result = indexes.map { count in
        shuffled(values, rng: rng, count: count)
    }
    let expectedResult = [
        [6],
        [5, 8],
        [4, 10, 5],
        [7, 10, 3, 8],
        [10, 8, 6, 5, 1],
        [1, 3, 9, 8, 4, 6],
        [4, 6, 8, 9, 3, 2, 1],
        [3, 9, 7, 4, 5, 1, 10, 8],
        [3, 10, 2, 6, 8, 5, 7, 9, 1],
        [1, 5, 3, 8, 2, 6, 7, 9, 4, 10]
    ]
    XCTAssertEqual(result, expectedResult)
}

func testShuffle() {
    let indexes = 1...10
    let values = Array(indexes)
    let result: [[Int]] = indexes.map { count in
        let rng = Xoshiro256(string: "Wolf")
        return shuffled(values, rng: rng, count: count)
    }
    let expectedResult = [
        [6],
        [6, 4],
        [6, 4, 9],
        [6, 4, 9, 3],
        [6, 4, 9, 3, 10],
        [6, 4, 9, 3, 10, 5],
        [6, 4, 9, 3, 10, 5, 7],
        [6, 4, 9, 3, 10, 5, 7, 8],
        [6, 4, 9, 3, 10, 5, 7, 8, 1],
        [6, 4, 9, 3, 10, 5, 7, 8, 1, 2]
    ]
    XCTAssertEqual(result, expectedResult)
}

Abstract

In bcr-2020-012-bytewords.md most of the words look to be ordered alphabetically. The exception I ran into is
the last line:

0xf8: yoga yurt zaps zest zinc zone zoom zero

The same issue is in both (c and c++) implementations of bytewords.

This causes lots of difficulties on the UI side in lethekit.

Hi, I think the second test vector on https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-0004-bc32.md probably not correct.

should be 'my6qv05zqq0wcpv9aeq6khvwfdcr5jlp7uawcg0pgwgjc4shjm6xu' after encoded?

I have tested using the test case for https://github.com/BlockchainCommons/bc-bech32

Having re-implemented/ported URKit to Java, mainly in order to assist with the transfer of PSBTs over QR, I am wondering why there is no registered type crypto-psbt. I am currently using ur:bytes/ with the CBOR encoded bytes of the serialized PSBT.

I realise PSBTs are Bitcoin-only, but it seems like such a clear use for the standardisation that URs provide given that PSBTs are becoming the standard of partial transactions when signing between different QR capable devices.

The choice to use the first four bytes of a CRC32 hash of a Bytewords body is open for comment. This issue is being tracked here. Please leave your comments below.

To help with guided recovery on clients, and metadata for collaborative recovery services (BlockchainCommons/Community#149), it is useful to have a type encoding just the config parameters of a unique SSKR split, without the share values.

The following parameters from https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md would be useful as part of this type:

• identifier (id)
• group-threshold (Gt)
• group-count (g)
• member-threshold (t) per group

sha256 digest of the message is 32 bytes, when converted to bc2 it is 58 characters long.
If I understand correctly it is only used to check the integrity of all pieces.

I have two suggestions:

• take only a part of the digest, for example 8 bytes instead of all 32, it is good enough for the checksum, and error correction is not possible with hash digests anyways
• allow transmitting hash digest only in one QR code, not in all of them - I don't see a reason to waste QR code capacity and transmit the same data in all frames. Or make it optional for sequential QR codes as well and let the implementation decide if they want to use it or not.

Currently the BCR-2020-006 standard defines the crypto-address UR type but the definition is a little bit ambiguous.

On Example/Test Vector 1 the specified P2PKH address 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 does not include the type of the address in the encoded CBOR, making it ambiguous to differentiate between it P2SH and P2PKH as these are both 20-byte hashes.

On the CDDL comment it should also:

- ;   For addresses of type `p2wphk`, the sha256 of the script bytes (32 bytes).
+ ;   For addresses of type `p2wpkh`, the witness program (20 bytes).

Hi,
I am creating an arduino version of UR. https://github.com/aaronwu2017/BitConserve-UR/tree/master/main
I am in the process of adding it to the arduino library manager
Could you add this to the implementation section?
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
thanks

Abstract

Across HD keys and output descriptors the test vectors are incomplete wrt depth and child number:

EDIT: removed incorrect example and showed a new example:

Output Descriptors

• incorrect depth. In certain cases depth must be provided despite derivation-path presence:

04 ; version 4
88b21e ; `xpub`
04 ; depth 4
78412e3a ; parent fingerprint
fffffffe ; child number
637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e29 ; chain code
02d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0 ; key data
7e652001 ; base58 checksum

    In the CBOR diagnostic notation:

403( ; public-key-hash
	303({ ; crypto-hdkey
		3: h'02d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0', ; key-data
		4: h'637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e29', ; chain-code
		6: 304({ ; origin: crypto-keypath
			1: [ ; components
				44, true, 0, true, 0, true ; 44'/0'/0'
			],
			2: 3545084735 ; origin-fingerprint
		}),

#[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub enum Payload {
    /// P2PKH address
    PubkeyHash(PubkeyHash),
    /// P2SH address
    ScriptHash(ScriptHash),
    /// Segwit addresses
    WitnessProgram {
        /// The witness program version
        version: bech32::u5,
        /// The witness program
        program: Vec<u8>,
    },
}

The Fragment Chooser section of the Multipart UR Implementation Guide states the following:

When seqNum is greater than seqLen, the big-endian serialized seqNum and checksum are concatenated and then passed through SHA-256 to generate a 256-bit seed for the PRNG.

(seqNum || checksum) -> SHA256 -> Xoshiro256

I have not found this to be the case in the URKit, Hummingbird, ur-rs, or foundation-ur-py libraries.

Instead, a 64-bit seed composed of the joined seqNum and checksum is passed to the Xoshiro256 RNG without hashing. Note that Xoshiro internally does sha-256 hash the seed when initialized, so that might be where this came from, or maybe where I'm getting confused? In any case, the seed provided to the Xoshiro constructor is not a 256-bit seed.

The UR encoder and decoder have to agree on the degree and selection of part indices for any given fragment, so the pseudo-random algorithm has to be followed by every implementation. However:

• Choosing a degree depends on an almost 100 line RandomSampler just to get the complexity from O(n) or O(log n) to O(1)[*].
• RandomSampler uses doubles for its computations; floating point computations are notoriously hard to make deterministic across platforms, and they're slow on embedded devices. RandomSampler even has a comment,

        while !S.isEmpty {
            // can only happen through numeric instability
            probs[S.removeLast()] = 1
        }

In BCR-2020-007, the specification for a derived-key includes a crypto-keypath for the key origin. However, crypto-keypath specifies a parent-fingerprint field instead of a master-fingerprint field, as would be normal for key origin information. This leads to a number of issues, and I believe the specification for a derived-key needs to be changed.

Note that the parent fingerprint is necessary in order to construct the xpub from a crypto-hdkey UR encoding. Therefore, the example in Test Vector 2 encodes the parent fingerprint into the key origin crypto-keypath, instead of the master fingerprint. This means the xpub can be reconstructed, but the master fingerprint is lost.

The issue is more serious when considering BCR-2020-010: Output descriptors. Considering Test Vector 4, we see here that the master fingerprint is encoded into the origin crypto-keypath instead of the parent fingerprint. This means that the parent fingerprint (in this case 0x78412e3a) is lost, and the xpub - and therefore the output descriptor - cannot be reconstructed.

My suggestion to resolve these issues is to add a further crypto-keypath to derived-key in BCR-2020-007 which contains the parent fingerprint, one path component with the child number, and the depth the HD key was derived at (as per BIP32). This means all the fields necessary to derive the xpub are available independently of the origin crypto-keypath.

derived-key = (
        ...
        ? parent: #6.304(crypto-keypath)
)

...
parent = 8

In https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md, should we have a version bit or bytes for SSKR so that we are not 100% intersecting the binary version of SLIP-39? Not that they are exposing that anywhere. Is the customization string ofshamir enough? I was always a bit uncomfortable with that trick in case we ever wanted to upgrade the checksum mechanism (say to bc32).

I know that @ksedgwic would ideally whatever we do to be small enough that when converted to mnemonics can fit on 2 of his metal doglegs. 15 characters per line, 6 lines per tag. So if a 1 byte version byte puts us over in whatever final mnemonic scheme we come up with, it could hurt. So it could maybe be a nibble somewhere?

-- Christopher Allen

Shouldn't c7098580125e2ab0981253468b2dbc52 have a CRC checksum of feac0dea? The current spec lists it as e824467c.

screenshot source

UDPATE: I submitted a PR to fix this #93

Hi!

I'm interested in working on a Rust implementation of Uniform Resources, does anybody know if somebody has already started to do this?