Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of dashjr.org
	designates 85.234.147.28 as permitted sender)
	client-ip=85.234.147.28; envelope-from=luke@dashjr.org;
	helo=zinan.dashjr.org; 
From: Luke Dashjr <luke@dashjr.org>
To: Jeffrey Paul <jp@eeqj.com>
Date: Thu, 4 Dec 2014 21:10:14 +0000
User-Agent: KMail/1.13.7 (Linux/3.17.3-gentoo; KDE/4.12.5; x86_64; ; )
References: <201412041542.44207.luke@dashjr.org>
	<F904F6F8-BA2E-4B86-8C6C-B34A88D384BD@eeqj.com>
In-Reply-To: <F904F6F8-BA2E-4B86-8C6C-B34A88D384BD@eeqj.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201412042110.16655.luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Serialised P2SH HD chains
Precedence: list

On Thursday, December 04, 2014 8:02:17 PM Jeffrey Paul wrote:
> What is the use case for something like this?  It=E2=80=99s my impression=
 that a
> single token that can be used to obtain many P2SH addresses paying to a
> multisig script looks something like
>=20
>    bitcoin:?r=3Dhttps://payee.com/customer12345/recurring/paymentrequest/=
new

This requires the payee operate a server. My use case is for payment to=20
individuals, who may or may not have a computer powered at the time of the=
=20
transactions being sent. Furthermore, the users I am targeting (miners, to =
be=20
specific), wish to remain entirely anonymous, and not hold accounts of any=
=20
sort.

> 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=E2=80=99 keys.  Is=
 this
> wise?

This depends on the framework. As of present day, miners are limited to onl=
y=20
use a single address ever, and cannot change it even to avoid address reuse=
=2E=20
One goal is to solve that, without breaking multisig.

Luke