Jeffrey Paul [ARCHIVE] on Nostr: đź“… Original date posted:2014-12-04 đź“ť Original message:> On 20141204, at 07:42, ...
đź“… Original date posted:2014-12-04
đź“ť Original message:> On 20141204, at 07:42, Luke Dashjr <luke at 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 at 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
đź“ť Original message:> On 20141204, at 07:42, Luke Dashjr <luke at 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 at 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