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.

Those additional bytes are for the elliptic curve parameters and the full public key. This format is described in http://www.secg.org/sec1-v2.pdf section C.4

You interact with bitcoind with the JSON-RPC protocol. So you can use cURL to do that. Or you can just copy a version of bitcoin-cli to your server. It's just a wrapper that can speak the JSON-RPC protocol, particularly for bicoind. It is a separate portable binary.

There's more to a computer than just the OS. A lot of firmware such as processor microcode are closed source. So it doesn't matter whether the OS you use is open source; if the firmware for your hardware and the hardware itself is closed source, then you are at risk of that closed source being malicious or containing something that can be exploited. One example of this is the Intel Management Engine which could allow someone to remotely access and control your computer and there's no way to disable it because it is baked into the hardware and firmware, both of which are also closed source.

stdMainNetDNSSeed is the array of DNS seeders for the mainnet. DNS Seeders are used by Bitcoin Core on the first run to get nodes to connect to.

pnSeed is an array of fallback seed nodes that Bitcoin Core can connect to if it is unable to find nodes to connect to from its own database or from the DNS seeders.

The error with peer banning is happening because a block that it read is probably corrupted and that block is marked as invalid. Then Bitcoin Core will try to continue to sync from its peers, but those peers are sending it the block that it had marked invalid so it will ban those peers. Eventually it will ban everyone it could get a connection to. To fix the peers banning problem, stop Bitcoin Core, delete the file named peers.dat, and start Bitcoin Core again.

I suspect that you have a hard drive failure. You have experienced what appears to be two cases of corrupt blocks on your hard drive. I suggest that you run hardware diagnostics to see if it finds anything wrong with your hard drive. You should stop running Bitcoin Core for now as it won't be doing anything if it can't sync the blockchain.

Yes (basically). Once a transaction is confirmed, it is, by definition, no longer replaceable under BIP 125, therefore the field bip125-replaceable will say "no".

There's actually a bit more to whether something is actually replaceable than just the signalling. That is included in the checks for labeling a transaction as replaceable.

Just because a confirmed transaction signals it does not necessarily mean that it was actually replaceable when in the mempool.

I moved it for you, but next time, do it yourself (OPs can move their threads) or use the report to moderator link.

Commits were last pushed on 3/19/2018 while the commit date is 10/10/2017. This happens because people will amend their commits and force push, but amending does not modify the commit date.

Without the chainstate, it doesn't matter because your node will validate the blocks anyways and fetch whatever it doesn't have.

The argument only matters if you are copying over the chainstate too since then you have to trust that the chainstate you are copying has not been modified. Usually you can trust yourself and your computer so it really isn't an issue. It's only an issue if you have malware or someone has maliciously accessed your computer.

To make it easier to implement HD into Core with minimal review. There are plans to generate HD keys on the fly instead of storing them in a keypool.

This is a known issue. Just use the receive page.