SHA-256 (and, by extension, double SHA-256) may be less secure than SHA-512 (already provided by the hash library) truncated to 256 bits.

A couple of guys in Austria did an analysis (Tbl 6.6, Sec 3.5, Sec 4.4, Sec 5.4)

David Strauss provides some arguments for SHA-512/256

FIPS SP 800-107 (Sec 4.1, Sec 4.2 Tbl 1)

A security analysis of SHA-512/256 and SHA-512/224

None of this is to say that SHA-256 itself is insecure, just that it may not be the optimal choice, especially when a better solution would be quite easy to drop in (from a very superficial glance, at least).

Currently we only support standard addresses.

Investigate if there are any table scans being performed by SQL queries that executing during sync and if things could be improved by adding more indexes.

As a newer contributor, I have to explore the code to get an idea of what I can work on. I noticed a lot of inconsistency with code style. I am opening this issue because I'm going through and tidying up code while all the moving parts in lbry-sdk get re-worked. There is no pylint config with this package so I am assuming it should resemble the sdk, I think #58 applies in that sense. I'm mainly making docstrings use " instead of ', and set declarations uses (item,) instead of set = item and other trivial PEPs. This is not a major issue but would be nice to have. I am opening this issue with the purpose to create a PR and have the effort be known to maintainers.

• torba.orchstr8 service
  • implement
  • documentation
  • js example
• workbench
  • implement

As located here.

Currently we use automatic transaction management where every query is a transaction. We could gain significant performance improvement if we manually managed the transactions. Investigate and implement.

The extended private and public key headers do not match lbrycrd: https://github.com/lbryio/lbry/blob/master/lbrynet/extras/wallet/ledger.py#L36

What are the ramifications of this for migrated wallets and newly created ones?

Also, https://github.com/lbryio/lbryum/issues/218 was fixed in Torba - do we need to account for anything?

Calculating the total proof of work is generally a useful metric to return, and necessary to do reorgs trustlessly. The total proof of work is the summation of all the work on the chain , work for each block is defined below:

https://github.com/lbryio/lbrycrd/blob/e90d7f54cede3c1c5bfc3590351054bdc5a99480/src/chain.cpp#L114

Actually electrum doesn't even have this... I'm not even sure how that works without being exploitable.

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

switch from slow, pure Python, ecdsa library to fast cryptography library for generating addresses

orchstr8 uses a deprecated API call. The deprecation warning says: "Application.make_handler(...) is deprecated, use AppRunner API instead." orchstr8 should be refactored to either conform to aiohttp's newer features or use asyncio/socket protocol factories: https://github.com/lbryio/torba/blob/master/torba/orchstr8/service.py#L43

• implement support for detecing reorganizations and recovering
  • rewind the headers
  • undo any transactions
• unit tests for rewinding headers
• unit tests for dropping transactions that happened on removed blocks
• integration tests using generate and invalidateblock commands

how do reorgs affect files you have on disk and claims you paid for?

I believe we can raise earlier if there is some place we can check if that's happening. Worth an issue as it holds the call for way too long and sometimes the connection is back but the call is still hanging, giving the impression that its waiting the server, but its actually just stuck in limbo.