10

The validity of a transaction (let's call it target-tx) can be evaluated with this algorithm: random selection of 100 new transaction for each of them: count 1 if there is a path to target-tx (i.e. if this random transaction indirectly—or directly—validates target-tx) once you have done this evaluation for all 100 transactions, the number you have is a ...


8

Some things to make chances better that transactions confirm quickly: Make sure that your transaction is valid (not a double spend) Try to get your transaction propagated as fast as possible after attaching it to the tangle (i.e. check if you can do PoW with GPU which can be noticably faster than CPU) Broadcast your transaction to a (full) node that is (as ...


6

As long as the Coordinator is in action, you will have to wait for at least one milestone by the Coordinator (which will happen approximately once per minute) for your transaction to confirm. Apart from that, there are no real bounds for confirmation time (although a transaction which stayed unconfirmed for 30 minutes has very little chances of getting ...


5

In the getInclusionStates api call you have two parameters. The first, 'transactions' parameter is an array of transaction hashes that you want to check the inclusion state for, and the second, 'tips' parameter is an array of transaction hashes that you wish to use as a reference to determine if they include the 'transactions'. You can pass a milestone as ...


4

If λ is the average rate at which transactions are issued in the tangle, then the cumulative weight of any single transaction (i.e. the count of transactions that directly & indirectly reference that single transaction) is expected to behave as follows, where up until the Cut the growth is exponential, and linear thereafter with slope λ. One could argue ...


4

The probability after reattaching a transaction shouldn't change, assuming that the node you use is not overloaded and has good neighbours. However, the cumulative probability does increase of course. Please don't spam reattachs through, just wait 30 minutes. With the new wallet update, you can promote your transactions, which is often more efficient than ...


4

This is basic practice on Bitfinex. They collect all the iota centralized and keep track of your iota in a Database. This process may take some time. So be patient. This is not Bitfinex support and if you have questions on Bitfinex use their support please.


4

I usually experience a 1-2 min confirmation time. I made a round transaction (sent to address return to address) in 3 minutes a month ago. Sometimes the network seems to be slower and I understand that this is because of the coordinator, that's the bottleneck right now. It also matters on what node you are (how many transactions are being made there)If you ...


4

this is Poisson distribution. If we are waiting for independent event to occur, time when it will occur is distributed according to Poisson. Optimized tangle or not, it will be Poisson, just parameters might change. It also depends of measurement itself, of course. Below confirmation time distribution in 16 days, 17300+ samples


3

I finally found time to check the iri source code myself, and there were two conditions missing in my question: A transaction whose bundle is still missing some transactions, based on the indexes (they may arrive later) A transaction whose bundle (in total) tries to spend/receive more than the total number of available IOTA And for reference, a list of ...


3

Let us assume every transaction directly references exactly k other transactions (k = 2 in the case of IOTA). Now under uniform random tip selection, every transaction will on average be referenced by k other transactions (due to the stationarity property). The histograms below provide a visual proof of this. I assumed a network delay of h = 1 with 40k ...


3

tl;tr With wallet 2.5.6 and IRI 1.4.1.4 : a transaction is confirmed if and only if it is confirmed by a milestone. To check the confirmation status of a transaction, the light wallet call the getInclusionStates api call. More precisely, the wallet will do that in 2 steps : ask to the full node it's latest solid milestone index (API GetNodeInfo). Let's ...


3

A good step into the right direction is to run your own full node and have it connected to multiple neighbors. Once you have a fully synced up node you can start sending transactions and since you are the only using this node directly the success rate will probably be a lot higher. If you don't want to run a full node and are running into issues with ...


2

It depends on the topology of the network and the tangle. If your node is at the "edge" of the network, your transaction might be slow to propagate through the whole of it, and the majority of other nodes will see younger tips before they see yours. Also consider the following points: If the tangle is very wide (having a large number of tips), and suddenly ...


2

You may also want to check out the section on consensus over here https://blog.iota.org/a-primer-on-iota-with-presentation-e0a6eb2cc621 Your question paraphrased is the same one here: How do long do we go from gray to green (in that chart) ie transaction finality. There really are lots and lots of factors that account for this. Acceptable confirmation ...


2

My question is: If i leave that tx in pending state will it eventually get confirmed after hours/days ? Unless you replayBundle or promoteTransaction, your tx will never get confirmed after a certain time because your transaction will be orphaned in the tangle and no other txs will reference it. The reasons for difference in confirmation time vary. If ...


2

The relationship between confirmation and milestones is still unclear in the current implementation. While the confirmation process still depends on the Coordinator, milestones are not necessary the indicator of valid transactions. (see the attached image *full-credit for @Abmushi) "Milestone" is a bundle that contains two txs and references the previous ...


2

It must be obvious for everyone that attaching a new transaction to a transaction that was already validated is useless for the network. It must be obvious for everyone that a node should do it's best to increase overall TPS (transaction per second). When selecting tips, a node is not sure that the tip is still a tip. Due to network lantency, there is a ...


2

Sometimes, there are attacks going on. These attacks are invalid transactions. Because of their invalid nature they are not confirmed by others. To maintain the Attack, the attacker needs to prefer the confirmation of his/her own transactions. So this is the reason why you see these unhealthy distribution within the tangle.


2

The only solution is to reattach and/or promote it again and again. Yes it is possible that a transaction is never confirmed. It may for instance be ending up in a parasite chain or other non-confirmed sidechain. This is a very often the case and of no concern for the general iota network topology. It's not a bug, it's by design! https://thetangle.org/...


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

The global confirmation rate (ctps) is unfortunately not a good indicator of the healthiness of the tangle. (and I say "unfortunately" because many commentators believe it is). Why global ctps isn't a good indicator ? IOTA is a permissionless and feeless network, so it is easy for anyone to setup a node using an unfair tip-selection algorithm, flooding the ...


2

You cannot get parts of the private key using reattachments. To understand why, let's see how signing works. First of all, there is an unsigned bundle consisting out of several transactins. To sign it, we first need to calculate the bundle hash. Only the address, value, obsolete tag, timestamp, current index and last index are used. Note, nonce, trunk/...


2

Yes all transactions referenced by a milestone (emitted by the coordinator every minute or less) is considered "confirmed" and final That is what the label in tangle explorer means. In the future you will get a certain interval of acceptance (like in Blockchains - accepted after 6 confirmations for example in Bitcoin ). This level should be very very close ...


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

There are two reasons why there might be pending transactions shown in the wallet You reattached a transaction and the reattachment confirmed, making the original transaction pending forever (this does not apply to promotions. Promoted transactions will also confirm the original transaction) You sent some IOTA (or somebody sent it to you) but the ...


1

The number of path to check is indeed arbitrary. The idea is that you must check enough paths so that the estimation of portion of tips approving your transaction is accurate.


1

The coordinator is the final decider whether a transaction is valid or not. Therefore there's no "tool" that confirms transactions with a (near) 100% success rate. What you could do is keeping track of all transactions you've sent (in a database for example) and check every few minutes if they are still pending. If so, promote them (this increases ...


1

For the public node problem, it turned out that attachToTangle is not available on it. However there was a bug and wrong error message was returned. After fix error message is : Request Error: COMMAND attachToTangle is not available on this node As for private node. It seems that EC2 t2.micro is just to weak to handle running a node and doing PoW. And ...


1

You are waiting forever using your node because 18 is a too high value for minWeightMagnitude parameter of sendTransfer call. Try with 14. minWeightMagnitude is related to PoW to accomplish.


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