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).

It shouldn't be necessary for moderators to babysit particular users like that. Such off topic posts have to be removed or edited (it's generally frowned upon to edit posts though) because posting off topic is against forum rules. Starting a flame war is also against forum rules. Why shouldn't we ban people who repeatedly violate forum rules? I don't think it is fair to other posters and to moderators to have to let people violate forum rules and then just clean up after them.

But he doesn't just present a different view point. He repeatedly flames other users and creates off topic posts. The fact that his posts often result in the locking of threads is pretty telling. Many people have challenged him and presented their side. His responses are usually some twist of words, snide remarks, or insults and they further drag the thread off topic. There are numerous personal and direct insults in his posts.

Many of his posts begin slightly on topic, e.g. in a thread about lightning he might mention something about lightning, but then start talking about segwit (which is somewhat related) and later block sizes. People will then respond correcting the incorrect things he has said about lightning, segwit, and block sizes. Then responses begin focusing on the incorrect things he has said and repeated back and forth. So the topic goes from discussing lightning to people arguing back and forth. Such a thread has now be derailed and taken off topic. Eventually insults are thrown and people start flaming, at which point it is necessary to lock the thread.

Now consider that this has happened to multiple threads, with largely the same catalyst (same set of posters, which includes franky1, making posts that result in thread derailment and locking). Given that this repeatedly happen, I, and apparently so does gmaxwell, finds this to be in  violation of the No Trolling rule.

It has nothing to do with preventing certain viewpoints from being posted, that's perfectly fine. It's that the same user constantly does it in threads where those opposing viewpoints are really relevant to the topic.

I don't think SMF really allows that. It's just that gmaxwell has decided to delete any post that franky1 makes in Dev & Tech, and has announced that decision publicly. It's close enough to a ban so that's what he called it.

Note that I was not involved in the decision to ban Franky1.

I do not think that it is unreasonable for him to be banned from the Development and Technical Discussion forum. While he may have "gave his honest opinion", he frequently posts in threads that are largely not related to his opinions and instead almost always starts talking about blockstream, segwit, "core censorship", etc. when those topics are irrelevant to the thread. He just repeats the same things over and over again. Ultimately, his participation in the Dev & Tech forum causes those threads to become derailed and devolve into flaming and mudslinging which results in those threads having to be locked. His posts in any thread that mentions the Lightning Network or segwit inevitably results in any meaningful discussion to be lost and eventually stopped. Due to the negative effect that he has had on actual technical discussions, I find that it is reasonable to have him banned.

No.

Presumably because those are the other secp curves that could have been used.

It is not the bit length of the private key. It is a byte length of a DER encoded private key as denoted in ASN.1 in the SEC standard: http://www.secg.org/sec1-v2.pdf.

This private key contains the private key itself as well as all of the curve parameters and the public key which makes it much larger than just the private key itself. So that it means it has the private key, the public key, the parameters for the curve equation, the finite field for the curve, the generator curve point, and the order of the generator. There are several 32 byte values, along with several bytes of overhead due to DER, and some more bytes for version numbers. This makes the total size of a private key encoded in this way to be 279 bytes.

The reason this encoding was used is because that is how openssl encoded private keys. This encoding is still being used for private keys in the wallet storage in order to maintain backwards compatibility. When compatibility was not necessary such as in the introduction of encrypted wallets, the private key was encoded just as itself thus significantly saving space.

IIRC the plan is/was to bootstrap rustc ourselves via guix. Although right now Bitcoin Core trusts Canonical for deterministic builds (Gitian uses Ubuntu), the plan is to move to guix for purely deterministic builds on all platforms (guix builds all dependencies deterministically). However, because we are currently trusting Canonical anyways, I think it was decided that it is okay to use rustc from Canonical until we get guix working.

My impression was that it would be failover, then in parallel, and then possibly, the main implementation. So at some point, both the rust and c++ implementations would be used to cross-check against each other. But then again, I haven't followed this conversation too closely.


The main issue I have with rust in Bitcoin Core is just the fact that there will be far fewer reviewers. I personally would have to learn rust.

The other point of contention is whether rust will actually reduce the number of major bugs in Core. C++ already does things that lets us not have to worry about some memory things, so it isn't as bad as c where it is very easy to forget to free a pointer. But we still can and do get segfaults due to null pointer dereferences so rust would certainly help there. But if you look at a lot of the other bugs that have been in Core, most of them have been logic errors. Rust would not help with those, and it could potentially make them worse as less people know rust.

At the end of the day, I'm personally +0 on rust. I mostly don't care, but would not be opposed to having rust in Core. It would be nice to have better compile time memory protection, but I don't think that's a super big issue that really needs to be fixed.

That warning is benign. There is no way to get rid of the warning, and that the warning exists does not cause any problems. You can safely ignore it.

Satoshi's wallet is not one address or public key. It is tens of thousands of individual keys because he did not reuse them. Being able to find a private key that he used would only let you spend 50 Bitcoin.

You don't seem to understand how close to 0 it is.

It is literally impossible to have the probability of collision be exactly 0 because that would require an infinite search space which is literally impossible (would require infinite matter and infinite energy which do not exist).

There is no way to prevent it because whoever produced the collision would have an equally legitimate claim to the Bitcoin.

It is far more likely that if there were a collision that it was the result of a bad implementation of the RNG and of the crypto library used in general.

In those cases, the public key is in the blockchain as part of the output. The output is a P2PK output. Bitcoin does not use public key recovery anywhere in transaction validation.

R and s are part of the signature. The signature is a DER encoded signature, and the breakdown of the encoding is given by Coding Enthusiast above.

It is. In Bitcoin, it is one item: a DER encoded signature. Because it is encoded, it can be further broken down into the R and s components. This is done by signature verifiers; Bitcoin itself (i.e. consensus and the script evaluator), do not care that it is encoded and just treat the signature as a single array.

The key itself can be broken down into X and Y components, each of which are of the same magnitude of R and s. The key is also encoded.

The message is the double SHA256 of the transaction with some modification. For your specific example/question, this SE question and answer should be sufficient: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx.

They are not. The signature is not a curve point.

R is the X component of the "public key" of the nonce. S is just a scalar computed by the ECDSA formula.

There is no function in Bitcoin Core to do this because it is never done and not needed.

Yes. Note that higher difficulty means that the target value for that block is lower than the target value for the block at the current tip, not that one block's hash is lower than the other's. Given two blocks that descend from the same ancestor, this is impossible.

When two competing blocks are received and their PoWs are equal (as two blocks descending from the same ancestor would be), the first block received is the one that remains on the tip. The second block is kept, but marked as stale. It is still tracked, so if another block is received extending the stale block, then the node will mark its original tip as stale and switch to the new most difficulty chain (a block mined on top of the stale block makes that branch the most difficulty).

Yes.

No. If you could, there would be a whole lot of forks.

Yes. Syncing is basically just this updating. The main thing is that while syncing, certain functionality is disabled to avoid operating with an old chain tip. There are a few optimizations to speed up syncing (e.g. assumevalid and minimumchainwork), but the process of receiving and validating blocks during sync is pretty much the same as receiving and validating them during normal operation.

Bitcoin Core cannot sign non-standard scripts.

It's not technically the password hash. Bitcoin Core stores a master encryption key which is used to encrypt the actual private keys. This master encryption key is encrypted with the user password after it has been through some key stretching (the specific parameters of the key stretching and encryption can vary, so these are stored along with the master encryption key). So you can extract the encrypted master encryption key along with its metadata from the wallet.dat file (not hard to do with existing BDB dump/modification tools) and bruteforce against that to get the password.

This only reveals the password and the master encryption key, not the private keys themselves. So funds are safe if only the master encryption key record is given.

Only if coins have been sent from that address. Only then can you look at a spending transaction and see if the redeemScript is a segwit script. Otherwise, you cannot.

No, that's completely wrong. It has nothing to do with the encoding.

Before segwit, the txid was the hash of the entire transaction. For non-segwit transactions, this is still true. But after segwit, some new data was added to transactions. This is not hashed as part of the txid, only those parts that were part of the non-segwit transaction format are hashed. The hash field was introduced for segwit as the hash of the entire segwit transaction.

When you see the txid and hash are the same, the transaction is non-segwit and both the txid and hash are hashing the entire transaction. When they are different, the transaction is a segwit transaction and txid is hashing some parts of the transaction while hash is hashing all of it.

The numbers there (bnNew, bnPowLimit, etc.) are not the difficulty. The difficulty value that we often see is not directly part of Bitcoin or the blockchain itself. Rather what we see in the blockchain is the target value. The target and difficulty are inversely related, as the target increases, the difficulty decreases. This is because mining works by finding a hash that is less than the target value, so by having  a larger target value, there are more possible valid block hashes and thus a lower difficulty.

The numbers bnNew, bnPowLimit, etc. are all compact representations of the target. This is then expanded out to a full target value that the block hash is compared to. This compact target value is what is included in blocks as the nBits field.

Bitcoin already limits the target to a maximum value which is equal to a difficulty of 1. If the target is that maximum value, its difficulty is said to be 1. This value is not explicitly listed in that function because it is different for mainnet, testnet, and regtest. This value is the variable that has the word powLimit in it. It is defined in src/chainparams.cpp.

There are two things that you are doing wrong: you are doing your limiting incorrectly, and you are doing the limiting after the built in limiter. Firstly, because difficulty decreases as target increases, you need to make the comparison a greater than operator (>) not less than (<) as you have done. If the target is above the maximum target, it needs to be decreased. What you done is set a target minimum, not a difficulty minimum. Look at the line directly above the one you added, that is the built in limiter that is correct. Secondly, you don't need to add your own limiter. Just change the powLimit variable for the correct blockchain in src/chainparams.cpp to the maximum and the limit will be done for you.

In fact, what you are asking has already been done. So I think you just fundamentally misunderstand how the PoW target actually works and what a difficulty of 1 actually looks like.

What software are you using to decrypt the key?

Because you are printing out the address of chSalt, not its contents. You are doing this everywhere that you have &. Why are you even putting & in front of things? Putting a & in front of a variable name gets a pointer to that variable, not any of its values. If you wanted to dereference a pointer to get the value it points to, you use *. But none of these are pointers, they are references which are treated exactly the same way as values. If you run it again, you will get different results because of different memory locations.

---

What are you trying to even accomplish?

Yes.

Within CMasterKey, vchCryptedKey is the encrypted master encryption key. This key is decrypted using a key derived from the user's passphrase (with key stretching parameters specified withing the CMasterKey. The decrypted encryption key is now a CKeyingMaterial and stored as vMasterKey in CWallet.

Encryption keys (along with some metadata) are stored in the wallet.dat file. They are encrypted by a key derived from the user's passphrase.