Yes, and a very tough one to make.

I think you're mixing some things up. When you mine a block, you decide which (outstanding) transactions to put in it. As a reward, you get 50 BTC + all fees from the transactions you put into that block. There is no such thing as "mined rights", and you don't get fees from transactions using the 50 BTC you received as reward; those go to whatever miner puts those in a block.

You can simply do a payment of 50 BTC + the fees you got from mining, to someone else.

"Getting a share of the initial distribution of the currency, in return for securing the network by processing transactions"... maybe a bit too long

I'm working on a (unencrypted) export/import wallet feature. There is prelimininary working version reported here: http://bitcointalk.org/index.php?topic=4448.0

You were right - fixed.

Hello,

this pull request has been waiting for some time, so maybe i should start a forum thread about it:
https://github.com/bitcoin/bitcoin/pull/123

The problem

Bitcoin currently only works for many things "per transaction", transactions as a whole are spent or not, and as a whole give a certain amount of available credits. However, when multiple outputs of a single transaction are available, it is sometimes useful to not use all of them. See http://bitcointalk.org/index.php?topic=3759.0

The problem with this is that bitcoin's wallet database only keeps a single boolean per transaction to indicate "spentness".

The patch

This patch adds an (optional) array of booleans per tx to the wallet format, while keeping the old single boolean updated according to "at least one output spent". Calculation of available coins is updated to only count the specifically available ones, and selection of coins for new transactions is done per-txout instead of per-tx (fixing the linked issue).

Backward compatibility

When you load an updated wallet (with partially-spent transactions) into an old client, it will show you a lower balance than the actual one, since it cannot cope with the available partial outputs. The transaction list is accurate though, and switching back to the new client fixes the issue.

You only need to backup wallet.dat. Anyone with access to that file, has access to your bitcoins though.

A priori you are helping even with the smallest amount of hashing power, since on average your expected number of blocks found is higher than zero (even though it may be 0.001/year).

A posteriori, if you haven't found anything (the most likely case), you have wasted your power. That doesn't mean it was meaningless, since you always had a chance to find something.

I'm just trying to debunk that it isn't true that having a very large chance for not finding anything necessarily implies completely wasted power.

Concerning the real topic of the discussion however, I believe we shouldn't give people false hope that they can generate coins in any serious amount without investing in mining. I'm in favor of removing mining functionality from the main client, but providing a separate reference getwork-based CPU miner in the source distribution.

And I agree, but I'm not convinced it's the best way to handle wallet dumps.

Anyway, my current walletdump branch (https://github.com/sipa/bitcoin/tree/walletdump) contains a "dumppemkey <address>" RPC call, which exports in the standard PEM format... 720 characters per key (compared to the base58 representation of a (bitcoin-specific) private key, 51 characters).

It currently does not support importing keys, or extracting only the public key of an address.

I don't make any prediction about the future, but you may see some useful patterns on my site with network speed and difficulty graphs: http://bitcoin.sipa.be

I think there are two outspoken opinions:

• (continued) increase of monetary mass is bad
• A certain % of newly injected money is useful (eg. 2%/year)

In the first case, I'd expect you to favor a system where block_reward eventually becomes 0.

In the second case, I'd expect you to favor a system where block_reward eventually becomes 1/2650000 of BTC mined so far at that point in time (causing 2% increase per year).

I'd like to know what reason there is to want 50 BTC forever.

This got me thinking. If the length of codes on a scratch-off card wouldn't have a limit, what would you put on it? My guess is: the full private key + the full txhash of the transaction that sends money to it.

This is two times 256 bits of data, plus maybe an 8 bit header and 32 bit crc, totalling 552 bits, or 95 base58 characters. With a bit of error-correction code, this is a 41x41 pixel QR code image. This seems quite reasonable.

In addition to that, a card could contain a shorter password/id combination like suggested in this thread, for those unable to read or type over the 95-character code. Maybe something like a website "Redeem your coins here!" after typing the id/password (since something would still need to do the lookup of the id, and you need to trust the issuer of the card anyway), could be linked to on the card as well.

I think it'd be really nice if it would become possible to physically give bitcoins to someone. It would correspond to what a (traditional) bank note was for gold, for bitcoin.

We only need the 256-bit private key, not curve parameters, generator point and public key, which are stored in the OpenSSL structures (and some of those in .pem files too, judging by their size) as well.

PEM looks useful as well, especially when people want to use bitcoin's keys to sign other things. Shouldn't be too hard to implement that as well.

However, what I'm trying to do is create a self-contained, compact, human readable, stable form of storage for wallets. PEM files are standard but not-so-compact ways of storing purely the cryptographic part.

I disagree, the work you need to for every block on average is identical. It is the criterion you use for marking a certain block as good or bad what will cause the difficulty. And as long as that criterion is (integer value of hash is less than given_number), all blocks that match have identical difficulty. The fact that only some of those blocks would also match a higher difficulty (and thus a different criterion), doesn't change that.

You could of course talk about the effective number of hashes one needed to try to find a block, instead of their average expected number of hashes, as you say. That's possible and reasonable, but not very useful in this context.

I believe this is a useful idea, but I would define it on the level below the base58 encoding.

So, an address currently is a base58-transformed sequence of bytes:

• A version byte (0)
• The pubkey hash (160 bit, 20 bytes)
• A 32-bit (4 byte) checksum

It's not that hard to define a similar format for shortened addresses, but I would suggest not requiring lookup code to parse full blocks when looking for an address - they could become quite big in the future. Rather, what about this:

A base58-transformation of:

• A version byte (1)
• A BER-encoded block number
• A BER-encoded tx number
• A BER-encoded txout number
• A 8-bit (1 byte) checksum

(BER encoding: in every byte, bits 0-6 contain data, bit 7 signifies if another data byte follows, like UTF-8 for unicode)

Up to block number 2113663, and as long as less than 128 transactions and less than 128 outputs per txout are used, this results in 7 bytes, or 10 base58-encoded characters. An alternative (if it's meant for typing over, instead of automated handling), would be to use base36 (case-insensitive alphanumeric) resulting in 11 characters.

Ok, I've since decided to use a CSV-like format anyway. It is more compact (for use in QR-encoded form, eg.), and easier to process using for example command-line tools like grep and cut.

Here is a preliminary branch that supports importing and exporting transactions: https://github.com/sipa/bitcoin/tree/walletdump

Working:

• dumping a wallet to file
• importing a file
• watching for others doing transactions with your keys
• rescanning the relevant portion of the block chain after importing
• correct updating of transactions and balance in the GUI

Todo:

• error-handling when a double spend has been tried anyway
• importing of reserve keys
• test

The file contains lines of the form:
Current flags are:

• R: reserve key
• L: label is present

For example:

92263nMUE7SkR62tMn1Ucu2AxY5nANmQhXRhxHZP6MVxpfLC2EH,10801,L,"Your Address"
934xQoFPHzYkwTvJQwQSPw8QspwVB8kPd1S3wRZsZGbgLKVQPb7,10814
92xRg4At7vN25B1esc768NvW7Exrr2PcgZ78MFNmd58MzXjXGYM,10955,R

No, you need to decide who (what address/public key) will earn the generated 50 BTC before starting to mine, since the hash depends on it. So once you find a real hash, you only have two options: broadcast it, and let the pool gain money (of which you'll get a piece), or discard it (which is bad for everyone).

See http://bitcointalk.org/index.php?topic=4220.0 and many threads before that one.

That's not necessary even - just a network (and many of those can exist) of a sufficiently high number of nodes (tens, hundred maybe now) that are not directly connected to eachother through the bitcoin network, which all verify that they have 1) received the requested transaction and 2) have not seen conflicting ones for a short time (let's say 0.5s)

A company could provide a service for verifying transactions, and for a small cost maybe give insurance against double-sent transactions for the seller.