I think there is a bug on the motion vote feature. I am using 0.5.1 beta. I put in the motion hash yesterday. I switched off the computer last night. This morning I launched the Nu client and found the Motion hash gone. Is it designed to store the motion hash locally?
Yes this bug was fixed in 0.5.2. Itâs stored in your wallet. The problem is it saves the vote in the old format, which allows only 1 motion. You can download version 0.5.2 there: Nu client version 0.5.2 promoted from beta to main download page.
Thanks for the update. I was planning to install the 0.5.3 version.
voted
voted
The âvoting PoSâ of NuShares is very interesting, its basically a proof-of-utxo. I know this was decided long ago, still some questions:
Couldnât the kind wallet say that transactions from an address to itself with a single input that is > 10k and n outputs with at least n - 1 of those having a value of 10k should be processed without tx fee? You can hardly spam the network with this rule, and it would speed up the splitting process.
With the new rule of the proposal, shouldnât the leftover be put in a new output? Because then you avoid wasting the coin age of the 10k block containing the leftover if you have enough shares to create a new 10k block together with the leftover.
1 Like
What new rule? Why is there a 10k block containing the leftover? i am confused.
Sorry if I was unclear. With the new rule I mean that the amount of shares used in the staking transaction doesnât influence the voting weight. Then you said
and I was referring to the edge case you mentioned in the brackets. So if I have a utxo of 27k your method will create one new output with 10k and another one with 17k. If I now get 3k more, I need to split the 17k output in order to form two new 10k outputs. If we however would have divided the original 27k output into 10k / 10k / 7k, we could keep the the existing 10k outputs untouched and therefore avoid wasting the coin age.
If you later have 3k utxo in the same address, then only when a utxo in this address finds a block this combination happens. Usually it is one of the many 10k blocks that finds a kernel and combine with the 3k to form an output that is origianl_block_size+40+3k . I donât know what happens if it is the 17k block that finds a block next.
So you say that the 3k has to wait for the 17k utxo to find a block to be recombined into a new 10k utxo? But then weâre wasting the age of the 7k and the 3k since they never contribute to the voting process.
This all may sound negligible, thing is if the source will be open one day, people will start optimizing the staking process (within the limitations of the protocol), and therefore the default wallet should also design the staking process as efficient as possible such that there isnât a small group that has an advantage.
the 3k one will be combined in the next block found by any utxo in the same address.
higher coin amount will allow a utx to find a block proportioally quicker.
But if there is only the 3k, several 10kâs and the 17k, and one of the 10k chunks finds a block, then it either has to split the 17k (wasting its age) or keep the 3k uncombined ⌠thats what I am trying to say.
why does it have to split the 17k one when it combines with the 3k one?
How do you want to make two 10k outputs out of one 17k input and one 3k input without splitting the 17k input?
0 somehow you get a 3k output in the address that has 10k 10k 10k 17k outputs
1 a 10k ouput finds a kernel
2 it looks for outputs smaller than 10k
3 it finds the 3k one
4 it combine w/ the 3k one to make a 13040 output
now you have 10k 10k 10340 17k outputs
What? But thats horrible, because both the 13040 output and the 17k output will only cast one vote each with the new rule, although the shareholder has enough shares to cast three votes per week. Then everyone who is aware of this and knows what coin control is has a clear advantage.
but the 13040 and 17k blocks have proportionally bigger chance to find a block in the same period. So on average Your voting power is proportional to the total amount of shares you have in blocks >= 10k.
Why that? If this is true, why are we splitting the outputs in the first place? If a 20k chunk produces twice the amount of blocks in expectation, then I donât see why I should want it to be divided into two 10k chunks if I want to improve voting power.
There is a monetary incentive of course, as in any PoS system, to split the balance into minimal chunks in order to maximize the number of candidates when searching for a kernel, but I thought the idea behind the splitting here is to optimize voting, not expected reward.
Even if the 20k chunk has twice the probability to find a block, two 10k chunks will still produce more blocks as long as each of them needs less than 3.5 days to find a kernel, which will basically always be the case considering the coin supply and the block time. And because of the same argument the 17k should be divided into 10k and 7k if 3k are available 