Ah, of course, I thought I was missing something! Thanks

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 see that Shamir's secret Sharing only as an alternative to passwords, not as an alternative to multiwallets. So in most cases this feature is not needed at all. Here are two examples:

Scenario #1: Multiwallet 2-of-2, passwordless

With BIP39 you can use two keys, e.g.
    before circle champion auto sleep embody nose february illegal refuse solve build
and a second key:
    enable struggle rather mail sea ski similar achieve ride wave hold black

The equivalent version with my proposal would be to use two 1-of-1 keys, e.g.
    banof gubit zokom zimuv tahuz vohih sahir nanuv vibar
and a second key:
    babor josas zasag dotit sasub jinug fanim lazup zogiv

The advantage of using my proposed proquints encoding here is that it's language agnostic, shorter, and provides better safety against typos

Scenario #2: 2-of-2 Multiwallet, one part password protected.

Again say you want to have a 2-of-2 multiwallet. In BIP39 it looks like this:

Part 1:
    dentist liquid evoke universe clinic convince cute erase fold about swap anger

Part 2:
    pepper cliff fruit wise extend daughter symptom quick once love shadow snap
password for part 2:
    my secret password that I will surely remember

In my proposal Part 1 is equivalent to above, a simple 1-of-1 proquint encoded key:
    bakad pusuz mamis vinod vutat siniz jutur vunun ruluv

For the second part of the multiwallet, since I do not support passwords, the alternative is to use a 2-of-2 shamir's secret:
    batuh nifat sizip jimuz hiror hibus masum ragis guhid
    bijol guhuh rudis hijag jofir virif duruv hudoz kufis

So instead of the 2 parts mnemonic & password, the key consists of 2 parts mnemonic & mnemonic. The main advantage here is that the password is replaced with another share that is required to reconstruct the secret.

This is different from multisignature. This a representation to store the root key, which might be part of a multisignature wallet or not. My proposal is similar to this: https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki

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!

Thanks! I've been talking with the author of bitcoinpaperwallet, maybe we'll integrate it into his site

Most of this page is actually from https://bitcoinpaperwallet.com/ which I am not part of. I have created a fork and only added the pattern generation on top of it.

Additionally, the obfuscation pattern is randomly created every time which should be safer than using a static picture.

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

Ah, verstehe.. das heißt ich muss meine wallet Datei nach jeder Transaktion sichern, damit ich die neu generierten Wechselgeldadressen mit dem Guthaben da drauf nicht verliere?

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?

oops, Ive just seen that exactly this is described in the HOWTO: create a 100% secure wallet document..

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?