You can just download the non-codesigned installer. Download bitcoin-0.21.0-win64-setup-unsigned.exe from https://bitcoincore.org/bin/bitcoin-core-0.21.0/. You just need to click through a few warnings to install it. A new SHA256SUMS.asc file was uploaded to the same folder which covers the non-codesigned installer too.

The warnings to click through are shown in the third section of this post: https://github.com/bitcoin-core/gui/issues/252#issuecomment-807400048

0220 and 022100 are not magic separators. They are part of the DER encoding of the signature. DER encodes data in a Type Length Value format. 0x02 is a type. The byte that follows (0x20, 0x21, or in this case, 0x1f) is the length of the data. The 0x00 in 022100 is actually the first byte of the s value.

So in this signature, the length of the s value is 31 (0x1f) bytes rather than 32 (0x20) or 33 (0x21). This can happen occasionally, although it has a low probability. However you can't just change a signature to use 0x1f for the length, or remove the length entirely. That would make it invalid.

This is some shoddy reporting.

Greg Maxwell neither has the ability to merge pull requests, nor was he significantly involved in the discussions that resulted in Speedy Trial. The person who actually merged it was fanquake, following months of review and revisions from several other developers.

It actually wasn't, the timing was just unfortunate. AJ and I agreed on the method to use, and the PR to close prior to the coin toss. However, it happened to be that I posted my comment with the resolution of that discussion at around the same time the coin toss occurred. Since that resolution was also what the coin toss came up with, it gives the appearance that this was decided by a coin toss, but it really wasn't.

This is expected. Prior to BIP 32 HD wallets (introduced in Bitcoin Core 0.13 in 2016), wallets pregenerated 100 keys (for both receiving and change). After BIP 32 HD wallets, wallets pregenerated 2000 keys (1000 for receiving, 1000 for change). This causes the size difference.

The format has not changed. Compatibility is maintained.

It does not. That 3rd parameter is a number of iterations to do and is based off of a benchmark of your computer that is done at the time encryption is added.

This is expected. Compatibility is maintained.

The format is as follows:

<length of encrypted key> is always 64. The encrypted key is a 32 byte key which means it is 64 characters.
<encrypted key> is the encryption key which itself is encrypted with your passphrase. Your passphrase is hashed to get the key that is used to encrypt this encrypted key.
<length of salt> is always 16. The salt is 8 bytes which means it is 16 characters.
<salt> is the salt. It is randomly generated. The salt is combined with your passphrase to generate the key used to encrypt the actual encryption key.
<derivation method iteration count> is the number of times to run the hash function that is used to derive the encryption key from your passphrase.
<length of derivation method> is always 2. The derivation method is stored as a single byte number, so it is always 2 characters.
<derivation method> is an integer that indicates the function to be used to derive the encryption key from the passphrase. Currently there is only one method, SHA512, and it is indicated with the number 0.
<length of additional parameters> is always 2. There are no additional parameters, so it is represented by a single byte of 0, which makes the length 2 characters.
<additional parameters> is always 00. There are no additional parameters, so it is always a 0 byte.

Descriptor wallets follow BIPs 44/49/84. The keys are no longer derived with fully hardened derivation paths. This is done at the expense of dumpprivkey now being disabled.

Use importdescriptors

The setup could be better, but once it is setup, the PSBT workflow has been significantly improved. Sending transactions can be done entirely from the gui.

You have recompiled each time?

The icons in share/ only effect the installer that is created. The icons that are used in bitcoin-qt are in src/qt/res

Did you change bitcoin.ico? That's the icon file.

All of the assets used in the binaries can be found in src/qt/res

Bitcoin Core is a full node. It downloads and verifies all blocks and transactions. Additionally, it is a wallet software so all of your private keys are generated, stored, and managed by Bitcoin Core if you use its wallet.

Bitcoin Core is more secure and private than online wallets. Those wallets may also be custodial wallets where your Bitcoin is held by the service provider and they just promise to send the Bitcoin when you ask for it to be sent somewhere. Those web wallets are not private - the service provider can see all of your transactions and associate those transactions to you. They can do this trivially. Additionally, if they go offline, go out of business, or stop operating for whatever reason, your Bitcoin is lost. Bitcoin Core does not have those problems. If Bitcoin Core is no longer being developed, you can still use the software that you have downloaded and installed. Because Bitcoin Core is a full node, it is much harder to know which transactions are yours because your node will be receiving and sending all transactions on the network. Any that are yours blends in with the crowd of other transactions being relayed by Bitcoin Core.

It is not a private key nor is it stored in any way similar to a private key. The master key is generated when you encrypt. It is never stored unencrypted.

The thing to look for is a record that begins with mkey

bitcoin-qt does not start the rpc server by default. You can enable that by adding server=1 to your bitcoin.conf.

Yes. They use the same code, just that bitcoin-qt has additional code to show a GUI.

Yes. getblocktemplate uses JSON-RPC over http. Stratum is a custom protocol. bitcoind does not implement stratum.

bitcoind must be synced for getblocktemplate to become available.

Is bitcoind synced?

Don't specify --stratum-port. Do not specify that the mining software should be using the stratum protocol. If anything, try to see if you can specify that it should use getblocktemplate (frequently shortened as gbt).

The version of bitcoind doesn't really matter. Bitcoind never supported stratum so stop trying to use stratum with it.

bitcoind is not a stratum server, so the stratum protocol will not work with it. The only mining protocol that bitcoind supports is getblocktemplate. If you change the url from stratum+tcp to http, your mining software should automatically try getblocktemplate and that should work.

Regardless it is still a soft fork. BIPs 66 (strict DER) and 65 (OP_CLTV) also used the same activation mechanism. You could say that BIP 66 is a bug fix, but BIP 65 is certainly a feature upgrade in the same way taproot is a feature upgrade.

The part that matters is where the new rules begin to be enforced. Under ISM, the new rules were enforced at 75%. This means that if any blocks failed the new rules after 75% had signaled, then there would be a chain split. The same is true of the proposed 90% threshold: the new rules activate when 90% of blocks signal (after a grace period) and any block that fails the new rules afterwards is invalid. it doesn't matter that blocks conforming to the old rules can be mined, the same applies to BIP 8 and 9 deployments. All that matters with this threshold is whether the new rules are being enforced. For the current taproot activation proposals, that is at 90%. In all ISM forks, that was 75%.

The 95% threshold has no counterpart in BIPs 8 or 9 as they do not have an invalidity requirement. There is no requirement that disallows blocks which are valid under the new rules but do not use them (as a v1 block would be after BIP 34). Even with segwit, miners can still mine blocks that contain only legacy transactions and they don't need to have the witness merkle root in their coinbases if they do so.

Activation thresholds have been lower in the past, ISM (BIP 34) used 75% to activate new rules. Additionally, at previous meetings and discussions in the ##taproot-activation channel (and later discussed on the mailing list), 90% was deemed acceptable.

AJ's initial proposal is based on BIP 9 which doesn't actually use block times as is. It uses the median time past, not the actual time in the header, although MTP is based on that time.

My version of this proposal (summarized by roconner: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html) is based on BIP 8 so it uses block heights. It also runs 2-3 weeks later than AJ's.

Yes because that's the default behavior.  In order to accept incoming connections, you need to configure your router to allow incoming connections to port 8333. Most users aren't going to or don't know how to do that. Not to mention the fact that there will be people running Bitcoin Core on computers where they can't control the router to allow incoming connections. Additionally many people run Bitcoin Core on laptops, and given their portable nature, aren't usually set up to accept incoming connections.

That does sound like a network bottleneck for you, however just increasing the number of connections won't necessarily solve the problem. You have specifically connected to high speeds nodes, there is no guarantee that just an increased connection count would have your node connect to those.

How are you connecting to those nodes? It should be possible to make the connection type one that Bitcoin Core connects to automatically if the connection drops.