Consider adding pendingEffectiveAmount data to claim information #203

Closed
opened 2018-09-11 21:30:27 +02:00 by tzarebczan · 9 comments
tzarebczan commented 2018-09-11 21:30:27 +02:00 (Migrated from github.com)

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.

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.
kaykurokawa commented 2018-09-17 16:29:47 +02:00 (Migrated from github.com)

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.

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.
bvbfan commented 2018-10-04 13:52:18 +02:00 (Migrated from github.com)

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.

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.
bvbfan commented 2018-10-24 13:21:10 +02:00 (Migrated from github.com)

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?

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 commented 2018-10-26 20:26:25 +02:00 (Migrated from github.com)

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?

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 commented 2018-10-31 13:50:42 +01:00 (Migrated from github.com)
#232
tzarebczan commented 2018-12-15 17:20:20 +01:00 (Migrated from github.com)

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

@bvbfan does your fix also take into account supports? I also noticed supports don't show until the takeover occurs.
bvbfan commented 2018-12-17 09:33:07 +01:00 (Migrated from github.com)

@tzarebczan it should.

@tzarebczan it should.
BrannonKing commented 2019-05-08 16:52:00 +02:00 (Migrated from github.com)

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.

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 commented 2019-09-06 22:12:49 +02:00 (Migrated from github.com)
Merged via https://github.com/lbryio/lbrycrd/pull/303
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbrycrd#203
No description provided.