12

Two reasons: When your transaction is seen by the network, it could be already deep in the tangle (several milestones old) which makes it unlikely to get picked for confirmation. This is often caused by PoW being done by a low-end device (or non-working GPU acceleration), so when PoW takes 10 minutes already, there have already been 10 milestones before the ...


11

Reattach: The process of reattaching a transaction is simply doing the proof of work and tip selection process to reattach the transaction to a different part of the Tangle. Reattach once every 30 minutes that a transaction remains pending, and then if still pending after 5 reattachments be sure to contact the sender to verify that the transaction ...


7

Transactions that are pending at a snapshot are forgotten, and the balance stays where it is. As the current wallet is stateless, the wallet does not know about those transactions any more either. So, while in theory (if you have still stored the transaction trytes somewhere) you can reattach the transaction after the snapshot, the current wallet does not ...


7

No. The data signed in a transaction don't include parent and branch transaction hash. So when you reattach a transaction the signature is unchanged. It means that the portion of the private key disclosed when you reattach is exactly the same as the portion disclosed during first "attach to tangle". This design choice (to not include parent and branch ...


7

Note that the code posted here is not a user-friendly solution, but somebody could easily wrap it up on a webpage with a nice UI. Just give the code the tail hash (i.e. transaction hash of the transaction with index 0) of the bundle you want to get confirmed: var node = 'http://service.iotasupport.com:14265'; var tailHash = '...


7

The best way, to get your transaction through is to run your own full node on a seperate Server. This makes transactions faster and gives you more control. However, if you don't run your own full node, I recommend you to check https://iota.dance/nodes and choose the first/highest node (which is the public node providing the best chances, because of the lowes ...


6

A transaction is only an envelope for the signed bundle that details the exact transaction of funds between addresses. The transaction gets attached to the Tangle by doing the Proof of Work and validating two tips. Once it is linked to the Tangle that way, it cannot move any more. It therefore has become part of the permanent history of the Tangle. It can ...


5

When you re-attach a transaction you don't take the old one out. You basically issue a copy of the same transaction. So if the yellow transaction is already approved/referenced by the black ones, then when you re-issue the yellow transaction nothing will really happen. You just have two yellow transactions: one that's already been approved and one that's ...


5

The current transaction structure is not the final variant. Later extraDataDigest field will be added, that field will be a part of the bundle essence (signed part). Setting the field value to the hash of signatureMessageFragment would allow to detect cases of changed content. You could use obsoleteTag now (store the hash fragment into the last 27-N trytes, ...


4

The transaction might get attached to the part of the tree that will never be validated for example because there were too many tips in the Tangle tree waiting for validation so that it gets “forgotten” by the tip selection algorithm. The tip selection algorithm is biased towards the transactions from the top of the tree - this is controlled by the Depth ...


4

When you select a transction in your wallet, the wallet will ask your connected node if it considers the transaction bundle still consistent. A transaction bundle can become inconsistent if one of its two approving transactions (which were chosen at the time when you initially attached your transaction) are double-spends (or reattachments) of already ...


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

Since B has the transaction hash, he can find the transaction inside of the Tangle (full node or tangle explorer) He would take the transaction, do the tip selection + the Proof of work again and then broadcast the transaction. (=reattaching) B does not need the seed (or private keys) of A to sign the transaction because it has already been signed by A. ...


4

The re-attached transaction will be stored in local tangle of the full node and broadcasted to neighbors. The full node won't keep track of the reattachment. The re-attached transaction is seen as a new one. (As it is a new transaction, there is more chance that it get picked by new transactions for validation.) If you reattach to multiple nodes : every re-...


3

A transaction has not failed even if it does not confirm. You should never make a new transaction, but replay the first one until it confirms. The only time a transaction will not confirm, is if the signature is invalid (not possible to do with wallet), or if the address (or one of them) you spend from have a lower balance than the transaction requires. ...


3

When your transaction is younger than 30 minutes, there is a significant chance that other transactions will use it as a tip for their transaction (and therefore confirm it). So, first, if you reattach early, you are wasting your PoW resources. To make matters worse, when you reattach really early (maybe even multiple times), there are two transactions on ...


3

If they are all identical transactions, then it doesn't matter which one you reattach. Make sure to wait at LEAST one hour before reattaching.


3

According to How does reattaching a transaction increase the chance for confirmation? two main reasons can be identified: Your computer takes a lot of time for the POW, which results in an attach position not in front of the tangle. Thus other tx will not pickup your tx. (see also Does the tip selection depend on how quickly the proof of work is done? and ...


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

"Inconsistent subtangle" - transaction you want to promote is referencing an invalid transaction (or one that was confirmed in other reattachment). That means you have to use reattach. "Cannot find tail" - not sure, maybe this node doesn't see this transaction or it isn't a tail (transaction with index 0 in the bundle) "Inconsistent tips pair selected" - ...


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 ...


1

You must keep promoting the pending transaction. You should also select a properly sync fullnode. (see http://iota.dance/nodes/). As you mention yourself, sending to a different address is a double spend, it will reveal another portion of your key... and there is absolutely no guarantee that this new transaction will confirm faster.


1

There is no fixed number of reattachings to have it processed. The recomendation is to keep reattaching every 30 minutes to 1 hour after the transaction is sent, this way the tip algorithm is more likely to select this transaction because it will be "fresh", since the reattachment proccess will re-do PoW.


1

Although @Laurence's answer is correct, I would like to point out a website developed by a community member which does the reattachment/promoting in a user-friendly manner: http://www.reattach.online


1

The process of reattaching a transaction is simply doing the proof of work and tip selection process to reattach the transaction to a different part of the Tangle and thereby creating a new transaction. If your transaction didn't get confirmed for a long time, it is very unlikely that it will get confirmed in the future because the tip selection algorithm ...


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