Yes; transaction fees are ignored by AcceptBlock. This is by design, as it allows competition for fees. ArtForz never charges fees, in fact.


Your transactions would be delayed if you're using an old client (before the fee rules were updated) and send a transaction over 25KB without a fee.

I changed "combined" to "concatenated" on the wiki page.


Transactions are never really "prioritized" based on fee (though they probably should be). Some are temporarily disallowed if their fee is too small, and they'll be included in a later block. In these cases I guess a higher fee would be prioritization, but generators don't look at all of the queued transactions and sort them by fee.

I like this a lot. This would win at least my 100 BTC "How to get started" bounty.

If someone happened to generate a colliding address, the amount would be added to their account. It's so unlikely that the coins should be considered lost.

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


No. It's too unlikely. It'd never be profitable, and it probably isn't even possible to do in any reasonable time frame (<20 years).

The purpose is to prevent an attacker from replacing the entire chain, either due to "boatloads of CPU power" or an unknown bug. See:



If the checkpoint is 1000+ blocks older than the current one, the chance of this happening is almost zero. No one could be stuck in a shorter chain for 1000 blocks without realizing it.

I will if the changes are compatible with Bitcoin.

More importantly: I will not use versions of Bitcoin that have stupid rules.

Clearly I am willing to bet my Bitcoin balance on the security of the system. There's no way to generate a longer chain without expending more CPU power than the current chain did, even without the checkpoints.

Feel free to make a different version with stupid rules. No one will use it.

When the checkpoint lockin system was implemented (a while ago), everyone had the opportunity to check that the included hash was correct. If it was not, no one would have updated and the change would have been rejected. Satoshi proposed a change, the participants voted with their CPUs, and the change was passed.

Obviously few people checked. They trust Satoshi and the other members of the community enough to take them at their word.

The checkpoint system is only "insurance" against unknown attacks. There are no known attacks that are prevented only by the checkpoints. So you can safely remove it if you want.

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.