Addresses cannot be deleted; in fact on a technical level, there are no addresses.

What that chart shows is how many unique addresses contains coins. Recently many people have been moving their coins to segwit wallets which means that they are consolidating their coins into fewer addresses. Furthermore, many people have been doing such consolidations to avoid paying higher fees in the future.

Compared to other fee estimators, it's very good. Note that Electrum basically uses Core's fee estimation (the estimation from the Electrum servers which use Core as the backend).

Many people look at fee information charts like https://dedi.jochen-hoenicke.de/queue/#24h and choose a fee rate based on what outbids most transactions. Unfortunately this kind of pattern seeing and the processes that the human brain does in order to make such a decision is hard to do algorithmically. Note that just doing that in software is actually very gameable and ignores a ton of other information that helps make a better fee rate prediction.

What you are interested in is key and signature aggregation. Recently such a scheme using Schnorr signatures was announced. The thread about it is here: https://bitcointalk.org/index.php?topic=2818782.0

0xFFFF0000 is a compact representation of the target. The target is a 256 bit integer, but is compacted into a 32 bit form that can be stored in blocks. What that format is is described here: https://bitcoin.org/en/developer-reference#target-nbits.

Things are only reversed for display to the user. On the protocol level, things are used as provided.

The sha256d of the coinbase will be the merkle root if there are no other transactions.

As is. This is correct.

Yes.

vbytes are calculated by first dividing just the size of the witness data by 4 and then adding that to the size of the non-witness data.

Bitcoin Core's estimator actually uses vbytes, it's just labeled improperly.

You should be fairly excited. The proposal comes from Laolu, one of the primary architects of the Lightning Network and main developer of LND. While perhaps the proposal as it was exactly written in the email won't happen, I'm sure that something very similar to it will be created and implemented.

There is active discussion about this on the mailing list (I haven't really been following), and it is still in the concept phase so expect the proposal to change and the issues worked out over time.

Segwit addresses are not derived from legacy addresses. However a legacy address can be derived from a private key for a segwit address, and vice versa. Private keys are just numbers and are not locked to a specific type of address that they should be used to create.

Note that Electrum uses a special format for private keys in order to indicate what type of address they should be used for. You will need to export those private keys and convert them into a format that your forked coin's wallet can understand.

That is the old website. The correct one is https://btcarmory.com/.

Armorydb.exe is the backend for the Bitcoin Armory wallet. It communicates with Bitcoin Core and builds its own databases and block index from Bitcoin Core's data. This is what actually performs the transaction scanning stuff.

ArmoryQt.exe is the GUI application for Armory. It relies on ArmoryDB in order to function.

He probably only had experience programming in windows and with GUIs. Bitcoin 0.1.0 was a Windows only, GUI only application.

Yes.

It does everything that Bitcoin Core's GUI does but without a GUI. it's meant for people running headless servers or who just don't like GUIs.

Yes.

It is not big endian.

I do not think that this is exactly what your miner received from the pool. I think what you are seeing is based on an internal representation of the data which makes it appear to be different than what it actually is.

That is what is being displayed, but that is not what it actually has to be in the block header.

Because your miner is displaying that information incorrectly.

The correct block hash is f90f78da7e91f335617b9ad9bb8eb96cfab30431cd7a0b000000000000000000. You will notice that if you byteswap this so that it is actually in big endian, the block hash becomes 0000000000000000000b7acd3104b3fa6cb98ebbd99a7b6135f3917eda780ff9 which is an actual block that you look up on a block explorer or node. Looking up what your miner is displaying in both its original form and byteswapped form results in not being able to find such a block.

The new issues and PRs are related to critical-sh bugs found in RC1 and RC2. The final version will be released when those bugs are resolved and no new ones are found with the next RC.

Because that Pull Request was not merged.

No, there is not.

Reloading the bitcoin.conf file comes with a lot of potential consequences that can result in strange or broken behavior. There are many things that have to happen at startup in order for some things to work.

What you want is unrelated to the bitcoin.conf file. There is no need to let the bitcoin.conf file be reloaded in order to allow for wallets to by dynamically loaded and unloaded. Instead of jumping to that extreme, we can just add a feature that lets you dynamically load and unload wallets. In fact, there is an open pull request for exactly that: https://github.com/bitcoin/bitcoin/pull/10740. It is not merged yet so this behavior does not currently exist in Bitcoin Core. But hopefully in the next major release, it will.

No, everything in Bitcoin is serialized as little endian. Actually, this is serialized as big endian, but in kind of a strange way. It seems like it is being printed out with each 4 byte chunk (32 bit integer length) in big endian, which also means that the merkle root and previous block hash fields are messed up. But this is not the actual block header it is hashing.

This is the correct block header. Everything is in little endian as it should be. This is what the block header should look like.

The second one.

I'm pretty sure that sipa was only added to that list so that he could help migrate/maintain the bitcoin-dev mailing list. Development had moved from sourceforge to github in 2010 before the sourceforge repo was abandoned.

IIRC all of Wladimir, Pieter, Greg, Gavin, Jeff, and Matt all got involved within months of each other in 2010-2011. I think Wladimir is actually the longest contributing active contributor.

The person who contributed the longest and is still somewhat active is actually Dooglus.

---

A good place to find this kind of history is to scroll through the git log in reverse (i.e. earliest commit first).

You can't do it with bitcoind/Bitcoin Core. In order to find the balance of an address, an address index is required. But maintaining an address index is expensive and not that useful since the node does not need it to operate, so one is not maintained. There is no code in Bitcoin Core to build such an address index.

It is important to note that addresses and balances do not exist on a technical level. It requires significant computation to produce balances for all addresses, and requires a lot of additional storage space to store that data.

This thread has devolved into a lot of trolling, mudslinging, and flaming. Thus it shall be locked.

Private network based on what? Bitcoin does not have a "genesis Json file"

It doesn't exist in 0.1.0. A lot of stuff has changed since then, and it really is not worth your time to read through the original source code. So much has changed that whatever you learn is not applicable to the latest source code. You should instead try to learn and understand Bitcoin Core's latest source code. Keep in mind that the project has grown significantly since 0.1.0 and is much more complex.

You can try the #bitcoin, #bitcoin-dev, and #bitcoin-core-dev channels on Freenode's IRC.

I don't know of any recent ones that are accurate. But it isn't all that hard to follow the code. It is fairly well commented and the names of things are self explanatory. You can start with src/bitcoind.cpp where the main function is for bitcoind and then follow along from there. Knowing how to use grep to find things is also very useful.

Bitcoin does not actually use that much cryptography. You just need to understand some basics, like what a hash function is and what digital signatures are. That's about it.