Bitcoin Core integration/staging tree

Overview

Bitcoin Core integration/staging tree

https://bitcoincore.org

For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.

Further information about Bitcoin Core is available in the doc folder.

What is Bitcoin?

Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

For more information read the original Bitcoin whitepaper.

License

Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be completely stable. Tags are created regularly from release branches to indicate new official, stable release versions of Bitcoin Core.

The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

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.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.

Issues
  • BIP-68: Mempool-only sequence number constraint verification

    BIP-68: Mempool-only sequence number constraint verification

    Essentially enforces sequence numbers as a relative lock-time as an IsStandard() rule to make it easy to test applications using it; blocks containing transactions with invalid sequence numbers given the age of their inputs per BIP 68 are still accepted.

    This pull-req is not a soft-fork nor does it contain any code to start that process.

    This pull request builds on top of #6177.

    Background: BIP 68, Consensus-enforced transaction replacement signalled via sequence numbers

    Feature Mempool 
    opened by maaku 171
  • Add a getutxos command to the p2p protocol

    Add a getutxos command to the p2p protocol

    Introduction

    The getutxo command allows querying of the UTXO set given a set of of outpoints. It has a simple implementation and the results are not authenticated in any way. Despite this, there are times when it is a useful capability to have. I believe @jgarzik also has a use case for this, though I don't know what it is.

    As a motivating example I present Lighthouse, an app I'm writing that implements assurance contracts:

    http://blog.vinumeris.com/2014/05/17/lighthouse/

    Lighthouse works by collecting pledges, which contain an invalid transaction signed with SIGHASH_ANYONECANPAY. Once sufficient pledges are collected to make the combination valid, we say the contract is complete and it can be broadcast onto the network, spending the pledged outputs. Before that occurs however, a pledge can be revoked and the pledged money redeemed by double spending the pledged output. For instance you might want to do this if it becomes clear not enough people care about the assurance contract for it to reach its goal in a timely manner, or if you simply need the money back due to some kind of cashflow crunch.

    It is convenient to be able to see when a pledge has been revoked, so the user interface can be updated, and so when the final contract is created revoked pledges can be left out. For this purpose "getutxos" is used.

    Protocol

    The getutxos message takes a boolean which controls whether outputs in the memory pool are considered, and a vector of COutPoint structures. It returns a bitmap with the same number of bits as outputs specified rounded up to the nearest 8 bits, and then a list of CTxOut structures, one for each set bit in the bitmap. The bitmap encodes whether the UTXO was found (i.e. is indeed unspent).

    Authentication

    The results of getutxos is not authenticated. This is because the obvious way to do this requires the work maaku has been doing on UTXO commitments to be merged, activated by default, miners to upgrade and a forking change made to enforce their accuracy. All this is a big project that may or may not ever come to fruition.

    For the Lighthouse security model however, this doesn't matter much. The reason is that the pledge transactions you're getting (which may be malicious) don't come from the P2P network. They come in the form of files either from a simple rendezvous server, or e.g. a shared folder or email attachments. The people sending these files have no way to influence the choice of peers made by the app. Once the outputs are returned, they are used to check the signatures on the pledge, thus verifying that the pledge spends the UTXO returned by the P2P network.

    So we can be attacked in the following ways:

    • The pledge may be attempting to pledge non-existent outputs, but this will be detected if the majority of peers are honest.
    • The peers may be malicious and return a wrong or bogus output, but this will be detected when the signature is checked, except for the value (!) but we want to fix this by including the value into the sighash at some point anyway because we need it to make the TREZOR efficient/faster.
    • The peers may bogusly claim no such UTXO exists when it does, but this would result in the pledge being seen as invalid. When the project creator asks the pledgor why they revoked their money, and learns that in fact they never did, the bogus peers will be detected. No money is at risk as the pledges cannot be spent.
    • If the pledgor AND all the peers collaborate (i.e. the pledgor controls your internet connection) then they can make you believe you have a valid pledge when you don't. This would result in the app getting "jammed" and attempting to close an uncloseable contract. No money is at risk and the user will eventually wonder why their contract is not confirming. Once they get to a working internet connection the subterfuge will be discovered.

    There is a final issue: the answer to getutxos can of course change the instant the result is generated, thus leading you to construct an uncloseable transaction if the process of revocation races with the construction. The app can detect this by watching for either a reject message, or an inv requesting one of the inputs that is supposed to be in the UTXO set (i.e. the remote peer thinks it's an orphan). This can then cause the app to re-request the UTXO set and drop the raced pledge.

    In practice I do not anticipate such attacks are likely to occur, as they're complicated to pull off and it's not obvious what the gain is.

    There may be other apps that wish to use getutxos, with different security models. They may find this useful despite the lack of UTXO commitments, and the fact that the answer can change a moment later, if:

    • They are connecting to a trusted peer, i.e. localhost.
    • They trust their internet connection and peer selection, i.e. because they don't believe their datacenter or ISP will commit financial fraud against them, or they are tunnelling via endpoints they trust like a randomly chosen Tor exit.
    • They are not using the response for anything important or worth attacking, like some kind of visualisation.

    Upgrade

    If enforced UTXO commitments are added to the block chain in future, it would make sense to rev the P2P protocol to add the proofs (merkle branches) to the response.

    Testing

    I attempted to write unit tests for this, but Core has no infrastructure for building test chains .... the miner_tests.cpp code does it but at the cost of not allowing any other unit test to do so, as it doesn't reset or clean up the global state afterwards! I tried to fix this and ended up down a giant rabbit hole.

    So instead I've tested it with a local test app I wrote, which also exercises the client side part in bitcoinj.

    BIP

    If the code is ACKd then I will write a short BIP explaining the new message.

    Philosophy

    On IRC I have discussed this patch a little bit before. One objection that was raised is that we shouldn't add anything to the P2P protocol unless it's unattackable, because otherwise it's a sharp knife that people might use to cut themselves.

    I personally disagree with this notion for the following reasons.

    Firstly, many parts of the P2P protocol are not completely unattackable: malicious remote nodes can withhold broadcast transactions, invent fictional ones (you'd think they're orphans), miss out Bloom filter responses, send addr messages for IP's that were never announced, etc. We shouldn't hold new messages to a standard existing messages don't meet.

    Secondly, even with UTXO commitments in the block chain, given the sick state of mining this only requires a collaboration of two people to undo, although that failure would be publicly detectable which is at least something. But anyway, there's a clean upgrade path if/when UTXO authentication becomes available.

    Thirdly, we have a valid use case that's actually implemented. This isn't some academic pie in the sky project.

    Finally, Bitcoin is already the sharpest knife imaginable. I don't think we should start rejecting useful features on the grounds that someone else might screw up with them.

    If the above analysis ends up not holding for some reason, and people do get attacked due to the lack of authentication, then Lighthouse and other apps can always fall back to connecting to trusted nodes (perhaps over SSL). But I would like to optimistically assume success up front and see what happens, than pessimistically assume the worst and centralise things up front.

    P2P 
    opened by mikehearn 163
  • Treat dust outputs as non-standard, un-hardcode TX_FEE constants

    Treat dust outputs as non-standard, un-hardcode TX_FEE constants

    This is a quick, safe fix for transaction fee handling. A riskier, more complicated fix still needs to happen, but will take more time to code/test/etc.

    Two motivations for this pull:

    First, to discourage people from bloating users' wallets and the UTXO set with tiny outputs.

    This pull defines 'uneconomic dust' as 54.3 uBTC (5430 satoshis, about $0.007 at current prices), and treats any transaction with outputs less than 5430 satoshis as non-standard (won't be relayed, won't be mined). 5430 satoshis is derived from the cost (in fees) to spend a TxOut/TxIn. See https://people.xiph.org/~greg/txouts2.png for proportion of recent outputs this will (eventually) affect.

    Second, we have no idea what will happen to Bitcoin prices or transaction volume / competition for space in blocks. So this patch lets users and miners specify the minimum transaction fees at startup, using the -mintxfee / -mintxrelayfee options (which I'm intentionally leaving undocumented for now). The dust/nonstandard test is based on the -mintxrelayfee.

    Qt and RPC both now tell the user why CreateTransaction fails, if it fails; Qt error reporting is a little wonky (try to send one satoshi, and you get two modal dialog boxes, one after the other; I don't care enough to try to fix that).

    Note: I spent several hours trying, and failing, to create unit tests for this patch; CWallet::fFileBacked is ignored by several of the wallet routines used by CWallet::CreateNewTransaction. In the end, I decided thatrefactoring CWallet to support unit testing would be much more extensive and riskier than these changes.

    opened by gavinandresen 134
  • ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large

    ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large

    Client info

    2015-01-15 18:15:21 Bitcoin version v0.10.99.0-4f73a8f-dirty (2015-01-09 20:21:19 -0800) 2015-01-15 18:15:21 Using OpenSSL version OpenSSL 1.0.1f 6 Jan 2014 2015-01-15 18:15:21 Using BerkeleyDB version Berkeley DB 5.3.28: (September 9, 2013) 2015-01-15 18:15:21 Default data directory /home/fredrik/.bitcoin 2015-01-15 18:15:21 Using data directory /home/fredrik/.bitcoin 2015-01-15 18:15:21 Using config file /home/fredrik/.bitcoin/bitcoin.conf 2015-01-15 18:15:21 Using at most 200 connections (1024 file descriptors available) 2015-01-15 18:15:21 Using 0 threads for script verification 2015-01-15 18:15:21 Binding RPC on address ::1 port 8332 (IPv4+IPv6 bind any: 0) 2015-01-15 18:15:21 Binding RPC on address 127.0.0.1 port 8332 (IPv4+IPv6 bind any: 0) 2015-01-15 18:15:21 Using wallet wallet.dat 2015-01-15 18:15:21 init message: Verifying wallet... 2015-01-15 18:15:21 CDBEnv::Open : LogDir=/home/fredrik/.bitcoin/database ErrorFile=/home/fredrik/.bitcoin/db.log 2015-01-15 18:15:21 Bound to [::]:8333 2015-01-15 18:15:21 Bound to 0.0.0.0:8333 2015-01-15 18:15:21 init message: Loading block index... 2015-01-15 18:15:21 Opening LevelDB in /home/fredrik/.bitcoin/blocks/index 2015-01-15 18:15:22 Opened LevelDB successfully 2015-01-15 18:15:22 Opening LevelDB in /home/fredrik/.bitcoin/chainstate 2015-01-15 18:15:28 Opened LevelDB successfully 2015-01-15 18:15:32 LoadBlockIndexDB: last block file = 218 2015-01-15 18:15:32 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=274, size=115501816, heights=338812...339085, time=2015-01-13...2015-01-15) 2015-01-15 18:15:32 Checking all blk files are present... 2015-01-15 18:15:32 LoadBlockIndexDB(): transaction index disabled 2015-01-15 18:15:32 LoadBlockIndexDB(): hashBestChain=0000000000000000188de542fd76b1676c4be6c380b39ddea119358c290cebd7 height=339085 date=2015-01-15 18:07:14 progress=0.999987 2015-01-15 18:15:32 init message: Verifying blocks... 2015-01-15 18:15:32 Verifying last 288 blocks at level 3

    log before crash

    2015-01-13 22:15:27 UpdateTip: new best=0000000000000000159e7d66c954312bccb5f12de808f2991b3859205665c442 height=338819 log2_work=81.997891 tx=56658614 date=2015-01-13 22:14:41 progress=0.999999 cache=6969 2015-01-13 22:15:58 ResendWalletTransactions() 2015-01-13 22:17:06 receive version message: /Satoshi:0.9.2/opennodes.org:0.1/: version 70002, blocks=338819, us=84.215.171.162:8333, peer=2855 2015-01-13 22:17:25 receive version message: /libbitcoin:2.0/: version 60000, blocks=0, us=10.0.0.1:8333, peer=2856 2015-01-13 22:17:25 Added time data, samples 200, offset -5 (+0 minutes) 2015-01-13 22:18:06 socket recv error Connection reset by peer (104) 2015-01-13 22:18:13 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=84.215.171.162:8333, peer=2857 2015-01-13 22:18:31 receive version message: /getaddr.bitnodes.io:0.1/: version 70002, blocks=338818, us=84.215.171.162:8333, peer=2858 2015-01-13 22:19:16 receive version message: /Satoshi:0.9.3/: version 70002, blocks=338817, us=84.215.171.162:8333, peer=2859 2015-01-13 22:19:16 Added time data, samples 200, offset -2 (+0 minutes) 2015-01-13 22:19:32 receive version message: /Snoopy:0.1/: version 60001, blocks=0, us=84.215.171.162:8333, peer=2860 2015-01-13 22:19:47 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=84.215.171.162:8333, peer=2861 2015-01-13 22:22:36 receive version message: /getaddr.bitnodes.io:0.1/: version 70002, blocks=338819, us=84.215.171.162:8333, peer=2862 2015-01-13 22:22:44 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:22:45 receive version message: /BTCXchange.ro Mapper:0.01/: version 60000, blocks=230000, us=84.215.171.162:8333, peer=2863 2015-01-13 22:22:47 receive version message: /BitCoinJ:0.11.2/MultiBit:0.5.18/: version 70001, blocks=338819, us=127.0.0.1:8333, peer=2864 2015-01-13 22:22:47 Added time data, samples 200, offset +10 (+0 minutes) 2015-01-13 22:23:00 receive version message: /Satoshi:0.8.4/: version 70001, blocks=338819, us=84.215.171.162:8333, peer=2865 2015-01-13 22:23:00 Added time data, samples 200, offset -7 (+0 minutes) 2015-01-13 22:23:53 receive version message: /Satoshi:0.8.2.2/: version 70001, blocks=336635, us=84.215.171.162:8333, peer=2866 2015-01-13 22:23:53 Added time data, samples 200, offset +14 (+0 minutes) 2015-01-13 22:24:13 receive version message: /Satoshi:0.9.3/: version 70002, blocks=338735, us=84.215.171.162:8333, peer=2867 2015-01-13 22:24:13 Added time data, samples 200, offset -5 (+0 minutes) 2015-01-13 22:25:06 receive version message: /Snoopy:0.1/: version 60001, blocks=0, us=84.215.171.162:8333, peer=2868 2015-01-13 22:25:49 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=84.215.171.162:8333, peer=2869 2015-01-13 22:26:33 UpdateTip: new best=00000000000000001829e20898eaff72aa667d3715a94535afae5ae7ada07bc0 height=338820 log2_work=81.997947 tx=56659414 date=2015-01-13 22:25:41 progress=0.999999 cache=9596 2015-01-13 22:26:35 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:26:43 ERROR: AcceptToMemoryPool : nonstandard transaction: dust 2015-01-13 22:26:48 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:26:58 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:27:01 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=84.215.171.162:8333, peer=2870 2015-01-13 22:27:20 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:27:22 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:27:46 UpdateTip: new best=000000000000000008b332686e0043a4b95ca7e46d1b0785536981b543dfc755 height=338821 log2_work=81.998004 tx=56659415 date=2015-01-13 22:36:09 progress=1.000013 cache=9706 2015-01-13 22:28:29 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:28:34 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:28:48 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:28:52 receive version message: /getaddr.bitnodes.io:0.1/: version 70002, blocks=338819, us=84.215.171.162:8333, peer=2871 2015-01-13 22:29:22 ERROR: AcceptToMemoryPool : inputs already spent 2015-01-13 22:30:29 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-01-15 18:02:07

    UTXO Db and Indexes Data corruption 
    opened by eN0Rm 131
  • Use std::filesystem. Remove Boost Filesystem & System

    Use std::filesystem. Remove Boost Filesystem & System

    This PR replaces our Boost Filesystem usage with std::filesystem and includes dropping Boost System as a dependency. It includes a squashed down version of the changes from #19245.

    A macro has been added, modelling how we check for -latomic to facilitate linking with -lstdc++fs when required. This is ~GCC < 9.1 & ~Clang < 9.0, however not always. i.e you could be using Clang 7 on top of a GCC 9 installation (i.e Ubuntu Focal) and use <filesystem> without passing any additional arguments. I've tested this with GCC 8 on Bionic, Clang 7 on Focal & with Apple Clang 12.0.0 on macOS.

    Guix build:

    bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
    c1f9b326f9be4140f00cebeae5ff8de428a2fb8ecced539fcc36c53f53bfecf4  guix-build-07269321f38e/output/aarch64-linux-gnu/SHA256SUMS.part
    b44aca3bcf5ea92a3a6c48c24d6f85576f425f59b73528d4d00c20e950cf2128  guix-build-07269321f38e/output/aarch64-linux-gnu/bitcoin-07269321f38e-aarch64-linux-gnu-debug.tar.gz
    27a5553f7bd14797293fc40c5fb131c91e98a61d5481a283f13a1d0497eb5ed8  guix-build-07269321f38e/output/aarch64-linux-gnu/bitcoin-07269321f38e-aarch64-linux-gnu.tar.gz
    99e55a88823f6095864a09c9eaa824e24d9ec527380eb394f751c7205b930f69  guix-build-07269321f38e/output/arm-linux-gnueabihf/SHA256SUMS.part
    b720b2724fa47fde584f58ed3b587f1d1183523540777fd367ab7e582605cfea  guix-build-07269321f38e/output/arm-linux-gnueabihf/bitcoin-07269321f38e-arm-linux-gnueabihf-debug.tar.gz
    c19c247f4e9e0d7f888ac8ba9de1c12d382f48fa828a685d4fe02818a18abd1f  guix-build-07269321f38e/output/arm-linux-gnueabihf/bitcoin-07269321f38e-arm-linux-gnueabihf.tar.gz
    55b49ccb38de03bb95101354a16fd8d2190abede5ccc0d9b00b40c0cd526a2f6  guix-build-07269321f38e/output/arm64-apple-darwin/SHA256SUMS.part
    baa44752470a6be9acae1c2f8fd1b9bc37afb00971787ea11fbaeddc9ab7c4aa  guix-build-07269321f38e/output/arm64-apple-darwin/bitcoin-07269321f38e-arm64-apple-darwin.tar.gz
    ad7df4d8026d5bcce1321cdccc2e1820e8a8bb7e1064ed16e20a7ea354057fd2  guix-build-07269321f38e/output/arm64-apple-darwin/bitcoin-07269321f38e-osx-unsigned.dmg
    f342066dc34a14d67c47779a2413a14633a996e8e7ddca89ae0184e23ef99efd  guix-build-07269321f38e/output/arm64-apple-darwin/bitcoin-07269321f38e-osx-unsigned.tar.gz
    f6905346a5d48f57805fb062d0247ab5007c89047070a0b3125941dd1a2b8aa6  guix-build-07269321f38e/output/dist-archive/bitcoin-07269321f38e.tar.gz
    a1f6c4b2b118dbd89770801f0bcffd2218b82df408cd227e34c40493469bb7a2  guix-build-07269321f38e/output/powerpc64-linux-gnu/SHA256SUMS.part
    ba8359426e523bf013d93579c1bedc57380214c8170a9743b64ec1a8a3bbccbf  guix-build-07269321f38e/output/powerpc64-linux-gnu/bitcoin-07269321f38e-powerpc64-linux-gnu-debug.tar.gz
    b0bb500c274a683ea28ecbc1e8f18c618a9f8acb00045f80ae43c515288402c0  guix-build-07269321f38e/output/powerpc64-linux-gnu/bitcoin-07269321f38e-powerpc64-linux-gnu.tar.gz
    38c85e9589e092cd3aa08996aa383c0ccd5c73208943389741355a6eb7f72537  guix-build-07269321f38e/output/powerpc64le-linux-gnu/SHA256SUMS.part
    50fcba7942ff48d91e84c093fda0affc17e46167fe1d5137c6e14c5c41f289d1  guix-build-07269321f38e/output/powerpc64le-linux-gnu/bitcoin-07269321f38e-powerpc64le-linux-gnu-debug.tar.gz
    fa08ef1ceca072e014faa95ffee945954b2976fa28f90926b87ab0e5f15f8ca5  guix-build-07269321f38e/output/powerpc64le-linux-gnu/bitcoin-07269321f38e-powerpc64le-linux-gnu.tar.gz
    e52dd80a9c306d6aeb544acaa1f4ed560b6b92b5184764a05026d45451aa2e94  guix-build-07269321f38e/output/riscv64-linux-gnu/SHA256SUMS.part
    864e0a16c485b4159cec3ee0a83b046f1b1c3bc821670011c5ac5cd09ddfb91f  guix-build-07269321f38e/output/riscv64-linux-gnu/bitcoin-07269321f38e-riscv64-linux-gnu-debug.tar.gz
    4a061172181322e7ad0cf06405bf74f4c8683eaba3a67ecfd46158cba7627f62  guix-build-07269321f38e/output/riscv64-linux-gnu/bitcoin-07269321f38e-riscv64-linux-gnu.tar.gz
    876d82251853205420dffe7237523fc6ee3d09f78bf74cc03dc71f548446f335  guix-build-07269321f38e/output/x86_64-apple-darwin/SHA256SUMS.part
    3f82b2e62c60eee68e7b8fc28e4792e069e3c2cd780ee2d67290ca422cdbc47c  guix-build-07269321f38e/output/x86_64-apple-darwin/bitcoin-07269321f38e-osx-unsigned.dmg
    4ccdd4c410cac9d627e54ce83ee4816608681735da3cb93c60c5eb70ca86337a  guix-build-07269321f38e/output/x86_64-apple-darwin/bitcoin-07269321f38e-osx-unsigned.tar.gz
    2179d36b2f60e28c15262d4e51f27465b5ae077f60e550345e125683ca611066  guix-build-07269321f38e/output/x86_64-apple-darwin/bitcoin-07269321f38e-osx64.tar.gz
    b377e72fe84b6a982b8d414d60c85e6319523dff50dc852a0ba907f6d850ddd0  guix-build-07269321f38e/output/x86_64-linux-gnu/SHA256SUMS.part
    8547e2f582ce05ae6a6224793b64efb2eb63f2816bf0bed5d53fcc4786274597  guix-build-07269321f38e/output/x86_64-linux-gnu/bitcoin-07269321f38e-x86_64-linux-gnu-debug.tar.gz
    83b64805aa39f31a6fa4c2ed41e029c3be084e6dea06b90fac1ebca5c95bce29  guix-build-07269321f38e/output/x86_64-linux-gnu/bitcoin-07269321f38e-x86_64-linux-gnu.tar.gz
    
    Refactoring Build system 
    opened by fanquake 130
  • Relay and alert user to double spends

    Relay and alert user to double spends

    Rebased version of #3354.

    Instead of dropping double-spend transactions, relay them to peers. This is crucial to allowing all parts of the network to detect double-spend attempts as quickly as possible, i.e. reducing the "confirmation" time for buying coffee to a time on par with credit card transactions. Only the first respend seen is relayed.

    I successfully completed a primary test running 3 copies of bitcoin-qt in regtest mode with this patch applied, connected in a node1-newtorknode-node2 configuration.

    I used the rawtransaction API for steps 2 and 3, but with -salvagewallet and a single funding transaction, tests would be possible that did not require rawtransactions.

    Still TODO: Regression test plan

    Primary Test Details Step 1

    • Send transaction from node1 to a node2 address
    • * Transaction is relayed through networknode, to node2
    • * Transaction appears in node2 wallet

    Step 2

    • Restart node1 with -salvagewallet (so it forgets about 1st spend)
    • Send new transaction using same input (first double-spend), using rawtransaction API
    • * Transaction is relayed through networknode, to node2
    • * node2 does not accept the double-spend into its mempool and it does not appear in node2 wallet

    Step 3

    • Restart node1 with -salvagewallet again
    • Send transaction using same input (second double spend), using rawtransaction API
    • * Transaction is not relayed through networknode

    Step 4 One more test for good measure

    • Restart node1 with -salvagewallet again
    • Using regular UI (not rawtransaction API), send entire wallet balance to node2 (third double spend). This included additional inputs besides the spent one.
    • * Transaction is not relayed through networknode
    opened by dgenr8 120
  • BIP-325: Signet [consensus]

    BIP-325: Signet [consensus]

    This PR is a part of BIP-325 (https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki), and is a sub-PR of #16411.

    • Signet consensus (this)
    • Signet RPC tools (pending)
    • Signet utility scripts (contrib/signet) (pending)
    Validation Consensus 
    opened by kallewoof 115
  • Add normalized transaction hash

    Add normalized transaction hash

    This is just a very basic implementation for exposure/review, with lacking documentation, and no functionality to look up transactions by normalized txid.

    opened by sipa 115
  • Testchains: Introduce custom chain whose constructor...

    Testchains: Introduce custom chain whose constructor...

    ...reads from runtime params and simplify the creation of partitioned chains by simply generating different gensis block hashes from a given custom name.

    It also allows to customize any chain param in these custom chains (but not the other chains).

    Dependencies:

    • [ ] Testschains: Many regtests with different genesis and default datadir #17037
    • [ ] Tests: Chainparams: Make regtest almost fully customizable #17032
    • [ ] Tests: Use self.chain instead of 'regtest' in all current tests #16681
    • [x] Preparations for more testchains #16680
    • [x] Use a proper factory for creating chainparams #8855 ~~- [ ] Really don't validate genesis block #9102~~
    • [x] Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs #9494
    • [x] QA: segwit.py: s/find_unspent/find_spendable_utxo/ #11869
    • [x] Refactor: One CBaseChainParams should be enough #12128

    Other features:

    • [x] Uses a custom chain for all python tests.
    • [X] Create new testchains with different genesis hashes at will.
    • [X] Load chainparams from ~~separated~~ file or command line. (file left for later, see https://github.com/jtimon/bitcoin/tree/b16-new-testnet-file )
    • [X] New chains are neither orange, blue nor green: they're purple and have your custom chain petname shown in the GUI.
    • Extra context: some people asked for signed blocks but that's way more disruptive and this is already review-thirsty (see #9177 ).
    Tests Consensus Needs Conceptual Review 
    opened by jtimon 108
  • LevelDB corruption with 0.8.x Mac client

    LevelDB corruption with 0.8.x Mac client

    I've run bitcoin-qt Mac client on the latest OSX version since 0.3.x thru to 0.7.2 with literally zero problems ever, on essentially this same hardware setup.

    Since the 0.8 update and switch to LevelDB none of the three Mac client releases have worked stably for me and I've had to downgrade to 0.7.2 (with the May 15 workaround) to maintain a stable bitcoin wallet.

    Current setup is: MacBook Pro Retina, OSX 10.8.4, bitcoin-qt 0.8.2

    I saw that some of the known corruption issues/bugs were fixed/closed with the 0.8.2 release, so I decided to try the upgrade again. After re-indexing and working fine for hours at time (much better than 0.8.1 at least) upon restart I get "Error opening block database. Do you want to rebuild the block database?" which of course I don't want to do because it takes forever, even on this world's fastest Mac with SSD drive. This has happened 6 times now, and the interesting line in debug.log is:

    Verifying last 288 blocks at level 3 LevelDB read failure: Corruption: block checksum mismatch

    More details here: https://bitcointalk.org/index.php?topic=155140.0

    Downgrading to 0.7.2 again, please help permanently fix this in the next 0.8.x release.

    Bug 
    opened by toffoo 108
  • Speedy trial support for versionbits

    Speedy trial support for versionbits

    BIP9-based implementation of "speedy trial" activation specification, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html

    Edge cases are tested by fuzzing added in #21380.

    Validation Consensus 
    opened by ajtowns 106
  • psbt: Check Taproot tree depth and leaf versions

    psbt: Check Taproot tree depth and leaf versions

    Since TaprootBuilder has assertions for the depth and leaf versions, the PSBT decoder should check these values before calling TaprootBuilder::Add so that the assertions are not triggered on malformed taproot trees.

    Fixes https://github.com/bitcoin/bitcoin/pull/22558#issuecomment-1170935136

    opened by achow101 0
  • test: refactor rpc_signrawtransaction.py

    test: refactor rpc_signrawtransaction.py

    rpc_signrawtransaction.py currently tests the signrawtransactionwithkey and signrawtransactionwithwallet RPCs.

    This PR splits rpc_signrawtransaction.py into

    1. rpc_signrawtransactionwithkey.py: the tests for signrawtransactionwithkey are moved here and this test can now be run with the wallet disabled.
    2. wallet_signrawtransactionwithwallet.py: wallet only tests for signrawtransactionwithwallet.py
    Tests 
    opened by ayush933 0
  • Confusing filtering by block hash behaviour in `listsinceblock`

    Confusing filtering by block hash behaviour in `listsinceblock`

    The reproduction speaks for itself:

    diff --git a/test/functional/wallet_listsinceblock.py b/test/functional/wallet_listsinceblock.py
    index fc06565983..e06fbf120a 100755
    --- a/test/functional/wallet_listsinceblock.py
    +++ b/test/functional/wallet_listsinceblock.py
    @@ -32,13 +32,14 @@ class ListSinceBlockTest(BitcoinTestFramework):
             self.connect_nodes(1, 2)
             self.generate(self.nodes[2], COINBASE_MATURITY + 1)
     
    -        self.test_no_blockhash()
    -        self.test_invalid_blockhash()
    -        self.test_reorg()
    -        self.test_double_spend()
    -        self.test_double_send()
    -        self.double_spends_filtered()
    -        self.test_targetconfirmations()
    +        # self.test_no_blockhash()
    +        # self.test_invalid_blockhash()
    +        # self.test_reorg()
    +        # self.test_double_spend()
    +        # self.test_double_send()
    +        # self.double_spends_filtered()
    +        # self.test_targetconfirmations()
    +        self.test_consistent_with_gettransaction()
     
         def test_no_blockhash(self):
             self.log.info("Test no blockhash")
    @@ -383,5 +384,19 @@ class ListSinceBlockTest(BitcoinTestFramework):
             assert_equal(original_found, False)
             assert_equal(double_found, False)
     
    +    def test_consistent_with_gettransaction(self):
    +        """Test the filtering in listtransactions is consistent with gettransaction's
    +        output.
    +
    +        The block hash parameter gives, according to the documentation, "the block hash
    +        to list transactions since". Test that if we have a transaction confirmed at a
    +        certain block, listing the coins since this block will output this transaction.
    +        """
    +        txid = self.nodes[2].sendtoaddress(self.nodes[2].getnewaddress(), 1)
    +        self.generate(self.nodes[2], 1)
    +        tx = self.nodes[2].gettransaction(txid)
    +        coins = self.nodes[2].listsinceblock(tx["blockhash"])["transactions"]
    +        assert txid in (c["txid"] for c in coins)
    +
     if __name__ == '__main__':
         ListSinceBlockTest().main()
    

    Is it intended that filtering transaction "since" block N only output transactions confirmed from block N+1?

    Bug 
    opened by darosior 2
  • guix: use elfesteem 2eb1e5384ff7a220fd1afacd4a0170acff54fe56

    guix: use elfesteem 2eb1e5384ff7a220fd1afacd4a0170acff54fe56

    Our patch has been merged upstream, see https://github.com/LRGH/elfesteem/pull/3.

    Guix Build (x86_64):

    3deb66d386587e7ce29b92528170081d9e74443ddf50d07b72aacaee31c11641  guix-build-103c0d9f7e08/output/aarch64-linux-gnu/SHA256SUMS.part
    5f53a059ccf07181fa1154dc6ab741a9beda663a48d123d2aa4256ca7d38497a  guix-build-103c0d9f7e08/output/aarch64-linux-gnu/bitcoin-103c0d9f7e08-aarch64-linux-gnu-debug.tar.gz
    20cdb705439ff54822f7c3cad12254b46f8ff93aae58f1716253f39bd734eaf1  guix-build-103c0d9f7e08/output/aarch64-linux-gnu/bitcoin-103c0d9f7e08-aarch64-linux-gnu.tar.gz
    ae51fb2ef8e76326bde4693f778444a5c21df1feba42b161e667c5f069aae967  guix-build-103c0d9f7e08/output/arm-linux-gnueabihf/SHA256SUMS.part
    0ffeaa089582871a578069c0251bf51823624274c23c2fd65f04d2a3e50f3296  guix-build-103c0d9f7e08/output/arm-linux-gnueabihf/bitcoin-103c0d9f7e08-arm-linux-gnueabihf-debug.tar.gz
    71f3da47678d8169414ef0072271604fa550e84ce86979706b3b289a1521a119  guix-build-103c0d9f7e08/output/arm-linux-gnueabihf/bitcoin-103c0d9f7e08-arm-linux-gnueabihf.tar.gz
    f5d13de726f7705e946a2b3a63d182d8c7e70e3adc9a92552676898e9819db27  guix-build-103c0d9f7e08/output/arm64-apple-darwin/SHA256SUMS.part
    e411e8f0cc3ab18981ccb65768a6af1622748c14b6e0513401179bcd0df519a7  guix-build-103c0d9f7e08/output/arm64-apple-darwin/bitcoin-103c0d9f7e08-arm64-apple-darwin-unsigned.dmg
    d7e9aa52f9b0a0249445e926753978d6845bab0c02639d162879b921f237b8ce  guix-build-103c0d9f7e08/output/arm64-apple-darwin/bitcoin-103c0d9f7e08-arm64-apple-darwin-unsigned.tar.gz
    cefde91f0b75a27e945f190194dbe0dab5653a6bcc91b18bec34d952aebd72d7  guix-build-103c0d9f7e08/output/arm64-apple-darwin/bitcoin-103c0d9f7e08-arm64-apple-darwin.tar.gz
    0b399fd5f7a85974ab25933575a0173c814d4ab578d16ab13896bb51e408b92f  guix-build-103c0d9f7e08/output/dist-archive/bitcoin-103c0d9f7e08.tar.gz
    22d6a771d2eab73ab328c8b472160333dd52c6f734761f466c79251a37bd1895  guix-build-103c0d9f7e08/output/powerpc64-linux-gnu/SHA256SUMS.part
    a6e598b022683e0858be8bd4a6d75bc15f2fbc7632c45f8b03c7a8dff367343a  guix-build-103c0d9f7e08/output/powerpc64-linux-gnu/bitcoin-103c0d9f7e08-powerpc64-linux-gnu-debug.tar.gz
    04ea54706ac47f8880ae0fcddabb0f4fe899a0bacf52d0d936dbbc1149e14e10  guix-build-103c0d9f7e08/output/powerpc64-linux-gnu/bitcoin-103c0d9f7e08-powerpc64-linux-gnu.tar.gz
    059a7018ce96e141c258d516b85c3ee95f02b61dc2db4931fa14993b2bd945e3  guix-build-103c0d9f7e08/output/powerpc64le-linux-gnu/SHA256SUMS.part
    aacaa0e4827808ed189152c6f1a4e0d9300b89136a7dc064fd045f700ee06084  guix-build-103c0d9f7e08/output/powerpc64le-linux-gnu/bitcoin-103c0d9f7e08-powerpc64le-linux-gnu-debug.tar.gz
    4041f8de495b4633df0e28d75ab6cfd0bfe7ec9292384ce4d3331383d06da310  guix-build-103c0d9f7e08/output/powerpc64le-linux-gnu/bitcoin-103c0d9f7e08-powerpc64le-linux-gnu.tar.gz
    1586a47797a803cab03a9ebcd207eb395e1651c443e9192ac2b144b85e014762  guix-build-103c0d9f7e08/output/riscv64-linux-gnu/SHA256SUMS.part
    74f088bca4e7c0d44e6b7161ee4c835b38bc9291c78f37e53d3ede2da98d52c0  guix-build-103c0d9f7e08/output/riscv64-linux-gnu/bitcoin-103c0d9f7e08-riscv64-linux-gnu-debug.tar.gz
    12cfe35b28de03f2355d6fb5ed9393001d3b5a06b12a2792cb863ca4ae61db17  guix-build-103c0d9f7e08/output/riscv64-linux-gnu/bitcoin-103c0d9f7e08-riscv64-linux-gnu.tar.gz
    b021e117d1e92ad105234661468efeab98246db79d51267a766399776999bafe  guix-build-103c0d9f7e08/output/x86_64-apple-darwin/SHA256SUMS.part
    0a6c9d00f9ea2d67ca58c867258bb1b595a3141d5f199ffb047f7235bb2863a6  guix-build-103c0d9f7e08/output/x86_64-apple-darwin/bitcoin-103c0d9f7e08-x86_64-apple-darwin-unsigned.dmg
    a7df5f759e792e4fae46ab7ddca5db8cff8973aa33d7d99c4bfbf7c04c2d3013  guix-build-103c0d9f7e08/output/x86_64-apple-darwin/bitcoin-103c0d9f7e08-x86_64-apple-darwin-unsigned.tar.gz
    801ec4f81af5f184cc0e0fcf650f4e5822d895a4202c35575f46e1c63498b1aa  guix-build-103c0d9f7e08/output/x86_64-apple-darwin/bitcoin-103c0d9f7e08-x86_64-apple-darwin.tar.gz
    813e9c9c6e0ce430d2096963dbffeb141f239d67b334e44b3fd1f1bc9246758d  guix-build-103c0d9f7e08/output/x86_64-linux-gnu/SHA256SUMS.part
    43e7afc360267fea8e1620e0c2ea40c45af07debbd646abf9fe631465c2e2c47  guix-build-103c0d9f7e08/output/x86_64-linux-gnu/bitcoin-103c0d9f7e08-x86_64-linux-gnu-debug.tar.gz
    0c5fc4b3c5bf4a53f1f9710cd738d5c0bbe6a2f0dc45e91f92065ae766b63635  guix-build-103c0d9f7e08/output/x86_64-linux-gnu/bitcoin-103c0d9f7e08-x86_64-linux-gnu.tar.gz
    08c031137c2c472a944f3220cf3812a8ec1dd70da9b0f264361ba16badb65b9f  guix-build-103c0d9f7e08/output/x86_64-w64-mingw32/SHA256SUMS.part
    4bbdc405075001b61e7cc48974e4b987c887a861add6db419fb51eccd914fbb0  guix-build-103c0d9f7e08/output/x86_64-w64-mingw32/bitcoin-103c0d9f7e08-win64-debug.zip
    8de95b683500300a787dd1d0d74580e9d6ab448f00f4c32e58ad830b763f2755  guix-build-103c0d9f7e08/output/x86_64-w64-mingw32/bitcoin-103c0d9f7e08-win64-setup-unsigned.exe
    36202c352d1f3b238daa00126f7ad369e53a510a32bb2585d69f967ef02aff48  guix-build-103c0d9f7e08/output/x86_64-w64-mingw32/bitcoin-103c0d9f7e08-win64-unsigned.tar.gz
    6255922a31502a23ea323095dec2d176bca22977222936fc7857a55ac001f6e9  guix-build-103c0d9f7e08/output/x86_64-w64-mingw32/bitcoin-103c0d9f7e08-win64.zip
    
    Build system DrahtBot Guix build requested 
    opened by fanquake 1
  • RPC: allow to track coins by imported descriptors

    RPC: allow to track coins by imported descriptors

    Wallet descriptors are useful for applications using the Bitcoin Core wallet as a backend for tracking coins, as they allow to track coins for multiple descriptors in a single wallet. However there is no information currently given for such applications to link a coin with an imported descriptor, severely limiting the possibilities for such applications of using multiple descriptors in a single wallet. This PR outputs the matching imported descriptor(s) for a given received coin in listsinceblock (and friends).

    It comes from a need for an application i'm working on, but i think it's something any software using bitcoind to track multiple descriptors in a single wallet would have eventually. For instance i'm thinking about the BDK project. Currently, the way to achieve this is to import raw addresses with labels and to have your application be responsible for wallet things like the gap limit.

    I'll add this to the output of listunspent too if this gets a few Concept ACKs.

    Wallet RPC/REST/ZMQ 
    opened by darosior 2
Releases(v23.0)
  • v23.0(Apr 25, 2022)

    Bitcoin Core version 23.0 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-23.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-23.0.md

    Do not use the links provided by GitHub, rather use the above download links, they are guaranteed to be generated deterministically and signed.

    Source code(tar.gz)
    Source code(zip)
  • v22.0(Sep 14, 2021)

    Bitcoin Core version 22.0 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-22.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-22.0.md

    Do not use the links provided by GitHub, rather use the above download links, they are guaranteed to be generated deterministically and signed.

    Source code(tar.gz)
    Source code(zip)
  • v0.21.1(May 3, 2021)

    Bitcoin Core version 0.21.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.21.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.1.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.21.0(Jan 15, 2021)

    Bitcoin Core version 0.21.0 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.21.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.0.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.20.1(Aug 2, 2020)

    Bitcoin Core version 0.20.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.20.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.20.1.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.20.0(Jun 3, 2020)

    Bitcoin Core version 0.20.0 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.20.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.20.0.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.19.1(Mar 9, 2020)

    Bitcoin Core version 0.19.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.19.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.19.1.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.19.0.1(Nov 24, 2019)

    Bitcoin Core version 0.19.0.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.19.0.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.19.0.1.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.18.1(Aug 9, 2019)

    Bitcoin Core version 0.18.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.18.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.18.1.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.18.0(May 18, 2019)

    Bitcoin Core version 0.18.0 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.18.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.18.0.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.17.1(Dec 25, 2018)

    Bitcoin Core version 0.17.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.17.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.1.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.17.0.1(Nov 6, 2018)

    Bitcoin Core version 0.17.0.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.17.0.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.1.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.17.0(Oct 3, 2018)

    Bitcoin Core version 0.17.0 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.17.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md

    Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.14.3(Sep 28, 2018)

    Bitcoin Core version 0.14.3 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.14.3/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.14.3.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.15.2(Sep 28, 2018)

    Bitcoin Core version 0.15.2 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.15.2/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.2.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.16.3(Sep 18, 2018)

    Bitcoin Core version 0.16.3 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.16.3/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.3.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.16.2(Jul 29, 2018)

    Bitcoin Core version 0.16.2 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.16.2/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.2.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.16.1(Jun 15, 2018)

    Bitcoin Core version 0.16.1 is now available from:

    https://bitcoincore.org/bin/bitcoin-core-0.16.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.1.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.16.0(Feb 26, 2018)

    Bitcoin Core version 0.16.0 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.16.0/

    and

    https://bitcoincore.org/bin/bitcoin-core-0.16.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.0.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.15.1(Nov 11, 2017)

    Bitcoin Core version 0.15.1 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.15.1/

    and

    https://bitcoincore.org/bin/bitcoin-core-0.15.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.1.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically and GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.15.0.1(Sep 19, 2017)

    Bitcoin Core version 0.15.0.1 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.15.0.1/

    and

    https://bitcoincore.org/bin/bitcoin-core-0.15.0.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.0.1.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically and GitHub's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.15.0(Sep 14, 2017)

    Bitcoin Core version 0.15.0 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.15.0/

    and

    https://bitcoincore.org/bin/bitcoin-core-0.15.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.0.md

    Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically and GitHubs's are not.

    Source code(tar.gz)
    Source code(zip)
  • v0.14.2(Jun 18, 2017)

    Bitcoin Core version 0.14.2 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.14.2/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.14.2.md

    Source code(tar.gz)
    Source code(zip)
  • v0.14.1(Apr 22, 2017)

    Bitcoin Core version 0.14.1 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.14.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.14.1.md

    Source code(tar.gz)
    Source code(zip)
  • v0.14.0(Mar 8, 2017)

    Bitcoin Core version 0.14.0 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.14.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.14.0.md

    Source code(tar.gz)
    Source code(zip)
  • v0.13.2(Jan 3, 2017)

    Bitcoin Core version 0.13.2 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.13.2/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.2.md

    Source code(tar.gz)
    Source code(zip)
  • v0.13.1(Nov 1, 2016)

    Bitcoin Core version 0.13.1 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.13.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.1.md

    Source code(tar.gz)
    Source code(zip)
  • v0.13.0(Nov 1, 2016)

    Bitcoin Core version 0.13.0 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.13.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md

    Source code(tar.gz)
    Source code(zip)
  • v0.12.1(Nov 1, 2016)

    Bitcoin Core version 0.12.1 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.12.1/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.12.1.md

    Source code(tar.gz)
    Source code(zip)
  • v0.12.0(Nov 1, 2016)

    Bitcoin Core version 0.12.0 is now available from:

    https://bitcoin.org/bin/bitcoin-core-0.12.0/

    For the release notes please see the git repository:

    https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.12.0.md

    Source code(tar.gz)
    Source code(zip)
An EDA toolchain for integrated core-memory interval thermal simulations of 2D, 2.5, and 3D multi-/many-core processors

CoMeT: An Integrated Interval Thermal Simulation Toolchain for 2D, 2.5D, and 3D Processor-Memory Systems With the growing power density in both cores

MARG 5 Jun 1, 2022
BTCU Wallet is the original Bitcoin Ultimatum client and it builds the backbone of the network.

The concept of BTCU is similar to the concept of the second cryptocurrency by capitalization - Ethereum.

Bitcoin Ultimatum (BTCU) 30 May 22, 2021
A high-performance distributed Bitcoin mining pool server.

Viabtc Mining Server ViaBTC Mining Server is a high-performance distributed Bitcoin mining pool server. We have made a lot of optimizations for Bitcoi

ViaBTC 90 Jun 22, 2022
Dogecoin is a cryptocurrency like Bitcoin

Dogecoin is a cryptocurrency like Bitcoin, although it does not use SHA256 as its proof of work (POW). Taking development cues from Tenebrix and Litecoin, Dogecoin currently employs a simplified variant of scrypt.

Dogecoin 14.1k Jun 23, 2022
Bitcoin Point of Sale

LNPoS Hardware https://shop.pimoroni.com/products/m5stack-faces-kit-pocket-computer-with-keyboard-game-calculator Installation Install Arduino IDE: ht

Arc 107 Jun 17, 2022
Bitcoin and Altcoins Publickey subtracter

keysubtracter Bitcoin and Altcoins Publickey subtracter Generate multiple but different "copies" of a publickey, Actually Added and substracted public

Luis Alberto 18 Jun 17, 2022
Brute Force Bitcoin Private keys, Public keys

Rotor-Cuda This is a modified version of KeyHunt v1.7 by kanhavishva. A lot of gratitude to all the developers whose codes has been used here. Feature

LostCoins 68 Jun 22, 2022
Onix is a decentralized blockchain project built on Bitcoin's UTXO model

What is Onix? Onix is a decentralized blockchain project built on Bitcoin's UTXO model, with support for Ethereum Virtual Machine based smart contract

Onix CryptoCurrency Development 4 Dec 16, 2021
mako - full bitcoin implementation in C

mako - full bitcoin implementation in C

Christopher Jeffrey (JJ) 523 Jun 18, 2022
Small collection of tools written in C for ECC and bitcoin

ecctools Small collection of tools written in C for ECC and bitcoin Why this programs are written in C language? Well i like C language because compil

Luis Alberto 18 Jun 15, 2022
Open-source, airgapped bitcoin hardware signer for the M5StickV.

Krux ✝ Krux is an open-source DIY hardware signer for Bitcoin that can sign for multisignature and single-key wallets. It is a low-cost airgapped devi

Jeff 40 Jun 16, 2022
Elecrypt core protocol details

This codes are compatible with esp8266 nodemcu 1.0 on Arduino board.media/esp8266nodemcu.png

null 6 Oct 17, 2021
Core - System components and backend.

Core System backend and start session and more. Compile dependencies sudo pacman -S extra-cmake-modules pkgconf qt5-base qt5-quickcontrols2 qt5-x11ext

CutefishOS 227 Jun 27, 2022
Bitcoin Core integration/staging tree

Bitcoin Core integration/staging tree https://bitcoincore.org For an immediately usable, binary version of the Bitcoin Core software, see https://bitc

Bitcoin Core 34 Jun 20, 2022
RavencoinLite Core integration/staging tree

RavencoinLite Core integration/staging tree https://ravencoinlite.org What is RavencoinLite? RavencoinLite is an experimental digital currency that en

null 24 Oct 12, 2021
Caffeecoin Core integration/staging tree

Caffeecoin Core integration/staging tree https://caffeecoin.com What is Caffeecoin? Caffeecoin is an experimental digital currency that enables instan

null 4 Feb 28, 2022
C++ implementation of R*-tree, an MVR-tree and a TPR-tree with C API

libspatialindex Author: Marios Hadjieleftheriou Contact: [email protected] Revision: 1.9.3 Date: 10/23/2019 See http://libspatialindex.org for full doc

null 614 Jun 20, 2022
This is like Inverting Binary Tree, but instead of a Binary Tree it's a File Tree.

Invert File Tree in C++ This is like Inverting Binary Tree, but instead of the Binary Tree it's a File Tree. This is intended as a simple exercise to

Tsoding 11 Jun 18, 2021
An intrusive C++17 implementation of a Red-Black-Tree, a Weight Balanced Tree, a Dynamic Segment Tree and much more!

This is Ygg (short for Yggdrasil), a C++17 implementation of several intrusive data structures: several balanced binary search trees: a red-black Tree

Lukas Barth 93 May 29, 2022
crwusiz branch is comma.ai devel-staging base xx979xx HKG_community source add

crwusiz openpilot crwusiz branch is comma.ai devel-staging base xx979xx HKG_community source add v0.8.9 [ allow white panda and gray panda, OP3T suppo

Lee Jong Mun 28 Jun 20, 2022
The PULP Ara is a 64-bit Vector Unit, compatible with the RISC-V Vector Extension Version 0.9, working as a coprocessor to CORE-V's CVA6 core

Ara Ara is a vector unit working as a coprocessor for the CVA6 core. It supports the RISC-V Vector Extension, version 0.9. Dependencies Check DEPENDEN

null 137 Jun 21, 2022
An EDA toolchain for integrated core-memory interval thermal simulations of 2D, 2.5, and 3D multi-/many-core processors

CoMeT: An Integrated Interval Thermal Simulation Toolchain for 2D, 2.5D, and 3D Processor-Memory Systems With the growing power density in both cores

MARG 5 Jun 1, 2022
Arduino core for GD32 devices, community developed, based on original GigaDevice's core

GD32 Arduino Core (New) This is a Arduino core is based off of the original GigaDevice core that was provided by the company in early June 2021 (see h

null 32 Jun 14, 2022
Probabilistic Risk Analysis Tool (fault tree analysis, event tree analysis, etc.)

SCRAM SCRAM is a Command-line Risk Analysis Multi-tool. This project aims to build a command line tool for probabilistic risk analysis. SCRAM is capab

Olzhas Rakhimov 112 Jun 16, 2022
BTCU Wallet is the original Bitcoin Ultimatum client and it builds the backbone of the network.

The concept of BTCU is similar to the concept of the second cryptocurrency by capitalization - Ethereum.

Bitcoin Ultimatum (BTCU) 30 May 22, 2021
The Game Boy ROM of the Game Boy bitcoin miner!

game-boy-bitcoin-miner The Game Boy ROM of the Game Boy bitcoin miner! To build this, currently this patch needs to be applied to GBDK: https://gist.g

Ghidra Ninja 78 May 29, 2022
A high-performance distributed Bitcoin mining pool server.

Viabtc Mining Server ViaBTC Mining Server is a high-performance distributed Bitcoin mining pool server. We have made a lot of optimizations for Bitcoi

ViaBTC 90 Jun 22, 2022