In the whitepaper, the confirmation status of a transaction is determined by calculating the percentage of tips that (in)directly reference it.

See http://iotatoken.com/IOTA_Whitepaper.pdf at the bottom of page 3:

The main rule that the nodes use for deciding between two conflicting transactions is the following: a node runs the tip selection algorithm many times, and sees which of the two transactions is more likely to be indirectly approved by the selected tip. For example, if a transaction was selected 97 times during 100 runs of the tip selection algorithm, we say that it is confirmed with 97% confidence.

What IOTA library can be used by a Java programmer that accepts a transaction and calculates the percent of N tips (ex. 100), that (in)directly reference the transaction?

Does the IRI API getInclusionStates do this?

This getInclusionStates function requires a transaction(s) and then checks against a list of tips to see if they are all included.

The main problem with this is that the user must supply the transaction and a set of tips to check.

Where does the user obtain a set of tips known to be newer than the supplied transaction?

Does the IRI API getTips provide a set of tips that the user can use in getInclusionStates?

Not really. Firstly, nodes can be full of tips and solid-tips and the returned result can be 10,000 tips that then need to be selected from.

What about the API getTransactionsToApprove?

This function returns two tips. It can take several seconds per call. Calling it many times to amass 100 unique tips could be very time consuming. It cannot be expected for clients to call this function 50 to 100 times to amass tips required for the confirmation of every single transaction that is required to be confirmed in a speedy manner. A user with a large funds transfer, millions, may want 99.9% confirmation probability. If 99.9% confirmation status is wanted, the GTTA would have to be called upwards of 500 to 1000 times, possibly even more if it returned any non-unique tips.

Furthermore, the API getTransactionsToApprove uses an EntryPointSelector that relies on Milestones. So obviously, as the confirmation status of a transaction is determined by calculating the percentage of tips that (in)directly reference it, this function and other functions that use Milestones cannot be used in the calculation.

The answer requires:

A library function that abstracts away the need for the user to make multiple API calls and then filter the results and randomly select a subset of tips to test against.

Such that function(transaction, Ntips) = percent referenced


For the bounty, an answer is required that uses Java and provides the required function to get the solution. The function must correctly determine the tips to check.

As per Come-from-Beyond's comments here:

PS: It's worth emphasizing that in IOTA we don't care about the order of transactions. For ledger validation we can traverse the transactions in any order. This boosts performance and helps to scale to much higher TPS than a ledger with ordering would allow."

So the tips must simply be provided by the approved Random Walk Monte Carlo algorithm which uses random tip selection. Furthermore, the tips from the Random Walk Monte Carlo must be unique.

However, as the EntryPointSelector in getTransactionsToApprove uses Milestones as the depth marker, this function cannot be used.

The answer to this question must not depend on Milestones.

This question has an open bounty worth +200 reputation from Austin Powers ending in 6 hours.

The question is widely applicable to a large audience. A detailed canonical answer is required to address all the concerns.

  • "The function must correctly determine the tips to check (they must all be newer than the transaction being checked" this requirement is not in line with the white paper. The white paper just state that you must select tips through the usual random walk, nothing more, nothing less. Asking for "newer tips only" will just increase artificially the confirmation ratio. – ben75 Sep 3 at 6:54
  • And the random walk can select a tip that is older than than the transaction being checked? Is that what you are saying - that there is no restricting the random walk to select tips that are more recent than the one being checked? – Austin Powers Sep 3 at 9:02
  • By 'indirectly approved' dose that mean that any forward or backward reference is acceptable? Also, since the 'the tip selection algorithm' currently chooses ones no older than a certain milestone, doesn't that eliminate many older tips? – Austin Powers Sep 3 at 9:17
  • the random walk can select a tip that is older than than the transaction being checked -> Yes. I'm not sure to understand your forward or backward stuff. But a transaction is always approving (directly or indirectly) OLDER transaction. – ben75 Sep 3 at 13:15
  • What is important is that the tips selected to compute the ratio are selected by the same algorithm that the algorithm to select transactions to approve. In other words : the confirmation ratio is the probability that a new transaction indirectly (or even directly) approves the transaction being checked. – ben75 Sep 3 at 13:19

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.