My ultimate goal is to add authentication to the iota wallet. However, this library currently only allows users to set a token as seen at

https://github.com/iotaledger/iota.lib.js/blob/master/lib/utils/makeRequest.js#L37

Unfortunately, this does not properly authorize a request to a headless node running --remote. I was considering adding settings.user and settings.pass to the library and doing basic auth if those values were present, but I was not sure if settings.token was supposed to be used for this purpose.

If someone could let me know which option to use, I will get you a pull request later today.

The argument in calling ascii.toTrytes(trytes) should be the variable string, not the variable trytes.

/**

• Convert bytes to trytes

• @method toTrytes

• @param {string} string

• @param {string} type

• @returns {string} address (without checksum)
  **/
  var toTrytes = function(string, type) {

  if (type === "ascii") {
  return ascii.toTrytes(trytes);
  }
  }

When I try to get the balances for a seed getInputs iterates over the start and end key to generate addresses:

        for (var i = start; i < end; i++) {

            var address = self._newAddress(seed, i, security, false);
            allAddresses.push(address);
        }

from:
https://github.com/iotaledger/iota.lib.js/blob/221e7692e9bcb7db4427551c303a7f9fcf39e631/lib/api/api.js#L878

This leads to a blocking of the whole Node process until all addresses are generated.

Is there a way to run those async?

Getting the following error when importing the iota.lib.js into another npm module

These dependencies were not found:

* child_process in ./node_modules/xmlhttprequest/lib/XMLHttpRequest.js
* fs in ./node_modules/xmlhttprequest/lib/XMLHttpRequest.js

Reproduction:
create new npm module --> var IOTA = require('iota.lib.js') --> npm install new npm module into quasar emtpy project --> error from above.

In the docs for prepareTransfers it says:

"If you provide an address with a checksum, this function will automatically validate the address for you with the Utils function isValidChecksum."

But then also "address: String 81-tryte encoded address of recipient"

The second of these contradictory statements is actually true since Kerl. If you provide a 90-tryte address in any of these fields, Kerl throws a cryptic error "Error: Illegal length provided", but with 81-tryte addresses it works.

Hi, I'm creating this issue because I think some of the package.json dependencies are not necessary for running this module (only for development). This will decrease the weight of the installed module when doing a npm install --save iota.lib.js in your local project.

The package.json have:

"dependencies": {
  "async": "^2.4.1",
  "big.js": "^3.1.3",
  "browserify": "^14.4.0",
  "mocha": "^3.4.2",
  "xmlhttprequest": "^1.8.0"
}

However it seems that only async and xmlhttprequest are actually used inside lib/. So maybe the other dependencies can be moved to devDependencies. Any reasons why it could not? Especially browserify is quite a big dependency with many sub-dependencies.

When I make more than 20 transactions, all "Receiving" transactions are not retrieved by api.getAccountData, I've tried this with multiple different nodes.
Of course, transactions are present in official wallet.

Can you check if that happens to you too?

Utils.fromTrytes doesn't validate input is Trytes (only that chars come in pairs):

>iota.utils.fromTrytes('AC1233')
"R￤￤"

these ￤ are due to:
TRYTE_VALUES.indexOf(trytes[0]); indexOf() returns -1
so character = String.fromCharCode(-1+-1*27) => ￤

in the spirit of @nicoschtein validation additions,
I propose to return null if non-tryte char was found (can be done while looping).

in addition, tests for this unit first convert using toTrytes() - so edge cases like this aren't caught.

Credit to Laurence Tennant & his tool for making this interface accessable.

I have this one Seed with roughly 40 Adresses and around 10tx and it takes very long to open, obviously, but when I cklick refresh 90% of the time nothing happens and an error message (see below in screenshot) pops up. OFC my node is running, I have neighbours, and I use 1.1.2.2 on OSX. This error is not the case with Seeds that have LESS tx/adresses.

Update: That error comes, too, when reopening from scratch

I prefer to write my JS with async/await and the readme only shows callback style. So I have to ask-is there no planned support for promises?
I already created a similar issue here:
iotaledger/iota.crypto.js#4
but it would be great to have it in both.

Any 'valid' address of 81 trytes, si of course OK, and if I add 9 trytes more (as checksum) it's still valid, regardless of the added 9 trytes.
Should not this function verify checksum if provided ? It does not, it only verifies that it is 9 trytes long...

both 'real' address : RQRKXKSMC9YEGOZOCVNPDPLNSFMMDIJKYDQWUE9YEUCHFDYZKZLLXFFIPTHOMPDYQTUIRNKUIAZSUBTFAHCKLPOMEY
and wrong address: RQRKXKSMC9YEGOZOCVNPDPLNSFMMDIJKYDQWUE9YEUCHFDYZKZLLXFFIPTHOMPDYQTUIRNKUIAZSUBTF9999999999
is considered 'valid' by the api-function.

Hello everyone. Almost all companies are behind a proxy. If we want that IOTA become the backbone of IOT and micro payment we have to allow companies to use it. To set up the proxy do the following :

Note that you have to change ec2-user by your user name

So, the IOTA lib is using this https://www.npmjs.com/package/xmlhttprequest to simulate the browser environment. This doesn’t have a proxy configuration, but there is fork that does https://github.com/jbeuckm/node-XMLHttpRequest

Copy https://github.com/jbeuckm/node-XMLHttpRequest/blob/master/lib/XMLHttpRequest.js that has the proxy patch to the local file system on /home/ec2-user/IOTA/test/node_modules/xmlhttprequest/lib/xml/XMLHttpRequest.js

The new library needs a config parameter, so we need to change /home/ec2-user/IOTA/test/node_modules/iota.lib.js/lib/utils/makeRequest.js to include the config parameter and pass it to make request:

So at the beginning of the file:

var config = { "proxy" : { "host": "your proxy", "port" : XXXX}}

Change everywhere in the file

var request = new XMLHttpRequest();

by
var request = new XMLHttpRequest(config);

As far as I can tell it doesn't mean that one should replay that transaction and more that one can replay it, right?

In lib/utils/asciiToTrytes.js, nodejs cannot execute the function charCodeAt(0), because the object named 'char' it is not recognized as String object.

function toTrytes(inputString) {
var TRYTE_VALUES = "9ABCDEFGHIJKLMNOPQRSTUVWXYZ";
var trytes = "";

for (var i = 0; i < inputString.length; i++) {
var char = inputString[i];
var asciiValue = char.charCodeAt(0);

This coding works:
inputString = String(inputString);
for (var i = 0; i < inputString.length; i++) {
var asciiValue = inputString.charCodeAt(i);

When trying to connect to a full node running latest IRI (1.4.1) I get:

Request Error: Invalid API Version

API.js Line 367
var command = apiCommands.interruptAttachingToTangle is missing (); at the end.

Example:

var IOTA = require('iota.lib.js');
// Create IOTA instance directly with provider
var iota = new IOTA({
    'provider': 'http://localhost:14265'
});
 // undefined address
  var adr;
 iota.valid.isAddress(adr)

Result:
node_modules/iota.lib.js/lib/utils/inputValidator.js:12
if (address.length === 90) {
^
TypeError: Cannot read property 'length' of undefined

We need to add documentation of interruptAttachingToTangle

The library needs to be optimized for light nodes.

• Cache whatever can be cached.
• Optimize the calls to the light node server. For example, instead of calling getTrytes with a single hash, combine all hashes into an array and call getTrytes 1 time. Same is probably true for other API methods such as findTransactions.

Right now, there are several overloaded light nodes which causes a lot of HTTP error 500 errors which in turn cause the wallet to malfunction.

4462ffe allows to override the balance. if the balance is undefined in input, we check for the balance using the api.

this results in a crash:

ERR! Cannot set property 'signatureMessageFragment' of undefined
ERR! TypeError: Cannot set property 'signatureMessageFragment' of undefined
ERR!     at Multisig.addSignature (/Users/robert/bitfinex/smidgen/node_modules/iota.lib.js/lib/multisig/multisig.js:337:67)
ERR!     at iota.multisig.initiateTransfer (/Users/robert/bitfinex/smidgen/lib/cmds/multisig.js:269:27)
ERR!     at createBundle (/Users/robert/bitfinex/smidgen/node_modules/iota.lib.js/lib/multisig/multisig.js:233:20)
ERR!     at Multisig.initiateTransfer (/Users/robert/bitfinex/smidgen/node_modules/iota.lib.js/lib/multisig/multisig.js:237:11)
ERR!     at continueWithSeed (/Users/robert/bitfinex/smidgen/lib/cmds/multisig.js:256:23)
ERR!     at getSeed (/Users/robert/bitfinex/smidgen/lib/cmds/multisig.js:240:7)
ERR!     at read (/Users/robert/bitfinex/smidgen/lib/get-seed.js:16:5)
ERR!     at Interface.onLine (/Users/robert/bitfinex/smidgen/node_modules/read/lib/read.js:111:5)
ERR!     at emitOne (events.js:96:13)
ERR!     at Interface.emit (events.js:188:7)
ERR!

If you'd really like to see this being used in IoT, like your mission statement claims, please provide a C library without external dependencies ( save the standard library).

Even if just a thin client, this will ACTUALLY work in the IoT setting, instead of expecting people to port a js interpreter to their IoT device, which, mind you, is starved for CPU & RAM.

    iota.api.prepareTransfers(data.seed, data.dest, function(error, response){

response is null,
error contains the array of trytes.

Here is a simple example which I encountered during create a new transfer:

var message =  iota.utils.toTrytes("hello world");  // WCTC9D9DCDEAKDCDFD9DSC
// Work fine with console.log(iota.utils.fromTrytes(message )); --> hello world

Then I created the transaction:

attached.signatureMessageFragment = 'WCTC9D9DCDEAKDCDFD9DSC99999.....';
// console.log(iota.utils.fromTrytes(attached.signatureMessageFragment)); --> null 

Why it is null? If is there a rule how many "9999" should be cleaned up from the response why it isn't documented?

There is a possible bug in the iota.api.getNewAddress() method.

By not providing "index" field in the options parameter works correctly (returns the next unused address).
But providing a integer in the "index" field doesn't always return the correct address located in that index.

To recreate the problem, try to use pass a index value for which the associated address has already been used or attached to the tangle. Index of unused address seems to be working.

I know that we can pass int values in start Index and End index. But how would we know that what should be the End index? Let's say I am making a wallet, How can i display user their balance if I don't know the exact End index? And if I pass anything as a guess, won't it make the whole thing slow OR ignore many addresses with non-zero balance?

Please help me understand this, so that I can build something beautiful.

Hi, I'm starting a new IOTA project (with IOTA as the data layer) and I'm getting a 401 (unauthorized) error when invoking sendTransfer for one of the Light Wallet Servers listed on iotasupport.com/lightwallet.shtml. Is it possible to invoke sendTransfer() with a Light Wallet Server and, if so, is there any documentation on how to do this?

I've run the leaderboard example by @domschiener at https://github.com/domschiener/leaderboard-example and replaced localhost with one of the wallet servers. getAccountData() works as expected and shows the correct balance from the Tangle, but any sendTransfer is 401'd.

Any guidance or help is super appreciated!

I have:

iota.api.sendTransfer(seed, 2, 18, [
  {
    address: 'AIB9GPOOOJFPWOKNLHUU9NSUDHDYJHDQL9OLYXLQEAXYWEARPAMPWPDKTZYOOM9KTWYDMFNNILLEKB9N9HJOSUEJLD',
    value: 4
  }
], (err, data) => {
  console.log('err: ', err)
  console.log('data: ', data)
})

now when I run that I get:

capaj@capaj-i7-4771:~/git_projects/gratiota$ node test.js
err:  Error: Request Error: COMMAND attachToTangle is not available on this node
    at Object.requestError (/home/capaj/git_projects/gratiota/node_modules/iota.lib.js/lib/errors/requestErrors.js:11:12)
    at makeRequest.prepareResult (/home/capaj/git_projects/gratiota/node_modules/iota.lib.js/lib/utils/makeRequest.js:167:24)
    at exports.XMLHttpRequest.request.onreadystatechange (/home/capaj/git_projects/gratiota/node_modules/iota.lib.js/lib/utils/makeRequest.js:61:25)
    at exports.XMLHttpRequest.dispatchEvent (/home/capaj/git_projects/gratiota/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25)
    at setState (/home/capaj/git_projects/gratiota/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14)
    at IncomingMessage.<anonymous> (/home/capaj/git_projects/gratiota/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:447:13)
    at emitNone (events.js:110:20)
    at IncomingMessage.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1045:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
data:  undefined

is this command removed from IRI? Is the JS lib out of date?

Reproduce

The following code

var iota = new IOTA({
  'provider': 'https://sandbox.iota.org/api/v1/',
  'sandbox': true,
});
iota.api.getNodeInfo(function(error, success) {
    if (error) {
        console.error(error);
    } else {
        console.log(success);
    }
})

results in this error:

Error: Invalid Response: Unsupported Media Type

Possible Solution

Why was this line commented out:
https://github.com/iotaledger/iota.lib.js/blob/37c5a1b10d8d6d7c6d688443f7c5b474e64d7679/lib/utils/makeRequest.js#L33
Commenting it back in fixes this issue.

I'm hitting a missing error handle line at https://github.com/iotaledger/iota.lib.js/blob/master/lib/api/api.js#L1448. I believe there should be a if (error) return callback(error); there, or something. I'm falling through to line 1453 and blowing up because transactionObjects is missing.

In Multisig.initiateTransfer, the value of totalBalance is hardcoded to 1000. It seems like this was intended to be for temporary/debugging purposes though:

var totalBalance = 1000 // parseInt(balances.balances[0]);

https://github.com/iotaledger/iota.lib.js/blob/master/lib/multisig/multisig.js#L248

Issue on line 1480 of api.js;

var thisInclusion = tailTxStates[tailTxArray.indexOf(tailTx)];

Uncaught typeError: Cannot read property '0' of undefined

As title:
The docs don't outline how to change the remote node. I've been creating a new IOTA object. I only found it when looking around in the code.

It might be useful to add this in.

It's useful to have a template for Issues and Pull requests so every developer knows which set of data to provide when creating an issue. this has multiple benefits:

• saves the developer from digging the entire code to disclose the issue when facing issues title like Undefined.
• Keeps the issues usable for the future community members to easily fine similar issues and avoid opening duplicated and redundant issues.

Also it's worth having a PR template so the reviewer gets onboard faster, not to mention it reduces the chance of misunderstanding and helps put the developer and reviewer on the same page.

when moving tag to obsoleteTag,
the lib no longer copies the tag provided to transaction - in prepareTransfers : api.js#L1003

Hi Dominik,

I didn't know what was the best way to reach out to you so I am reaching out this way.
I work for the “Blockchain Research Group” at the Cloud.Security Alliance;We are a Non-Profit organization focused on understanding and sharing various working aspects of Blockchain technology all over the World(via our Peer-reviewed Research Papers) & through our Member Developers.

We are interested in learning more about what your solution exactly offers in this space.Is it possible for you(or someone on your development team) to give our working group a 25–30 minutes detailed presentation on this issue?

You can reach out to either me(as Chairman of the Initiative) or our Research Analyst-Ms.Hillary Baron via Email- [email protected]

Many Thanks& Looking to hear from you soon!

Ashish.Mehta

Chairman,
Blockchain Research Group
Cloud Security Alliance.

Getting the following error when calling sendTransfer:

VM1804:3501 Uncaught (in promise) Error: Invalid attached Trytes provided
    at Object.invalidAttachedTrytes (eval at module.exports (addScript.js:8), <anonymous>:3501:16)
    at api.storeTransactions (eval at module.exports (addScript.js:8), <anonymous>:352:32)
    at api.storeAndBroadcast (eval at module.exports (addScript.js:8), <anonymous>:464:10)
    at eval (eval at module.exports (addScript.js:8), <anonymous>:540:22)
    at doNext (curl.lib.js:67)
    at curl.lib.js:78
    at <anonymous>

To reproduce, run the following:

let CURL = require('curl.lib.js')
let IOTA = require('iota.lib.js')
let seed = "UFLKWXVHYTPDBAOJS9CQMGNRZEI" // This was randomly generated
let iota = new IOTA({host:"http://iota.bitfinex.com", port:80})
CURL.overrideAttachToTangle(iota.api);
CURL.init()
iota.api.getNewAddress(seed, {}, (error, address) => {
    console.log("ADDRESS:", address)
    if (error) throw error;
    let transfers = [{
        'address': address,
        'message': iota.utils.toTrytes("testing"),
        'value': 0,
        'tag': 'SURJIKAL'
    }]
    iota.api.sendTransfer(seed, 4, 14, transfers, (error, results) => {
        if (error) throw error;
        console.log("RESULTS:", results)
    });
});

This was working fine before the latest update. I traced the error to iota.lib.js/isArrayOfAttachedTrytes. The tryte that gets passed in this function is 2727 characters long, but the function expected it to be 2673 characters long. I don't know what this means but that's what causes the validation to fail.

Similar error is thrown if I remove the CURL stuff.

Related issue: iotaledger/legacy-wallet-use-trinity-wallet-instead#21 (comment)

Since getNewAddress() creates addresses one-by-one and calls findTransactions() on every single one of them, it is slow even when there are not so many addresses.

Possible solution

• don't create them one-by-one, but batches of five or so (in expectation that the first one might be used already)
• if the newly created address(es) are taken then do not index++, but try if index * 2 is free and do a binary search between index and index * 2

Hi! I found several issues with the multisig example:

The first issue was introduced with 4462ffe. The bug is fixed by passing the new initiateTransfer arguments.

However after fixing this issue, the example breaks in another place for me:

/Users/robert/bitfinex/iota.lib.js/lib/crypto/bundle/bundle.js:121
            sum += (normalizedBundle[i * 27 + j] = Converter.value(Converter.trits(bundleHash.charAt(i * 27 + j))));
                                                                                             ^

TypeError: Cannot read property 'charAt' of undefined
    at Bundle.normalizedBundle (/Users/robert/bitfinex/iota.lib.js/lib/crypto/bundle/bundle.js:121:94)
    at Object.validateSignatures (/Users/robert/bitfinex/iota.lib.js/lib/crypto/signing/signing.js:178:39)
    at Object.validateSignatures (/Users/robert/bitfinex/iota.lib.js/lib/utils/utils.js:344:20)
    at /Users/robert/bitfinex/iota.lib.js/examples/multisig.js:68:64
    at Multisig.addSignature (/Users/robert/bitfinex/iota.lib.js/lib/multisig/multisig.js:343:12)
    at /Users/robert/bitfinex/iota.lib.js/examples/multisig.js:65:23
    at Multisig.addSignature (/Users/robert/bitfinex/iota.lib.js/lib/multisig/multisig.js:343:12)
    at /Users/robert/bitfinex/iota.lib.js/examples/multisig.js:59:19
    at createBundle (/Users/robert/bitfinex/iota.lib.js/lib/multisig/multisig.js:233:20)
    at Multisig.initiateTransfer (/Users/robert/bitfinex/iota.lib.js/lib/multisig/multisig.js:237:11)

I generate a new address with the javascript command:

`var XMLHttpRequest = require("xmlhttprequest").XMLHttpRequest;

var performance = require("performance-now");

var IOTA = require("iota.lib.js");

var seed = "RANDOMSEED"

var iota = new IOTA({
'host': 'http://localhost',
'port': 33333
});

iota.api.getNewAddress(seed,[0,true,1,true],function(e,s) {
console.log("ERROR: "+e);
console.log("ADDRESS: "+s);
});
`
Then I try to increment the argument 'index' of getNewAddress in order to generate a new address:

`var XMLHttpRequest = require("xmlhttprequest").XMLHttpRequest;

var performance = require("performance-now");

var IOTA = require("iota.lib.js");

var seed = "RANDOMSEED"

var iota = new IOTA({
'host': 'http://localhost',
'port': 33333
});

iota.api.getNewAddress(seed,[1,true,1,true],function(e,s) {
console.log("ERROR: "+e);
console.log("ADDRESS: "+s);
});
`

I also try to generate a list of address with the command

`var XMLHttpRequest = require("xmlhttprequest").XMLHttpRequest;

var performance = require("performance-now");

var IOTA = require("iota.lib.js");

var seed = "RANDOMSEED"

var iota = new IOTA({
'host': 'http://localhost',
'port': 33333
});

iota.api.getNewAddress(seed,[1,true,5,true],function(e,s) {
console.log("ERROR: "+e);
console.log("ADDRESS: "+s);
});`

but no matter what argument i set, i always have the return

`ERROR: null

ADDRESS: X9MDSKGMQKG9SWDNHCZL9QLINUWSVYZUXMGOCCDXRTQCRWSUZNIELZWOQBSJNFO9SKYGYASF9SEBGCIIJ`

Too lazy now, will do in the future.

Sorry but I really dont know whats wrong. I have used the high level function for doing a transfer iota.api.sendTransfer and it worked, then I tried to send the options so that I can control remainder address and funding addresses, there the error happened the fist time. But now it also happens when not using any funding addresses. Anyway this should not happen when using highlevel functions.

Here is the stack trace:
/home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/crypto/kerl/kerl.js:29
throw new Error('Illegal length provided');
^

Error: Illegal length provided
at Kerl.absorb (/home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/crypto/kerl/kerl.js:29:15)
at Bundle.finalize (/home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/crypto/bundle/bundle.js:95:14)
at signInputsAndReturn (/home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/api/api.js:1250:16)
at addRemainder (/home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/api/api.js:1215:21)
at /home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/api/api.js:1166:21
at /home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/api/api.js:948:28
at makeRequest.prepareResult (/home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/utils/makeRequest.js:189:12)
at exports.XMLHttpRequest.request.onreadystatechange (/home/mike/projekte/crypto-currencys/iota/node_modules/iota.lib.js/lib/utils/makeRequest.js:61:25)
at exports.XMLHttpRequest.dispatchEvent (/home/mike/projekte/crypto-currencys/iota/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25)
at setState (/home/mike/projekte/crypto-currencys/iota/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14)

Reproducible on both dev (504f3f0) and master (45d5214).

See below code for an example. After calling iota.multisig.addSignature, it appears that the signatureMessageFragment for every input in the bundle remains empty:

const Bundle = require('./lib/crypto/bundle/bundle');
const IOTA = require('./lib/iota');

var iota = new IOTA();

var privateKey = iota.multisig.getKey('TESTVALUE9DONTUSEINPRODUCTION99999XKMYQPOIFGQSMIIWCQVMBSOKZASRQOFSIUSSHNDKVL9PJVS', 0, 3);

var multisigAddress = 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI';

var bundle = new Bundle();

// The spend transaction has a signatureMessageFragment, just so we can verify that
// there isn't a problem with the code in the for loop at the bottom.
bundle.bundle = [ { address: 'TESTVALUE9DONTUSEINPRODUCTION99999NDGYBCQZJFGGWZ9GBQFKDOLWMVILARZRHJMSYFZETZTHTZR',
    value: 42,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 0,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX',
    signatureMessageFragment: 'HDWCPCBDLDEAUCIDFDEARCWCTCTCNDQCIDFDVCTCFDGD9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: -42,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 1,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: 0,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 2,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: 0,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 3,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: 0,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 4,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: 0,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 5,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: 0,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 6,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: 0,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 7,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' },
  { address: 'WYIKYFEYULFVZZCVBVOUSGVNBOZEUUBPFEPJKH9EUCSBAGGBYWBCSHSDHSSHRSYSEDW9WSUB9JWTTWALI',
    value: 0,
    tag: 'KITTEHS99999999999999999999',
    timestamp: 1501355744,
    currentIndex: 8,
    lastIndex: 8,
    bundle: 'DZBUANFERBAVZFT9HLVYC9WHLNTJASCXUFKHLWRBQGUFPDAHJBJWB9VNOSE9YTRKRBMEQNQEHFFINFBNX' } ];




iota.multisig.addSignature(bundle, multisigAddress, privateKey, function(error, signedBundle) {
  if(error) { console.log(error); }
  else {
    for(var i = 0; i < signedBundle.bundle.length; ++i) {
      console.log(signedBundle.bundle[i].signatureMessageFragment);
    }
  }
});

The above code outputs:

HDWCPCBDLDEAUCIDFDEARCWCTCTCNDQCIDFDVCTCFDGD9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
undefined
undefined
undefined
undefined
undefined
undefined
undefined
undefined

Note that the first signatureMessageFragment is from the spend transaction (which we hard-coded at the top) — all of the inputs have null signatureMessageFragment.

In lib/api/api.js traverseBundle around line 1271 you get a failure if getTrytes returns an empty trytesList.trytes array. The whole functions throws an error and kills down a few lines when it starts looking for things like txObject.bundle. Does this mean that a transaction is malformed or there's missing data? I'm not sure what the appropriate response should be from traverseBundle when this occurs?

I suspect that's what line 1277, if (trytes === null) return callback(new Error("Bundle transactions not visible")), was trying to catch. If so, just changing that to if (!trytes) should do the trick. That'll catch both null and undefined. When I change that out the bug I'm hitting seems to disappear.