From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xwa9P-0000nn-Pn for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 17:25:11 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.45 as permitted sender) client-ip=209.85.213.45; envelope-from=swansontec@gmail.com; helo=mail-yh0-f45.google.com; Received: from mail-yh0-f45.google.com ([209.85.213.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xwa9O-0003sL-Uw for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 17:25:11 +0000 Received: by mail-yh0-f45.google.com with SMTP id f10so8447517yha.32 for ; Thu, 04 Dec 2014 09:25:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.236.30.65 with SMTP id j41mr13023569yha.105.1417713905573; Thu, 04 Dec 2014 09:25:05 -0800 (PST) Received: by 10.170.34.69 with HTTP; Thu, 4 Dec 2014 09:25:05 -0800 (PST) In-Reply-To: <201412041542.44207.luke@dashjr.org> References: <201412041542.44207.luke@dashjr.org> Date: Thu, 4 Dec 2014 09:25:05 -0800 Message-ID: From: William Swanson To: Luke Dashjr Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.0 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (swansontec[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.6 URIBL_SBL Contains an URL's NS IP listed in the SBL blocklist [URIs: dashjr.org] X-Headers-End: 1Xwa9O-0003sL-Uw Cc: Bitcoin Dev , Eric Lombrozo Subject: Re: [Bitcoin-development] Serialised P2SH HD chains X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:25:12 -0000 Yes. A few of us over here in San Diego actually started working on a format like this a few months ago, but it's been on the back burner for a while. Our motivation was to come up with a shared HD wallet format. Say I would like create a 2-of-3 multisig wallet using my phone, PC, and hardware key fob. All three devices would presumably be running different wallet software, so we need some sort of standardized HD multisig chain-description format that all three wallets can understand. That way, regardless of their other differences, the wallets can at least agree on how to generate new addresses. Of course, once you share this chain-description file with a third party, they too can generate addresses out of the wallet. This can be used for auditing (like for charities), for receive-only wallets (like a merchant kiosk), and for recurring payments. The recurring payment case is a little problematic, since you need to trust the payee with your privacy. I imagine this would only be useful for payouts you manage yourself, like a mining pool, and not something you share with the general public. Our format is very similar to yours. We have a script template, just like you do, but we describe the HD chains in a separate section rather than in-line with the script. The script template only comes into being once the chains have been gathered together into one place, so the chain descriptions need to stand alone. Unfortunately, we still have a lot of details to work through before we have a concrete proposal that's ready for this mailing list. Perhaps we can work together to come up with something. -William On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr wrote: > Is anyone working on a serialisation format to convey P2SH HD chains? For > example, to give someone who wants to make recurring payments a single token > that can be used to generate many P2SH addresses paying to a multisig script. > > I'm thinking of something along the lines of a simple series of tokens, each > indicating either a HD chain or literal script content. For all HD chains in > the data, a child key would be generated based on the payment number, and all > tokens concatenated to form the P2SH serialised script. Eg, for a simple 2- > of-2, you would do something like this: > literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG) > Does this sufficiently cover all reasonable use cases? > > Luke