Difference between revisions of "Talk:Input Selection Algorithm (voting pools)"

From Open Transactions
Jump to navigation Jump to search
(Addendum to bonus question)
 
Line 20: Line 20:
  
 
Could we split 'how we search' and 'how the output should be ordered' into two distinct sections? The second can refer to the first, if it's the same ordering, but then it's explicit.
 
Could we split 'how we search' and 'how the output should be ordered' into two distinct sections? The second can refer to the first, if it's the same ordering, but then it's explicit.
 +
 +
[[User:Justusranvier|Justusranvier]] ([[User talk:Justusranvier|talk]]) 13:39, 1 October 2014 (UTC)
 +
 +
Example: 3 of 5 pool.
 +
inputstart is 1/2/3 (series/branch/index)
 +
 +
; Are there any eligible inputs at 1/2/3?
 +
: If yes, add them to the list. If there are more than one, sort them by txid/output first.
 +
; Are there any eligible inputs at 1/3/3?
 +
: same procedure as above
 +
; Are there any eligible inputs at 1/4/3?
 +
: same
 +
; Are there any eligible inputs at 1/5/3? (branch 5 is the highest branch of a 3-of-5 series, since series numbers start at 0 but that's the change branch).
 +
: After this, it's time to increment the index
 +
; Are there any eligible inputs at 1/0/4?
 +
: Imagine we're proceeding left-to-right across a table. Branches are columns and indexes are rows. When we get to the last column then we move back to the front of the next row.
 +
; ...etc
 +
: ...until we exhaust all the inputs in series 1 (should track the highest-used index for all branches, so you know when this occurs).
 +
; Are there any eligible inputs at 2/0/0?
 +
: and so forth.

Latest revision as of 13:39, 1 October 2014

Larshesel (talk) 09:08, 1 October 2014 (UTC)

I don't understand the part about moving from address to address in the 'Input Ordering' section. I suppose it is meant to specify an ordering?

So the entire ordering would be by branch/index/series/txid/outputidx. For the addresses with only one output the last two parts of the ordering scheme are not necessary.

Larshesel (talk) 09:38, 1 October 2014 (UTC)

Bonus quesion

I would expect that when I am searching for eligible inputs, the (voting pool), series and branch are fixed and I only ever change the index number. Is that the case?

Larshesel (talk) 10:21, 1 October 2014 (UTC)

I think I've started to use this wiki as my rubber duck :-) It at least appears that asking questions here helps me understand.

The bonus question - I somehow had a notion that the series and branch should be fixed. But we want to use any eligible output we can get our hands on. Therefore it makes sense to look for any eligible input in the *hot* series - all branches and all indexes.

But if the moving from address to address part of the 'Input Ordering' sections is supposed to describe how we search the space of eligible inputs, then the 3rd item does not make sense as there is only one series to select addresses from - the hot one, since the other series cannot be used for spending as the private keys are not online yet.

Could we split 'how we search' and 'how the output should be ordered' into two distinct sections? The second can refer to the first, if it's the same ordering, but then it's explicit.

Justusranvier (talk) 13:39, 1 October 2014 (UTC)

Example: 3 of 5 pool. inputstart is 1/2/3 (series/branch/index)

Are there any eligible inputs at 1/2/3?
If yes, add them to the list. If there are more than one, sort them by txid/output first.
Are there any eligible inputs at 1/3/3?
same procedure as above
Are there any eligible inputs at 1/4/3?
same
Are there any eligible inputs at 1/5/3? (branch 5 is the highest branch of a 3-of-5 series, since series numbers start at 0 but that's the change branch).
After this, it's time to increment the index
Are there any eligible inputs at 1/0/4?
Imagine we're proceeding left-to-right across a table. Branches are columns and indexes are rows. When we get to the last column then we move back to the front of the next row.
...etc
...until we exhaust all the inputs in series 1 (should track the highest-used index for all branches, so you know when this occurs).
Are there any eligible inputs at 2/0/0?
and so forth.