Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2014-12-04 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2014-12-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul <jp at eeqj.com> wrote:
>
>> 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?
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 many ways of authenticating payment addresses. This stuff isn't evident in trivial consumer<->merchant use-cases, but is very common in anything else. For instance, consider the case of moving funds from a hot wallet or cold, 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 avoid specifying scriptPubKey formats too explicitly. (though obcs k-anon set 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
=Atvv
-----END PGP SIGNATURE-----
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul <jp at eeqj.com> wrote:
>
>> 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?
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 many ways of authenticating payment addresses. This stuff isn't evident in trivial consumer<->merchant use-cases, but is very common in anything else. For instance, consider the case of moving funds from a hot wallet or cold, 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 avoid specifying scriptPubKey formats too explicitly. (though obcs k-anon set 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
=Atvv
-----END PGP SIGNATURE-----