Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open CashAddr #266

Open
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@m4ktub
Copy link
Contributor

commented Jan 30, 2019

This pull request provides a revision of CashAddr that intends to make the specification less ambiguous while, at the same time, allowing CashAddr to be used as a general form of address encoding on Bitcoin Cash. The changes can be summed up as:

  • Reserve three prefixes for the address types also defined in the specification.
  • Unconstrain the payload structure for any other prefix.

This revision makes previously invalid payloads now valid (eg. prefix:x64nx6hz). It also makes the specification of simpleleger addresses slightly more ambiguous, although arguably still valid. Like in the PR #259, due to the unconstraint of the payload for other prefixes, some test vectors were changed as they can no longer be type and length checked.

After a brief review of some libraries, although theoretically less backward compatible it seems this revision is, in practice, as backwards compatible as the one in PR #259. Most libraries are limited to the 3 Bitcoin Cash networks and their corresponding address prefixes.

In this specification new address schemes, like stealth addresses, could look like this: stealth:9vqq80nex6callf0srmgrsmfvxmkd30354s0ukmft5c2hjhtdafth7weqypyrttwfj3es6xufs3fqdwlz4lqnf9wr6ldwv38fdnph4rhu34tclgpqqqqfrvvj9ll.

@m4ktub m4ktub referenced this pull request Jan 30, 2019

Open

Generalized CashAddr #259

@markblundeberg

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2019

There is a slight conceptual error in this one. You write:

 data             checksum
+------ ~ -------+---------+
|    N bytes     | 5 bytes |
+------ ~ -------+---------+

However actually it's structured like this:

 data             checksum
+------ ~ -------+---------+
|    M chars      | 8 chars |
+------ ~ -------+---------+

In other words, the checksum is appended after conversion to base32.

The distinction is important in the case where the number of bits preceding checksum (8N) is not a multiple of 5. For example when we have normal P2PKH addresses (N = 21, so 168 bits) that leaves only 3 bits left over on the last base32 character of the payload. So if you look at the 9th-from-last character on such an address you'll see it only ever takes on one of 8 values: q, p, z, r, y, 9, x, 8, and not any of the other 24 values.

@m4ktub

This comment has been minimized.

Copy link
Contributor Author

commented Jan 30, 2019

You're right about my error, the payload is not necessarily byte aligned (8N = 5M) and I assumed it was.

In that part I'm referring to the data, and not the representation, so I can also add the variable padding to the diagram as bellow. I believe it's important to make explicit that the encoded data is actually a series of bytes since, in general, there would no way to figure "P".

 data             padding  checksum
+------ ~ -------+--------+---------+
|    N bytes     | P bits | 40 bits |
+------ ~ -------+--------+---------+

Regarding your example, just a note that, the 8 possible characters are actually q, y, g, v, s, 5, c, and u.

@markblundeberg

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2019

Aha! You're right, good catch about those characters :-D. And yes, I think that new representation is clearer. I have to read over the doc again, though...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.