From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XwdHM-0008HX-Ol for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 20:45:36 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.80 as permitted sender) client-ip=62.13.149.80; envelope-from=pete@petertodd.org; helo=outmail149080.authsmtp.com; Received: from outmail149080.authsmtp.com ([62.13.149.80]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XwdHL-0004RG-Cm for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 20:45:36 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sB4KjP4O051210; Thu, 4 Dec 2014 20:45:25 GMT Received: from [10.32.64.79] (no-dns-yet.sleek.net [37.205.56.238] (may be forged)) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sB4KjOir080953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2014 20:45:25 GMT User-Agent: K-9 Mail for Android In-Reply-To: References: <201412041542.44207.luke@dashjr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Thu, 04 Dec 2014 20:43:32 +0000 To: Jeffrey Paul , Luke Dashjr Message-ID: X-Server-Quench: 791af9f2-7bf6-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgYUHFAXAgsB AmIbWVReVFh7W2Y7 aA1PbwVYfE9IQQdp WFdNRFdNFUsrcxh6 XGFHEBl6dwxDezBx ZkZiWj5cVUUrI08r QFNTRzsAeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4wEyQ9 ThQDBjgjVXVffAV7 DzBuIV4VHUAKWgAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 37.205.56.238/465 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by punt17.authsmtp.com id sB4KjP4O051210 X-Spam-Score: -0.9 (/) 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 SPF_PASS SPF: sender matches SPF record 0.6 URIBL_SBL Contains an URL's NS IP listed in the SBL blocklist [URIs: dashjr.org] X-Headers-End: 1XwdHL-0004RG-Cm Cc: Bitcoin Dev 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 20:45:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul wrote: > >> On 20141204, at 07:42, 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? > > >What is the use case for something like this? It=E2=80=99s my impressio= n that >a single token that can be used to obtain many P2SH addresses paying to >a multisig script looks something like > >bitcoin:?r=3Dhttps://payee.com/customer12345/recurring/paymentrequest/ne= w > >As it=E2=80=99s impossible to actually transmit a tx without network acc= ess, >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=E2=80=99d like paid at that = moment? It's quite common to run into situations where the payee is *not* online.= Similarly requiring them to be online is a security risk and defeats man= y ways of authenticating payment addresses. This stuff isn't evident in t= rivial consumer<->merchant use-cases, but is very common in anything else= . For instance, consider the case of moving funds from a hot wallet or co= ld, and vice-versa. Luke-Jr: sounds like some of the ideas I've been playing around with for = generalised stealth addresses, using a declarative template scheme to avo= id specifying scriptPubKey formats too explicitly. (though obcs k-anon se= t issues) -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQFQBAEBCAA6BQJUgMd0MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRJjB/0fvNisFR4cktOhDJYl nq2gb39aiV7Wufh7NcTI0mqsC1yhIgFW5fgl7TmiK76Tn4gH0rhfJe3u7GhVsmSy Sx1qEJJN6yNsiu6elmLe8xISVTwHu+kLqKFTyZNrd4BObHVumyLAhea2lFSzZmBu GQF/AnVzf06vAT8CnZZm3hMgt1kFv32KglIIWLdztvvgi7yK6fi2GlZUW1J+jCUk 6AyQbnpPkHPHIJe7UMM0oeC2w6cN5nH0ccIutwkYDHwo/APa0TkX1hu3bJh5/Cor zh+BLdOYgAP28wUZ1fkQoAj/0l79+3wyBC7+6lblV90y7C68G6zqMav7lDZdsBK9 4DU0 =3DAtvv -----END PGP SIGNATURE-----