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
next prev 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 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--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