There are many reasons, but it mostly comes down to technical debt in Bitcoin Core's codebase.

Originally, Bitcoin Core did not build a UTXO set. Instead it indexed every transaction in the blockchain and would look up transactions directly. So when a new transaction arrived, it would lookup the transactions specified in their inputs and check whether the specified outputs were marked as spent. There was no separate UTXO set as we do today. So to get the UTXOs for an import, you had to rescan the entire blockchain. Even after the change to construct a separate UTXO set, this hasn't really been changed.

The second issue is the wallet itself. The wallet does not work with UTXOs. It uses entire transactions, which you cannot get from the UTXO set. The wallet computes the balance by iterating through every transaction stored and checks whether each output belongs to it before adding its amount. So there is no explicit UTXO set in the wallet either, it has to check every transaction it stores. Because of this, we cannot use just the UTXO set as we require storing the entire transaction, even if only one UTXO as actually ours.

The last reason is that users expect to be able to see their transaction history and be able to look at transaction details. Both of these are not possible without a rescan. Just the UTXOs do not provide the transaction history, and the UTXOs also do not give any other details about the incoming transaction.

---

Reworking the wallet so that you can just scan the UTXO set (and so that does things with just UTXOs too) is on my list of things to do. But there are other priorities in the wallet right now as what it does now is still mostly sane.

This method of pruning was never implemented. Bitcoin Core uses a different method for pruning that is more efficient.

With this method of pruning, parts of the merkle tree is still stored, not just the root hash. It's more than just the block header. As transactions get spent, their txids get pruned from the merkle tree and the intermediate merkle branch hashes are stored. So if you were to perform a double spend, looking up the input would fail either because the txid is no longer stored as it has been hashed with others into a merkle branch, or it is still there but the particular output you are spending has been marked as spent. Either way, it is still safe.

But this is not as efficient and harder to reason about than how Bitcoin Core does pruning today. Bitcoin Core today builds a separate database of just the UTXOs. As a block is processed, all of the transactions are verified and the UTXO set is updated. When a block is done processing, it actually doesn't need to keep the block around because the UTXO set is what determines the chain state. So in Bitcoin Core, after a block is deep enough, its transaction data is discarded in entirety. The block header is still kept in another database, but the block data itself is deleted. This is safe because all of the important information, the UTXOs, are stored separately in the UTXO database. So if a double spend were to occur with a transaction that has been pruned, the output being spent would not exist in the UTXO database and thus that double spend is invalid.

Sad to see another topic get derailed into another block size and LN argument. /locked

Didn't work last time I tried it, but that was also a while ago, so I probably just misremember.

generatetoaddress is for regtest only. It is only used for testing purposes. It cannot be used on mainnet.

Bitcoin Core no longer has mainnet mining capability. This has been removed for a long time because it is not worth CPU mining (as mining with Bitcoin Core was). Even if you do use a version of Bitcoin Core that has mining capabilities, you will never find a block.

If you just want to learn how mining works, do it on regtest or testnet. You will need external mining software. Running a CPU miner on mainnet won't get you anything. You probably won't find any shares that can be submitted to a pool either.

Go to Help > About Bitcoin Core not Help > About Qt

That's not WIF, it's not a private key.

How did you compute this P2SH address?

I've imported that private key and it does not produce a P2SH segwit address with an uncompressed pubkey. The address that Core produces (the one that you have listed) has a compressed pubkey. What makes you think that it is uncompressed? That you have calculated a different address?

---

Your calculated P2SH address is incorrect and will result in lost funds.

You have hashed the public key and just made that hash the hash inside of the P2SH. That is incorrect. The public key is not a script and it is not the redeemScript. The correct thing to do is to produce the Segwit scriptPubKey, hash that, and put that hash inside of the P2SH.

The Segwit scriptPubKey is 00146b227b4934af1a8f9648b40c3614dec300abf435. Note that it contains the pubkey hash but has more to it than just the pubkey hash. The hash of this script is a91a60e23a8ce5654cbefb50cdee7c05acfc82b1 which means that the P2SH scriptPubKey is a914a91a60e23a8ce5654cbefb50cdee7c05acfc82b187. This corresponds to the address of 2N8fMnWYo2h9JfZZvYFnPC73baYn5E3oyiU produced by Bitcoin Core.

It should be in getnetworkinfo under localaddresses. It should also be logged in your debug.log file.

A node will connect to many peers in a way that is unlikely to have many peers that are also behind. The reason for this is twofold. Firstly, a node will store a database of peers and some information about those peers. When it starts up, it chooses peers from that database and chooses them based on some "goodness" information it stores. Secondly, if that database is too small or has a lot of offline nodes, then it will use the DNS seeders. The DNS seeders will filter for nodes which are up for a long time so new nodes will be connected to seed nodes that know many peers. Those nodes will return additional nodes for new nodes to connect to based on node uptime and other characteristics. So peer discovery itself will select for nodes that have been up for a while and thus are likely to have the latest block.

But even if all of the peers are just coming online, they too will be connected to other nodes and syncing their own blockchain. As they receive new blocks and block headers, they will be able to serve them to their peers. So if you are only connected to nodes that are still syncing, you will still sync from them as they sync their blockchain from their other peers.

It is a bunch of heuristic tests that just check for whether the node is likely to be not synced. It is used to disable certain functionality that is dependent on a recent blockchain (IsIBD will return true before being fully synced).

Other nodes will just send invs to all of their peers regardless of sync state and other status. It is up to the receiver of those invs to do something with them. Because your node is still syncing, it won't request those transactions as it might not be able to validate them yet.

Yes.

Transactions cannot be canceled. There is no undo nor can you force any nodes on the network to forget about your transaction.

You can try to replace a transaction with another if you have it set to signal BIP125 RBF. In your original transaction, you need to set the replaceable argument of createrawtransaction to true. So you would do something like
That 0 is needed for the locktime. Setting it to 0 just means no locktime.

When you send your replacement transaction, you need to use the same inputs but also pay a higher fee. Note that replacing a transaction is not guaranteed to work. Not all nodes support RBF, and various network issues may cause your original transaction to still be mined. Furthermore, you can only replace transactions that have not yet been included in a block.

That is not true. decoderawtransaction will decode unsigned transactions. This is intentional. Users need to be able to decode and understand their transaction before it is signed

Use a lowercase t. so it's true not True.

There is no private information contained in a transaction that can cause Bitcoin loss. Transactions are completely public information, so anyone can go look up your transaction in a node anyways and learn all of the details that you have tried to hide. The only "private" information are txids which may allow others to link this transaction to your identity which reduces your privacy.

---

The difference in size is because you are comparing your unsigned transaction to the signed one. createrawtransaction creates an unsigned transaction signrawtransactionwithkey will modify the transaction and add signatures to it.

This is not secure. I can generate my own priv and pubkey pair, subtract everyone else's pubkeys from that to get a different pubkey, then claim that calculated pubkey is mine. When all those pubkeys are added up, you get the pubkey I generated which I have the private key for. So now I can use my private key to produce a signature and steal coins. I would be able to do this with any other UTXO for which I know the pubkeys for without needing anyone else to be involved.

I don't think there is a secure way to do this with ECDSA, or if there is, it will be fairly complicated. ECDSA does not allow signatures to be combined linearly which makes this difficult.

What you are describing is a technique known as Cross Input Signature Aggregation. This is an idea that has been around for a while, and using Schnorr signatures, would be possible. Schnorr signatures can be combined linearly and there are now secure pubkey aggregation and signature aggregation schemes that have been developed using Schnorr signatures. The proposed Taproot and Schnorr signatures BIPs do not include Cross Input Signature Aggregation, as it requires more complicated changes to transaction formats, but do introduce Schnorr signatures themselves. So in the future, we could deploy Cross Input Signature Aggregation into Bitcoin using Schnorr signatures.

There are consensus rules regarding what the version number can be. But there is no consensus rule saying that the version number must be a particular value.

E.g. there is a rule saying that the number cannot be less than 3. But there is no rule saying that it must be 4, so it can be 4, 5, or any other number so long as it is greater than 3.

A soft fork isn't required to use a different version number. Some numbers cannot be used, but, for the most part, miners can set whatever block version number they want. This is what allows them to use the version number to signal soft fork readiness and also allows them (unfortunately) to use asicboost.

Compact int isn't very compact. There is not much space to be saved there, and really no reason for the version to be a super expandable field.

Ah, yes, that's right. Because they have the same txid, they would be treated as the same transaction even though the contents are different. So if a node received the malleated one first, it would ignore the correct one later, and vice versa.

Yes, the scriptWitness is malleable.

While you could malleate a transaction to be larger, I'm not sure why you would. You can't change the fee that is paid by that transaction, so your malleated one would have a lower fee rate than the original, so it would most likely be rejected in favor of the original. That also means that the malleated transaction is less likely to show up in a block than the original transaction. Additionally, such malleation would make the transaction non-standard, so most nodes would discard it regardless of whether they had seen the original.

You can use Lightning Loop style swaps to rebalance the channel. Essentially, after the subscriber runs out of funds on his side of the channel, he can perform a Loop In swap where he sends the balance with an on chain payment and then the service sends the same amount back to the subscriber over their payment channel. This swap is enforced by Bitcoin scripts so that it is atomic.

For example, if the user has paid 1 BTC in subscription fees and now his side of the channel is empty, he sends 1 BTC to the service on chain, and the service sends 1 BTC to him over their channel. The net result is that both sides have the same amount of money, the channel can continue to be used for payments, and the service now has BTC that they can actually use as it isn't tied up in the channel.

This means that channels don't need to be continually closed and reopened, just every so often a Loop In swap is made.

You will need to create accounts on https://travis-ci.org/ and https://www.appveyor.com/ and link them to your GitHub. Then you can enable builds for your cloned repo. They will then automatically build when you push.

travis-ci and appveyor and completely unrelated to your error, and to MSVC. They are services which automatically build Bitcoin Core and run tests and are used to check Pull Requests before they are merged. They are not for building Bitcoin Core locally.

Because it would be dead code and dead weight in the codebase. IIRC the CPU miner got fairly complex because it was using different CPU instructions and extensions and various tricks to make computing SHA256 hashes faster. This means that it was complex. If the CPU miner was still in Core, it would still have to be maintained which adds additional burden on developers. It means that refactors are a bit harder. It means that we would needs tests for it. Because it would be consensus related, it means that people have to review it more carefully, and if there are bugs, those have to be fixed. There would be feature requests related to the miner to do things like make it support Stratum and pool mining. In general, more work is required to maintain it, but it is a feature that few, if any, people would use at all. It was eventually decided that it was not worth maintaining a feature that basically no one used, so the CPU miner was removed.

Even so, there were other mining software that had more efficient CPU miners and more mining features than Core even when it still had a miner built in. So people who wanted to CPU mine weren't using Core anyways.

That's because blocks don't contain the hashes. If it did, then you'd lose the transaction data itself which means you can't validate the transactions themselves.

The merkle tree is used for proving to clients that don't have the full block that a given transaction is in that block. A full node can provide such a client the block header and the path of merkle branches to a particular transaction so the client can be sure that that transaction was in the block.