jbaczuk / bscript-parser Goto Github PK

Add the following convenience methods:

1. asmToAddress(options = {})
2. addressToAsm(options = {})
3. rawToAddress(optionsOrEncoding = {})
4. addressToRaw(optionsOrEncoding = {})

2\. When a bad option is provided, the program should error rather than ignore the value. For example, providing `-l badliteraltype`

I agree, I think this should be implemented in the module, however, otherwise changes to the valid parameter values will have to be duplicated in the command line script as well. Could we have the bscript module throw an error that we can catch in the cli app?

Originally posted by @JBaczuk in #52 (comment)

Stop parsing script immediately after op_return is detected.

See blockchain.info and https://github.com/bitpay/bitcore-lib/blob/master/lib/script/script.js#L287 for a reference

Parse a verbose script like OP_HASH160 <scriptHash> OP_EQUAL to the corresponding hex string.

For example, OP_RETURN PUSHDATA(2)[abcd] should instead be simply OP_RETURN abcd.

Needs proper API documentation. This might be included as a section of the README.md file.

Things to document:

• BScript class
  • Constructor
  • Instance Properties
    • tokens
    • hasAddress
    • scriptType
    • redeemScript
  • Instance Methods
    • toRaw
    • toAsm
    • toAddress
  • Static Methods
    • fromRaw
    • fromAsm
    • fromAddress
• Token class
  • Constructor
  • Instance Properties
    • type
    • value
    • startIndex
    • endIndex
  • Instance Methods
    • toScript
    • toAsm
    • toString (alias for toAsm)
  • Static Properties
    • Token Types: LITERAL, OPCODE, PLACEHOLDER
  • Static Methods
    • Constructor Helpers: literal, opcode, placeholder
• Convenience Methods
  • rawToAsm
  • rawToAddress
  • asmToRaw
  • asmToAddress
  • addressToRaw
  • addressToAsm
• Opcode Helpers
  • opcodeForWord
  • wordForOpcode
  • opcodeIsValid
  • wordIsValid
  • descriptionForOpcode
  • descriptionForWord
  • inputDescriptionForOpcode
  • inputDescriptionForWord
  • outputDescriptionForOpcode
  • outputDescriptionForWord
  • opcodeIsDisabled
  • wordIsDisabled
• Options Struct
  • encoding (for raw script buffer conversion)
  • literalStyle (for asm stringification)
  • opcodeStyle (for asm stringification)
  • terms (object of overrides & additions for term opcodes)
  • opcodes (object of overrides for opcode terms, inverse of terms)
  • pubKeyHash
  • scriptHash
  • bech32 (the prefix, i.e. 'bc')
  • allowPlaceHolders (for asm parser)

Example: https://defuse.ca/online-x86-assembler.htm#disassembly2

This needs to be able to run in a browser for bitcoin-script-js

This prevents having to perform the calculation multiple times. This requires the use of Object.defineProperty.

This requires that a script's tokens are immutable. Consider enforcing this by freezing (a copy of the) the token array and making the Token class's instance properties read-only (unfortunately, there is not a neat syntax for this built into the language).

Consider using the depd library.

Also, remove it from the documentation.

When a P2SH or P2WSH transaction is detected, parse and show the redeem script. This might require returning the parsed data as an object. Example:

parsedScript = {
    "script": "PUSHDATA(22)[0014d3530760601a3af53c7c93b01dfaf08d1ab156e0]",
    "redeem_script": "WITNESS_V0 PUSHDATA(20)[d3530760601a3af53c7c93b01dfaf08d1ab156e0]"
}

For reference: https://bitcoin.stackexchange.com/questions/2285/script-op-pushdatas

Options should be:

This options object should be added as the last parameter to the following functions:

1. Token#toAsm
2. BScript.formatAsm
3. BScript.rawToAsm
4. BScript#toAsm

It would be nice to get hex output from opcodeForWord as an option and to be able to pass hex into wordForOpcode

E.g. P2SH <asm>

See https://github.com/bitcoin/bitcoin/blob/master/src/test/script_tests.cpp#L485

Currently, each of these opcodes returns the string 'The next opcode bytes is data to be pushed onto the stack', but should instead replace the word opcode with the actual number of bytes that will be pushed onto the stack. For example, descriptionForOpcode(0x02) should return 'The next 2 bytes is data to be pushed onto the stack'.

For example, accept CHECKSIG and EQUAL in addition to OP_CHECKSIG and OP_EQUAL, respectively.

Should add test fixtures to keep the test code clean.

• P2PKH
• P2WSH
• P2SH(P2WSH)

I'm thinking it would be nice to have the projects designated as assembler and interpreter, if there are some good names that would make sense. I know this project does more than an assembler, but I think it would help delineate the functionality. @wardlem o you have any ideas/preferences?

Requires two new methods and one new (getter) property:

• BScript.fromAddress(address, options = {})
• BScript#toAddress(options = {})
• get BScript#isAddress

Options and defaults should be:

• bech32: 'bc'
• pubKeyHash: 0x00
• scriptHash: 0x05

Optional convenience methods:

• asmToAddress
• addressToAsm
• rawToAddress
• addressToRaw

A command line interface would be awesome. If you could install the module globally and execute commands like

$ bsp rawtoasm a914c9f05571026bc94ad04ae03bf108d4bbe6815f1387
OP_HASH160 c9f05571026bc94ad04ae03bf108d4bbe6815f13 OP_EQUAL

• add function stringForOpcode(opcode: int) : string
  • For opcodes 0x01-0x4b returns a string in the format PUSH_DATA(n) where n is the number of bytes that will be pushed onto the stack.
  • For all other opcodes, the result of wordForOpcode is returned.

The immediate use case for this is the cli which attempts to display a the term for a push_data opcodes when undefined is returned.

Having everything in the top level directory is a little messy.

Run integration tests on every PR and have a build badge on the README.

• Finalize and merge all outstanding pull requests in the v1.1.0 milestone
• Generate final API documentation for release
• Update package version
• Do npm publish

This needs to be calculated in raw and assembly parsers.

E.g. https://github.com/bitcoinjs/bitcoin-ops, or we could maintain our own, but preferrably not.

It would make sense to me to export the following functions:

// main functions
parseAsm(asm :: string) => Script
parseRaw(script :: Buffer|string, encoding='hex') => Script

// convenience functions
asmToScript(asm :: string, outputEncoding='binary') => Buffer|string
scriptToAsm(script :: Buffer|string, encoding='hex') => string
normalizeAsm(asm :: string) => string

The parseAsm would return a Script object with the following def:

class Script {
  constructor(tokens) {
    this.tokens = tokens
  }

  toAsm() {
    // .. convert to assembly
  }

  toRaw() {
    // .. convert to raw script
  }

  toAddress(network=BITCOIN_MAINNET) {
    // .. returns an address if the script is recognized as a standard address script
  }

  get redeemScript() {
    // .. returns the redeem script if the scriptType is 'p2wsh' or 'p2sh' as a Script object
    // .. returns undefined (?) if the scriptType does not have a redeem
  }

  get scriptType() {
    // .. returns a string (i.e. 'p2sh') if the script is recognized as a standard script type
    // .. returns undefined (?) if the script does not match a standard script
  }
}

The primary motivation for this would be to gain access to the parsed tokens. The tokens could then be converted into a 'binary' by an upstream project and executed. The tokens could also be utilized by an upstream code editor for bscript.

However, this would be a breaking change and may require a bump to new major version.

UPDATED: To address #6 and #7.

See #19 for function signatures.

1. asmToRaw — Takes a string of assembly and returns a raw script (format specified)
2. rawToAsm — Takes a raw script (format specified) and returns an assembly string
3. formatAsm — Takes an asm string and returns an asm string in a 'normalized' format.

The asm encoding parameter should accept, at minimum, 'hex' and 'base64'. It should also accept null (the default) to indicate that a buffer should be returned. base58 and base32 should also be considered as acceptable encodings because of their prevalence within the bitcoin community.

Assembly formatting options should also be considered. A possible option is to override a term. This is useful if, for example, you want to prefer OP_FALSE over OP_0 or vice-versa. It could also be useful if a custom or experimental opcode is being used. Another possible option is to specify the formatting of the pushdata abcd vs [abcd] vs PUSHDATA(2)[abcd].