If Bitcoin Core now thinks that the wallet is encrypted, it is either encrypted or very corrupted. Because Bitcoin Core has to maintain compatibility with previous versions, it is intentionally not possible for a valid old wallet to be misinterpreted as having new features.

This topic has been moved to Trashcan.

Malware links

What is the point of that? Instead of having two forks, why not just have the one fork have the deadline be farther away so that people have more time to migrate. The point is that during the migration period, ECDLP is still not broken yet.

What is the point of burning the coins? Why would anyone even want to reveal their pubkeys to a miner just to gain nothing? Only the miners benefit from that, it's completely pointless to anyone else. it's the equivalent of just having a fork that completely disallows OP_CHECKSIG.

I disagree. It isn't a mess until QCs actually show up. Migration to PQC is pretty straightforward and non-messy, just needs a lot of time and warning.

The two forks are just so much more complex than a single fork which disallows OP_CHECKSIG and OP_CHECKMULTISIG after a deadline. And I don't think they're any easier than they seem, consensus and the script interpreter and far more complicated than you think, especially with anything that requires storing state or remembering previously executed scripts.

There's no reason to take so many steps and add even more special cases to the scripting system. To allow P2PKH but not P2PK requires adding special cases to OP_CHECKSIG which then needs to inspect the script to check whether it was P2PKH. And then you aren't covering things like multisigs or any complex script that uses OP_CHECKSIG. What about if the P2PK was nested inside of P2SH (because that's allowed)? Or people using bare multisig? So now we need to have tons more logic to handle all the weird things people can do with scripts? That's completely unnecessary.

The simpler and easier, and just as safe solution is to soft fork in a hard deadline (that can be several years in the future) where OP_CHECKSIG and OP_CHECKMULTISIG both become immediate script failures thus outlawing ECDSA. People can move their coins to whatever PQC signature scheme is introduced up until that deadline, regardless of script type, and then after the deadline, any usage of OP_CHECKSIG and OP_CHECKMULTISIG is disallowed.

I don't see why it is necessary at all to roll out such a migration so slowly with different script types getting different treatment. And it really doesn't generalize at all.

It's not even just the high proportion, it's also the visibility of some of the coins. In particular, all coins suspected to be Satoshi's are in P2PK outputs. If those moved ever, even to a different sig algo, it would cause enormous chaos. If those are stolen, there would be even more chaos. And those coins are just ~4% of the final money supply. So even if everyone else moved to non-ECDLP keys, the fact that those high profile coins are still secured by ECDLP poses a huge problem.

I agree, and it is mentioned in the article that what is most likely to happen is that we see QCs evolve and get better and better over time. By watching their evolution and planning ahead, we can move to post quantum cryptography before quantum computers even get to the point that they can break ECDLP in feasible time. It is highly unlikely that a QC would show up overnight that can break ECDLP. However, the point of the article is to discuss hashing in the worst case scenario: QCs magically appear and can break ECDLP in feasible time (not minutes, seconds, or at a glance, feasible time is the worst case scenario).

There won't be a transient phase. Either we have moved onto PQC by the time QCs can break ECDLP in feasible time, or Bitcoin is doomed.

The reason there is no transient phase and why "feasible time" is the worst case, we need to consider the fact that there are already millions of Bitcoin in outputs with their public keys exposed. They don't need to target new outputs with hashed pubkeys, there are millions of exposed pubkeys already in the blockchain that are with outputs that haven't been touched in years, such as Satoshi's outputs. They could just spend a lot of time cracking those keys, and then at some point in the future after the machine was created, they use all those private keys at once to move a bunch of coins. This would devastate the Bitcoin economy and kill it, unless we move to PQC before that happens (but the attacker would know, and could attack earlier). Either way, hashing did nothing.

If the attacker decides to just slowly steal old outputs that have had their pubkeys exposed, then he's slowly destroying Bitcoin and its value because people's money is being stolen. By the time it's realized, the damage would be done and people would probably panic to get out of Bitcoin before their coins are stolen too. It's extremely probably that the fear that a QC exists that can just steal millions of old coins would kill Bitcoin itself (cause the value to plummet, and people to rightfully no longer trust the cryptography). Either way, Bitcoin is killed.

And of course, in both of these, the attacker has time to just stockpile cracked private keys. During that time, QCs will also improve, so the attacker could get newer and better ones that crack even faster. Or he could just build more of them and crack in parallel. And so long as QCs can break ECDLP in reasonable time, it's only a matter of time before it gets to the point that they can break them very very quickly.

The point of the article is to say that while hashed public keys protects your coins specifically, they do nothing against the millions of already exposed public keys from which an attacker with an ECDLP break can use to wreak havoc and destroy the value of Bitcoin. Yes, your coins will be safe, but they won't have any value, so what's the point?

And all of this was just to say that there won't be a transient phase where hashing matters at all. The attacker will just target the already exposed pubkeys in outputs that haven' been touched in years.

Either we move to PQC before QCs can break ECDLP, and hashing didn't do anything. Or a QC comes along and can break ECDLP, and hashing did nothing because there are millions of available pubkeys with outputs that they can target, and hashing did nothing.

---

It would be a completely different story if Bitcoin had hashed pubkeys in everything since the beginning (but it did not, pay to pubkey was the expected method of usage) and no one ever reused addresses (so pubkeys were only exposed once and had no value afterwards). If those things were true, then I would say that there is a transient period and hashing does help protect against QCs. But that didn't happen.

No, that's wrong.

The public key you see in a taproot output is still a public key. It has a discrete logarithm (aka a private key) and anyone who is able to find it will be able to spend the coins regardless of any internal pubkey or script. The private key for a taproot pubkey (assuming a script) is the private key of the internal key + the hash of the script. The public key itself is computed by the sum of the internal pubkey and the "pubkey" of the hash of the script (i.e. multiply the hash by the curve generator).

For QC resistance and why hashing doesn't matter, see: https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance

The message that is signed is not the hash of the previous transaction. Nor is it the hash of the current transaction. Rather it is the current transaction with some parts modified.

For non-segwit inputs, the message that is signed is the current transaction with all input scriptSigs blanked out except for the current input that is being signed (or verified). For that particular input, the redeemScript is put into the scriptSig if one exists. If there is no redeemScript, the scriptPubKey of the output that was spent in that input is put in the scriptPubKey. At the end of the transaction you append a 4 byte little endian integer for the sighash type being used, in most cases, it's sighash all which is type 1. That is hashed once, then hashed again to get the value that is passed into the signing/verifying function.

For segwit inputs, read BIP 143.

Neither, it isn't an integer. It's a byte array, do not modify.

It is extremely likely that you are parsing the hex strings into bytes improperly (or maybe not at all). What do your "hashFromString" and "hashFromStringLE" functions do/work?

Also, the signature is not a hash nor anything little endian, so I don't know why you are passing that into a function named "hashFromStringLE". It isn't hashed either.

Lastly, as has been said multiple times, RecoverCompact takes 65 byte signatures which you can retrieve from the 72 byte one by extracting R and s. Again, R and s BOTH may have leading 0 bytes due to signed integers. You can drop the leading 0 byte so that both R and s are 32 bytes long. If they are shorter than 32 bytes (that is possible), then you need to pad 0's in front of them until they are 32 bytes.

The first byte of the compact signature needs to be a recovery id.

If you have done everything correctly but are still getting the wrong public key, try different recovery ids. There are 4 possible public keys you can recover from the signature, the recovery id just specifies which of those 4. Since you don't have a recovery id, you need to just guess.

Given that Satoshi's coins are in Pay to public key outputs, the pubkeys are publicly available already. So if we assume Satoshi is dead or otherwise gone, his coins moving would actually be an indication that Quantum computers exist because the only way for them to move (assuming he is no longer around) is for someone to have been able to compute the private keys to those exposed public keys, presumably via quantum computer. In general, it would mean that the ECDLP is has been broken in some way (regardless of QCs) and should no longer be relied upon (i.e. we should move off of ECDSA and Schnorr).

It is impossible for the sender to know whether the redeemScript is a standard script. The address is a P2SH address, which means it is the hash of a redeemScript. The sender does not know whether the redeemScript is standard, or even valid, because they don't have the redeemScript, and there is no reason that they should.

Furthermore, because the redeemScript is a public key hash, even if the sender had the redeemScript, they wouldn't know whether the public key is compressed or uncompressed unless they had the public key. And there is no reason they would have the public key either.

It is the receiver's job to ensure that the coins are spendable by them, not the sender. It is in the receiver's best interest that they can spend the coins. Why should the sender be sure the receiver can spend those coins? It would be a severe hindrance to have to check that the receiver could spend the coins, and may even make it less secure for the receiver.

Core does not allow accepting non-standard transactions on mainnet. There is a -acceptnonstdtxn option that can be enabled, but it does not do anything on mainnet; it only works on testnet and regtest. However, it is trivial to change that, there is just one if block that can be removed to allow accepting non-standard transactions on mainnet.

So it would be pretty easy for a pool operator to run a slightly modified version of Core that accepts non-standard transactions.

ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction. But if it is included in a block, it is still consensus valid and all nodes (including miners) will validate and accept it.

Standardness only applies to the relay of unconfirmed transactions. It has no effect on transactions in blocks.

His script isn't P2SH-P2WSH, it's P2SH-P2WPKH. It's key hash, not script hash, so it's still RIPEMD160(SHA256()), and the documentation does say that.

Apparently yes.

The documentation is wrong and should be fixed.

It won't be because the transaction is consensus valid. Blocks have never been rejected for containing non-standard transactions.

If you don't think it is consensus valid, you can test it yourself. The getblocktemplate RPC allows you to submit a block proposal. It is just a block that does not have a valid proof of work, everything else needs to be valid (scripts, signatures, merkle root, etc.). That block proposal is validated for everything except the Proof of Work (and no attempt is made to relay it). The RPC will tell you whether the block proposal is valid (everything passes validation) or what the specific validation error is if not valid. So if you make a block proposal with OPs transaction, you will find that it is in fact consensus valid.

Here is a python script that will connect to a bitcoind and check whether the given txs are consensus valid: https://gist.github.com/achow101/51751f10f394ec1a5fb1cd77a3e30181

The thread was linked in the message...

Sure, but it's not some random website or link. Bitcoin.org is still somewhat trustworthy. And tbf, Bitcoin Core releases are still posted to bitcoin.org in addition to bitcoincore.org.

Checkpoints are still there. They are effectively consensus required. So if someone wanted to make a fake bootstrap.dat, they would have to fork from the most recent checkpoint (block 200000 something) and still do all of the work to mine valid blocks.

It actually isn't. It's just the original bootstrap.dat file (that is no longer being updated) that people previously used. Notice how it is hosted on bitcoin.org.

The original thread announcing it is at https://bitcointalk.org/index.php?topic=145386.0. That message is signed with Jeff Garzik's old PGP key: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3710408162759fc5a4296536e7a58e337adca079

Because it isn't any faster to use the bootstrap.dat file. It has not been faster to use it since 0.10.0 when headers first sync and out of order download were first introduced. The bootstrap.dat file was useful prior to that, but it no longer is.

The reason it is slower to use the bootstrap.dat file is because it just contains the blocks. Your node still has to read them off disk and validate them. It also happens to be one big file and the node does not know where each block is in that file, so it can only go through it one at a time. This is much slower than how syncing works now where multiple blocks are downloaded in parallel, and because the node is the one writing them to disk, it also knows exactly where in each file the blocks are stored so they can be pulled up later for the final step of validation. This parallelization also allows validating things that are independent of each other to be done in parallel which speeds up the sync.

It is important to note that the primary slow down in syncing is due to the processing, storage (disk I/O), and validation of blocks, not the network speed.

It isn't really "1 byte for sign". Rather they are big endian signed integers. Because R and s cannot be negative, there is an additional byte added in order to make them a positive signed integer as otherwise they would be interpreted as a negative value which is not valid.

You have an off by one error in your code somewhere. s begins with 009c.... The 0x21 byte is the length.

Even so, s would still be a 33 byte value. This is because, again, DER requires positive signed integers. However compact signatures use big endian unsigned integers which are always positive. This means that in converting from DER to compact, you can drop leading 0x00 bytes as those are only there to make the integer a positive signed integer.

The size of a compact signature here does not refer to just the r and s values. It also includes one additional byte for the recovery id. This is because compact signatures in Bitcoin are only used for signed messages which do public key recovery (as you are trying to do). The recovery id is the first byte of the signature, the rest is the compact signature that you expect (32 byte R followed by 32 byte s).

It's important to note that while you can choose to use different encodings for P2P and storage, consensus does require the transactions be serialized in a specific way for hashing and for weight calculations. So while you could serialize blocks and transactions using more compact integer encodings, you still need to be able to serialize everything correctly for txid computation and weight calculation.

With Schnorr signatures, we're finally getting rid of these. The signatures will be the 64 byte "compact" signature. The R and s values will be a fixed 32 bytes and none of the DER stuff surrounding it. Also the sighash byte can be ommitted for SIGHASH_ALL (which is the sighash type used by almost every transaction).