Yes. However transaction selection is not determined by the absolute value of the fee itself but rather the fee rate in BTC/kB. The higher fee rate you pay, the more likely your transaction will be included.

Getting your transactions confirmed requires a transaction fee, mining itself does not. Miners generate Bitcoin through the coinbase transaction which is a special transaction in every block. The coinbase transaction creates an output which is typically the sum of the current block subsidy and the sum of the transaction fees paid by the transactions in the block. It essentially produces this out of thin air; there is no previous output it spends from.

It depends on the transactions. If you included a high enough transaction fee on each transaction and each one does not spend from any outputs created by one of the transactions, then you can expect all 30 to confirm. If you have a high enough fee but they all spend from a transaction that is one of the thirty (i.e. 2 spends from 1, 3 spends from 2, 4 spends from 3, etc.), then you can't expect all of them to confirm.

No, they won't stop hashing. Most miners will not be using asicboost right now because it requires software that does the preprocessing for asicboost to be used with the miners and a different firmware on the miners themselves to be able to use asicboost. Furthermore, the stratum protocol is incompatible with ASICBOOST (at least the covert version, which is what is apparently being used) so people who are using antminers are not using asicboost right now, and making asicboost impossible to use would not effect them.

Disabling ASICBOOST by a protocol change would make the miners operated by Bitmain and those who received the special software and firmware from Bitmain would only make asicboost unusable and thus take away their advantage. It is unknown who is actually using asicboost besides the miners operated by Bitmain.

Bitcoin Core generates several private keys, their respective public keys, and the associated address, before you request a new address. These are saved to the wallet.dat file and then read from that file when you need to use them.

You cannot delete individual private keys. Deleting private keys would be a very good way to shoot yourself in the foot and lose a lot of money, so Bitcoin Core does not provide such a functionality. If you want to delete all of the private keys, you can just delete the wallet.dat file.

If you want to delete specific private keys, no, it is not possible. Bitcoin Core does not provide this functionality because it is a very good way to shoot yourself in the foot and lose a lot of money.

If you want to delete all of the private keys in a wallet, you can delete the entire wallet.dat file.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1857669.0

Duplicate thread

Yes. If by longer you mean has more total work (that is the definition of a longer blockchain), then the other node, once it received the longer chain, would switch to using your longer blockchain so long as it still met all of the consensus rules that that other node is following.

When you sent again, it is possible that you did not spend the same inputs spent in the abandoned transaction. If the abandoned transaction has confirmed, then you would have made the payment twice.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1856990.0

Duplicate. Wrong forum anyways.

Except no one has been able to replicate it. Greg also showed that he tried to replicate the bug but got the expected error.

They certainly don't understand it to the degree that they want everyone to think they understand it.

Here's a reddit thread with links and sources detailing most of the incompetency of the BU devs: https://www.reddit.com/r/Bitcoin/comments/61bkqe/the_astounding_incompetence_negligence_and/

Were you able to identify the Remote DoS bug there?

The point is that even with changes that aren't "earth-shattering" they lack any code review whatsoever. The BU devs also have demonstrated that they don't understand the code that they are modifying. In the post where they went over supposed issues in Core, they made several claims which were later debunked by Greg He also said that "AFAICT many of issues were actually caused by changes they made to code they didn't understand."

BU has recently had 3 publicized and exploited remote crashing bugs. Here's a thread on reddit discussing the first two. These bugs allowed people to send specially crafted messages over the P2P network to a BU node and cause it to crash thus taking it offline. These bugs are a result of large changes with little or poor code review. Two of the 3 bugs was first introduced in PR 36. As you can see from looking at the PR, there was very little commentary prior to it being merged, no one ACK'ed it, there is no indication that anyone had even reviewed the code. The third bug was added in PR 43, which, much like the previous PR, is a very large change which does not have a lot of review and very few comments about the changes even though the changeset is quite large. There is only one person who reviewed the code, and even in the end, he doesn't give an indication of approving the code before it is merged in. This lack of review makes BU more prone to severe bugs like the aforementioned Remote DoS bugs and potentially even changes to wallet code that can risk your Bitcoin.

There is more to the BIP system than just block size increases and scaling solutions. Proposed block size increases make up a very small fraction of BIPs. Furthermore, BIPs are not used only by Core, but rather nearly every other popular wallet software or service uses the BIPs in order to implement things in a standardized way to make all software compatible with each other. One such example of commonly used BIPs are BIP 32 and BIP 44 which specify the derivation process for Hierarchical Deterministic wallets and that standard is what allows people to import the BIP32 master private and public keys into multiple wallets.

You can get the raw transaction for a txid if the transaction has already been created. However, it does not work the other way around; you cannot make up a txid and make a transaction out of that.

No. You need to post at least once in each activity period in order to gain activity.

Do not use the bootstrap.dat. That is an old and outdated method for syncing. It is actually slower to use the bootstrap.dat to sync now. Just let Core sync normally.

It can only increase at most 14 for every two week period. So at the next activity period, you will have 28 activity.

Those listening nodes still need to connect to the network. They usually, on first start, will connect to a DNS Seeder and ask it for some nodes to connect to. Generally these nodes are ones that have high uptimes and high bandwidth. The seeder will also record some information about the node that asked it for data in case it is a listening node so that it can send nodes to connect to that node as well. So there are then two ways to get information about non-listening nodes; run a DNS seeder, or operate a high uptime, high bandwidth node that gets lots of connections.

The second method doesn't really work that well since Bitcoin Core puts a maximum of 125 connections so it can't actually get thousands of nodes connecting in order to get accurate data. What Luke-Jr does is he operates a DNS seeder and builds his information off of there.

The DNS seeders are hard coded into the software. There are currently 6 DNS seeders, one of which is Luke-Jr's.

That is simply impossible. You cannot send more money than you have. Bitcoin does not work that way.

Can you please post the txid of your unconfirmed transaction?

Except no one from Core was refusing to work with them nor have they shut them out.  Many now are refusing to work with BU due to BU's active hostility and toxicity towards them. Would you want to work with someone who shit on you, talked trash about you, and insulted you all day? Because that is what the BU devs are doing to the Core devs yet they (and their supporters) somehow expect the Core devs to voluntarily contribute to their project should they become the reference implementation.

Regarding the BIP process, the BU devs most certainly were not shut out at all. In fact, they were explicitly invited by Luke-Jr (current BIP editor) to submit their BUIPs as BIPs as well who even offered to go and assign a BIP number to every single BUIP (even though I don't think those BUIPs meet the standard for BIPs, i.e. not enough specifics for implementation in the document) but they explicitly rejected the offer and refused to work with the process that every single other developer in the Bitcoin ecosystem has been using to standardize every protocol change.

Furthermore, the BU developers are explicitly alienating the Core developers with their childish and rather unprofessional behavior of posting about suspected bugs in Core in blog posts rather than responsibly reporting them to Core through the issue tracker. Instead of reporting bugs responsibly when they find them, they wait days, weeks, to report them, and do so using outside channels instead of the bug reporting channel. Conversely, people on Core have pointed out bugs in BU to them through their official bug reporting channel (github issue page) and when proposals with implementations have been posted to the mailing list (Matt Corallo reviewed Tom Zander's reference implementation for FlexTrans). Greg Maxwell has said that he found several sever vulnerabilities in BU which he reported to them but they never responded nor did they patch the bugs.

In what way is the BIP system broken? So far, what BU has come up with seems to be even worse than the BIP system. At the very least the BIP system has defined what it is supposed to do, what can be considered a BIP, and what needs to be included in a BIP before it will be accepted, given a number, and added to the repo. AFAICT, no such document exists in the BUIP repo.

BIPs are not affiliated with Core. Core is not involved in what is accepted as a BIP (they don't have to like it or agree with it for the BIP to be given a number and added to the repo, e.g. FlexTrans, BIP 134).

With every single change, there will always be people who do not agree with it. BU happens to be that group of people right now. Yet Core and segwit has been able to gain the support of the a significant number of wallet developers, exchanges, and services while BU has not.

Furthermore several hundred individuals, organizations, and companies have indicated that they support Core.

Documentation for Core has been around for a very long time already. The doxygen docs were added in 2011, for version 0.5.1. For BIPs to be considered for final status and deployment, they must be well documented. They have to have enough specifics about the change so that anyone can independently implement the BIP just by reading the BIP. Hell, the code is, IMO, very well commented and has comments that explain what everything does.

Now, I understand that it wasn't always like this (and granted, there are still some undocumented parts that are basically holdovers from the very early days, and those are not consensus critical), but with so much documentation already, if BU wants to become the reference implementation, they need to be able to match the same code quality and documentation quality of Core. They keep advocating for multiple implementations, but the only way to allow multiple implementations is to provide enough documentation that people can independently implement everything, which, as of now, is not the case with the BUIPs.

Then you are not redownloading the entire blockchain. Just because you see the progress bar there does not mean that you are redownloading the blockchain. Look at what it says next to that. In your screenshot, it says "Reindexing" which is exactly what it is doing.