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?
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
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
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.
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
getTransactionsToApprove uses Milestones as the depth marker, this function cannot be used.
The answer to this question must not depend on Milestones.