Add minconf param to claimtrie RPC commands #44

Closed
opened 2016-09-13 00:52:51 +02:00 by kaykurokawa · 9 comments
kaykurokawa commented 2016-09-13 00:52:51 +02:00 (Migrated from github.com)

The following commands need a minconf param to specify how many confirmations are required (aka how many blocks back to look). Default minconf should be 6, like other commands (e.g. listnameclaims).

  • getclaimsforname
  • getclaimsintrie
  • getclaimtrie
  • getvalueforname
The following commands need a `minconf` param to specify how many confirmations are required (aka how many blocks back to look). Default minconf should be 6, like other commands (e.g. listnameclaims). - getclaimsforname - getclaimsintrie - getclaimtrie - getvalueforname
kauffj commented 2016-09-13 09:46:18 +02:00 (Migrated from github.com)

If you change this, please parameterize this. I do not want 6 to be the
only option.

On Mon, Sep 12, 2016 at 6:52 PM, Umpei Kay Kurokawa <
notifications@github.com> wrote:

Claimtrie RPC commands such as getvalueforname, or getclaimsforname need
to look back six blocks , or need an option to specify the block to look
at. Getting the claims for the most recent block is not secure.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lbryio/lbrycrd/issues/44, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAgZVsW_E4FI43vqH7nHQuxcJd6-2449ks5qpdfDgaJpZM4J7Hhe
.

Jeremy Kauffman, Founder, LBRY http://lbry.io/
(267) 210-4292

Build LBRY: get https://lbry.io/get, follow https://twitter.com/lbryio,
like https://facebook.com/lbryio

If you change this, please parameterize this. I do not want 6 to be the only option. On Mon, Sep 12, 2016 at 6:52 PM, Umpei Kay Kurokawa < notifications@github.com> wrote: > Claimtrie RPC commands such as getvalueforname, or getclaimsforname need > to look back six blocks , or need an option to specify the block to look > at. Getting the claims for the most recent block is not secure. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > https://github.com/lbryio/lbrycrd/issues/44, or mute the thread > https://github.com/notifications/unsubscribe-auth/AAgZVsW_E4FI43vqH7nHQuxcJd6-2449ks5qpdfDgaJpZM4J7Hhe > . ## Jeremy Kauffman, Founder, LBRY http://lbry.io/ (267) 210-4292 Build LBRY: get https://lbry.io/get, follow https://twitter.com/lbryio, like https://facebook.com/lbryio
tpruvot commented 2017-05-05 03:16:09 +02:00 (Migrated from github.com)

add a minconf argument like other rpc commands maybe ?

add a minconf argument like other rpc commands maybe ?
shamoons commented 2018-05-17 22:07:41 +02:00 (Migrated from github.com)

In listnameclaims, the default minconf appears to be set to 1. Do we want to change it to 6 everywhere?

https://github.com/lbryio/lbrycrd/blob/master/src/wallet/rpcwallet.cpp#L764

In `listnameclaims`, the default `minconf` appears to be set to 1. Do we want to change it to 6 everywhere? https://github.com/lbryio/lbrycrd/blob/master/src/wallet/rpcwallet.cpp#L764
BrannonKing commented 2018-07-20 17:15:00 +02:00 (Migrated from github.com)

We discussed changing minconf from 1 to 6 everywhere it previously existed. However, in working on this, it only exists in rpcwallet. I'm adding it to rpcclaimtrie. Hence, I don't think that we need to keep the same default, and I'm hesitant to change the out-of-the-box API.

We discussed changing minconf from 1 to 6 everywhere it previously existed. However, in working on this, it only exists in rpcwallet. I'm adding it to rpcclaimtrie. Hence, I don't think that we need to keep the same default, and I'm hesitant to change the out-of-the-box API.
tzarebczan commented 2018-08-07 01:21:27 +02:00 (Migrated from github.com)

How does this affect lbryumx that uses these calls to get claim information? Will it not be available until 6 confirmations? Cc @ful0n

How does this affect lbryumx that uses these calls to get claim information? Will it not be available until 6 confirmations? Cc @ful0n
BrannonKing commented 2018-08-07 16:32:40 +02:00 (Migrated from github.com)

lbryumx would be affected (unless we set the default to 1). It could be updated to pass in the number of confirmations that it cares about.

lbryumx would be affected (unless we set the default to 1). It could be updated to pass in the number of confirmations that it cares about.
kaykurokawa commented 2018-09-19 18:46:42 +02:00 (Migrated from github.com)

So a related motivation for this was the issue of synchronization, as well as confirm depth.

So lbryum-server, (now lbryumx, but still has same issue I believe) in order to access the claimtrie uses "pass through" commands, which makes direct queries to lbrycrd and passes it along to the client. This is in contrast to the "direct response" commands used in commands related to address balances where lbryum server responds directly to the client using its own internal state that is synchronized to lbrycrd.

This results in a synchronization problem because a) lbryum-server may not have synced yet to the latest block on lbrycrd. Thus the pass through commands and direct response commands will return inconsistent results due to being on different blocks b) lbryum-server could make multiple "pass through" commands on a single query, meaning that lbrycrd may have incremented a block in between those commands, also returning inconsistent states.

Now the minconf argument doesn't solve the issue of synchronization but a blockhash argument (already included in getnameproof) would solve the issue. Users can also implement minconf through blockhash as well.

I should also note that this method to solve synchronization may be a bit slow as we will need to roll back the claimtrie a X number of blocks. Another way to solve the synchronization issue is to store the different claimtries for X number of blocks, either within lbrycrd or within lbryum server (perhaps utilizing lbrycrd-go? I heard that it has this feature).

Probablly, this needs to be a new issue..

So a related motivation for this was the issue of synchronization, as well as confirm depth. So lbryum-server, (now lbryumx, but still has same issue I believe) in order to access the claimtrie uses "pass through" commands, which makes direct queries to lbrycrd and passes it along to the client. This is in contrast to the "direct response" commands used in commands related to address balances where lbryum server responds directly to the client using its own internal state that is synchronized to lbrycrd. This results in a synchronization problem because a) lbryum-server may not have synced yet to the latest block on lbrycrd. Thus the pass through commands and direct response commands will return inconsistent results due to being on different blocks b) lbryum-server could make multiple "pass through" commands on a single query, meaning that lbrycrd may have incremented a block in between those commands, also returning inconsistent states. Now the minconf argument doesn't solve the issue of synchronization but a blockhash argument (already included in getnameproof) would solve the issue. Users can also implement minconf through blockhash as well. I should also note that this method to solve synchronization may be a bit slow as we will need to roll back the claimtrie a X number of blocks. Another way to solve the synchronization issue is to store the different claimtries for X number of blocks, either within lbrycrd or within lbryum server (perhaps utilizing lbrycrd-go? I heard that it has this feature). Probablly, this needs to be a new issue..
BrannonKing commented 2018-09-20 01:54:13 +02:00 (Migrated from github.com)

After further discussion on this, we have decided that taking a block hash will be more effective than a minconf number. I'm going to make that change and resubmit.

After further discussion on this, we have decided that taking a block hash will be more effective than a minconf number. I'm going to make that change and resubmit.
BrannonKing commented 2018-10-31 20:53:26 +01:00 (Migrated from github.com)

Done via #189

Done via #189
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#44
No description provided.