9

A milestone and a snapshot are two separate things. Currently, the network has the coordinator set up to ensure that malicious attacks cannot occur. The specifics of what a milestone is are detailed in this answer: What does the IOTA coordinator actually do? A snapshot is a separate technical feature of IOTA that essentially captures a snasphot of all ...


8

The two numbers are the the latest solid subtangle milestone index The "latest solidsubtangle milstone" is used for sending transactions. For a milestone to become solid your local node (or whatever node your lightwallet is connected to) must basically approve the subtangle of coordinator-approved transactions, and have a consistent view of all referenced ...


5

First, the Coordinator is not forced to resort to key reuse. It could also issue transactions from a new Coordinator hash (and anybody who did not update their iri would see no new milestones any more) That being said, a new milestone is issued once per minute, meaning 1440 milestones per day. And during manual snapshots, the milestone number is rounded to ...


5

The Latest Milestone is the latest milestone you have received from the coordinator. The Latest Solid Milestone, as the documentation says, is the latest milestone where your node has all transactions that are directly or indirectly referenced by it (called subtangle here). If some transactions are missing, the milestone is not solid and your node is not ...


4

Purchase Iotas The "source" of all Iotas is the genesis transaction. There will never be more than this amount of Iotas. When you want to purchase Iotas, you buy them from another IOTA user which will be an exchange in most cases. Markov Chain Monte Carlo The default tip selection algortihm is the Markov Chain Monte Carlo Algorithm. It is used to select ...


4

Yep, you are out of sync You could ask in the #nodesharing channel for a few new neighbours. Perhaps you chose some dead ones. You can detect dead neighbours if they are also behind Additionally, try to restart your node. There are some weird syncing issues with the current iri version, this sometimes seems to fix it


3

It is a known bug in versions prior to 1.4.1.6. It's definitely not correct. This issue is fixed in version 1.4.1.6. As stated in the release notes: https://github.com/iotaledger/iri/releases/tag/v1.4.1.6 fixes stale tcp connections fixes solid milestone getting stuck (regression) enables checking balance based on tips enables API Rate limit for ...


3

Via curl if the neighbor exposes the getNodeInfo API: curl -H 'X-IOTA-API-VERSION: 1.4' \ -d '{"command":"getNodeInfo"}' \ http://<hostname>:14265


2

243000 was the milestone of the latest snapshot. Therefore, if your node has not loaded or seen any transactions, latest milestone will show as 243000. The milestone hash of the snapshot will show as 999999⋯9 as the snapshot milestone does not correspond to a transaction, and the trytes conversion of all zeroes is all nines. (This value will change if there ...


2

When running with Xmx3G you are limiting the memory to 3Gb. In Java, when memory consumption raises up to the limit : a process called the GC (Garbage collector) start to try to free memory (by releasing old objects not used anymore). The problem with the GC is that (under some circumstances) it is a "stop the world" process. i.e. your app cannot do ...


2

There is a link between milestone frequency and average confirmation time. But the time interval between milestone is not a lower bound for confirmation time. If you submit a tx, and if you are lucky this tx can be immediately selected as tip to approve by a new milestone and you will have a very short confirmation time. Establishing the exact ...


2

Broadcast a tx/Request a missing tx When IRI broadcast a transaction to neighbors, it can append to the transaction data the hash of a transaction to request (i.e. the hash of a transaction unknown by the broadcaster), or the NULL_HASH if the broadcaster don't have any transaction to request. Basically, when IRI broadcast a tx, the packet will look like ...


2

Tip selection and PoW are completely different things, which do not necessarily have to happen at the same point. Tip selection performs MCMC on the tangle to find two transactions (or rather their hashes) your new transaction (or transaction bundle) should approve. This step is not deliberately computationally more expensive than it has to be, so it can be ...


2

Last Milestone index is the highest index of a milestone transaction you have seen (because it was pushed to you by another node). Last Solid Subtangle Milestone index is the highest index of a milestone transaction where you have received all referenced transactions as well (so when you start walking from them towards the beginning of the tangle, there are ...


1

The time to propagate a transaction through gossip is orders of magnitude smaller that the time required to accumulate a significant cumulative weight (so that it start to be relevant to look at the confirmation confidence). Therefore the information-delta (i.e. the difference between the Tangle from node A and Tangle from B) is negligible when computing ...


1

So far, the solution isn't found/decided yet. In other words there is no implementation yet. That being said, every transaction have a "height" property defined as the length of the shortest path to genesis. A measurement of the sync state of a node can be based on the (average) height of it's (solid) tips. The exact formula still to be found, but ...


1

Initial motivation for checkpoints in bitcoin is to prevent 51% attacks as explained by satoshi (July 17, 2010): The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday. (if you have this update) I'll probably put a checkpoint in ...


1

Milestones are bundles that reference a certain part of the Tangle. All transactions within this part are considered confirmed by those who trust the COO. In my eyes, milestones behave very much like a transactions with infinite weight. Other nodes can only issue transactions with a weight of 1 (Maybe more in the future). The problem with that is, that ...


1

I think while we have coordinator fastest confirmation time is limited by frequency how milestones are issued. By definition. Because to be confirmed = to be referenced by milestone. Average confirmation time must be strongly correlated with the milestone frequency too


1

Nobody will say internet is centralized, but there is something call IANA(Internet Assigned Numbers Authority) for internet. The same thing can be done to tangle. And IF can be IANA of tangle, and tangle will be still decentralized. i.e. instead of COO generating milestone, IF can have a list millstones that fullnotes can use. Now the issue is how to add ...


1

IMO, your proposal don't address the key question : Wait until it is considered confirmed by the network. This leads to the tricky questions : Waiting for how long ? Most important : how the IRI knows that it is considered confirmed by the network ? The IRI have no knowledge of the network, it only knows it's neighbors. ( Using Qubic may help, but ...


1

Since this question is still getting upvotes, here is an answer (more of an approximation) by myself, having kind of a solid knowledge about it as of now, running a node and actively developing stuff for the iri. When I fire a lot of requests to my node, it here and there crashes. It's not denial of service or anything, but maybe 2 requests per second. When ...


1

From my understanding, today milestones impact the IRI at (at least) 3 (more or less critical) points : Milestones indicate fully confirmed transactions. Without milestone the validity of a transaction must be evaluated by the proportion of tips approving it. (but this point is just impacting clients interested by the confirmation state of a transaction, ...


1

Two possibilities (but there may be others): your neighbors are dead or not synchronized. In this case your node cannot synchronize with the Tangle. solution: find other neighbor. You may consider using Nelson to improve your connectivity to the network (check channel #nelson on the slack) you run into a behavior that is suspected to be a bug in IRI https:/...


1

You have 2 Nodes, both are not(!) synchronous: curl http://173.212.242.212:14265 -X POST -H 'Content-Type: application/json' -H 'X-IOTA-API-Version: 1.4' -d '{"command": "getNodeInfo"}' | jq curl http://144.217.243.6:14265 -X POST -H 'Content-Type: application/json' -H 'X-IOTA-API-Version: 1.4' -d '{"command": "getNodeInfo"}' | jq Have a look at your 1. ...


1

This is the basic answer for IRI synchronization issues: Make sure that your neighbor nodes are active and fully synchronized. If that's the case proceed with step two. Restart the node once with the parameter --revalidate. It will re validate your database without removing transactions and hopefully fix the issue.


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