From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xwd3A-0004Y0-8J for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 20:30:56 +0000 Received: from mail-pd0-f178.google.com ([209.85.192.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xwd38-0005hf-Sg for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 20:30:56 +0000 Received: by mail-pd0-f178.google.com with SMTP id g10so18283160pdj.23 for ; Thu, 04 Dec 2014 12:30:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=CRu93HmqVm9L9qNtpHYv/zB14Q5YxEUzV8996VcblFA=; b=VTBLpe8KfCJ5ppLkyZaieDo1H9o7IX+JxxXg+oG4fw8cwQqSb4OmlpGVckiUIudG9e +W5I6mhNPJMn34NKK2jqGElvQ+8ZZDzjfTlDM7WA/zR3JgMW5HSRMLJcsrv4IcgH6F3h dLDRWZC0xL7LfwxnyDBcw1I5IWuY1WG8zozOiBUxzXGk6yg7gRQwE4orNS4cI5X/Si1C +IMpAg99PwbcnXlLPy1+Bl2QfPpQDV2CjORCFkBO0qyUSctCxZqFg4XaQ+a8EjTBOeUp yHwgiLppeaDpr5GKsMkAJcb4wTQktabFUUtqjD0GjhMAk+zF509cifYBjL1X5Y0Iet9V ThNQ== X-Gm-Message-State: ALoCoQlqi3RgOg7hHHjPaWV2gBCq1pUZWyChIX2kWeW92FYC/tg9uy3hQlJXNdgI0xjJP+olpPkC X-Received: by 10.66.231.141 with SMTP id tg13mr22235840pac.122.1417723335814; Thu, 04 Dec 2014 12:02:15 -0800 (PST) Received: from [10.0.1.77] ([104.193.169.194]) by mx.google.com with ESMTPSA id ml5sm26996794pab.32.2014.12.04.12.02.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 12:02:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Jeffrey Paul In-Reply-To: <201412041542.44207.luke@dashjr.org> Date: Thu, 4 Dec 2014 12:02:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412041542.44207.luke@dashjr.org> To: Luke Dashjr X-Mailer: Apple Mail (2.1993) X-Spam-Score: 0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.6 URIBL_SBL Contains an URL's NS IP listed in the SBL blocklist [URIs: dashjr.org] X-Headers-End: 1Xwd38-0005hf-Sg 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:30:56 -0000 > On 20141204, at 07:42, Luke Dashjr wrote: >=20 > Is anyone working on a serialisation format to convey P2SH HD chains? = For=20 > example, to give someone who wants to make recurring payments a single = token=20 > that can be used to generate many P2SH addresses paying to a multisig = script. >=20 > I'm thinking of something along the lines of a simple series of = tokens, each=20 > indicating either a HD chain or literal script content. For all HD = chains in=20 > the data, a child key would be generated based on the payment number, = and all=20 > 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 = impression 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/new As it=E2=80=99s 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=E2=80=99d 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=E2=80=99 = keys. Is this wise? Lately I=E2=80=99ve been thinking of bitcoin addresses (even multisig) = as sort of MX records - something that the paying user shouldn=E2=80=99t = depend on being static, because they are derived from keys that may = change (or be lost or compromised) over time. The canonical =E2=80=9Cpay = me at this address forever QR code=E2=80=9D 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