I am reposting this error from here: badger-cash/badger#197

Just in case someone is looking here for same problem. I am pretty sure I have gotten this bug in slp-sdk as well, possibly due to some network issue (rest being down/responding incorrectly perhaps?).

Per title, under Handy Links, SLP API docs link leads to a 404 error.

Some applications may need to access additional methods that are not wrapped by SLP-SDK. For these use cases, it would be useful to expose the whole SLPJS.

I've seen other users have this same request, and I've come across this in consuming SLP-SDK myself.

Summary

In the Genesis Transaction for your token type you can create a minting baton output which gives you the ability to mint more tokens at a later point. This is useful if you have a token with no fixed supply and need to continuously issue new tokens.

We need to add this functionality to SLP SDK.

Details

In SLP.SlpTokenType1 create the following methods:

• buildExtendedMintOutput
• buildExtendedMintRawTx

Do we need to update slpjs and expose it through the above methods? Can we create that functionality in SLP SDK w/out creating it in slpjs?

buildExtendedMintOutput

Per the spec this needs a nulldata output with a properly formatted OP_RETURN. It should spend the mint_baton_vout from the previous transaction as well as create a new mint_baton_vout which enables further minting of tokens. It should optionally be able to not create a new mint_baton_vout output which would provably prevent any further token issuance.

Tests

Check out our Util tests and please add some tests for the extended mint functionality.

More info

• Extended Minting Transaction

this module relies on Babel 6, which is broken:

$ node
> Object.prototype.test = () => null
[Function]
> require('bitbox-sdk')

yields:

Error: You passed traverse() a visitor object with the property "Block" that has the invalid property "test"
at verify (/Users/ekkis/dev/otc-trader/node_modules/babel-traverse/lib/visitors.js:205:17)
at Function.explode (/Users/ekkis/dev/otc-trader/node_modules/babel-traverse/lib/visitors.js:72:3)
at Plugin.normaliseVisitor (/Users/ekkis/dev/otc-trader/node_modules/babel-core/lib/transformation/plugin.js:155:29)
at new Plugin (/Users/ekkis/dev/otc-trader/node_modules/babel-core/lib/transformation/plugin.js:66:27)

I reached out to the Babel guys and they said v6 is no longer maintained and your package should upgrade. please see: babel/babel#9786

please upgrade and let me know when I can refresh

Within TokenType1.ts none of the methods are utilizing the /slp/validateTxid endpoint which will perform much faster than LocalValidator.

The TokenType1.ts library has no unit tests in the test directory

To support the BCH and SLP spec of BCH utxos living on 145' and SLP utxos living on 245', it could be necessary to use a fundingAddress and fundingWif as arrays pulling fundingAddresses and fundingWifs from both paths. This is currently the approach used by mint.bitcoin.com, which relies on a fork of slp-sdk proposed here in #91

Per @thr0wn:

slp-sdk master does not accept an array of values for the parameter 'fundingAddress' and 'fundingWifs'. Even if you pass only path 145' as the single funding address, you will not be able to mint, as path 145' does not have the baton. If you pass only the path 245' you will not have enough funds, as it has only slp utxos.

#91 was tabled with this comment from @SpendBCH:

Thank you for the PR @thr0wn, it's a bit big for us to consider right now though. There may be some more single -> array cases that can be solved with small changes like the ones in #90 , for more elaborate changes or more advanced use cases it may be best to use SLPJS.

In response, I'm looking into a simpler PR to solve the same issue.

In the meantime, mint.bitcoin.com has already diverged from the Bitcoin-com/master repo of slp-sdk. We are looking to ensure that we don't spin off too far on another version going forward. If it's a feature that mint needs, it's probably also a feature that should be added to slp-sdk, and we can assist for dev work and review.

While running create-token.js , facing this error, Also not able to get balance (showing 0) as i have 0.1 tbch .....
Please guide

If TokenType1.send has a non-existent bchChangeReceiverAddress property it fails in an unexpected way (Error: Encountered empty TXID).

This is a manifestation of #27 with actually the same example used as the culprit

When slpjs is instantiated inside slp-sdk, it is not passed any configuration data. This means it calls rest.bitcoin.com and is not configurable for other rest servers. The scope of this issue is to pass the restURL value through slp-sdk and into its instance of slpjs, so that the entire library can be configured for other rest servers.

When importing slp-sdk in a TypeScript project with:
import * as SLP from "slp-sdk";
it will complain:

Error:(7, 22) TS7016: Could not find a declaration file for module 'slp-sdk'. '/ts-test/node_modules/slp-sdk/lib/SLP.js' implicitly has an 'any' type.
  Try `npm install @types/slp-sdk` if it exists or add a new declaration (.d.ts) file containing `declare module 'slp-sdk';`

This error is correct, since there is no .d.ts or .ts file in the root dir.
The best fix would be to rename index.js to index.ts and export proper TS classes (as you already did in bitbox-sdk).

I know I can still use it in a TypeScript project, but without slp-sdk types which defeats the purpose of using TypeScript.

Semantic release has been enabled in SLP SDK. There are some gotchas that we need to be aware of:

• Semantic release uses the commit message format to trigger version changes with commit messages. This is what makes releases 'unromantic and unsentimental' and feature changes well documented.

• This repository publishes an npm package, so it generates a GitHub Release. When releasing on GitHub only but not npm, Semantic Release will only generate a Tag, and not a full Release.

• Semantic release expects tags to start with the letter v and follow the patter vX.X.X. When manually releasing, if a release does not append v to the tag, semantic release won't pick up on it and iterate the version.

• Semantic Release will not automatically update the version in package.json or index.js. But the version of the npm package will increment, and will track the GitHub release. However, Semantic Release supports these plugins. Perhaps one of them would do that kind of versioning?

burn-all currently results in this error:

Token inputs less than the token outputs

Which prevents the example from actually burning anything.

SLPDB url should not be hard coded. This url should be configurable like the rest api url.

The scope of this Issue is to refactor Util.isTokenUtxos() to match the refactoring done to tokenUtxoDetails() in PR #86. The new behavior of this function will return confident false or true. It will only return null if SLPDB has not processed the UTXO yet and has not yet made a determination of its validity.

The workflow for this refactor is as follows:

• For each UTXO, retrieve the raw transaction data from the full node.
• If there is no OP_RETURN in the TX, then the UTXO can be marked as false.
• If there is an OP_RETURN, attempt to decode it. If it can't be decoded, then the UTXO can be marked as false.
• If the OP_RETURN can be decoded as an SLP transaction, then the txid is validated with SLPDB.
• If SLPDB returns null, it means it has not yet processed the utxo. The UTXO should be marked as null to communicate this.
• Otherwise the UTXO can be marked true

The scope of this issue is to refactor unit tests to mock any external service calls. The primary differences between unit and integration tests, is that unit tests do not call external services. External services need to be mocked for unit tests, and live for integration tests.

If unit tests make external calls, then any CI system relying on unit tests will fail when those services fail, and then bad things happen. The reliability of the CI system is thrown into question and the ability to push a fix fails if the CI can't pass tests and validate the PR.

I ran all tests on slp-sdk and they passed. But then I turned off my wifi and ran the tests again. The following tests failed:

561 passing (4s)
  5 failing

  1) #Utils
       #list
         should list all SLP tokens:
     Error: getaddrinfo ENOTFOUND rest.bitcoin.com rest.bitcoin.com:443
      at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)

  2) #Utils
       #list
         should list single SLP token by id: 4276533bb702e7f8c9afd8aa61ebf016e95011dc3d54e55faa847ac1dd461e84:
     Error: getaddrinfo ENOTFOUND rest.bitcoin.com rest.bitcoin.com:443
      at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)

  3) #Utils
       #balancesForAddress
         should fetch all balances for address: simpleledger:qr5agtachyxvrwxu76vzszan5pnvuzy8duhv4lxrsk:
     Error: getaddrinfo ENOTFOUND rest.bitcoin.com rest.bitcoin.com:443
      at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)

  4) #Utils
       #balance
         should fetch balance of single token for address: simpleledger:qr5agtachyxvrwxu76vzszan5pnvuzy8duhv4lxrsk:
     Error: getaddrinfo ENOTFOUND rest.bitcoin.com rest.bitcoin.com:443
      at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)

  5) #Utils
       #validateTxid
         should validate slp txid:
     Error: getaddrinfo ENOTFOUND rest.bitcoin.com rest.bitcoin.com:443
      at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)

For mocking external services, here is an example of how I mock Express:
https://github.com/Bitcoin-com/rest.bitcoin.com/blob/master/test/v2/mocks/express-mocks.js

And here is an example of a mocking library for BITBOX:
https://github.com/christroutner/bch-cli-wallet/blob/master/test/mocks/bitbox.js

your module depends on lodash, which has a problem described here: https://github.com/lodash/lodash/issues/4247

as is evidenced by the thread, the lodash team is completely uncooperative, which means I can't use your module. the fix is small and simple. it is possible for your team to post-patch their module, fork it and fix it, or implement some other kind of solution?

Using the example code from the documentation (https://developer.bitcoin.com/slp/docs/js/socket). I no longer get mempool entries. If I do the same query at https://slpsocket.bitcoin.com/channel I get entries. Making a query for "transactions" works fine.

Using version: 4.15.0

yarn init
yarn add slp-sdk

let SLPSDK = require('slp-sdk');
let SLP = new SLPSDK();

let socket = new SLP.Socket({
    callback: () => {
        console.log("connected")
    },
    wsURL: "wss://ws.bitcoin.com"
});
socket.listen(
    {
        v: 3,
        q: { find: {} }
    },
    msg => {
        console.log(msg)
    }
);

Any ideas?

Bitbox sdk works fine:

yarn init
yarn add bitbox-sdk 

let BITBOX = require('bitbox-sdk').BITBOX;
let bitbox = new BITBOX();

let socket = new bitbox.Socket({
    callback: () => {
      console.log("connected")
    },
    wsURL: "wss://ws.bitcoin.com"
  })
  socket.listen(
    {
      v: 3,
      q: { find: {} }
    },
    msg => {
        console.log(msg)
    }
  )

Tested in Chrome 78
I have uploaded a small sample project to reproduce this error: https://github.com/Ekliptor/BlockchainAPI

I can run the example from here with NodeJS v12 and create a wallet https://github.com/Bitcoin-com/slp-sdk/blob/master/examples/create-wallet/create-wallet.js
However, when I try to run it in the browser I get an error in hdnode.js:

f {message: "Expected property "0" of type ECPair, got g", __label: undefined, __property: 0, __value: g, __type: ƒ, …}
message: "Expected property "0" of type ECPair, got g"
__label: undefined
__property: 0
__type: ƒ t(t)
__value: g {d: n, compressed: true, network: {…}}
__valueTypeName: "g"
stack: "Error: Expected property "0" of type ECPair, got g↵    at a (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:60:76182)↵    at tfSubError (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:60:77360)↵    at http://localhost:63342/BlockchainAPI/blockchain-api.min.js:24:73605↵    at Array.every (<anonymous>)↵    at t (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:24:73547)↵    at d (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:24:74101)↵    at new p (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:72:5919)↵    at Function.p.fromSeedBuffer (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:72:6536)↵    at t.e.fromSeed (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:52:66628)↵    at Object.<anonymous> (http://localhost:63342/BlockchainAPI/blockchain-api.min.js:60:275738)"
__proto__: Error

Stack

(anonymous) | @ | index.js:190
-- | -- | --
  | t | @ | index.js:186
  | d | @ | index.js:233
  | p | @ | hdnode.js:16
  | p.fromSeedBuffer | @ | hdnode.js:48
  | e.fromSeed | @ | HDNode.ts:26
  | (anonymous) | @ | createWallet.ts:40
  | r | @ | bootstrap:19
  | (anonymous) | @ | bootstrap:83
  | (anonymous) | @ | bootstrap:83

Possibly this error should be forwarded to bitcoinjs-lib.

I also remember this worked with SLP-SDK v1.x about 1 year ago, but now even going back to 1.3.2 still results in the same error. So some breaking changes in WebPack (??) could also be the cause.

Description

Currently when calling REST's address/utxo it will return all utxo and the client needs to determine if any of the utxo are colored for SLP tokens.

Ex: https://rest.bitcoin.com/v2/address/utxo/simpleledger:qzht6wanjrxqjp6qyla6t856mfhgktg3wcphvqpm6m

You could use isTokenUtxo but that would require an extra network call for each utxo.

1. We need to make a batch endpoint for that method.
2. We need a method for decoding OP_RETURN on the client and checking if it's slp.

Does this already exist in slpjs? If so expose it in SLP SDK and add docs.

Capturing the results of a team conversation around Util.tokenUtxoDetails().

The current behavior

tokenUtxoDetails() calls validateTxid() for each UTXO it receives, to have SLPDB validate each UTXO. For those UTXOs that come back as valid, the raw transaction data is retrieved from the full node and the OP_RETURN data decoded.

The desired behavior

tokenUtxoDetails() should retrieve the raw transaction data directly from the full node and check for the presence of an OP_RETURN. If there is no OP_RETURN, it can mark the UTXO as false to indicate it is not an SLP UTXO. For those with an OP_RETURN, it should attempt to be decoded. No calls need to be made to SLPDB.

Reasoning

The reason for this change is a realization that SLPDB may not know about a TX, and thus may erroneously return a false negative that would cause a wallet to burn a token. This new method increases demands on full nodes and increases computation, but removes the risk of burning tokens.

Thanks for all of the developer tools Bitcoin.com provides. I'm using SLP-SDK currently but this request is applicable to all of the libraries documented on Bitcoin.com. Currently there is no easy way to get an overview of all of the methods provided by a class. For example, in the SLP HD Node page it is necessary to scroll through the whole page including many, many examples in order to find the verify method. It makes api method discovery very difficult and navigation in general extremely cumbersome. Ideally the "HD Node" menu entry on the left would expand, tree like, when selected to show the topics on the page. Alternatively, a second menu on the right of the page could show a method summary with links.

Anyway, feel free to close this issue if it's not easy to address but it's a recurring pain point for me so I thought I'd give some feedback.

Attempting to initialize SLP to testnet like this:

let slp = new SLP({ restURL: 'https://trest.bitcoin.com/v2/' })

Will fail. SLP will actually initialize to rest.

The scope of this Issue is to investigate and see what may be preventing SLP-SDK from initializing to trest.

The libraries in SLP SDK are riddled with the pattern of return error instead of throw error. Returning an error will not trigger an error handler. Here is an example

The scope of this Issue is to refactor all the libraries in SLP SDK and replace instances of return error with throw error.

I just want to know if there is a chance for BCH to get burnt on the NON SLP Wallets. Like bitcoin ABC core or other unsupported wallets. If there is any resource on this do share it in the comments.

Util.getTokenMetaData() has no unit tests.

The IMintConfig interface only allows one funding address and corresponding private key. Nevertheless a common setup is to have the baton in address A while having extra funds in another address B. Note that BitboxNetwork already includes a simpleTokenMint method that accepts multiple inputs.

Please consider extending IMintConfig to allow multiple funding addresses and private keys.