19

Trinary Note In the "normal" world we have bytes & bits, where 1 byte is 8 bits giving us 2^8 = 256 possible data values for 1 byte. In the trinary world we have trytes & trits, where 1 tryte is 3 trits giving us 3^3 = 27 possible data values for 1 tryte. This is what IOTA uses to stores its transaction data. Transaction Composition One IOTA ...


13

When you perform PoW, you specify "Min Weight Magnitude" (not Weight Magnitude). That means that the PoW will modify your transaction hash until it ends (in ternary) with at least 14 zeroes. As the hashing is random, it can happen that your hash ends with more zeroes (without you doing extra work), thus resulting in a transaction with Weight Magnitude of 16 ...


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

There is no a perfect solution, the both variants (fixed-size and variable-size transactions) have their own pros and cons. These are some pros of fixed-size transactions which make them the best choice for the IoT: Smaller codebase for transaction processing (if implemented in software) Fewer logic gates for transaction processing (if implemented in ...


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


10

The issue with the spammer was that it was spamming a single (and commonly used) node and wasn't intelligent enough to distribute transactions among nodes, so it was just overwhelming that one node. This is also the issue some people are having with transactions -- using overloaded nodes. On top of this, the coordinator limits throughput, so there is an "...


9

It's important to understand that IOTA use UTXO scheme (like bitcoin and probably many other cryptocurrencies). UTXO means Unspent Transaction Output. To understand from where the UTXO concept comes from I will first describe it "in theory" and in the end I describe how it is really implemented in IOTA. How it works ? Assume that Alice owns an address ...


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


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


8

While one single transaction is pending, there is no threat to your balance (apart from the obvious, that if the transaction confirms later, your balance will decrease by the transaction amount). However, if you have more than one transaction spending from the same address pending (where the transactions have different bundle hashes, i. e. the second one is ...


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


8

As of the current implementation state, every node will have to receive every confirmed transaction eventually (so that the solid subtangle milestone can increase and the node can calculate all balances if asked for them). There are plans for "sharding" so that nodes only care about certain transactions (e. g. based on first letter of address), but there is ...


8

Then you basically lost the money. Typos like I<>1 or O<>0 are unlikely to happen, because the address only has [A-Z9] characters. I'm not sure if the target addresses have a checksum on them, I've been using 81 tryte addresses as a target in the API, never a wallet (not using it), and checksummed addresses are 90 trytes long. Anyway, one typo = lost ...


8

It's safe to keep your seed. Even if you double-spend or reuse your address, your seed doesn't get exposed, only the private key of one address of your seed is partially revealed. You can generate an infinite amount of addresses with one seed. What's the difference between a private key and a seed? What is the difference between "double-spending&...


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


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

For most purposes (e.g. determining confirmation status or propagation of transactions) it does not matter which transaction is where. Inside a bundle, however, it is at some places clearly mandated which transaction has to be the trunk transaction and the branch transaction (e.g. when signatures are split between multiple transactions, they have to be ...


7

IOTA's proof-of-work is formed by successively hashing the data in a transaction, including a nonce, and increasing the nonce until producing a hash which ends with a particular number of zeroes. This is hard to calculate, but easy to verify given the nonce. Here you can see the weightMagnitude of a transaction is simply a calculation of the number of ...


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

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

Addresses are derived deterministically from the seed. In order to receive iotas your address doesn't have to be in "confirmed" state. In fact, You could even decide to not attach your receiving address at all, and you would still be able to receive iotas to that address, and spend from it. It's encouraged to reattach receiving addresses in the current ...


7

Technically speaking, a zero value transaction (bundle) neither needs to have nor can have a sender address. (Sending transactions in a bundle have value < 0 and receiving transactions have value ≥ 0). That being said, you can send zero value transactions to any address. No funds will be moved and the address will not get added to the next snapshot ...


6

A full node has a local database of current IOTA balances (which gets initialized from the latest Snapshot and then updated by confirmed transactions). When the full node performs its validation of a transaction bundle, it will verify that the balances of the spending transactions do not exceed the amounts stored in its database. This is done sequentially so ...


6

What you are referring to as 1 Mi is 1 MIOTA, which stands for 1 million IOTA. 1 MIOTA is the standard traded amount of IOTA on exchanges, but the you can divide it into 1 million single IOTAs which is the smallest amount to transfer. By holding 1 MIOTA you have the capability of sending 1 million 1 IOTA transactions. See the following image for the full ...


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


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


6

IOTA transactions are less than 4kB, they are currently 2673 trytes which is equivalent to about 1600 bytes or 1.6kB. By far the largest field in the transaction is the 2187 tryte signature/message field. Signatures for addresses of security level 2 are 4374 trytes long so actually have to be split up across two transactions; this is part of the design. ...


6

Short answer: it is not. Long answer: Signatures are not supposed to protect anything else than the iota values and (obsolete)tag fields. Therefore, as long as your transaction is not confirmed, anybody could replay/reattach it with a different content in the message field of the receiving transaction and the luckiest transaction would win. Therefore, you ...


6

Let me complement the whitepaper based answer with a bit more explicit technical arguments. Confirming just one transaction would lead just to a linked list of transactions - in other words, a blockchain. Confirming more than two transactions would (1) increase the work required to select valid tips and (2) increase the probability than an invalid tip is ...


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


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