eb64d2486f
83950275eddacac56c58a7a3648ed435a5593328 qa: unit test sighash caching (Antoine Poinsot)
b221aa80a081579b8d3b460e3403f7ac0daa7139 qa: simple differential fuzzing for sighash with/without caching (Antoine Poinsot)
92af9f74d74e76681f7d98f293eab226972137b4 script: (optimization) introduce sighash midstate caching (Pieter Wuille)
8f3ddb0bccebc930836b4a6745a7cf29b41eb302 script: (refactor) prepare for introducing sighash midstate cache (Pieter Wuille)
9014d4016ad9351cb59b587541895e55f5d589cc tests: add sighash caching tests to feature_taproot (Pieter Wuille)
Pull request description:
This introduces a per-txin cache for sighash midstate computation to the script interpreter for legacy (bare), P2SH, P2WSH, and (as collateral effect, but not actually useful) P2WPKH. This reduces the impact of certain types of quadratic hashing attacks that use standard transactions. It is not known to improve the situation for attacks involving non-standard transaction attacks.
The cache works by remembering for each of the 6 sighash modes a `(scriptCode, midstate)` tuple, which gives a midstate `CSHA256` object right before the appending of the sighash type itself (to permit all 256, rather than just the 6 ones that match the modes). The midstate is only reused if the `scriptCode` matches. This works because - within a single input - only the sighash type and the `scriptCode` affect the actual sighash used.
The PR implements two different approaches:
* The initial commits introduce the caching effect always, for both consensus and relay relation validation. Despite being primarily intended for improving the situation for standard transactions only, I chose this approach as the code paths are already largely common between the two, and this approach I believe involves fewer code changes than a more targetted approach, and furthermore, it should not hurt (it may even help common multisig cases slightly).
* The final commit changes the behavior to only using the cache for non-consensus script validation. I'm open to feedback about whether adding this commit is worth it.
Functional tests are included that construct contrived cases with many sighash types (standard and non-standard ones) and `OP_CODESEPARATOR`s in all script types (including P2TR, which isn't modified by this PR).
ACKs for top commit:
achow101:
ACK 83950275eddacac56c58a7a3648ed435a5593328
dergoegge:
Code review ACK 83950275eddacac56c58a7a3648ed435a5593328
darosior:
re-ACK 83950275eddacac56c58a7a3648ed435a5593328
Tree-SHA512: 65ae8635429a4d563b19969bac8128038ac2cbe01d9c9946abd4cac3c0780974d1e8b9aae9bb83f414e5d247a59f4a18fef5b37d93ad59ed41b6f11c3fe05af4
|
||
|---|---|---|
| .github | ||
| .tx | ||
| build-aux/m4 | ||
| build_msvc | ||
| ci | ||
| contrib | ||
| depends | ||
| doc | ||
| share | ||
| src | ||
| test | ||
| .cirrus.yml | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .python-version | ||
| .style.yapf | ||
| autogen.sh | ||
| configure.ac | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| INSTALL.md | ||
| libbitcoinconsensus.pc.in | ||
| Makefile.am | ||
| README.md | ||
| REVIEWERS | ||
| SECURITY.md | ||
Elements Project blockchain platform
This is the integration and staging tree for the Elements blockchain platform, a collection of feature experiments and extensions to the Bitcoin protocol. This platform enables anyone to build their own businesses or networks pegged to Bitcoin as a sidechain or run as a standalone blockchain with arbitrary asset tokens.
Modes
Elements supports a few different pre-set chains for syncing. Note though some are intended for QA and debugging only:
- Liquid mode:
elementsd -chain=liquidv1(syncs with Liquid network) - Bitcoin mainnet mode:
elementsd -chain=main(not intended to be run for commerce) - Bitcoin testnet mode:
elementsd -chain=testnet3 - Bitcoin regtest mode:
elementsd -chain=regtest - Elements custom chains: Any other
-chain=argument. It has regtest-like default parameters that can be over-ridden by the user by a rich set of start-up options.
Confidential Assets
The latest feature in the Elements blockchain platform is Confidential Assets, the ability to issue multiple assets on a blockchain where asset identifiers and amounts are blinded yet auditable through the use of applied cryptography.
- Announcement of Confidential Assets
- Confidential Assets Whitepaper to be presented April 7th at Financial Cryptography 2017 in Malta
- Confidential Assets Tutorial
- Confidential Assets Demo
- Elements Code Tutorial covering blockchain configuration and how to use the main features.
Features of the Elements blockchain platform
Compared to Bitcoin itself, it adds the following features:
- Confidential Assets
- Confidential Transactions
- Federated Two-Way Peg
- Signed Blocks
- Additional opcodes
Previous elements that have been integrated into Bitcoin:
- Segregated Witness
- Relative Lock Time
Elements deferred for additional research and standardization:
Additional RPC commands and parameters:
The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.
License
Elements is released under the terms of the MIT license. See COPYING for more information or see http://opensource.org/licenses/MIT.
What is the Elements Project?
Elements is an open source, sidechain-capable blockchain platform. It also allows experiments to more rapidly bring technical innovation to the Bitcoin ecosystem.
Learn more on the Elements Project website
https://github.com/ElementsProject/elementsproject.github.io