Hot answers tagged

8

You can call the GetLatestInclusion convenience function in iota.lib.js. Under the hood, this will first call getNodeInfo to find out the latest solid subtangle milestone hash, and then call getInclusionStates to determine if the transaction has been confirmed at that milestone. This might be useful if you use a different API (for a different programming ...


7

The API command reference is available here: https://iota.readme.io/v1.2.0/reference At the time of answering, the commands are: getNodeInfo getNeighbors addNeighbors removeNeighbors getTips findTransactions getTrytes getInclusionStates getBalances getTransactionsToApprove attachToTangle interruptAttachingToTangle broadcastTransactions storeTransactions


7

This occurs when you launch the full node with the --remote-limit-api flag and disallow the use of certain commands. Normally it is used to disallow access to attachToTangle, but the same could happen with getNodeInfo too.


6

Basically there are three ways to get to the data (depending on what you want): Query the API of your node to find transactions and walk along them. This might be slow (depending on what you are looking for), but the API is well-documented and you can walk the tangle quite easily. Directly query the node's database (which is a RocksDB instance) for what you ...


6

1) Every fullnode must reference neighbors and must be referenced by (same) neighbors. When a new transaction is submited to a fullnode: it immediately broadcast it to all it's neighbors. So a node don't need to "fetch" transactions from another node, it just receive them (it just have to permanently listen for broadcast). 1a) In addition to real-time ...


6

Each record represents one transaction which was newly received by the node. I'll take apart one single line (which represents this transaction - so you can compare the values there). The Java code in iri that builds these tx messages is here. tx - this is a transaction received ...


5

Found the problem myself. Addresses must be 81 in length. The address above has a length of 90 because it includes the checksum. The Tangle obviously is clever enough to strip the last 9 digits.


5

If possible, you should make it available via HTTPS as well (as some wallets will only talk to HTTPS nodes). You should definitely disable commands related to neighbors, otherwise others could remove your neighbors or add some others (to send them an UDP flood). The official GUI wallet needs the following commands: getNodeInfo - to retrieve the latest ...


5

There is the findTransactions api (with the approvees parameter) that return the list of all transactions directly approving the one (or the multiple) passed in parameter : curl <NODE_URL> \ -X POST \ -H 'Content-Type: application/json' \ -H 'X-IOTA-API-Version: 1' \ -d '{"command": "findTransactions", "approvees":"<TX_HASH>"]}'


4

It's the "Security level to be used for the private key / address. Can be 1, 2 or 3." A security level determines the number of rounds for hashing, or in other words the length of the private key. Security level 1 : key length 81 trits (security low) Security level 2 : key length 162 trits (security medium) Security level 3 : key length 243 trits (security ...


4

When your node recieve a transaction from one of it's neighbors: this transaction is referencing 2 other transactions : t1 and t2 (trunk and branch transaction). If either t1 or t2 (or both) is not in the database of your node: then the transaction hash of t1 (or t2 or both) is added to the queue of the "transactions to request to one of your neighbors". ...


4

Exposing your API to the public has risks, but is not necessarily a problem. Some of the risks include a higher likelihood of a Denial of Service attack, additional attempts to port-scan your IP (for example, to see if you have an open SSH port as well), etc. Additionally, if you do expose the API to the public, you will want to limit which API calls are ...


4

When you reattach a transaction bundle, you will have two or more sets of transactions (the bundles) with identical bundle hash. Therefore, query transactions by bundle hash, and then group the transactions based on the links between them into the individual bundles (trunk transaction hash of Transaction "x of y" in bundle points to "x+1 of y" in same ...


4

Call findTransactions and pass the hash of the "certain" transaction in the approvees parameter: curl http://localhost:14265 \ -X POST \ -H 'Content-Type: application/json' \ -H 'X-IOTA-API-Version: 1' \ -d '{"command": "findTransactions", "approvees": ["YOUR9HASH9HERE9..."]}' All IOTA libraries (Java, JS, Go, etc.) provide a convenience method ...


4

Zero value transactions don't have a sender address. If you wan't to get them for value transactions you can get them through the input of the bundle which had that transaction.


3

Yes, this is all correct. Don't forget to storeTrnsactions before you broadcast them, or your own node may not have them later for reference.


3

The Tag field is short and can be used to search transactions (so you can search the tangle for transactions with tag "GUS9GORMAN", but not for transactions with message "GUS9GORMAN"). The Message field is longer; but for transactions that spend iota (which is internally represented by a negative Value), the message needs to contain the signature so that the ...


3

When you limit the allowed API calls with remote-limit-api option, this will only be valid when the caller is remote (i. e. not on the loopback interface). So if you run scripts on your own host, they can do everything. In case you need to run "limited" commands from another host, you'd probably have to put some kind of reverse proxy (e. g. Apache httpd) in ...


3

Unlike other systems like Bitcoin, IOTA transactions do not distinguish between source and destination addresses. Every transaction in a bundle has exactly one address. If the transaction value is negative, it is considered a spending transaction and the address is considered a source address (and it will need a signature of the bundle hash). If the ...


3

You don't need to generate million of addresses at least if your seed was use properly. Normally, a wallet should use addresses one after the other by just incrementing by one the index of the previous address. It means that a transaction from address at index n exists if and only if a transaction at address n-1 exists. So, what you should do is searching ...


3

Here is the list of all API calls (except nodeInfo and neighbors related calls), with a brief description of what it does. Hope it helps. (don't hesitate to edit, or leave a comment is something is wrong) storeMessage Only for testnet attachToTangle Run the pow. Safe to run on an non sync node. It make sense to dispatch those calls to the machine with ...


2

Probably depends on what library is used to access your node. The Java library (as well as the Android wallet) uses three parameters for protocol, hostname and port, and therefore would require some redesign to support nodes who don't provide the API at /. The JS library seems to take the full URL, so probably it should work to access such nodes (if the ...


2

This is definitely just an issue with the IOTA Wallet. You can create an issue on GitHub. It's probably very easy to add functionality for this and just nobody needed it until now. I assume it just wasn't considered when writing the check regex and you would work fine if you would change it. I found it here in the GUI Wallet code. Click on the link then ...


2

The problem is related to the default limits encountered. Most users might be presented with a disconnected message after attempting to login. To understand why, let's review some of the code. Here is a line statement indicating a generic message of failure. private final static String overMaxErrorMessage = "Could not complete request"; As you see the ...


2

IRI API currently uses HTTP Basic Authentication which transports username and password in an unencrypted form. I believe the documentation is implicitly suggesting that you shouldn't use your regular user account password but rather some arbitrary large random string which can be easily generated by hashing some text or your regular password (which I would ...


2

Attaching such old (Curl) addresses might work, but it is by design that it does not most of the time, because usually this is not what you want to do (if you do not want to lose your funds). Read below for more details. Keep in mind: NEVER send any funds to old Curl addresses (generated by tools before the Curl to Kerl update). The iota node has some ...


2

Starting from the bundle hash, call the findTransactions API to get the transaction hashes of all transactions in your bundle. Pass the hashes to getTrytes to retrieve the transactions as tryte-encoded strings. You may want to sort the transactions in the original order (i. e. so that they are chained by trunk transaction hash) to avoid surprises when ...


2

Attaching an address is just sending a 0 value tx to this address. You can use the sendTransfer method of the JavaScript library. It handles the tip-selection (branch- and trunkTransaction) and conversion to trytes for you. var transfers = [{ 'address': addressToAttach, 'value': 0, }] var minWeightMagnitude = 14 // as in the light-wallet var ...


2

The following Python code can be used to attach an address to the tangle import time from iota import Iota from iota import Address from iota import ProposedTransaction ''' both work, with and without checksum ''' address = 'KO9CVYUHZSZGHCXSRXDHBTT9U9WUJROIBSRNYKUBXOWONSGKIEHBOXBPKVG9FCHFCJ9QZQTRBYTESRQLCEGNFPFEVD' address = '...


2

The problem is caused by the fact that a transaction has two "tag" fields. The traditional/obsolete one (called either "tag" or "obsoleteTag"), and a "new tag" which is not part of the signature. Thetangle.org shows the new tag, while the search functions search for the old one. So whenever the tags of a transaction differ, you won't be able to find it via ...


Only top voted, non community-wiki answers of a minimum length are eligible