+1
voted too.
"regardless of the amount of shares involved or their age"
Did I understand correctly that the amount of shares involved would no longer matter?
Then if I divide my shares into many addresses I get more votes?
If itās so then Iām against this motion.
Coin age of course should not change the weight of a vote but the number of shares held by the voting address must definitely correlate positively to the influence of the vote. This needs clarifying.
Currently all send transactions will divide neshares into outputs of 10,000 NSR by the client by default. So everyone should have their shares stored in their wallets in 10,000 NSR āblocksā (unspent transaction outputs, UTXOs). If you split them into, say, 5000 NSR outputs, then since the smallest UTXO that can find a block (therefore can vote) is 10,000 NSR, your shares wonāt be able to find blocks.
Whatās more, if in the same address you have a UTXO of 10,000 NSR or more that finds a block, the output will combine those outputs that are smaller than 10,000 NSR and split them into 10,000 NSRs outputs (if there is a leftover less than 10,000, it will be combined with a 10,000 one)
Those who receive their shares in a big lump (more than 20k in an output) will loose opportunity to find blocks and should complain to the sender who must have changed the behavior of the client.
So, essentially the voter is responsible of making sure that their nushares are divided into 10000 NSR per address chunks? In that case I donāt see a problem with this motion. Would I have to use RPC command such as listunspent to see if any of my addresses contains far more than 10000 nushares?
edit:
this may be a bit offtopic now but since the client generates new addresses in order to maintain the 10000 shares per address distribution does that mean wallets will get out of synchronization at some point? In my case I use duplicate wallets concurrently. One wallet runs at a safe place and is unlocked for minting only and the other wallet I run on my PC and that is locked but it shows me the blocks I mint in real time. The problem would arise when I receive new funds. Which wallet gets to generate the new addresses needed for the distribution of nushares? Things may get messy thereā¦
better: use the coincontrol function of the 0.5.2 wallet. 
see related discussions here.
If both wallet own the same receiving addresses both will see the same funds. When not sending, clients are just blockchain browsers.
If the addresses are generated by one wallet and the walletS.dat are not shared between the two clients, you will need to use dumpprivkey / importprivekey.
So the inner workings of the client regarding the maintenance of 10000 chunks are deterministic? But the generated change addresses are not deterministic?
The amount of shares a shareholder owns still influences the global vote because with more share heās able to find more blocks, and each block still allows you to cast exactly 1 vote. What changes is that these votes will all have the same weight.
They may do that for good reasons. For example splitting shares implies large fees. An exchange would have to deduce this fee from withdrawals and traders may not want that (because they donāt intend to mint, or not immediately).
You can still split the outputs yourself later by paying the fees.
It doesnāt generate new addresses. It just split the outputs. It means when you receive 50k itās like you received 5 times 10k to the same address at the same time.
If the wallets are just receiving and minting you donāt have to worry, theyāll never generate addresses by themselves.
When you send share thereās no address generated for the change either, because we enabled avatar mode by default on the NSR wallet. That means the change is sent back the first sending address. Note that itās not the case on the NBT wallet. But we enabled avatar mode by default to solve another problem, so it may change in the future if we find a better solution, so you probably should not rely on that.
I guess I answered that question above but if I didnāt let me know.
Ok thanks for that clarification. This motion has earned my trust now.
Or wait for 7 days until the first block is found by the ālumpā and in its output all shares will be sent in 10k blocks without paying fees, right? Not being sent in 10k blocks will cause the receiver to loose the 8th-14th daysā minting reward. After the the 14th day, all shares are in 10k (plus some rewards) and minting regardless how the shares were received. Is this correct?
Indeed.
Except there are some limits on the number of outputs generated in this situation. Itās currently arbitrarily set to 5 maximum outputs when the CoinStake outputs are split. The reason is thereās a protocol limit of 1 kb for the CoinStake transaction (which includes the vote). So to avoid too large CoinStake this limit was added. We could take some time to make this more optimal and actually use the maximum available size, but we had more urgent developments to do.
So your outputs will eventually be split in 10k chunks but it may take some time.
1 Like
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.