Bitcoin Core version 0.16.3 is now available from:

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

This is a new minor version release, with various bugfixes.

Please report bugs using the issue tracker at GitHub:

  <https://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

  <https://bitcoincore.org/en/list/announcements/join/>

How to Upgrade
==============

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0 or newer, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
-------------------

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. Existing
wallets that were created with older versions are not affected by this.

Compatibility
==============

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===============

Denial-of-Service vulnerability
-------------------------------

A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners has
been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended
to upgrade any of the vulnerable versions to 0.16.3 as soon as possible.

0.16.3 change log
------------------

### Consensus
- #14249 `696b936` Fix crash bug with duplicate inputs within a transaction (TheBlueMatt, sdaftuar)

### RPC and other APIs
- #13547 `212ef1f` Make `signrawtransaction*` give an error when amount is needed but missing (ajtowns)

### Miscellaneous
- #13655 `1cdbea7` bitcoinconsensus: invalid flags error should be set to `bitcoinconsensus_err` (afk11)

### Documentation
- #13844 `11b9dbb` correct the help output for -prune (hebasto)

Credits
=======

Thanks to everyone who directly contributed to this release:

- Anthony Towns
- Hennadii Stepanov
- Matt Corallo
- Suhas Daftuar
- Thomas Kerin
- Wladimir J. van der Laan

And to those that reported security issues:

- (anonymous reporter)

---

Plagiarism is an automatic permanent ban. It does not matter how many posts are copied from others nor does it matter if the posts are deleted by a moderator. The mere fact that there were copied posts means that you will be permanently banned from the forum. A permanent ban applies to you the user, not to your account. Just because one account is permanently banned does not mean that you can use another account to make posts. You are not allowed to create a new account or use another account to post; you as a person are banned from this forum.

Most mods _do_ delete posts without relying on reports, but we still do rely on reports. However the quantity of posts that get made per minute is so high that it would be a more-than-full time job (i.e. probably 12-16 hours per day) to read every post and make a decision whether to delete them. The moderators do not have time for that. More moderators would be helpful, but we cannot rely on just the moderators. The community needs to help police itself, and people need to understand the rules.

There are multiple mathematical formulas and algorithms involved in both the calculation of a public key from a private key, and from a public key to a bech32 address.

I would estimate that it would take you a few decades to do either of these algorithms. With a computer to do some precomputation, you can probably do it in a few years.

---

For public key from a private key, Andrew Poelstra has a pretty good post describing it here: https://bitcointalk.org/index.php?topic=1534028.msg15594185#msg15594185 along with a precomputed table for you.

---

For the Bech32 calculation, you will need to be able to do two different hash functions: SHA256 and RIPEMD160. Then you also need to calculate the checksum which uses a BCH error correcting code.

For SHA256, Ken Shirriff has a pretty good blog post about how to do SHA256 by hand for mining. It's the same operations, just on different data. Also, you are doing only 1 SHA256 computation, not 2 as mining requires. You perform the SHA256 on your serialized public key in compressed form.

For RIPEMD160, I don't think anyone has really explained how to do by hand (and I don't really want to be cause it is long and takes a lot of time which I don't have). The algorithm is described in this paper with pseudocode given in Appendix A. It is similar to SHA256 in that the message is broken up into chunks which are XOR'd initially with some initial values and then later with the previous chunk.. You would like use a similar method as described in the SHA256 blog post but with the modifications to be able to do RIPEMD160. You perform RIPEMD160 on the above SHA256.

For calculating the checksum, you use the algorithm described under the Checksum section in the BIP. The gist of it is that, given a list of numbers, you apply multiple polynomials on all of the numbers and the "sum" of the results is the checksum (it's a lot more complicated than that and I don't remember all of the details). The python code given in the bech32_polymod() function describes how to do this. Note that ^= in python means XOR, not exponentiation.

To calculate the final bech32 string, you first need to convert the hash160 into a list of numbers usable for bech32's checksum calculation. You do this by splitting up the 160 bit hash into 5 bit chunks. Each 5 bit chunk is then a number so you now have a list of 5 bit numbers. You prepend to that the witness version, which is 0, so the list now starts with the number 0. Then you prepend to that an expansion of the human readable part of a bech32 string, bc. This is expanded by using the bech32_hrp_expand() function in the python code given in the BIP. You will get a list of numbers like so: [3, 3, 0, 2, 3]. So the resulting list of numbers will be 39 numbers in length and begin with [3, 3, 0, 2, 3, 0, .... Lastly you append six 0's to the end of the list which represent the positions that the checksum will go in. Now you do the bech32_polymod() function on this list of numbers and the resulting value you get back is the checksum.

Now you must convert all of these numbers to characters. You do this by breaking the checksum into 5 bit chunks to get a list of 6 numbers. Then, given the list of numbers containing the witness version number, the hash160, and the checksum, convert each number to the corresponding character using the lookup table described in the BIP. Note that you do not need to do this to the expanded human readable part. The resulting bech32 address is the human readable part concatenated to the character '1' concatenated to the characters for the witness version number, the hash160, and the checksum. So it will begin with bc1....

Regarding the human readable part expansion, that is done because the human readable part can be any ascii character and the numbers in the list of numbers need to be in the interval [0, 32). However ASCII can have numbers outside of that interval, so the expansion is done to have the higher bits, then the lower bits so it all fits in the interval.

Bech32 would probably only really take a few days / weeks. You just need to be careful to not make a mistake. The thing that takes a while would be privkey to pubkey.

getblockchaininformation is not a RPC command. You are probably looking for getblockchaininfo.

It doesn't it exist in Bitcoin yet. SIGHASH_NOINPUT requires a soft fork.

This question doesn't make any sense.

You can't. Lightning Network funding transactions look identical to any other transaction paying to a P2WSH output.

It can't do anything to mainnet since testnet is a completely separate network with almost 0 hashrate. The only reason this can happen on testnet is because someone has the majority hashrate.

Is your node fully synced? What do you get from the getblockchaininfo command?

No, because those things are not used in Bitcoin. Also, the library is heavily reviewed by cryptographers.

Even experimental things are generally safe to use as their cryptography is reviewed before it is implemented into libsecp256k1. The experimental mostly refers to the fact that APIs may change for those experimental things. Also, the experimental stuff is not enabled by default and must be explicitly enabled when compiling the library.

Yes, and no. Yes, a miner started from 0 and incremented the nonce until they found a hash that met the proof of work requirements. No, the difficulty does not require them to find a hash with 18 leading zeroes.

The leading zeroes thing is just a simplification of how the proof of work check actually works. What actually happens is that there is some target value that is a 256 bit integer. Block hashes are interpreted as a 256 bit integer. So all that happens is that the block hash (interpreted as a 256 bit integer) is compared to the target value. The block hash must then be less than or equal to the target value. Because the target value is "small" (small in terms of the 256 bit number space), it will have many leading zeroes. But the zeroes themselves do not actually matter, all that matters is the value.

There is only one parameter that matters: the target value. The difficulty is just the inverse of the target divided by the maximum target value.

The difficulty readjustment is really a target readjustment. The target changes every 2016 blocks, which is approximately two weeks. It does not actually change every two weeks since it may take shorter or longer than 2 weeks to find 2016 blocks. The target is just scaled proportionally to the amount of time it took to mine 2016 blocks and the amount of time it should take to mine 2016 blocks (2 weeks). Of course there must have been a starting point for the target, and that is the maximum target value (so difficulty is the lowest) which is defined in the consensus rules. The maximum target value was used in the genesis block so that is the starting point for target adjustment.

That is close. Miners don't usually re-select transactions after every set of nonces is exhausted. Usually they will change something within the block they already have. Specifically, they will set some value in their coinbase transaction that is known as the extra nonce. This extra nonce is then incremented every time the nonce runs out so that the merkle root is different and thus the nonces can be tried again. Furthermore, miners may change things like the block timestamp and block version number in order to get different candidate blocks.

Transactions are just transactions. There are no transaction headers. The block contains the transactions themselves and then the hash of all of the transactions is included in the merkle root which is in the block header.

No, the nonce is a 32 bit integer. It can only have the 32 bit integer values. It does not change with the difficulty.

A block hash is valid so long as it is less than or equal to the current target. So one with more leading zeroes is inherently less than, thus it will still be accepted.

Yes, but it is somewhat annoying to setup and it doesn't really work in the way that you would want it to.

On your offline wallet, get a bunch of addresses by using getnewaddress. Import these addresses into your online wallet using importmulti. Your online wallet will now track those addresses and your balance will update when those addresses receive coins.

Because those addresses are imported and are watching only, any time you do any wallet command, you must set whatever watching only option for that command to true, otherwise it will pull things from the online wallet itself and not the things you are watching.

HOWEVER, you cannot use getnewaddress or the GUI equivalent on the online wallet as that will actually give you keys generated in the online wallet. Furthermore, in order to have your offline wallet sign the transactions, you will need to provide additional information from the online wallet besides the transaction being signed. You will need to provide the scriptPubKey's of the outputs being spent, the amounts, and some other stuff I can't remember right now.

---

Note that the above HOWEVER only applies to versions prior to 0.17. The upcoming 0.17.0 release fixes these problems. You can create a wallet that has no private keys thus eliminating the need to be careful about getnewaddress as getnewaddress will not work when private keys are disabled for a wallet. Furthermore, 0.17 introduces BIP 174 Partially Signed Bitcoin Transactions which solves the issue of having to provide additional information as part of the command arguments. Instead that information will be packed into a PSBT which you can create and send to the offline wallet.

Because there isn't really a risk to using libsecp256k1. That's just there as a disclaimer since some parts of the library are experimental, but those are also labeled clearly.

libsecp256k1 is what Bitcoin Core uses for all of its ECDSA operations for several years now. The library was created by some Bitcoin Core developers.

BIP 174 and the Lightning Network are two completely separate and independent things. They are designed to achieve complete separate and independent goals. That article is wrong.

The Lightning Network is a scaling solution for doing transactions off chain.

BIP 174 is a transaction format for transactions that are not ready to be broadcast to the Bitcoin network yet. It is not a protocol nor is it a layer 2 solution for off chain transactions.

BIP 174 only helps for creating and signing on chain transactions. It is designed for inter-client compatibility and to allow easier hardware wallet and offline wallet setups.

Yeah, those docs tend to lag a few versions. The most up to date versions exist in the code itself. You can get those docs by doing
It will give you the help for the command.

Indeed, that probably would help. The heuristic currently is actually rather dumb. IIRC it decodes as non-witness first and then checks for whether there are invalid opcodes in the scripts of any inputs. We could certainly have it check the output amounts to see if they are sane (between 0 and 21 million).

There's nothing illegal about it. There is just no real benefit to the network if many or all nodes are running on VPS services like AWS. All of those nodes are using the same block of IP addresses. They are likely hosted in the same data centers, so they are centralized in both the same digital region (IP address blocks) and the same physical region (datacenter location). Furthermore, if Amazon or DIgitalOcean decided that they didn't want people running Bitcoin nodes on their VPSes, they could shut down those VPSes and take off a large portion of the network. Thus having many nodes on VPSes with the same VPS providers does not really contribute to the decentralization of the network and is similar to just one node being run.

This is a known issue and unfortunately it cannot be fixed without a fork. The issue lies with the format of a segwit transaction itself. A segwit transaction, under some circumstances, can be interpreted as either a 0 input, 1 output transaction, or as a witness transaction. Since getrawtransaction fetches transactions from blocks themselves or from the mempool, the transaction must be a valid network transaction and thus witness serialization can be attempted safely as a first step and only deserializing as non-witness if the witness deserialization fails.

However, decoderawtransaction behaves differently as it is intended to be used during the transaction creation steps. This means that it must be able to handle 0-input, 1 output transactions (which are inherently non-witness) as users may create a 0-input, 1 output transaction, decode it, and then pass it to fundrawtransaction to get inputs. But because some 0-input, 1 output transactions can be interpreted as witness transactions, and some witness transactions can be interpreted as 0-input, 1 output transactions, decoderawtransaction does not always succeed to decoding a transaction correctly. It uses some heuristics in order to decrease the number of false decodings, but sometimes, as you can clearly see, it's wrong.

Fortunately, if you know that a transaction is witness you can set the iswitness argument (added in 0.16) to true to tell it explicitly to decode the transaction as witness. You can set it to false for non-witness decoding. Not setting it uses the heuristics.

So your command will be something like:

First of all, double the current hashrate would be nearly impossible for someone to get. They would have to acquire ALL of the mining equipment in the world, and then do it again, all without taking away the existing equipment. This would be exorbitantly expensive, both in resources and in time. Manufacturers can't just magically produce machines that they don't have. It takes time, money, and raw materials. Such an operation would be very obvious.

Second, people running nodes, and nodes themselves, are not stupid. They would definitely notice a 500,000+ block blockchain reorganization. That is extremely obvious and there would be warnings put up all over place. Such an attack would likely result in some form of human intervention which prevents people's nodes from switching to using the attacker's blockchain.

It's a good thing that the code is completely different from what you did.

Also, this isn't "stealing your idea". You created a pull request for a particular feature. People did not like how you implemented it (and they also did not like how you rude you were in the thread and on IRC). The existence of your pull request has been taken as a feature request (you put out a request for us to implement this feature). Someone is implementing the feature you requested.

There's a link in the linked article that goes directly to the TOR Project's website. That's what it is telling people to download and extract. Furthermore, the link is to the download page, not a directly download link itself.

No, this is wrong.

First of all, 0x05 does not mean segwit, it means P2SH. Bitcoin Core by default creates addresses that are P2WPKH nested inside of a P2SH address. That is why you see embedded in the getaddressinfo output.

Your pool software is incorrect here, and that is the source of the problems. The scriptPubKey that you should have used is a91409763cb05dcea0f98f53b0f08651f92c5d2d2f3887 which maps to the address 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM. The 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 part is the hash160 of the redeemScript. Since this is a P2WPKH nested in a P2SH, the redeemScript is 00142ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0. However, what your pool software did was it ignored the version byte (the 0x05) which indicates that the hash160 encoded in the address should use a P2SH scriptPubKey. Instead, it made a P2PKH scriptPubKey using the provided hash160 which is why you see that the coins were sent to 1s2iywx94HudryMHsU2g1K9x8DB1cahGc.

It is missing because the pubkey does not exist in your wallet. What it is looking for is a pubkey that has a hash160 of 09763cb05dcea0f98f53b0f08651f92c5d2d2f38. But what you have is a redeemScript that has a hash160  of 09763cb05dcea0f98f53b0f08651f92c5d2d2f38. The pubkey that is in that redeemScript is unrelated to this address entirely.

The address is unrelated to the pubkey.

Your coins are lost, you cannot recover them. You would need a public key which hashes to 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 and its associated private key. All you have is a redeemScript that has that hash. That redeemScript is not a public key. Thus you cannot get those coins as you cannot spend them.


No No No! You are horribly mistaken and completely wrong. That is not how P2WPKH is nested in P2SH. Doing this will cause your coins to be lost. P2WPKH nested in P2SH uses the scriptPubKey of the P2WPKH output as the redeemScript. It does not use the keyhash as the hash in the P2SH scriptPubKey. The P2SH address OP has is correct, his pool software is just broken.