Using share days destroyed as vote weight

[sigmike]

Continuing the discussion from [PASSED] Finalized motion for protocol changes:

[PASSED] Finalized motion for protocol changes

Permit shareholders to vote to set transaction fees. Default transaction fees equal to the current transaction fees should be applied if there is no transaction fee vote for a particular currency in the majority of share days for the voting period of 2000 blocks. The share day weighted median vote will be the fee. The vote will consist of an 8 bit currency/share code and an uint32 expressing the fee in satoshis.

I’m wondering whether using the share days destroyed is a good thing here, and more generally in all the votes.

An advantage of using share days destroyed is it compensates the variance. If an output doesn’t have much luck and takes a lot of time to find a block, its vote will have more weight. I don’t really see any other advantages.

But it’s also a problem. If someone with a large stake doesn’t mint for a while he will have a huge impact when he starts minting. He may do that intentionally or not. It may result in rapid changes in the fees.

I think we should just use the median fee of the last 2000 blocks here, not weighted by the share days.

[Cybnate]

We already seeing that effect over the weekends when some shareholders go online and have a higher impact than others with similar stakes. I think that’s why we have seen the fluctuations with some proposals going up and down and back up later. It seems to be worth waiting and not minting until a favourite proposal comes up and then start minting and with a bit of luck push something over the line, which might not have made it otherwise.

[JordanLee]

I regard the way share days accumulate beyond seven to be a bug in the protocol and is contrary to my intention all along. When I first noticed it in the block explorer I thought it was a block explorer bug, but it was easy to verify that is not the case.

My original intention was that a block found with an output containing 100,000 NuShares would get ten times the weighting of an output with 10,000 NuShares. So, a 10 day old output with 10,000 NuShares in it would have 70,000 share days of weighting. A 100 day old output with 100,000 NuShares would have 700,000 share days. The principle is you don’t get any extra benefit or influence by leaving your NuShares offline. All that matters is the size of the output. The probability of minting already works this way (capped at seven days), but vote counts do not.

Therefore, I request that this bug be fixed in 0.6.0 with other protocol changes. I don’t think it requires a motion as it is a bug.

What sigmike has proposed is slightly different. I’m not certain whether it is the best direction. What is clear is that at least right now nearly everyone has their outputs split into 10,000s so that both counting methods would yield quite similar results. I guess I am still leaning toward what I understood as the original specification, which I believe sigmike would agree is a big improvement over how it works now.

[Ben]

I regard the way share days accumulate beyond seven to be a bug in the protocol and is contrary to my intention all along. When I first noticed it in the block explorer I thought it was a block explorer bug, but it was easy to verify that is not the case.

Let’s confirm it really is a defect in the protocol vs. a visual issue with a block explorer calculation.

[JordanLee]

I’ve done a little more thinking about whether share day weighting is a useful way of measuring consensus.

If someone buys 1,000,000 NSR and places them in a single output everyone could agree they deserve more influence than someone who only buys 10,000. The problem is they can get all that influence at once, which makes the network subject to sudden changes instead of the slow, creeping consensus formation we have seen so far.

In the case that we didn’t use share weighting for any consensus measurement the perspective could be taken that if someone doesn’t divide their NSR into outputs of 10,000 that is a user error. There is an incentive to not divide into outputs of 10,000 because that requires more transaction fees. The sender pays the fees, but the recipient gets the benefit of optimal voting power. My guess is that if an exchange didn’t divide outputs to save money on withdrawals there would be complaints that would induce them to pay the extra fees to properly size outputs. Outputs will slowly grow in size as they mint, so if we don’t use share weighting an output of 10,200 that had found five blocks in the past would get the same influence as an output of 10,000. I would expect at some point we will create easy to use functionality that optimizes the size of outputs in a wallet automatically. It would be analogous in some ways to the way a disk defragmentation utility works.

While there are problems with not using weighting, there are certainly issues with using it. I’m warming up to the idea of not using share day weighting in any context. Perhaps @sigmike is interested in advancing a motion on the subject.

[JordanLee]

Let’s confirm it really is a defect in the protocol vs. a visual issue with a block explorer calculation.

The getmotions and getparkvotes RPCs yield the same results as the block explorer.

[mhps]

if someone doesn’t divide their NSR into outputs of 10,000 that is a user error.

I thought according to the following quotes dividing up to 10,000 shares was automatically done in the sending process ,

Probability to find a kernel

Then it tries to make as many 10k outputs as possible. For example if you have 33k as total input there will be 2 outputs with 10k and 1 output with 13k. 10k is the default because it’s the minimum amount allowed to mint. You can change the split amount with the config/argument splitshareoutputs. The same process applies when sending NSR in normal transactions.

Anyway it would be great to redistribute the utxos. I was thinking how to make all utxo’s 10,000 shares again because you get more minting reward if you spread you shares to more utxos with smaller sizes (Time-to-find-a-block is longer for smaller utxo’s, so the 7-day waiting period occupies a smaller fraction in time-to-find-a-block).

[JordanLee]

I thought according to the following quotes dividing up to 10,000 shares was automatically done in the sending process

That is the default behavior but it can be modified using the .conf file

[sigmike]

My original intention was that a block found with an output containing 100,000 NuShares would get ten times the weighting of an output with 10,000 NuShares. So, a 10 day old output with 10,000 NuShares in it would have 70,000 share days of weighting. A 100 day old output with 100,000 NuShares would have 700,000 share days. The principle is you don’t get any extra benefit or influence by leaving your NuShares offline. All that matters is the size of the output. The probability of minting already works this way (capped at seven days), but vote counts do not.

Since the minimum age to vote is also 7 days then what you want is actually to remove the days from the equation, because they will always be equal to 7 (so they won’t change the vote because all the weights are multiplied by the same value). Let’s use the term shares or amount of share in this case, not share days.

So that solves the problem of people accumulating days when they don’t mint. That’s good.

But I think using the amount of shares is also a problem. Someone with a large stake has basically 2 options:

1. Split his stake in 10k outputs. In this case he will find many blocks and get the maximum reward.
2. Use a single output. He will only find 1 block per week because of the min age, but he will have a large impact on the votes weighted by the amount of shares.

He can also use anything in-between, for example to try to find a block every 2000 blocks (because some votes are based on the last 2000 blocks).

So basically there’s a trade-off between reward and vote influence. I don’t think it’s a good thing.

If we don’t use shares as weight then the optimal strategy for both reward and influence is to split your outputs. Not splitting the outputs would only save some fees.

it is a bug

The term “share days” just means “the amount of shares multiplied by the number of days”, there’s no implicit maximum or minimum in any of the terms. So if you have constraints in mind it’s better if they are explicit.

if someone doesn’t divide their NSR into outputs of 10,000 that is a user error

It’s more a choice than an error. He looses potential vote weight and reward to pay less fees. The problem as you say is that the choice is not yours, it’s the sender’s. But you can still correct it by sending the shares to yourself.

I would expect at some point we will create easy to use functionality that optimizes the size of outputs in a wallet automatically. It would be analogous in some ways to the way a disk defragmentation utility works.

That may be costly and it would reset the age of your outputs. This process can probably be done progressively while minting to avoid fees and age reset. It’s already partially done because amounts less than 10k are combined and amounts larger than 20k are split.

That makes me think it may be possible to avoid all these output splittings and still give every slice of 10k shares the same odds to find a block. We may have to remove the min age though, but it may not be a problem if every slice effectively has the same chances of finding a block. But that’s probably for another topic.

[sigmike]

Anyway it would be great to redistribute the utxos. I was thinking how to make all utxo’s 10,000 shares again because you get more minting reward if you spread you shares to more utxos with smaller sizes (Time-to-find-a-block is longer for smaller utxo’s, so the 7-day waiting period occupies a smaller fraction in time-to-find-a-block).

If you have large outputs then splitting them would indeed increase your global reward. You can do that by selecting them with coin control and send them to yourself. If you haven’t changed splitshareoutputs the outputs will be split in 10k.

[sigmike]

While there are problems with not using weighting, there are certainly issues with using it. I’m warming up to the idea of not using share day weighting in any context. Perhaps @sigmike is interested in advancing a motion on the subject.

I’ll think about a motion. In the meantime I guess I will put fee voting development on hold until this is decided.