After doing some code archaeology, I am pretty sure that wkey records were never actually used. I am unable to find any point in time where wkey were even able to be written to disk. So it's really odd that you have a wallet file that contains wkeys.

In any case, wkey is supposed to be a private key with some extra metadata. There should be a 4 byte version number, followed by the private key, followed by an 8 byte creation time, followed by an 8 byte expiration time.

There is somewhat of a defacto standard in that the extra nonce is usually part of the coinbase script. This comes about because the vast majority of mining pools use the stratum v1 protocol which requires that the miners put the extra nonce in a specific place in the coinbase transaction that the mining pool has allocated for them. As such, it almost always is part of the coinbase script because that is an area where the individual miner can modify without affecting other consensus parts of the transaction or the payout address. However the actual format within the coinbase script itself can vary as those are determined by the mining pool. Some pools may use an OP_PUSHBYTES, some may have extra nonces of different lengths, etc.

Making a private section would be against the ethos of FOSS. It would literally be a "gang of old school b'developers" that you claim we will end up with without "changes". Making a private section that only an approved list of people are allowed to post in makes it almost impossible to get new people to join.

The goal is to create an environment where the barrier of entry is high enough to stop spam, but low enough that anyone who actually cares can still join. IRC channels and mailing lists appear to be pretty close to meeting those requirements. They require people to be able to read documentation and be able to use a computer well enough to download and use an IRC client or send an email to an email address. But the barrier of entry isn't so low that anyone can just make an account and shitpost in every thread on the forum.

Making an account on some website is a process everyone is familiar with today, so the barrier of entry is super low.

Even with the mailing list, sending emails is a low barrier of entry, so the mailing list does get quite a bit of noise and nonsense, but it's not nearly as bad as on this forum.

IRC is a bit of a higher barrier of entry, but really not that high and we do get many new developers joining.

This statement just really shows to me how much you have no idea what the state of open source Bitcoin development is. In the past couple of years, we have had a huge surge in the number of people contributing to Bitcoin Core. It's clear the joining an IRC channel, sending emails to a mailing list, and making a github account are not very high barriers of entry. Many new developers are fairly young and are not what I would classify as "old school".

All the developers moved on to other forums for discussion because Bitcointalk is full of spam and nonsense.

btc.com is still not fully signaling. My monitoring of them indicates that they are only issuing work that signals for Taproot on 1 out of 4 of their stratum servers. This is consistent with the number of signaling blocks that they have been mining too, as most of their blocks do not signal.

I don't think so.

Requiring all UTXO amounts is there to allow for offline signers to be guaranteed that the amount they are sending is correct. There have been some theorized situations where an offline signer could be tricked into sending more or less Bitcoin to fees than they expect to, which could result either in the loss of funds, or in the transaction not confirming in a timely manner.

Trezor described a potential attack that involve the uncertainty of the amounts in other inputs. This attack could result in the loss of funds by causing an increasing the transaction fee.

So this change to the sighash algorithm resolves such attacks. If the offline signer is lied to about the amount of other inputs, it will produce an invalid signature and so the transaction becomes invalid. Thus it doesn't matter if it is lied to, no funds can be lost.

For requiring all the output scripts, this is again for offline signers, particularly in coinjoins. In this scenario, the offline signer needs to be able to prove that all of the other inputs in the transaction do not belong to it. Otherwise it could lose funds. By requiring all of the scriptPubKeys for the other inputs, the offline signer can be safe to sign even if it is being lied to. Like with the amounts, if it is lied to, it will make an invalid signature and so the transaction is invalid. There is some more information about this on the bitcoin-dev mailing list.

The new Sighash algorithm includes all of the values and output scripts of the UTXOs being spent in the transaction.

They never gave a reason, so I have no idea.

For past few years, we've been getting 1 year certificates around the end of March. So this year, I went to renew the certificate, but Sectigo (the CA we've been using) asked us to register the organization we use with a government. The legal entity we have been using for certificates is a Swiss Association, and those don't require government registration. But apparently the CA/B Forum (the group that sets the rules for certificates) added a new rule late last year that requires CAs to make sure that organizations are registered with governments.

So we've spent the past 2 months figuring out how to register the Association with the Swiss government, and then waiting for the registration to go through and become publicly searchable so that whatever CA we use will be able to find it. So this should just be a delay, but it might take another month or two.

We did also setup another organization, this time a LLC in the US. So this should give us a backup option in the future, as well as possibly for right now if the LLC can be fully setup before the Swiss Association is registered.

There was also another annoying thing that happened when I tried to renew the certificate: Sectigo revoked the one that was about to expire, with a backdated revocation. This means that any release that was code signed with that certificate now shows even scarier warnings when you try to install it. This affects 4 released versions and we will be re-releasing those versions once we get the new certificate.

I'm not sure how pywallet dumps the wallet, but for examining the wallet data itself, if you're seeing timestamp next to the pubkey, then you are looking at the wrong records. The timestamp is attached to a metadata record, not the record containing the private key itself.

Bitcoin Core prefixes records with ascii, so you can search for the strings ckey or key. There will also be a 0x04 byte before ckey and a 0x03 byte before key. Those records will have the pubkey first followed by the privkey. With ckey, the private key will be encrypted. With key, it will be in plaintext but serialized with DER so it will be very long and include a bunch of unnecessary information about the secp256k1 curve.

0.21.1 Release Notes

Bitcoin Core version 0.21.1 is now available from:

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

This minor release includes various bug fixes 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 in some cases), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
or bitcoind/bitcoin-qt (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Notable changes

Taproot Soft Fork

Included in this release are the mainnet and testnet activation
parameters for the taproot soft fork (BIP341) which also adds support
for schnorr signatures (BIP340) and tapscript (BIP342).

If activated, these improvements will allow users of single-signature
scripts, multisignature scripts, and complex contracts to all use
identical-appearing commitments that enhance their privacy and the
fungibility of all bitcoins. Spenders will enjoy lower fees and the
ability to resolve many multisig scripts and complex contracts with the
same efficiency, low fees, and large anonymity set as single-sig users.
Taproot and schnorr also include efficiency improvements for full nodes
such as the ability to batch signature verification.  Together, the
improvements lay the groundwork for future potential
upgrades that may improve efficiency, privacy, and fungibility further.

Activation for taproot is being managed using a variation of BIP9
versionbits called Speedy Trial (described in BIP341). Taproot's
versionbit is bit 2, and nodes will begin tracking which blocks signal
support for taproot at the beginning of the first retarget period after
taproot’s start date of 24 April 2021.  If 90% of blocks within a
2,016-block retarget period (about two weeks) signal support for taproot
prior to the first retarget period beginning after the time of 11 August
2021, the soft fork will be locked in, and taproot will then be active
as of block 709632 (expected in early or mid November).

Should taproot not be locked in via Speedy Trial activation, it is
expected that a follow-up activation mechanism will be deployed, with
changes to address the reasons the Speedy Trial method failed.

This release includes the ability to pay taproot addresses, although
payments to such addresses are not secure until taproot activates.
It also includes the ability to relay and mine taproot transactions
after activation.  Beyond those two basic capabilities, this release
does not include any code that allows anyone to directly use taproot.
The addition of taproot-related features to Bitcoin Core's wallet is
expected in later releases once taproot activation is assured.

All users, businesses, and miners are encouraged to upgrade to this
release (or a subsequent compatible release) unless they object to
activation of taproot.  If taproot is locked in, then upgrading before
block 709632 is highly recommended to help enforce taproot's new rules
and to avoid the unlikely case of seeing falsely confirmed transactions.

Miners who want to activate Taproot should preferably use this release
to control their signaling.  The getblocktemplate RPC results will
automatically be updated to signal once the appropriate start has been
reached and continue signaling until the timeout occurs or taproot
activates.  Alternatively, miners may manually start signaling on bit 2
at any time; if taproot activates, they will need to ensure they update
their nodes before block 709632 or non-upgraded nodes could cause them to mine on
an invalid chain.  See the versionbits
FAQ for
details.

For more information about taproot, please see the following resources:

• Technical specifications
  
  • BIP340 Schnorr signatures for secp256k1
  • BIP341 Taproot: SegWit version 1 spending rules
  • BIP342 Validation of Taproot scripts
• Popular articles
  
  • Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin
  • What do Schnorr Signatures Mean for Bitcoin?
  • The Schnorr Signature & Taproot Softfork Proposal
• Development history overview
  
  • Taproot
  • Schnorr signatures
  • Tapscript
  • Soft fork activation
• Other
  
  • Questions and answers related to taproot
  • Taproot review

Updated RPCs

• Due to BIP 350
    being implemented, behavior for all RPCs that accept addresses is changed when
    a native witness version 1 (or higher) is passed. These now require a Bech32m
    encoding instead of a Bech32 one, and Bech32m encoding will be used for such
    addresses in RPC output as well. No version 1 addresses should be created
    for mainnet until consensus rules are adopted that give them meaning
    (e.g. through BIP 341).
    Once that happens, Bech32m is expected to be used for them, so this shouldn't
    affect any production systems, but may be observed on other networks where such
    addresses already have meaning (like signet).

0.21.1 change log

Consensus

• #21377 Speedy trial support for versionbits (ajtowns)
• #21686 Speedy trial activation parameters for Taproot (achow101)

P2P protocol and network code

• #20852 allow CSubNet of non-IP networks (vasild)
• #21043 Avoid UBSan warning in ProcessMessage(…) (practicalswift)

Wallet

• #21166 Introduce DeferredSignatureChecker and have SignatureExtractorClass subclass it (achow101)
• #21083 Avoid requesting fee rates multiple times during coin selection (achow101)

RPC and other APIs

• #21201 Disallow sendtoaddress and sendmany when private keys disabled (achow101)

Build system

• #21486 link against -lsocket if required for *ifaddrs (fanquake)
• #20983 Fix MSVC build after gui#176 (hebasto)

Tests and QA

• #21380 Add fuzzing harness for versionbits (ajtowns)
• #20812 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
• #20740 fuzz: Update FuzzedDataProvider.h from upstream (LLVM) (practicalswift)
• #21446 Update vcpkg checkout commit (sipsorcery)
• #21397 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
• #21081 Fix the unreachable code at feature_taproot (brunoerg)
• #20562 Test that a fully signed tx given to signrawtx is unchanged (achow101)
• #21571 Make sure non-IP peers get discouraged and disconnected (vasild, MarcoFalke)
• #21489 fuzz: cleanups for versionbits fuzzer (ajtowns)

Miscellaneous

• #20861 BIP 350: Implement Bech32m and use it for v1+ segwit addresses (sipa)

Documentation

• #21384 add signet to bitcoin.conf documentation (jonatack)
• #21342 Remove outdated comment (hebasto)

Credits

Thanks to everyone who directly contributed to this release:

• Aaron Clauson
• Andrew Chow
• Anthony Towns
• Bruno Garcia
• Fabian Jahr
• fanquake
• Hennadii Stepanov
• Jon Atack
• Luke Dashjr
• MarcoFalke
• Pieter Wuille
• practicalswift
• randymcmillan
• Sjors Provoost
• Vasil Dimov
• W. J. van der Laan

As well as to everyone that helped with translations on
Transifex.

---

---

Note that for this release, due to issues with acquiring a Windows code signing certificate, the Windows installer is not code signed. This means that there will be additional warnings when attempting to run the Windows installer.

Bitcoin operates on a UTXO model, not an accounts model. A transaction does not deduct some amount from an account balance; there are no accounts in Bitcoin.

Rather how Bitcoin works is that transactions create transaction outputs, and other transactions spend existing transaction outputs. Transaction outputs specify an amount and the conditions that a future transaction must meet in order for the output to be spent. There is a set of standard conditions that can be encoded as addresses. Once a transaction output is spent, it is gone and cannot be spent again. Only the Unspent Transaction Outputs (UTXOs) can be spent in a new transaction. Rebroadcasting the same transaction does not do anything because nodes will either consider the UTXOs spent, or say they have already seen this transaction and have already updated their state to accomodate it, so the rebroadcast does not do anything.

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