There are a few layers of bullshit to this PR. First, there is the fact that it adds a functional test gated on a new config flag which is disabled by default, so it actually adds broken code with no tests, waiting to ruin your day 520 PRs later when #21935 enables the broken test. Second, the test appears to be superficially nonsensical because it generates two transactions from different wallets and tries to compare them for byte-for-byte equality, which doesn't make sense (at least) because change outputs are randomly located...so something fishy is going on. Of course, in Elements the transactions are *not* equal half the time because the outputs are permuted, which may have let me quickly figure out the issue, except... Third, there is a red herring of a bug where the two transactions have slightly different feerates. This turns out to be caused by CWallet::CalculateMaximumSignedTxSize using differently sized dummy transactions depending on whether watchonly outputs are included (this fact is conveniently disguised by #17211 slightly changing this logic; this is an unmerged PR in Core that Elements has a backport of an old version of). And the two wallets have different watchonly settings. A sub-red-herring is the fact that this bug results in a discrepancy of 0.25 vbytes, so it does not appear in Core but does appear in Elements (there is a 3/16 probability that we should be so unlucky... we are). But this is all irrelevant, because... Fourth, this test is actually super bullshit. The way it works is by constructing a PSBT legitimately, saving this to disk, then re-"signs" using the external signer interface by using a mock signer that COMPLETELY REPLACES THE TRANSACTION UNDER CONSTRUCTION. So it doesn't matter what the fee output looks like and it doesn't matter what the order of the outputs. Core does not detect this malfeasance and neither does Elements. For some reason, Core has a functional test that explicitly checks that you can do this even though it is insane and it is hard to think of non-malicious reasons to do it. Fifth, while Elements fails to detect that its external signer is actually changing the transaction out from under it, it DOES assume that this won't happen. In CWallet::SignPSBT it blithely un-replaces the transaction, which undermines the functional test. Sixth, the original PR where this test was introduced has comments locked, so anyone who spent six hours reverse-engineering this idiotic broken test, and is still feeling charitable enough to discuss it with the Core developors, can go pound sand. Anyway, just disabled the broken test and move on with our lives. |
||
|---|---|---|
| .. | ||
| man | ||
| release-notes | ||
| .gitignore | ||
| assets-attribution.md | ||
| benchmarking.md | ||
| bips.md | ||
| bitcoin-conf.md | ||
| bitcoin_logo_doxygen.png | ||
| build-freebsd.md | ||
| build-netbsd.md | ||
| build-openbsd.md | ||
| build-osx.md | ||
| build-unix.md | ||
| build-windows.md | ||
| dependencies.md | ||
| descriptors.md | ||
| developer-notes.md | ||
| dnsseed-policy.md | ||
| Doxyfile.in | ||
| elements-upstream-tracking.md | ||
| external-signer.md | ||
| files.md | ||
| fuzzing.md | ||
| gitian-building.md | ||
| guix.md | ||
| init.md | ||
| JSON-RPC-interface.md | ||
| multiprocess.md | ||
| productivity.md | ||
| psbt.md | ||
| pset.mediawiki | ||
| README.md | ||
| README_doxygen.md | ||
| README_windows.txt | ||
| reduce-memory.md | ||
| reduce-traffic.md | ||
| release-notes-18077.md | ||
| release-notes-19776.md | ||
| release-notes.md | ||
| release-process.md | ||
| REST-interface.md | ||
| shared-libraries.md | ||
| tor.md | ||
| translation_process.md | ||
| translation_strings_policy.md | ||
| zmq.md | ||
Bitcoin Core
Setup
Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires a few hundred gigabytes of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.
To download Bitcoin Core, visit bitcoincore.org.
Running
The following are some helpful notes on how to run Bitcoin Core on your native platform.
Unix
Unpack the files into a directory and run:
bin/elementsd(headless)bin/elements-qt(GUI)
Windows
Unpack the files into a directory, and then run elements-qt.exe.
macOS
Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
Need Help?
- See the documentation at the Bitcoin Wiki for help and more information.
- Ask for help on #bitcoin on Freenode. If you don't have an IRC client, use webchat here.
- Ask for help on the BitcoinTalk forums, in the Technical Support board.
Building
The following are developer notes on how to build Bitcoin Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
- Dependencies
- macOS Build Notes
- Unix Build Notes
- Windows Build Notes
- FreeBSD Build Notes
- OpenBSD Build Notes
- NetBSD Build Notes
- Gitian Building Guide (External Link)
Development
The Bitcoin repo's root README contains relevant information on the development process and automated testing.
- Developer Notes
- Productivity Notes
- Release Notes
- Release Process
- Source Code Documentation (External Link)
- Translation Process
- Translation Strings Policy
- JSON-RPC Interface
- Unauthenticated REST Interface
- Shared Libraries
- BIPS
- Dnsseed Policy
- Benchmarking
Resources
- Discuss on the BitcoinTalk forums, in the Development & Technical Discussion board.
- Discuss project-specific development on #bitcoin-core-dev on Freenode. If you don't have an IRC client, use webchat here.
- Discuss general Bitcoin development on #bitcoin-dev on Freenode. If you don't have an IRC client, use webchat here.
Miscellaneous
- Assets Attribution
- bitcoin.conf Configuration File
- Files
- Fuzz-testing
- Reduce Memory
- Reduce Traffic
- Tor Support
- Init Scripts (systemd/upstart/openrc)
- ZMQ
- PSBT support
License
Distributed under the MIT software license.