The hash of your genesis block does not match what your software says the genesis block hash should be.

It doesn't become any number. Code is just text to a computer and is completely meaningless until it is compiled. That number will never have meaning to a computer because it will never be compiled into machine code that has meaning to a computer.

Compilers don't understand human comma separating for numbers. This code should fail to compile.

Scams are not moderated; we leave that up to the community to police itself. That is why there is a trust and feedback system.

Bitcoin Core 0.16 intentionally makes it more difficult to generate legacy addresses because we want to move towards segwit by default (particularly bech32). Thus there isn't really an easy way to make legacy addresses from within the GUI.

However you can use the debug console (or RPC interface, i.e. bitcoin-cli) to generate legacy addresses when -addresstype is not set to legacy. getnewaddress has a new address type parameter that lets you specify what type of address to generate.

They get it by deriving a lot of addresses from the xpub and then looking up the transactions related to those addresses. They follow the BIP 32 specification for deriving public keys from a parent public key.

Yes

Trust is not inherently tied to a transaction. Trust can be given for any reason. While a trade is what is most obviously something that warrants trust (or mistrust), people can do other things too that warrant trust. Furthermore, the forum has no idea of whether a transaction took place, and it is difficult for moderators to verify that.

They aren't obligated to respond to you, nor are the moderators.

It is not a moderator issue, the trust does not break any forum rules. Some people like to also give negative trust to people who they believe to break forum rules, in addition to reporting the user to moderators. They are allowed to do that.

That's not how Satoshi put text in the genesis block. The text was put in the coinbase (aka scriptSig of the coinbase transaction), not in an output. Many miners still do this today, usually to identify who mined the block.

Trust is not moderated unless it is blatant spam.

Schnorr signatures is actually a somewhat broad topic that includes many things. Schnorr signatures are a cryptographic scheme, but to actually be used in Bitcoin, you still have to use that cryptography in a specific way besides just the signature algorithm itself. There are certainly insecure ways to use Schnorr signatures, just as there are insecure ways to use ECDSA or RSA signatures.

Yes, there was. There was a scheme using Schnorr signatures for key aggregation that was originally thought of that was insecure. But this doesn't mean Schnorr signatures themselves are insecure, just that specific cryptosystem that happened to use Schnorr signatures.

It would mean that, at worst, sensitive data such as private keys (but not necessarily private keys) are revealed which allows an attacker to be able to forge or create a signature that he should not be able to. This could result in coins be stolen.

Not really. The cryptography itself can be proven to be sound. It is just mathematics, there's nothing special about it. For example, the key and signature aggregation scheme that uses Schnorr signatures that is likely to be used - MuSig - has a formal security proof that takes up a large part of the paper describing that scheme. Since it is just mathematics, the proof, assuming that there are no errors in it (so it needs review from other cryptographers), proves that the cryptography is sound assuming that the discrete logarithm problem is hard (which we currently do assume). This means that any software which follows the spec for MuSig will not create anything that results in sensitive data being leaked.

Of course there could be some insecure implementation of MuSig, but that's not a problem unique to it. There have been many insecure implementations of ECDSA which has resulted in lost coins. Even secure implementations that use a bad PRNG results in leaked private keys.

It certainly will. But with regards to the cryptography itself, the scheme itself will probably not be accepted unless it has a formal security proof.

The network is not some private network thing that is pingable or has its own block of IP addresses. There is no "network IP" or "network domain"; it is just many machines that have opened connections to each other and are sending data to each other using the Bitcoin network protocol.

This topic has been moved to Trashcan.

Duplicate

I don't think any Bitcoin 0.7 nodes were actually crashing. They were simply unable to validate the larger blocks created by 0.8. None of the threads from that time indicate any sort of software crashing.

For reference, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-March/002235.html, https://bitcointalk.org/index.php?topic=152030.0. Here's also writeup explaining the events of the fork and the actions that were done: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-bitcoin-fork-centralized-decision-making-saved-the-day/

Can you print them in hex? The negative makes things slightly harder to check things.

The X component of m's Pub is correct and iL * G is also correct.

Before you do the adding, can you print out what you get for
and

Make sure that those are what you expect them to be.

The only thing that can be wrong here is that either you are adding the wrong things or Point::add is broken.

They were able to build new blocks, and new blocks were in fact being built on both sides of the fork.

What happened was that miners who were using Bitcoin 0.8 had the majority of the hash rate, so they were finding blocks that were invalid to 0.7 nodes. IIRC miners still use 0.7 nodes were able to find blocks, just much more slowly. Then once the fork was known to have happened, the Bitcoin 0.8 miners downgraded to 0.7 and resumed mining on the 0.7 fork of the blockchain. Once that fork over took the 0.8 branch, all nodes once again began using the same blockchain as the chain valid to 0.7 was valid to 0.8 and had more cumulative work.

I suggest you read the post-morten BIP, BIP 50

BIP 91 Reduced threshold for enforcing Segwit activation. It happened but code enforcing BIP 91 was never merged into Bitcoin Core. The author of the BIP is also not someone that many would consider to be a Bitcoin Core developer.

No, the "New" button in the "Receiving Addresses" dialog was removed. You can still generate bech32 addresses with the "Receive" tab; nothing has changed there.

Yes

For compatibility reasons. Earlier versions of Bitcoin Core (including the original Bitcoin 0.1.0) used OpenSSL to do key operations. When keys were written to disk, they used the OpenSSL format which includes all of this extra data. Later, when key encryption was introduced, it was decided that for encrypted keys we could use a different format (since encrypted keys are already backwards incompatible with earlier versions). So for encrypted private keys, we only store what we need, not the full extra stuff. We could bump the wallet version and change the unencrypted key storage format to just be the private key, but no one has bothered to do that and it really isn't all that important.