v0.17.3.3 - small update

Changes:

1. Added more seed nodes.
2. Reduced wallet LSN reset calls; use the backup command or shut down the daemon before moving wallets to another machine. (Backported from v0.17.4.)
3. Updated the build process to match v0.17.4. This should make it more compatible with older GLIB.
4. Updated the minimum chain work and tweaked cache numbers.

SHA256 Sums:

e7fb29da99bf4ca056c652dc9c6b0ec3f617c43a8f8de27e67d30a4d94944b01 lbrycrd-linux-1733.zip
2ce77a7d8c6d0bec33f34bba82251af59045754a4f52e992e905bec2baa8e395 lbrycrd-windows-1733.zip
9872ef2f02795830d19d4b8df85fd2b2f6530969b911f88dc7ce7a882ce4d9b0 lbrycrd-darwin-1733.zip

v0.17.4.6 - SQLite-based trie and index storage

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

Notes

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).

Changelog Summary

1. The RPC calls dealing with claim sequence now use the original block creation height rather than the last update height for their sequence comparisons.
2. Much of the LBRY-specific code has been isolated into its own library.
3. Socket selection was changed to use the poll mechanism on Linux.
4. The CLI help for getclaimproofbybid was repaired.
5. lsn_reset is no longer triggered as part of every wallet flush. Run the wallet backup RPC command to trigger it.
6. The wallet auto-flush period was changed from half a second to a full second.
7. Regtest block generation performance was improved.
8. Linux builds are no longer a mix of Clang and GCC. GCC 7 is now used instead of GCC 5.
9. Reindex will be continued on restart (after a clean shutdown), and the corruption that was happening with that has been repaired.
10. A maxblocksize parameter was added to aid in testing.
11. Block generation RPC calls are no longer allowed during initial block download (or reindexing).
12. Database flushes will now trigger before the ZeroMQ events for the new block trigger.
13. We now only attempt to disk sync for 4 seconds instead of 20.
14. The size estimate from RPC gettxoutsetinfo is now much more reasonable.
15. The testnet chain was reset

SHA256 Sums

aacd79497f41c14c8177eefcdabca068392f375f7707a8f5c8bf17cc3d2a2297  lbrycrd-darwin-1746.zip
9c902ae1b82ee52a9e3ad109c693553bfaff6c6ab18a225e9f1c327c3a395085  lbrycrd-linux-1746.zip
8e149b6eb7feaadef850744a6e19d20a4f88367f6b1a4110f4d6c839ee69890e  lbrycrd-windows-1746.zip

v0.19.1.2 - Bitcoin Core rebase

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.

• TxIndex was reworked to more closely match Bitcoin Core, including the creation of it on a background thread. It is still on by default but now uses its own Sqlite DB file.
• The recent fixes that went into the v17.4 branch for handling block 745383 and the testnet reset.
• The block filter handling has been repaired (see #383) and is now all in the filter's database file rather than using flat files. If you ran v19.1.1 and enabled the block filters, you will need to remove the existing block filter folder before running this build, which is typically ~/.lbrycrd/filter/* .
• Repaired issues #381 and #382 .

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

v0.17.3.2 - getblocktemplate & max TX fee tweaks

This is a minor release with the following fixes:

1. The getblocktemplate RPC method is modified to require the segwit capability flag after segwit goes live on or near December 11. This is to help mining pool hosts know when to enable their pool software's segwit support.
2. The code to flush to disk after new blocks no longer applies to regtest. (It was slowing the SDK unit tests.)
3. lbrycrd will crash when names registered on block 539939 (the normalization fork) expire in 7+ years -- fixed in this release.
4. The default max TX fee was increased from 0.1 LBC to 0.5 LBC.
5. The "submit/coinbase" flag was removed from the reported getblocktemplate capabilities. The submitblock RPC has never supported this.
6. When the node starts the current debug.log file will be renamed (and overwrite) debug.log.old. This is different from the old behavior that always shrank the debug.log file to 10MB on startup.

SHA256 Sums:

65cd5c79c51758def40c723b532760381662c5439ae07f313761446475b73afc  lbrycrd-darwin-1732.zip
7d0de93a178553a5832b6c560ceb1c270047a124b834d875a772d4dcebac9056  lbrycrd-linux-1732.zip
272bed01b1d62a51f8586c600c2be59f052236760b8f08c9b012ecf64edd726b  lbrycrd-windows-1732.zip

v0.17.3.1 - HF1910: all claims in the hash

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

v0.17.2.1 - Minor fixes to 0.17.2

Changes:

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.

SHA256 Sums:

Linux: e11605cb1ac4916b840d22cfc761838ee0b502e6f66a454a1fc53dee96f3720d
Windows: ecf9b4857535375801866b8bc78f467083bd3bbb0c76338af277a49d67d80310
Darwin: 0f5c6daf3a41f73c8146de721e19b4d3ef292391d32c82473028f8fbe1386aff

v0.17.2.0 - Memory Improvements Release

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.

Breaking changes:

1. RPC methods now return UTF-8 data. Claim names that cannot be represented in UTF-8 will utilize standard JSON escape sequences. Claim values (aka, metadata) are returned as hexadecimal strings. They will not utilize escape characters as they have in the past.
2. RPC method getclaimsintrie is now deprecated and getclaimtrie is removed. Use getnamesintrie instead.
3. There is a one-time upgrade of the existing data when running this build. Copy your ~/.lbrycrd/ folder first should you need to go back.
4. Those using Yiimp or other traditional miners will need to run the daemon with -deprecatedrpc=accounts and -deprecatedrpc=validateaddress.

Other changes:

1. Everything that was added to bitcoin after 0.12 through 0.17! See bitcoin.org/en/version-history . This includes the removal of built-in CPU mining.
2. Reproducible_build.sh is now build.sh, and utilizes the "depends" build system.
3. An issue where names with overlapping characters would match each other was repaired (Kenya vs Kenyavshak).
4. getblocktemplate now supports coinbasetxn for local solo mining.
5. These issues were fixed: #158, #108, #138, #106, #256, #261, #282, #246, #277, #133
6. The recent pre-release contains an issue where the validation hash may not match the mined hash. This was repaired in this build.

SHA256 sums:

Darwin: 825af0c416e6c3c8bb4c70ac519a0c7af1fc40422fd83e586783f34104d5ccd1
Linux: ab0ef3da0cbb46b94730707f7fd7a78694046648d81c134deb675060491a126e
Windows: c838f037ee7650f88479c5565d647207ed6cceb5d7693734c89d4b5f953f8664

v0.17.1.0 - Rebased on 0.17

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.)

Breaking changes:

1. RPC methods now return UTF-8 data. Claim names that cannot be represented in UTF-8 will utilize standard JSON escape sequences.
2. Claim values (aka, metadata) is returned has hexadecimal strings. They will not utilize escape characters as they have in the past.
3. RPC method getclaimsintrie is now deprecated and getclaimtrie is removed. Use getnamesintrie instead.
4. Issue #119 was repaired.
5. There is a one-time upgrade of the existing data when running this build. Copy your ~/.lbrycrd/ folder first should you need to go back.

Other changes:

1. Everything that was added to bitcoin after 0.12 through 0.17! See https://bitcoin.org/en/version-history . This includes the removal of built-in CPU mining.
2. Reproducible_build.sh is now build.sh, and utilizes the "depends" build system.
3. Unicode updated to v11 to match Python3.
4. The Windows build is now 64bit.

Known issue:

1. RPC methods that query for names may return longer names that have the same characters. This is fixed in the coming build.
2. Claim OPs may not play well appended with Segwit transactions, and the other parts of the LBRY stack definitely won't play well with them.
3. Blocks that include supports followed by updates for a given name may fail to verify in the initial verification stage. Block 567082 is the most recent known block with this issue. This is fixed in the coming build.

SHA256 values:

Linux: 1bafac6dbc9b3d3cf64be1cdb4fa4c3a2c48153dccb86a94d731e2818bce51e9
Windows: 9ac3d143a3da8ebe5fc69f7be4dd512e466b64b8dc56b0913e10698047c0c83d
Darwin: 48632c89e7a9015dbb02cf9ba958c748a912b8461072388b1435e38a9cfc0872

v0.12.4.1

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

v0.12.4.0

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:

• For determining the winning claim at a given name, we use a case-insensitive and unicode-normalized comparison. This ensures that similar accent marks compete and that differing case compete.
• UTF8 input is supported. Non-conformant input is also supported. Thus malformed or partial UTF8 will still get recorded. (And those exact bytes will have to be used to look it up.)
• The exact bytes that came in with a claim are preserved. You can see those exact bytes in the name field that is returned by these RPC methods: getclaimsintrie, getvalueforname, getclaimsforname, getclaimbyid. We hope these will be rendered as the correct address; we want the consumers to see the exact casing chosen by the publisher.
• The name field on the UPDATE op can be used to change casing. The SUPPORT op is no longer case sensitive (but relies heavily on the claimId).
• The name input field for these RPC methods is not case sensitive: getvalueforname, getclaimsforname, getnameproof.
• There is a new RPC command, checknormalization, that returns the normalized, lower-cased form of the input.
• The getclaimsintrie results will have a name field added inside the claim object, which will then contain the original name. The outer name field will become normalized_name. This is a breaking change and will happen with the release, not fork height.

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