Bitgen 0.18 has been released:

http://bitgen.org/

This release includes support for electrum seed generation.

Here is an example:
http://bitgen.org/electrum_btc_example_private.pdf

To generate an electrum seed, use the command "electrum" followed by the generation method, for example:

$ bitgen electrum random

This will generate a 24 word seed using random data from "/dev/random"

Other possible generation methods are "hash", "mnemonic", "hex", "dice" and "brain".

For example, the following command will generate a 24 word seed from 100 dice values:

$ bitgen electrum dice 6123623123652635162356516316213666166253162356253654545162456125213612536523615 236512631532131236616

The default seed size is 24 words, but this can be changed by adding "words" followed by the desired number.
The following command will generate a 18 word seed:

$ bitgen electrum random words 18

Possible values are 12, 15, 18, 21 and 24.

An optional "account name" can be specified by using "name", for example:

$ bitgen electrum random name "My test"

Bitgen 0.17 includes support for split wallets using one-time-pads:

https://bitcointalk.org/index.php?topic=1107927.40

Bitgen 0.17 has been released:

http://bitgen.org/

This release includes support for split wallets using one-time-pads.

When using split keys, the private key is split in two (or more) parts that all needs to be used in order
to recreate the secret key. The parts by themself do not give information about the private key.

When a split key is created, several 256-bit random numbers are generated instead of just one.
Then the final private key is created by doing bitwise XOR on the parts.

For example, if the following parts are randomly generated:
DBD2CECBBBA5D7D3FAFFB573B59E43A92C50D3135DE89A91614322A36D14ECC0
42EDDF6112DC308EFEAFEB4A8907AF4164FBF1C4DF5A32DEF55AD90DEB96D006

The bitwise XOR of these parts gives the following private key:
993F11AAA979E75D04505E393C99ECE848AB22D782B2A84F9419FBAE86823CC6

More than two parts can be used, in that case N random numbers are generated,
and the private key is the XOR of all N random numbers.

The parts can for example be stored in separate places. If one part should be stolen,
the private key is still safe since all parts are needed to recreate the private key.
With N parts (N-1) parts are not enough to recreate the private key.

To use split wallet with one-time-pad in bitgen, the otpgen command is used, for example:

$ bitgen otpgen 2 random

This will generate two random parts ("pads"), here is an example:
http://bitgen.org/split_wallet_example_private_pad1.pdf
http://bitgen.org/split_wallet_example_private_pad2.pdf

To create the private key the otp command is used with the pads as arguments,

$ bitgen otp DBD2CECBBBA5D7D3FAFFB573B59E43A92C50D3135DE89A91614322A36D14ECC0 42EDDF6112DC308EFEAFEB4A8907AF4164FBF1C4DF5A32DEF55AD90DEB96D006

This will give the private key, for example:
http://bitgen.org/split_wallet_example_private.pdf

To create random numbers, the methods "random", "dice", "hash" and "hex" can be used.

For example when using "hash", the following command can be used:
$ bitgen otpgen 2 hash sdfsdfsdfsdflkjsdlkfjsdlkfjsiusdyfisudyfsiduyfiusdyfiusdyfiudsyfiusdyfiusydfiuy sdifuydsiufysdiufysdiufysdiufysdiuyfisudyfisudyfiusdyfiudsyfiudsyfiudsyfiusdfyu syasuauuuauuasdiasudyasiudyaiusydasoidasdasidiasdiasodiasodiasodiasodi

More about one-time-pads:
https://en.wikipedia.org/wiki/One-time_pad

Bitgen 0.16 has been released:

http://bitgen.org/

This release includes support for mnemonics to extended addresses for HD wallets (BIP 32).
Random mnemonics are created by bitgen, and the corresponding xprv/xpub addresses are calculated and displayed.

Here is an example of a mnemonic generated by bitgen:

Private part:
http://bitgen.org/mnemonic_sample_private.pdf

Public part:
http://bitgen.org/mnemonic_sample_share.pdf

The supported randomness functions are "random", "dice", "hash" and "hex".
Also an existing mnemonic can be specified.

To generate a 24 word random mnemonic the following command is used:

$ bitgen genMnemonic random

It is possible to create mnemonics with fewer than 24 words. The values 12, 15, 18, 21 and 24 are supported.
If so, the number of words should be specified directly after the "genMnemonic" command, for example:

$ bitgen genMnemonic 15 random

However, 24 word mnemonics are recommended since fewer words reduces the strength of the random data.

If "dice", "hash" or "hex" generation is used the corresponding random data should be given.
For example, the following command will generate a mnemonic from hash data:

$ bitgen genMnemonic hash hJhKHUiisdfiosduoiuueuUUIDUoiudfiosnNMMMDDFSSDFiuUDFIDSFUoiFUiodfOIUoiuqoiuqoiu auiodsodifusdofiuIUIOUOIUDSFoiusdfiouIUFDSfs7dfsd8f7sdfkjsdfsdjfhj3242h34kjsadf kjhsdkjHJKJKJFskjdhfskjdhhsdfhghqhqhqiaibbxvvzzaajassiusadasiduasidfusujhYYUYhJ jsi

If an existing mnemonic is used, the "mnemonic" generation type can be used to calculate the corresponding xprv/xpub addresses.
For example:

$ bitgen genMnemonic mnemonic "tortoise wool skate ribbon tragic noise disorder napkin gossip slice improve vapor"

In the ps/pdf files the lower right QR code is the mnemonic.
The lower left QR code is the corresponding xprv address.
The top left QR code is the xpub corresponding to the xprv.
The top right QR code is the derived address for the derivation path "m/44H/0H/0H".

The derivation path "m/44H/0H/0H" can for example be used with electrum to create a watching only wallet for the addresses corresponding to the mnemonic.

The txt files that are created includes the same information in text form.

Bitgen 0.15 has been released:

http://bitgen.org/

The new release includes support for creating transactions.

Transactions are created with the command "transaction", followed by a list of inputs,
then the keyword "out", and finally a list of outputs.

Four items should be given for each input, normally the following:
1. Input transaction hash
2. Input transaction index
3. Private key in WIF format
4. The amount stored in this input, used for fee calculation.

For example, an input may look like the following:
192696c9166c15727204839e462de5684c47276bd9e48f5976ce6b60fe912451 0 L2VwsTTtJPLRkddkMcaqiYi6mLy6S7qF26cVbis6VS6gpSG3YRjK 0.520

One or more inputs can be specified.

Each output is given by two items:
1. Destination address
2. Amount

For example:
1JFj6tUTATKqs5LXzmZsvgY2B3TnzMGmZH 0.519

Any number of outputs can be specified.


For example, this command will generate a transaction:

$ bitgen transaction 192696c9166c15727204839e462de5684c47276bd9e48f5976ce6b60fe912451 0 L2VwsTTtJPLRkddkMcaqiYi6mLy6S7qF26cVbis6VS6gpSG3YRjK 0.520 out 1JFj6tUTATKqs5LXzmZsvgY2B3TnzMGmZH 0.519

This will give the following output:

============= Num inputs: 1
Tx  : 192696C9166C15727204839E462DE5684C47276BD9E48F5976CE6B60FE912451 at 0 (P2PKH output)
Addr: 1BXi4NozT14Pg8WZ2Z4bCkd9wkopq3mAak Amount : 0.52000000 btc

============= Num outputs: 1
Addr: 1JFj6tUTATKqs5LXzmZsvgY2B3TnzMGmZH Amount : 0.51900000 btc

                                      Miner fee : 0.00100000 btc


Transaction: 0100000001512491FE606BCE76598FE4D96B27474C68E52D469E83047272156C16C996261900000 0006B483045022100D4BA3967D41E1698CD8578066EC94AA53F45E30F188A47CEBA13F28F6F2435 6602207D9B0FCA9B8D8571E067BE9635EA0943B16B2E68A29C699DAD39C4C21D86B345012103BF1 2ABFAF61FF4A3DC16B16D76E484008E277219FAA2AD6046EAD62E133E5959FFFFFFFF0160EE1703 000000001976A914BD431B3A4D6C597C77D90DB441421BFC144B4B2D88AC00000000

Transaction size   : 192
Fee per byte       : 520 satoshi/byte
Hash of transaction: ED34DF6F8DFD1907444274B4DDBD2EC68826929D1608E1A564709FF9AF5A3040

Saved file: btc_ED34DF6F8DFD1907444274B4DDBD2EC68826929D1608E1A564709FF9AF5A3040.trans

Bitnote is a command line application that can be used to create bitcoin paper notes in ps and pdf format:

http://bitgen.org/bitnote



Here are an examples of a generated paper wallets:

http://bitgen.org/bitnote/example_canton.pdf
http://bitgen.org/bitnote/example_rtuga.pdf
http://bitgen.org/bitnote/example_timbo.pdf

To generate a postscript file, use the bitnote command with the WIF as parameter, for example:

$ ./bitnote Kx1oiWaDdU5udEbAzQfEztwR2YzRedbwaN9H8GJqtGVKj5J6ReDD

A design can be specified as a second parameter, currently one of "canton",  "mrno",  "rtuga" and "timbo".
A bitcoin amount can be specifed as the third argument.

Example:
$ ./bitnote Kx1oiWaDdU5udEbAzQfEztwR2YzRedbwaN9H8GJqtGVKj5J6ReDD rtuga 1.3

The code is open source, and uses the same bitcoin library as bitgen:
http://bitgen.org/

The designs originate from this thread:
https://bitcointalk.org/index.php?topic=155847

Bitgen 0.14 has been released:

http://bitgen.org/

The new release includes the following new features:

* Added support for transaction/script decode
* Added support for saving transactions/scripts
* Added support for executing transactions

As en example this transaction is used:
https://blockchain.info/tx/dd62dd9ce8d3a4484c23c904996194b0241690e2b11b02313647a68c1186b48d

In order to get the raw transaction data, "?format=hex" is added to the blockchain.info url:
https://blockchain.info/tx/dd62dd9ce8d3a4484c23c904996194b0241690e2b11b02313647a68c1186b48d?format=hex

To save the transaction in the bitgen format, the command "savetrans" is used with the hex string as a parameter on the command line:

$ bitgen savetrans 0200000001bbac9a005478c48888ecd95f9ce3dfd7e395ddcab61535ebed8dbfcbc8749d1500000 0006a47304402201304595735c8ab411e33df908eacbd1b27f600284a7d4bb772127ce324ee7788 022018af3831efc2f238938e2e1c77001937206b3bed2f6de264ab324f44ce23dbe80121036b5aa 4d546569bfd314235eda77235efe80c47b1666951ae009733512d8a3328feffffff02a0782d0000 0000001976a914311fbc254b0756e9407107139d413a5a5863024a88acf0689c00000000001976a 914c4f19c920b6112caa86b74462b0ff39d81ec30bc88ac20040700
(There should be no spaces or newlines in the hex data)

This will save the file transaction file "btc_DD62DD9CE8D3A4484C23C904996194B0241690E2B11B02313647A68C1186B48D.trans"
The file name will include the transaction hash.

Now this file can be used when decoding the transaction. The raw hex string can also be used, but it is easier to first save the transaction in a file when working with it.

To decode the transaction the following command is used:
$ bitgen decodetrans btc_DD62DD9CE8D3A4484C23C904996194B0241690E2B11B02313647A68C1186B48D.trans

This will give the following output:
Inputs: 1 Outputs: 2

14LTgYzjP9wbPVArV4WYheJW79RbUCEaAG 159D74C8CBBF8DEDEB3515B6CADD95E3D7DFE39C5FD9EC8888C47854009AACBB at 0

15Uk8PAvJPJwnzsMrVsfmpUDRSMF2NK8g5         2980000 satoshi = 0.02980000      btc
1JxLt4uK8Vbeod3VyXr5P7KPCC93Xh9BLs        10250480 satoshi = 0.10250480      btc

It is also possible to add the argument "verbose" at the end of the command line to get extended information:

Transaction data----------------------
Version   : 2
Locktime  : 459808 (block height)
Inputs: 1 Outputs: 2

--Input index 0
IHash  : 159D74C8CBBF8DEDEB3515B6CADD95E3D7DFE39C5FD9EC8888C47854009AACBB at 0
Address: 14LTgYzjP9wbPVArV4WYheJW79RbUCEaAG
Type   : P2PKH input
Seq    : FFFFFFFE
IScript: 47304402201304595735C8AB411E33DF908EACBD1B27F600284A7D4BB772127CE324EE778802201 8AF3831EFC2F238938E2E1C77001937206B3BED2F6DE264AB324F44CE23DBE80121036B5AA4D546 569BFD314235EDA77235EFE80C47B1666951AE009733512D8A3328
Decoded script: DATA(304402201304595735C8AB411E33DF908EACBD1B27F600284A7D4BB772127CE324EE7788022018A F3831EFC2F238938E2E1C77001937206B3BED2F6DE264AB324F44CE23DBE801) DATA(036B5AA4D546569BFD314235EDA77235EFE80C47B1666951AE009733512D8A3328)

--Output index 0
OScript: 76A914311FBC254B0756E9407107139D413A5A5863024A88AC
Decoded script: OP_DUP OP_HASH160 DATA(311FBC254B0756E9407107139D413A5A5863024A) OP_EQUALVERIFY OP_CHECKSIG
Script type: P2PKH output
 15Uk8PAvJPJwnzsMrVsfmpUDRSMF2NK8g5         2980000 satoshi = 0.02980000      btc
--Output index 1
OScript: 76A914C4F19C920B6112CAA86B74462B0FF39D81EC30BC88AC
Decoded script: OP_DUP OP_HASH160 DATA(C4F19C920B6112CAA86B74462B0FF39D81EC30BC) OP_EQUALVERIFY OP_CHECKSIG
Script type: P2PKH output
 1JxLt4uK8Vbeod3VyXr5P7KPCC93Xh9BLs        10250480 satoshi = 0.10250480      btc

It is also possible to "run" a transaction in order to verify if the scripts succeed, this is done with the "runtrans" command.
In order to run a transaction, the transaction(s) it depends on needs to be stored in file(s).
If the files are not found, an error is returned.

This command:
$ bitgen runtrans btc_DD62DD9CE8D3A4484C23C904996194B0241690E2B11B02313647A68C1186B48D.trans

Will give the following result:
InputHash: 159D74C8CBBF8DEDEB3515B6CADD95E3D7DFE39C5FD9EC8888C47854009AACBB Index: 0
Could not find locking transaction file, skipping verification for this input

Transaction FAILED

The specified transaction is missing, but it can be found using blockchain.info and the specified transaction hash:
https://blockchain.info/tx/159D74C8CBBF8DEDEB3515B6CADD95E3D7DFE39C5FD9EC8888C47854009AACBB?format=hex

When this transaction has been saved as "btc_159D74C8CBBF8DEDEB3515B6CADD95E3D7DFE39C5FD9EC8888C47854009AACBB.trans" the "runtrans" command is successful:

$ bitgen runtrans btc_DD62DD9CE8D3A4484C23C904996194B0241690E2B11B02313647A68C1186B48D.trans

InputHash: 159D74C8CBBF8DEDEB3515B6CADD95E3D7DFE39C5FD9EC8888C47854009AACBB Index: 0
Got script from file
InAmount: 0.13235000
Unlock succeeded for script

Transaction OK, all inputs OK

Total in amount : 0.13235000
Total out amount: 0.13230480
Miner fee       : 0.00004520

This will run the script and verify that it executes without errors.

Bitgen 0.13 has been released:

http://bitgen.org/

This release has moved parts of the codebase into the library bitlib:
http://bitgen.org/bitlib

The bitlib library currently includes functionality for address and private key handling,
more functionality will be included in later releases.

Also, the big integer implementation used by bitlib is released as a separate library
that provides support for fixed length signed big integers:

http://bigintctl.org/

This release also includes support for storing private key and address information
in a folder structure to make it easier to manage multiple addresses.
The command line argument "folder" should be added to use this feature, for example:

$ bitgen random folder

Windows binaries are now provided for direct download.
However, it is recommended that binaries are built from source instead
of using the existing exe-files.

On Linux it is very easy to build windows binaries.

bitgen can be used:
http://bitcoin-gen.org/

Currently it will require two commands to get the information, but modifying the source to give all information at once is trivial.
It can run on a 32-bit machine and has low memory requirements.

For example:
$ bitgen hex 12312381273918273128937128912c3b1293cb712938cb12983cb192cb1289b3 info

Would give:
Wif    : 5HxJGdttiqC6hd4wXyExr8Jmv6WugaCtZtteoT8MCj74fhanXrQ

Next:
$ bitgen info 5HxJGdttiqC6hd4wXyExr8Jmv6WugaCtZtteoT8MCj74fhanXrQ

Gives:
Public point  :(6B4D16EF98953A36752D7A2776B5989ED8700B8F80ECAA1818F15E3EF31D1532
              : E9B6F7C6BE1017AC8D0A733DD099CBBB3A0DAEC89514F50F57A4B0259ACC0F10)
Public key    : 046B4D16EF98953A36752D7A2776B5989ED8700B8F80ECAA1818F15E3EF31D1532E9B6F7C6BE101 7AC8D0A733DD099CBBB3A0DAEC89514F50F57A4B0259ACC0F10

Bitgen 0.12 has been released:

http://bitcoin-gen.org/

The release includes Windows support in addition to refactoring changes and improvements to the software tests.

No Windows binary is included (yet) since it is easy to build for Windows,
and to encourage building from source.

It is possible to build for Windows both on Linux and Windows, using Linux is actually easier than Windows.

On Linux the mingw-w64 cross compiler is used for the build.
On Windows MSYS2 is used.

Bitgen 0.11 has been released:

http://bitcoin-gen.org/

The new release includes:

* Performance improvements
* Support for bitcoin testnet and some other currencies

Work is in progress to prepare for a release of version 1.0.

Here is a description of cold wallet storage:

Bitcoin 101 - Intro to Paper Wallets & Cold Storage:

https://www.youtube.com/watch?v=I1uefzJJ6nM

There are people that have looked at the code, and I have also got code improvements sent to me.

But a deeper review of critical parts would be good before 1.0 is released.

I have some ideas of perhaps creating an independent library for the core functionality.
That would make it easier to focus on the important parts and not less important command line parsing etc.
The amount of core code is rather small.

(Tread title now also includes litecoin.)

Bitgen 0.10 has been released:

http://bitcoin-gen.org/

The new release includes Litecoin support and EC arithmethic operations.

Litecoin addresses are generated with the new "bitgen-ltc" binary, for example:

$ bitgen-ltc random

It takes a while to go through all the code, I just had a quick look at the main encryption function.

You use ECIES with the curve sect283r1 for public key encryption and aes-256-cbc for the symmetric encryption.

It seems like you send iv directly over the network.
That should be ok, but giving an attacker as little information as possible is a good thing,
so another possibility is to compute the iv from the shared secret, as is done in the Electrum ECIES.
But that is probably not a problem.

Here is the encrypt function:

==============================
    @staticmethod
    def raw_encrypt(data, pubkey_x, pubkey_y, curve='sect283r1',
                    ephemcurve=None, ciphername='aes-256-cbc'):
        if ephemcurve is None:
            ephemcurve = curve
        ephem = ECC(curve=ephemcurve)
        key = sha512(ephem.raw_get_ecdh_key(pubkey_x, pubkey_y)).digest()
        key_e, key_m = key[:32], key[32:]
        pubkey = ephem.get_pubkey()
        iv = Cipher.gen_IV(ciphername)
        ctx = Cipher(key_e, iv, 1, ciphername)
        ciphertext = iv + pubkey + ctx.ciphering(data)
        mac = hmac_sha256(key_m, ciphertext)
        return ciphertext + mac
==============================

The message encryption is not done by the elliptic curve when using ECIES,
conventional encryption such as AES is used for message encryption.

The elliptic curve is used to make the sender and the receiver agree on an encryption key.

From http://www.johannes-bauer.com/compsci/ecc/

================================
Performing encryption using ECIES is then relatively easy. Let's assume we want to encrypt data with the public key Q that we just generated.
Again, first choose a random number r so that
0 < r < n

Then, calculate the appropriate point R by multiplying r with the generator point of the curve:

R = r * G
Also multiply the secret random number r with the public key point of the recipient of the message:

S = r * Q
Now, R is publicly transmitted with the message and from the point S a symmetric key is derived with which the message is encrypted.
A HMAC will also be appended, but we'll skip that part here and just show the basic functionality.
================================

The only thing that is done with the elliptic curve is two multiplications.

The point S is used as a symmetric key, and is known by the sender and recipient but no one else.

The point R is transferred over a public network, seen by anyone.

The receiver can then compute S by using his private key.


Note the extreme simplicity in the scheme: Only EC multiplication is used.

If you have more information, I am interested in that.

The reasoning is simple: In order to break ECC, you would have to perform the "discrete logarithm"
in both cases, both for ECIES and ECDSA.

Use of ECIES also use conventional encryption such as AES which should also be cryptographically strong.
But the assumption is that the conventional crypto is sufficiently strong.

Regarding the security when using the public key for message encryption:

The security of the ECIES encryption is equally strong as the ECDSA that bitcoin use.

It is possible to estimate the strength of the encryption in monetary terms.

This is an address that contains 92 000 bitcoins:
https://blockchain.info/address/3A1KUd5H4hBEHk4bZB4C3hGgvuXuVX7p7t

The address is reused, money has been sent repeatedly from that address.
This means that the only thing that protects these 92 000 bitcoins is the Elliptic curve.
(When a message is signed the ECC public key is revealed)

The ECC is in this case able to protect 92 000 bitcoins.

If your encrypted data is worth less than 92 000 bitcoins it is safe.

Also look at bitgen:

http://bitcoin-gen.org/

The latest version supports public key encryption.