I've had three thumbdrives just stop working over the years. The correct answer is probably to have it on both.

Well, for such things as difficulty, there's not a lot of difference in how the code reads and just a verbal explanation. It's kind of just busy work to write it out. But if you have questions, go ahead and ask them.

Every 2016 blocks, look at the last 2016 blocks. IntervalLength=Last blocktime - first blocktime. Adjust the difficulty according to NewDifficulty=OldDifficulty*(2 weeks)/(IntervalLength). If the NewDifficulty is more than 4x or less than .25x, limit it.

There you go.

The wiki has most of it, but the best place to look is the code.

Yes, the mining is necessary. Each block in the chain makes it harder for an attacker to compromise the network. Without a reward, there would be no incentive for solving blocks and wasting that electricity. The purpose of mining is only secondarily to introduce Bitcoins into the system. The primary goal is to create incentive to support the network.

Also, if all Bitcoins were created at once, who would control them? How would they be distributed? As of now, the more effort you put into supporting the network, the more Bitcoins you earn.

If he was just adding a transaction fee, he wouldn't have to change anything. He would just have to send it just to this one miner, whoever that was, rather than broadcast it to the network. As soon as that miner solved a block with that fee in it, he would claim the fee.

All the same, this wouldn't count as zero-interest. Instead of paying interest to the lender, which makes sense, you'd be paying it to the miner instead for some strange reason, but you'd still be paying it... It seems he doesn't really understand how Bitcoin works.

There's a built-in escrow system in the works as well. See https://en.bitcoin.it/wiki/Contracts for details. It's not active in the client yet though.

They're undoubtedly (probably) secure passwords, but they seem hard to remember. I mentioned this in another thread, but another option aside from including uppercase, lowercase, numbers and symbols is to create a long password with just plain English words, which are much easier to remember. Check out http://www.diceware.com for example. Long passwords result in exponential growth in complexity, rather than just polynomial growth by including more symbols.

As others have mentioned, the idea as it stands is unworkable because you don't understand how Bitcoin works. Miners don't need your transaction to mine Bitcoins. The only incentive that a miner has to process a particular transaction is the fee associated with it. Blocks can be created with no transactions other than the one that creates 50 BTC. You're not offering any incentive to a miner that he doesn't already have.

Now if you offered a fee to a miner and an exclusive right to mine that transaction rather than broadcasting it to a network, that would be something at least. As others have mentioned though, not many players have sufficient power to solo mine any more, so it would take them a highly variable random amount of time to actually generate the block with your transaction. And then you're not having zero-interest, you're just having a fee in place of the interest.

The 21 million is never actually really reached (well, not for a long long time). The distance to it just keeps halving. In another 1.5 years or so, half the coins will be found and the reward will drop by half. I think this step is going to actually be a huge problem for the network as many many rigs just become unprofitable and are taken offline. Therefore, the network hashrate, and thus response time, drops like a rock, and stays there for 6-8 weeks or so.

Not quite accurate. The 50 BTC reward figure divides by two every 210,000 blocks (about four years, depending on network growth). Let's see, 50 BTC = 5*10*10^8 satoshi = 5^10 * 2^9. The division is performed by bitshifting, so the 5s are really identical to 4s or 2^2 for these purposes, so all together 2^29. So the fee will entirely disappear in 30 cycles of 210,000 blocks, or about 120 years.[/nitpick]

Keep in mind that "a Bitcoin" doesn't exist in any real sense in the code. What does exist is the satoshi (.00000001 BTC). In other words, there's not really such a thing as 21 million Bitcoins. Rather, in the technical sense there are 21x10^6*10^8=2.1x10^15 = 2.1 quadrillion satoshis. In comparison, according to Google, the world GDP is about $56 trillion, which is to say about 5.6 quadrillion pennies. (Yes, I know the whole world GDP is not actually measured in dollars, but go with me here.) So really, it's not that ridiculous a level of volume.

No, your wallet contains the key associated with your address. Transferring your wallet.dat file will allow you to access those funds from another computer. (That's also why it's so important to make sure you never ever let your wallet.dat file get stolen.)

The wiki page https://en.bitcoin.it/wiki/Contracts has a good overview. The page https://en.bitcoin.it/wiki/OP_CHECKSIG also has a good overview of the different types of signature.

And yes, I think some of these features are currently disabled in the client. Hopefully they will be activated when the need for them arises though, and since they are already part of the protocol, it would probably be easier than making a new addition.

Seems like the same thing can be done currently as follows:

A generates Tx1 with an output that can be unlocked by either (keyA and keyB) OR (secretA, secretB, and keyB). He does not broadcast it. He then generates Tx2 with Tx1 as the input with sequence number 0, an output that can be unlocked by keyA, and an nLockTime of sometime in the future. Because the sequence number of the input is 0, the transaction won't be finalized until the time encoded in nLockTime. He then signs Tx2 with keyA and sends it to B. B signs it and sends it back. A now broadcasts Tx1 and Tx2. After making sure a similar scheme is conducted on the other crypto network, he reveals secretA to B. B now reissues Tx2 using secretA, secretB, and keyB, but with nLockTime of 0, finalizing it, and an output of his choosing. A sees secretB in the broadcast transaction, and uses it to unlock the coins on the other network.

The thing is that the latest movie doesn't require knowledge of all the past movies. However, in order to prevent double spending, you need at least knowledge of all the transactions between the time the funding transaction output was generated and the present.

The system is set up so that a future client can cut down to just the block headers (just 88 bytes each) and request the transactions that it needs to verify payment. However, because it won't have a full node and can't verify transactions by itself, this future client will have to take a wait-and-see approach to see if the transaction is accepted by the network or rejected because of a double-spend attempt. Either that or used some trusted third party that does have access to the full network history.

Then you'll need to modify the code and recompile. The place I saw testnet being referenced was here:


So currently it's hard-coded to not even try to generate blocks until after it has 118000 unless it's on a test net. Among other things affected by the testnet flag are the genesis block.

Just glancing at the code, you probably have to specify the -testnet argument as well.

To what purpose? You have to go back to the real world at some point, whether buying/selling Bitcoins, or ordering something from your drug dealer. The authorities are more likely to get you at that point than at any other.

Bitcoins don't really have an identity like that. There's just inputs to transactions and outputs of transactions. Every output can be used as a future input.

Alice receives 2 generation transactions worth 100 BTC. She makes a transaction that uses both of them as inputs and sends 100 BTC to Bob. Now Bob has an output transaction of 100 BTC that he can use as the input to another transaction.

Hope that helps.

Yes, it's called the Genesis Block. http://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f