The 2023 protocol upgrade had a transaction-version rule that was added to consensus. (CHIP).

The unrealized side-effect is that there is a good chance that in the future we might see a new, incompatible transaction format. The point is, a future transaction version may work fine with todays codebase, it may not. There is no way to know.

So, if someone runs todays version of libauth (or any application that incorporates it) unexpected things may happen.

This issue is to suggest that libauth's raw transaction processing code will refuse to process transactions that have a too-high version number. Forcing people that get those transactions to upgrade to a newer version of libauth that presumably has added support. And to avoid them getting bad results that may happen due to parsing unknown transaction type.

The transactions-in-mainchain research showed that there are no transactions with versions higher than 9 in testnet4 and mainchain (all bets are off for testnet3). Therefor I suggest rejecting all transactions greater-equal 10.

How to compile with gmp?

Create a new React App:

npx create-react-app debug-libauth
cd debug-libauth
npm i @bitauth/libauth --save

Add to App.js

import * as bitcoin from '@bitauth/libauth'
console.log(bitcoin)

Run the app

npm run start

Observe the error

./node_modules/@bitauth/libauth/build/module/lib/template/compiler.js 112:37
Module parse failed: Unexpected token (112:37)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
|   }), {});
|   const entityOwnership = Object.entries(template.entities).reduce((all, [entityId, entity]) => ({ ...all,
>     ...Object.keys(entity.variables ?? {}).reduce((entityVariables, variableId) => ({ ...entityVariables,
|       [variableId]: entityId
|     }), {})

Version info:

 "@bitauth/libauth": "^1.15.3",
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.5.0",
    "@testing-library/user-event": "^7.2.1",
    "react": "^16.13.1",
    "react-dom": "^16.13.1",
    "react-scripts": "3.4.1"

This might be a good item to start working on when we build support for the BCH_2019_11 VM. It's also a good thing to do while working on full, per-opcode documentation of the VM.

Basically, for each VM version, there will be two sets of test vectors, one for the block-level validation ("consensus" or "miner"), and one for pre-network rebroadcasting validation ("isStandard" or "strict" in this library). For implementations which use flags, they'll run each list of test vectors using the same set of flags for the full list. As much functionality as possible should be tested using only opcodes, and maybe we'll support other state input for a few cases (e.g. locktime and sequenceNumber). As we get the full VM tested by the new vectors, we can remove the current script_tests.json tests and the hack using script_tests_addendum.json.

Bitcoin ABC will likely continue supporting the existing script_tests.json format, but might also be interested in testing against these new vectors. (CC: @markblundeberg)

• I'm submitting a ...
  [x ] bug report
  [ ] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary
  It's possible this project is impacted by this malicious code : dominictarr/event-stream#116

Dependency listed on this page: https://libraries.io/npm/flatmap-stream/usage?page=3&requirements=0.1.1

Although the exploit targets Bitcoin wallets derived from Copay, so it may not be relevant here. Regardless, dependencies on packages controlled by malicious sources should be removed.

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

Hi, @bitauth, thank you for your nice library.

I am trying to generate the SLP's OP_RETURN scripts using the libauth and would like to ask you for your feedback.
I've taken the USDT example from the SLP spec and was successful to reproduce the Genesis transaction.
The resulting script look's like this and its bytecode generation like this

Am i doing it the right way?
I am not really satisfied that I need to use the vm evaluations like $(<0x01 decimals>) and manually fiddle with endianness and the need to introduce the new bigIntToBinUint64BE method.

Thanks for your feedback in advance,
pat.

• I'm submitting a ...
  [ ] bug report
  [x ] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary

Need this methods to fast calculate incrementing key pair.

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary

Please add bcrypt support. bcrypt is actually the most useful because it is the slowest in a browser. js is so slow you probably never want to do it client-side. But if it were as fast as a server, you could do it client-side. in the case of Money Button, client-side bcrypt would let us encrypt the wallet with something strong than just the user's password. If our DB were ever hacked, every user with weak passwords could have their wallet decrypted. Client-side bcrypt is a way to mitigate that problem.

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

• I'm submitting a ...
  [x] bug report
  [ ] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary

Right now, I get positive feedback from validatePrivateKey for the input values

• e4ade2a5232a7c6f37e7b854a774e25e6047ee7c6d63e8304ae04fa190bc17 (31 bytes)
• e4ade2a5232a7c6f37e7b854a774e25e6047ee7c6d63e8304ae04fa190bc1732aa (33 bytes)

so it looks like in all the stack of validatePrivateKey, the input length is not checked.

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

Hey Jason,

I've been eager to try your library for like EVER now, but I never knew where to begin.

I recently integrated Hop.cash into my platform Smartstarter and had the pleasure of working with Jonathan Silverblood's codebase, which makes great use of your library.

I'm looking forward to extending my knowledge of your APIs, but I'm strongly encouraging you to provide a few "practical" examples for the "average" developer to get started. Similar to what BitPay's Bitcore Lib Cash does in their README.

I LOVE that fact that your library is PURE JavaScript.

"THIS IS THE WAY"

As soon as I can make the time, I intend to replace Bitcore Lib Cash with Libauth for my own primary SDK NitoJS.

I've been so frustrated with Bitcore Lib Cash over the years as it really DOESN'T play well with others. Not even other/older versions of itself, I mean srsly wtf is THAT about?? And try adding Bitcore Mnemonic in the same app, because you HAVE to import it first, otherwise it'll error out some cryptic message.

Anyway, I'm happy to contribute to this effort, but I'd like some guidance from you as to "how" to construct these examples. Due to how "low-level" your API is, examples could be quite long. I look forward to connecting soon..

Cheers!
Shomari

• I'm submitting a ...
  [ ] bug report
  [ ] feature request
  [*] question about the decisions made in the repository
  [*] question about how to use this project

I was trying my hand on exposing a function I needed for a project of mine, I thought rather than submitting an issue about it without knowing if or when it would be implemented, I thought I'd learn something new and add it myself, so I spent a lot of time figuring out how the WASM functions were exposed to JS, which lead me to the compiling commands in secp256k1.Dockerfile.

I've tried running the commands specified in the docker-file, but... I kinda ran into a wall when actually trying compile it:

$ emmake make FORMAT=wasm
  CC       src/libsecp256k1_la-secp256k1.lo
In file included from src/secp256k1.c:9:
./src/util.h:118:37: error: __int128 is not supported on this target
SECP256K1_GNUC_EXT typedef unsigned __int128 uint128_t;
                                    ^
In file included from src/secp256k1.c:11:
In file included from ./src/field_impl.h:19:
In file included from ./src/field_5x52_impl.h:19:
./src/field_5x52_asm_impl.h:281:3: error: invalid output constraint '+S' in asm
: "+S"(a), "=m"(tmp1), "=m"(tmp2), "=m"(tmp3)
  ^
./src/field_5x52_asm_impl.h:496:3: error: invalid output constraint '+S' in asm
: "+S"(a), "=m"(tmp1), "=m"(tmp2), "=m"(tmp3)
  ^
In file included from src/secp256k1.c:12:
In file included from ./src/scalar_impl.h:20:
./src/scalar_4x64_impl.h:379:7: error: invalid input constraint 'S' in asm
    : "S"(l), "n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1)
      ^
./src/scalar_4x64_impl.h:459:7: error: unknown register name 'rax' in asm
    : "rax", "rdx", "r8", "r9", "r10", "r11", "r12", "r13", "cc");
      ^
./src/scalar_4x64_impl.h:504:52: error: invalid input constraint 'D' in asm
    : "g"(p0), "g"(p1), "g"(p2), "g"(p3), "g"(p4), "D"(r), "n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1)
                                                   ^
./src/scalar_4x64_impl.h:709:7: error: invalid output constraint '+d' in asm
    : "+d"(pb)
      ^
./src/scalar_4x64_impl.h:853:7: error: invalid input constraint 'S' in asm
    : "S"(l), "D"(a->d)
      ^
src/secp256k1.c:29:53: warning: unused parameter 'str' [-Wunused-parameter]
static void default_illegal_callback_fn(const char* str, void* data) {
                                                    ^
src/secp256k1.c:39:51: warning: unused parameter 'str' [-Wunused-parameter]
static void default_error_callback_fn(const char* str, void* data) {
                                                  ^
2 warnings and 8 errors generated.
ERROR    root: compiler frontend failed to generate LLVM bitcode, halting
Makefile:1028: recipe for target 'src/libsecp256k1_la-secp256k1.lo' failed
make: *** [src/libsecp256k1_la-secp256k1.lo] Error 1

It is my understanding that createInstructionSetBCHCHIPs should result in the most recent instruction set based on chipnet rules, which I'd expect to be further than BCH_2023. However, the BCH_CHIPS instruction set treats P2SH32 as non-standard output scripts. We ran into this while trying to debug a WalletTemplate scenario that sends to a P2SH32 locking bytecode.

See https://github.com/bitauth/libauth/blob/ade015123b2bfdbca721602cda19191c6f12252d/src/lib/vm/instruction-sets/bch/chips/bch-chips-instruction-set.ts#L697C16-L697C40

One nice property of both compilation outputs (both the secp256k1 build and the hashes build) is that their algorithms are supposed to be deterministic. So as long as we're fully testing both, consumers can be reasonably-sure that I haven't poisoned them. Probably the most important example: all produced signatures are themselves deterministic (both Schnorr and ECDSA signatures) so we can randomly test inputs to confirm they match expected outputs. This is done for the hashes too. The only current weakness is that currently, we're not testing against another BCH-style Schnorr implementation, so until we have something else there to test against, that could be subverted. (Not to mention, the implementation we're compiling from could be subverted itself. It has had far less review so far than the secp256k1 implementation.)

As long is we're aggressively, randomly testing inputs and validating outputs, most poisoning issues are likely to be discovered. Even if I did something like secretly leak some private key material after every 1,000,000 signatures, that can be detected in about 5 minutes of random testing.

So: we should add a verify:binaries task which runs random tests until it's stopped. Then if you're building an application which is likely to use these binaries millions of times, you can run a test for whatever length of time needed to guarantee accurate results for the duration of your use-case. If you've run the randomized tests for 10M signatures, you're safe to use the tested binary for up to that many signatures before re-initializing the WASM instance. (Assuming your inputs are cryptographically-random. If you're somehow signing non-uniformly-random message hashes, I could be more clever about hiding a leak – e.g. only after 1M signatures over message hashes in which the first 3 bits are 0. To catch that in random testing, you need an average of 1B signatures, which would take about 3.5 days on my machine. So if you're signing bitcoin block hashes, test that properly too.)

Some good developer experience observations from @rkalis:

Why is there a decodeCashAddress and decodeCashAddressFormat, but only decodeCashAddressFormatWithoutPrefix and no decodeCashAddressWithoutPrefix? And why are their return types not compatible with AddressContents so I cannot use them in addressContentsToLockingBytecode?
In any case, this is my goal:
I'm using cashAddressToLockingBytecode but that only works if you pass in a a prefixed address, I also want to support using an unprefixed address (don't think the prefix matters for the locking bytecode), but it throws an error if there's no prefix.

Originally, I’d thought you wouldn’t need decodeCashAddressWithoutPrefix if you already knew it was a cash address (since you simply need to add the prefix, no testing loop needed), but I think it would be valuable to have it just as a convenience method to "complete the set".

It would also be valuable to figure out how to make the results of decoding compatible with the AddressContents type – either by adjusting the types or by adding a couple more to/from utility methods.

So, TODO:

• add decodeCashAddressWithoutPrefix
• either:
  • make decoded cash address and AddressContents types compatible, or
  • add utility methods for converting between them

See implementation of function :

API documentation :

https://libauth.org/globals.html#generateprivatekey

I've been trying to merge some libsecp256k1 upstream into libauth-secp256k1. This would solve #25, which is what i need.

Merging with bitcoin-core libsecp256k1 and solving conflicts is too painful and I wasn't able to make it compile and pass make check, merging with ABC's libsecp256k1 fails with git reporting fatal: refusing to merge unrelated histories.

Replacing the submodule with core libsecp256k1 is possible. The implementation of schnorr (schnorrsig module) has the same function signatures but ultimately fails to pass tests(results seem to be different), you can check this on https://github.com/angel-manuel/libauth/tree/d7f3fab9b1e1581a45e9c303c6de7743b96063b5

On https://github.com/angel-manuel/libauth/tree/feat-update-libsecp256k1 you can see part of my work wrapping the new functions.

Any ideas, @bitjson?

In any case I'm thinking about forking the WASM libsecp256k1 parts and supporting just stable bitcoin-core libsecp256k1. But I would like to finish my contribution if we find a way to merge with an acceptable upstream. Also, if the 0 npm dependencies restrictions were dropped it woudl be possible to maintain the WASM + wrappers on different repo/packages.

I really like what you've done with this library, and would really like to use it to replace some hand-rolled crypto I wrote. My biggest concern however is how to verify the build.

If I am not mistaken, the current build process involves at least 1251 unique packages, any of which could potentially subvert the build.

However, fortunately the vast majority of those libraries have no purpose outside of development. I propose that the dependencies are split between those that are essential for reproducing a build, and those for developer convenience.

@2qx mentioned that React Native can egregiously fail to crypto.getRandomValues. We should add a sanity check in generateRandomBytes to verify that the results differ across two runs.

• I'm submitting a ...
  [ ] bug report
  [*] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary
  For steem, EOS and everiToken blockchain, a canonical signature is needed for transactions. By calling libsecp256k1 directly I can make it by passing a noncefn parameters for signing and in passed function I can return a series of incresed nonces until generated signature is canonical (that is, both r and s of the signature have a length of 32 byte. that is, in a der signature array, der[3] == der[37] == 32 ).

But I can't do it with bitcoin-ts. There is no way to pass noncefn, and the signature produced by bitcoin-ts is not canonical.

The requirements are widespread for developers of these blockchains, therefore I think it's necessary to add it to the library. If it couldn't be done in the near future, is there a way to modify the code to achieve this by myself?

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

encodeTransaction calls encodeInputs and encodeOutputsForTransaction which call bigIntToBitcoinVarInt, which calls bigIntToBinUint64LE. bigIntToBinUint64LE in turn looks like this:

export const bigIntToBinUint64LE = (value: bigint) => {
  const uint64Length = 8;
  const bin = new Uint8Array(uint64Length);
  const writeAsLittleEndian = true;
  const view = new DataView(bin.buffer, bin.byteOffset, bin.byteLength);
  // eslint-disable-next-line functional/no-expression-statement
  view.setBigUint64(0, value, writeAsLittleEndian);
  return bin;
};

view.setBigUint64(...) is not supported by Safari on macOS or iOS (see DataView.prototype.setBigUint64). Note that most iOS browsers are Safari under the hood, so this propagates to those iOS browsers as well. This accounts for about 20% of the global browser market share.

I am not yet sure how to fix this, but I think it is important that this does get fixed, since transaction encoding is a pretty important part of Bitcoin applications, and excluding 20% of potential users is not something you want to do.

Currently the most recent implemented instruction set is BCH_2019_05, while there is also a BCH_2019_11_SPEC option. To use modern functions such as OP_REVERSEBYTES we need to implement support for the newer hardforks.

According to the specs on GitHub (https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/), these are the features that were introduced by these hardforks. These should be added to libauth to support these newer instruction sets.

BCH_2019_11

• Enable Schnorr signatures for OP_CHECKMULTISIG(VERIFY).
• Enforce minimal push and minimal number encoding rules in Script.

BCH_2020_05

• Bitcoin Cash's SigOps counting and limiting system is replaced with a new system, referred to as SigChecks.
• A new opcode called OP_REVERSEBYTES has been added to the script system.

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary

Personally I'm never going to use the wasm Sha functions as both the web browser and NodeJS provide native implementations of that. Perhaps you should put secp256k1 in a different package secp256k1-wasm or something like that for all the other parts and make bitcoin-ts depend on all the parts.

module.exports = require("@bitauth/libauth");
                 ^
Error [ERR_REQUIRE_ESM]: require() of ES Module <path>/node_modules/@bitauth/libauth/build/main/index.js from <path>/dist/apps/rewards/main.js not supported.
Instead change the require of index.js in <your_working_dir> to a dynamic import() which is available in all CommonJS modules.

Any help is appreciated!

The documentation wrongly states it takes secp256k1 as first parameter: https://github.com/bitauth/libauth/blob/071f9cdd/src/lib/key/key-utils.ts#L70

Not really a bug-report, but just some food-for-thought if you weren't aware (and my apologies if you were).

One thing I've had a lot of success with is writing a sha256 hash like this:

https://github.com/hookedin/hookedin-lib/blob/0d5b3287fa192692c23bb261f92b0b75e4f3dc84/src/util/browser-crypto/sha256.ts

as well as provide a node.js version with the same signature:

https://github.com/hookedin/hookedin-lib/blob/0d5b3287fa192692c23bb261f92b0b75e4f3dc84/src/util/node-crypto/sha256.ts

and then in the package.json tell it to switch files depending if it's included in the browser or not:

https://github.com/hookedin/hookedin-lib/blob/0d5b3287fa192692c23bb261f92b0b75e4f3dc84/package.json#L30

It's also worth noting there's no browser crypto for ripemd, so that's another annoyance.

The library bundles libsecp256k1 and a bunch of other libraries. When one includes 10 libraries in the repository, it's not zero deps.

It's misleading to call it "zero dependencies" in README and docs.

After andywer/leakage#27 lands

Currently benchmarks can be manually run with yarn bench. It would be great if this was part of CI builds and tested for notable regressions from previous results.

ran into this when using rollup.js to bundle paybutton.

(!) Conflicting re-exports
../react/node_modules/@bitauth/libauth/build/module/lib/vm/instruction-sets/bch/bch.js re-exports 'OpcodesBCH' from both ../react/node_modules/@bitauth/libauth/build/module/lib/vm/instruction-sets/bch/bch-instruction-sets.js and ../react/node_modules/@bitauth/libauth/build/module/lib/vm/instruction-sets/bch/bch-opcodes.js (will be ignored)

• I'm submitting a ...
  [ ] bug report
  [ ] feature request
  [ x ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary
  Referencing an error I got : event-stream-3.3.6.tgz not found when executing yarn as described, I found two solutions in this issue.

The solutions are :

• removing the yarn.lock file
• adding to package.json that piece of code :

  ...
  ,
  "resolutions": {
    "**/event-stream": "^4.0.1"
  }

Is it THAT necessary to have the yarn.lock file? Which one of these solutions are the best? I would then making a merge request with the chosen solution.

Just opening this issue to have a URL to share until I and/or another contributor get around to implementing a demo of cross-input signature aggregation in detached signatures, presumably as part of a v5 transaction format proposal. Also implicit/optional sequence numbers (but not locktime to avoid disincentivizing re-org resistance), probably some solution for fractional satoshis, maybe implied OP_RETURNs, and compactUint everything else. (And consider enabling or requiring v5 TXs to support UTXO Hash Sets.)

A key goal is to reduce the size/cost of CashFusion transactions, e.g. the largest one so far was ~40KB, with 261 inputs and 114 outputs¹. Replacing each signature in this TX with a reference to a detached signature (e.g. OP_1) would save 261 * 64 = 16,704 bytes (minus the aggregated, detached signature itself), bringing the transaction size down to ~24KB (41% savings). The savings are also greater for transactions with more inputs than outputs, so the overall effect will also encourage (privacy-preserving) UTXO set consolidation.

Also worth noting that we could save an additional 261 * 33 = 8,613 bytes (down to ~15KB, for 62% total savings) if all inputs switched to P2PK rather than P2PKH. Between the funding output (the change output of the last TX) and fusion input, each user saves 24 bytes of public key hash and P2PKH overhead.

There are some privacy considerations on the P2PK usage: you don't want to leak which output is the "change" if you're paying to P2PKH, but if the funding transaction was already using PayJoin, there was no meaningful cost to negotiating P2PK addresses rather than P2PKH. We can also expect 1) network wide P2PK usage to increase due to the cost savings and 2) if some popular wallets support both P2PK and P2PKH (esp. mixed use) the difference stops being useful as a privacy-breaking heuristic (wallets could even juggle funds between them to throw off naive trackers).

 {
  transaction(
    where: {
      hash: {
        _eq: "\\xf55237e16408134f6ff21c75c857f0db38dc106a7bf2572af3717475cbefdf02"
      }
    }
  ) {
    hash
    input_count
    output_count
    size_bytes
    encoded_hex
}

{
  "data": {
    "transaction": [
      {
        "hash": "\\xf55237e16408134f6ff21c75c857f0db38dc106a7bf2572af3717475cbefdf02",
        "input_count": "261",
        "output_count": "114",
        "size_bytes": "40703",
        "encoded_hex": "[... snip ... ]"
      }
    ]
  }
}

query CashFusionTxs {
  search_output_prefix(
    args: { locking_bytecode_prefix_hex: "6a0446555a00" }
    limit: 100
  ) {
    transaction_hash
    transaction {
      input_count
      output_count
      size_bytes
      block_inclusions {
        block {
          hash
          height
        }
      }
    }
  }
}

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [x] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary

I am getting started with this library and did not find a keypair generator in the API. Is this something that can be added? Or do you expect the keypairs to come from somewhere else?

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

The encodeDataPush method doesn't quite work for SLP applications because SLP disallows single-byte push operations. We should refactor the multi-byte encoding segment of encodeDataPush into an encodeDataPushMultiByte, then use it internally in encodeDataPush for payloads which can't be encoded in a single byte.

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary
  Ethereum uses Secp256k1 for its ECC and Keccak256 (original submission, not final NIST SHA-3) for its hashing. While I know this is a bitcoin library, it would be great if it could be used in Ethereum as well by getting support for Keccak256 added.

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

Q&A on Ethereum's hashing algorithm: https://ethereum.stackexchange.com/a/554/704

Hello Jason, I am exercising transaction generation involving cashtokens in v2 alpha release and stumbled upon this issue that compileOutputTemplate does not respect token field of the outputTemplate param at the following lines:

• I'm submitting a ... question about the decisions made in the repository / feature request.

• Summary

When using deriveHdPath to derive a node using a "relative" path, the prefix m or M must be included even when the source node is not a master(depth 0) node.

For example if I have a source node with absolute path m/1/2 and I want to reach a destination node with absolute path m/1/2/3/4, I must specify the relative path between them as m/3/4. I think it would be more intuitive to accept the relative path as /3/4 or 3/4 or ./3/4 as m should be reserved for nodes with depth 0 and m/3/4 should result in a node with depth 2.

It could also accept m/1/2/3/4 and then, observing that the starting node has depth 2 and index 2, drop the appropriate prefix from the derivation path and proceed from there.

  // Derive a master node:
  const masterNode = deriveHdPrivateNodeFromSeed(crypto, hexToBin("000102030405060708090a0b0c0d0e0f"));
  if (!masterNode.valid) return console.error(`Error with initial derivation.`);
  console.log('Master node depth:', masterNode.depth);  // 0
     
  // Derive a depth 2 node:
  const depth2Path = "m/1/2";
  const depth2Node = deriveHdPath(crypto, masterNode, depth2Path);
  if(typeof depth2Node === 'string') return console.error(depth2Node);
  console.log('Node depth:', depth2Node.depth); // 2
  
  // Derive a depth 4 node (absolute path):
  const depth4Path = "m/1/2/3/4";
  const depth4Node = deriveHdPath(crypto, depth2Node, depth4Path);
  if(typeof depth4Node === 'string') return console.error(depth4Node);
  console.log('Node depth:', depth4Node.depth); // 6 (expected 4)

  // Dervice a depth 4 node (relative path, absolute notation):
  const depth4PathRelativeAbs = "m/3/4";
  const depth4NodeRelativeAbs = deriveHdPath(crypto, depth2Node, depth4PathRelativeAbs);
  if(typeof depth4NodeRelativeAbs === 'string') return console.error(depth4NodeRelativeAbs); 
  console.log('Node depth:', depth4NodeRelativeAbs.depth); // 4

  // Derive a depth 4 node (relative path, currently generates an error):
  const depth4PathRelative = "/3/4";
  const depth4NodeRelative = deriveHdPath(crypto, depth2Node, depth4PathRelative);
  if(typeof depth4NodeRelative === 'string') return console.error(depth4NodeRelative); // Error
  console.log('Node depth:', depth4NodeRelative.depth); 

• Other information

See here for an executable demo of the code above.

• I'm submitting a ...
  [x] bug report

• Summary

When using [email protected], I get a Cannot find namespace 'WebAssembly' error. When I switch to [email protected], I get multiple Cannot find name 'SharedArrayBuffer'. and Cannot find name 'BigInt'.

• Other information

My tsconfig.json looks like this:

{
  "compilerOptions": {
    "sourceMap": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "strictNullChecks": true,
    "noImplicitAny": true,
    "esModuleInterop": true,
    "declaration": true,
    "target": "es2015",
    "outDir": "dist",
  },
}

The error for [email protected]:

node_modules/bitcoin-ts/build/main/lib/bin/secp256k1/secp256k1-wasm-types.d.ts:80:24 - error TS2503: Cannot find namespace 'WebAssembly'.

80     readonly instance: WebAssembly.Instance;
                          ~~~~~~~~~~~


Found 1 error.

The error for [email protected]:

node_modules/bitcoin-ts/build/main/lib/auth/instruction-sets/common/types.d.ts:5:51 - error TS2304: Cannot find name 'BigInt'.

5 export declare const isScriptNumberError: (value: BigInt | ScriptNumberError) => value is ScriptNumberError;
                                                    ~~~~~~

node_modules/bitcoin-ts/build/main/lib/bin/secp256k1/secp256k1-wasm.d.ts:14:70 - error TS2304: Cannot find name 'SharedArrayBuffer'.

14 export declare const getEmbeddedSecp256k1Binary: () => ArrayBuffer | SharedArrayBuffer;
                                                                        ~~~~~~~~~~~~~~~~~

node_modules/bitcoin-ts/build/main/lib/crypto/ripemd160.d.ts:56:70 - error TS2304: Cannot find name 'SharedArrayBuffer'.

56 export declare const getEmbeddedRipemd160Binary: () => ArrayBuffer | SharedArrayBuffer;
                                                                        ~~~~~~~~~~~~~~~~~

node_modules/bitcoin-ts/build/main/lib/crypto/sha256.d.ts:56:67 - error TS2304: Cannot find name 'SharedArrayBuffer'.

56 export declare const getEmbeddedSha256Binary: () => ArrayBuffer | SharedArrayBuffer;
                                                                     ~~~~~~~~~~~~~~~~~

node_modules/bitcoin-ts/build/main/lib/crypto/sha512.d.ts:56:67 - error TS2304: Cannot find name 'SharedArrayBuffer'.

56 export declare const getEmbeddedSha512Binary: () => ArrayBuffer | SharedArrayBuffer;
                                                                     ~~~~~~~~~~~~~~~~~


Found 5 errors.

• I'm submitting a ...
  [x] bug report
  [ ] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary

I created a set of 20 test vectors from pyca/cryptography and in 12/20 cases, the resulting signatures are valid but not equal to the signature in the test vectors.

When I change the implementation from bitcoin-ts to elliptic, the exact same tests pass.

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

I created a set of test vectors from pyca/cryptography by doing

$ git clone https://github.com/pyca/cryptography.git && cd cryptography
$ python2 -m virtualenv venv
$ source venv/bin/activate
$ pip install cryptography cryptography_vectors pytest ecdsa
$ curl https://patch-diff.githubusercontent.com/raw/webmaster128/cryptography/pull/1.diff | git apply
$ python ./docs/development/custom-vectors/secp256k1/generate_secp256k1.py > secp256k1_test_vectors.txt

and used the following 20 data sets:

{
  message: fromHex("5c868fedb8026979ebd26f1ba07c27eedf4ff6d10443505a96ecaf21ba8c4f0937b3cd23ffdc3dd429d4cd1905fb8dbcceeff1350020e18b58d2ba70887baa3a9b783ad30d3fbf210331cdd7df8d77defa398cdacdfc2e359c7ba4cae46bb74401deb417f8b912a1aa966aeeba9c39c7dd22479ae2b30719dca2f2206c5eb4b7"),
  privkey: fromHex("21142a7e90031ea750c9fa1ba1beae16782386be438133bd43195826ae2e25f0"),
  signature: fromHex("30440220207082eb2c3dfa0b454e0906051270ba4074ac93760ba9e7110cd94714751111022051eb0dbbc9920e72146fb564f99d039802bf6ef2561446eb126ef364d21ee9c4"),
},
{
  message: fromHex("17cd4a74d724d55355b6fb2b0759ca095298e3fd1856b87ca1cb2df5409058022736d21be071d820b16dfc441be97fbcea5df787edc886e759475469e2128b22f26b82ca993be6695ab190e673285d561d3b6d42fcc1edd6d12db12dcda0823e9d6079e7bc5ff54cd452dad308d52a15ce9c7edd6ef3dad6a27becd8e001e80f"),
  privkey: fromHex("824282b6069fe3df857ce37204df4312c35750ee7a0f5e5fd8181666d5e46fb2"),
  signature: fromHex("30440220626d61b7be1488b563e8a85bfb623b2331903964b5c0476c9f9ad29144f076fe02202002a2c0ab5e48626bf761cf677dfeede9c7309d2436d4b8c2b89f21ee2ebc6a"),
},
{
  message: fromHex("db0d31717b04802adbbae1997487da8773440923c09b869e12a57c36dda34af11b8897f266cd81c02a762c6b74ea6aaf45aaa3c52867eb8f270f5092a36b498f88b65b2ebda24afe675da6f25379d1e194d093e7a2f66e450568dbdffebff97c4597a00c96a5be9ba26deefcca8761c1354429622c8db269d6a0ec0cc7a8585c"),
  privkey: fromHex("5c0da42cec87a6b7a173514965343c30013386c0fe9b39203ed7af43ea425944"),
  signature: fromHex("304602210083de9be443bcf480892b8c8ca1d5ee65c79a315642c3f7b5305aff3065fda2780221009747932122b93cec42cad8ee4630a8f6cbe127578b8c495b4ab927275f657658"),
},
{
  message: fromHex("47c9deddfd8c841a63a99be96e972e40fa035ae10d929babfc86c437b9d5d495577a45b7f8a35ce3f880e7d8ae8cd8eb685cf41f0506e68046ccf5559232c674abb9c3683829dcc8002683c4f4ca3a29a7bfde20d96dd0f1a0ead847dea18f297f220f94932536ca4deacedc2c6701c3ee50e28e358dcc54cdbf69daf0eb87f6"),
  privkey: fromHex("ab30a326599165b48c65ab8d3c77d312d7b2ea4853f721e18cc278628a866980"),
  signature: fromHex("30440220723da69da81c8f6b081a9a728b9bba785d2067e0ed769675f8a7563d22ed8a1602203a993793cf39b96b3cd625df0e06f206e17579cd8ebcb7e704174c3d94dba684"),
},
{
  message: fromHex("f15433188c2bbc93b2150bb2f34d36ba8ae49f8f7e4e81aed651c8fb2022b2a7e851c4dbbbc21c14e27380316bfdebb0a049246349537dba687581c1344e40f75afd2735bb21ea074861de6801d28b22e8beb76fdd25598812b2061ca3fba229daf59a4ab416704543b02e16b8136c22acc7e197748ae19b5cbbc160fdc3a8cd"),
  privkey: fromHex("1560b9fa5229f623a9c556132da4fc0e58633f39ce6421d25b5a6cde4ad7e019"),
  signature: fromHex("304502200e0c5228e6783bee4d0406f4f7b7d79f705f0dbb55126966f79e631bd8b23079022100faae33aec5b0fafd3413c14bfdef9c7c9ac6abd06c923c48ab136a2c56826118"),
},
{
  message: fromHex("1bc796124b87793b7f7fdd53b896f8f0d0f2d2be36d1944e3c2a0ac5c6b2839f59a4b4fad200f8035ec98630c51ef0d40863a5ddd69b703d73f06b4afae8ad1a88e19b1b26e8c10b7bff953c05eccc82fd771b220910165f3a906b7c931683e431998d1fd06c32dd11b4f872bf980d547942f22124c7e50c9523321aee23a36d"),
  privkey: fromHex("42f7d48e1c90f3d20252713f7c7c6ce8492c2b99bcef198927de334cda6bad00"),
  signature: fromHex("3046022100b9d3962edadc893f8eeff379f136c7b8fc6ea824a5afc6cbda7e3cb4c7a1e860022100bb1c1f901cf450edfdce20686352bb0cf0a643301123140ec87c92480d7f9d6a"),
},
{
  message: fromHex("18e55ac264031da435b613fc9dc6c4aafc49aae8ddf6f220d523415896ff915fae5c5b2e6aed61d88e5721823f089c46173afc5d9b47fd917834c85284f62dda6ed2d7a6ff10eb553b9312b05dad7decf7f73b69479c02f14ea0a2aa9e05ec07396cd37c28795c90e590631137102315635d702278e352aa41d0826adadff5e1"),
  privkey: fromHex("6fe5b986c18da5d4fbcea6f602f469ac039085247ccb97b6292992363ea1d21c"),
  signature: fromHex("30460221009369ab86afae5e22ed5f4012964804d2a19c36b8b58cf2855205b1cfcc937422022100a27dfc38d899b78edcf38a1b2b53578e72270b083d7d69424c4b4a7d25d39f4d"),
},
{
  message: fromHex("a5290666c97294d090f8da898e555cbd33990579e5e95498444bfb318b4aa1643e0d4348425e21c7c6f99f9955f3048f56c22b68c4a516af5c90ed5268acc9c5a20fec0200c2a282a90e20d3c46d4ecdda18ba18b803b19263de2b79238da921707a0864799cdee9f02913b40681c02c6923070688844b58fe415b7d71ea6845"),
  privkey: fromHex("fbf02ff086b215d057130a509346b64eb63bec0e38db692e07ad24c6ca8fe210"),
  signature: fromHex("3045022100c5e439cef76b28dc0fe9d260763bec05b5e795ac8d90b25d9fccbc1918bc32f302201b06144e6b191224d5eda822a5b3b2026af6aa7f25a9061c9e81c312728aa94a"),
},
{
  message: fromHex("13ad0600229c2a66b2f11617f69c7210ad044c49265dc98ec3c64f56e56a083234d277d404e2c40523c414ad23af5cc2f91a47fe59e7ca572f7fe1d3d3cfceaedadac4396749a292a38e92727273272335f12b2acea21cf069682e67d7e7d7a31ab5bb8e472298a9451aeae6f160f36e6623c9b632b9c93371a002818addc243"),
  privkey: fromHex("474a7dc7f5033b6bf5e3027254cd0dbd956f16f61874b2992839a867f607d0dd"),
  signature: fromHex("3045022100ee8615a5fab6fc674e6d3d9cde8da2b18dece076ae94d96662e16109db12d72002203171705cdab2b3d34c58e556c80358c105807e98243f5754b70b771071308b94"),
},
{
  message: fromHex("51ad843da5eafc177d49a50a82609555e52773c5dfa14d7c02db5879c11a6b6e2e0860df38452dc579d763f91a83ade23b73f4fcbd703f35dd6ecfbb4c9578d5b604ed809c8633e6ac5679a5f742ce94fea3b97b5ba8a29ea28101a7b35f9eaa894dda54e3431f2464d18faf8342b7c59dfe0598c0ab29a14622a08eea70126b"),
  privkey: fromHex("e8a2939a46e6bb7e706e419c0101d39f0494935b17fe3ca907b2ea3558d6ab3a"),
  signature: fromHex("3046022100f753c447161aa3a58e5deeca31797f21484fb0ec3a7fe6e464ab1914896f253b02210099640fbcce1f25fd66744b046e0dfd57fa23070555f438af6c5e5828d47e9fa7"),
},
{
  message: fromHex("678b505467d55ce01aec23fd4851957137c3a1de3ff2c673ec95a577aa9fb011b4b4a8eb7a0e6f391d4236a35b7e769692ace5851d7c53700e180fa522d3d37dbaa496163f3de6d96391e38ff83271e621f2458729ff74de462cdce6b3029f308d4eb8aef036357b9de06d68558e0388a6e88af91340c875050b8c91c4e26fc8"),
  privkey: fromHex("08ce8f7118eda55b008f6eb3281a445a3ddbc5209d5ac16c09dbf40fe4bbc22c"),
  signature: fromHex("30440220439fd0423bde36a1616a6fa4343bb7e07a6b3f6dc629aa8c93c91831055e476c022020998a26ae4b96ef36d48d83e8af0288f0bbc2db5ca5c8271a42f3fdc478fcb2"),
},
{
  message: fromHex("9bf457159f0d44b78d0e151ee53c41cecd98fb4e4129fcda8cc84a758636f84dcad9032f3ec422219d8a7ec61ea89f45d19cab3c3d451de1a634e3d2532231bc03031973d7150cf8e83d8b6a34f25fc136446878e3851b780abdca069c8e981b3ea3f1bf1ff6e47a03f97aed64c1cc90dd00389fa21bb973f142af5e8ceccef4"),
  privkey: fromHex("820be5c5e14e802300ca024fce318910f00470f6c3eabb12e7f3fac9383cf247"),
  signature: fromHex("304502204ce72a83cf1d148db4d1e46e2f773c677f72933c40d7100b9192750a1c8222a80221009d5fbd67ce89ba8c79df9dc3b42922026a8498921c2bdb4ea8f36496d88c2cfb"),
},
{
  message: fromHex("2469172b7a046e6112dfe365590dfddb7c045cccd4ab353edc3076091aad1c780a9a73ff93f3dbf9e2189c5d1fdd6f6167d0ae8cc0f53dc8950e60dd0410e23589999d4ce4fa49e268774defd4edce01c05b205014b63591a041745bfffc6ae4d72d3add353e49478106653cc735b07b0fe665c42d0e6766e525bb9718264c87"),
  privkey: fromHex("d92d6170e63bc33647e6dcdf1981771ecd57e11d47d73138696fbf49a430c3ab"),
  signature: fromHex("304502201f1e1fb673e9a7dee09961c6824b473189904deb4f0d8e28da51f77f4de2efe6022100ae8df1fcdb226fac8b46e494720e45f6d9a5350174faaf22e47b6329ee6c5e1b"),
},
{
  message: fromHex("6f8983e74f304c3657cffde0682b42699cb2c3475b925058ff37292c40a0aa296690ad129730339ac60cf784225b2fd3db58297c8ce5889df7a48d3e74a363ae4135e8a234cab53ca4c11c031d561a6cf7dd47b925ed5bc4c2794ba7b74a868b0c3da31ff1e4540d0768612192a236d86f74fb8c73f375b71c62f1648c0e6126"),
  privkey: fromHex("a70eb435feaeb6ccda7d3ebd3c4ae40b60643bc933f37ad1aca41dd086e8ae50"),
  signature: fromHex("30460221009cf7d941dcbbbe61c2a6f5112cb518094e79e5d203891de2247e75fd532c3f21022100fc5a04579b2526f2543efd2a57e82b647da08b6924bff39cf021398a56ad70de"),
},
{
  message: fromHex("6fbe6f0f178fdc8a3ad1a8eecb02d37108c5831281fe85e3ff8eeb66ca1082a217b6d602439948f828e140140412544f994da75b6efc203b295235deca060ecfc7b71f05e5af2acc564596772ddbfb4078b4665f6b85f4e70641af26e31f6a14e5c88604459df4eeeed9b77b33c4b82a3c1458bd2fd1dc7214c04f9c79c8f09b"),
  privkey: fromHex("34a677d6f0c132eeffc3451b61e5d55969399699019ac929e6fdb5215d37be5e"),
  signature: fromHex("3045022059cd6c2a30227afbd693d87b201d0989435d6e116c144276a5223466a822c0f2022100b01495efda969b3fd3a2c05aa098a4e04b0d0e748726fc6174627da15b143799"),
},
{
  message: fromHex("2b49de971bb0f705a3fb5914eb7638d72884a6c3550667dbfdf301adf26bde02f387fd426a31be6c9ff8bfe8690c8113c88576427f1466508458349fc86036afcfb66448b947707e791e71f558b2bf4e7e7507773aaf4e9af51eda95cbce0a0f752b216f8a54a045d47801ff410ee411a1b66a516f278327df2462fb5619470e"),
  privkey: fromHex("2258cdecaf3510bc398d08c000245cadceadcf149022730d93b176b4844713e1"),
  signature: fromHex("30460221009eaf69170aeba44966afe957295526ee9852b5034c18dc5aeef3255c8567838a022100ebd4c8de2c22b5cb8803d6e070186786f6d5dae2202b9f899276fa31a66cb3bb"),
},
{
  message: fromHex("1fa7201d96ad4d190415f2656d1387fa886afc38e5cd18b8c60da367acf32c627d2c9ea19ef3f030e559fc2a21695cdbb65ddf6ba36a70af0d3fa292a32de31da6acc6108ab2be8bd37843338f0c37c2d62648d3d49013edeb9e179dadf78bf885f95e712fcdfcc8a172e47c09ab159f3a00ed7b930f628c3c48257e92fc7407"),
  privkey: fromHex("a67cf8cead99827c7956327aa04ab30cfd2d67f21b78f28a35694ece51052a61"),
  signature: fromHex("304402210091058d1b912514940e1002855cc930c01a21234bad88f607f213af495c32b69f021f5d387ce3de25f1b9bad1fb180de110686d91b461ae2972fa4e4a7018519870"),
},
{
  message: fromHex("74715fe10748a5b98b138f390f7ca9629c584c5d6ad268fc455c8de2e800b73fa1ea9aaee85de58baa2ce9ce68d822fc31842c6b153baef3a12bf6b4541f74af65430ae931a64c8b4950ad1c76b31aea8c229b3623390e233c112586aa5907bbe419841f54f0a7d6d19c003b91dc84bbb59b14ec477a1e9d194c137e21c75bbb"),
  privkey: fromHex("4f1050422c4fce146bab0d735a70a91d6447210964b064309f90315c986be400"),
  signature: fromHex("3046022100fe43eb9c38b506d118e20f8605ac8954fc0406efd306ba7ea5b07577a2735d15022100d589e91bf5014c7c360342ad135259dd7ae684e2c21234d7a912b43d148fcf19"),
},
{
  message: fromHex("d10131982dd1a1d839aba383cd72855bf41061c0cb04dfa1acad3181f240341d744ca6002b52f25fb3c63f16d050c4a4ef2c0ebf5f16ce987558f4b9d4a5ad3c6b81b617de00e04ba32282d8bf223bfedbb325b741dfdc8f56fa85c65d42f05f6a1330d8cc6664ad32050dd7b9e3993f4d6c91e5e12cbd9e82196e009ad22560"),
  privkey: fromHex("79506f5f68941c60a0d7c62595652a5f42f2b9f5aa2b6456af1c56a79a346c2f"),
  signature: fromHex("3046022100ccdbbd2500043bf7f705536d5984ab5f05fdc0fa3cf464d8c88f861e3fc8e54c022100d5c6342c08dcd8242e1daf3595cae968e320a025aa45ec4bc725795da3d1becb"),
},
{
  message: fromHex("ef9dbd90ded96ad627a0a987ab90537a3e7acc1fdfa991088e9d999fd726e3ce1e1bd89a7df08d8c2bf51085254c89dc67bc21e8a1a93f33a38c18c0ce3880e958ac3e3dbe8aec49f981821c4ac6812dd29fab3a9ebe7fbd799fb50f12021b48d1d9abca8842547b3b99befa612cc8b4ca5f9412e0352e72ab1344a0ac2913db"),
  privkey: fromHex("4c53b8e372f70593afb08fb0f3ba228e1bd2430f562414e9bd1b89e53becbac8"),
  signature: fromHex("304402205c707b6df7667324f950216b933d28e307a0223b24d161bc5887208d7f880b3a02204b7bc56586dc51d806ac3ad72807bc62d1d06d0812f121bd91e9770d84885c39"),
},

All those signatures are successfully validated by bitcoin-ts. But when I calculate the signatures from message and privkey, I get different (also valid) signatures for the 0-based list indices 2,4,5,6,9,11,12,13,14,15,17,18:

   (index 02) Expected '304502210083de9be443bcf480892b8c8ca1d5ee65c79a315642c3f7b5305aff3065fda278022068b86cdedd46c313bd352711b9cf5707eecdb58f23bc56e07519376570d0cae9'
              to equal '304602210083de9be443bcf480892b8c8ca1d5ee65c79a315642c3f7b5305aff3065fda2780221009747932122b93cec42cad8ee4630a8f6cbe127578b8c495b4ab927275f657658'.
   (index 04) Expected '304402200e0c5228e6783bee4d0406f4f7b7d79f705f0dbb55126966f79e631bd8b2307902200551cc513a4f0502cbec3eb4021063821fe8311642b663f314bef46079b3e029'
              to equal '304502200e0c5228e6783bee4d0406f4f7b7d79f705f0dbb55126966f79e631bd8b23079022100faae33aec5b0fafd3413c14bfdef9c7c9ac6abd06c923c48ab136a2c56826118'.
   (index 05) Expected '3045022100b9d3962edadc893f8eeff379f136c7b8fc6ea824a5afc6cbda7e3cb4c7a1e860022044e3e06fe30baf120231df979cad44f1ca0899b69e258c2cf755cc44c2b6a3d7'
              to equal '3046022100b9d3962edadc893f8eeff379f136c7b8fc6ea824a5afc6cbda7e3cb4c7a1e860022100bb1c1f901cf450edfdce20686352bb0cf0a643301123140ec87c92480d7f9d6a'.
   (index 06) Expected '30450221009369ab86afae5e22ed5f4012964804d2a19c36b8b58cf2855205b1cfcc93742202205d8203c727664871230c75e4d4aca8704887d1de71cb36f97387140faa62a1f4'
              to equal '30460221009369ab86afae5e22ed5f4012964804d2a19c36b8b58cf2855205b1cfcc937422022100a27dfc38d899b78edcf38a1b2b53578e72270b083d7d69424c4b4a7d25d39f4d'.
   (index 09) Expected '3045022100f753c447161aa3a58e5deeca31797f21484fb0ec3a7fe6e464ab1914896f253b0220669bf04331e0da02998bb4fb91f202a6c08bd5e15954678c53740663fbb7a19a'
              to equal '3046022100f753c447161aa3a58e5deeca31797f21484fb0ec3a7fe6e464ab1914896f253b02210099640fbcce1f25fd66744b046e0dfd57fa23070555f438af6c5e5828d47e9fa7'.
   (index 11) Expected '304402204ce72a83cf1d148db4d1e46e2f773c677f72933c40d7100b9192750a1c8222a8022062a04298317645738620623c4bd6ddfc502a4454931cc4ed16def9f5f7aa1446'
              to equal '304502204ce72a83cf1d148db4d1e46e2f773c677f72933c40d7100b9192750a1c8222a80221009d5fbd67ce89ba8c79df9dc3b42922026a8498921c2bdb4ea8f36496d88c2cfb'.
   (index 12) Expected '304402201f1e1fb673e9a7dee09961c6824b473189904deb4f0d8e28da51f77f4de2efe6022051720e0324dd905374b91b6b8df1ba07e109a7e53a4df118db56fb62e1c9e326'
              to equal '304502201f1e1fb673e9a7dee09961c6824b473189904deb4f0d8e28da51f77f4de2efe6022100ae8df1fcdb226fac8b46e494720e45f6d9a5350174faaf22e47b6329ee6c5e1b'.
   (index 13) Expected '30450221009cf7d941dcbbbe61c2a6f5112cb518094e79e5d203891de2247e75fd532c3f21022003a5fba864dad90dabc102d5a817d49a3d0e517d8a88ac9ecfb125027988d063'
              to equal '30460221009cf7d941dcbbbe61c2a6f5112cb518094e79e5d203891de2247e75fd532c3f21022100fc5a04579b2526f2543efd2a57e82b647da08b6924bff39cf021398a56ad70de'.
   (index 14) Expected '3044022059cd6c2a30227afbd693d87b201d0989435d6e116c144276a5223466a822c0f202204feb6a10256964c02c5d3fa55f675b1e6fa1ce722821a3da4b6fe0eb752209a8'
              to equal '3045022059cd6c2a30227afbd693d87b201d0989435d6e116c144276a5223466a822c0f2022100b01495efda969b3fd3a2c05aa098a4e04b0d0e748726fc6174627da15b143799'.
   (index 15) Expected '30450221009eaf69170aeba44966afe957295526ee9852b5034c18dc5aeef3255c8567838a0220142b3721d3dd4a3477fc291f8fe79877c3d902048f1d00b22d5b645b29c98d86'
              to equal '30460221009eaf69170aeba44966afe957295526ee9852b5034c18dc5aeef3255c8567838a022100ebd4c8de2c22b5cb8803d6e070186786f6d5dae2202b9f899276fa31a66cb3bb'.
   (index 17) Expected '3045022100fe43eb9c38b506d118e20f8605ac8954fc0406efd306ba7ea5b07577a2735d1502202a7616e40afeb383c9fcbd52ecada6213fc85803ed366b6416bfaa4fbba67228'
              to equal '3046022100fe43eb9c38b506d118e20f8605ac8954fc0406efd306ba7ea5b07577a2735d15022100d589e91bf5014c7c360342ad135259dd7ae684e2c21234d7a912b43d148fcf19'.
   (index 18) Expected '3045022100ccdbbd2500043bf7f705536d5984ab5f05fdc0fa3cf464d8c88f861e3fc8e54c02202a39cbd3f72327dbd1e250ca6a351695d78e3cc10502b3eff8ace52f2c648276'
              to equal '3046022100ccdbbd2500043bf7f705536d5984ab5f05fdc0fa3cf464d8c88f861e3fc8e54c022100d5c6342c08dcd8242e1daf3595cae968e320a025aa45ec4bc725795da3d1becb'.

Looks like the first part of the signature is always okay.

Hi

I am using bitbox in mt project and I work to convert it from use (bitbox or bch-js) to use libauth

and I have small problem is this method

but I do not know if libauth have like method

bitbox.Crypto.sha256(inputLockScript);

bitbox.Address.isCashAddress(address)

bitbox.Crypto.hash256(...);

bitbox.Address.fromOutputScript(lockscript)

bitbox.Address.cashToHash160(address)

bitbox.Address.detectAddressType(address)

bitbox.ECPair.fromPublicKey(
          verificationParts.publicKey
);

 bitbox.ECPair.verify(
          verificationKey,
          verificationMessage,
          verificationSignature
);

The following works with node 12.14.0.

// index.mjs
import bitcoints from 'bitcoin-ts';
import crypto from 'crypto';

/*
import { instantiateSha256 } from 'bitcoin-ts';
produces error: 
import { instantiateSha256 } from 'bitcoin-ts';
         ^^^^^^^^^^^^^^^^^
SyntaxError: The requested module 'bitcoin-ts' does not provide an export named 'instantiateSha256'
*/

(async () => {
  const b = Buffer.from('hello');
  const bitcoinSha256 = await bitcoints.instantiateSha256();
  console.log('bitcoin-ts', Buffer.from(bitcoinSha256.hash(b)).toString('hex'));
  const nodeSha256 = crypto.createHash('sha256').update(b).digest('hex');
  console.log('nodecrypto', nodeSha256);
})();

node --experimental-modules index.mjs

The docs state that it is, and recommends a builder/bundler etc. I'm using vite, and when importing libauth in an otherwise working project I get:

[vite] ✘ [ERROR] Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)
[vite]     node_modules/@bitauth/libauth/build/lib/crypto/default-crypto-instances.js:6:53:
[vite]       6 │ ... [sha1, sha256, sha512, ripemd160, secp256k1] = await Promise.all([
[vite]         ╵                                                    ~~~~~

So is it supporte, and if so, what is needed to get it working?

Hello @bitjson , trying to get signed and verified string messages on mainnet-js but hitting a bit of an issue with the signatures from libauth.

For testing, the example from electron-cash was taken, but implemented for mainnet-js here:

https://github.com/mainnet-cash/mainnet-js/blob/c4345dd17e2e1c83509dad661ed745fde33efaa4/src/message/signed.test.ts#L27

message: "Chancellor on brink of second bailout for banks" 
PrivateKey: L1TnU2zbNaAqMoVh65Cyvmcjzbrj41Gs9iTLcWbpJCMynXuap6UN
Cash Address: bitcoincash:qqehccy89v7ftlfgr9v0zvhjzyy7eatdkqt05lt3nw

The implementation to sign is here:

https://github.com/mainnet-cash/mainnet-js/blob/c4345dd17e2e1c83509dad661ed745fde33efaa4/src/message/signed.ts#L57

After applying the message formatting and using secp256k1.signMessageHashRecoverableCompact, this returns a signature of:

/2Mw6ePgwVsfd3u3jIJD2LsOBlT9VnbvzDf7JK/YXjIix2qOxzmeDeSY3w5kBOGDJ8Jk5DFkJbNr1XlfOVVjRg==

From what I understand, with different nonces there can be different there can be different signatures. However, the resulting signature from libauth with secp256k1.signMessageHashRecoverableCompact() throws an error on https://tools.bitcoin.com/verify-message/ as being too short.

There have been separate tests to break out and test the message magic formatting and they appear to match what is created by electron-cash.

It's not clear from the documentation what the RecoveryId is used for. I'm thinking that perhaps this id should have been included in the signature.

Its there anything that clearly stands out as being incorrect. Would it be possible to use signMessageHashSchnorr and future-proof against leaking keys using RFC6979?

I have a BCH-only project that is packaged with Parcel.

When I run the bundle analyzer I can see both btc and bch opcodes in the vm/instruction-sets:

• bch/2023/bch-2023-opcodes.js
• btc/btc-opcodes.js

I'm not sure if this is intended, or if the btc-opcodes should be tree-shaken and removed from the bundle.

Hey, great library. I was able to reliably generate BTC addresses using HD.

Next I'd like to build a multisig address (P2SH or P2WSH), and spend any inputs. I can't seem to figure out the API for this, can anyone point me to the correct instances or functions I should be using? Thank you!

Hello,

I'm trying to import and use the function importAuthenticationTemplate but I am not able to import it.

example code:

import { importAuthencicationTemplate, authenticationTemplateP2pkh }

const template = importAuthenticationTemplate(authenticationTemplateP2pkh);

result: Uncaught SyntaxError: ambiguous indirect export: importAuthenticationTemplate

alternate approach:

import * as libauth from "@bitauth/libauth";

const template = libauth.importAuthenticationTemplate(authenticationTemplateP2pkh);

result: libauth.importAuthenticationTemplate is not a function

Manually searching for the function:

cd node_modules/@bitauth/libauth
grep -R "importAuthenticationTemplate"

result: <no result>

I found it interesting that the "schema" dir is also not visible on the code coverage tool: https://app.codecov.io/gh/bitauth/libauth/tree/master/src/lib

The function is clearly defined in https://github.com/bitauth/libauth/blob/master/src/lib/schema/authentication-template.ts, exported in https://github.com/bitauth/libauth/blob/master/src/lib/schema/schema.ts, and exported again in https://github.com/bitauth/libauth/blob/master/src/lib/lib.ts, so I'm at quite a loss for why this function won't import :(

your library seems quite good but I'm unable to understand how to do simple basic operations like:

• decoding a tx from hex
• building a tx from some UTXO with a destination address
• encoding the built tx for signing
• generate taproot address, if possible

Thanks for any help / pointers to the right place!

Doing a fresh git clone:

$ yarn
yarn install v1.12.3
[1/5] 🔍 Validating package.json...
[2/5] 🔍 Resolving packages...
[3/5] 🚚 Fetching packages...
error https://registry.yarnpkg.com/event-stream/-/event-stream-3.3.6.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

One missing functionality I am missing from this library is the ability to combine multiple public keys. This is provided by libsecp256k1 with secp256k1_ec_pubkey_combine.

I'm trying to use bitcoin-ts inside my (synchronous) library, but it's a bit clumsy to use due to the async nature of instantiateSecp256k1 and (AFACIT) will force my functions to also become async (or loading the library async). I'm not quite sure how the webassembly stuff works, but I'm wording if it's possible to have a blocking version?