30

In every DLT, a transaction have a probability to be valid. (In Bitcoin, a transaction is valid as long as it is written in the longest chain, so the probability for your transaction to be invalid is the probability that a longer chain exists somewhere without your transaction). In a blockchain like Bitcoin: 2 conflicting transactions cannot be in the ...


8

Every double-spending is an address reuse but not every address-reuse is a double-spending. Let's say you have an address with a balance of 100i Double Spend You send 100i from the address to another address and 100i from the address to yet another address. or You send 40i to from the address to another address and 70i from the address to yet another ...


7

There is no green light. If you sign a transaction a second time, even if it is pending, you reveal your private key and the address is insecure. All remaining funds on that address might get stolen. The light wallet on your computer prevents you from doing that. The Android wallet doesn't. The only way to get out of this situation is to promote (as often ...


7

You can't. Just consider the complete flash channel as two transactions. Opening channel. Closing channel. Neither transaction is allowed to conflict with the network. On opening a channel both parties deposit IOTAs to a multi-signatory address. On closing you get the IOTAs back with a different distribution. Basically like Poker. You buy in and get chips. ...


7

According to this answer to another question, I can just reattach my transaction again without signing it, so the answer is no. I cannot be forced to reuse my address for spending this way.


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

In short: double spending is incredibly unlikely in IOTA. In IOTA, majority hashpower is insufficient for a double-spend attack. IOTA is unlike proof-of-work based blockchains in this regard. You also need enough neighbors to get your transactions confirmed. IOTA calls this concept omnipresence. IOTA nodes use mutual tethering rather than automatic peer ...


5

The IOTA Tangle more network-bound than hash-power-bound because in order to perform an attack, you need to meet three conditions: X [any number] percentage of network hash rate (depending on Y 34% may not be enough) Omnipresence You have to know how a big section of the network topology (know which nodes are neighbours of which nodes) Y percentage of ...


5

1. If you consider flash channels : double-spend is not possible because when creating a flash channel all participants MUST transfer the exact same amount of iota to a multi-sig wallet (signed by all participants). The amount of iota "in" the flash channel cannot be double-spend because transaction initiating the flash channel (and so the multi-sig address) ...


5

Reattachments won't help and the transfer can't be deleted. Sending 1i to A will help because after that the pending transfer won't be a doublespending.


4

Due to the dag structure of the Tangle a complete ordering of transactions is impossible. Therefore, the protocol don't relies on transaction time ordering to determine which of two conflicting transactions is the legitimate one. By design, the protocol will decide that the transaction with most weight will be the accepted one.(here is a brief explanation of ...


4

A transaction will likely remain pending if it doesn't confirm within ~ 1 hour. That is just a rough estimation and may change in the future. Anyone can reattach it, so it will have another chance to get confirmed. Never resend (reusing the address which is bad), always reattach until confirmed. The current GUI wallet 2.5.4 throws a warning if you try to ...


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


2

In this example, transactions X, K, L, Q, R, a, b, e, f, j must be re-attached to other transactions to get a new opportunity to be confirmed (promoting will not help because promotion don't change trunk and branch transaction). Note that X is now conflicting with all tips: so re-attachment will also fail forever for X. So, yes regarding confirmation speed:...


2

Generally speaking, the double-spend which is directly and indirectly referenced by more transactions (i.e. has a larger cumulative weight) will most probably get confirmed. This is because more nodes will have accepted that double-spend and will thus impose their consensus on the rest of the network (eventually) by simply ignoring/orphaning the other double-...


2

It traverses through ancestors until it reaches a recent memory-persisted snapshot of balances, creates a new potential state, and then checks to see whether any addresses resolve to a negative value.


2

When can a transaction be considered irreversable ? (without COO) Strictly speaking: never. In any really decentralized DLT any transaction have a probability to be valid... and this probability is always < 1 (except in the infinite future). Is this true, that a double spend attack can happen at any time in the future? In theory : yes (...because ...


2

If I'm not remembering wrong, when a discrepancy is detected the node runs again the MCMC algorithm and chooses two other tips. The inconsistent tips will remain on the tangle. The growth of the tangle will (hopefully) confirm only one of the two tips, the other will be on an orphaned branch and will never be confirmed.


2

It's Taylor series of the exp function to the 1st order: https://en.wikipedia.org/wiki/Taylor_series#Exponential_function exp(-x) = 1 + (-x)^1/1! + (-x)^2/2! + .... Since white paper assumes x to be small, you forget about higher order terms and only take 1st order. What remains is an approximation for exp(-x), since x^2 is really tiny, once x is already ...


2

Iota requires PoW on individual transactions. An attacker could double spend but they would need more hashing power than the rest of the honest users. The hashing power of the current tangle is fairly low hence the need for the protection of the Coo. Unlike other PoW systems the hashing is not used in a competitive manner by miners but by the users ...


2

All that we know is that Tf and Tg come after Ta,Tb, Tc ...and the transactions (directly or indirectly) referenced by Ta, Tb, Tc. That is all the Tangle "knows" about the temporal order of these transactions. It makes no statement about the temporal order of the independent (neither directly or indirectly referencing each other) transactions Tf and Tg. ...


1

In the current moment, users are protected against this scenario by the same methods that protect them from sending to a wallet where the first 100 addresses are already spent before the last snapshot (as Trinity will not check that many addresses when you first add a seed and do not perform "Snapshot Recovery"). And it is the exact same way that the ...


1

Double spends are resolved once your transaction or bunch of transactions is attached to the main tangle. 1) COO in mainnet: The COO emits milestones every minute. Once your transaction is indirectly approved by a milestone which will happen quickly, your transaction is confirmed 2) no COO in mainnet: The weight of your transaction grows over time. In the ...


1

There are no recommendations out yet, because we still need the coo to prevent double spends. In the whitepaper it stats that the confirmation status of a transaction is given by the percentage of tips that directly or indirectly reference this transaction (http://iotatoken.com/IOTA_Whitepaper.pdf Page 3). If we select 100 random tips and 70% of them ...


1

Yes, the coordinator does protect us against these kind of attacks. Let's call the honest transaction A and the double spend B. If neither A or B are confirmed, the coordinator can only confirm one of them. If it would confirm both, his milestone would be rejected, just as any other transaction trying to archive that. If A already got confirmed by the coo ...


1

Transactions are conflicting if they try to spend the same money from the same address (and the address does not include enough money to satisfy both at the same time - but this should not happen anyway, as compliant clients will move the remaining balance to a change address - but can of course happen if an adversary tries this). Either this can be because ...


1

Ok so first of all generating a new address, doesn't move any of your funds to the new address. So each address only contains the amount of iota which had been deposited before. This is the reason why it makes sense to generate a new address for each deposit, so you have the ability to send multiple, legitimate transactions at a time. Yes, you are able to ...


1

Yes, it is ok to have more pending transaction as long as the used funds for those transactions do not overlap. Usually, the client would prevent you from broadcasting such transactions.


1

The action that will compromise your security is sending a transaction from the same address twice. That is what address reuse is: sending a transaction from the same address twice. You CAN do this by double spending, which is trying to send the same IOTA multiple times while it is still pending. But you can also re-use your address by sending, receiving ...


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