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


7

(I already know that this answer will disappoint you - as it did disappoint me when I found it out) The current algorithms around the tangle depend on a central node run by the Foundation, known as the Coordinator (or Coo). This node will publish a signed milestone transaction approximately every minute. The exact rules which tips will be selected for this ...


4

In IOTA, every new (unconfirmed) transaction is known as a tip. These tips should each reference two previous transactions. Choosing which tips to extend is decided by a Random Walk Monte Carlo algorithm which uses random tip selection to ensure that only good transaction branches grow. How consensus is reached if random numbers are being used is explained ...


4

Currently the tip selection is only performed on full nodes, and cannot be performed on light nodes. This is not only true for the tip selection, but also for broadcasting transactions and for searching the balance or inclusion (confirmation) states. You run a full node because either you are an individual who wants to help the network or have influence on ...


4

They will get removed (together with the confirmed transactions) at the next snapshot. Permanodes will keep them forever (if they have ever seen them; it is not guaranteed for unconfirmed transactions that every node will eventually see them)


3

You want it confirmed because transactions which do not become part of consensus (heavy part of tangle) are pruned/discarded by full nodes (because they aren't relevant and are taking up memory) and fall into oblivion. Using the Tangle for data transactions is to have an immutable and trustless way of making a statement about the state of some data. For ...


3

Selecting 2 random tips will impact negatively the probability for your transaction to be confirmed by others. There are multiple reasons for that: There is a chance that 2 randomly selected tips are inconsistent. (i.e. your transaction would approve a double spend and will never be selected by any other transactions selected by the recommended GTTA ...


3

First of all, the property of a transaction being a tip is volatile and can change before the walk even finishes. So even if the function was guaranteed to find a tip, by the time it returned it could already be a non-tip (as somebody else approved it). Also keep in mind that the property of a transaction being a tip is not the same in the whole network, a ...


3

This error message was removed in April 2017. Thats the reason why you can't find it. You can fix the issue by deleting your local database. Take a look here. The code which contains this error message is following: final Iterator<Map.Entry<Hash, Long>> stateIterator = state.entrySet().iterator(); while (stateIterator.hasNext()) { ...


3

Successfull merging of a subtangle and the main tangle: How to start a new offline subtangle? The case, that you have to reattach your whole subtangle occurs when you start your subtangle at a transaction that is not very likely to be confirmed and conficting with the main tangle. In this example, the two transactions marked with Xs are conflicting and the ...


3

When you have a large offline subtangle (which somebody already did the POW for); it is already attached to some (very old) transaction, which has hopefully confirmed until now (when starting an offline subtangle I'd start at a "confirmed" transaction anyway - at least as long as there is the coordinator, you can just use a milestone). When you bring the ...


3

The protocol does not enforce a particular tip selection algorithm, so every transaction-issuing network participant is free to choose whatever method they want. The IOTA reference implementation (IRI) has chosen MCMC. As demonstrated in Equilibria in the Tangle from https://arxiv.org/abs/1712.05385 all network participants should (in theory) converge to the ...


3

Strictly speaking : branch and trunk transaction can be the same. Let's think about transaction validating the genesis: there was only only one transaction on the tangle... so impossible to pick 2 distinct tips. (same reflection is also valid for a tangle with very low load: in this situation, there is almost always no more than one single tip on the tangle.....


3

Not all nodes see the same state of the tangle at the same time. So it can be expected that two nodes pick the same tip (which might actually even not be a tip anymore) at the same time and issue their transactions building on this node concurrently. It is not a problem if some transactions are directly confirmed by two others. However, on average a new ...


2

Tips in the context of iota (if they are not meaning small payments, as in tipbot) refer to transactions that have not been confirmed by other transactions. When you make a new transaction, you (or rather the node you are connected to) will have to choose two tip transactions that your transactions should approve. Instead of just randomly selecting two tips ...


2

It is correct that tip selection generally favours newer transactions. So it is of benefit to finish your PoW quicker. But unless your computer takes a couple minutes, this should not have a huge impact in practice.


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

The highlighted points of the tangle whitepaper are that first, you cannot enforce a selection strategy, and second, if you assume others are following monte carlo, then that is your best strategy to follow in order to be selected by others.


2

Entire subtangle will be treated as invalid and won't be confirmed. That means you have to reattach all of the transactions.


2

I didn't check the code of IRI 1.5.2 in details, but as far as I understand, it seems that the changes in this version are really going in the same direction as the strategy of local modifiers in the tangle exposed in this paper . The idea of "Local Modifiers in the Tangle" is to penalize lazy tips based mainly on the timestamp of reception of the ...


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


1

There is no problem with that and it can't be completely avoided simply because of network latency. One tip can be selected in good faith by 2 different nodes at the same time. Note that lazy nodes may decide to select many time the same transaction to attach new ones. This is unfair behavior and decrease the overall tps. You can see this kind of structure ...


1

I would question your first sentence. If you are not interested in getting your transaction confirmed, why do you want the transaction on the tangle anyway? One of the use cases of putting data on the tangle is to later prove that the transaction has existed before (and give an approximate time it was inserted). For example to have "unforgeable" car ...


1

As I'm new to Iota development I can not tell, if this is really the correct way to do it but I found the following works for me and the result looks correct and like what I expected it to look like: After requesting all transactionObjects from the confirmed Tips (like I discribed in my question) I go ahead and get the bundle for each transaction: self....


1

The IRI (Iota Reference Implementation) select the transactions to approve such that "selected transactions-to-approve are almost always tips". A tip is a transaction that isn't approved yet. This process is also known as the "tip selection algorithm" (or the "random walk"). It is expected that all "honest" nodes use this official tip selection algorithm to ...


1

To be honest, I am not sure whether you can be that careless about whether your transactions confirm. There is no guarantee that unconfirmed transactions will (eventually) reach every node of the network. Also permanodes will probably not retain unconfirmed transactions forever (in case they reached the node originally). Also, it is hard to "timestamp" ...


1

The IRI implements a random tip selection algorithm but you are free to modify it to select again and again the same transaction. It's what you do when you promote a transaction. Inundating the network should be very costly because you have to do the pow for every transaction.


1

Tip selection for approval does not look at the amounts at all, so it should not matter whether you do value transactions or zero-value transactions. however, I'd check that your node is synced (otherwise your spam is only approving outdated transactions and that makes it unlikely for anyone to approve your spam), and that the transactions you are spamming ...


1

Transaction to approve are indeed called "tips". There is a tip selection algorithm doing the tip selection, and normally this algorithm should select transaction that are : recent probably not approved yet Today, because with a coordinator, we can make a precise distinction between "confirmed" and "approved" transaction : A transaction is "confirmed" ...


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