The block and transaction indexes are stored in the blocks folder.

The addresses are encoded here: https://github.com/bitcoin/bitcoin/blob/da9a2f5cd9032ee22acc5c2dc175e6934f63132c/src/key_io.cpp#L19. The specific functions that do the encoding are https://github.com/bitcoin/bitcoin/blob/ad823178e85aa070e5ec62799c17c36210b0dd7a/src/base58.cpp#L133 and https://github.com/bitcoin/bitcoin/blob/1d4662f5dcf64bd8cbab7386616461b570e93e67/src/bech32.cpp#L146

That isn't a bug fix or a critical change, so it isn't eligible for a minor release anyways.

You can use OpenSSL's hashing command. Or you can write your bytes to a file (with a hex editor or something) and hash the file using sha256sum which comes standard in most linux distributions.

This is supposed to happen. The daemon is supposed to stop when encrypting the wallet to ensure that nothing sensitive remains unenecrypted. You have to restart it after it stops.

Presumably Josh has his own redeemScript and does not share one with Carla so his redeemScript is unknown unless he has used it before. Furthermore, once Carla's transaction is confirmed, no one can spend that output.

I misunderstood what you meant by "retrieving redeemScripts from previous transactions". You can retrieve a redeemScript for a previous transaction. However when a transaction is validated, redeemScripts are not retrieved from previous transactions (which is what I thought you meant).

That is true.

However, no one who legitimately wants to receive money would give someone else an address for an OP_TRUE script. With P2SH, they can specify any script they want, and most scripts that people use still have a public key and a signature. Additionally, well known scripts such as an OP_TRUE have known addresses and people have bots that actively look for transactions sending to an OP_TRUE address and sweeping the funds immediately.

The script itself is the part which is expanded into the script. You can decode this as a script and you will get that script.

Not necessarily. It could be anyone who knew the redeemScript (by having generated it himself at some point) who created the transaction and sent it to 1GWdcSNAYdq3eG6YR4tb9YWiRvuC8k7J6V. It doesn't have to be the owner of that address.

No, it depends on the redeemScript. Not all redeemScripts are anyone-can-spend. You can specify anything you want, and most P2SH scripts that people use still require a signature.

I don't think bitcore-lib allows you to create and spend from non-standard scripts (which is what you want) unless you make raw transactions yourself and construct the scriptSig and redeemScript manually.

There are many reasons the reported sizes may be different. It depends on what they are actually measuring as "blockchain size".

A naive way of measuring would be to just take the size of the datadir for a bitcoind instance. However, this is going to include a bunch of extra data which is not actually the blockchain. This would include data like log files, wallet files, the UTXO set database, the block index, and the transaction index if that is enabled.

There may also be a discrepancy if one site does not run a segwit enabled node. Since a Segwit block is physically larger than the stripped block that a non-segwit node would receive, sites that support Segwit will report a larger blockchain.

Additionally, a site may receive more orphan blocks than another site which means that they are storing more blocks on disk. They may be measuring this as well which will cause the reported blockchain size to differ from sites that have received different orphan blocks.

No, this is incorrect. Carla does not need the redeemScript from Bob, she already has the redeemScript. In order for Bob to send Bitcoin to Carla, he has to have received an address from Carla to send to. Bob cannot just make up an address that Carla can theoretically spend and say he paid her. Rather Carla needs to create the address and give the address to Bob. So Carla would have to create the redeemScript, hash it and Base58 Check encode that to get the address. Then she gives the address to Bob so he can pay here. Thus Carla has the redeemScript and can spend the coins.

RedeemScripts are not retrieved from previous transactions.

Have a read of https://blog.lightning.engineering/announcement/2017/10/12/test-blitz.html. It explains the steps for the testnet. The mainnet version is not ready yet.

There is no need to sync the blockchain or run LND by yourself. The Lighting App handles all of that for you. Furthermore, it uses a BIP 158 (Neutrino) light client so there is no need to sync the entire blockchain at all.

Bitcoin Core 0.16.1 has been released: https://bitcointalk.org/index.php?topic=4476057.0

Bitcoin Core version 0.16.1 is now available from:

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

This is a new minor version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

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
===============

Miner block size removed
------------------------

The `-blockmaxsize` option for miners to limit their blocks' sizes was
deprecated in version 0.15.1, and has now been removed. Miners should use the
`-blockmaxweight` option if they want to limit the weight of their blocks'
weights.

0.16.1 change log
------------------

### Policy
- #11423 `d353dd1` [Policy] Several transaction standardness rules (jl2012)

### Mining
- #12756 `e802c22` [config] Remove blockmaxsize option (jnewbery)

### Block and transaction handling
- #13199 `c71e535` Bugfix: ensure consistency of m_failed_blocks after reconsiderblock (sdaftuar)
- #13023 `bb79aaf` Fix some concurrency issues in ActivateBestChain() (skeees)

### P2P protocol and network code
- #12626 `f60e84d` Limit the number of IPs addrman learns from each DNS seeder (EthanHeilman)

### Wallet
- #13265 `5d8de76` Exit SyncMetaData if there are no transactions to sync (laanwj)
- #13030 `5ff571e` Fix zapwallettxes/multiwallet interaction. (jnewbery)

### GUI
- #12999 `1720eb3` Show the Window when double clicking the taskbar icon (ken2812221)
- #12650 `f118a7a` Fix issue: "default port not shown correctly in settings dialog" (251Labs)
- #13251 `ea487f9` Rephrase Bech32 checkbox texts, and enable it with legacy address default (fanquake)

### Build system
- #12474 `b0f692f` Allow depends system to support armv7l (hkjn)
- #12585 `72a3290` depends: Switch to downloading expat from GitHub (fanquake)
- #12648 `46ca8f3` test: Update trusted git root (MarcoFalke)
- #11995 `686cb86` depends: Fix Qt build with Xcode 9 (fanquake)
- #12636 `845838c` backport: #11995 Fix Qt build with Xcode 9 (fanquake)
- #12946 `e055bc0` depends: Fix Qt build with XCode 9.3 (fanquake)
- #12998 `7847b92` Default to defining endian-conversion DECLs in compat w/o config (TheBlueMatt)

### Tests and QA
- #12447 `01f931b` Add missing signal.h header (laanwj)
- #12545 `1286f3e` Use wait_until to ensure ping goes out (Empact)
- #12804 `4bdb0ce` Fix intermittent rpc_net.py failure. (jnewbery)
- #12553 `0e98f96` Prefer wait_until over polling with time.sleep (Empact)
- #12486 `cfebd40` Round target fee to 8 decimals in assert_fee_amount (kallewoof)
- #12843 `df38b13` Test starting bitcoind with -h and -version (jnewbery)
- #12475 `41c29f6` Fix python TypeError in script.py (MarcoFalke)
- #12638 `0a76ed2` Cache only chain and wallet for regtest datadir (MarcoFalke)
- #12902 `7460945` Handle potential cookie race when starting node (sdaftuar)
- #12904 `6c26df0` Ensure bitcoind processes are cleaned up when tests end (sdaftuar)
- #13049 `9ea62a3` Backports (MarcoFalke)
- #13201 `b8aacd6` Handle disconnect_node race (sdaftuar)

### Miscellaneous
- #12518 `a17fecf` Bump leveldb subtree (MarcoFalke)
- #12442 `f3b8d85` devtools: Exclude patches from lint-whitespace (MarcoFalke)
- #12988 `acdf433` Hold cs_main while calling UpdatedBlockTip() signal (skeees)
- #12985 `0684cf9` Windows: Avoid launching as admin when NSIS installer ends. (JeremyRand)

### Documentation
- #12637 `60086dd` backport: #12556 fix version typo in getpeerinfo RPC call help (fanquake)
- #13184 `4087dd0` RPC Docs: `gettxout*`: clarify bestblock and unspent counts (harding)
- #13246 `6de7543` Bump to Ubuntu Bionic 18.04 in build-windows.md (ken2812221)
- #12556 `e730b82` Fix version typo in getpeerinfo RPC call help (tamasblummer)

Credits
=======

Thanks to everyone who directly contributed to this release:

- 251
- Ben Woosley
- Chun Kuan Lee
- David A. Harding
- e0
- fanquake
- Henrik Jonsson
- JeremyRand
- Jesse Cohen
- John Newbery
- Johnson Lau
- Karl-Johan Alm
- Luke Dashjr
- MarcoFalke
- Matt Corallo
- Pieter Wuille
- Suhas Daftuar
- Tamas Blummer
- Wladimir J. van der Laan

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).

---

Note this thread will be self-moderated to keep out the spam that usually appears in these release announcement threads.

I'm not currently running LND, so I'm not sure. However, you should see log lines related to circuits.

Have you set up the Ledger yet? The device configuration and setup happens completely on the device itself and does not require a computer or any interaction with a computer.

Bitcoin Core 0.16.1 IS NOT released yet. It has only been tagged. We are still doing the deterministic build process. The release is only official when Wladimir posts the release announcement to the mailing lists.

You will see that someone has offered you an HTLC and then you have offered someone else an HTLC.

Yes, routing occurs over open channels, you cannot route without multiple open channels.

It depends on how many coins you have and how man you are willing to put into each channel.

No.

You can't, not without modifying a lot of code. It's almost all in https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp. Bitcoin Core does not actually track the number of confirmations for a transaction; there is no trigger for that. Rather it just records the block height the block including a transaction was found and calculates the confirmations from the current block height. You will need to add something which, for each block, checks all known transactions in the wallet, calculates their confirmations, and triggers walletnotify for transactions at whatever confirmation count.

This topic has been moved to Trashcan.

Duplicate thread

Protecting against this is fairly trivial. Actually fixing the problem requires a hard fork unfortunately as the entire merkle tree structure needs to be redone.

The cost of exploiting this vulnerability is pretty high. With as much hashrate as Bitmain, there are easier and cheaper attacks that can be performed against SPV wallets that are inherent to how SPV wallets work. I wouldn't be too worried about this.

getblockchaininfo will tell you the height of the oldest stored complete block. You can then look up its hash using getblockhash.

This is impossible to do in Bitcoin.

Doing such contracts requires using the Bitcoin scripting language. However the scripting language does not have access to output amounts, nor does it have access to other UTXOs which it would in order to have the correct balance for an address.