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.

If your OS is 64-bit, download bitcoin-0.13.2-x86_64-linux-gnu.tar.gz. If you use a 32-bit OS, download bitcoin-0.13.2-i686-pc-linux-gnu.tar.gz.

For both, extract the folder inside, named bitcoin-0.13.2. Inside that folder are three folders, bin, include, and lib. Copy those three folders to /usr and merge them with the folders already there. Once that is done, you can start Core by running bitcoin-qt in the terminal.

It depends on your OS. That link has more than just the .tar.gz. It has every other binary file that is made with the releases in there.

A backup of what? The datadir?

If you have a backup of the datadir, then you can just replace everything inside of the datadir with the contents of your backup datadir, except the wallet, you will want the most recent wallet file.

Put the bitcoin.conf file in your datadir, E:\Bitcoin\BitCoinData. That is where it needs to go in order to be properly read by Core.

Bitcoin Unlimited has demonstrated a lack of understanding of the code that they are working on and have introduced multiple critical bugs. Their code review process is non-existent.

The BU developers are also extremely toxic. They refuse to work with every other developer in the Bitcoin community. They have refused to use the BIP system which is used by everyone else in the Bitcoin community (not just Core) in order to standardize proposals and make sure that different implementations of the consensus rules still follow the consensus rules. Furthermore, BU's BUIP system is extremely lacking in technical documentation that allows other developers to work on separate implementations of a BUIP.

The very nature of how BU is conducting themselves is that they are making it extremely difficult for multiple implementations of Bitcoin to exist; their documentation for stuff like Emergent Consensus, the specific system that they are using, XThin, etc. is so bad that no pretty much no other developer can actually independently implement any of them. Thus you will be stuck with just whatever the BU developers put out, and they have shown that what they do produce has many issues.

Those settings set the fee rate in BTC/kB, not the actual fee itself. IIRC, there is no way to set an absolute fixed fee now because you really shouldn't be using an absolute fixed fee.

Your question is a bit hard to understand. So you basically want someone to pay you without them knowing that they are paying you? Or do you mean routing payments through a hub without the hub knowing that you are routing payments through him?

Either way, I don't think it is possible because each hub in the route will need to create an HTLC and change the balance of each channel involved in the payment, so they will know that a payment is being routed through them.

In theory, yes. In practice, maybe not.

You should batch your payments and send to multiple addresses at the same time. This will reduce your transaction fees and reduce the amount of transactions that you will need to create.

Once the lightning network is up and running (and that could take a while) you should use that as it will reduce your transaction fees even further and reduce the number of onchain transactions that you will need to make.

I have rebroadcasted the transaction for you so that it can propagate better.

The issue here is that the transaction did not propagate well, so not many nodes now about it (for example, mine did not). By rebroadcasting it, it should reach more nodes and thus reach miners and be more likely to be included in a block. It should confirm fairly quickly due to your absolutely massive (and completely unnecessary) transaction fee.

You're late to the party. "Your idea" has been discussed for years now, and already implemented and already in use. Look up BIP 152 Compact Blocks or BUIP 10 XThin blocks (both operate conceptually the same, but are wholly different from each other).

It does nothing about the fact that months after your proposal activates, when I restart my node, it will have either a completely empty mempool, or a mempool that is completely outdated. Either way, if a new block is found immediately after I start my node and I receive that block, the mempool on my node is not likely to have all of the transactions in that block. Even if it did, those transactions would not be there for more than 15 seconds if I received the block less than 15 seconds after starting my node. It will still consider that block invalid, and I will still have to wait for 3 more blocks to be found on top of it before I can actually use my node properly.

"A few blocks" can take anywhere from 30 minutes to a few hours. Do you realize how long you would have to wait in order for the wallet to actually become usable? That is a huge usability problem. Also, a lot of people may simply run their wallet for a few minutes a day to receive or send some Bitcoin. It takes a couple of seconds to sync the last day of blocks and then the wallet is immediately useable. They use it for a few minutes, and then shutdown. These people (and most people for that matter), don't have time to wait 30 minutes to a few hours for their wallet to actually become usable. There is a possibility that they would have to wait this long many times that they start their wallet, not just the one time wait for initially syncing a wallet.

No they don't. Miners don't have to relay transactions at all. They can just assume that a transaction has already been propagated. Even if they do attempt to relay a transaction, a node that already has a transaction isn't going to re-relay a transaction just because another node relayed the transaction again to them. If they did, that would be a huge DoS vector.

No, initially you called it "invalid blocks" which encompasses more than just your "undesireable blocks"

Oh really?
You are not specifying that it is the best VALID chain, just the BEST CHAIN which can include invalid blocks.

If you did not change any settings regarding the location of Armory's data directory, then the folder will be on your C drive. It is typically at C:\Users\<username>\AppData\Roaming\Armory.

This topic has been moved to Trashcan.

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

Duplicate thread. Original here: https://bitcointalk.org/index.php?topic=1853420.msg18438180#msg18438180

Click the arrows. It's a tree structure.

In Armory, uncheck the "Let Armory run Bitcoin Core in the background" Checkbox. Stop Armory. Start Bitcoin Core. Let Bitcoin Core sync. Then start Armory again.

Actually, I read that part of the spec incorrectly.

From the spec:

So you can have a channel where one party puts in 0 funds, but once that party's balance is greater than the channel-reserve-satoshis, their balance cannot go below that minimum so that they always have something to lose if they try to broadcast an older commitment.

-reindex and -reindex-chainstate are command line options for when you start Bitcoin Core. They are not commands that you enter into the debug console.

If something is corrupted and requires a reindex, usually Core will let you know when you start it and it will begin the reindexing process when you continue to let it run. It will appears as if it is syncing and redownloading the blockchain (and if you pruned, it will be), but in reality it is reading the blocks on the disk and reindexing them, not redownloading the entire thing. However, if you do have pruning enabled, it will have to redownload the entire blockchain (and do the normal pruning thing) because reindexing requires walking through the entire blockchain again from beginning to end.

What files exactly did you delete?

Contrary to popular belief, there is in fact no signalling activation threshold for BU. It requires miners to analyze the community and see how likely a larger block would be accepted by most nodes and to then manually change a configuration option to mine said larger block.

IMO it is unlikely that BU will activate any time soon. However, you should keep an eye on what the operators of many large pools are doing and what BU is doing to see if a hard fork is imminent. Prior to a hard fork, you should move all of your Bitcoins off of an exchange to a desktop wallet so that you will have BTC and BTU coins post fork. If you don't care about BTU, you can keep your Bitcoin on the exchange as nearly all exchanges said that BTU would be listed as an altcoin if and only if they have replay protection, and those exchanges will still allow BTC trading and withdrawals.