From: William Swanson <swansontec@gmail•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Eric Lombrozo <eric@ciphrex•com>
Subject: Re: [Bitcoin-development] Serialised P2SH HD chains
Date: Thu, 4 Dec 2014 09:25:05 -0800 [thread overview]
Message-ID: <CABjHNoRJV4r9YxjFamnA1G2CJwmig3FqbJhpXt9LAovMkPCPvA@mail.gmail.com> (raw)
In-Reply-To: <201412041542.44207.luke@dashjr.org>
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 <luke@dashjr•org> 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
next prev parent reply other threads:[~2014-12-04 17:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 15:42 Luke Dashjr
2014-12-04 16:46 ` Gavin Andresen
2014-12-04 17:25 ` William Swanson [this message]
2014-12-04 18:04 ` Mike Hearn
2014-12-04 20:02 ` Jeffrey Paul
2014-12-04 20:43 ` Peter Todd
2014-12-04 21:10 ` Luke Dashjr
[not found] <mailman.473107.1417725057.2207.bitcoin-development@lists.sourceforge.net>
2014-12-04 20:40 ` Michael Perklin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABjHNoRJV4r9YxjFamnA1G2CJwmig3FqbJhpXt9LAovMkPCPvA@mail.gmail.com \
--to=swansontec@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=eric@ciphrex$(echo .)com \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox