Fixes #9

I've updated this PR with all the related stuff:

• [x] synced with the latest master branch.
• [x] formatted the source & test files.
• [x] add a github action to check the format.
• [x] add pre-commit hook

im unable to upgrade bsv-wasm to latest version, but would like to use the new testnet address support. Im currently using 1.2.3 in prod with no issues. When i upgrade to 1.3.0-beta.6, bsv-wasm butchers my op_return script when calling .toHex() on a transaction.

ASM string i want to publish, its a twetch post

OP_FALSE OP_RETURN 31394878696756345179427633744870515663554551797131707a5a56646f417574 676d 746578742f706c61696e 74657874 7477657463685f7477746578745f313634373533323430393832322e747874 7c 3150755161374b36324d694b43747373534c4b79316b683536575755374d74555235 534554 7477646174615f6a736f6e 6e756c6c 75726c 676d 636f6d6d656e74 6e756c6c 6d625f75736572 6e756c6c 7265706c79 6e756c6c 74797065 706f7374 74696d657374616d70 6e756c6c 617070 747765746368 696e766f696365 64373935653432622d323462342d343938372d386562382d353665343733316637636237 7c 313550636948473232534e4c514a584d6f5355615756693757537163376843667661 424954434f494e5f4543445341 314a4d6f6456736e376d7248643273646447645742566d324d4d7039517338565146 4834384e5336544d7977496c6a527662615849743041546b4246514b2b5431444b2f504f562b496f59326d53616c6576526b3562644232424876654d5a736a64422f4b3333577071484d5037717a79493958626d332b773d

ASM I get from decoding on WOC the rawtx from transaction.toHex()

OP_FALSE OP_RETURN 31394878696756345179427633744870515663554551797131707a5a56646f417574 676d 746578742f706c61696e 74657874 7477657463685f7477746578745f313634373533323335343733352e747874 OP_SWAP 3150755161374b36324d694b43747373534c4b79316b683536575755374d74555235 534554 7477646174615f6a736f6e 6e756c6c 75726c 676d 636f6d6d656e74 6e756c6c 6d625f75736572 6e756c6c 7265706c79 6e756c6c 74797065 706f7374 74696d657374616d70 6e756c6c 617070 747765746368 696e766f696365 37353839326639392d613436612d343462652d393134382d303737613134326535353236 OP_SWAP 313550636948473232534e4c514a584d6f5355615756693757537163376843667661 424954434f494e5f4543445341 314a4d6f6456736e376d7248643273646447645742566d324d4d7039517338565146 OP_8 397371626775475a58366e433931327577686877707a524e3575575947585561725250373776646e56634751447943355071614759515564545a58367a597478646d364848793166 [error]

rawtx i get from 1.3.0-beta.6 with improper formatting of my op_return script

0200000001570de65ef5fed67a1f702e0dc5f944843dbfb4efad0cacdcad49a278f68f206d010000006b483045022100a33e42d41f0656ab0e9b41cfb923a78672295e8898236292d6e89f0649b8ba43022044014d0d9a00168eb3922271d216315cf084097271bfa970940c1b9b7ab3f8754121029f470ec0384edb3fcdf98dd0c136fe3ff4cfc7e3a7bdb1bdfcc87ee87d90da1effffffff020000000000000000fdbe01006a2231394878696756345179427633744870515663554551797131707a5a56646f41757402676d0a746578742f706c61696e04746578741f7477657463685f7477746578745f313634373533323430393832322e747874017c223150755161374b36324d694b43747373534c4b79316b683536575755374d74555235035345540b7477646174615f6a736f6e046e756c6c0375726c02676d07636f6d6d656e74046e756c6c076d625f75736572046e756c6c057265706c79046e756c6c047479706504706f73740974696d657374616d70046e756c6c036170700674776574636807696e766f6963652464373935653432622d323462342d343938372d386562382d353665343733316637636237017c22313550636948473232534e4c514a584d6f53556157566937575371633768436676610d424954434f494e5f454344534122314a4d6f6456736e376d7248643273646447645742566d324d4d7039517338565146584834384e5336544d7977496c6a527662615849743041546b4246514b2b5431444b2f504f562b496f59326d53616c6576526b3562644232424876654d5a736a64422f4b3333577071484d5037717a79493958626d332b773de4ab0200000000001976a914be6961b83778feb6917a26070b794dc5c70fbaba88ac00000000

rawtx from 1.2.3 with proper formatting of my op_return script

0200000001570de65ef5fed67a1f702e0dc5f944843dbfb4efad0cacdcad49a278f68f206d010000006b483045022100c4d56808cef9d5b49ea6af76efdcfccde41564a3c62cd5aa5fab7c269d18fc07022012a1cf5ea5fefe215bfeba321921fba9f530b50f4a9333c250b1cdd4c7f1224f4121029f470ec0384edb3fcdf98dd0c136fe3ff4cfc7e3a7bdb1bdfcc87ee87d90da1effffffff020000000000000000fdbf01006a2231394878696756345179427633744870515663554551797131707a5a56646f41757402676d0a746578742f706c61696e04746578741f7477657463685f7477746578745f313634373533333130393339372e747874017c223150755161374b36324d694b43747373534c4b79316b683536575755374d74555235035345540b7477646174615f6a736f6e046e756c6c0375726c02676d07636f6d6d656e74046e756c6c076d625f75736572046e756c6c057265706c79046e756c6c047479706504706f73740974696d657374616d70046e756c6c036170700674776574636807696e766f6963652464646438633964642d653164632d343435622d396533312d353466316130333136663733017c22313550636948473232534e4c514a584d6f53556157566937575371633768436676610d424954434f494e5f454344534122314a4d6f6456736e376d7248643273646447645742566d324d4d70395173385651464c58494d525777484632796b676a56532f7a582b52467a717a76446d726a6a6935316e5378626d4d562f53356757555535673872454842465a79544d76726c64787245573766757354334d7142374f5076784b464147434f303de4ab0200000000001976a914be6961b83778feb6917a26070b794dc5c70fbaba88ac00000000

As you can see, bsv-wasm is adding op codes in the middle of my data, no tegridy

Tested with Node v16.10.0 on Linux.

If we take a simple example

const bsv = require("bsv-wasm");
while (true) {
  const key = bsv.PrivateKey.fromRandom();
}

and run it, after 5 minutes we've nearly hit the heap limit

  PID  RES    SHR  %CPU  %MEM     TIME+ COMMAND
 7526 3.7g  21908 138.5   5.9   5:06.24 node

and kaboom!

wasm://wasm/002542aa:1


RuntimeError: unreachable
    at <anonymous>:wasm-function[928]:0x873ca
    at <anonymous>:wasm-function[522]:0x7d4ce
    at Function.fromRandom (/-----/node_modules/.pnpm/[email protected]/node_modules/bsv-wasm/bsv_wasm.js:2133:24)
    at Object.<anonymous> (/-----/test.js:3:30)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:79:12)
    at node:internal/main/run_main_module:17:47

There are different ways to sign a message or message digest dependent on:

• Endianness of the digest when generating ephemeral K
• SHA2 hashing algorithm chosen for signing (SHA256, SHA256d, etc)

Maybe a good way to approach this is having simple sign methods on different structs (like Transaction)

• Transaction Signing

  • Used for signing Sighash buffers
  • Reversed K: true
  • Double SHA256

• Traditional ECDSA Signatures

  • Used for signing any message to be compatible with ECDSA libraries outside of Bitcoin (SSH, Code signing, etc)
  • Reversed K: false
  • Single SHA256

• Bitcoin Signed Messages (BSM)

  • Used for verifying a message has been signed with a Bitcoin P2PKH Address
  • Requires being able to recover a public key from a signature.
  • Reversed K: optional (?)
  • Double SHA256

I noticed it since I only use the stable compiler and I was surprised by the undocumented breaking change.

After the following changes the library doesn't compile in stable anymore: https://github.com/Firaenix/bsv-wasm/blob/67ce940c7c16479257898fa67e414f8a455677a3/Cargo.toml#L15 https://github.com/Firaenix/bsv-wasm/blob/67ce940c7c16479257898fa67e414f8a455677a3/src/lib.rs#L1

I personally don't think removing stable compatibility is a good idea, specially not just to avoid using an ugly long chain of traits in only 3 places...

For now I've removed the feature and the trait alias definition in my local copy in order to be able to keep working with this lib...

Getting errors when running Transaction.fromHex() on some some coinbase transactions, depending on the value of the input scripts. The majority of the coinbase transactions i've tested work, however there are some outliers.

The following testnet transactions are failing failing:

• 2e5dd635c33562dee6ef8be47d3cd7e23fa9e318e6a26aaf6f88ea6d39141fb6
• 73e2aa791918b8a9f5d4dd37c3ada0d1362095749e788f41fe0b466043f74fe8
• cf10f6e38861cee65d03e0b21c24f2297ed612d621e470ece9703653676b37c1
• 8f780508d52563d400f7cf03e740b0bd553dc6110c4f5c1417703078b18c4154
• 946626c46be810e5378148f5a011d706e06ab9450d02219b5acbb2e132e38cfc
• 83f9cc5a2d13072e5446c1f7bf903491de1b54669ecdabb2126e009ce575f4ea

RuntimeError: unreachable
    at wasm://wasm/0031f49e:wasm-function[1366]:0xb6f35
    at wasm://wasm/0031f49e:wasm-function[960]:0xb1030
    at wasm://wasm/0031f49e:wasm-function[126]:0x53616
    at wasm://wasm/0031f49e:wasm-function[142]:0x59a21
    at wasm://wasm/0031f49e:wasm-function[105]:0x49a6e
    at wasm://wasm/0031f49e:wasm-function[451]:0x90a41
    at wasm://wasm/0031f49e:wasm-function[678]:0xa30d8
    at Function.fromHex (/node_modules/bsv-wasm/bsv_wasm.js:3524:24)

Additionally, the following testnet transactions are failing with a different error

• 422f2631ee4f87f6b04c7006ed3096c81f1c22a4d6134a0148b02bcdfbf8ef06
• 917b9fcf0e507c6a11a25b8ef9c81ff95c9cc865234344aaa3c541745faf7583

Error when deserialising Script: OP_IF statement requires an OP_ELSE code

When a signature is created on a TX using SIGHASH_ALL or similar, the HashCache is set. When you subsequently sign with a SIGHASH_NONE, the HashCache hashes show up in the sighashPreimage where they should be zero buffers.

These are some already used topics in other bitcoin (sv) projects, ordered by number of results:

• bitcoin (6803)
• bitcoin-api (183)
• bsv (86)
• bitcoinsv (43)
• bitcoin-sv (28)

• add missing "repository" key info.
• add missing "keywords": add "blockchain"; move "bitcoin", "bsv" away from "categories".
• update "categories": leave only "wasm", "network-programming" and "cryptography::cryptocurrencies".

Adds ability to get all outpoints from all TxIns in a transaction using tx.getOutpoints().

In Js it will return Uint8Array[], in Rust, it will return a Vec<Vec>

For ppl like me who cant read remembering the correct byte order for outpoints is too much brain power would be nice to get the outpoint like txOut.getOutpoint()

With bsv.js (legacy 1.x version) we can define script flags when signing a transaction.

e.g.: bsv.Interp.SCRIPT_ENABLE_MAGNETIC_OPCODES | bsv.Interp.SCRIPT_ENABLE_MONOLITH_OPCODES | bsv.Interp.SCRIPT_VERIFY_STRICTENC | bsv.Interp.SCRIPT_ENABLE_SIGHASH_FORKID | bsv.Interp.SCRIPT_VERIFY_LOW_S | bsv.Interp.SCRIPT_VERIFY_NULLFAIL | bsv.Interp.SCRIPT_VERIFY_DERSIG | bsv.Interp.SCRIPT_VERIFY_MINIMALDATA | bsv.Interp.SCRIPT_VERIFY_NULLDUMMY | bsv.Interp.SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS | bsv.Interp.SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY | bsv.Interp.SCRIPT_VERIFY_CHECKSEQUENCEVERIFY | bsv.Interp.SCRIPT_VERIFY_CLEANSTACK

would be the flag value 870366.

When we sign with bsv-wasm we don't have the option to set the flags and the unlocking of our non-standard script fails.

Does bsv-wasm support settings flags when signing a tx?

Hey @Firaenix, I'm currently running some tests with your new version and experienced a RuntimeError: unreachable when using Transaction.add_outputs(). Adding them all manually with Transaction.add_output() works as expected.

Originally posted by @trgsv in https://github.com/Firaenix/bsv-wasm/issues/53#issuecomment-1273332083

Checking equality between a pair of keys/addresses/scripts/etc. in javascript requires something like the following.

Buffer.compare(a.toBytes(), b.toBytes()) === 0

It would be nice to have a convenience method for checking this.

a.equals(b)

Note: this is separate to the TxIn script name that was fixed in 4ca0fcb9fd091a82f49a6b5aa19aa6027ee5c35a.

https://github.com/Firaenix/bsv-wasm/blob/fa5aceaad3dfd14b368e89b7ae50d3afe38c93ed/src/transaction/txout.rs#L16 https://github.com/Firaenix/bsv-wasm/blob/fa5aceaad3dfd14b368e89b7ae50d3afe38c93ed/src/transaction/txout.rs#L105

This member and related methods should be referred to as script or locking_script.

A txid is calculated as sha256d(tx). When a txid is presented as a string for a human or a text based api, it is first reversed, then hex encoded. This reversing step can be a source of bugs and confusion. Unfortunately, this convention also sees use with block ids, merkle roots, merkle tree nodes, etc.

This lib is currently using reverse order everywhere. As the lib is for low level manipulation of bitcoin primitives, I believe txid should always be in normal order. A txid string in reverse order, should be considered a different construct.

This could be achieved by having separate methods on every object using this bitcoin id convention, or with functions for explicit conversion.

tx.get_id()
tx.get_id_string()

txin.set_prev_tx_id(id)
txin.set_prev_tx_id_string(id)

// or

tx.get_id()
bitidtos(tx.get_id())

txin.set_prev_tx_id(id)
txin.set_prev_tx_id(stobitid(id))

Another thing to consider is the get_id_hex methods. For new users of the lib, it is not clear from the method name what this actually returns. It may be best to remove them entirely.

The TxIn constructor requires a script, however when a transaction input is first created, its script is typically not yet known. Therefore providing a script should be optional.

How I'm currently adding an input

const txin = TxIn.default();
txin.setPrevTxId(prevTxid);
txin.setVOut(prevVOut);
tx.addInput(txin);

How I'd like to add an input

const txin = new TxIn(prevTxid, prevVOut);
tx.addInput(txin);