Include last block hash on claimtrie RPC results #130

New issue

Closed

opened 2018-04-27 07:23:33 +02:00 by shyba · 4 comments

shyba commented

2018-04-27 07:23:33 +02:00

(Migrated from github.com)

Use cases for other projects getting this information:

lbrynet/lbryum asks for claims in a name. That currently doesn't accept a block hash parameter neither returns the block hash itself and it's not yet possible to use a block hash to query a previous claimtrie state at arbitrary blocks, specially if the hash is from a fork. So, the easiest way to ensure consistency is to return the hash and compare with the database tip.
lbryum-server/lbryumx is querying and the block tip changes right before the query or during a large query. It's useful to know that as this wont match the database tip and could require information that's not in fetched yet or to discard previous results to get consistency.
worst case: lbrynet specifies a block hash for URI resolutions, we get a proof for that tip but all the other info comes from the current tip. It's hard to know when that happened and having mixed information can easily bring weird results such as a proof on a block tip that has no claim information (the claim got abandoned on the next blocks).

Modifications on lbrycrd code:

if a claimtrie RPC command accepts an optional block hash parameter, include it in the response if no hash is given as parameter.
if a claimtrie RPC command doesn't accept block hash paramter, include it in the response so the client knows the tip at which the query occurred.

Both lbryumx and lbryum/lbrynet could benefit from knowing which block hash the response came from, so it can check if that matches the current database state. It should also make it easier to check if the blockchain tip changed during large queries. Use cases for other projects getting this information: * lbrynet/lbryum asks for claims in a name. That currently doesn't accept a block hash parameter neither returns the block hash itself and it's not yet possible to use a block hash to query a previous claimtrie state at arbitrary blocks, specially if the hash is from a fork. So, the easiest way to ensure consistency is to return the hash and compare with the database tip. * lbryum-server/lbryumx is querying and the block tip changes right before the query or during a large query. It's useful to know that as this wont match the database tip and could require information that's not in fetched yet or to discard previous results to get consistency. * worst case: lbrynet specifies a block hash for URI resolutions, we get a proof for that tip but all the other info comes from the current tip. It's hard to know when that happened and having mixed information can easily bring weird results such as a proof on a block tip that has no claim information (the claim got abandoned on the next blocks). Modifications on lbrycrd code: * if a claimtrie RPC command accepts an optional block hash parameter, include it in the response if no hash is given as parameter. * if a claimtrie RPC command doesn't accept block hash paramter, include it in the response so the client knows the tip at which the query occurred.

kaykurokawa commented

2018-09-19 23:15:39 +02:00

(Migrated from github.com)

The code required to implement minconf is nearly identical to the code required to implement blockhash as an argument. And blockhash can be used to implement minconf (look up the block hash on the particular height), so I believe #189 should be modified to use blockhash.

This is a related issue https://github.com/lbryio/lbrycrd/issues/44, and PR: https://github.com/lbryio/lbrycrd/pull/189 The code required to implement minconf is nearly identical to the code required to implement blockhash as an argument. And blockhash can be used to implement minconf (look up the block hash on the particular height), so I believe #189 should be modified to use blockhash.

BrannonKing commented

2018-09-20 01:53:10 +02:00

(Migrated from github.com)

Thanks for pointing out the connection. I concur on using blockhash for #44. I will make that change and resubmit #189. I will also add this (return the block hash) into #189 as I think it would be trivial. My current plan is to get a working implementation on #107 first, though, unless somebody wants to argue for this as a higher priority.

BrannonKing commented

2018-10-05 06:07:47 +02:00

(Migrated from github.com)

We've adjusted #44 to make the RPC methods take an optional blockhash. It will return an error if the blockhash cannot be accommodated. Is that sufficient to achieve this? Or is there value in returning a blockhash field for the case when you want the current tip? (Which would be a rare situation when the API is used by a higher-level entity.)

kaykurokawa commented

2018-10-31 18:29:42 +01:00

(Migrated from github.com)

@shyba confirmed that it #44 will fix this

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#130

No description provided.