đź“… 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
Jeffrey Paul [ARCHIVE] /
npub1nd…54w0x
2023-06-07 15:27:42
in reply to nevent1q…2d7k
Author Public Key
npub1ndhsmnejw9cuvq3t6tuwd95q99mpdjx4szvnvx8szkp2vppqppgs254w0xPublished at
2023-06-07 15:27:42Event JSON
{
"id": "af53a523939fac2f6d981512fc1669ea8517cfe543566c4281a3b89b0670b5e4",
"pubkey": "9b6f0dcf327171c6022bd2f8e69680297616c8d580993618f01582a604200851",
"created_at": 1686151662,
"kind": 1,
"tags": [
[
"e",
"c6dbfebcd0f9a793242cef8ce15ddce4c1c9f20ab58ce3175f3a0ec04fe25d80",
"",
"root"
],
[
"e",
"3d71a4dc92858eb2fb54f633869a34d0649dc9a25b9e699407e311f33f01dd1b",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-12-04\n📝 Original message:\u003e On 20141204, at 07:42, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \n\u003e Is anyone working on a serialisation format to convey P2SH HD chains? For \n\u003e example, to give someone who wants to make recurring payments a single token \n\u003e that can be used to generate many P2SH addresses paying to a multisig script.\n\u003e \n\u003e I'm thinking of something along the lines of a simple series of tokens, each \n\u003e indicating either a HD chain or literal script content. For all HD chains in \n\u003e the data, a child key would be generated based on the payment number, and all \n\u003e tokens concatenated to form the P2SH serialised script. Eg, for a simple 2-\n\u003e of-2, you would do something like this:\n\u003e literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG)\n\u003e Does this sufficiently cover all reasonable use cases?\n\n\nWhat 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\n\n bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new\n\nAs 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?\n\nThe 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?\n\nLately 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?\n\nBest,\n-jp\n\n--\nJeffrey Paul EEQJ\njp at eeqj.com https://eeqj.com\n+1-800-403-1126 (America) +1-312-361-0355 (Worldwide)\n5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2",
"sig": "ff1c16891f4937caa86f74f0e35fadb9472fef36edef8958667642a63feabfc04b831a8523063fc79020397035d9b9f41ee65eb931c4c0ced160781865434d1f"
}