- Sep 19, 2014
It could initially just be FIFO, with organization bullet points added later.Vote per project is a hands off approach without any coordinating when to pay projects, in what order. Also both projects start right away and potentially would be completed faster.
As already discussed, fund rate, priority, etc...
Binary works well in layers. It keeps things organized.
1) Are we doing this shit? Y/N
2) How much of the block reward are we committing to this shit? 1/5/10/15/Decide Later
3) Is this shit more or less important than other existing shit we're doing? M/L/I'm Too Drunk To Make This Decision.
Things could go parallel... If 3 accepted proposals get 5%, then all 3 fit into the 15% cap,and can be funded at once... % doesn't slow down the queue, all things funded as fast as possible within cap constraint. Just throwing out ideas, that may be a dud even as I type it...
It may be "clumsier" but more useful to keep the % independent of the project. "X% going to Queue" This could flex depending on where all nodes stand at each block time, and could even be an average of all stated %... IT would be like a MN defined Difficulty, designating input based on value perceived in the queue at a given time. Making it an average would marginalize slow voting and ramp anyway.
The ncurses interface could even display current status of decision making. "28%Y - 0%N"
Last edited by a moderator: