Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding pendingEffectiveAmount data to claim information #203

Closed
tzarebczan opened this issue Sep 11, 2018 · 9 comments
Closed

Consider adding pendingEffectiveAmount data to claim information #203

tzarebczan opened this issue Sep 11, 2018 · 9 comments
Assignees
Labels
priority: medium Work needs to be done within 2-3 sprints Tom's Wishlist type: new feature New functionality that does not exist yet

Comments

@tzarebczan
Copy link
Contributor

Currently, we have a data field called EffectiveAmount which shows the current claim bid, including any tips and supports. During a claim takeover bid, the effective amount of the newly bid claim is set to 0 until the takeover completes. If another user tries to take over the vanity URL, they will only be aware of the current vanity claim bid, and not the pending one which could be outbidding theirs. Optimally, we would show the current and any pending claim takeover bids.

@tzarebczan tzarebczan added the type: new feature New functionality that does not exist yet label Sep 11, 2018
@alyssaoc alyssaoc added needs: grooming Issue needs to be groomed before work can start needs: priority Priority level needs to be defined labels Sep 12, 2018
@kaykurokawa
Copy link

kaykurokawa commented Sep 17, 2018

Can confirm that this is indeed the case, can check via getclaimsforname for example (but also same case with getclaimbyid)

{
  "nLastTakeoverHeight": 412837,
  "claims": [
    {
      "claimId": "5cbbfe31cd8fbaf442097981474bfa81bd068469",
      "txid": "d5b135291ea857ff73b7a4c9e97cffcd2a7934aa63d33409bc5c12710b286818",
      "n": 0,
      "nHeight": 412837,
      "nValidAtHeight": 412837,
      "nAmount": 10,
      "value": "",
      "nEffectiveAmount": 10,
      "supports": [
      ]
    }, 
    {
      "claimId": "56257f567cc64505e145b56d773004f79a53c576",
      "txid": "ca72c26365364093163308b5b983504261ab602f360e3487b4287c2a7b1aca5b",
      "n": 1,
      "nHeight": 591604,
      "nValidAtHeight": 595636,
      "nAmount": 2000000000,
      "value": "\u0000\u0000",
      "nEffectiveAmount": 0,
      "supports": [
        {
          "txid": "63aa07fc65c831f88ba1fb4f8f94353e93e5117cbbf5c7ea8dfb2da659f4cc29",
          "n": 1,
          "nHeight": 591607,
          "nValidAtHeight": 595639,
          "nAmount": 1000000000
        }
      ]
    }
  ],
  "supports without claims": [
  ]
}

This happens because a claim's effective amount is only calculated in the claim trie. When claims are not activated yet, there are not placed in the claim trie, they are placed in a queue. In the queue, effective amount does not matter because it is only important for calculating the winning claim of the name and claims in the queue cannot win.

@kaykurokawa kaykurokawa added type: bug Existing functionality is wrong or broken priority: low Work should be done but can stay in the backlog for now and removed needs: grooming Issue needs to be groomed before work can start needs: priority Priority level needs to be defined labels Sep 17, 2018
@bvbfan
Copy link
Collaborator

bvbfan commented Oct 4, 2018

Claims have in itself nEffectiveAmount that is calculated despite current height, which is actual reason to not show it. I think we should serialize nEffectiveAmount from CClaimValue @BrannonKing told that on other issue.

@BrannonKing BrannonKing removed the type: bug Existing functionality is wrong or broken label Oct 17, 2018
@bvbfan
Copy link
Collaborator

bvbfan commented Oct 24, 2018

One possible solution is to serialize nEffectiveAmount from CClaimValue to use it for pendingEffectiveAmount when current height is lower that claim valid height. But serialize it we should enforce to re-index, @kaykurokawa can you confirm or decline?

@bvbfan
Copy link
Collaborator

bvbfan commented Oct 26, 2018

After some kind of implementations pendingEffectiveAmount should replace effectiveAmount in result or effectiveAmount should presents event with 0 value which indicate that pendingEffectiveAmount can be in?

@bvbfan
Copy link
Collaborator

bvbfan commented Oct 31, 2018

#232

@tzarebczan
Copy link
Contributor Author

@bvbfan does your fix also take into account supports? I also noticed supports don't show until the takeover occurs.

@bvbfan
Copy link
Collaborator

bvbfan commented Dec 17, 2018

@tzarebczan it should.

@BrannonKing
Copy link
Member

BrannonKing commented May 8, 2019

Updated requirement: we need to expose queued claims/supports in the RPC methods where it makes sense to do so. getclaimsforname needs to return items that are not yet valid. The effectiveAmount should match should go with things that are valid at the specified block. The pendingEffectiveAmount should be the amount after everything we know about is activated.

@BrannonKing BrannonKing added priority: medium Work needs to be done within 2-3 sprints Tom's Wishlist and removed priority: low Work should be done but can stay in the backlog for now labels May 8, 2019
@BrannonKing
Copy link
Member

Merged via #303

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: medium Work needs to be done within 2-3 sprints Tom's Wishlist type: new feature New functionality that does not exist yet
Projects
None yet
Development

No branches or pull requests

5 participants