search

slimcoin-project / pacli

Simple CLI PeerAssets client (extended version).
GNU General Public License v3.0
0 stars 0 forks source link

proposal list without the DECK argument / proposal voters #175

Open buhtignew opened 1 month ago

buhtignew commented 1 month ago

Would it make sense to consider the proposal list run without a DECK argument as referring to the standard PoB token?

d5000 commented 1 month ago

Affirmative. :)

Implemented not only for proposal list, but also for: podtoken state and podtoken votes.

Commit: 2071615. Can be closed if there are no new problems, was pre-tested.

buhtignew commented 1 month ago

For the podtoken votes I'm getting the following error message:

  File "~/.local/bin/pacli", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/__main__.py", line 479, in main
    fire.Fire({
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 143, in Fire
    component_trace = _Fire(component, args, parsed_flag_args, context, name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 477, in _Fire
    component, remaining_args = _CallAndUpdateTrace(
                                ^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 693, in _CallAndUpdateTrace
    component = fn(*varargs, **kwargs)
                ^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/dt_classes.py", line 222, in votes
    return self.__get_votes(proposal_or_deck, debug=debug)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/dt_classes.py", line 168, in __get_votes
    proposal_id = eu.search_for_stored_tx_label("proposal", proposal)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_utils.py", line 481, in search_for_stored_tx_label
    raise ei.PacliInputDataError("Label '{}' not found.".format(identifier))
pacli.extended_interface.PacliInputDataError: Label 'None' not found.

The other ones seem to work as expected.

d5000 commented 1 month ago

The podtoken votes command doesn't work without any argument. Either you have to enter a proposal (as positional argument) or -m or -a ADDRESS. I just checked -m and -a and they work. The help was perhaps a bit misleading so I improved it so it's clear that the command doesn't work without any argument.

The error is however ugly, so I catched it. Commit: b0df8b4

Doesn't really need testing, you can close it (leave open so you read the info).

buhtignew commented 1 month ago

Maybe it doesn't make sense at this stage, but what if the address would become a positional argument as the deck so as there is no need to use the -m flag (no address = current main address) and also to use the -a flag. Also because the -m flag for the other commands means --mini-id. We'd have too much positional arguments in this command in such a case, wouldn't we? _ While testing this I've noticed the following: If I run proposal list a2459e054ce0f600c90be458915af6bad36a6863a0ce0e33ab76086b514f765a there is the only one proposal, 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595, mentioned. Then if I run proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 there is number of addresses. I've picked the last one of the list, n3qWzoBX24abCSq8hMMzmCb8dh5ePnhdmL, and have run podtoken votes a2459e054ce0f600c90be458915af6bad36a6863a0ce0e33ab76086b514f765a -a n3qWzoBX24abCSq8hMMzmCb8dh5ePnhdmL but got 'Votes cast from address: n3qWzoBX24abCSq8hMMzmCb8dh5ePnhdmL' only. Since the proposal 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 makes part of the deck a2459e054ce0f600c90be458915af6bad36a6863a0ce0e33ab76086b514f765a and the address n3qWzoBX24abCSq8hMMzmCb8dh5ePnhdmL seems to have voted for that proposal I was expecting the output to provide some result about the votes provided by that address, but I feel like I'm not fully understanding how it supposed to work in this case.

d5000 commented 1 month ago

We're talking about pobtoken votes here, right?

The reason the -m argument is required is the branching logic of the command. If the command is called with one positional argument and without any flags (or without -a and -m), then it assumes that to be a proposal ID, not a deck ID. Testing if it's a deck or a proposal in this case is quite slow and complicated.

That's why I'd prefer to leave it the way it is.

In theory, we could move the command variant with the proposal as main positional argument to the proposal category. This is not that complicated because the command variant uses a different main function anyway than the other variant with DECK as first argument. This would allow the change you proposed.

My argument against that was until now that the proposal voters command exists and the commands are a bit similar, in addition being one command more. But perhaps a command keyword like allvotes or voteresults or so would be possible. If you agree with one of these or have a good idea for the keyword I'm willing to implement these changes.

Another idea is to change proposal voters to proposal enabledvoters or something similar. This is also an easy change and would allow to use proposal votes for the command variant which now is podtoken voters PROPOSAL.

The response to your second issue is simple: This command displays the "enabled voters", not those who vote actively. It's the addresses which can vote on a proposal. I have changed the help a bit so it becomes clearer.

Changing this command to enabledvoters or so would also help to make that clearer. Only problem is that enabledvoters is a bit long, perhaps you have an idea?

buhtignew commented 1 month ago

But perhaps a command keyword like allvotes or voteresults or so would be possible.

What about proposal approval, proposal ratification or proposal assent?

Changing this command to enabledvoters or so would also help to make that clearer. Only problem is that enabledvoters is a bit long, perhaps you have an idea?

Maybe proposal suffrage or proposal franchise? _ By the way is it expected that until the second last block of the Voting Round 1 the output is different than from the last block of the Voting Round 1 on? (for instance in case of proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 134650 and proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 134651 commands).

Another question: what is the meaning of the negative "balances" in both outputs?

d5000 commented 1 month ago

I like proposal approval, so I implemented it this way:

I also added support for address labels for podtoken votes. Commit is a0b8e9c.

Made also a very small bugfix in pypeerassets (only relevant for some commands with debug option but update is not a bad idea).

is it expected that until the second last block of the Voting Round 1 the output is different than from the last block of the Voting Round 1 on?

what is the meaning of the negative "balances" in both outputs?

Both things look unexpected. Strange because I've tested that part extensively. Have to look deeper into it, so I leave this open. Can take some days.

buhtignew commented 1 month ago

In the mean time I'd like to ask you whether it is possible/would make sense to add into proposal approval the list of addresses that have voted during each voting round of the proposal?

Or maybe there is such a command I'm not aware of?

In my understanding at the moment to get the same info one needs first to list the voters (e.g. proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595) and then running podtoken votes a2459e054ce0f600c90be458915af6bad36a6863a0ce0e33ab76086b514f765a -a ADDRESS for each of those addresses extract manually the searched proposal's info from each output.

d5000 commented 1 month ago

In the mean time I'd like to ask you whether it is possible/would make sense to add into proposal approval the list of addresses that have voted during each voting round of the proposal?

Closest one-liner is probably pacli proposal show DECK -s -p voting_txes, but it does not show the addresses but the voting TX IDs, and would be probably an easy addition so I'll consider it.

d5000 commented 3 weeks ago

Implemented a --voters option for proposal approval showing the voting transactions, the voters addresses and the weights.

Pre-tested. Commit is 0d7676a. Detailed testing should be done once the dPoD unittests are implemented.

Please close if there's not something very important because it's not more about the proposal list command. Later a new issue can be opened.

buhtignew commented 3 weeks ago

There is still the following question left:

Both things look unexpected. Strange because I've tested that part extensively. Have to look deeper into it, so I leave this open. Can take some days.

Do you prefer me to open another issue for this or you have it under your control and will make me know somehow when it solved?

d5000 commented 3 weeks ago

Ah, you're right. Ok, then we can leave this open until it is solved. I'll perhaps rename the issue.

d5000 commented 3 weeks ago

This was actually a mix of 2 bugs on pypeerassets, one of both was quite important:

1) -b option was flawed. The parser algorithm which processes the votes was not stopping correctly at the block height, instead continuing to the last block of the chain. Nevertheless -b influenced the result because some other parameters depended on it. The bug wasn't really severe because the blockheight function was only used by the proposal voters command and would not have influenced voting outcomes or so, but anyway had to be fixed.

2) The algorithm processing the voting token (SDP token, which is a PoB token) weight affected also the voters who voted with the dPoD token. This was a major problem because it could have influenced voting outcomes, and it caused also the negative values. The affected functions were not unittested still and I probably would have discovered the flaw when unittesting them, but anyway it's a relief that it's fixed now. Both voter categories were now cleanly separated, but if a voter has balance of both tokens always his full balance will be taken into account.

Commit: c495983 (on pypeerassets)

We can now close this and test it later when it's the turn of the rest of the dPoD parts.

buhtignew commented 3 weeks ago

I have only one question left: Now both the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 134650 and the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 134651 outputs contain only one voter, while previously it was a long list. But what is the meaning of the following sentence in the output:

'Note: The weight corresponds to the adjusted PoD and voting token '
'balances at the start of the epoch 168 containing the selected '
'blockheight 134651.'

Specifically what the number 168 means? Is it the epoch number? If so how what are the epoch number and how are they distributed? Or it's the number of voters that should be displayed?

d5000 commented 3 weeks ago

Epoch is the "distribution period" where at the end a reward can be paid out if there are completed proposals. See the wiki:

Distribution Period: A fixed interval of blocks, defined by the Deck Issuer in the initial rules, where one Token Distribution takes place. Also called epoch.

It could also be called the "block" of the dPoD token, because it corresponds to one dPoD reward (although in periods without completed proposals the reward is not paid out).

In the case of the "standard" dPoD token on Testnet the epoch has a length of 800 blocks. This means that epoch 168 starts at block 168 * 800 = 134400 (counted from the genesis block, not the deck spawn block).

buhtignew commented 2 weeks ago

Thank you for explanation!

Does the fact that proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 134650 displays only one voter means that there was only one potential voter enabled for that proposal? My assumption was that every PoB token owner would be considered as a potential voter, so the output provided before the commit c495983 (on pypeerassets) looked more expected to me because there was a long list of voters while in this case there is only one.

d5000 commented 2 weeks ago

Answer is easy: this proposal was created very early and only me was testing this dPoD token then. The voting token had just been created too (it is the same one that is now the "standard" PoB token on Testnet), and my address that was the only voter was the only one that had claimed the PoB tokens until the deadline block for this epoch.

You can investigate that if you simply use the transaction list DECK -c command for the standard PoB token, and you'll see that the only claim transaction before block 134400 is 97e82554217ff486343833c1e8c7629d459b9a831496091da46b4096d2523815 which issues 574.5 PoB tokens to mie75nFHrNAHHKfQ141fWfWozdMnaec8mb and enables this address to vote.

buhtignew commented 2 weeks ago

I've got it. Thank you!

And why is it that from the block 136800 on the output of the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 136800 is like this:

{
    'mie75nFHrNAHHKfQ141fWfWozdMnaec8mb': Decimal('109155.000000000'),
    'mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh': Decimal('5137')
}

While the output of the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 is just a long list of addresses.

It's basically the list of the current weighted standard dPod and PoB tokens balances, isn't it?

d5000 commented 2 weeks ago

And why is it that from the block 136800 on the output of the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 136800 is like this:

I re-checked and made actually a small but important mistake when fixing that pypeerassets bug. The first address should have had less balance. Now I fixed the bugfix and re-checked and now everything looks as expected (commit 338f440 on pypeerassets).

mie75nFHrNAHHKfQ141fWfWozdMnaec8mb has voting weight 51705 due to its balance of 574.5 PoB tokens (with weight 0.9 at this block height because already one proposal had been approved, and every approved proposal evey epoch with an approved and completed proposal reduces the number by 10 percentage points), mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh due to 51.37 dPoD tokens (always have weight 1). The numbers are as high as they are because always the minimum possible value of the token with more decimal places (in this case: dPoD with 2 decimal places, i.e. minimum of 0.01 tokens) is the unit which gives you weight = 1.

It's basically the list of the current weighted standard dPod and PoB tokens balances, isn't it?

Yes. I'm just realizing that the wording of the command isn't ideal here - I would expect this outcome from a command like podtoken enabled_voters or so, not proposal voters, because that output isn't related to any proposal.

I'll think about how to reorganize that. An idea could be moving it to the podtoken class with the following changes:

podtoken voters [DECK] outputs the current voting weight, and can be fine tuned by the -b (blockheight) parameter. If DECK not given, the standard dPoD token is used.

podtoken voters -p PROPOSAL -p PHASE outputs the voting weights for one of both voting phases of the proposal. Should return an error if the "electorate" isn't defined still (if the vote is in the future and the epoch where the vote takes place has still not started).

voters in the podtoken class would not be 100% ideal due to the votes command being also in that class. Your suggestion above suffrage could also work, or electorate perhaps.

buhtignew commented 6 days ago

And why is it that from the block 136800 on the output of the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 136800 is like this:

What I was trying to ask, and it's still not that much clear to me right now:

What is not clear to me is: 1) Why there is an additional voter at the block 136800? Is it a voter that had claimed the tokens of another proposal that has finished all his rounds in the mean time? If so do you know which is that proposal? 2) What is the list of the voters I'm getting if I'm not using the -b flag? Are they the voters of the moment I'm launching the command? 3) Why is it that the voting weight of the address mie75nFHrNAHHKfQ141fWfWozdMnaec8mb is so different when I launch proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 compared to its weight at the block 136800? _

... because already one proposal had been approved, and every approved proposal reduces the number by 10 percentage points...

I think the original idea was to reduce that PoB tokens weight by 10% on each epoch on which there are approved proposals, because if on each voting the PoB token loses its value by 10% if there are 10 proposals to vote at once the PoB tokens will lose they voting power just in one epoch and the PoD tokens will take over too quickly. _

An idea could be moving it to the podtoken class....

Having this command in the podtoken class doesn't look to me too intuitive either, because at least in the beginning we'll have both podtoken and pobtoken owners to vote. Maybe it can make sense just to change the word voters into suffrage or electorate and keep it in proposal group? Another idea can be to move it into token group, but I'm not sure about, TBH.

d5000 commented 6 days ago

1) Why there is an additional voter at the block 136800? Is it a voter that had claimed the tokens of another proposal that has finished all his rounds in the mean time? If so do you know which is that proposal?

This is actually exactly the issue why I had the idea to move the command into the "podtoken" group. The token amount of the "additional voter" you're referring to is actually the tokens the donor to the selected proposal (37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595) got for his donation transaction e9b1c2c444a1be202306838a27c070611a0983293c90e7a0310db96936dd40b4. 136800 is the start block of the first epoch this voter is enabled to vote.

This outcome is a bit unintuitive, because it's independent from the proposal you enter. The outcome of proposal voters on a specific block height (-b flag) will be the same for all proposals from the same deck. So for me it's more intuitive if you enter this command with the Deck ID as argument, not the Proposal ID, although a secondary mode with the proposal as argument could be useful.

I also don't see a problem if it's in the podtoken group because the command, if we change it in the way I proposed in the last post, would take a dPoD token deck ID as an argument. It doesn't seem important to me that the voting token is a PoB token (and it can be any kind of token, depending on deck rules).

token would not a good command group, because this is for commands which can apply to any token. In this case we have a specific dPoD token function.

2) What is the list of the voters I'm getting if I'm not using the -b flag? Are they the voters of the moment I'm launching the command?

Yes.

3) Why is it that the voting weight of the address mie75nFHrNAHHKfQ141fWfWozdMnaec8mb is so different when I launch proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 compared to its weight at the block 136800?

Because it's the current state of the weights based on the voting token and the dPoD tokens. There were a lot of PoB tokens claimed since block 136800, and the "main" PoB token is the voting token for this dPoD token.

buhtignew commented 3 days ago

An idea could be moving it to the podtoken class...

I've reconsidered your idea more thoroughly and, contrary to what I've said previously, I think it's a very good idea.

In fact until we don't have tokens that use other rules to define the voting weights there won't be even the need to specify the deck. And everybody would be enabled to see the current voters' weights picture or how it was previously (at any block).

The idea with podtoken voters -p PROPOSAL -p PHASE usage mode is also very good because it will help people to see the voters weights in a specific phase of the specific proposal and also will warn the users if the voting phase hasn't begun yet.

But do you think it will be possible to use the same flag twice?

It's up to you to change the word voters into electorate or suffrage or not, I agree in advance with whatever choice you consider to be the best one in this case.

If you still not 100% satisfied with this idea maybe we can consider to create a separate category electorate with just one command list in it as alternative (i.e. pacli electorate list). But I'm not that sure about this idea, TBH.

I think the original idea was to reduce that PoB tokens weight by 10% on each epoch on which there are approved proposals, because if on each voting the PoB token loses its value by 10% if there are 10 proposals to vote at once the PoB tokens will lose they voting power just in one epoch and the PoD tokens will take over too quickly.

I'd like to know your opinion about this my remark.

d5000 commented 3 days ago

I think the original idea was to reduce that PoB tokens weight by 10% on each epoch on which there are approved proposals, because if on each voting the PoB token loses its value by 10% if there are 10 proposals to vote at once the PoB tokens will lose they voting power just in one epoch and the PoD tokens will take over too quickly

I thought I had answered this, maybe I deleted the answer accidentally. This was simply a mistake in my post, it's not 10% per proposal but 10 percentage points (1.0 to 0.9 to 0.8 to 0.7 etc.) per epoch with completed proposals, so it's more or less like you wrote.

Regarding the double flag -p, this was also probably a mistake. Of course that would not work this way, we'd need two different flags.

I'll proceed moving the command into the podtoken group then. Once ready I'll post the commit and the new usage.

buhtignew commented 2 days ago

Looking forward for the new upgrade. _

The token amount of the "additional voter" you're referring to is actually the tokens the donor to the selected proposal (37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595) got for his donation transaction e9b1c2c444a1be202306838a27c070611a0983293c90e7a0310db96936dd40b4. 136800 is the start block of the first epoch this voter is enabled to vote.

I still have some doubt about the change of the number of the voters at the block 136800. The difference between the output of the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 136800 and proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 136799 outputs is the address mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh. The block 136800 is the very first block where the donors of the proposal 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 were enabled to claim tokens. The proposal 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 refers to the deck a2459e054ce0f600c90be458915af6bad36a6863a0ce0e33ab76086b514f765a (I've got it from the proposal show 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -i output). If I run token transfers a2459e054ce0f600c90be458915af6bad36a6863a0ce0e33ab76086b514f765a -a mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh I'm seeing transaction 0064a21776ddf70004d34c7a51de68de585e7ee6b5e0d5d4d43832984892077c that has occurred at the block 137298 which is 498 blocks after the block 136800. So it's as if the proposal voters 37e7f1556c5e192ac782e3576b5723492daebdb884e1ce0a6d8aa89867194595 -b 136800 output were anticipating the block at which the voter actually have that voting weight.

d5000 commented 7 hours ago

You were correct, there was still a problem with the command. It processed actually more epochs that it should have. Meanwhile I discovered another problem in pypeerassets, which allowed to create voting power out of thin air.

Both problems are fixed now, and the command was also updated as announced (I change the title of the issue accordingly). The relevant commits are:

Both have to be upgraded.

The command is now called podtoken electorate. Proposals can be checked with the -p option, to see the enabled voters for each phase. More details in the help string.

There was also a new option added: With -n or --next you can check the epoch after the current block height (or the block height you give). This allows if a proposal is to be voted in the next epoch, to see how the electorate would look if the "cut" for the voting weights was at the current block and not at the epoch start block, taking into account the transfers in the epoch the given block height is in. In addition this option is useful for debugging.