No. The size of a block does not matter in how quickly the block is solved. A block with no transactions and a full block both have the same probability of being the solution.

In reality the network only handles around 2-3 transactions per second. 7 tps is only a theoretical maximum with optimal conditions; it's a scenario that never happens.

Yes there are plans on increasing this, it's the whole block size/scalability debate that is happening and has been for a while. In Bitcoin Core, the current plan is to implement Segregated Witness which has an effect of essentially doubling the block size limit which will increase the number of transactions the network can handle. Then later there will be additional scaling plans which may also include increasing the block size limit.

Yes. A transaction simply takes in inputs and spits out outputs, it doesn't care what the addresses are, so long as the input script properly spends the output script of the output it spends.

Awesome, I'll check it out. It has come a long way since I last looked at that!

Sent from

Can you post the raw transaction here? I don't see it in my node (not surprising). There are some instructions here: https://bitcointalk.org/index.php?topic=161311.0.

Please do not double post, instead post this in your original thread.

Can you provide the txid?

The transaction may simply disappear, in which case the Bitcoin will simply appear to return to you as if you had never spent them.

I made a transaction that was Opt-In RBF but I didn't replace it. It confirmed, but that transaction, when I try to open up details from the transactions ledger, shows up with the same error mentioned by pop9119.

Edit: Rescanning the databases did not help

Edit 2: A rebuild and rescan didn't work either.

Well if this is for a prize, then I think that he should figure it out himself instead of asking for others to do it for him.

Try the documentation at bitcoin.org: https://bitcoin.org/en/developer-documentation.

I did ask for that. I can write you a command line script which does this.

It can be modified to work with other APIs like blockchain.info's.

Also, it isn't code, it is pseudocode which is just logic, not actual code.

Edit: what OS do you use? I can write you a batch or shell script (os dependent) that does this. I can do it in a few hours after I get to my computer.

Shorena has already given you the pseudo code for it. You already have the logic, you just need to implement that in whatever programming language you want as a program or script which connects to bitcoind to get the data you want.

Based on this error I think that you may have a hardware problem with your memory. Maybe try doing a hardware diagnostic and see if it finds any problems

Why do you keep assuming that it renamed the file and moved it somewhere? Bitcoin core saw the file, tried a salvage and then deleted the file when it was done because it didn't need it anymore. That file is gone.

Since you said you have a backup of the old wallet, restore that and you will get some bitcoin back.

If the receiving addresses in your current wallet look familiar to you, then you probably have the private keys to your addresses so your can get your bitcoin back. You just need to initiate a rescan so it can find the transactions in the blockchain.

Can you please provide the entirety of your Debug.log file?

Transactions do not work by balances, but rather inputs and outputs which have a certain amount.

If your first transaction spent from a 20BTC output as its input, then 10 BTC will go to one output which the vendor can spend from and 10 BTC to a change output that you can spend fun. Your second transaction would then spend from the change output. These two transactions are not identical, and identical transactions in bitcoin cannot exist because they are the same transaction and treated as such.

The two transactions can confirm in the same block but if they don't, the second must confirm after the first because it spends from the first transaction.

Rebroadcasting s transaction doesn't drain the balance of an address. It simply reminds the network that there is a transaction spending from some inputs to some outputs but the data is still the same so it is treated as one transaction.

Unless you made a backup, there is probably a low chance of recovering the coins.

However the data might still be in the wallet.dat file since bitcoin core won't just delete it even if the data is corrupted. What you should try doing is starting button core with the salvagewallet option and see if that can salvage anything from the corrupted file.

A wallet is a collection of different private keys. Public keys are derived from private keys. There are 2^256 - 1 possible private keys and thus that many public keys.

Some wallets are Hierarchical Deterministic which means that they have one master private key which other private keys are determined from.

It is possible to generate the private keys to someone else's addresses because technically they are all known, every single number from 0 to 2^256 - 1. However that range is so large that the likelihood of generating the private key to an address in use is very low unless the random number generators used is broken in some way like blockchain.info has done.

Your fundamental assumptions are wrong.

First of all there is empirical evidence which directly relates the network hashrate to the difficulty. As the hashrate has increased so has the difficulty and vice versa.

Secondly, you have the wrong assumption that blocks will be found by a single pool every ten minutes on average. That is the wrong assumption.

There are 2^256 - 1 possible solutions. A pool will only  search through 2^64 hashes for each set of transactions that it includes in a block. Note that each pool will have a different transaction set due to choosing different transaction and setting different coinbase script text.

For the sake of simplicity let's assume that each pool has the same hashrate and that there are 10 pools (pools can also be interchanged with individual miners). In, say, 1 hashes, 10*2^64 hashes will be searched, way short of the 2^256 - 1 possible hashes. After 10 minutes, 100*2*64 hashes will be searched. With whatever difficulty is set, within that set of hashes, there will be at least 1 block solution (actually there will probably 1 solution).

Now if there are suddenly 5 pools but the difficulty stays the same, 100*2^64 hashes will need to be searched but only 50*2^64 hashes will be searched. That means there are 50*2^64 hashes that haven't be searched yet. In order to have a high probability of having found the block, each pool will have to search another (1/5)*2^64 hashes which will take an extra (1/5)*(10-5)=10 minutes to search the remaining space to find the block.

tl;dr you are assuming that pools are searching from the same place, but they don't and all start and search different areas of the hash space.