Bitcoin Exotic 8Q: Why was block 620826 born 1 second earlier than block 620825?

Write in front:

Regarding Bitcoin, we sometimes encounter technical problems that are difficult to understand, such as "new blocks are born 1 second earlier than the old blocks", "whatever the size of the full node is different at the same time" and other strange phenomena. For these problems, we need to Ask professional developers for help. In this article, the translator chose 8 relatively interesting questions, and the gods from the Bitcoin development community also gave wonderful answers.

(Note: The following questions and answers are from bitcoin.stackexchange.com)

(Picture from tuchong.com)

• Satoshi Nakamoto may be the creator of Monero. Do you accept the findings?
• A war on asset devaluation: BTC will witness the occurrence of financialization
• Monthly Financing Report | Global Blockchain Private Equity Financing in March was 3.767 billion, 90% of the funds flowed to the US market

Question 1: Why are two fully synchronized Bitcoin Core nodes different in blockchain size?

Detailed description of the problem: When executing getblockchaininfo , the size of the size_on_disk display is 1.2 GB smaller than other nodes reported at the same time (block).

txindex = 1

What could be the cause? I have asked other peer node operators on twitter to see if anyone else has the same experience, but everyone has more ledger data than me. (Https://twitter.com/bitdov/status/1231915231368163328)

Ugam Kamat: The difference in the size of the blockchain is due to the number of stale blocks stored by the nodes. Obsolete blocks are blocks that once formed part of the main chain, but are not now part of the main chain.

For example, if a miner mines 2 blocks at a height of 102 at the same time, when a miner relays a block through the gossip network, the network closer to miner 1 will receive it first than the block mined by miner 2 (102b). Mined block (102a). Bitcoin core adds the first valid block received to the top of the chain. Later blocks received at the same height will not be deleted, but will be saved in the database to prevent reorganization. Therefore, if the next block 103 is mined on block (102b), the node that first received 102a will reorganize its chain into a chain containing block 102b, as shown in the figure below.

Bitcoin Core does not delete any valid blocks received from its peers. It is always stored in the blocks / blk ****. Dat file in the database (this is the same for the blocks in the main chain). However, the software does not relay stale blocks. To receive stale blocks, you need to be online when your peers broadcast blocks to you from different chain views. Peer nodes will only broadcast those blocks that they see from the current active chain. Therefore, you will only have stale blocks that you receive when you are online.Due to this variability, the Bitcoin blockchain size of many nodes is different. Question 2: I tried to synchronize the entire blockchain with the bitcoin-core client, and it took me about 9 days, but the result was broken, so I had to delete and resynchronize. Are there any resources that can be downloaded via torrent or regular browser?

chytrik A: If you download the blockchain using torrent or other methods, but do not verify the received data, then you will not know whether the received data is valid. This means that you may easily download a maliciously changed blockchain by an attacker, which may include fake transactions, delete legitimate transactions, etc., which are all unknown to you.

That's why bitcoin-core takes time to download and verify the blockchain: this is the only way to get the current network status without trust.

Please note that bitcoin-core is most effective in downloading chain data. If you download a blockchain torrent and then try to use it for verification, it will take longer (you need to wait for the full download and then complete the verification Instead of executing each part in parallel).

I don't know of any software that can perform these verification steps more efficiently than bitcoin-core. If the RAM utilization is insufficient, you can try increasing the -dbcache option. Question 3: Why was Bitcoin 620826 block born one second earlier than 620825 block?

Andrew Chow Answer: Bitcoin does not require the time stamp of the latter block to be later than the previous block. The only requirement is that the time stamp is greater than the median of the last 11 blocks. Therefore, this means that a block can have a lower timestamp than its parent block within a certain range.

The 620826 block is earlier than the 620825 block, because the miners do not have a fully synchronized clock. Their internal clock may be slightly different, so it may be delayed for a few seconds. If a miner is really lucky and finds another block quickly due to different clocks, then due to the different clocks, his clock may still be behind the timestamp of the parent block. This is probably what happened here. Question 4: Can I run two Bitcoin nodes with the same wallet?

Detailed description of the problem: We have a Bitcoin full node and wallet on the server. The problem is that most of our wallets have been synchronized long ago. It seems to us that this synchronization task may take a lot of time, during which all other requests will not be able to access the Bitcoin node and users will not be able to use our server.

We consider copying the current Bitcoin node on a separate server and synchronizing the wallet there. After completing this process, we will copy the wallet back to the original server.

Is this feasible? Or can't we have the same wallet on two different Bitcoin nodes?

Gašper Čefarin: This is possible, you can run as many nodes with the same wallet as you need. I think you did this because the synchronization process would be faster on another node? After the process is complete, you must copy the complete blockchain data, not the wallet itself.

You may need to consider the bottlenecks to check, which might be hard disk, CPU, or in some cases Internet bandwidth. Question 5: Why doesn't the hash public key actually help against quantum computing?

Detailed description of the problem: In the discussion about taproot, it was mentioned that the output will directly contain the public keys, rather than hashing them. Some people say that at present, hashing can't really help against quantum computing. Why?

Andrew Chow Answer: Although hashing a public key itself does help against quantum computing, in fact, it will only be like this in a "vacuum" condition. Public key hashing does not exist in such an environment. Bitcoin has many other things to consider.

First, if the public key is hashed, the funds are protected only before they are used. Once the P2PKH or P2WPKH output is used, the public key is made public. When the transaction is unconfirmed, an attacker with a quantum computer fast enough can calculate the private key and create a conflicting transaction, sending the funds to himself instead of the intended recipient.

In addition, if the attacker is a miner, they can do this for every transaction, simply refusing to mine transactions that do not send coins to themselves.

Although this is a problem, people generally think that it is better than spending Bitcoin directly because they have the public key in the blockchain. Although this is true, there is a large amount of public public key output.

There are currently more than 5.5 million BTC outputs with public public keys, either because of P2PK output or because users are reusing addresses, so their public keys are public in other transactions. So if there is a quantum computer that can generate a private key for a public key in a reasonable amount of time, this is the bitcoin that an attacker can obtain.

So, although your specific outputs may be protected by a hash, the value of these outputs will be 0 because millions of BTC will be stolen. What hashing can really do is provide a false sense of security.

In addition, there are some problems with tools and wallet software, they just publicly disclose public keys in transactions and blockchains. No existing tool treats public keys as private information, and they have no reason to do so.

There are other problems with complex scripts and contracts involving public keys. These scripts (such as multisigs) do not hash public keys. In addition, these contracts usually exist because not all parties must trust each other (one of them may be malicious ), In which case the malicious participant in the contract will know the public key involved and be able to steal bitcoins related to these outputs. Existing public key hashing cannot prevent this.

Finally, if a quantum computer is found that can disrupt ECDLP, it is possible to transition to a post-quantum cryptosystem. If it is detected in time, but it is still too late to perform an appropriate upgrade, all the use of the signature algorithm that relies on ECDLP (ie, ECDSA and Schnorr) can be soft-forked to lock all coins. These coins can then provide some non-public or quantum-resistant information by providing a zero-knowledge proof that indicates the ownership of the private key.

For example, users can provide evidence that they own the BIP 32 seed used to derive the corresponding private key for a given public key. Since it is a zero-knowledge proof, the seed itself is not public (note that the seed is not part of a public-private key pair, so there are no shared public components). Since most wallets use BIP 32, this is sufficient. Perhaps there are other ways to prove ownership without taking the risk of an unthinkable coin.

Of course, all of this assumes that a quantum computer can calculate the private key of a public key, but the public does not know that the technology already exists. It is actually more likely that the development of quantum computers will be observed, and sometime before they are powerful enough to break ECDLP, Bitcoin will softly introduce a quantum-resistant signature algorithm. Eventually, signatures that rely on ECDLP will be deleted. All of this will happen before quantum computers really become a threat. So in this case, the hash public key will not help anyway.

Please note that all of the above is not limited to quantum computers, it is generally applicable to any cryptographic breach of ECDSA (or Schnorr). Question 6: How can I get the private key by two signatures sharing the same k value?

Detailed description of the problem: In order to create a test, I wrote my own ECDSA signature algorithm. Using it, I created two signatures, issued from the address 1GXFXm3es …, and generated transactions 56ec7ca7df … These signatures use the same k value ( Although the value of k can never be reused).

Later, someone stole 0.0016BTC from the 1GXFXm3es …. address and sent the money to 17WRjamox6VhTUaHsTWfFnMNDYHvwCtWio.

Therefore, someone must be monitoring the blockchain for such errors and stealing funds when encountering such errors.

So how do I get the private key from two signatures that share the same k value?

Pieter Wuille answers: The ECDSA signature is a (r, s) pair, where r = (kG) .x mod n, and s = (m + rx) / k mod n, where x is the key and k is a random nonce And m is information.

For the same key with two s values ​​s1 and s2 and the same nonce k (and thus the same value r), you can do the following:

1. s1 = (m1 + r * x) / k
2. s2 = (m2 + r * x) / k

From this we can draw:

1. s1 * k = m1 + r * x
2. s2 * k = m2 + r * x
3. (S1-s2) * k = m1-m2
4. k = (m1-m2) / (s1-s2)
5. x = (s1 * (m1-m2) / (s1-s2) -m1) / r
6. x = (m1 * s2-m2 * s1) / (r * (s1-s2)) (all mod n)

So not only can you easily detect signatures with the same random number (they have recognizable r values), but once someone sees two signatures, there is a simple formula to calculate the private key.

Such attacks have been widely known since at least 2013, and some people are actively using it. Do not reuse k values. Use RFC6979 to determine but generate them securely.

Also note that different k values ​​are not enough, and they cannot be linked together in a known way. For example, you cannot use k values ​​for one signature and then k + 1 for the next signature. Question 7: Why does Bitcoin choose Merkle proof instead of RSA accumulator, what are the advantages and disadvantages of the two?

Pieter Wuille answers:

1. The RSA accumulator is difficult to implement correctly; 2. The RSA accumulator requires a trusted setting (single or multiple entities must get a sufficiently large integer, which is the product of 2 prime numbers, and then discard these prime numbers). Bitcoin is usually designed to avoid trusted parties; 3. For a 128-bit security level, you need at least a 3000-bit RSA module, which means that the proof will be 3000 bits. This is just an advantage compared to Merkle paths with more than 12 layers of trees, which means more than 4096 transactions for transactions in a block. This is usually not the case, and even so, it is just barely. Question 8: Are all three Bitcoin address types interoperable (legacy, segwit, native segwit)?

Detailed description of the problem: Is it possible to send transactions back and forth between all 3 address types (legacy, segwit, native segwit-bech32)?

Or one kind cannot be sent to the other?

Pieter Wuille: At the protocol level, they are all compatible, and transactions can cost any of them and send to any of them.

Wallet software may of course have restrictions, but these restrictions are usually not related to the combination. Murch added:

In the Bitcoin protocol, there is no limit to sending from any type of output to any address type, but some older wallets may not support sending to newer address types.

Let's better understand what might happen when sending a Bitcoin transaction:

The recipient chooses an address where they want to receive funds, which involves an address format, and choosing a more efficient address format can save money, which is in the interests of the recipient.

The sender selects the input they want to spend, and the input script is set by the type of address received before these outputs. However, senders are motivated to choose a valid address type for their change output to save future costs.

However, older e-wallet software may not be able to send to newer address types. Specifically, the original Segregated Witness address only received the address standard (BIP-173) in March 2017, and not all wallets support sending to such addresses. In this case, the sender should provide an encapsulated segregated witness address. All wallets should be able to send to the encapsulated segregated witness address because it uses the Pay to Script Hash (p2sh, BIP-16) address standard introduced in 2012.

In any case, the problem of sending to any particular address type is caused by a lack of functionality in the sender's wallet and has nothing to do with the type of input used.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!