The blockchain that provides the digital content namespace for the LBRY protocol
Changes:
SHA256 Sums:
e7fb29da99bf4ca056c652dc9c6b0ec3f617c43a8f8de27e67d30a4d94944b01 lbrycrd-linux-1733.zip
2ce77a7d8c6d0bec33f34bba82251af59045754a4f52e992e905bec2baa8e395 lbrycrd-windows-1733.zip
9872ef2f02795830d19d4b8df85fd2b2f6530969b911f88dc7ce7a882ce4d9b0 lbrycrd-darwin-1733.zip
This release includes a major refactor to store the claim trie and other indexes in Sqlite instead of LevelDB. The build does not include any code to read LevelDB. Hence, on its first run it will require you to run with the -reindex parameter. The reindex process takes 1-2 hours.
The wallet storage remains in Berkeley DB. The new backing storage brings an advantage of allowing other tools to monitor the storage in real-time. Moreover, the trie structure that was stored in RAM previously is now fully contained in the Sqlite tables. This repairs a long-standing issue: the RAM requirement no longer increases daily. It's tuned to run at about 2GB out of the box and less if you're already caught up to the current block — half that of the current build.
A clean exit is required to fully flush the disk buffers. This will be fast when lbrycrd is caught up to the current block height as it flushes on every new block, but it could be slow if exiting during the initial block download (IBD). Be patient and wait for it.
The schema for the data can be explored by opening these files via the sqlite3 shell: ~/.lbrycrd/*.sqlite
Breaking change: The blocksdir
parameter, when utilized, now specifies the blocks directory fully rather than getting a "blocks" folder appended onto whatever was specified in the parameter. It now matches the behavior specified in the documentation for that parameter.
Wallet RPC sendtoaddress
times are still unreasonable for large wallets (aka, wallets that have grown over time through numerous sends and receives). For frequent sends we recommend the use of the sendmany
RPC call. Another workaround is to create a new wallet and forward your funds there. This works if you don't need your transaction history.
It is still expected that the v0.17.4+ builds will be marginally slower than the v0.17.3 builds because they exchange some performance for less (and more deterministic) RAM usage. Hence, this and all other v0.17.4 builds are not recommended for use on a spinning disk (an HDD).
aacd79497f41c14c8177eefcdabca068392f375f7707a8f5c8bf17cc3d2a2297 lbrycrd-darwin-1746.zip
9c902ae1b82ee52a9e3ad109c693553bfaff6c6ab18a225e9f1c327c3a395085 lbrycrd-linux-1746.zip
8e149b6eb7feaadef850744a6e19d20a4f88367f6b1a4110f4d6c839ee69890e lbrycrd-windows-1746.zip
For this release the LBRY-specific functionality was rebased onto the Bitcoin Core version 19 codebase. The previous releases were based on Bitcoin Core version 17, so we encourage you to read the changes for 18 and 19 here: bitcoin.org/en/version-history .
There are no significant changes in LBRY-specific functionality.
If you are upgrading from v17.3 or below, be sure to read through the release notes of the v17.4.6 release.
SHA256 Sums: 52ef725c391648187c112ece9a7d82af589bf2efaef57fd3d9c68e3a8a1fd2af lbrycrd-darwin-1912.zip 239574880e14dbbec663f1defb4224850801cc1910722a735c9184258ecb8d21 lbrycrd-linux-1912.zip 3b45312a05a0394f839413577e54f3eeb1f0819f1d927ba0c38*5a269ee670f36 lbrycrd-windows-1912.zip
This is a minor release with the following fixes:
SHA256 Sums:
65cd5c79c51758def40c723b532760381662c5439ae07f313761446475b73afc lbrycrd-darwin-1732.zip
7d0de93a178553a5832b6c560ceb1c270047a124b834d875a772d4dcebac9056 lbrycrd-linux-1732.zip
272bed01b1d62a51f8586c600c2be59f052236760b8f08c9b012ecf64edd726b lbrycrd-windows-1732.zip
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:
SHA256 Sums: Linux: 86805a47314395201257df0132452c392f45f080d16dd745496ed8d65bc23c89 OSX: 112eabf4ee35739cde82eb38ce71d92d522c7ee829b879030e152d3ce07e1d40 Windows: 8012ba19800cb23f288f2eff68605123d296a1796b7007971028038da8b65231
This release fixes the CLI help command. It also improves memory usage when updating from pre 0.17.2 to 0.17.2.
We have decided to enable the Segwit features in conjunction with the upcoming hard fork (instead of using BIP9). They are still disabled in this build.
Linux: e11605cb1ac4916b840d22cfc761838ee0b502e6f66a454a1fc53dee96f3720d Windows: ecf9b4857535375801866b8bc78f467083bd3bbb0c76338af277a49d67d80310 Darwin: 0f5c6daf3a41f73c8146de721e19b4d3ef292391d32c82473028f8fbe1386aff
This release focuses on reducing the RAM used by the claim trie data structure. Details on the approach are found here: https://lbry.com/news/claim-trie-memory-reduction .
This release builds on the effort to rebase lbrycrd on bitcoin 0.17. We've previously published an initial build of that with detailed notes here: https://github.com/lbryio/lbrycrd/releases/tag/v0.17.1.0 . Some of those changes are included in the list below.
-deprecatedrpc=accounts
and -deprecatedrpc=validateaddress
.Darwin: 825af0c416e6c3c8bb4c70ac519a0c7af1fc40422fd83e586783f34104d5ccd1 Linux: ab0ef3da0cbb46b94730707f7fd7a78694046648d81c134deb675060491a126e Windows: c838f037ee7650f88479c5565d647207ed6cceb5d7693734c89d4b5f953f8664
This is a pre-release of lbrycrd, which is now based upon the Bitcoin 0.17.0 codebase. Unless we find some showstoppers, we will release another build next week with significant RAM usage reductions. This build does not have the RAM reductions, and requires over 5GB of RAM for a full blockchain sync. (Restarting after the you are up to date on the current block will significantly reduce RAM usage.)
Linux: 1bafac6dbc9b3d3cf64be1cdb4fa4c3a2c48153dccb86a94d731e2818bce51e9 Windows: 9ac3d143a3da8ebe5fc69f7be4dd512e466b64b8dc56b0913e10698047c0c83d Darwin: 48632c89e7a9015dbb02cf9ba958c748a912b8461072388b1435e38a9cfc0872
Fixed: the claim trie file cache was incorrectly set to a value too small, thus overburdening the disk. The cache has been increased to 20MB in this release. With this repaired the chain will synchronize faster than before, and there should be slightly less memory fragmentation.
New Feature: the REST endpoint for blocks now supports querying blocks by chain height.
SHA256 Sums: Linux: 63fe910597dfff07445929fff65823a2ec6badd045c5330637e64d1810582526 OSX: df331f9e25f1fe501e12d47f6fabf969e7474432d80c067ecdcab9b24294213a Windows: 6301372b1a8e08fd0c41cd534fd6ec16a72961139d15a4b58db4ffc3fb6ca53c
This release incorporates a significant change to the way that claim names are compared. We now use case-insensitive comparison. It will take effect at mainnet height 539940 and on testnet height 993380. Notes on this change follow:
The only other change in this release is that testnet will stop resetting to minimum difficulty at block 1100000.
Known issue: the normalized_name field returned in RPC getclaimsforname does not actually contain the normalized name until after the fork height applies.
SHA256 of Zips: Linux: 38d36ea3f746235fdffe0fb4b9e035a29fb00e79d9c852fcc11b4167acdaafc1 OSX: b7d495ae83b7b867101346d3ff182a31157daba793707ec5ba9d64d2e2002718 Windows: 344de48aac734d6224585ef9849af759a36ca466b16cc992f24084a8a86d504b