Yes. SPV wallets are not actually verifying the transaction itself as they can't. They can only check whether it is in a block, and even then, they have to trust that the data they are getting from the node is correct as they can't verify whether a block is valid without having verified the full blockchain.

Instead of requesting each transaction individually, request the block with verbosity level 2 (just another parameter with the value 2). This will also include the JSON data for each transaction instead of just the txids.

Connections, both inbound and outbound, are rarely closed unless one peer goes offline. So listening and non-listening nodes will change their peers at about the same frequency. Outbound connections in general might change more frequently as we have stricter criteria for who we connect to and when to disconnect from them than we do with inbound peers.

That commit was reverted: https://github.com/btc1/bitcoin/commit/98c0af58c29efbecba25818adb5531fa8c3d0506 so that is no longer a viable method.

This topic has been moved to Trashcan.

Duplicate thread

The point is that SPV wallets can't and don't "simply verify transactions". There is no verification that can be done without having the transactions that a transaction spends from.

That's also not true. A transaction is not necessarily deep in the blockchain. SPV wallets allow you to receive unconfirmed transactions and sometimes spend from them. You can also spend from transactions with one confirmation; those are definitely not "deep in the blockchain"

Yes, I agree that not everyone is going to run a full node, but current SPV wallets are not a decentralized self verifying experience at all.

That is not at all how difficulty works and not where it is changed. What you changed was the output of an RPC command, not any actual internal behavior.

First of all, Bitcoin does not actually use the difficulty number in mining. It uses a 256 bit integer called the target and a block's hash must be less than that target value. That target value is in turn used to calculate the difficulty value for us humans to understand, but the difficulty value itself is not used in Bitcoin anywhere.

Do change the difficulty, you will need to change this value to false: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L281 and modify these two functions: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L49 and https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L13 to give you a target that matches the difficulty that you want to have.

Yes, you could do that. That would reduce the UTXO set. You wouldn't need to have all your coins sent to the same address in the first place, although if they were, there is then no harm to your privacy.

The transaction will confirm eventually, you do not need to do anything. If you think the transaction is taking too long to confirm, you can increase the fee.

No.

Yes.

A lot of them are spam or low value. I will delete posts from people who clearly do not read the thread and just post the same thing that someone else posted earlier in the thread.

Replaceable means that the transaction conforms to BIP 125 and can be replaced by a transaction which spends the same inputs but includes a higher transaction fee.

Post your debug.log file.

You actually were mining. Bitcoin Core contains mining code for regtest. The difficulty of regtest is low enough that a CPU can mine a regtest block nearly instantaneously. The generate and generatetoaddress commands will perform mining operations.

As there shouldn't be. Those are not mining commands, so blocks will not be mined after they are run. Blocks are not found for every single transaction.

To mine on the regtest network, you just need to use Bitcoin Core's generate or generatetoaddress commands.

There actually are multiple transactions in the blockchain which have the same txid. These transactions are coinbase transactions included in blocks prior to the deployment of BIP 30 and BIP 34 (and were the impetus for BIPs 30 and 34). Only the most recent transaction of a transaction with duplicate txids is the one that is considered to be spent from and included in the UTXO set. The other transactions with the same txid have provably burned coins as they are unspendable. BIPs 30 and 34 have since disallowed duplicate txids and made it nearly impossible for duplicate txids to occur (except when there are hash collisions).

Pieter Wuille has been working on this. A mailing list email about this is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html

What he has been working on is a way to do rolling UTXO set hashes so that the UTXO set can be committed to the blockchain to allow for UTXO set syncing. Once we figure that out, the rest is fairly trivial.

That is untrue. A SPV wallet cannot fully verify a transaction. It does not have the UTXO set, so it cannot fully verify it. Even if it does know the previous transactions, it does not know the transactions that those spend from and so on. If it did, it would basically be a full node, which they are not. Because an SPV node does not have the UTXO set and has not verified the chain of transactions that a given transaction is part of, it must trust the node that gave it the transaction and trust that that node gave it the right transaction and that the transaction was valid to it. Without the previous transactions, it cannot verify that the input script is correct. Without the previous transactions, it cannot verify that the amounts in the outputs are valid.

This idea is known as UTXO syncing and is something that has been proposed and though about for several years now. It is still being worked on and to enable UTXO syncing would require a fork. Enabling UTXO syncing requires that each block commits to the entire UTXO set. People are working on ways to securely and efficiently commit the UTXO set but all of that is still being researched.

Yes.

Just because bitnodes is unable to connect to your node does not mean that your node is offline or not connected to the network. That website only knows about nodes which accept incoming connections. It is likely that your node does not accept incoming connections (i.e. your router or something else blocks incoming connections to port 8333). Your node can still make outgoing connections and connect to other nodes so you are still connected to the Bitcoin network. Even with just outbound connections, you are still contributing to the network as you are still receiving, verifying, and relaying all blocks and transactions.

I don't think you understand how forums work. This is not like Reddit where the topic is a link to something else. Each topic is a thread where people make comments about whatever they want. The first post of the thread is "the topic". Everything else is a response to that post (or another post in the thread). This is analogous to self posts on Reddit except there are no comment threads where people respond directly to a comment like on Reddit. Because all other posts are responding to the same topic, each post is titled with "Re: ..." automatically as that stands for "reply about X".

Performance doing what? Electrum does a lot of things and each has its own "performance". These include things like syncing, network bandwidth, key generation, storage, etc. What kind of performance do you want to optimize?