[Passed] Motion proposal to give all votes the same weight

[sigmike]

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.

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.

since the client generates new addresses in order to maintain the 10000 shares per address

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.

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…

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.

So the inner workings of the client regarding the maintenance of 10000 chunks are deterministic? But the generated change addresses are not deterministic?

I guess I answered that question above but if I didn’t let me know.

[Hyena]

Ok thanks for that clarification. This motion has earned my trust now.

[mhps]

You can still split the outputs yourself later by paying the fees.

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?

[sigmike]

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.

[miner]

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?

[sigmike]

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.

[miner]

Thanks for the update. I was planning to install the 0.5.3 version.

[crypto_coiner]

voted

[cryptog]

voted

[sigmike]

The motion passed: https://blockexplorer.nu/motions/success

[creon]

The “voting PoS” of NuShares is very interesting, its basically a proof-of-utxo. I know this was decided long ago, still some questions:

So your outputs will eventually be split in 10k chunks but it may take some time.

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.

(if there is a leftover less than 10,000, it will be combined with a 10,000 one)

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.

[mhps]

mhps:
(if there is a leftover less than 10,000, it will be combined with a 10,000 one)

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.

What new rule? Why is there a 10k block containing the leftover? i am confused.

[creon]

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

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)

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.

[mhps]

If I now get 3k more, I need to split the 17k

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.

[creon]

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.

[mhps]

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.

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.

[creon]

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.

[mhps]

why does it have to split the 17k one when it combines with the 3k one?

[creon]

How do you want to make two 10k outputs out of one 17k input and one 3k input without splitting the 17k input?

[mhps]

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