📅 Original date posted:2016-06-21
📝 Original message:On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote:
> > What do you mean by "replacement addresses" and "UI confirms" here?
>
> "Replacement addresses" would take the place of BIP 32/47 support, if
> someone thought maybe that was too difficult to deal with. So each time i
> paid Alice, Alice could generate a new payment address for the next monthly
> payment. If you support BIP 32 pub seed, then there's no need for this.
I suppose it makes sense that since every payment requires communication with
the recipient, that the recipient could give you a new scriptPubKey each time.
No need to save [potentially compromised] payment info in advance?
> I don't know any wallets that support a BIP 32 pub seed (and then what,
> some random number generator?) as a destination address yet.
The point, as I see it, of payment protocol(s) is to deprecate addresses.
ie, this new protocol *could be* the BIP 32 pub seed destination address. ;)
> > Disagree with hard-coding intervals, or mandating specific policies from
> > the service providers.
>
> I think mandating is a harsh word here, but i I'm a strong believer in
> providing strict guidelines that if people break, others can call them
> on. Giving someone a 12.3 +/- 5 day interval for payments using this
> protocol would suck. You should use payment channels for that stuff.
> The idea is a lightweight protocol for getting monthly subscriptions
> working.
Maybe just a field specifying how far in advance payments should be sent,
then?
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:51:19
in reply to nevent1q…nc9z
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:51:19Event JSON
{
"id": "a1dd61464b481ab92d7d6cc137889e16af964e12f8de794e5df522a6b06b0afd",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160279,
"kind": 1,
"tags": [
[
"e",
"a5039b46ff53fe0ad45fb1e565b7c7f05169b35d2126c2ee18198a6f3405f573",
"",
"root"
],
[
"e",
"4581ef7bd7da50ebd1673afe0296ab628d44697d96d101aa2f9b202439de96e2",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2016-06-21\n📝 Original message:On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote:\n\u003e \u003e What do you mean by \"replacement addresses\" and \"UI confirms\" here?\n\u003e \n\u003e \"Replacement addresses\" would take the place of BIP 32/47 support, if\n\u003e someone thought maybe that was too difficult to deal with. So each time i\n\u003e paid Alice, Alice could generate a new payment address for the next monthly\n\u003e payment. If you support BIP 32 pub seed, then there's no need for this.\n\nI suppose it makes sense that since every payment requires communication with \nthe recipient, that the recipient could give you a new scriptPubKey each time. \nNo need to save [potentially compromised] payment info in advance?\n\n\u003e I don't know any wallets that support a BIP 32 pub seed (and then what,\n\u003e some random number generator?) as a destination address yet.\n\nThe point, as I see it, of payment protocol(s) is to deprecate addresses.\nie, this new protocol *could be* the BIP 32 pub seed destination address. ;)\n\n\u003e \u003e Disagree with hard-coding intervals, or mandating specific policies from\n\u003e \u003e the service providers.\n\u003e \n\u003e I think mandating is a harsh word here, but i I'm a strong believer in\n\u003e providing strict guidelines that if people break, others can call them\n\u003e on. Giving someone a 12.3 +/- 5 day interval for payments using this\n\u003e protocol would suck. You should use payment channels for that stuff.\n\u003e The idea is a lightweight protocol for getting monthly subscriptions\n\u003e working.\n\nMaybe just a field specifying how far in advance payments should be sent, \nthen?\n\nLuke",
"sig": "967205b32fa51144905b9d3baf10ac1e4a9fcbf5f262f4d16e42be14557eaaf343e6cec1bb0ebeed74268f11a045d47a7a2da54677566342b00d397e2a87c500"
}