There is a dust limit on the transaction outputs as per the protocol rules. It is generally about 546 satoshis.

This means that each of the output of the transaction should be larger than the 546 satoshis. How much are you trying to send? Before sending, can you check the transaction by pressing 'Preview' and check if any of the outputs are lower than 546 satoshis?

If I'm not wrong, as per BIP35, nodes can send a mempool message to each other for updates to their own mempool.

A node could send a mempool message to the other nodes for information of their mempool. The response will be an inv message which gives a full list of the TXID in the mempool.

Given the adoption rate and maturity of lightning network, I would say it is rather tough for the network to be scalable. As compared to the major payment processors, Bitcoin can't handle as much transactions. If the adoption increases exponentially, the lightning network would be the technology used to scale it.

In addition, with the current state of the world, there are still certain areas without an internet connection. It would be easier for them to just use fiat directly instead.

Your address is a P2SH address. This means that there are conditions for which the signature has to fulfill in order for the signature to be valid. This could be in the form of multisig or P2WSH over P2SH.

Try to determine the type of address it is. If possible, try to explore the page to find the redeem script, the private keys associated with the address.

As long as someone has a copy of the Bitcoin source code, they can continue to run a node and continue to maintain the network.

It is possible to wipe out the blockchain however. If there isn't anyone keeping a copy of the blockchain secure (from nuclear attacks and to protect it against possible EMP blast), the blockchain could be wiped out. If that happens, all of the transaction history would be gone and Bitcoin would start again from square one. If the blockchain archive lags behind the network by X blocks, the transactions after that would be gone too.

There are two main ways for a node to function; by the use of the IP address or by its onion address. The use of the nodes on the network is to relay information (ie. Blocks, transactions). The node do not request or receive signed messages from others. Since the nodes would verify the contents sent by the other nodes, it isn't necessary for them to identify the other nodes. If any of the nodes misbehaves (by sending incorrect information repeatedly) , their peers would just disconnect them.

Tor works by anonymizing your connection through the use of nodes which bounces your traffic within the nodes before having the traffic exit through a node called exit node. Your traffic is encrypted while it is transferred within the tor network and when it exits through the exit node, the only encryption of your traffic is by the SSL that Bitcointalk uses.

This means that the final exit node can see the traffic in plaintext if your traffic isn't encryption. Since Bitcointalk implements HSTS and that Tor has HTTPS Always built in, it isn't that big of a problem. Your privacy is definitely guaranteed by the proper use of Tor and that should be your only aim if you're using Tor.

It's a lot more convenient to keep a copy of Electrum running. Assuming that you're not going to use the wallet that much, you can just create it on an offline computer, get the master public key and keep the seeds safe. By importing it onto the Electrum wallet, you'll be able to obtain the address that could be generated from the seeds and it's balances. It would act just like any other Electrum wallet, less the ability to spend its coins straight.

It is not a requirement for the verifier to have the public key of the address used in the signature. The address is NOT the public key but rather, it is the hash of the public key. With the use of ECDSA and the secp256k1 curve, you can determine the 2 possible public keys used to sign the message. The client will then hash the address given by the user to check if it matches the key. Brainwallet can even show you with the address used to sign the message if you don't provide them with one.

Online wallets are most likely actively logging your IP for security purposes and for their own internal logging. You can't hide your actual IP without the use of a proxy. When broadcasting your transaction, it would be tougher for others to guess the origin IP of the transaction and it would be much more inaccurate.

If the attacker holds enough percentage of the nodes, the attacker could guess the IPs with a better accuracy.

You can't use Electrum with wallet.dat. The wallet formats are different and you have to export the wallet.dat into private keys before importing it into Electrum.

Does the pywallet show all your addresses? Can you try running Bitcoin Core with -salvagewallet as a flag?

Dont send your wallet.dat to anyone and keep multiple backups of it.

You do not mine transactions. You include transactions in a block and hash the block headers (which includes its merkle root) to generate a hash with the matching difficulty. It is more of a security feature to have a certain level of difficulty when mining blocks.

Mining pools have payment strategies (PPS, PPLNS) which gives the rewards when you attempt to contribute to the pool's efforts to getting a block.

There's a simple solution to this possible problem. The reference nodes do not relay transactions that are already in their mempool, unless it has an Opt-in RBF flag. This means that if there is another transaction that spends the same input as another transaction in the mempool, the client would automatically reject that transaction and thus it would have a bad propagation. It takes quite a while for the transaction to be dropped from the mempool of the individual nodes in the network. Until then, you won't be able to double spend the inputs. Even if it does get dropped, the casino can simply just rebroadcast the transaction and it would be back in the mempool.

Of course, this could still be successful in certain instances but with a proper risk management, the losses suffered by the casino would be negligible.

Malware can still function without an internet connection and the information can still transmitted the next time the computer is connected to the internet. It would be better to get a cleanly wiped computer and generate a paper wallet on it instead.

---

That being said, I'm not a huge fan of paper wallets either. It is too much of a hassle and you'll have to find a way to clear the cache off your printer if you want to be completely secure. Using an airgapped and clean computer, get Electrum and generate a wallet. You can simply write down and remember the seeds and addresses. The next time you want to spend it, just boot up a livecd and install Electrum on it. It'll eliminate the need for printers and you'll be able to store a lot more addresses on a single piece of paper.

Most wallets have a fixed gaplimit which specifies the number of unused addresses to be generated from the seed. This would mean that if you've generated 21 addresses and you use the 21st address, the wallet won't generate the 21st address and would instead only generate up till the 20th. Different wallet has different gaplimits and that might be the issue here.

It's just a simple attack involving social engineering of the telecom companies. It's really nothing new and that this kinds of attacks is fairly commonly used to target accounts that were secured with their phones. These attacks are particularly vulnerable with sites who uses SMS based authentication instead of token based authentication. With the accounts obtained, the attackers would get more information to be used and social engineer their next target.

The main prevention is to not store large amounts of coins online.

The speed of you getting a transaction in the block is not fully dependent on the number of transactions with low transaction fees. Your transactions are only competing with those who have paid a larger fee/size for their transactions. It doesn't matter if there are thousands of transactions paying low fees, as long as you pay a higher fee than them.

The block height field takes reference from the time that your node sees the unconfirmed transaction. It does not mean that the transaction is included in the block but it simply means that your node saw it when the latest block is X. It is of course quite inaccurate to be used to gauge the time where the transaction was sent.


It contains transactions that are in not yet included in a block. When it sees a transaction, the node automatically purges the transactions that are in that block from the mempool.

It doesn't. There is no use for the client to keep multiple copies of the same transaction, especially when Bitcoin Core is resource intensive enough.

That's wrong. Orphan blocks still occur once in a while but they are less common with the better connection between the mining pools. Mining pools are often listening directly to each other and thus it is less likely for orphans to occur.  It was more common in the past whereby the propagation of the network was much slower.

The version of your Bitcoin Core is from a few years ago and that is before most of the protocol change and standards that affected Bitcoin. Your transaction was likely non standard and it wasn't propagated properly.

The wallet backup is your wallet.dat file. With that, you can recover the wallet even if you wipe your whole wallet. To get your wallet.dat file, there should be an option in the client to export a backup. If not, you can go to %appdata%/Bitcoin on your computer and you should be able to see the wallet.dat. After backing it up and making multiple copies, you can safely install a newer version of Bitcoin Core. 0.01BTC as fees is too excessive and not required.

Edit: You can't send any coins if you have a password on your wallet.