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.

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.

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.

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

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.

I was under the impression that P2SH was intended for all multi-sig transactions, though you are right there is no reason plain-text multi-sig can't be used (is there? they were probably never added to isStandard...).  One reason for desiring P2SH, in general, is that very long scripts become part of the TxIns instead of the TxOuts.  This means that they will never bloat a pruned version of the blockchain.  If everyone only used P2SH, then no TxOut script would ever be longer than 22 bytes.

I don't want to get side-tracked on the philosophy and use-cases of P2SH (though, I do agree, I much prefer plain multi-sig for escrow/contracts).  Even if users agreed to use plain multi-sig and avoid necessitating such backups, there's probably plenty of information in their wallet that is nearly-critical to have backed up -- perhaps contact information stored with the wallet, order numbers of various transactions, identities associated with non-wallet addresses, etc.  A lot of this isn't widely used now, but I expect it will be with the URI spec -- I've been pushing for contact information and order numbers to be included in URI strings so that when a merchant requests payment for something, they can auto-document the transaction for the buyer by pre-filling those fields which will end up in the user's wallet.  Even without P2SH, the user has a strong interest in securing that data (and users always fail if effort expenditure is required for a seemingly-non-essential operation).

Alan, did you look at the payment protocol discussions happening on bitcoin-development? Some of it may be relevant to this work.

Re: P2SH/normal, I agree with Mike that P2SH is not always the right tool for the job. It was designed on the assumption that people will want to use short addresses and that may well turn out to be true, but if we successfully move most payments to use a payment protocol (as we're going to try) then addresses will start to fade away as a user-visible part of Bitcoin and that rationale goes away. It leaves P2SH being purely a UTXO set size optimization, which like any optimization must be weighed against the additional complexity it introduces. If it's going to make the user experience worse, it's better to just use regular scripts.

Mike, escrow is indeed meant to work as you describe but using 2-of-3 multisig which boils down to (A AND E) or (B AND E) or (A AND B):

  https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

A think a lot of these things become easier to reason about when you assume a payment protocol.

Ahh, so it does make sense to use P2SH for paired/linked wallets, and regular multi-sig for escrow tx, etc.  For some reason, I was under the impression that P2SH was intended for everything.  I do prefer plain multi-sig for those escrow tx.

@Mike,

I'm not sure the payment protocol changes this much.  It means that the decision about which form to use will be irrelevant to those using the payment protocol, but there will still be users who will do it the "old" way, which should still be accommodated.  Though it sounds like we already have a consensus ... it makes sense to use P2SH for linked wallets, and regular multi-sig for isolated escrows and contracts.

---

@Casascius:  I was just about to post an expanded idea for linked wallets, but I think you already did it.  I'll restate it, though, for clarity, and maybe add a little.

Let's say I make wallet A/j, and my spouse creates wallet B/j.  We exchange the root of the external/internal chains.  Meaning, we exchange the data needed to not just generate one chain of addresses, but both the primary chain and change chain.  

So, I give her A'/j and she gives me B'/j.  All addresses generated by my wallet will be of the form 2of2([A'/j/0/x, B'/j/0/x]) and all change will go to 2of2([A'/j/1/y, B'/j/1/y]) -- external chain is 0, internal chain is 1.  The order will be switched for her wallet:  she will create addresses of the form 2of2([B'/j/0/x, A'/j/0/x]) and change will go to 2of2([B'/j/1/y, A'/j/1/y]).  So each wallet will only generate addresses from its own two chains, but watching for addresses on all four chains.  

I'm pretty sure that's very similar to what you suggested.  


EDIT: to avoid ordering issues for 3+ wallets, the addresses should be ordered by wallet fingerprint order, and each wallet always generates addresses starting with their own in that list, wrapping around.  So if the wallet fingerprints end up ordering the wallets  B, A, C,  then all 2-of-3 addresses generated by wallet B will be {B,A,C}, wallet A will be {A,C,B} and wallet C will be {C,B,A}.  That makes sure there are only N possible address orderings (one per party), instead of N-factorial