No. The address is "used" in the sense that it is removed from the pool and put into the wallet proper. The addresses can be used for unlimited sending and receiving.

Nearly every time you send bitcoins, you also end up creating a brand new address and sending some "random" number of bitcoins to it (back to yourself). This new address takes one address from the pool, puts it into the regular section of the wallet, and generates a new address to "top off" the pool. Wallet backups are good for only 100 "new address actions" because addresses generated after that will not be in the old wallet.

Back up your wallet. Hit "New Address" 100 times. All of those addresses are in the backup. Create one more address and you've created an address that's not in the backup -- it will be lost if you restore from the backup.


They would diverge after a new address action, though this would only become apparent after their pools are exhausted. They'll both be able to see and spend transactions sent from and to the addresses that they share (current addresses + 100 pooled addresses). Bitcoin will synch their shared transactions to some degree by looking at the block chain, but this is not an intended use of Bitcoin and you will run into occasional errors.

See http://www.bitcoin.org/wiki/doku.php?id=backup

All transactions to a particular Bitcoin address are to one key. Once you create the address (key), your wallet will always contain the necessary information to receive using that address. Somewhat counter-intuitively, receiving with a Bitcoin address is one of the few activities that does not require backing up your wallet.dat.


You can use Bitcoin's -printblock or the getblock patch for RPC. See these wiki pages for some necessary background info:
http://www.bitcoin.org/wiki/doku.php?id=block
http://www.bitcoin.org/wiki/doku.php?id=transactions

I'm making an easy-to-use web tool for looking at this data.

You're currently allowed to make complex transactions that can, for example, be redeemed by either of two public keys (whoever gets it firsts wins). This would be impossible in a balance sheet system unless you also record the transaction script, and if you do that you're right back at full transactions.

To be able to say, "No other transaction has spent these coins," you need to know the contents of every other transaction. There's simply no way around this. Balance sheets would reduce the space required for each transaction, but this would remove the useful script functionality, since every transaction would need to be sent to exactly one public key or hash.

Balance sheets are basically "simple transactions":

Even with balance sheets, you'd still have 100-200 bytes per transaction, which doesn't help the network end (the real problem).

It's possible for non-generators to store almost nothing. However, the purpose of the network is to verify that transactions are not double-spending, and this is only possible if the generators know all of the current unspent transactions.

The available transaction fees will accumulate. Whoever generates the next block might get 2000+ BTC. This will encourage a return to something close to a normal rate of generation. Bitcoin won't become unusable, just more expensive.


This would never work in the long-run. In a few years, being a generator will require amounts of disk space and bandwidth that are unreasonable for most users.

PayPal does 382,000 transactions per minute. If we want Bitcoin to do 100,000 per minute, every generator would need at least a 5.76 megabit (upload and download) connection.

If some irrational and wealthy organization (such as a government) wants to take Bitcoin offline, there's nothing that can be done to stop them. It will be very expensive for them to maintain this, though.

ArtForz on IRC came up with a much simpler solution with the same result.


The private key is encrypted with AES-256. To create a code:
1. Get 60 bits of random data.
2. Generate a new ECDSA keypair.
3. Encrypt the private portion of the keypair with a hashed version of the random numbers.
4. Create the transaction shown above.
5. Write down the random numbers and transaction hash in base64.

To redeem:
1. Find the transaction in the block chain using the transaction hash (only a small portion of it is needed).
2. Hash the "password" that you received and use it to decrypt the private key.
3. Use the private key to sign a new transaction to yourself.
4. Get coins.

That's only 15-18 characters that you have to type in order to redeem! I believe that's less than a Tracfone card code.

Valid addresses can be 25-34 characters in length, though the smaller ones are very rare.

Testnet addresses can be 35 characters long, and they don't always start with a 1.

It's technically possible, but Bitcoin isn't yet able to import/export keys. You could probably do something like that by swapping wallet files around, though the "checking" account wouldn't detect transactions to the "savings" account.

The private key is used as a hash, not for authentication. I don't care if people can create a valid signature: I only care that doing this will take them a few minutes with the proof-of-work scheme.

Consider that Bitcoin blocks could be done in the same way. The hash is replaced with a signature. Signatures less than than the target are valid, and people publish the public+private key in the block for verification (the private key isn't necessary, but it does no harm when public-key cryptography is used like this). There would be no point in doing it this way of course, but it would be possible. The reason I'm doing it like this here is that only OP_CHECKSIG can read the transaction outputs.


Of course this isn't done for normal transactions. They're using the keys for authentication; I'm using it as a proof-of-work.

The person creating the card generates an ECDSA keypair. This consists of two pieces of data: a public key and a private key. Anyone who has the private key can make signatures that validate with the public key.

The card creator creates a transaction that contains both the public key and the private key. The private key is no longer really private, though it is still considered the "private key" portion.

The card creator also generates some random numbers. They write these down. They append to these numbers the first few bytes of this public key (or private key). They hash this and add it to the transaction.

The person redeeming the transaction gets a piece of paper with the transaction hash and the random numbers that were written down above. They find the transaction in the block chain. Reading the transaction, they find the public key. They append this to the random numbers on the piece of paper. This is the code.

The person redeeming the transaction also looks at the transaction and finds the private key (which is totally revealed any not really "private"). Using this pair, he creates and signs a new transaction to himself. He now has the coins (after some proof-of-work retries).

The keypair used here is public and not really owned by anyone. We are not using it as intended. It is just a method of delaying attackers. It is used very much like a hash. Surely a more elegant solution could be used if Script supported it.

Perhaps you would find it useful to read:
http://www.bitcoin.org/wiki/doku.php?id=transactions


That's right. I think it would be very convenient to give/sell simple codes that can be redeemed instead of sending to an address. It follows the more traditional model of receiving money instead of sending it.

Various schemes such as this have been discussed, but they all entail either an electronic device or such a large amount of data that a QR code is required. The OP is about a way to do it with codes small enough to type.


Almost right, but replace "public key" with "transaction hash". The redeeming person is not taking over a keypair. They are collecting the output of a transaction. A similar collection process is done whenever you send a transaction -- you collect the coins that you're sending. In this case you would actually want to collect the output right away (make a transaction to yourself) so that the sender can't take it back. With the hash, you are able to verify that an appropriate output exists and has not been collected already.


The security of this would be horrible. I am definitely not proposing anything like this. Somehow, the rest of your post is an accurate summary, even though you believed this.


All current scripts check that you have knowledge of the private key for the public key which the output of a transaction was intended to credit.

OP_CHECKSIG checks that you've signed the entire transaction -- input and output. The output signature is the important part: it prevents a MITM from rewriting your transaction. Just a hash wouldn't give this protection, which is why the signature is necessary.

- The real code is on the card. The hashed version of it is in the publicly-available transaction that you will collect.
- The provided code is provided by someone when they try to collect the transaction.
- The private key is in the publicly-available transaction that you will collect. Maybe part of it is on the card.
- The target is specified by the person creating the card/transaction/code. A lower target is more secure, but it will take longer to process the proof-of-work for the redemption.
- The signature is made using the private key in the publicly-available transaction.


You can use part of the private key or part of the public key. Anything random that is known by both the card creator and the redeemer. It's added to the code given to the network. So if the code on the card is 1122 and the salt is 4, the real code is 41122. The hash of this is the hash in the transaction. This salted code is the code as the network sees it.


It's the key made public in the transaction. This keypair, being public, should be freshly-generated by the person making the card.


The card creator supplies the public key, not the redeemer.


The output is also signed. If this was not the case, all current Bitcoin transactions could also be stolen in the same way.


I'm working on a page on the wiki (to be named "script") that will list them all. It's all specified in script.cpp. You can't do that, though.

In any case, ArtForz controls 30%+ of the network's CPU, and he would immediately adjust his fee rates in response to a block flood. Eventually dedicated companies will own the network's CPU and will be able to do likewise.

The script functionality is limited. Some commands are disabled. It's still possible to do some interesting things with it, though.


I realized that the OP_DUP in my script is redundant. Take that out.

When you redeem, you publish the signature and the code (in that order). They are prepended to the script I wrote. To determine whether your transaction is valid, nodes go through these steps (moving left-to-right through the full script):
1. The signature, code, and private key are put on the stack.
2. The private key is discarded (OP_DROP). This is just data meant to be read by the person making the transaction, and is not necessary for verification.
3. The top code is replaced by a hashed version (OP_HASH256).
4. The real hashed code is put on the stack.
5. The the top two items on the stack (the hash of the real code and the hash of the provided code) are compared, and then these items removed (OP_EQUALVERIFY).
6. The public key is put on the stack.
7. The signature is compared to the public key (OP_CHECKSIG).

The script will evaluate to true if the provided signature is valid for the public key in the later part of the script (scriptPubKey) and the hash of the provided code is equal to the hash in the scriptPubKey.


Yes. Only the sender and recipient need to upgrade, though.


An attacker probably would win at that point usually. However, the question is whether the full private key can be recovered with a cost less than the cost of the number of bitcoins transmitted, and in less time than it takes for the code to be used by the intended recipient. Hopefully any attack would be too expensive. I am not familiar with partial-key attacks, though; it could very well be a trivial matter to recover a private key when you have 90% of it.


I'm trying to figure out the required length for the code. This is a similar case to figuring out appropriate password length, but with the important difference that each byte has much more entropy.


I just realized that this is possible now! I thought that all of the arithmetic functions were disabled, but actually only some of them are. You would use a script like this:

The person redeeming provides a signature and a code (in that order). It would evaluate like this:
1. The signature, code, and private key are put on the stack.
2. The private key is removed (OP_DROP).
3. The code is hashed (OP_HASH256).
4. The real code is put on the stack.
5. The real code is compared to the provided code, and both are removed (OP_EQUALVERIFY).
6. The signature is duplicated on the stack (OP_DUP).
7. The target is put on the stack.
8. If the signature is less than the target, 1 is put on the stack. Otherwise 0. Both items are removed.
9. If 1 is the the top item on the stack, go to 10 and 11. Otherwise, the transaction will not be valid.
10. The public key is put on the stack.
11. The signature is compared to the public key (OP_CHECKSIG).

This is assuming the signature can be converted into a bignum. Otherwise I think we'd need OP_SUBSTR, which is disabled.

So I believe it is right now possible (with a modified client) to transfer bitcoins using an ~8-character code! It'd probably even be safe to reduce that to 6 characters.

What version are you using? Versions older than 0.3.13 will send bad transactions that most generators won't accept if you've ever received a similar bad transaction.

Run Bitcoin with the -debug switch and double-click the transaction. Paste the hash here. The hash is located under the "transaction" header:
CTransaction(hash=c3821b, ver=1, ...


That is possible. Bitcoin waits a long time before it rebroadcasts, and it might take an especially long time if you never leave Bitcoin open for longer than a few hours.


An attacker with more than 50% of the network's CPU could prevent a specific transaction from gaining confirmations. See the wiki. There's pretty much no chance that this is happening here, though.

You might be able to do this for a while with less than 50% of the network. It depends on how lucky you are. You need to create more than 50% of blocks.

All of the data that Bitcoin hashes is too large and random to use rainbow tables with.

Generating is just like buying bitcoins, except you pay with electricity and time.

I think Mizerydearia is planning to release bitbot's source. That would allow a new bitbot to be set up on a more stable server, or at least a backup bot to be made.

I forgot to move the decimal over for the fee per KB.  

Driving a block to 1MB costs 21 million BTC. I don't think attackers are going to pay...


Here's how much it would cost (estimates) to make the block size go to various levels:
-50 KB: Free
-250 KB: 2 BTC
-300 KB: 127 BTC
-350 KB: 293 BTC
-400 KB: 543 BTC
-450 KB: 1043 BTC
-490 KB: 3543 BTC
-495 KB: 8543 BTC
-499 KB: 33543 BTC

Attackers can feel free to pay 500 BTC every 10 minutes to make sending transactions expensive...