When a bitcoin miner is at work, it tries many nonces x, such that sha256(sha256(block_header_with_nonce(x))) results in a number that is small enough.
Currently, this number needs to be smaller than

  000000000000DC31000000000000000000000000000000000000000000000000

(written in hex) for it to result in a real bitcoin block with value. Pools, however, (at least the ones i know about), only request hashes that are smaller than

  00000000FFFF0000000000000000000000000000000000000000000000000000

So, it will see all "real" hashes calculated by the miner, but also many hashes that are somewhat larger than this.
The pool gets its income from those real hashes calculated by the miners, and distributes them (using some formula)
according to the number of low-difficulty hashes it received from each miner.

That is exactly what my patch does (I needed spent-per-txout for another purpose, but as it enabled better selection of imputs for transactions, it's implemented too): https://github.com/bitcoin/bitcoin/pull/116

It corresponds to finding a hash whose value matches the target for difficulty 1, being 0x00000000FFFF0000..., that means it will on average correspond to 4295032833 hashes.

I've though about it. It's a very simple way to avoid any parsing/escaping difficulty, while making it easy to extend it further afterwards. On the other hand, CSV is so simple that you don't even need any library for parsing.

Still, a proposal:

[
  { // moura6ybHvwzMtrWdyqiEN6n2mMakf8HxD (50.01 BTC)
    "privkey" : "91iwnurxhWmDF9gqwc4CbuLCB4HxuMXf5B2vEhTPDftY3rkMgDY",
    "firstblock" : 10806
  },
  { // mmFPR1oaDExBfJqpRohWBvbE2aCg86Kwcx (0.00 BTC)
    "privkey" : "92JsNVMJgG4RiC2ARxpduJp8DXKgdDMj9WREE5jo66Hg8UMdr3L",
    "firstblock" : 10870,
    "label" : "My Address"
  },
  { // midiVjwgBCkMSup4X2FifFinwLhpHYe2wn
    "privkey" : "91s3swvX2a3F7FDoypEV7rTVhWUKiw8RCBmDuHMN8xMksLn3YtV",
    "firstblock" : 10870
  },
  { // reserve
    "privkey" : "93NM1B7y35d9VxqGBvc8DZcAvEB9kE5UZV7WqNGMTNWhPBdhsJT",
    "firstblock" : 10870,
    "reserve" : true
  }
]


Does anyone know how JSON libraries cope with comments?

For RSA, this is true, there it is just encrypting the hash of the data with your private key, and verifying it by decrypting it with the public key. This is possible since the public and private keys can be used interchanged.

The DSA family of algorithms however, are only usable for signing, and can't be used for encryption, as far as I know.

I don't think you need another transaction type for this, see https://en.bitcoin.it/wiki/Script#Transaction_with_a_message.
You do need support in the client to add a message (just some random byte sequence in some encoded format, maybe prefixed with a marker and a suffixed with checksum to allow easy regcongition without fully parsing the script) to a transaction. Ideally, it would also be possible to have bitcoin: URI with such a string, so transactions created by clicking such a link automatically have it.


I doubt a better solution than still using (some) separate addresses is possible for this.

I don't like the wallet as more than an internal database for one specific implementation of a bitcoin client. It's not transparent or human readable, hard to keep updated when accessing it using external tools, and maybe very different from what other implementations like to use. It is very fast and hard to corrupt, so it is perfect for an internal database, but for all other applications, i prefer a separate, more interchangeable format.

Simply by adding reserve keys (which are in fact harder to filter out when exporting, since they are available in mapKeys like change keys and used keys), you have everything to have a bitkeys file function as a backup or by limiting its contents, as an interchange format.


I agree, I suggested exporting them as comments because they help making a bitkeys files also a useful way to inspect your wallet (which is maybe also a use case?), and possibly select which keys from it you want to give to someone else (essentially doing use case 3 or 4 by hand, by copy-pasting a part of a bitkeys file).

This pull request should fix this issue: https://github.com/bitcoin/bitcoin/pull/116

Hello all,

I've been working on a patch for bitcoin which allows exporting and importing of wallets in the so-called bitkeys format (initially suggested here: http://bitcointalk.org/index.php?topic=3638.msg52066#msg52066).
Now there are still some issues with this, so i thought maybe it's a good idea to discuss some details in a separate thread.

First of all, there are basically four classes of keys:

• (1) Used keys, which have unredeemed transaction outputs linked to them (and thus contain funds)
• (2) Used keys, which only have redeemed transaction outputs linked to them (worthless, but the addresses may be used still by others)
• (3) Unused keys (whose corresponding addresses may have been published)
• (4) Reserve keys (whose corresponding addresses have typically never been divulged, but may have been divulged at the time the export is imported again)

Furthermore, for the first three classes, each key may either be in the address book or not, and have a label/account name or not (which may or may not be considered relevant information for a wallet export).

Especially for the reserve keys, I'm not sure what the best way to proceed is when importing. Clearly, you don't want to add them to the reserve keys when importing (either they've been used in between already, in which case they should definitely not become a reserve key but still imported, or they haven't ever been used, probably never will, and importing them would just clutter the wallet).

The current proposed bitkeys format does not contain information about how the key was used, whether it is a reserve key, or what label it has. Maybe it is useful to add that information to the format?

Currently, my dev branch (https://github.com/sipa/bitcoin/tree/walletdump) produces exports with lines like this (warning: valid, importable, testnet keys):

v=1
91iwnurxhWmDF9gqwc4CbuLCB4HxuMXf5B2vEhTPDftY3rkMgDY,10806 # moura6ybHvwzMtrWdyqiEN6n2mMakf8HxD (50.01 BTC)
92JsNVMJgG4RiC2ARxpduJp8DXKgdDMj9WREE5jo66Hg8UMdr3L,10870 # mmFPR1oaDExBfJqpRohWBvbE2aCg86Kwcx (0.00 BTC)
91s3swvX2a3F7FDoypEV7rTVhWUKiw8RCBmDuHMN8xMksLn3YtV,10870 # midiVjwgBCkMSup4X2FifFinwLhpHYe2wn (unused)
93NM1B7y35d9VxqGBvc8DZcAvEB9kE5UZV7WqNGMTNWhPBdhsJT,10870 # (reserve)

The first line is a class-1 key, with an unmatured generation output (so not yet really 50.01 BTC). The second line is of class 2, the third of class 3, and the fourth of class 4. Notice that the block number for keys without balance is always the current block number (since there is definitely - unless in case of a chain split - no available money transferred to these before), and that the address for reserve keys is not revealed.

So, I suggest to a third field, which distinguishes between those classes, either a boolean active/inactive, or some more elaborate form. Maybe an optional fourth field that contains the label for adding it to the address book is useful as well?

The format of the private keys is described on http://bitcointalk.org/index.php?topic=3906.msg55643#msg55643, and also contains a version number and a checksum, like addresses.

Ideas/comments/suggestions/remarks/bitcoins?

Before something can be a store of value, it needs to have value. Gold gained this initially through being wanted for use in jewelry. The only way bitcoin can gain value, is by proving its worth as a useful (or even best) means of electronic payment.

You should read https://en.bitcoin.it/wiki/Block_hashing_algorithm and https://en.bitcoin.it/wiki/Block_chain. The blocks in the block chain indeed have two functions: 1) ordering transactions and 2) generating new bitcoins.

If you don't mind, i was planning on extending my dumpprivkey/importprivkey patch (see other thread) a bit so it can export and import whole wallets, one of the next days.

This was indeed not detected - incoming blocks and transactions were only checked for transactions to your own addresses, not from. Updated version of the patch fixes this as well: http://bitcoin.sipa.be/bitcoin-0.3.20.01-dumpprivkey.patch

PS: it also changes the unix makefile to use wx-config to find the locations of headers and libraries.  If necessary, i'll split this into separate patches.

Depends on what you want. Once support for thin clients exist, just keeping the block headers in the assumed best chain is enough, but for fat clients (including those miners connect to), you'll always need a database of all unspent coins (transaction outputs).

Here are some (new) testnet coins to play with (thanks comboy) for those who have applied the patch: 93VYUMzRG9DdbRP72uQXjaWibbQwygnvaCu9DumcqDjGybD864T.

You are right that all who receive a particular piece of work, will search for the same hashes. However, the getwork call to bitcoind never returns the same piece of work twice. To be more precise: there is a second nonce inside the generation transaction of the block too, and this one is set by the client instead of by the miner.

EDIT: this patch is for version 0.3.20 and isn't updated anymore. It is incorporated in my showwallet branch. See this thread for more information: http://forum.bitcoin.org/index.php?topic=3906.0

Hello all,

after working Hal's challenge to import a private key into a wallet last week, I created a patch for bitcoin which adds 2 new RPC commands:
* dumpprivkey <bitcoinaddress> reveals the private key corresponding to the given address (if known)
* importprivkey <bitcoinprivkey> adds a private key to the wallet.

See http://bitcoin.sipa.be/bitcoin-0.3.20-dumpprivkey.patch

The format is similar to that of addresses, but:
* contains the 256-bit private key instead of a 160-bit hash of a public key (resulting in 51-character strings)
* uses version byte 128 (239 for testnet) instead of 0 (111 for testnet)

This is not the same format as used by Hal initially (adds version number and checksum, but I think these are useful properties).

importprivkey will perform a rescan of the block chain after adding the key, to discover transactions based on it.
dumpprivkey does not delete a key from the wallet though, so it is not really intended as a way of moving funds from one client to another, but it's a first step towards making handling private keys more accessible.

I've also created some code that generates a "full" (279-byte) private key based on a given 256-bit private key number (using openssl's EC_KEY_generate_key after setting the private key as a parameter). The problem is (more or less expected?) that the corresponding public key varies each time.

Are we sure that a public key can be generated deterministically from *just* the 256-bit private number? It is stored in full in the 279-byte version, which may be becsause multiple public keys can correspond to the same private number.

I do wonder why/how 0x6763 and m0mchil managed to get the same (wrong?) public key from that private number. Maybe I'm still not getting something

As I understand it, private keys are indeed 279 bytes long (though with some redundancy in them), public keys are 0x04 + 32-byte X-coordinate + 32-byte Y-coordinate (totalling 65 bytes, 520 bits), and addresses contain a 20-byte (160 bit) hash of the public key.

Not sure what you've given us Hal, but as it is only 256 bit, I doubt it's a private key.

PS: base58 encoding is more efficient than hex encoding, but it still can't turn a 279-byte key into a 44-character string...

Absolutely, it is exponential growth. But nonetheless there was a sudden (though not very large) increase recently.

Originally i made the graphs on an exponential scale but people seem to like the linear ones more (maybe they look more dramatic?):