search

lbryio / lbrycrd

The blockchain that provides the digital content namespace for the LBRY protocol
https://lbry.com
MIT License
2.57k stars 178 forks source link

implemented hard fork to include nonwinning claims in hash #209

Closed BrannonKing closed 5 years ago

BrannonKing commented 6 years ago

It also uses Merkle trees for hashing children and claims post-fork. This significantly reduces the output for getnameproof.

Notable things to look at:

  1. The way the tree is verified after it is loaded form disk (now using the Cache).
  2. The place in the Cache's (Dis)ConnectBlock methods where we rehash the whole tree.
  3. The use of the already-included MerkleHash and MerkleBranch methods.
  4. The names in the getnameproof data and the Proof structs.
BrannonKing commented 6 years ago

CClaimTrieCache::insertClaimIntoTrie needs to be updated to detect if there were any ordering changes.

kaykurokawa commented 5 years ago

We should clarify how the claims are ordered when hashed.

It looks to me like the winning claim would always be the first in position of the merkle tree ( that is good because it is still important to be able to prove that a claim is the winning one). It also looks like the non winning claims are sorted from highest effective amount to lowest effective amount? I would make sure that this is the case (are claims ever stored out of order ?) .

BrannonKing commented 5 years ago

For the claim sorting, the code has been adjusted to do a full, stable sort instead of heapify. The sort operator is complete and has been for a while (see CClaimValue::operator<). However, I think there is a scenario where we might end up with out-of-order claims: when loading blocks that were created before the addition of the full sort. Claims aren't re-sorted on load. We have been discussing doing this, though, as we've been considering the right way to recreate the effective amount in this same scenario (which isn't serialized at present).

BrannonKing commented 5 years ago

We've had new requirements on this. It now needs to implement all necessary support for this: https://www.notion.so/lbry/Q-A-on-RPC-results-verification-44888d23efa3475a90eec997f9bf3103 . It also needs to return the claim_sequence field in all claim RPC calls.