public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeffrey Paul <jp@eeqj.com>
To: Luke Dashjr <luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Serialised P2SH HD chains
Date: Thu, 4 Dec 2014 12:02:17 -0800	[thread overview]
Message-ID: <F904F6F8-BA2E-4B86-8C6C-B34A88D384BD@eeqj.com> (raw)
In-Reply-To: <201412041542.44207.luke@dashjr.org>


> On 20141204, at 07:42, 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?


What is the use case for something like this?  It’s my impression that a single token that can be used to obtain many P2SH addresses paying to a multisig script looks something like

   bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new

As it’s impossible to actually transmit a tx without network access, why would it be necessary to, at payment time, not contact the payee and use the existing bip70 authenticated payment request protocol to find out exactly what multisig address they’d like paid at that moment?

The model that you describe where a payer can, without communication with the payee, generate additional multisig p2sh addresses based on a set of xpubs presumes that the payee would never want to e.g. cycle their own keys or change their cooperating multisig participants’ keys.  Is this wise?

Lately I’ve been thinking of bitcoin addresses (even multisig) as sort of MX records - something that the paying user shouldn’t depend on being static, because they are derived from keys that may change (or be lost or compromised) over time.  The canonical “pay me at this address forever QR code” should be a bitcoin: URI that points to a payment request generating URL, should it not?

Best,
-jp

--
Jeffrey Paul                                                      EEQJ
jp@eeqj.com                                           https://eeqj.com
+1-800-403-1126 (America)                  +1-312-361-0355 (Worldwide)
5539 AD00 DE4C 42F3 AFE1                      1575 0524 43F4 DF2A 55C2




  parent reply	other threads:[~2014-12-04 20:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04 15:42 [Bitcoin-development] Serialised P2SH HD chains Luke Dashjr
2014-12-04 16:46 ` Gavin Andresen
2014-12-04 17:25 ` William Swanson
2014-12-04 18:04   ` Mike Hearn
2014-12-04 20:02 ` Jeffrey Paul [this message]
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=F904F6F8-BA2E-4B86-8C6C-B34A88D384BD@eeqj.com \
    --to=jp@eeqj.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=luke@dashjr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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