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

Parse different bitcoin payment request and identifiers #10

Open
johnsBeharry opened this issue Jan 25, 2022 · 0 comments
Open

Parse different bitcoin payment request and identifiers #10

johnsBeharry opened this issue Jan 25, 2022 · 0 comments
Assignees

Comments

@johnsBeharry
Copy link
Member

There are various payment request formats that often should be used once. Also, identifiers which have a longer lifespan as they can be used to identify a contact and either, establish a communication channel to relay a message between wallets, return payment request, etc. While one way of communicating such data is through text, it is also often the case that they are displayed as QR Codes.

We need to build a library that would allow the input of a payment request or identifier and parsing them for any meta data they contain.

An inverse of this function would be to encode it back to a string, with optimisations for QR Codes. See reference BTC Pay Server.

You will need to have a few libaries from NPM to make the validation a bit easier.

  • bip21
  • bolt11

Payment Request Types

  1. Addresses
    2. Legacy Address
    3. Native Segwit
    4. Segwit
    5. Taproot
  2. BOLT11
    7. With URI
    8. Without URI
  3. BIP21
  4. BIP21 with Lightning Parameter

Identifiers

  1. LNURL Pay URI
  2. LNURL Withdraw URI
  3. BIP47 (low priority)

Optimiser

Optimise string size, for use in QR encoding. The uppercasing of characters use less bits. When encoding these payment request strings as QR Codes the result would be less dense, thus easier to scan.

  • Uppercase bech32 address, attribute names, and meta data where it doesnt change the meaning.
  • For example uppercasing the value of some invoice description or label could change the intended meaning.
  • Warning: Legagcy addresses cannot be made uppercase as they would be invalid.

Testing

We use the Jest framework. Test files are in /__tests__

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

2 participants