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.
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?
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.
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?
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.
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.
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