Topic: New wallet file ideas - page 2. (Read 2629 times)

In my view, the wallet IS the relationship, or at least a file representing one party's participation in a relationship.  Multiple relationships means multiple files, one file per party per relationship.  The data defining the relationship would be in the root structure of the wallet file, along with the party's own private keys and the other parties' public keys.  This would be consistent with the view that a regular wallet file was simply a "relationship" file where number of parties is 1 and that party has the one and only private key.



The proposal I speak of would preserve this ability.  Although I proposed that party A issue some record proposing a relationship and party B issued a record accepting the proposal, nothing stops A and B from being a single program running in a trusted environments and producing both records and printing them to separate pieces of paper.

Given that offline computers are something that come easy for you and me, and the popularity of smartphones among everybody else, I envision the most popular use case scenario being where party A is a computer, B is the same person's smartphone.  In this case, the "relationship record" goes from A to B in the form of a camera scanning an on-screen QR code, and where the returned record travels from the smartphone back to the computer via E-mail, or removable flash media, or the user just bearing it and hand-typing the response record off their phone's display onto their computer via keyboard.  Private key material for A is backed up by printing it, and private key material for B is backed up by the user writing down a wordlist-encoded record they see on their phone's screen.

Once such a relationship is set up, users would initiate transactions on their computer (A), and their on-computer client would show QR code (or a series of them if the transaction was large) containing the proposed transaction and the party A signature.  The smartphone would display the transaction details on screen, get the user's consent, provide the party B signature, and send it all directly to the bitcoin network itself.

Re: "Relationship Objects"

I like the idea of defining "relationships" and having that be defined somewhere. However, where would it be stored?  I really think that however it is done, it must be coded into the wallet:  the user should never be in the position that they recover this wallet and think it's a single-sig wallet.  I want wallets to be dedicated to multi-sig or not.  If a user doesn't want multi-sig, create a regular wallet.  (easy for me to say, Armory is a multi-wallet app)

To me, it would be ideal if two-factor auth wallets were always generated by an offline computer.  It would create both wallets and generate 3 things to print:   paper backup of AB, A'B and AB' (where A is full wallet and A' is watching-only wallet).  AB goes into a safe-deposit box, A'B is entered into one device (desktop), AB' entered into the other device (smartphone).  Those could be backed up, too, in separate locations, with less security each than the AB backup.  A physical burglar would have to find both to compromise the funds.   I don't want to see A backed up separately from B. I really want the user to be backing up the wallet after the linkage has been defined in the wallet, so it's obvious from the backup that it is a multi-sig wallet and to which other wallet it is linked.  

The problem is, not all users want to do this with an offline system.  The desktop could make both and then just delete B (after it's backed up).  But some users want the keys to never be on the same device, ever.  There will probably have to be an interface to convert a regular wallet to a paired wallet, and allow users to merge them at a later time.  Perhaps, it is as simple as popping up a warning, suggesting they make a new backup when a link is created.

For escrow transactions and contracts, etc, I think you have to allow a regular, single-sig wallet to generate a private key intended to be used for this purpose.  This would be signified by the stored P2SH script in the wallet file, which would contain both public keys (and your own will be easily identifiable).  When the wallet is loaded, it will search all stored P2SH scripts and identify how they relate to your wallet.  But that will need to be backed up the moment you generate it.  I just don't see another way to be totally safe about this without using something as persistent as Dropbox (what other backup options are there for this, besides keeping this extra file on a network drive on another system, or external device?)

Yes, you are right, that makes sense.  Count me up for one missing the obvious!

Because you yourself proposed putting "xpub" or "xprv" at the beginning. There is never a question of which one you are working on.

I don't believe this will work, because you won't be able to disambiguate when you have 33 bytes that begin with 0x02/0x03 and ends with 0x01, how do you know whether that's a public or private key?  You won't.

Besides, I have this cunning plan to start canvassing, writing a BIP to propose consensus seeking on base58 visual prefixes, and asking us to deprecate the "serialized private key format" you mention, and let the world rid itself of Bitcoin private keys that start with "L", which force users to ask "wtf is the difference between a '5' and a 'L' private key?  how about 'K' and 'L'?" and forcing TMUI(too-much-useless-information) down their throats just to understand Bitcoin.  It will most likely be to use 0x82 instead of 0x80 as a prefix byte (so the keys are still visually distinct in the 2nd character for those interested in compressed status at a glance), and then continue to accept the existing K/L format on a basis where it is universally acceptable as input (for compatibility) but propose that new keys in the old format never be emitted.

Well, I have little problem with changing the serialization of the extended public/private keys if it's worth it. Whatever preliminary implementations exist, I doubt they have more than the internal key derivation mechanism.

I've generally given up on the human recognizability aspect of Base58 - if we wanted that, base64 or base32 would be far better choices, as they allow prefixing/suffixing with bit/byte arrays without affecting every single encoded character.


I don't consider this a priority anymore. A human will need to know what type of data it encodes anyway before using it.


Ok, I admit I like that. I'll ask around whether anyone objects. Instead of 0x00 + privkey, I'll use privkey + 0x01, so that it matches the serialized private key format exactly (which has a 0x01 at the because the corresponding public key is compressed).

Here is what I think on P2SH persistence: I think the paired wallet idea is a great way to go.

Perhaps there should be such thing as a "relationship object": an object that exists for each party to the relationship, which includes that party's private objects, the pattern of keys that can be created in the relationship, and the public keys/objects of the other parties.  A "paired wallet" would be one type of relationship, but despite a pair sounding like a couple, a relationship could have many more parties than just two.

The first party proposes the relationship as a text record and decides how many vacancies are in it, and that record is transferred to other parties/devices, who in turn generate text records offering to fill those vacancies, much like creating a certificate signing request to acquire an SSL certificate.  When all parties/devices have all the records, they should all produce a single "relationship hash" acknowledging mutual understanding of the terms, at which point, the user(s) of the P2SH system can reconcile and confirm amongst each other that they have backed up the private goodies for each role in the relationship with hash H, and finally, address generation can occur by the parties/devices who have been authorized to do so.

P2SH addresses would be generated deterministically from the relationship object which must be backed up by each party to the relationship when the relationship is created, but no backup is ever necessary for the keys it produces.

Sample exchange in forming a relationship

1. Party/Device A creates a record that says: "I propose an (A AND B)" relationship.  I want to be A, here is my public chain code.  I'm looking for a B to offer a chain code."

The record could go on to say "In this relationship, new addresses should be issued by parties in this list: [A,B]".  One party could be responsible for all the issuing (e.g. if party A is a computer and party B is merely a smartphone app for confirming transactions).  Or, if multiple parties are authorized to issue addresses, then (for example) A issues addresses having sequence mod 2 == 0, and party B issues sequence mod 2 == 1. (replace 2 with the number of parties able to issue addresses).

2. Party/Device B is fed that record and agrees.  It creates a record saying "I agree to be the B for proposal whose hash is X. Here is my public chain code."

3. That record is transferred back to party/device A.  They each agree that a relationship H has been formed, where H is 32 bits of the hash of all the public keys etc going into the relationship record.  When all parties/devices acknowledge being parties to relationship H, and the user(s) have safely backed everything up, then they can start issuing addresses.

Defined this way, a "relationship" becomes a supertype of a wallet... a normal wallet can then be defined as merely a "relationship" with one party (self) who has the only private chain code and who itself issues all addresses.

As I look through BIP 0032 and see the suggestion for serializing extended public and private keys in Base58, I'm sort of turned off by the fact that the resulting strings have no useful visible prefix.  Any way we can change this before getting serious about implementations involving BIP 0032?

The BIP calls for 74 or 75 bytes starting with a "version" byte of 0x06.  This results in strings in the following ranges: CHp9i78Gq2z9cmoCwmasob3nLUfDMfhQPmRGAF12dARaUfsEi33j6UbWSe3SdRnfBbtqQmGZEFP5qvrD9amMVcbUuxZA znDwP1hKDNTKYb thru EAx1Vd9V8hz1PQGEwEMBwMPaZPbv5n9UHtpe27fhZXL1PcgGzYPWn4CG1utBZqFbt33UUiypGTSmKRA5WM4QuiXZZnUs L5Rm7M9N2fPpqe for 74 bytes, and rqD7SS36s1mF2tiwijnXEdHH6y5fYDoLFV45uno8AcbUm8YjW832oAoJxAVn7nQXXo1nftPfFUUUNxgCct2mTJ7CCkD1 82c72A4vu1oa9UR thru 218uoBLYTB1tchsgGWMv7Gtzf7xm7J6GPTZjGPvRp2YrtipUMayYNRs6hH2QuduySxG1vHNHmdDiicHd4tXY4XgHtjhk1 9CYHh1uvD9aCV8b for 75 bytes.  That means these strings could start with any character within "CDErstuvwxyz12".  Yikes!  How does one know by looking that such gibberish serves any specific purpose?

I'd like it much better if instead of worrying about conserving the "Version byte space", we considered the visual prefix space as seen by humans.

If instead of 0x06 and 0x0C, we used 0x0488B21E and 0x0488ADE4 plus 74 payload bytes, the resulting prefixes would be "xpub" and "xprv" respectively.  0x043587CF and 0x04358394 yield tpub and tprv (for testnet).  If instead of specifying "use 32 bytes for a private key and 33 bytes for a public key", we specified "use 0x00 + 32 bytes for a private key" (knowing public keys always start with 0x02 or 0x03), then the payload beyond the prefix would always be 74 bytes, and we wouldn't have base58 prefixes that change drastically because the message length changed.  One could know by looking just what they are looking at.

As for the original question (how to safely persist P2SH scripts), I have input on that as well but am still contemplating whether it's sensible.

Sure, I was using Dropbox as a common example of a reliable backup system someone would want to use, but hesitate because of the security concerns.   But there's lot of other systems people could use to do this backup -- but with this method, it doesn't have to be a secure channel to maintain your privacy.

This won't work for everyone, but for those people who have it installed Freenet is ideal for storing data like this. For that matter you could securely backup the entire wallet in Freenet.

I am in-process of doing a full rewrite of Armory wallets; not just to improve the design, but to enable tons of new features.   However, I think this time I want to collect input from others before I go ahead and just do it my own way.  I'd like some feedback before I'm too committed to it my way.  

There are two major features I want to implement in the wallet that are "forward-thinking."  There's a lot of other stuff going in, but these are the two that warrant a real discussion.   Some quick background:  the new wallets will be based on BIP 0032 so that they will be compatible with future Satoshi wallets, and get all the nice features of hierarchical deterministic wallets.  There will have the ability to store multiple wallets/chains/accounts per file.  There will also be a way to merge wallets.  And, I want the wallet to handle P2SH scripts elegantly.  

However, P2SH engenders some complications in the wallet design.  P2SH was designed to hide scripts, thus you cannot just search the blockchain for multi-sig tx involving you -- you must actually save the (TxID, p2shScript) pair somewhere so you can recognize and find it later.  This is really annoying from the wallet-backup perspective:  all P2SH scripts must be backed up immediately to avoid potential of losing coins, but you also don't want your primary wallet to be copied around everywhere.  For instance, I think Dropbox is ideal for backing up P2SH scripts and tx/address comments, but should the user should never backup his entire wallet to Dropbox.  And I don't trust users to manually&responsibly set up reliable backups.   With that in mind:

• (1) Paired-wallet support (two-factor auth):  Each wallet/chain/account will have a field to specify another wallet/chain/account.  If that field is present, it signifies this is a "paired" wallet -- Armory will expect to have a watching-only copy of the second wallet in the same file.  It will never generate single-sig addresses -- it will only generate P2SH scripts requiring a signature from both wallets (design will also accommodate 2-of-3 and 3-of-3 wallet combos).  All multi-sig scripts will have public keys added to them in the order of the wallet IDs -- the wallet with the lower binary fingerprint/ID will always have its address first, etc.  By doing this, devices with complimentary wallet combinations (A'B and AB') will generate the same, completely deterministic chain of 2-of-2 payment addresses.    This means that in either wallet, I can say "get me address index 37", and it will fetch PubKeyA[37] and PubKeyB[37], and put them into a P2SH 2-of-2 script and return the associated payment address.  This makes P2SH for two-factor-authentication schemes completely deterministic, and will look almost identical to a regular wallet.  (for two-factor auth, you don't need ((A and B) or C) transactions, you just use (A and B) and backup both wallets to where you would otherwise backup wallet C)
• (2) "Lightly encrypted" P2SH and Comments files:  There are still situations where you need to backup your scripts:  escrow transactions with strangers on the internet, or various other contracts, etc.  Also, it would be nice to backup your comments/labels too, but not worth risking your whole wallet to do it.  So the user will be able to enable an external "wallet" file containing only these scripts & comments ("wallet" in quotes because it stores no keys).  Whenever you save a comment or P2SH script, it will save it to both files. Most importantly, these scripts and comments will be encrypted with AES256 using HMAC(walletRootPubKey, walletRootChainCode) as the encryption key.  Therefore, this external file can be backed up just about anywhere, even Dropbox, because the holder needs [at least] the watching-only wallet to decrypt it.  Someone who compromises only your Dropbox account will not have that wallet, and thus your privacy is maintained.  If your HDD crashes, you can restore your deterministic wallets/chains/accounts from your backup, and merge the Dropbox'd file into it and you're back to where you were before the HDD crash.  This not only saves your P2SH scripts from failure, but gives you a way to preserve all your address comments/labels, too (i.e. -- it's useful even for non-P2SH wallets).  The default behavior will be to not have an external file, but to allow the user to specify a location to create it that will be backed up regularly.

Edit:  Some might suggest you could always get the P2SH script from the other party if you lose your wallet.  My response is:  what if you stored their contact information as a comment in your wallet file?  This system would preserve both comments and P2SH scripts on an insecure channel without compromising privacy.

Number 2 is a bit crazy, but I think it solves a unique problem introduced by P2SH, as well as providing extra options for users deciding how to keep their P2SH/comments file backed up.