In bip 152 compact block relay is described, which consist of a list of 6-byte shortids: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

In bip 158 Golomb-Coded Sets are described, which sounds to me like the ideal data structure for these IDs. I wonder if it would be beneficial to encode & transmit a golomb-coded sets for the shortids instead of the fixed 6-bytes? It should reduce the size of the transmitted data a bit, at the cost of a bit more processing power.

I've been working on an alternative to BIP39. These are my main motivations:

• I wanted to get rid of the wordlist, and replace it with a more language agnostic representation that's still relatively easy to read.
• Much more compact representation.
• Use a configurable n-of-m representation of the root key instead of passwords

Additionally, the prototype that I have has these features:

• Very compact representation: 16bit overhead for each share
• 4 version bits. This prototype is currently version 0.
• Supports n-of-m shares, up to 4-of-4.
• Very good safety against typos: The probability that a typo of a 2-of-m share is undetected is 1 in 262144.
• Very compact QR code: 128 bit encode into 45 Alphanumeric characters, so version 2 is enough. E.g. see https://chart.googleapis.com/chart?chs=150x150&cht=qr&chl=BASABMIVAPPOTUFJULOHHIFOBRIGIJPAJIHLUTOLHAJAJ
• Accidentally mixing two shares that were constructed from different secret is undetected with a probability of 1 in 65536.
  
• the proquints representation is optional, e.g. base 58 is also possible.

Here is a sample random 128 bit secret encoded in 2-of-3 shares:

batod kibab namus jupag pahot zumas filur fuhuk hojid
bipap bupar bugul nadun lokil kuhoj jilub buzih pijuv
bonik foguf mutal fasoz gaham dugar mubab dakap bofif

Each share consists of 9 proquints (see https://arxiv.org/html/0901.4016) encoding 16 bits each. The first proquint is special: it encodes the version, share ID, number of required shares to reconstruct the secret, and checksum.

• Version: the first 4 bit. Since the first 4 bit are encoded by the first letter, the letter for version 0 is always 'b'.
• Share ID: 2 bits to identify the ID of the share (1, 2, 3, 4).
  
• The next 10 bits encode the number of required shares (2 bit), and 1-byte checksum of the reconstructed secret. These 10 bit are XORed with 10 bits of the checksum of the share when the 10 bits were set to zero. When decoding the message from two shares, the number of required shares and 1-byte checksum of the secret is reconstructed for each share by XORing back with the share's checksum. Both shares must decode the same 10 bits to be valid. Additionally, the first byte of the reconstructed secret's checksum must match for a reconstruction to be successfull. Thus, the actual safety of this checksumming system is 2^10 * 2^8 = 2^18 = 262144 (there is a 1 in 262144 chance that a typo remains undetected).

I have a prototypical implementation in Ruby here: https://github.com/martinus/bitcoin-mnemonic/blob/master/bitcoin-mnemonic.rb.

What do you think? I appreciate any comments!

I've played around with bitcoinpaperwallet, and modified the code to automatically create a unique guilloche pattern for any bitcoin address. Here is the result:

http://bitcoin.ankerl.com/generate-wallet.html
Click on "Print front", then press "randomly generate new key" a few times to see the kinds of patterns this generates.

Here is an example:

This is inspired by Identicon, where a pattern is created as a visual representation of a hash value. I want to automatically create a beautiful paper wallet pattern that is also unique, only dependent on the bitcoin address. So when you manually enter a private key in the above link, it will always generate the same pattern for the same bitcoin address.

I wonder what you all think about this? You can see my changes on github: https://github.com/martinus/bitcoinpaperwallet

Hallo, ich hab vor kurzem 0.5 BTC auf 1ketoNTtcSz3kN3KwMM2ad3APccNvxnpm überwiesen. Komischerweise wird jetzt angezeigt dass zwei mal 0.5 BTC überwiesen worden sind, und zwar einmal an eine von mir unbekannte Adresse, siehe

http://blockexplorer.com/tx/27d75964a3a3fbe3861b5766e95b85476709fbddfe151fb6475af4eb55f4d7f8

Was ist da los, wo sind jetzt meine zweiten 0.5 BTC hinverschwunden?

Hi, I wonder if this would be a good/save idea to use bitcoins more securely:

1. Create a wallet with bitcoin
2. Write down it's address
3. Encrypt this wallet (e.g. 7z with encryption), and send it to yourself via email. This will be the 'savings account'.
4. Delete the wallet from your computer
5. Create a new wallet, this will be your 'portemonnaie'
6. Whenever you want to save some coins securely, send them to the address of the 'savings account'.

As I see it, this way you can secure most of your money, and when the computer get's compromised, the intruder cannot get to the savings account.

Will this work? Or is it possible that transactions to the 'savings account' will get lost, when you do not actually use it in the bitcoin client?