Closed martinmatak closed 6 years ago
Ring size column added.
What does it mean?
I added the num_of_mixins, but under the name of ring_size, which is preferred name for this in monero.
Thank you for that @moneroexamples !
Now, a quick question. I would like to know which input is in which ring. Imagine a transaction with 2 inputs, inputA and inputB. And let's say ring size is 3.
Then, in output of this app, I will have something like:
tx_hash | num_of_mixins | candidate
hashVal, 3, candidateX hashVal, 3, candidateY hashVal, 3, candidateZ hashVal, 3, candidateA hashVal, 3, candidateB hashVal, 3, candidateC
Does it necessary mean that first ring size referenced outputs as input in a transaction all belong to the ring of a first input (are candidates as a first input)? Then next ring size referenced outputs as input in that transaction all belong to the ring of a second input (are candidates as a second input)?
i.e. in this example above, candidateX, candidateY and candidateZ are candidates for a first input, and candidateA, candidateB and candidateC are candidates for a second input?
Or it could be the case that order is mixed and not necessary corresponds to the logic above? I guess in that case it's impossible to figure out which inputs belong to the same ring?
In your example, you are missing the input. So if you have this:
tx_hash, input, num_of_mixins, candidate
hashVal, input1 , 3, candidateX
hashVal, input1 , 3, candidateY
hashVal, input1 , 3, candidateZ
hashVal, input2 , 3, candidateA
hashVal, input2 , 3, candidateB
hashVal, input2 , 3, candidateC
Than candidateX, candidateY and candidateZ are ring members of the input1 only. Similarly, candidateA, candidateB and candidateC are ring members of the input2 only.
And input1 or input2 in this case above are defined as different key images?
i.e. in reality, it looks like this:
tx_hash, key_image, ring_size, Referenced_output_pub_key
hashVal, image_1 , 3, candidateX hashVal, image_1 , 3, candidateY hashVal, image_1 , 3, candidateZ hashVal, image_2 , 3, candidateA hashVal, image_2 , 3, candidateB hashVal, image_2 , 3, candidateC
and it means that candidateX, candidateY and candidateZ are ring members of the first input and candidateA, candidateB and candidateC are ring members of the second input?
Is it possible that same key image occurs in more than one ring?
And is the export of transactions always done in this "sorted/grouped by ring" manner or it can be shuffled?
and it means that candidateX, candidateY and candidateZ are ring members of the first input and candidateA, candidateB and candidateC are ring members of the second input?
yes.
Is it possible that same key image occurs in more than one ring?
you mean, public key in key image's ring members? I dont think so. I think all public keys must be different from each other.
And is the export of transactions always done in this "sorted/grouped by ring" manner or it can be shuffled?
The order of the the txs, images, etc in the csv generated is same as they appear in blockchain. I dont sort them in anyway.
Is it possible that same key image occurs in more than one ring?
you mean, public key in key image's ring members? I dont think so. I think all public keys must be different from each other.
I mean -- is it possible that there are two same key images in a whole blockchain which are not in the same transaction? I.e. any key image happens only ring size times in a whole blockchain?
Key images are unique. If you find two same key images in the blockchain, this means double spend.
Thank you for clarifying my doubts! :+1:
Hello there,
I figured out that a transaction can have more than one real input: https://monero.stackexchange.com/questions/7348/more-than-one-real-input-per-transaction
As for now, after export of a transaction I have a list of inputs (i.e. referenced outputs) and the problem is I don't know neither how many inputs are there nor how many mixins per input. However, I would like that for every input in a transaction I have all (1 true and n fake) references (to outputs from some previous transaction) for that input. And that it's written how many mixins are there for that specific transaction.
For instance, if transaction has two inputs and three mixins per input, it would look something like this:
tx_hash | input | num_of_mixins | candidate
hashVal, input1 , 3, candidateX hashVal, input1 , 3, candidateY hashVal, input1 , 3, candidateZ hashVal, input2 , 3, candidateA hashVal, input2 , 3, candidateB hashVal, input2 , 3, candidateC ....
Is it possible to implement something like this please?