LBRYcrd Files

LBRY is pleased to announce the release of lbrycrd 17.3. This release includes a hard-fork (labeled HF1910) to address a shortcoming in the previous block computation. The hardfork will occur at block height 658300, which we presume will happen on or near October 30th, 2019. Please upgrade well before then! Presently only the winning claim is included in the claimtrie hash (and thence in the block hash). This hard fork changes the hash computation to include all claims for a given name in the hash, thus allowing provable claim existence for non-winning claims, which is not possible presently. Note: the actual hard-fork processing uses quite a bit of RAM; we recommend restarting lbrycrd shortly after the fork takes place to reduce memory usage. (Issue [#107])

Additional query and proof methods have been added: getclaimbybid, getclaimbyseq, getclaimproofbybid, getclaimproofbyseq. After the fork, the data returned from the proof methods will be different. The "pairs" field represents an actual Merkle tree. Those using the proof methods will need to adjust to utilize the "pair" data. "odd" means that the data being combined into the hash goes on the right. Seek help with this if necessary.

As part of the above hardfork, an optional metadata field on supports has been added. After the fork you will be able to put a third data parameter on the OP_SUPPORT_CLAIM. The supportclaim RPC was updated accordingly. (Issue [#272])

The next significant change is the enabling of Segwit support. This will not use Bitcoin's BIP9 process. Instead, it will enable with hard fork timing on block 680770, targeting December 11th, 2019. Existing transaction forms will all continue to work as they do presently.

Some work was done to cap the RAM that lbrycrd uses. This was later removed from this release, as we have a better implementation coming in the next release and didn't want to force you to reindex on both. In the meantime, we've added a "-memfile" parameter that you can use to force claimtrie allocations to disk (via mmap). This is useful for scenarios of 4GB of RAM or less. We recommend that you set it to 6 or more (and ensure that you have 6GB of disk space to spare). Another thing you might consider is preloading tcmalloc, especially scenarios of 4GB or less on Linux, as it is better at freeing unused memory than the default glib allocator. We also continue to recommend that you restart lbrycrd after a full sync-to-current. (Issue [#166])

The claimtrie RPC methods have undergone a breaking change in order to make the field names identical among all methods. Namely: txid → txIdeffective value → effectiveValue nEffectiveValue → effectiveValue valid at height → validAtHeight nValidAtHeight → validAtHeight nHeight → height nLastTakeoverHeight → lastTakeoverHeight supports without claims → supportsWithoutClaims normalized_name → normalizedName nOut → n is controlling → isControlling in queue → inQueue in support map → inSupportMap blocks to valid → blocksToValid in claim trie → inClaimTrie

Other notable changes in this release: 1. LevelDB mmap'd files reduced to 400 (for a total of 800MB of RAM). 2. An error with the fee calculation in the claimname RPC was repaired. 3. Added stake totals to the getwalletinfo RPC. 4. getrawtransaction now includes a "subtype" field that states the type of transaction used in the suffix of a claim -- all P2PKH at the moment. 5. Minimal data is no longer verified on claims. (Issue [#242]) 6. The dust relay fee was moved from 3k to 1k sats to match previous behavior. (Issue [#307]) 7. We now flush to disk on every block once we are caught up to current. (Issue [#309]) 8. The getclaimsforname RPC now returns names and supports that are not yet active and a "pending effective amount" -- the effective amount for the time after all known inactives become active. (Issue [#203]) 9. Moved the claim logging into its own category "claims", which is off by default now. 10. Time-locked P2SH can now be signed with the built-in wallet. 11. An RPC method named getchangesinblock was added to allow you to see what came out of the activation queues on a given block. 12. Other minor issues addressed: [#92], [#104], [#196], [#268], [#287], [#293], [#306], [#310], [#311]

SHA256 Sums: Linux: 86805a47314395201257df0132452c392f45f080d16dd745496ed8d65bc23c89 OSX: 112eabf4ee35739cde82eb38ce71d92d522c7ee829b879030e152d3ce07e1d40 Windows: 8012ba19800cb23f288f2eff68605123d296a1796b7007971028038da8b65231